Wikipedia talk:Manual of Style/Dates and numbers

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Manual of Style
WikiProject icon This page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.

Microsoft is more important than IBM and Toshiba[edit]

It is for the best that editors remain unaware that IBM and Toshiba use unambiguous binary prefixes, because (shock, horror, probe!) they might start to use them themselves, and we wouldn't want that, would we? Dondervogel 2 (talk) 21:26, 1 August 2014 (UTC)

For further clarification, according to IBM:

  • Decimal units (base-10), such as K, MB, GB, and TB, are commonly used to express data storage values. These values, however, are more accurately expressed using binary units (base-2), such as KiB, MiB, GiB, and TiB. At the kilobyte level, the difference between decimal and binary units of measurement is relatively small (2.4%). This difference grows as data storage values increase. When values reach terabyte levels, the difference between decimal and binary units approaches 10%.
  • To avoid confusion, the online LTFS Single Drive Edition product documentation represents data storage using both decimal and binary units. Data storage values are displayed using the following format:#### decimal unit (binary unit)
  • For example, a value of 512 terabytes is displayed: 512 TB (465.6 TiB)

It is for the best that Wikipedia editors remain ignorant of the benefits of IEC prefixes. Dondervogel 2 (talk) 21:40, 1 August 2014 (UTC)

