Wikipedia talk:Manual of Style/Dates and numbers

Microsoft is more important than IBM and Toshiba

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

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 2¹⁰ 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)

They, the kilobytes, are multiples of 2¹⁰ bytes which is what most other people understand them to be. If there is any need to clarify further then just write the number of bytes or use power notation. Both methods are perfectly acceptable and don't use the hardly used and confusing IEC prefixes. Fnagaton 15:04, 9 September 2014 (UTC)

What they are "understood" to be obviously depends on context; a 3 TB HDD is generally not 3 TiB. It is obviously absurd to describe an unambiguous notation as "confusing", while an ambiguous notation is (by omission) considered not to be confusing. Because "kibibyte" has an unambiguous definition, the mapping "1 KiB → 2¹⁰ B" is well-established; they are literally the same thing, whereas the ambiguity in the abuse of the "kilo-" prefix in this context, a level of nonsense which also undermines the integrity of the SI, means that 1 kB is emphatically not the same thing as 2¹⁰ B. Archon 2488 (talk) 16:29, 9 September 2014 (UTC)

Something being unambiguous does not mean it cannot be confusing to others. It is not absurd to describes IEC prefixes as confusing, they are hardly used and not very well understood, ergo they are confusing. Using exact numbers of bytes is completely unambiguous and numbers are much more widely understood. Fnagaton 00:46, 12 September 2014 (UTC)

The 9 year long push for the IEC binary prefixes (KiB, MiB, GiB) on Wikipedia has failed in part because of Wikipedia policies: WP:Neutral point of view, WP:What Wikipedia is not, and WP:Verifiability.

Here is a quote from Neutral point of view

Neutrality requires that each article or other page in the mainspace fairly represents all significant viewpoints that have been published by reliable sources, in proportion to the prominence of each viewpoint in the published, reliable sources. Giving due weight and avoiding giving undue weight means that articles should not give minority views or aspects as much of, or as detailed, a description as more widely held views or widely supported aspects. Generally, the views of tiny minorities should not be included at all, except perhaps in a "see also" to an article about those specific views.

Virtually all publications, web sites and user documentation use the traditional KB, MB and GB. The new Apple iPhone 6 comes with 16GB, 64GB or 128GB of memory. Proponents of IEC binary prefixes propose using an obscure terminology will reduce ambiguity. The tradeoff is reduced readability, readers can click on a blue link and they will learn about this 10 year old failed standard. There is a policy that Wikipedia is not a soapbox or means of promotion.

There is not policy for reducing ambiguity at the expense of readability. Wikipedia does not use the scientific names for common plants and animals in articles aimed at general readers. It is acceptable to refer to a dead horse instead of the less ambiguous expired equus ferus caballus. -- SWTPC6800 (talk) 21:05, 12 September 2014 (UTC)

The IBM style guide

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. It has a 500 GB hard drive.

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)

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 ...

... 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.2x10⁹ bytes) of RAM. It has a 500 GB (500x10⁹ bytes) hard drive.
4. PREFERRED: My computer is equipped with 16 GB of RAM. It has a 500 GB hard drive.

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

---

References

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, 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)

References

Any use of IEC prefixes should not be permitted on Wikipedia for disambiguation, except in those very few articles that specifically talk about the prefixes. This is because it is still the case that they are hardly used and confusing to readers. For all other general articles just use the number of bytes or power notation for disambiguation. Actually the IEC prefixes in those very few articles should be disambiguated with the precise number or power notation anyway since they're hardly understood. Fnagaton 15:10, 9 September 2014 (UTC)

I would posit that the actual source of confusion is that we are not allowed to use unambiguous notation, and hence there are ambiguous articles. At least in the case of other ambiguous units such as "miles", the resident luddites are not so draconian as to forbid a conversion to unambiguous standard units of measurement. Who actually benefits from banning the use of unambiguous prefixes, other than those who hate rational standards? Archon 2488 (talk) 16:36, 9 September 2014 (UTC)