Please read WP:RIGHTGREATWRONGS. What you added, even if the statements are accurate (I didn't check; many such statements added have been faked), have no place in the MOS. They may be used on the MOS talk page to attempt to justify a change in the MOS, but they do not belong in the MoS. — Arthur Rubin (talk) 23:13, 1 August 2014 (UTC)
See also the OR-laden QUOTEFARM Timeline of binary prefixes, which includes stuff like '1957 ... Earliest instance of "kilobit" in both IEEE explore and Google Scholar'. EEng (talk) 23:40, 1 August 2014 (UTC)
Well, are the statements in question true or false? Is this yet another context in which we are supposed to ignore inconvenient facts for political reasons? Archon 2488 (talk) 22:48, 2 August 2014 (UTC)
IBM still uses KB, MB and GB to specify memory in their computers. Here are some quotes on the IBM Power System S824 [1]
"Level 4 (L4) cache - 16 MB per DIMM" and "Memory Min/Max - 16 GB, 32 GB and 64 GB 1600 MHz DDR3 module"
The IBM zEnterprise z196 [2] can have 3056 GB of Processor Memory.-- SWTPC6800 (talk) 23:53, 2 August 2014 (UTC)
The question is, are these units actually GB etc. or are they GiB, etc.? Archon 2488 (talk) 00:25, 3 August 2014 (UTC)
IBM may be weird (they now offer a decimal floating point unit on their mainframes) but they're not weird enough to build Random-access memory (RAM) with a capacity that is evenly divisible by one billion. Nobody's built RAM with a bit capacity that's evenly divisible by a power of 10 since the 1950s. Jc3s5h (talk) 00:56, 3 August 2014 (UTC)
The memories are industry standard binary size. The decimal floating point units are required for bookkeeping that is accurate to the penny. The repeated decimal to binary to decimal conversions of several million dollars could introduce serious round off errors. All the calculations are done in decimal to eliminate this problem. -- SWTPC6800 (talk) 01:32, 3 August 2014 (UTC)

I don't see the relevance of computer architecture to how data storage is reported. In its customer support pages, to reduce confusion IBM consistently provides conversions between MB and MiB. Here's another example:

  • Decimal units such as KB, MB, GB, and TB have commonly been used to express data storage values, though these values are more accurately expressed using binary units such as KiB, MiB, GiB, and TiB. At the kilobyte level, the difference between decimal and binary units of measurement is relatively small (2.4%). This difference grows as data storage values increase, and when values reach terabyte levels the difference between decimal and binary units approaches 10%.
  • To reduce the possibility of confusion, this information center represents data storage using both decimal and binary units. Data storage values are displayed using the following format:#### decimal unit (binary unit)
  • By this example, the value 512 terabytes is displayed as: 512 TB (465.6 TiB)

The wording is slightly different but the underlying message is the same. The fact is that IBM and Toshiba are following international standards. Another fact is that IBM has gone to a lot of trouble to explain why it follows them. A third fact is that MOSNUM editors consider it appropriate to hide this information from its readers.Dondervogel 2 (talk) 07:47, 3 August 2014 (UTC)

Our (well, your) reasoning is not appropriate for the MOS, but only for discussions about the MOS. (And, even if correct, it doesn't significantly affect the arguments for the status quo, that KiB, MiB, etc., should not be used unless used in the sources.) — Arthur Rubin (talk) 08:04, 3 August 2014 (UTC)
So far I have just stated relevant facts. You are arguing that while MOSNUM readers (i.e., WP editors) need to be informed that unambiguous units are unfamiliar, they do not need to know that they are being used for disambiguation by the computer industry in situations for which disambiguation is needed. So far I have drawn no conclusions from the facts, but let me do so now by stating that I disagree strongly with your opinion and by explaining why. For the most part, MOSNUM does a good job not just in prescribing good practice, but in explaining the reasons for the choices made. A bizarre exception is made in the case of binary prefixes. Where it has attempted to disambiguate, the computer industry has chosen to use IEC binary prefixes for binary powers, and standard prefixes for decimal powers. MOSNUM should follow that lead instead of insisting on the present (failed) guidelines that result in hundreds (possibly thousands) of ambiguous articles. Dondervogel 2 (talk) 11:03, 3 August 2014 (UTC)
Suggestion: does the convert template not support TB --> TiB conversions, etc? If not, why not? This would be a good way to disambiguate, and should keep everyone happy. It's all very well to say that WP should follow the conventions used by particular industries, but then in order to understand the units used, it would appear that the readers would also need to be familiar with industry practice. Archon 2488 (talk) 12:36, 3 August 2014 (UTC)
The first step would be to find an industry that uses the "MiB" units. An obscure application note on the IBM web site does not mean IBM uses this failed standard. "MiB" has been the binary unit of the future for almost 2 decades. -- SWTPC6800 (talk) 14:41, 3 August 2014 (UTC)
Toshiba press releases and product specifications [3] [4], plus IBM [5] [6] [7] and HP [8] [9] Dondervogel 2 (talk) 15:21, 3 August 2014 (UTC)
It's still beyond the scope of this discussion or of what should be in the MOS, but you have demonstrated that some (major) players in the industry say that they use MiB or that they use MB solely in the decimal sense, not that the industry uses MiB, even in situations where the disambiguation between the binary and decimal usage are made. (I was going to say "are necessary" rather than "are made", but that would be wrong.) We would need third-party comments to remove the "say", and survey articles to support what you seem to want. — Arthur Rubin (talk) 14:50, 4 August 2014 (UTC)
What I have shown is that these major players do use MB vs MiB to disambiguate between decimal and binary meanings, by which I mean that when both meanings are needed in the same article or on the same page, the decimal meaning is indicated by MB and the binary by MiB. I maintain further that this is the only form of disambiguation followed by industry and challenge you to cite one single example of a major player using an alternative disambiguation method. Dondervogel 2 (talk) 15:39, 4 August 2014 (UTC)
Here's an example where a major player (Samsung) deliberately exploits the confusion to "overprovision", describing a GiB of SSD as a GB, while reserving the additional ~7.4% for bad block repairs. This seems like a relatively principled practice if one concedes to the idea that confusion is inevitable, but the explicit conversion is clearly the most honest approach. Using {{convert|1|TiB|TB}} seems perfectly reasonable, though Module:Convert does not presently support these units. LeadSongDog come howl! 18:53, 7 August 2014 (UTC)
IEC prefixes shouldn't be used on Wikipedia just because someone can find one quote somewhere on a website from a manufacturer, especially when other pages from the same manufacturer use the commonly used units. Has the majority use or consensus changed in the real world yet? No it hasn't. No MOS change needed. Disambiguate any articles using exact numbers (or power notation) instead of IEC prefixes, the exact numbers (or power notation) are simpler and generally understood by more people. Fnagaton 11:55, 9 August 2014 (UTC)

MOSNUM history on IEC binary units[edit]

The adoption of the IEC binary prefixes on MOSNUM in July 2005 was controversial from the start.

This is ridiculous. There are a few extremely important points that are being ignored here. First, and most importantly, The Manual of Style should reflect common usage on Wikipedia, and not prescribe a usage which is not the common usage'. So no matter if 3 or 5 people vote here that the MoS should "recommend" the IEC prefixes, if that usage is no the common usage on Wikipedia, then it shouldn't be in the MoS. The reality is that the IEC prefixes are extremely obscure, particularly to the lay reader. Second, "oh, we'll just put in a link" is not really an adequate response to that complain. It's not a valid argument for the same reason that many articles include measurements in feet in inches. Third, people are used to kilobytes being 1024 bytes and megabytes being 1024 kilobytes, and even though there are new prefixes that define that explicitly, those prefixes do not enjoy common usage. It doesn't matter if they're official (whatever that means--there is no regulatory authority over the English language). The only thing that matters is common English usage—and with the exception of hard disk manufacturers and a few others, a megabyte almost always means exactly 1,048,567 bytes. Usage on Wikipedia should reflect the common usage, and the MoS should reflect usage on Wikipedia. Nohat 23:24, 12 July 2005 (UTC) [10]

In January 2006 a rogue editor, User:Sarenne, began the wholesale editing of articles to change KB to KiB, MB to MiB, and so on. That was his only contribution to the articles. Here is an example from May 2007[11]. When the article creators and regular editors complained at MOSMUN, they were told that consensus was the IEC prefixes. [12] There was a long and tedious debate about mandating the IEC binary prefixes. By July 2008 MOSNUM switched back from the IEC MiB to the traditional MB.[13] It appears that a few specialized devices are now specified with the IEC binary prefixes. This does not mean the Apple II article should be change to 4 KiB of RAM. If in 6 more years TiB is common, the vintage computer articles might still use the vintage units. Following the reliable sources would still be a valid guide. -- SWTPC6800 (talk) 21:45, 10 August 2014 (UTC)

A slightly one-sided "history" don't you think? For a start it takes no account of the simple fact that Sarenne was trying to improve articles by removing ambiguity. Eight years on and what do we find? The same ambiguity in the same articles, and now many more due to the passage of time. The present draconian guidelines effectively contradict themselves by requiring disambiguation but then putting up a barrier that makes it nearly impossible to do so. Second, it fails to mention the incivility and socks used by those opposed to disambiguation. It was that incivility that caused the problems, not Sarenne (after all, there are plenty of mechanisms in place to keep rogue editors in check), and in your heart of hearts you know it. Third, it fails to point out that Nohat's summary is itself one-sided in not mentioning that the megabyte had a decimal meaning long before Apple and Microsoft created the present confusion.
One final point: mosnum should not construct a barrier to disambiguation as it does now - it should facilitate it. It should start by encouraging simple steps that any editor can carry out (and yes, that would inevitably involve the mebibyte because like it or not the mebibyte has become the industry standard disambiguation tool for binary units), and then encourage further improvement by replacing any unfamiliar ones with footnotes, ad presently prescribed. Permitting this 2-step disambiguation would make it much more likely to happen, and WP would have far fewer articles that contravene the present requirement to disambiguate. Dondervogel 2 (talk) 05:28, 13 August 2014 (UTC)
It's not "one-sided" at all. Sarenne was blocked for repeated major disruption to hundreds of pages. There is no ambiguity to using the commonly used prefixes and if necessary using exact numbers or power notation to state the bytes used. The present guidelines are not draconian at all, they reflect real world use. They are like that because some people tried to push their point of view about uncommon and rarely used IEC prefixes. Therefore MOSNUM should rightly create a barrier to people trying to push a point of view about these hardly used IEC prefixes. The mebibyte is not the de facto industry standard tool for binary units, simply because it is not widely used in the industry. It doesn't matter what supposed "standards body" anybody can cite because that is a primary source and does not follow the policy about reliable sources. A "standard" that isn't followed by the industry isn't actually a standard, it's a failed standard and one that Wikipedia does not insert into general articles. What actually matters to Wikipedia is the majority real world use demonstrated by secondary sources. Permitting what you call the "2-step disambiguation" (i.e. using IEC prefixes with a footnote) pushes a point of view that is contrary to the accepted majority real world use. Wikipedia does not push a point of view. Fnagaton 13:54, 21 August 2014 (UTC)
Saying they are hardly-used is a bit unfair. For example, I recently noticed that git-clone seems to display data transfer information in terms of mebibytes. Archon 2488 (talk) 23:09, 21 August 2014 (UTC)
The occurrence of a term in version control software could be the definition of "hardly-used" by the general public. -- SWTPC6800 (talk) 14:38, 22 August 2014 (UTC)
The general public is unfamiliar with git? You really think so? EEng (talk) 15:36, 22 August 2014 (UTC)
So giving an example of use is evidence that it is unused. How can one argue with such logic? I am sure that nobody ever uses Git, and GitHub is an obscure idea that never caught on or influenced anything. Honestly, discussions on MOSNUM make me feel like I'm stuck in a timewarp and I'm not sure whether I'm in 2014 or 1954.
Does the exclusive use of base-ten constitute "pushing a point of view"? What about the merits of base-twelve or base-fourteen counting systems? Or do those arguments apply only when the masses of certain kinds of simians living on certain islands are under consideration? What about those rare cases where non-decimal counting systems are actually useful, and there is actually an objective reason for using them? Are we not supposed to use them only in those cases? Again, what kind of logic is that? Archon 2488 (talk) 22:46, 22 August 2014 (UTC)
Hardly used is not equal to unused. My version of git displays KB, not KiB. Fnagaton 13:47, 25 August 2014 (UTC)
The question then is, are those "actual" kilobytes, or is the term being abused to refer to multiples of 210 bytes (i.e. kibibytes?). Displaying kibibytes and dishonestly relabelling them as kilobytes (which happens, let us be honest) does not mean that binary units are "hardly-used". Archon 2488 (talk) 16:56, 28 August 2014 (UTC)

Units of measurement[edit]

My request is incredibly simple and basic. May we please have a table showing the style adopted by WP for basic units of measurement, e.g. centimeters, inches, pounds, ounces? Like the sort you see in diaries, on the back of calendars, etc. P123ct1 (talk) 19:34, 10 August 2014 (UTC)

Can you give an example of what you're looking for that's not here? EEng (talk) 20:18, 10 August 2014 (UTC)
I am also confused by this request. The current guidance is if anything somewhat too extensive, and several special exemptions have had to be negotiated at the MOS level (some might say this is less than ideal). In what way is the existing guidance deficient? Archon 2488 (talk) 14:28, 11 August 2014 (UTC)

Date format consistency between body and reference sections[edit]

I made this change, which is based on consensual current practice and is one of the desired aims of this guideline but seems to not to have been made explicit, for some unknown reason. However, my change has been reverted claiming that it needs to be discussed at Wikipedia talk:Citing sources. We do not rely on our sources to determine the date formats within our citations, and to do so would lead to an undesirable mish-mash of dmy, mdy and yyyy-mm-dd that would be contrary to our goal of format consistency. As my change is purely a format issue and does not seem to be one that impinges on using a mix of "standard" dmy or mdy with another such as yyyy-mm-dd or yyyy, mmm dd, I reversed his removal and open the discussion here. -- Ohc ¡digame! 04:07, 11 August 2014 (UTC)

I went through this when rationalizing the presentation (the presentation -- not the content) of MOSNUM 6-9 months ago. For reasons I've been unable to discern there's extreme protectiveness of the flexibility to use somewhat different date formats in the article proper versus in the cites. As I recall there's extensive discussion of this over the years, but I can't recall where, though if you search the archives here, at Wikipedia talk:Citing sources, and (I seem to recall for some reason) at Help_talk:Citation_Style_1 I think you'll pick up the scent.
In the meantime I think it would be best if you self-revert. I say this not because I have a position on this (I don't) but because of the extreme emotions I've seen on this in the past. EEng (talk) 04:53, 11 August 2014 (UTC)
AFAICR, that was in relation to the mixed use of dmy (or mdy) and yyyy-mm-dd dates in the references section, there was an understanding there needed to be internal consistency vis à vis the use of dmy vs mdy. -- Ohc ¡digame! 08:03, 11 August 2014 (UTC)
I agree with EEng that the best we've been able to agree so far seems to be: be consistent in the text; be consistent in the publication dates in the refs, not necessarily using the same style as the text; be consistent in the style used for access and archive dates, not necessarily using the same style as elsewhere, e.g. here yyyy-mm-dd can be used. So there can be three consistent styles in an article, and experience shows that some editors will strongly defend this situation. Peter coxhead (talk) 07:44, 11 August 2014 (UTC)
So you seem to be saying that we should allow ourselves to be consistently inconsistent when it comes to the two sections?? <scratches head furiously> It's bad enough to have some articles in dmy and others in mdy, but at least there is potentially consistency within an article, but sincerely fail to see how it can be in readers' interest to have dmy in the body and mdy in the references or vice versa. It just looks sloppy. -- Ohc ¡digame! 07:51, 11 August 2014 (UTC)
Article-consistency for optional styles is the mainstay of our system. Just why we would allow mdy in the main text and dmy in the references is beyond my small intelligence. Yet I too often see it. No one has ever complained at its harmonisation. Tony (talk) 07:59, 11 August 2014 (UTC)
Strongly agree Confucius and Tony. Consistency is more important than the egos of individual editors each wanting their own favrit spelling. Dondervogel 2 (talk) 09:04, 11 August 2014 (UTC)
I really don't care either way, but it's easy to turn that argument around. "...the egos of a small group of editors wanting to impose their favourite spellings on all editors of all articles, some of whom may prefer to use their favorite spellings." Who's imposing on whom? But again, I have no dog in this fight. I really should unwatch this page, but it's like a traffic accident -- I can't help looking. EEng (talk) 14:54, 11 August 2014 (UTC)
Agree that we should be consistent in articles and we should disallow a mix of DMY and MDY in an article text & references. It should be made clear in the MOS that such a mix is not to be tolerated. Keith D (talk) 11:26, 11 August 2014 (UTC)
Suggested criterion: if the article is in US English, use MDY, otherwise use DMY? If there is a strong reason to prefer the latter, which I doubt, then the article probably shouldn't be in US English in the first place. In any case, MDY isn't commonly used outside of the US. Archon 2488 (talk) 11:33, 11 August 2014 (UTC)
I agree DMY should not be seen outside articles written in US English. Other articles would then choose between DMY and YMD, as appropriate. Dondervogel 2 (talk) 11:50, 11 August 2014 (UTC)
I agree with the points above. @Ohconfucius: I agree that we shouldn't allow a mix of DMY and MDY in the text and in publication dates in references (although I favour allowing YYYY-MM-DD in access and archive dates). My point was that there are editors who object strongly, quoting WP:CITEVAR, which does seem to allow citations to exist in a world of their own. So CITEVAR would need to be adjusted to achieve consistency of the kind those of us commenting here seem to favour. Peter coxhead (talk) 14:31, 11 August 2014 (UTC)
If there are editors who object to this kind of consistency, they must be very few, or very shy. Maybe we don't need to invent such stumbling blocks. Let's move forward. Dicklyon (talk) 14:38, 11 August 2014 (UTC)
All I know is that I've made such consistency adjustments in the past and been sharply "told off" quoting CITEVAR. I tend to move on in such cases, so I can't off-hand recall where this happened. Peter coxhead (talk) 14:41, 11 August 2014 (UTC)
so what am i doing wrong? i've harmonised dates in over 100k articles and nobody has complained using the argument you quoted. -- Ohc ¡digame! 22:21, 11 August 2014 (UTC)
@Ohconfucius: luck – you didn't encounter those with views like Jc3s5h below. :-) Peter coxhead (talk) 08:18, 12 August 2014 (UTC)
@Peter coxhead: Tempting fate, I have had flaming arguments here at WT:MOSNUM with JC3, but have never come across editors holding those views in article space. ;-) Or maybe it's simply because "other formats" represent a minuscule proportion of all WP articles. -- Ohc ¡digame! 08:29, 12 August 2014 (UTC)
To add in my agreement, one should be be used DMY in the prose and MDY in references, or MDY in prose and DMY in references. Or, more specifically, if one is using DMY or MDY in references, that choice needs to be consistent with the date format in the prose. --MASEM (t) 14:50, 11 August 2014 (UTC)

I have advertised this discussion at WT:MOS and WT:CITE. Since the current state of affairs has been arrived at through numerous requests for comments, I consider it unacceptable to change the state of affairs without a well-advertised and well-attended request for comment.

Given that the Wikipedia community steadfastly refuses to adopt a house citation style, I will offer two substantial reasons for allowing the date format in the citation to be different from the date format in the body of the article:

  1. The editors may be using citation management software that automatically produces one of the external format styles. Having to manually change the date format after the software has created the citation would defeat the purpose of using software. An example of a format that could be cut-and-pasted into Wikipedia is the CSE style. Here is an example of that style: "5. Stevens MH. Heavenly harbingers. Smithsonian. 2001 Nov:20, 22."
  2. If the style does not provide automatic links among the inline citation markers, the short footnote (if any), and the list of works cited, it is helpful to have works by the same author listed in chronological order. Putting the year first in the publication date makes it easier for readers to manually locate the correct work in the list.

Jc3s5h (talk) 15:20, 11 August 2014 (UTC)

"It's bad enough to have some articles in dmy and others in mdy", why? "Suggested criterion: if the article is in US English, use MDY, otherwise use DMY?" I am sill amazed that people don't realise that in Britain both styles are used.

I am developing an article at the moment and throughout the text I an using DMY (it is in British English), but this leaves me with a quandary, because it is a very detailed military campaign article that covers a few days. If I place the dates as section headers I get "10 June" "11 "June" etc, with sub headings for the actions of the day and the bivouac locations at night. The problem with this is that the TOC looks odd because I get:

4 10 June
 4.1 lots sub headings
5 11 June
 5.1 lots of different sub headings
6 12 June
 6.1 more sub headings

Stylistically it looks better in the TOC to use

4 June 10
 4.1 lots of sub headings
5 June 11
 5.1 lots of different sub headings
6 June 12
 6.1 more sub headings

This fits in with the advise in MOS:SECTIONS "Avoid starting headings with numbers ... ", and is stylistically justified, yet I know that if I use one format in the text and another in the headers it will not be long before a muppet comes along insisting that the days and months MUST be consistent. There are times when it is convenient to use different formats within an article and there are times when for stylistic reasons someone may wish to use more than one format.

-- PBS (talk) 16:53, 11 August 2014 (UTC)

The first format looks clearer to me, because it seems less likely to be mistaken for
4 June 2010
 4.1 lots of sub headings
5 June 2011
 5.1 lots of different sub headings
6 June 2012
 6.1 more sub headings
Dondervogel 2 (talk) 17:40, 11 August 2014 (UTC)
Also, one can "split" the numbers a few different ways without impacting much else, such as "Day 1: 10 June" or "Tuesday, 10 June". --MASEM (t) 17:46, 11 August 2014 (UTC)
You have to consider it in context, the military campaign was fought over days not years, and the lead explains the context before the TOC is read. Why would you assume "2010" and not 1010, 1610, 1810 or 1910? The day as in Tuesday ought not to be included as it is not a significant, as to "Day 1" it is meaningless as no reliable sources counts the days like that (and few mention the days of the week), but they all mention the day of the month, the month and the year. -- PBS (talk) 18:17, 11 August 2014 (UTC)
I think the issue is not whether the table of contents can be deciphered, but whether it is instantly understandable. There are an infinite number of ways to indicate that a car should stop, but the Manual on Uniform Traffic Control Devices strictly regulates what a US stop sign must look like so that drivers will recognize it instantly. Since a table of contents is a navigation aid, just as a traffic sign is, I think Dondervogel 2 is justified in tinkering with the format to make the meaning instantly recognizable.
However, this is off-topic for this thread; consistency of the table of contents with the body of the article should be raised at WP:MOS. Jc3s5h (talk) 18:40, 11 August 2014 (UTC)
yes, this conversation has splintered and ought to be forked, but to reply to your point: MOSNUM isn't here to cut down on traffic accidents and there's no huge need to "instantly" recognise dates. "instant recognition" can be had if ALL dates were in the same format, and we wouldn't want that, wound we? ;-)-- Ohc ¡digame! 22:21, 11 August 2014 (UTC)
No, we woundn't. EEng (talk) 22:46, 11 August 2014 (UTC)
I do not think it is off topic because it is an example of why one shoe size fits all is not necessarily the best way to go. -- PBS (talk) 07:26, 12 August 2014 (UTC)

Does anyone know of a publication or publisher which expects works to contain proper citations, has a manual of style about how to write the body of the work, but does does not specify citation format? Wikipedia is the only publication I know of that fits this description. If someone does know of such a publication or publisher, how do they prevent conflicts between their manual of style and whatever publication style the author picks? Jc3s5h (talk) 23:29, 11 August 2014 (UTC)

Wikipedia is the only publication I know of that fits a lot of descriptions. I wouldn't worry about it too much. It's just argle-bargle to worry about whether the date formats in the references match the text. One more rule and one more thing to worry about. For references I use whichever style I like and so should you. If someone doesn't like it they should leave it alone anyway. But if they want to change it anyway let them. It's not worth worrying about. Herostratus (talk) 00:24, 12 August 2014 (UTC)
  • Wikipedia isn't a professional publication and doesn't even try to be even though some articles may be close to professional quality. Overall, we try our best and would be best classified as a "lay publication" targeted at the layman. I see no real point allowing editors from different fields to ape the different formats used in various external style guides applicable to their professional publication. Anything other than a unified style would just confuse our readership. -- Ohc ¡digame! 01:58, 12 August 2014 (UTC)
Sure, but there are a number of factors that have prevented Wikipedia from adopting a unified style for citations. I don't know why no printed style guide could be agreed upon before the advent of citation templates, that was before I heard of Wikipedia. By the time I started editing, it was a contest between templates and no templates. Templates really didn't lend themselves to being adopted as a house style, because they were more a toolkit than a style. Different editors would make uncoordinated changes to various templates, and if you put too many on a page, they stopped working. Also, there were no templates for some kinds of sources.
In such a contentious atmosphere, it's no wonder that no one was willing to write a complete citation manual that could coordinate the development of citation templates, or explain how to cite sources that weren't supported by templates. Such a work would be at least 50 pages, judging by the size of the corresponding chapter(s) of printed style guides. The would-be author would probably figure no one would accept it, no matter how good it was, so why start. Jc3s5h (talk) 02:27, 12 August 2014 (UTC)
The text in MOSNUM already spells out in great detail which date formats should be used where (mdy vs dmy). Let's not invent a new set of rules for citations based on engvar (which is not necessarily consistent with date format). We just need to say: "Avoid using dmy in reference lists where mdy is used in the main text, and vice versa." Tony (talk) 03:00, 12 August 2014 (UTC)
The style for the American Medical Association says dates are in the MDY form. Automated tools that generate citations in that format generate MDY dates. So Tony1 proposes forbidding the American Medical Association style in dates that use DMY in the body of the article, but making such a prohibition violates WP:CITE. There is no point in putting the rule in; since it contradicts another guideline, it is unenforceable. Jc3s5h (talk) 03:14, 12 August 2014 (UTC)
The AMA style is not god. Like the much-reviled APA style. If the dates are dmy in the article, why should some US system be used in citations? Think about our readers, please. The AMA is not servicing an international online wiki encyclopedia that is edited and read by speakers of all varieties of the language. Tony (talk) 06:17, 12 August 2014 (UTC)
A person who wants advice about the best citation format to use for an article is going to read WP:CITE, not WP:MOSNUM. It is wrong to put a rule in WP:MOSNUM that forbids certain citation style formats, because that is not the topic of this guideline. Jc3s5h (talk) 15:34, 12 August 2014 (UTC)
"We just need to say: Avoid using dmy in reference lists where mdy is used in the main text, and vice versa." Why? Herostratus (talk) 03:47, 12 August 2014 (UTC)
Popcorn, anyone? EEng (talk) 05:37, 12 August 2014 (UTC)

@Dondervogel 2 "It's bad enough to have some articles in dmy and others in mdy", why? --PBS (talk) 07:26, 12 August 2014 (UTC)

I think what I said was that MDY should be avoided in references unless used in the main article. My view is that MOSNUM (and MOS generally) should strive for a consistent style, first within articles (essential) and then across articles (desirable). Dondervogel 2 (talk) 07:46, 12 August 2014 (UTC)
  • Although I think that it would be better to say that the text and references should not mix DMY and MDY, I do agree with Jc3s5h that this would need to be agreed at WP:CITE as well as here. A full RfC, anyone? Peter coxhead (talk) 16:27, 12 August 2014 (UTC)
  • The actual purpose of the "two styles" rule was always, as far as I could tell, to allow YYYY-MM-DD in the refs, "a foolish consistency" etc. I am happy for all dates in an article to follow DMY or MDY. I trust that there will be no actions that casue conflict taken if we adopt this approach, and certainly none that prolong it if it occurs. All the best: Rich Farmbrough00:27, 13 August 2014 (UTC).
    • Just to expand a little, phrases like "not to be tolerated" are not consistent with the wiki-way, and the guideline status of MoS. All the best: Rich Farmbrough00:28, 13 August 2014 (UTC).

I strongly agree with Ohconfucius, Tony1, Dondervogel2, Keith D and Masem. It seems like a no-brainer to me: If the article uses DMY, use DMY in the references. To do otherwise just looks very sloppy. If "citation management software" produces the wrong results, don't use citation management software. I strongly disagree with Herostratus's assertion that this issue doesn't matter. -- Alarics (talk) 10:58, 13 August 2014 (UTC)

There's an important difference between "if the article text uses DMY, don't use MDY in the references" and "..., use DMY in the references". I agree with the first, but not the second. Peter coxhead (talk) 13:10, 13 August 2014 (UTC)
Why not turn it on is head "if the references use DMY then don't use MDY in the text"? It seems to me if all someone wants is consistency it does not matter which way round it is. -- PBS (talk) 15:34, 19 August 2014 (UTC)
We could, but it would require revision of WP:STRONGNAT; I doubt consensus could be formed to change that. Jc3s5h (talk) 15:50, 19 August 2014 (UTC)

The IBM style guide[edit]

There are hundreds (probably thousands) of articles in which the unit symbol MB is used ambiguously to mean one of megabyte and mebibyte. There are also many articles in which the same symbol is used in the same article to mean both of those. I don’t know how many but it is not hard to find them (a simple search for “MB GB” returned TomTom top of the list, and I am sure there are many more). What is the purpose of inflicting this kind of ambiguity on the reader? IEC binary prefixes are part of the International System of Quantities, are used in hundreds of scientific publications every year, and have been adopted by industry as the preferred disambiguation method when both binary and decimal meanings are presented in the same article or context (see, e.g., the IBM style guide). I propose that MOSNUM follows IBM’s lead, drags itself kicking and screaming into the 21st century, and ends its pointless deprecation of IEC binary prefixes. Dondervogel 2 (talk) 13:29, 13 August 2014 (UTC)

An extract from the IBM style guide reads [DeRespinis, F., Hayward, P., Jenkins, J., Laird, A., McDonald, L., & Radzinski, E. (2011). The IBM style guide: conventions for writers and editors. IBM Press.]

To help avoid inaccuracy (especially with the larger prefixes) and potential ambiguity, the International Electrotechnical Commission (IEC) in 2000 adopted a set of prefixes specifically for binary multipliers (See IEC 60027-2). Their use is now supported by the United States National Institute of Standards and Technology (NIST) and incorporated into ISO 80000. They are also required by EU law and in certain contexts in the US. However, most documentation and products in the industry continue to use SI prefixes when referring to binary multipliers. In product documentation, follow the same standard that is used in the product itself (for example, in the interface or firmware). Whether you choose to use IEC prefixes for powers of 2 and SI prefixes for powers of 10, or use SI prefixes for a dual purpose ... be consistent in your usage and explain to the user your adopted system.

Dondervogel 2 (talk) 13:36, 13 August 2014 (UTC)
Or we could add MB with some parameters to {{convert}} and have it display any and all results in base 10. I think that would meet the spirit of the IBM guide and use one of our standard tools. Any interesting default could be to always output base 10 and those funny camel case things that no one uses. Vegaswikian (talk) 17:47, 13 August 2014 (UTC)
Adding a MB <-> MiB conversion to the convert template is a (very) good idea, but I'm not sure this would solve the ambiguity/contradiction in the TomTom article. How do you see it working there? Dondervogel 2 (talk) 07:54, 14 August 2014 (UTC)
Not much reaction yet - I guess everyone's on holiday - so let me make a more specific proposal, like this
  1. DEPRECATED: My computer is equipped with 16 GB of RAM. It has a 500 GB hard drive.
  2. PERMITTED: My computer is equipped with 16 GiB of RAM. It has a 500 GB hard drive.
  3. PREFERRED: My computer is equipped with 16 GB of RAM.[1] It has a 500 GB hard drive.[2]
In this way, articles can be improved in a stepwise basis. They can be disambiguated easily by going from 1 to 2, at the cost of the unfamiliar GiB (which must be linked). Going from 2 to 3 removes the unfamiliar GiB at the cost of the additional effort required for the footnotes. Dondervogel 2 (talk) 12:35, 14 August 2014 (UTC)
  1. ^ When measuring RAM, 1 GB = 10243 B
  2. ^ When measuring hard drive storage, 1 GB = 10003 B

The excerpt from the IBM style guide doesn't say to use the IEC prefixes, it says "In product documentation, follow the same standard that is used in the product itself (for example, in the interface or firmware)." That's not quite as restrictive as MOSNUM, but it certainly isn't a directive to change to IEC prefixes with all deliberate speed. Personally, I think the reason people don't care about this is that in the systems people use every day, they have more disk capacity and RAM than they know what do with, and just don't care about a 13% difference; when they think of increasing their disk or RAM capacity, they think of doubling it. (By the way, I used to use the IBM Style Guide when it consisted of a list of exceptions to the Chicago Manual of Style, with little stickers to stick in the affected sections of Chicago so you would know to look up the exception whenever that section applied to what you were writing.) Jc3s5h (talk) 14:28, 14 August 2014 (UTC)

I guess my concern is that option will run afoul of the MoS by creating too many blue links. I'd rather see:
  1. PREFERRED: My computer is equipped with 16 GB (17,179,869,184 bytes) of RAM. It has a 500 GB (500,000,000,000 bytes) hard drive.
I think we have to spell out the conversion clearly. Of course if convert supports this, then there is no user calculation needed. The template would display the conversion requested. If the numbers are too large we could output the conversion using the E9 scaling in the template. One could argue that GB, as a common term, should not be linked. Whereas GiB does since it is not common. But as pointed out above GB is ambiguous but if the conversion is provided, it is not ambiguous. Vegaswikian (talk) 19:06, 14 August 2014 (UTC)
I believe the degree of precision suggests is absurd in nearly every Wikipedia article. Jc3s5h (talk) 19:24, 14 August 2014 (UTC)
If you convert to E9, I think that issue is addressed. Using footnotes or section links for the same term does not really help the readers. Vegaswikian (talk) 20:14, 14 August 2014 (UTC)
@Vegaswikian: The need for the blue links will stay as long as there is ambiguity in the meaning of GB. The links are needed even doing it your way, with explicit conversions, because the reader will otherwise not understand why two different conversions are used. I also think that writing 16 GB (17.2 E9 bytes) is more confusing than 16 GiB, which is more precise as well as more concise. Dondervogel 2 (talk) 21:52, 18 August 2014 (UTC)

Modified proposal ...[edit]

... addressing the comments of Vegaswikian and Jc3s5h

  1. DEPRECATED: My computer is equipped with 16 GB of RAM. It has a 500 GB hard drive.
  2. PERMITTED: My computer is equipped with 16 GiB of RAM. It has a 500 GB hard drive.
  3. PERMITTED: My computer is equipped with 16 GB (17.2x109 bytes) of RAM. It has a 500 GB (500x109 bytes) hard drive.
  4. PREFERRED: My computer is equipped with 16 GB of RAM.[1] It has a 500 GB hard drive.[2]

The idea is that 2 and 3 are both permitted as stepping stone on the way to 4.

  1. ^ When measuring RAM, 1 GB = 10243 B
  2. ^ When measuring hard drive storage, 1 GB = 10003 B

Dondervogel 2 (talk) 06:45, 28 August 2014 (UTC)

I don't think #2 should be permitted unless used by the source, per existing guidelines. (Perhaps a source, rather than the product specification.) If changed to DEPRECATED or PERMITTED[note 1], I could agree.— Arthur Rubin (talk) 13:47, 28 August 2014 (UTC)
As I said, the conversion should not be in the reference. So I can not support 4 being the only preferred option. If we made it 3 and 4, while I would not be really supportive, I guess I also could not oppose that. Remember that we don't convert feet to meters in a footnote, so why should we in this case, so why do we need 4 at all? Readers are very familiar with conversions in running text as generated by convert. Also the final guideline should address mobile data. I know some plans use 1024 for the calculation. But do all? Vegaswikian (talk) 17:15, 28 August 2014 (UTC)
  1. ^ Only if used in the source

Sept vs Sep for September[edit]

Someone called BattyBot ran awb[14] to change the abbreviation for September from Sept (the US standard) to Sep (I have never seen that before!) in a reference.

There was a discussion here in January 2014 and an RFC (which supported this nonsense). Also note that most spell checkers, including the one in the Chrome browser, consider "sep" to be an error. The Chicago Manual of Style clearly says that the abbreviation should be "Sept".

Before I change it back, I thought I would post here. Robert - Northern VA (talk) 23:19, 14 August 2014 (UTC)

  • If the months are standardized to 3 letter ones (including "Jun", "Jul", etc. ) then "Sep" is right. But if one is using the partial abbreviations, ("June", "July") , then "Sept" should be used. --MASEM (t) 23:23, 14 August 2014 (UTC)
  • Why abbreviate? This is not paper. Spell it out so readers with English as a second, third or fourth language know what this is. Vegaswikian (talk) 23:25, 14 August 2014 (UTC)
My answer is the citation style in WinFixer is execrable and the right answer is ignore the trivia of the date abbreviation and do a major cleanup on the citations. As far as browser spell checkers, they consider "accessdate", most proper names, and URLs to be misspelled, so they are of limited value when editing Wikipedia. (If we had smarter bots, we would have them skip articles like this because they need much more help than a bot can give.) Jc3s5h (talk) 23:39, 14 August 2014 (UTC)
The result of the RFC linked above was that "Sep" or "September" are both valid, depending on circumstances. "Sept" and "Sept." are proscribed. See MOS:MONTH. Quoting from the RFC closure: "when it is necessary to shorten a month, the month should be shortened to the first three characters with no full stop and this should be reflected in the two relevant MOS's". After the RFC was closed, the MOS was updated to reflect the consensus of the RFC.
Please read the RFC and discussion. It resolved inconsistency in the MOS and provided clear, concise guidance to editors. As for your spell-checker, if you are unable to prevent yourself from "correcting" "Sep" by ignoring the little red squiggly line, you can right-click on "Sep" and add it to your dictionary.
P.S. Jc3s5h, I cleaned up the references in a variety of ways. It's 20% less execrable now. – Jonesey95 (talk) 23:42, 14 August 2014 (UTC)
I will add that, as an American, "Sep" doesn't look right to me either. If we allowed abbreviated dates in the running text of articles, as the Associated Press Stylebook does, I would argue for "Sept" in articles that use American English. But since we only allow abbreviated dates in limited situations, I think it's OK to go with the format that saves the most space. Jc3s5h (talk) 00:00, 15 August 2014 (UTC)
I am more used to seeing "Sep" than "Sept" myself. This comment about ISO 8601 (from an MIT website) seems relevant

"Are there any variations within, or applied to, ISO 8601 ?

The standard lays down a 'full' format for calendar date/time (e.g. the last day of last year is 1996-12-31), and then also defines 'truncated' forms (as in '96-12-31' says year 96 in any century, December 31st) and 'reduced precision' (for example '1996-12' specifies only down to month level) formats. The 'full' format is the most relevant here.

Astronomers have been using the ISO 8601 format to record observations and transfer data for many years, in fact since before computers were invented. Astronomers have made one small (unofficial) change to the way that ISO 8601 works. They often write the month as a 3-letter abbreviation. So instead of writing '1996-12-31' for the last day of last year, astronomers would write '1996-Dec-31'. This makes the date clearer to those who have not come across the Year-Month-Day way of writing dates before, but does have the disadvantage that it may render the date unknown to a non-English-speaking person. So it is appropriate to perhaps have a menu option on computer software that allows a choice of the 'Month in Numbers' or 'Month in Words' on output screens and printouts; so that software may store dates internally as numbers, but will convert the month to words on computer printouts intended for human reading e.g. store as '19991231' but print as '1999-Dec-31'."

Dondervogel 2 (talk) 04:16, 15 August 2014 (UTC)
Dondervogel 2, I don't see how ISO 8601 applies. It requires a 4-digit year followed by a 2-digit month. Neither of the references you supplied talks of month abbreviations. In addition, the examples you give - '1996-Dec-31' - is not in the same format as Sept 4, 1999. Your argument is apples and oranges. Robert - Northern VA (talk) 05:40, 15 August 2014 (UTC)
I did not explain myself well. My point was that 3-letter abbreviations are common (in my experience more common than 4-letter ones, though I accept the likelihood of regional variations). Perhaps a better example is Microsoft Excel, which also uses 3-letter abbreviations, and might on its own explain why "Sep" seems familiar to me while "Sept" or "Sept." do not. Dondervogel 2 (talk) 05:57, 15 August 2014 (UTC)
Interesting argument - spreadsheet software now dictates English grammar. We are discussing dates used in human readable text and not the quirks of computer software. According to The Associated Press Stylebook 2012
Always capitalize months. Spell out the month unless it is used with a date. When used with a date, abbreviate only the following months: Jan., Feb., Aug., Sept., Oct., Nov. and Dec.
I am not aware of any style guide or grammar book used in the US that supports the 3-letter abbreviation for September in text except when used in columnar tables (like a spreadsheet?). By pushing this change, you are effectively rewriting every English grammar book. Robert - Northern VA (talk) 08:56, 15 August 2014 (UTC)
I am pushing nothing - just stating facts. But if you want an opinion I am happy to offer one. If the context of this discussion is limited to text that one would read, I agree 100% with User:Vegaswikian: why abbreviate? Dondervogel 2 (talk) 09:02, 15 August 2014 (UTC)
@Dondervogel 2:, I started to read your comment above until I came to "This comment about ISO 8601". Our ISO 8601 article, in my opinion, is seriously broken, but there are not enough editors to move forward with any solution. So until some editors go over there and take a look, I will stop reading comments by editors who invoke that article in guideline discussions. This is my small way of trying to put work on articles ahead of work on guidelines. (I will read the MIT link to see if it might help with the "ISO 8601" problems.) Jc3s5h (talk) 10:00, 15 August 2014 (UTC)


Hi, portions of the writeup at MOS:LARGENUM are breaking my brain. Is there any way to clarify this?

Where explicit uncertainty information is available and appropriate for inclusion, it can be written various ways...

I've never heard of "explicit uncertainty information" and it's coming off as a grammatical mistake, although I do see 11,000 Google hits for the phrase being used in statistical and other math worlds (such as here), so I assume the problem is me. That said, those words in that order are bizarre to the layperson. And then a following clause reads:

Where explicit uncertainty is unavailable (or is unimportant for the article's purposes) round to an appropriate number of significant digits...

That's messing up my head as well, because we have a double-negative, followed by a negative alternative, so it's difficult to figure out what we're not looking for, or what our option isn't. I really don't know what is trying to be said here. "If you know the exact number, but such precision is unimportant for the article, round the number to an appropriate number of significant digits"? If so, can't we just say that?

Thoughts? I'm sure the math nerds will laugh me out of here, but I come in peace! I think we need to make this area a little clearer for we commonfolk. The boldface might be hindering as well. Thanks, Cyphoidbomb (talk) 02:13, 23 August 2014 (UTC)

Perhaps it would be better to say "explicit information about the uncertainty". Does that make more sense to you? Dbfirs 07:40, 24 August 2014 (UTC)
Hi Dbfirs, sadly, no. Face-smile.svg Based on the context it sounds as though "explicit uncertainty information" implies "a specific known value" (only in abstruse math language). Assuming that I've inferred that correctly, wouldn't it be more universally understood to say, "Where a specific known value is available and appropriate for inclusion, it may be written in various ways:" The "explicit uncertainty information" could be included in parens, if that is a known mathematical concept. Likewise, the second bullet could be changed to: "Where a specific known value is available, but is is unimportant for the article's purposes, round to an appropriate number of significant digits." That seems plainer, but then again, I don't know what the concept means. Confused.png Cyphoidbomb (talk) 18:18, 24 August 2014 (UTC)
No, I think you've misunderstood it.
"Uncertainty" here means the margin for error, or, the uncertainty of the measurement. For example, if I measure the height of Mount Everest, my methods might be accurate to the nearest five metres or to the nearest metre or to the nearest 20 centimetres. "Explicit uncertainty information" means, if the source explicitly tells you what the potential error on a measurement is.
"Where explicit uncertainty is unavailable (or is unimportant for the article's purposes)" means, where the source doesn't report the margin for error (or uncertainty) of the measurement (or where it doesn't matter - you get that bit I think). Kahastok talk 19:59, 24 August 2014 (UTC)
That does help a lot, actually. Thank you. I knew the problem was my own ignorance! Can we include the words "margin of error", perhaps in parens? I think that's a little more universally understood. Addendum: Thanks for including the margin of error note, EEng, as painful as it might have been. Face-smile.svg Cyphoidbomb (talk) 22:04, 24 August 2014 (UTC)
Your wish is my command. EEng (talk) 23:47, 24 August 2014 (UTC)

Additional notion added; please scruitinize[edit]

Here [15] I added a somewhat new notion that I think is reasonable but which is, well, new, so please comment mercilessly:

  • It may sometimes be appropriate to note the lack of uncertainty information, especially where such information is normally available and necessary for appropriate interpretation of the figures supplied
  • A local newspaper poll predicted passage of the bond with 52% approval from the voters, but did not publish information on the uncertainty of this estimate.

EEng (talk) 23:47, 24 August 2014 (UTC) <bump>05:01, 28 August 2014 (UTC)

WP:DATERANGE problem... new style of using the last two digits of 4-digit year in ranges is a disaster[edit]

Why was this changed? Can we please change it back, it looks completely unprofessional, is unnecessary and confusing, and is almost unreadable at times to have a date range of "2001–10" instead of just "2001–2010". Is it really worth saving two characters, especially given all the exceptions where it can't be used (seen at WP:DATERANGE, such as 1999–00)? It makes things unnecessarily ambiguous (anyone could mistake "2001–10" for October 2001 instead of a date range), and there are so many exceptions that it makes it seem as if there is no guideline whatsoever, since basically half of the date range cases must use the full digits (i.e. 400–401, birth—death ranges, etc.) , and the other half don't.

Marriage ranges have become particularly confusing (i.e. m. 2001–12), because to the normal observer unfamiliar with Wikipedia conventions this could easily be mistaken as meaning the person was married in December 2001, and is still married, rather than that they were married between 2001 and 2012. Two numbers would eliminate that entire ambiguity. Can we have a poll for this? Can we just change it back? What procedure should be followed here? I'm just a regular everyday editor, but this small style guideline drives me to my wit's end. — Crumpled Fire (talk) 19:56, 23 August 2014 (UTC)

Of course, the hyphen/endash enthusiasts will point out that 2001—12 and 2001-12 are different... Seriously, contracting the end of a year range is unnecessary and best avoided. Peter coxhead (talk) 20:12, 23 August 2014 (UTC)
2001-12 seems perfectly clear and unambiguous to me. It obviously means December 2001, and should never be used to imply a date range. Dondervogel 2 (talk) 20:18, 23 August 2014 (UTC)
Thank you both for your support, I entirely agree that in normal conventions (outside Wikipedia), "2001–12" would almost always imply December 2001, never 2001–2012, and using it to imply the latter is something that never should have been implemented here, and should now be reversed. — Crumpled Fire (talk) 20:27, 23 August 2014 (UTC)
I just don't believe the assertions by Dondervogel 2 and Crumpled Fire that 2001–12 will, outside Wikipedia, be understood to mean December 2001. In running text I believe 2001–12 will usually be interpreted as 2001 to 2012. Only in contexts where it would be convenient to sort years and months in chronological order, such as some file names, would I expect people to interpret it as December 2001. Jc3s5h (talk) 21:32, 23 August 2014 (UTC)
How it is interpreted would depend on context. But that is almost the definition of ambiguity. A date range should always be given with the years written in full, which is unambiguous. Archon 2488 (talk) 22:31, 23 August 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The above disagreement over the obvious interpretation shows a difference in background of the readers. Most readers from the UK and the US and countries directly related to them (eg my home of Australia) will find only a single interpretation of 2001-12, ie 2001 to 2012. However, readers from many European and Asian countries are used to seeing dates in the form 2001-12-31, so 2001-12 naturally means December 2001 to them. English Wikipedia needs to assume our readers have at least a certain proficiency in reading English, but we shouldn't go to the other extreme and make it hard for our international readers. It's similar to why we avoid slang, jargon and local idioms. For the sake of 2 extra characters, 2001–2012 is easily understood by all.  Stepho  talk  23:24, 23 August 2014 (UTC)

Yep. Why do we insist on taking something that is clear, readable and probably makes sense to all readers and change it? I don't think I participated in the discussion that made the change, but seeing the results, maybe I will if it comes up again. Vegaswikian (talk) 23:45, 23 August 2014 (UTC)
I find 2001-12 slightly ambiguous and 2001-2012 to be clear. I see no advantage to the shorter form except perhaps rarely in tables or infoboxes. I'd support a change to the MOS to specify use of full years. SchreiberBike talk 23:50, 23 August 2014 (UTC)
The OP refers to the "new" style, but MOSNUM has endorsed year ranges such as 2005–09 for ten years ([16]) and forbidding it now seems to me a nonstarter. For one thing, there are certainly places (e.g. horizontally dense tables) where not only does dropping these two digits make sense, it would look utterly stupid not to do so at the cost of making everything else that much more horizontally squeezed.

Unlike with DD-MM-YYYY/MM-DD-YYYY (where the probability of confusion really is high) it seems to me there are few situations where the reasonably alert reader will be misled. In fact, "married" is the only phrase I can think of just now that is ambiguously either a point in time ("married 2005-12" = took vows in December 2005) or a period of time ("married 2005-12" = was in a state of being married for 7 years). No doubt there are other examples I'm not thinking of, but I'd like to hear a few plausible ones, as they might arise in actual articles, before we keep worrying about this. EEng (talk) 00:00, 24 August 2014 (UTC) Please no lectures about hyphens versus endashes in my examples -- we know all about that and it's not the point here. :P

Most usage will be unambiguous. But I certainly have no problem with people who want to use the full years, especially outside tables. All the best: Rich Farmbrough19:02, 24 August 2014 (UTC).

Another reason to capitalize the season[edit]

WP:SEASON says "Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter."

I propose adding guidance that seasons should also be capitalized in citations when used in a |date= or |issue= parameter, like this:

  • P. E. Dant (Summer 2002). "Seasons, months, and days: what to do?". Journal of Capitalization 4 (2). 

Such capitalization is normal practice, but an editor has cited WP:SEASON to object to citation error messages. Thoughts? – Jonesey95 (talk) 13:55, 26 August 2014 (UTC)

@Jonesey95: No one "cited WP:SEASON to object to citation error messages". Could you please reread the post? Thanks! GoingBatty (talk) 14:00, 26 August 2014 (UTC)
Point taken. The editor cited the dictionary, and the editor said "season names are not capitalized", which I took as a paraphrase of WP:SEASON. My proposal/question still stands. – Jonesey95 (talk) 14:07, 26 August 2014 (UTC)
After further investigation, I see that the APA Style Blog and the Chicago Manual of Style (16th ed., paragraph 14.181) recommend capitalizing seasons in source citations. But this is the wrong forum for this discussion. If we want to limit the advice to CS1 templates and the Citation template, the discussion should be at Help talk:Citation Style 1 and Template talk:Citation. If we want to point out that two internal Wikipedia styles, APA, and Chicago all recommend capitalizing seasons in citations, that should be done at WP:CITE. Jc3s5h (talk) 14:29, 26 August 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Really, no change is needed here at MOSNUM. That words not normally capitalized do get capitalized at the beginning of a sentence and so on, is obvious and doesn't even need to be said. You'd capitalize Moon in The Research Journal (Moon-landing issue) even though moon isn't normally capitalized, because you'd capitalize any word here. If the cite tempates' error checks or whatever aren't consistent with this, they should be. EEng (talk) 04:59, 28 August 2014 (UTC)

Use of frac template[edit]

Recently some of my edits on chess-related articles such as this [17] have been reverted, because the editors in question believed that the use of characters such as ½, while deprecated by the MOS, was stylistically better. What should the MOS position be here? Archon 2488 (talk) 22:59, 27 August 2014 (UTC)

Isn't there an issue with screen reader software for the visually impaired? The special characters aren't always supported. -- SWTPC6800 (talk) 00:18, 28 August 2014 (UTC)
Here's the various alternatives:
  1. 4½/6, as deprecate by MOS. Supposedly favoured by WP:WikiProject Chess but I can't find a mention there.
  2. 412/6, as favoured by MOS and Archon.
  3. 412/6
  4. 41/2/6
  5. 41/2 out of 6
  6. 41/2/6
  7. 4.5 out of 6
  8. 4.5/6
  9. 412 / 6
  10. 41/2 / 6
  11. \frac{4 \frac {1} {2} } {6}
  12. {4 \frac {1} {2} } / {6}
They all pretty awful but #6 looks the best to me. I don't follow chess scoring, so I can't say what format professional tournaments use or even if they use a consistent format between them. Note: a half point means a draw. If we can agree on a suitable format, I'm sure I can make a template to make it easy to use.  Stepho  talk  04:07, 28 August 2014 (UTC)
This was discussed at the chess project a few years ago. We decided against ".5" (#7 & #8) because the score can't be anything except a whole number or a whole number plus a half. I think #11 is terrible, and I'm against any of #7-12. The slash is commonly used in chess literature, but "out of" would be better to the casual reader. (There are some chess editors who abbreviate everything to the hilt.) So I think I'd prefer #5 or #1 with "out of" instead of the slash. Bubba73 You talkin' to me? 04:38, 28 August 2014 (UTC)
Or #3. Bubba73 You talkin' to me? 02:17, 29 August 2014 (UTC)
I personally prefer #s 5-7, but #7 is out due to prior consensus, so I'd support #5 for readability or alternatively #6. (I'm not a member of WikiProject Chess, but I play the game and variations of it.) —PC-XT+ 04:58, 28 August 2014 (UTC)
For the record, the previous discussions were about decimal (4.5) vs fractions (4½) are here:
They didn't discuss how the fraction was actually built up (ie which slash, font size, etc).  Stepho  talk  09:23, 28 August 2014 (UTC)


In tournament crosstables either "½" or "=" may be used to indicate a draw. If "½" is deprecated we should probably replace them all with "=" in any crosstables, e.g. Carlsbad 1929 chess tournament. While the total score in the right hand column was traditionally recorded as (for example) 12 or 12½, 12.0 and 12.5 have become more common since the internet, and are used by Chessbase among others. Maybe our project should agree on a standard format for tournament crosstables too? MaxBrowne (talk) 11:43, 28 August 2014 (UTC)

Modern published chess literature, say from 1980 onwards uses #1 above. Previously, up to around 1950, with a period of crossover in the intervening time, something akin to #4 - #6 was most regularly used. I'm really not sure why we would want to be considering going in the reverse direction. I can understand that the half symbol will be difficult for partially sighted people in many arenas, but less so in chess as other fractions are never used, so a vague recognition will suffice. Besides, the decimal point (0.5) version has got to be way more difficult for partially sighted people to pick up on.
The main problem with fractions that stick up or down from the rest of the text is that they look awkwardly out of place in a passage of prose, and become objects that the eye is drawn to. I imagine this is why chess publishers have moved away from them. Chess is perhaps the only topic where fractions are regularly sprinkled among prose and hence, it is quite conceivable that the MOS would not have considered this specific effect when deprecating #1. An example passage would be under 'War Years' at Vassily Smyslov, where you'd have to imagine how it would appear with large 'half' symbols projecting into the line spaces - clunky and poorly conceived I would imagine. I gather the line spacing would not be affected, but that is something that would need confirmation. Tables and cross-tables are other places where fraction-heavy chess scores are used. A current example would be the tables used in Russia (USSR) vs Rest of the World. Once again, we'd have to visualize how these boxes would look with large fractions in them. Would there still be adequate space to the edge lines or would it all look ill-fitting, with variable gaps? As Max Browne says, using the decimal version in tables is one way forward, and frequently seen nowadays (although I personally think it looks poor).
If it helps, I can't see much problem with #3, should there be an insurmountable problem with #1. To my eyes, #3 is not a whole lot different, but still contrary to the vast majority of contemporary chess literature. We should also be aware that #1 has already been used in hundreds if not thousands of chess articles to date. Brittle heaven (talk) 12:17, 28 August 2014 (UTC)
3 would clearly be the best option if the kerning around the numerator and denominator could be balanced out. Cobblet (talk) 21:02, 28 August 2014 (UTC)
Note that MOS deprecates the ½ character (#1 above) because it is not always present on some computers and can give trouble to screen readers for blind people. However, fractions are still allowed (#2-6 above). The fraction could be shrunk down a bit to make them fit in the normal spacing. Eg 412 or 41/2. We could hide the complexity inside a template (possibly as a size option for {{frac}} and {{sfrac}}).  Stepho  talk  21:44, 28 August 2014 (UTC)
How do screen readers for the blind handle ones using Frac? Bubba73 You talkin' to me? 02:21, 29 August 2014 (UTC)
412/6 doesn't fix the kerning issue and as result is slightly less legible than option 1 (what we used to use), but at least seems to minimize the disruption in line spacing at most text sizes. Cobblet (talk) 22:04, 28 August 2014 (UTC)
How about 412/6, 412/6, 412/6, 412/6, 412/6 or 412/6 ? We can tweak the size, position and spacing of each part.  Stepho  talk  02:01, 29 August 2014 (UTC)
All of those make the numerator extend beyond the cap height, which to me (and others here) is unacceptable. It seems the frac template isn't optimal for our purposes. So far the best I can come up with is 412/6 which seems to ensure that the numerator never exceeds the cap height. Comparing to the original, side by side: 412/6 4½/6 Cobblet (talk) 03:13, 29 August 2014 (UTC)
On my screen, the half in the one you suggest is too thin to be seen easily. The second one in the comparison is fine, and is the same size as a capital letter. Bubba73 You talkin' to me? 03:43, 29 August 2014 (UTC)
Is it more legible if the fraction's bolded? So 412/6 vs. the original 4½/6. Or how about 412/6 which has the numerator slightly higher, which does cause it to exceed the letter heights at larger text sizes but seems fine at smaller sizes. Cobblet (talk) 07:59, 29 August 2014 (UTC)
On my screen, the second of those three is by far the best. The half is bold enough and it is the same height as the 4 and 6. Bubba73 You talkin' to me? 00:34, 30 August 2014 (UTC)
unfortunately your choice is the illegal one we are trying to replace.  Stepho  talk  02:25, 30 August 2014 (UTC)
Well, #3 in the list of 12 looks just about as good to me. Bubba73 You talkin' to me? 02:32, 30 August 2014 (UTC)
Brittle Heaven said "The main problem with fractions that stick up or down from the rest of the text is that they look awkwardly out of place in a passage of prose". I agree with that. Using Frac makes it go above and below the other characters and also causes a little more white space between that line and the ones above and below it. Bubba73 You talkin' to me? 02:12, 29 August 2014 (UTC)
Using Cobblet's idea of using bold fonts, let's push the bold weight to full, shrink the font a little more and tweak the vertical position like so: 412/6 . I believe that covers all of Bubba's stated concerns.  Stepho  talk  14:00, 29 August 2014 (UTC)
On my screen with my settings, that makes the half way too small. Bubba73 You talkin' to me? 00:31, 30 August 2014 (UTC)
Okay, let's give you a selection of sizes using the frac template:
  1. 412/6 at its natural size
  2. 412/6 at 60%
  3. 412/6 at 58%
  4. 412/6 at 56%
  5. 412/6 at 54%
  6. 412/6 at 52%
  7. 412/6 at 50%
  8. 412/6 at 48%
  9. 4½/6, the illegal character we want to replace
Personally, I find 4½ looks just too flat and boring for my taste. I find them more readable and natural looking if the fractions do stick out above and below the line a little as overshoots. But I agree that they should not affect the line spacing, which frac unfortunately does in its natural form. I think some of the new examples above are an effective compromise between small enough to not affect the line spacing (only a nearly indistinguishable pixel or two) and large enough to read.  Stepho  talk  02:25, 30 August 2014 (UTC)
The point is that we want them to be flat and boring. Otherwise you get travesties like this:
76th Tata Steel Tournament
Player Rating 1 2 3 4 5 6 7 8 9 10 11 12 Total TPR
1  Levon Aronian (Armenia) 2812 * 12 1 1 1 1 12 0 1 12 12 1 812 2911
2  Anish Giri (Netherlands) 2734 12 * 12 12 12 12 1 12 12 12 12 1 612 2809
3  Sergey Karjakin (Russia) 2759 0 12 * 0 12 12 12 1 12 1 1 1 612 2806

Those uneven cap heights are exactly what we're trying to avoid. Compare the complete original table at Tata Steel Chess Tournament#2014. Cobblet (talk) 04:26, 30 August 2014 (UTC)

What does a screen reader for the visually impaired do when it encounters a frac|1|2 ? Bubba73 You talkin' to me? 02:29, 30 August 2014 (UTC)

One last try: 4 12/6. User:Bubba73 and User:Brittle heaven, how does this look to you? Cobblet (talk) 04:26, 30 August 2014 (UTC)
that one is fine with me. Bubba73 You talkin' to me? 05:21, 30 August 2014 (UTC)
I think #2 and #3 are OK too - the only drawback is that they are a little taller than the 4 and 6 (which isn't too bad in those cases). Bubba73 You talkin' to me? 18:09, 30 August 2014 (UTC)
yes, also fine with me - could live with #1, #3 or this version. Brittle heaven (talk) 14:33, 30 August 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────That rendering of a half requires 192 characters in the wikitext, or an ugly template like {{chess half}}. I normally like what frac does but in chess articles it looks silly. I think all the potential replacements would need to be evaluated in a sandbox to show how they would appear in an article. Perhaps Graham87 would like to comment on how 4½/6 (using the symbol for half) works in a screen reader. Is there a problem? Following is the sentence from 41st Chess Olympiad, first with a single character for a half, then with the preceding proposal:

...and recorded four wins, one loss and one draw for a total score 4½/6.
...and recorded four wins, one loss and one draw for a total score 4 12/6.

Unless there is a knock-out access issue, the single-character half should continue to be used because it is wonderfully simple and has a very good appearance. Johnuniq (talk) 07:28, 30 August 2014 (UTC)

The character "½" is one of the few fraction characters that consistently works well with screen readers (the others are "¼" and "¾"), because it's in the ISO/IEC 8859-1 character set. Graham87 09:00, 30 August 2014 (UTC)
  • What is the issue with the character? If we are only talking about screenreaders, I occasionally use one called NVDA, which reads the character better than any given alternative for this purpose. The character actually reads as "[and] one half", while the others read as "one, two", "one slash two", or the math code beginning "slash frac". One of the alternative items of the first list above actually reads as "forty-one, two slash six" —PC-XT+ 20:59, 30 August 2014 (UTC)
In light of comments by User:Graham87 and User:PC-XT, keeping the ½ symbol is definitely the way to go. Perhaps we should even change the MOS guideline to allow for this exception. In situations where the ½ has a specific meaning and no other fraction would make sense in the same context, we should prefer to use the dedicated character. It should apply to an article like spin-½ as well. Cobblet (talk) 21:53, 30 August 2014 (UTC)
It isn't just a question of screen readers. The characters are hard for people with normal vision to read, especially if they allow their browser to display the text with the default size. I have normal vision and find the regular text hard to read unless I enlarge it. Even with the text enlarged, I have to interrupt the normal flow of my reading and loke closely to read the fraction characters. Jc3s5h (talk) 23:20, 30 August 2014 (UTC)
In contexts where the reader is unlikely to be concerned with making a distinction between ½ and ¼ (e.g. chess or quantum mechanics), I think a character that preserves normal line spacing while retaining decent legibility (compared to the various frac-template-based options presented above) should be preferred. The use of ½ characters on WP:CHESS is so widespread and non-controversial that we shouldn't change this unless there is an extremely compelling reason to do so. Cobblet (talk) 23:55, 30 August 2014 (UTC)
If the half character is OK in most modern readers, I'm wondering why it is depreciated in the MOS. Bubba73 You talkin' to me? 02:59, 31 August 2014 (UTC)
(edit conflict) If a unit symbol is needed to represent a half, when no other fraction is needed, I could see a character being used, either ½ or = (though = is less universal.) I could see a problem if it could be more than one fraction, though: ¼ and ¾ resemble each other enough to be confused rather easily. Even % can look similar. If this confusion isn't an issue for an article, the characters seem preferable, if they are closer to the sources. —PC-XT+ 03:08, 31 August 2014 (UTC) 03:12, 31 August 2014 (UTC)
I would oppose applying such an exception – made for the purpose of chess scores – to spins. If nothing else, this would clash with the existing advice at MOS:FRAC that science and mathematics articles should use either the form 1/2 (or the LaTeX equivalent \frac{1}{2}) or simply inline numerals, 1/2. The MOS already reads like a Byzantine legal document; making it internally inconsistent would worsen what is already a very messy compromise. My bias is that I tend to oppose such "targeted" exceptions in principle, lest the MOS turn into something resembling the Celestial Emporium of Benevolent Knowledge, and something like a law degree will be required to edit the encyclopedia. Archon 2488 (talk) 15:06, 31 August 2014 (UTC)
In that case I look forward to seeing your proposal to change the title of spin-½. The complexity of the MOS is a reflection of the complexities involved in editing an encyclopedia. Internal consistency is only desirable when it streamlines a set of arbitrary choices made by different disciplines (e.g. citation formats for different academic journals); but when those choices are not arbitrary, sacrificing logic in favour of "consistency" is bureaucracy at its worst. Cobblet (talk) 23:41, 31 August 2014 (UTC)
I don't like exceptions in the MOS, either. If, instead of a fraction, ½ is considered a symbol, like =, (though understood to represent [and resemble] a constant fractional value,) the MOS relating to fractions would not necessarily apply, right? (Of course, I would not advocate its use in an article with normal fractions, due to this resemblance.) —PC-XT+ 07:09, 1 September 2014 (UTC)
The logic behind that seems a little tortuous; it reads too much like a rationalisation. Special fraction characters are "fractions" for some purposes and generic "symbols" for others. Why is ½ really a better choice for spin articles? Solely because of kerning and line spacing issues? But what about other quantum numbers? Do we say that, for example, the charm quark is a spin-½ particle with a charge of +2/3? Moreover, my understanding of the above discussion is that other "special" fraction characters such as ¾ would remain proscribed. Why is it not arbitrary to use ½ for spin, but the fraction template in other contexts? Surely the least arbitrary option, in this case, is to display fractions in a consistent manner, rather than inventing a plethora of rules for every sub-category of article (which does not even have the excuse of aligning with real-world representation of fractions).Archon 2488 (talk) 12:09, 1 September 2014 (UTC)