Numbers of bytes and power notation are completely unambiguous and are much more widely understood. The source of confusion comes from people trying to use hardly used prefixes on Wikipedia. The prefixes are not accepted standards by the industry so they're not standards that Wikipedia can use. Wikipedia reflects the world as it is, not as some people might want it to be. Fnagaton 00:41, 12 September 2014 (UTC)

Sept vs Sep for September

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)

As we know, WP has its own MOS which doesn't always agree with outside style guides nor need it. The current WP guideline rules "Sept" out. If you don't agree, start another RFC; anyone's free to challenge any guideline. It may seem like nonsense to some but a single system of abbreviations allows consistency and three-letter abbreviations form an internally consistent system (which is good for tables and infoboxes) besides they'd be hard to eliminate since {{#time:}} produces these. Anyhow, why are people using abbreviations in references? Per MOS, months should only be abbreviated where space is tight. Jimp 02:09, 3 September 2014 (UTC)

MOSNUM and WP:CITE say dates in references should conform to the date format called for by the citation format selected for the article. At least one allowable citation format, Modern Language Association (MLA), calls for dates such as 3 Sept. 2014. Thus, that format is allowed in articles that choose to follow the MLA citation style. Jc3s5h (talk) 12:25, 3 September 2014 (UTC)

MOS:LARGENUM

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. 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. 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. 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

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

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 Farmbrough, 19:02, 24 August 2014 (UTC).

In general, I agree with the OP. 2001–2010 is far less ambiguous than 2001–10, although this (as Stepho notes) to some degree might depend on the reader's background. There are some objections above, such as space considerations in tables, etc. I think that there's every chance that new guidelines could accommodate for exceptions in such cases. The only occurrence where I think the 2001–02 style should be kept is in expressions (and article titles) like the 2001–02 XXX season. HandsomeFella (talk) 16:11, 11 September 2014 (UTC)

There would be no harm in the MOS at least encouraging 2005–2012 rather than 2005–12 in all instances where brevity is not called for (i.e. indicating that it is preferred without mandating it in all circumstances). I think such a guideline would be appropriate. —Quondum 16:57, 11 September 2014 (UTC)

Another reason to capitalize the season

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

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. 41⁄2/6, as favoured by MOS and Archon.
3. 41⁄2/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. 41⁄2 / 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:

• Wikipedia talk:WikiProject Chess/Archive 17#Format for half-points?
• Wikipedia talk:WikiProject Chess/Archive 27#Notating draws
• Wikipedia talk:WikiProject Chess/Archive 27#On our other favourite bug-a-boos

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 41⁄2 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)

41⁄2/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 41⁄2/6, 41⁄2 /6, 41⁄2/6, 41⁄2 /6, 41⁄2/6 or 41⁄2 /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 4¹⁄₂/6 which seems to ensure that the numerator never exceeds the cap height. Comparing to the original, side by side: 4¹⁄₂/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 4¹⁄₂/6 vs. the original 4½/6. Or how about 4¹⁄₂/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: 41⁄2 /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. 41⁄2 /6 at its natural size
2. 41⁄2 /6 at 60%
3. 41⁄2 /6 at 58%
4. 41⁄2 /6 at 56%
5. 41⁄2 /6 at 54%
6. 41⁄2 /6 at 52%
7. 41⁄2 /6 at 50%
8. 41⁄2 /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	*	1⁄2	1	1	1	1	1⁄2	0	1	1⁄2	1⁄2	1	81⁄2	2911
2	Anish Giri (Netherlands)	2734	1⁄2	*	1⁄2	1⁄2	1⁄2	1⁄2	1	1⁄2	1⁄2	1⁄2	1⁄2	1	61⁄2	2809
3	Sergey Karjakin (Russia)	2759	0	1⁄2	*	0	1⁄2	1⁄2	1⁄2	1	1⁄2	1	1	1	61⁄2	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 1⁄2/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 1⁄2/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)

Perhaps you're right in the case of QM; that does not mean you're also right in the case of chess. Cobblet (talk) 01:59, 2 September 2014 (UTC)

Special fraction characters shouldn't be used as fractions. That is what the templates and math code are for, and problems with screen readers should be fixed in them. Fraction methods should be consistent within the article, as well. Special fraction characters should only be used as symbols, if they are appropriate. The ¼ and ¾ characters should probably be avoided, due to the higher possibility of confusion, unless they are the only like symbol used on the article, for some reason. The ½ symbol usage should be based on the amount of confusion it may have with other symbols in the article, and whether fractions would actually provide more benefit. In most cases, fractions should be used, but chess scoring is specialized enough that it works best with a symbol rather than with fractions. Since I suppose we only have Spin-½ or Spin-1/2 to choose from, this article title might be an exception, but it shouldn't affect the MOS. There are often exceptions. In the article body, with math, the fraction should most likely be used, as I've said. The only exception I would think reasonable to this would be to differentiate fractions from each other with different templates/math code, when labels and other methods are inappropriate. At that point, problems with the article will become more likely, and it will hopefully be reorganized to eliminate the need for such methods. —PC-XT+ 09:39, 2 September 2014 (UTC)

There are standard eight-bit Extended ASCII characters for ¼, ½, and ¾ that have been around for more than 30 years. Surely those should be OK. Bubba73 ^{You talkin' to me?} 03:32, 2 September 2014 (UTC)

Currency symbol before the figures

Wikipedia:Manual of Style/Dates and numbers#Format currently has

Do not place the currency symbol after the accompanying numeric figures (e.g. 123$, 123£, 123€) unless that is the normal convention for that currency when writing in English. Never use forms such as $US123 or $123 (US).

Can we remove the exception "unless that is the normal convention for that currency . . . "? Oxford and Chicago seem to get by without this exception, and it is my understanding that the convention is dependent on the language, rather than the currency, and that the text is usually adapted to the English convention when translating from foreign languages. If the text remains, we need an example showing where we want the symbol to follow the number. --Boson (talk) 16:15, 1 September 2014 (UTC)

Are there any instances in which this has been problematic? The existing language seems to be a reasonable means of providing a get-out clause in the (unexpected) case that there is some currency which generally uses a different convention. Archon 2488 (talk) 21:39, 2 September 2014 (UTC)

I would suspect that symbol-after usage is more prevalent outside the highest-profile currencies. I notice, for example, that Polish zloty uses puts the symbol after the number. Note also that symbols for currency subdivisions in English almost always occur after the number (50p not p50, 25¢ not ¢25). Kahastok talk 22:13, 2 September 2014 (UTC)

But again this is language-dependent. I think in most Eurozone countries, notation like "2,50 €" is more common (e.g. France [18] [19]) whereas Ireland uses the more common English-language convention [20]. Archon 2488 (talk) 23:09, 2 September 2014 (UTC)

Well, yes. Obviously. Nobody denied that usage of the euro sign euro was language-dependent. We even have an article on the subject. The same happens to the Canadian Dollar (English $2, French 2$).

But that does not mean that when English-speakers write currency subdivisions in English, they do not in most cases write the symbol after the number (and that includes euro cents - it's 60c not c60). Nor does it mean that there are not some less-well-used currencies where English speakers put the symbol after the number, such as (based on our article) the Polish zloty (2 zł). Kahastok talk 21:50, 3 September 2014 (UTC)

Kahastok shows with two examples why that language is there. Just copy-paste Kahastok's examples into MOSNUM if you think people won't understand.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:22, 6 September 2014 (UTC)

"give or take about"

The phrase "X give or take Y" already means "X, varied by approximately around Y". To include the word "about" is redundant, and poor use of language. To suggest that "give or take" implies bounds is WP:OR, to say the least. That's like saying we should suggest the notation (1.26 ± ~0.32) × 10³, because someone might interpret (1.26 ± 0.32) × 10³ to mean 0.94 × 10³ or 1.58 × 10³. Let's remove the phrase "give or take about" from an {{xt}} example, if necessary by using a noncontroversial equivalent. —Quondum 18:17, 2 September 2014 (UTC)

Agreed; "give or take" is the plain-English equivalent of "±". That said, this is an obvious enough typo, it could simply have been made per WP:BOLD without pre-empting WP:BRD with a discussion.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:24, 6 September 2014 (UTC)

The change was made, but since it was reverted, it is appropriate to seek consensus here. —Quondum 13:29, 6 September 2014 (UTC)

For the record, I do not object to the removal of "about". It seems redundant to me. Archon 2488 (talk) 20:08, 6 September 2014 (UTC)

It's not redundant, nor is it poor use of language. This gets to be rather complex to discuss, because there are "wheels within wheels", but first take a look at [21] to see how widespread "X give or take about Y" is in good semitechnical usage such as elementary statistics texts. That should convince you that it's at least acceptable usage. If you then want to discuss whether it's preferable (to "X give or take Y") let me know. EEng (talk) 00:02, 7 September 2014 (UTC)

Do the same search with the word "about" removed and the count drops to a quarter – which tells you there is something weird. But if you want to look at statistics, Google Scholar returns "give or take" about 26,000 and "give or take about" 209. Ngram viewer supports this a similar difference in books, with usage "about" coming in at under 0.5% of the usage. Conclude from this what you will. —Quondum 02:50, 7 September 2014 (UTC)

As you discovered, Google result counts are enigmatic at best, since one would think a search on "ABC" would return everything returned by a search for "ABCD", and more. My purpose was only to show that it has widespread accepted usage, and the search I linked does show that. EEng (talk) 05:34, 9 September 2014 (UTC)

I don't agree that you have demonstrated the point you seek to make: that it has widespread accepted usage. You also seem to have failed to gain support for your particular choice of words. My suggestion of using a noncontrovertial phrasing seems appropriate. —Quondum 20:00, 9 September 2014 (UTC)

If I understand "wheels within wheels" correctly, then I would ask this question in response to it: how do you calculate the uncertainty on an uncertainty? It doesn't work that way; it's not turtles all the way down. Normally you would simply give a range of error equivalent to "give or take 1 sigma". Archon 2488 (talk) 20:31, 7 September 2014 (UTC)

I'm afraid you're wrong. Let's say we make a point estimate of an unknown platonic "exact" value, to which we assign an uncertainty. However, what can't (in most situations) know precisely what the uncertainty is, only estimate it, and so to that estimate we attach an uncertainly -- an uncertainty on the uncertainty. And, yes, there's an uncertainty on the uncertainty's uncertainty of the, um, uncertainty. I'm certain of it ... The reason statistics works, in spite of this infinite regress, is that in most situations there's a rapid decay in the magnitude of these uncertainties, so that you quickly come to the point where the higher-order uncertainties are trivial (though not nonexistent).

So it is indeed turtles all the way down, except in a sort of inverted pyramid with the biggest turtle at the top, if bigger turtle = bigger uncertainty. (If bigger turtle = bigger "certainty" -- whatever that might mean -- then it's the more intuitive turtle-on-a-bigger-turtle-on-a-bigger-turtle-on-a-... all the way down.) In the words of the great Augustus de Morgan:

Great fleas have little fleas upon their backs to bite 'em,

And little fleas have lesser fleas, and so ad infinitum.

And the great fleas themselves, in turn, have greater fleas to go on;

While these again have greater still, and greater still, and so on.

EEng (talk) 05:13, 9 September 2014 (UTC)

In principle I guess that's right, but in principle there's no such thing as an uncertainty anyway. In the real world, an uncertainty is a calculated property of a measured distribution; it will converge to a certain limit as the sample of measurements becomes more representative of the underlying distribution (this is your "platonic uncertainty"). But at a practical level this is really meaningless; if your estimate of sigma is crap, the solution is always collecting more data (or more representative data); it's not doing higher-order corrections to the calculation of sigma ("errors on errors"). If your analysis isn't dominated by statistical fluctuations, then the variance in the variance should be zero, or negligible. Moreover, confidence levels and p-values are always defined in terms of actual observed sigmas, not Plato's hypothetical perfect sigmas. Archon 2488 (talk) 13:24, 9 September 2014 (UTC)

Years at beginning of sentences

The manual now says that we should avoid writing out years as words. While I generally agree with this, which is pretty standard across writing guides, I think this should not include years when they are at the beginning of a sentence, since another precept of English is to avoid starting sentences with digits. Hopefully, this "conflict" won't come up often, but in reporting speech (e.g., two thousand five /2005 was the best year of my life) and some other occasions starting a sentence with a year is probably unavoidable. Can we have a statement on this in the manual?Kdammers (talk) 07:11, 11 September 2014 (UTC)

In such cases I think it would be best to rewrite the sentence, if possible, so that the number does not occur at the beginning. Generally I would oppose writing out numbers because it decreases legibility and increases wordiness; "2005" is certainly easier to parse. Archon 2488 (talk) 10:33, 11 September 2014 (UTC)

This can always be fixed by prefixing the words The year: "The year 2005 saw the biggest increase in..." I've boldly added an example illustrating this [22]. EEng (talk) 21:53, 11 September 2014 (UTC)

I've reverted myself because, as a friend points out, it's a problem keeping people from overusing "In the year 19xx" and so on, and we don't want to encourage it. Such sentences can always be rewritten. EEng (talk) 03:00, 12 September 2014 (UTC)

The northern hemisphere versus the southern

At the moment, MOSNUM (Seasons) is worded as if the Northern and Southern Hemispheres were in competition. I believe it could be copy edited from this:

• Because the seasons are reversed in the northern hemisphere versus the southern (and areas near the equator may have wet and dry seasons instead)...

to this:

• As the seasons are reversed in the northern and southern hemispheres and areas near the equator may have wet and dry seasons instead,...

Any comments or other suggestions? Michael Glass (talk) 02:32, 13 September 2014 (UTC)

versus is used in contexts outside litigation and pugilism. In general it means in contrast to, which is fine here. But if it keeps you up at night I don't think anyone would object to your version (though I'd keep the and areas near bit in parens). EEng (talk) 02:53, 13 September 2014 (UTC)

As an Australian (southern hemisphere) I can say we are definitely in competition with the north. So many articles say "in the spring of 2012" or similar because the majority of editors come from the north and think that their local season applies to the rest of the world. Although, to be fair, we southerners also say "in the spring" when talking among ourselves", but we swap to "in September" when talking to non-locals. The 'versus' in the original emphasises that the hemispheres are completely opposite, while the 'and' in the proposed version implies that the northern and southern hemisphere are somehow united.  Stepho  talk  07:30, 13 September 2014 (UTC)

I'm also Australian and the fact that the Northern Hemisphere has different seasons is only problematical because Northerners sometimes forget that their seasons are not universal. There are the monsoons near the equator and the reversal of the seasons further south. Despite this, the world is still united. As for the parentheses, I suggest deleting them because it seems to downgrade the importance of the monsoon seasons. My suggested wording is also slightly shorter, which I believe is also an advantage, other things being equal. Michael Glass (talk) 07:50, 13 September 2014 (UTC)

In my view, the existing bullet point plus its subpoint don't explain clearly the real issue, which not to use seasons when a specific time is meant, because seasons aren't universal. Only use seasons when they are relevant regardless of the location, e.g. it's fine to say that a particular plant flowers in the spring, or that an animal hibernates in the winter. Peter coxhead (talk) 10:52, 13 September 2014 (UTC)

Do you think this more extensive rewrite would address the point you made?

• Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
• Reference to seasons are appropriate when related to the point being made (the autumn harvest;  migration typically begins in mid-spring).
• Reference to seasons are problematical when used to refer to time, for example, winter 1995 This is because:

• Seasons are reversed in the northern and southern hemispheres.
• Areas near the equator often have wet and dry seasons.

• Therefore avoid references to seasons as markers of time. Consider instead early 1995;  the first quarter of 1995;  January to March 1995, even where a particular location is involved.

Are there any other suggestions or recommendations? Michael Glass (talk) 11:33, 13 September 2014 (UTC)

This guideline covers the body of the article, tables, infoboxes, and the like, but not citations. Citations should be dealt with in whatever documentation may be available for the citation style used in the article, and universal principles could be mentioned in WP:CITE. Any rewrite should probably avoid words like "refer", "cite", or "citation". If a publication lists its publication date as "SPRING 2014", the citation date would give the same season name and year for the publication date (but the capitalization would be changed to conform to the rules for the citation style used in the article). Jc3s5h (talk) 13:56, 13 September 2014 (UTC)

Reference is also used in the present wording so your criticism applies to the present text. However, my wording can be tweaked to remove this difficulty:

• Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
• Using seasons is appropriate in instances like these: (the autumn harvest;  migration typically begins in mid-spring).
• Using seasons to refer to time, for example, winter 1995 is problematical. This is because:

• Seasons are reversed in the northern and southern hemispheres.
• Areas near the equator often have wet and dry seasons.

• Therefore avoid using seasons as markers of time. Consider instead early 1995;  the first quarter of 1995;  January to March 1995, even where a particular location is involved.

Does this answer the concerns you expressed or could you suggest a better solution? Michael Glass (talk) 14:49, 13 September 2014 (UTC)

Yes, the revision of 14:49, 13 September 2014 (UTC) addresses my concern. I'll leave it to others to consider whether it needs to be that long. Jc3s5h (talk) 15:41, 13 September 2014 (UTC)

I'm afraid I disagree on the qualification even where a particular location is involved. Isn't it more meaningful to talk about the winter advances of Napoleon and the German army into Russian than to give months (except where specific dates for specific aspects are given)? and what about ancient Roman or Greek events? Are we to use months that didn't exist then to date battles or droughts? Kdammers (talk) 23:24, 13 September 2014 (UTC)

Recurring problems with Temperature RANGE or COMPARISON versus temperature CONVERSION

I don't know where else to raise this issue. I don't even know if this issue has a standard name.

I am not a Wikipedia Expert, Maven or Nit-picker, but sometimes I notice things which are just plain wrong, and are wrong in ways I have not seen covered elsewhere. Please see talk I posted at at https://en.wikipedia.org/wiki/Talk:Flash_point#Temperature_Comparison_vs_Temperature_Conversion and https://en.wikipedia.org/wiki/Talk:Exhaust_gas_temperature_gauge#Temperature_RANGE_versus_temperature_CONVERSION

The problem is, the 32-degree temperature offset built into the present Conversion Function does not apply in such cases. Only the slope of the two temperature graphs matters, which is a simple rate or ratio rather than the usual Math Function.

I suggest that an article on this topic be created and that any use of the Temperature Conversion Function be caused to throw a warning about proper use. Further, I suggest a separate function to deal specifically with Temperature Range Comparison, which is a simple and exact rate like 9 Fahrenheit degrees equals 5 Celsius degrees, 18 Fahrenheit degrees equals 10 Celsius degrees, 27 Fahrenheit degrees equals 15 Celsius degrees, etc., a rate of 1.8 to 1 regardless of the particular temperature involved. The conversion rate is the ONLY thing which matters in such cases. When comparing temperatures given in Celsius, the same exact rate applies, but reversed: 1 to 1.8.

/end rant

Thank you. YodaWhat (talk) 06:11, 14 September 2014 (UTC)