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)

Anyway, using the traditional KB, MB and GB for powers of ten or two is not ambiguous. People who are experts in the subject matter are easily able to know what the precise number bytes is by looking at the context of their use. Fnagaton 06:45, 14 September 2014 (UTC)

"using the traditional KB, MB and GB for powers of ten or two is not ambiguous" But that is the very definition of ambiguity; a term which can have multiple meanings. Of course, additional contextual information or expertise can aid in disambiguation, but that does not mean that there is no ambiguity to be resolved. A standard is not a viewpoint, because it is not a proposition that can be true or false; it is simply a medium for communicating information. This is like saying that writing articles in English biases them – the medium is not the message. The standard is verifiable not because lots of random publications use it, but because it has been formally defined by an international organisation. By contrast, if everyone used the word "metre", but with hundreds of different meanings depending on context, then the standard would not be well-defined. In the real world, it is a well-defined standard because the (very unpopular in MOSNUM) BIPM maintains its definition. As for "the views of tiny minorities should not be included at all", the article evolution has a section which is at least in part about creationism. Archon 2488 (talk) 22:02, 22 September 2014 (UTC)

I served on standards committees for over ten years and sometimes industries just ignore a standard. The semiconductor and computer industries have ignored the IEC binary prefixes. Try to purchase a product specified with Mib or Gib. The publishing industry has ignored the IEC binary prefixes. Try to find a reliable source that mentions MiB or GiB. (A one in a million source is not a neutral point of view.) There is just a tiny minority of Wikipedia editors advocating the adoption of the IEC binary prefixes. The rest of the world has the viewpoint that MB and GB are good enough. This is a dead horse debate. -- SWTPC6800 (talk) 02:41, 23 September 2014 (UTC)

Is this a one-in-a-million source [14]? Is it reliable? Clearly Canonical is not interested in settling for what some would consider "good enough". IMO their units policy is far better than ours in this regard, because it deliberately avoids confusing decimal and binary. Spelling things out is unambiguous but tedious and arguably less legible; you wouldn't really thank someone who told you in every instance that 23.5 kilometres is the same thing as 23500 metres and that 1.5 t is equivalent to 1.5×10⁶ g. Archon 2488 (talk) 16:08, 23 September 2014 (UTC)

Your source, "Ubuntu wiki", appears to be a wiki for a software product. They are giving their local definitions for units. There is a high bar for self-published sources; the Wikipedia Manual for Style does not qualify as a reliable source and it is very unlikely that "Ubuntu wiki" is a reliable source. There is also the serious problem of undue weight. Read Wikipedia:Identifying reliable sources -- SWTPC6800 (talk) 00:09, 24 September 2014 (UTC)

Archon, by the way your claim "But that is the very definition of ambiguity; a term which can have multiple meanings." is incorrect because it ignores the important definition of "ambiguous" that includes "not having one obvious meaning". To someone skilled in the area, like myself, KB etc do have one obvious meaning when they're considered in context. Hence they are not ambiguous per se. If someone finds them ambiguous then I would point out they are apparently not experts in the field. Therefore, if they are apparently not experts in the field then perhaps they should not be contributing poorly sourced changes to technical articles that rely on technical knowledge and understanding to apply due weight. Fnagaton 10:46, 3 October 2014 (UTC)

Continue discussion of the multiple and uncertain meanings of the word ambiguous here

EEng (talk) 15:57, 3 October 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)

By that logic one ought to ban the abuse of SI prefixes, which is actually ambiguous and genuinely confusing. These IEC standards have a single unambiguous definition which is maintained by an authority independent of Wikipedia, so it is hardly surprising that people would try to use them (which, by the way, is counterevidence to your claim that they are hardly-used; if they were actually hardly-used then the argument would solve itself and we would not be here). Archon 2488 (talk) 13:17, 22 September 2014 (UTC)

Kilobyte et al. have a long history of using powers of two with RAM, that's the accepted use in the industry over many years. One of the problems is that some people cannot accept IEC prefixes are hardly used. That some cannot accept they are hardly used does not provide counter evidence of my claim either, that's because my claim references the real world majority use not the distinct minority opinion of those who want to use IEC prefixes contrary to accepted industry use. Fnagaton 10:59, 28 September 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 ([15]) 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)

Yes, I concur with encouraging preference for the longer form in the MOS, while not prohibiting the shortened form where appropriate. Mojoworker (talk) 17:24, 1 October 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 [16]. 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)

I agree that the phrase even where a particular location is involved. could be dropped. The phrase adds nothing to the policy. How could a particular location not be involved? The draft is shorter and better without it. Michael Glass (talk) 09:35, 14 September 2014 (UTC)

Here is the policy without the words about location:

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

Are there any further suggestions? Michael Glass (talk) 10:45, 16 September 2014 (UTC)

I would actually prefer the language to be stronger and more forceful about basically prohibiting the use of climatic seasons as "dates". The word "problematical" is wishy-washy, we need much more emphatic deprecation than that - if for no other reason than to teach our dear Yank friends that their country's borders are not congruent with the limits of the known universe.  ;)Roger (Dodger67) (talk) 13:09, 16 September 2014 (UTC)

Thanks for your observation. There are ways to strengthen the wording.:

One way is to use the word inappropriate in place of problematical:

• Using seasons to refer to time, for example, winter 1995 is inappropriate.

or

• It is inappropriate to use seasons to refer to time, for example, winter 1995

What do others think? Michael Glass (talk) 11:52, 17 September 2014 (UTC)

I recommend the word "ambiguous", which is the reason for avoiding this usage. – Jonesey95 (talk) 14:56, 17 September 2014 (UTC)

small suggestion, instead of "Seasons are reversed in the northern and southern hemispheres." use "Seasons are reversed between the northern and southern hemispheres." --MASEM (t) 14:59, 17 September 2014 (UTC)

I -- yam the very model of a modern problematical

I've information verified and templated -- heretical ! ...

--EEng (talk) 00:50, 18 September 2014 (UTC)

Arbor tree-ish break

Thanks to all who contributed. EEng, thanks for making me laugh. Jonesey95, using ambiguous might work but though Masem makes a good point, but what lies between the Northern and Southern Hemispheres is the Equator! Nevertheless, there is a way of removing the word in"" Here is a draft which takes into account Jonesey95 and Masem's ideas and also cuts the word count:

• 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 ambiguous because:

• Northern and southern hemisphere seasons are reversed. and
• 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.

How do people feel about this draft? Michael Glass (talk) 10:52, 19 September 2014 (UTC)

I've tinkered a little. In MOSNUM, bolding is used to help editors find relevant passages, not for emphasis; we don't need to bulletlist the north/south and wet/dry reasons; and I do think it needs to be said that a known locale being in play doesn't really change anything. Apologies if anything here conflicts with something agreed upon above:

• Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
• Avoid using seasons as periods of time because the seasons are reversed in the northern and southern hemispheres, and areas near the equator often have wet and dry seasons instead: not dividend in winter 1995, but early 1995 or January to March 1995.

• This remains true even where a particular location is involved: spent the summer in Melbourne
• Exception: Constructions such as autumn harvest and spring migration may be appropriate when the particular season(s) are relevant to the point being made.
• Avoid of unless sentence structure calls for it: herd declined in the spring of 2003;  declined in spring 2003;  declined in the springs of 2004, 2005, and 2006

Remember: editors below the equator (determined either from their account preferences or their IP location) will see these points presented in reverse order. EEng (talk) 17:41, 19 September 2014 (UTC)

Here is my proposal, taking up many of EEng's suggestions. I have not taken up his last point because it is purely a question of style and I have tried to keep the word count down. Please review

• Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
• Using seasons to refer to a particular time of year, for example, winter 1995 is ambiguous. This is because orthern and southern hemisphere seasons are reversed. and areas near the equator often have wet and dry seasons.
• Consider instead early 1995;  the first quarter of 1995;  January to March 1995;   spent the southern summer in Antarctica;.
• Using seasons is appropriate in instances like these: the autumn harvest;  migration typically begins in mid-spring.

Michael Glass (talk) 23:07, 20 September 2014 (UTC)

I applaud your impulse to keep the guidelines succinct but I think it's a mistake to omit material anticipating ill-advised logic that editors might come up with e.g. "well, it's not ambiguous if I say it's Australia". As for the material re use of of, of often offends awfully... um... trust me... if we don't say this there will be fights about it. Let's see what others think. EEng (talk) 04:49, 21 September 2014 (UTC)

I don't see why "spent the summer in Melbourne" should be disallowed in every instance; that strikes me as very pedantic. Who would interpret it to mean "spent the northern hemisphere summer in Melbourne"? Archon 2488 (talk) 21:49, 21 September 2014 (UTC)

The main aim is stop stop people from putting in things like "The new Ford Mustang was released in the Summer of 2005", which has only a tenuous link with summertime and confuses those of us in the south. Sayings like "spent the summer in Melbourne" is more of a grey area and also depends on context. Eg a Californian saying he spent the summer in Melbourne could mean he spent the time in Melbourne during the Californian summer (ie Australian winter) or during the Australian summer (ie Californian winter). It also depends on whether the trip to Melbourne (from whatever location) was linked to summer (eg spent at the beach) or just happened to coincide with summertime (eg business trip). If the context is clear and there is a strong link to the season, then "summer" is fine, otherwise it should be a month (or the closest we can match).  Stepho  talk  05:24, 22 September 2014 (UTC)

A better example would be going to Antarctica for the southern summer as per my draft above. One does not usually go to Melbourne, or most other cities, for the summer. Michael Glass (talk) 09:16, 22 September 2014 (UTC)

OK, point taken. I suppose "the southern hemisphere summer" would be unambiguous and so probably better in most instances. Personally I would not reject the idea of spending summer in Melbourne :) Archon 2488 (talk) 21:43, 22 September 2014 (UTC)

Final draft before posting in MOSNUM?

First, I'd like to thank everyone for their suggestions. Here is a draft that could go in MOSNUM. I was tempted to have the migration occur in mid-autumn but refrained because it would mean two references to the same season.

• Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
• Using seasons to refer to a particular time of year, for example, winter 1995 is ambiguous. This is because northern and southern hemisphere seasons are reversed. and areas near the equator often have wet and dry seasons.
• Consider instead early 1995;  the first quarter of 1995;  January to March 1995;   spent the southern summer in Antarctica;.
• Using seasons is appropriate in instances like these: the autumn harvest;  migration typically begins in mid-spring.

No wording can hope to be perfect, so if anyone can think of another improvement, please suggest it. Otherwise I'll wait about 48 hours and then insert it into MOSNUM. Michael Glass (talk) 06:30, 23 September 2014 (UTC)

Minor typo in second bullet point "orthern" should be "northern" Keith D (talk) 12:37, 23 September 2014 (UTC)

Thanks for picking that up. I've now corrected it. Michael Glass (talk) 13:10, 23 September 2014 (UTC)

MOSNUM revised as proposed above. Many thanks to all who have contributed to the revised wording. Michael Glass (talk) 21:10, 25 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)

Don't worry about not being a maven or nit-picker. Here at MOS we have editors who have carved out roles for themselves specifically devoted to such activities. The technical terms for what you're talking about is the difference between "interval" and "ratio" variables. WP's treatment of this (Level_of_measurement#Interval_scale) could use improvement, but see these other explanations: [17][18][19][20].

{{convert}} already has provision for this -- the C change and F change "units". Search the word warmer in Template:Convert/list_of_units. EEng (talk) 12:19, 14 September 2014 (UTC)

Wikimedia product development and en.WP style

This thread might have relevance to MOSNUM experts. Tony (talk) 12:18, 18 September 2014 (UTC)

Edit

Winner -- least useful section heading. EEng (talk)

I hadn't noticed the sprawling boldface, which (i) was often inconsistent grammatically in a sequence; (ii) was diluted in effect through an excessive bold–non-bold ratio in the main (non-section-title) text; (iii) was weakening the effect of the section title formatting, which is strongly reliant on boldface; and (iv) was messy to look at, synoptically.

So I've gone through and tamed it, retaining instances of obvious contrast and most of the bolded sub-sub-headings that neatly opened a point. There was evidence of a strategy of bolding one item consistently in each bullet throughout a list once one or two initial points had received the bolding treatment—a kind of slippery slope that led to suboptimal formatting in many places.

I've reworded the recently edited point on seasons WRT the two hemispheres to avoid ambiguity: "This is because northern and southern hemisphere seasons are reversed. and areas near the equator often have wet and dry seasons." -> "This is because northern and southern hemisphere seasons are six months out of phase, and many areas near the equator instead have wet and dry seasons." (Again, I've removed what appears to be a low-value boldface.)

I hope this is all OK. Tony (talk) 02:09, 26 September 2014 (UTC)

You killed my baby. <sniff> The bolding is intended to make it easier to locate vaguely remembered provisions at the level just below sections. It was added over many months with many editors participating in related discussions of guideline wording. (There was very little mention of the bolding -- it seems to have been a given it was an improvement.) I'm sure you're right it's applied inconsistently, incompletely, and in some cases for emphasis (which it's not meant for), but I'd like you to consider that we should improve it rather than dump it. EEng (talk) 04:13, 26 September 2014 (UTC)

"Seasons are reversed" versus "seasons are six months out of phase". I really do think that the former phrase says all that needs to be said in plain English. What do others think? Michael Glass (talk) 09:55, 26 September 2014 (UTC)

EEng ... now I feel bad. :-( Perhaps try it for a few days and see if it's ok, on balance. I'm easy about it. Michael, never doubt the ability of some editors to take the seasons as reversed in order (seriously): winter, fall, summer, spring. Tony (talk) 10:03, 26 September 2014 (UTC)

Continue "seasons" discussion here, please

If they were that challenged they probably wouldn't understand what "six months out of phase" meant. Seriously, everyone in the southern hemisphere knows that when the north has summer, we have winter and when we have autumn, they have spring. and vice versa in both cases. I hope that no-one believes that time goes backwards south of the equator. Michael Glass (talk) 13:56, 26 September 2014 (UTC)

Continue "boldface" discussions here, please

Perhaps we should consider a form of highlighting other than boldface, though it needs to be eyecatching. How about small caps?

• Current events are dated using the Gregorian calendar.
• Dates of events in countries using the Gregorian calendar at that time are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752, and Russia from 14 February 1918 (see Gregorian calendar).
• Dates before 15 October 1582 (when the Gregorian calendar was adopted) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1 January (see below for more details).
• Dates for Roman history before 45 BC are given in the Roman calendar, which was neither Julian nor Gregorian. When (rarely) the Julian equivalent is certain, it may be included.
• For dates in early Egyptian and Mesopotamian history, Julian or Gregorian equivalents are often uncertain. Follow the consensus of reliable sources, or indicate their divergence.

I don't think this is eyecatching enough when one scans the page. Underlining?

• Current events are dated using the Gregorian calendar.
• Dates of events in countries using the Gregorian calendar at that time are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752, and Russia from 14 February 1918 (see Gregorian calendar).
• Dates before 15 October 1582 (when the Gregorian calendar was adopted) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1 January (see below for more details).
• Dates for Roman history before 45 BC are given in the Roman calendar, which was neither Julian nor Gregorian. When (rarely) the Julian equivalent is certain, it may be included.
• For dates in early Egyptian and Mesopotamian history, Julian or Gregorian equivalents are often uncertain. Follow the consensus of reliable sources, or indicate their divergence.

(I'm not even gonna show italics -- looks awful.) Here's the original boldface:

• Current events are dated using the Gregorian calendar.
• Dates of events in countries using the Gregorian calendar at that time are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752, and Russia from 14 February 1918 (see Gregorian calendar).
• Dates before 15 October 1582 (when the Gregorian calendar was adopted) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1 January (see below for more details).
• Dates for Roman history before 45 BC are given in the Roman calendar, which was neither Julian nor Gregorian. When (rarely) the Julian equivalent is certain, it may be included.
• For dates in early Egyptian and Mesopotamian history, Julian or Gregorian equivalents are often uncertain. Follow the consensus of reliable sources, or indicate their divergence.

And -- I know it sounds weird -- here's bold + smallcaps:

• Current events are dated using the Gregorian calendar.
• Dates of events in countries using the Gregorian calendar at that time are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752, and Russia from 14 February 1918 (see Gregorian calendar).
• Dates before 15 October 1582 (when the Gregorian calendar was adopted) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1 January (see below for more details).
• Dates for Roman history before 45 BC are given in the Roman calendar, which was neither Julian nor Gregorian. When (rarely) the Julian equivalent is certain, it may be included.
• For dates in early Egyptian and Mesopotamian history, Julian or Gregorian equivalents are often uncertain. Follow the consensus of reliable sources, or indicate their divergence.

The bold+smallcaps looks better than I thought it would, actually. Shall we all meditate on this a while? I do think it's a good idea help people find individual points in the very large oceans of guidelines. EEng (talk) 17:42, 26 September 2014 (UTC)

<bump> (If I may distract my esteemed fellow editors from the statue-heights argument.) EEng (talk) 04:55, 3 October 2014 (UTC)

Which units should be primary for the height of a UK statue of a UK politician?

I ask because, to me at least, it is blindingly obvious that it should be feet and inches. However, my experiences at Donald Dewar and Forth and Clyde Canal Pathway with User:Archon 2488 (who burns most of his Wikipedia hours converting articles, particularly those with a British subject matter, to metric) and supported in the instances mentioned by User:Lesser Cartographies, leads me to suspect that the MOS needs to either make it very explicit that Wikipedia expects articles to use a single standardised/standardized system of spellings, units of measure, etc. OR it should more strongly support the use of the indigenous units for UK articles, as it does for US articles. Any comments? ProProbly (talk) 20:48, 30 September 2014 (UTC)

WP:UNIT is explicit that the main units for personal height in non-science/engineering UK articles are feet and inches. RGloucester — ☎ 21:17, 30 September 2014 (UTC)

Yes, but this is the height of a statue, not Dewar himself, so the letter of the rule prefers metres. If the statue was deliberately the same height as Dewar (or a specific multiple of it), you might say, well, it's still a personal height - but this one's 9 feet tall. Kahastok talk 21:35, 30 September 2014 (UTC)

Oh, it is about a statue. I thought that he meant the fellow's height. In that case, you are correct. RGloucester — ☎ 22:17, 30 September 2014 (UTC)

I am not convinced that WP policy should be guided by something as vague as someone's idea of what "indigenous" means. This sounds more like an attempt to introduce a dubious nativist political bias than to reflect modern usage. WP is not going to standardise/ize on a single style for every article, because its subject matter and users are spread across many cultures that use different conventions. ENGVAR is a whole different can of worms, but similar considerations apply there also. Archon 2488 (talk) 22:26, 30 September 2014 (UTC)

When in doubt, use universally understood (SI) units. Dondervogel 2 (talk) 06:56, 1 October 2014 (UTC)

That is obviously the wise approach. This IS a global encyclopaedia, after all. HiLo48 (talk) 17:20, 1 October 2014 (UTC)

SI units are not universally understood or used. In fact, it would be highly unusual to insist upon SI units in many circumstances - even in countries that generally prefer them. Kahastok talk 17:42, 1 October 2014 (UTC)

Yes, many know about SI units. Do they understand them or know how big 2.75m is? No. Vegaswikian (talk) 18:37, 1 October 2014 (UTC)

How many people actually don't know what 2.75 m means? In most countries it's the only scale of length which is taught (and has been so for many years), so few outside the older generations in some English-speaking countries really have any excuse for being ignorant of it. I don't believe that Wikipedia should entertain the silliness of people who pretend not to understand "those newfangled kilowotsits" or "that celsigrade thingy"; at least in the UK, most of these people have an overt cultural-political bias to their pretend ignorance. Moreover, if someone claims not to understand dimensions in metres or feet, does that justify the use of vivid units such as "two-thirds the height of a double-decker bus"?

As for "SI units are not universally understood or used", that would in principle be true even if there were only a single example of someone ever using a non-SI unit, or only a single example of someone who was ignorant of the SI. But you cannot infer from that somewhat trivial point that the use of the world's standard measurement system is "highly unusual ... in many circumstances". Archon 2488 (talk) 19:57, 1 October 2014 (UTC)

Thank you for age discrimination and calling people ignorant. And no, I don't know how long 2.75m is. It is not important that I know what it means, which I do. But since it is not my normal unit of measurement, I don't know how long it is. Yes, I can figure it out, but that is not the same as knowing. Vegaswikian (talk) 21:10, 1 October 2014 (UTC)

It's not age discrimination to point out that older generations at least have some sort of credible excuse for not knowing what a metre is. In my grandmother's generation it was quaint, like the occasional references to farthings and tanners, but in someone of my generation I would consider it very strange. And what do you call someone who is ignorant of something, except ignorant? That is why the word exists. Archon 2488 (talk) 23:29, 1 October 2014 (UTC)

You always argue this and it's always specious. Your continual insistence that there is no difference between being able to define a unit and having an intuitive scale in that unit only undermines your argument. Nobody denies that most people may well know that 2.75 metres is 275 centimetres. But that does not mean that they can visualise what 2.75 metres means in terms of the height of a statue. Your points about double-decker buses and "those newfangled kilowotsits" or "that celsigrade thingy" (could we have a diff for those quotes please?) are nothing by straw men.

As to the second point, it is trivial to think of circumstances in which use of "the world's standard measurement system" is indeed highly unusual. Even in scientific discussion. Astronomy is the classic one - are you seriously suggesting that astronomers use SI petametres and exametres instead of non-SI light-years and parsecs? Plane altitudes in feet are standard in countries throughout the world. Screen sizes in inches are standard in countries throughout the world. And when was the last time you heard someone discussing their age in megaseconds or kilodays? The year is not permitted by SI. Kahastok talk 21:22, 1 October 2014 (UTC)

I've never said that knowing the definition of a unit (e.g. being able to recite the definition of the metre in terms of c) is relevant. Having seen and used a ruler would probably be more realistic. But in either case you're saying that a certain arbitrary length is, for example, 3.15 times the length of a metre stick or 10 1⁄3 times the length of a foot rule. I fail to see how the latter is more meaningful than the former. Anyway, we're not talking about some great mystery of the universe on the scale of a GUT; we're talking about a basic numeracy skill that I had mastered by the grand old age of about ten, and which the vast majority of people on earth who've received any formal education have been taught and examined on. If we were to apply this extremely low bar for numeracy skills to literacy skills, what reading level would articles need to be written for? My point is that this is a standard which is applied nowhere else.

As for astronomy, the larger SI prefixes are indeed uncommon (as they are for most things), but that doesn't mean it would be "highly unusual" to give such large distances in metres or kilometres in scientific notation. Saying that exametres are unused is obviously a strawman intended to make the SI look silly, as is the stuff about kilodays. To state something which is so obvious it should not have to be said, the earth's orbital and rotational periods are neither metric nor imperial units (they are not even constants), so they are irrelevant to this discussion. Archon 2488 (talk) 23:29, 1 October 2014 (UTC)

Most people who see "9 feet tall" don't think in terms of 9 rulers - or 3 yardsticks - laid end-to-end. Same as most people thinking of walking 500 metres don't think of it in terms of 500 metre-rules laid end-to-end, and those thinking of walking a mile don't think of it in terms of 1760 yardsticks laid end-to-end. You know how tall 9 feet is because you have seen things that you know are 9 feet tall, or that you know are 6 feet tall (half as high again is not that big a leap). You may not have any point of reference for something that is 3 metres tall because you've never seen something measured that you know is three metres tall, because - ultimately - you don't use metres in day-to-day life. In the same way, you know how far thirty miles is because you've walked/rode/driven that distance before, and known that it was thirty miles, enough times to give you an intuitive sense of the distance. You may not have ever knowingly driven 60 kilometres before (you may have done the distance but not known it was 60 kilometres), or done it so long ago or so infrequently that you do not have an intuitive sense of the distance. Do you really think that most people in metric countries imagine 60 kilometres as 60000 metre-rules laid end-to-end? Of course they don't.

You believe that all people who don't have an intuitive scale of metric units are deeply stupid. I feel I can say this with confidence given how many times you have abused me and others when we point out that not everyone does. In doing so you are issuing a personal attack against a significant proportion of our readers and editors, and that's not really an appropriate attitude to have when editing Wikipedia.

On your second paragraph, the point you are disputing is "it would be highly unusual to insist upon SI units in many circumstances - even in countries that generally prefer them". It seems bizarre that when I point out some of those circumstances you claim that they are "obviously a strawman intended to make the SI look silly". Reality is, because the year is not accepted by SI, the ages of people is a circumstance in which it would be highly unusual to insist upon SI units - in every country on the planet. And incidentally, it really is highly unusual for astronomers to insist upon metre-based distance measures (whether with SI prefixes or using scientific notation) for very large distances. It would distinctly unusual for any astronomer to prefer metre-based units. The parsec and light-year - neither accepted by SI - are far more common because they actually have some meaning at that scale. The metre does not.

Anyway, this discussion is becoming unproductive, so I do not intend to respond further. Kahastok talk 17:25, 2 October 2014 (UTC)

I respond only so that nobody else is misled by your statements. You have not shown that it is "highly unusual" to use SI in astronomy (the burden of proof you originally took upon yourself), merely that in some circumstances astronomers use certain non-SI units. In my own field of particle physics it is common to measure scattering cross-sections in a non-SI unit, the barn, but it is not uncommon to use square centimetres in standard form, e.g. for instantaneous luminosity measurements. Holding the likes of the parsec or the barn up as evidence that scientists don't really use SI units is just part of the tedious strategy that anti-metric people have been using for decades, and it is no more intellectually honest than quote-mining. The same goes for "kilodays", which is a cheap and unintelligent joke at the expense of the SI, the likes of which you would expect from the British Weights and Measures Association. If you're interested in inconvenient things like facts, the standards relating to the calendar and timekeeping (UTC, ISO 8601, time zones and so on) don't actually have all that much to do with the SI beyond using the experimental definition of the SI second. The guiding principle is that time is experienced and measured very differently from any other physical dimension (because one cannot directly control it, and because the experience of time on Earth is based more on cycles rather than linear measurement), so it does not make sense for even the most ardent SI fundamentalist to abandon the Gregorian calendar in favour of petaseconds since the beginning of the Universe.

It is obviously absurd to suggest that the metre has no meaning beyond a certain cutoff – if that were literally true it would violate important principles of fundamental physics. The metre is not simply a stick of an arbitrary size; it is a distance scale which measures everything from the widths of atoms to the size of the universe. Even your beloved parsecs merely prove this point; they are not more meaningful than the metre at this or any scale, because they are defined with respect to the orbital characteristics of a certain planet and a certain arbitrary measure of angle (to rub salt into the wound, the parsec is defined precisely by the metre via the AU – so apparently it acquires meaning despite being defined in terms of something which is meaningless).

I'm not interested in arguing over who is "deeply stupid", but I will say that just as creationists should not write policies on biology education, anti-metric types who insist that the meaning of such arcane hieroglyphics as "2.75 m" escapes them are not the sort of people who should write policies on units of measurement. One does not allow the lunatics to run the asylum. I also don't care for unsupported armchair speculation about what certain groups of people are able to intuit; if someone wishes to think of 80 km as 8×10⁴ m then there is no obstacle to their doing so. The supposedly-greater proficiency of British people in using imperial units does not seem to manifest itself in, for example, their ability to tell whether one road sign that says "450 yds" is indicating a greater distance than another which says "1⁄3 mile"; if those were replaced with "400 m" and "0.5 km" then even the people who claim not to understand all that newfangled European nonsense would get the idea. Clearly intuition isn't all it's made out to be. Archon 2488 (talk) 18:22, 2 October 2014 (UTC)

I rather took it as read that neither proposal was a practical proposition or worthy of further discussion. I don't know what precisely ProProbly means by "indigenous units" (not least because neither system is purely British in origin), but would note that the whole point of the current rule is to reflect modern usage in the UK. Kahastok talk 17:42, 1 October 2014 (UTC)

It's not just me then, there is no clear-cut answer in the guideline. Common sense would rule out expecting Dewar's own height to be stated primarily in feet and inches, but the height of the statue to be stated in metres.

It isn't even clear to me why the guidelines treat the UK and the US differently. I don't believe that the usage of metric units in UK spoken or written language has ever got close to matching the usage of the traditional imperial units (what I loosely referred to above as the "indigenous units"). Ask 100 people in Glasgow to estimate the height of the statue and at least 80 of them will give their answer in feet. The first page of Google search results all used feet, most used feet only, but one gave "9ft (3m)" (Yelp, Glasgow Sculpture, BBC News 2002, BBC News Scotland 2005, BBC News Scotland 2002, Scottish Government, Undiscovered Scotland, Bella Caledonia). To suggest that "2.75 m" reflects modern British usage misrepresents modern British usage - or is there evidence to the contrary? ProProbly (talk) 22:00, 1 October 2014 (UTC)

This is silly. In most of the world (and this is a global encyclopaedia), feet mean almost nothing to most of the population. Yes, older folk, like me, in my country, Australia, remember them well, but the teenagers I teach have almost no idea. In the UK, feet and metres would both be common, and, I would hope, understood by most people. Similar in Canada I imagine. The USA would be the only major exception. Libya and Burma, the only other countries to have not officially metricated, are less likely to be concerned. So we have around 5% of the wolrd's population who might be confused by metres, and a much higher proportion who will be confused by feet. The answer seems obvious. HiLo48 (talk) 22:06, 1 October 2014 (UTC)

A global encyclopedia you say? No shit Sherlock. How about saying something original instead of just harping on the same Anti-American bullshit you've been preaching for the last half decade.

LOL. What brought you here? Stalking me? You obviously think you know me. This is only the second post ever from that IP address. The other was back in July when someone from that address asked for Association football to be renamed to Soccer because, at that moment in time, the USA had not yet been eliminated from the World Cup. My thoughts an America are irrelevant here. That's why I expressed no opinion on the country in that post. But your behaviour, from someone whose IP address geolocates to Massachusetts, is hardly a great advertisement for the country. HiLo48 (talk) 03:11, 2 October 2014 (UTC)

Those 5% of Americans make up close to 50% of our readership, which puts a different spin on the figures. Brits are another 10-15%. The status quo - reflecting local unit use - generally works. Kahastok talk 17:25, 2 October 2014 (UTC)

Actually, I don't think anyone other than you has argued that the height of a statue in the UK should put anything other than metres first in the general case. Kahastok talk 17:25, 2 October 2014 (UTC)

Possibly not, but I was expecting an evidence supported defence of the current guideline, to help rationalise the apparent anomaly, especially given the weight of evidence I provided to support my belief that no modern British usage would describe the statue primarily in any units but feet. But none seems to be forthcoming. ProProbly (talk) 19:02, 2 October 2014 (UTC)

Gentlemen, since we're nearly down to the level of call each other Nazi's (from which no consensus will ever be reached), may we step back a bit. Measuring the lifetime of the universe and the size of atoms are interesting topics themselves but tangential to the current argument and aren't leading to a consensus - let's keep to the topic of everyday use. Likewise, estimates of intelligence will always be able to find idiots in any system.

Most countries can be clearly labelled as being metric or imperial today. The US is clearly imperial (aka US customary units) and hence US topics use imperial measurements followed by metric units so that the rest of the world can understand them. Most countries (I'll use my home of Australia as an example) have shifted to metric and the current crop of children know nothing else - so topics on these countries are in metric followed by imperial units so the Americans can understand. Notice that so far we have given both types of units so that nobody gets left out while still diplomatically giving precedence to the host country.

But the UK is still in the transition stage going from imperial over to metric. Many of the children will have no intuitive grasp of 'nine feet' and some of the older people will have no intuitive grasp of 2.75 metres. But surely practically all Brits will be capable of understanding '9 ft (2.75 m)' or '2.75 m (9 ft)'. If a particular reader doesn't understand one type of unit then he/she/it can read the unit in brackets. There is no loss of understanding and it's only up to the editor to make sure the article is neatly consistent in being metric first or imperial first. To argue this further is akin to counting how many angels can stand on a pin.  Stepho  talk  01:42, 3 October 2014 (UTC)

For the sake of future newcomers

Can we please have a brief explanation added to the guideline as to why, given that modern British usage still prefers imperial units, the guideline does not recommend imperial units be primary for most British related articles. The reason - I am sure that I am not the only one who finds, or who will find, it illogical and divisive, particularly when the guideline recommends US units for most US related articles.ProProbly (talk) 18:57, 2 October 2014 (UTC)

There is no comparison between metrication in Britain and in the United States. The only example of a metric unit usage that an average American might encounter in daily life is the two-litre bottle of fizzy drink. In Britain, however, metrication is close to complete, other than in certain special contexts, such as personal height, weight, road distances, and speeds. Imperial units are not even taught in schools. Just think of the The Guardian, for instance, which is metric in almost every circumstance. RGloucester — ☎ 19:11, 2 October 2014 (UTC)

The explanation is simple. As RGloucester has pointed out above, metrication has progressed much further in the UK than in the USA. For example, most industries in the UK have used metric units for many years; in the USA most industries still use US customary units. If anything the existing guidelines are too conservative – we're told that milk is normally measured in pints, yet it is not hard to find shelves of milk bottles in metric sizes in British supermarkets. Likewise, it's not hard to find examples of metric units being used for human heights and weights, e.g. here [21] or here [22]. Archon 2488 (talk) 22:54, 2 October 2014 (UTC)

Let's try to understand the background to what we have with respect to the UK. From the comments above, it seems that it must be based on an assumption that the UK is a mostly metric country. This is far from the case. It is true that UK industry largely, if not exclusively, uses metric measures, but that is where it ends. The British public at large have emphatically refused to embrace the metric system in any significant way. If they had not rejected it, how else can we explain the following:

• This BBC article titled "Will British people ever think in metric?" from a couple of years ago which describes "the persistent British preference for imperial over metric". Declaring "All the evidence suggests that, despite more than decade-and-a-half of goods being labelled in both metric and imperial, the British remain defiantly out of step with their counterparts across the channel."
• The EU climbdown over their insistence that the UK adopts the metric system as described in this Guardian article. It describes how "the commission has decided to abandon its attempt to force Britain to adopt the metric system." This is incompatible with the assertion that the UK is already mostly metric as if it was, the EU would not have still been trying to force it to adopt it.
• The UK Metric Association still exists, advertising itself as "an independent, non-party political, single issue organisation which advocates the full adoption of the international metric system ("Système International" - SI) for all official, trade, legal, contractual and other purposes in the United Kingdom as soon as practicable." Thus recognising there is a long way to go yet. They even commissioned YouGov to do a survey, the results of which they published earlier this year. The main conclusion being "Government policy on metrication has failed." i.e. the UK is not yet significantly metricated.

So there we have even more evidence that the UK is NOT yet metricated, to add to the fact that most modern British usage in speech and print is imperial. All we have so far to support the advice given in this guideline are vague and unsupported assertions from a couple of editors, including Archon 2488 whose edits demonstrate his clear bias towards the metric system, that the UK is metricated. You see, that case is still very much unproven. Indeed the opposite, that modern UK usage prefers imperial units, is actually supported by all the evidence brought to the table so far. ProProbly (talk) 22:01, 3 October 2014 (UTC)

Modern Britain favours metric units in some places and imperial units in others, and each person has their own personal preferences. I've provided The Guardian newspaper as one example of a print source that is almost entirely metric, outside of the occasional parenthetical reference to miles. Meanwhile, The Times favours an admixture, and the The Daily Mail favours imperial. RGloucester — ☎ 22:09, 3 October 2014 (UTC)

Newspapers choose the units they use, not based on the preference and practice of the country as a whole, but based on what they think their target audience prefer. That is not a measure of how metric the country is. However, the YouGov/UKMA 2013/14 survey may give a more realistic impression, especially as it was scientifically conducted by a reputable and trusted specialist polling organisation. ProProbly (talk) 22:22, 3 October 2014 (UTC)

We all have lots to do so let's suspend this until the SPI is resolved. EEng (talk) 22:15, 3 October 2014 (UTC)

SPI Filed

I think User:DeFacto needs no introduction here (except when he's using a different name, of course). Comments welcome at Wikipedia:Sockpuppet investigations/DeFacto. Lesser Cartographies (talk) 03:33, 3 October 2014 (UTC)

Pointing out the obvious

Can there be any doubt that the appropriate unit of measure here is the statute mile? EEng (talk) 04:57, 3 October 2014 (UTC) Those inheriting the defective humor gene from both parents may wish to refer to the text in bold below to assist them in interpreting this post, which is known to normal people as a "pun". EEng (talk) 22:13, 3 October 2014 (UTC)

Given that they're apparently as meaningful as metres at this scale, I was going to suggest parsecs. Kahastok talk 17:41, 3 October 2014 (UTC)

Why would you use a parsec to measure a statute statue? EEng (talk) 19:30, 3 October 2014 (UTC)

Reference to the discussion above. I assume you didn't read it? I wouldn't blame you. Kahastok talk 19:48, 3 October 2014 (UTC)

Only skimmed it. I'll get interested when the discussion moves to a British statue of a Roman emperor which gets sent to Mars via an American-built shuttle crewed by Chinese astronauts. Is there some pun on parsecs that I'm missing? EEng (talk) 20:17, 3 October 2014 (UTC)

No - I didn't get your pun I'm afraid. Kahastok talk 20:50, 3 October 2014 (UTC)

I'm sorry. I didn't realize you have a serious disability. Does it hurt much? You hear a lot about things that hurt "only when I laugh" but I guess in your case that's not a problem. :P EEng (talk) 22:13, 3 October 2014 (UTC)

Are you actually trying to go out of your way to be as offensive as possible or is it just an accident? You made a shit pun. It was so shit it wasn't even clear that you were making a pun. You don't like that? Your problem. Kahastok talk 22:33, 3 October 2014 (UTC)

I'm really sorry you were offended. That was not at all my intention. Surely, even if you missed the pun in the first place, once you saw it you should have realized that entire thread was all in fun. Teasing someone about missing the joke is standard practice and nothing you should take offense from, though on rereading now I can kind of imagine how you might have felt insult was intended, if you were having a bad day or something. My apologies.

On one point I must be firm, however. My pun was not "shit". It was brilliant in context. All my friends and admirers say so. EEng (talk) 00:34, 4 October 2014 (UTC)

Temperature ranges, e.g "mid-70s"

Should phrases such as "mid-70s" (i.e. Fahrenheit) be allowed? If so, what is the appropriate way of offering a conversion? Archon 2488 (talk) 22:15, 30 September 2014 (UTC)

It seems pretty sloppy writing for an encyclopaedia. HiLo48 (talk) 22:32, 30 September 2014 (UTC)

The suitability would depend on context, but what would be wrong with writing something like: September 2014 was unusually warm, with daytime temperatures reaching the mid-70s Fahrenheit (low-20s Celsius) for much of the month? ProProbly (talk) 21:17, 1 October 2014 (UTC)

That seems to clash with the existing style guide; the temperature units shouldn't be referred to just as "Fahrenheit" and "Celsius", and in almost all cases they should be represented by symbols. It would probably be better to give it as a range, e.g. 70 to 75 °F (21 to 24 °C) but I don't see that this is explicitly required. Archon 2488 (talk) 23:34, 1 October 2014 (UTC)

Such a conversion introduces a false accuracy. "70 to 75" is a range of round figures. 21 to 24 sounds more precise, when that is not the intention. HiLo48 (talk) 02:55, 2 October 2014 (UTC)

The clash with the existing style guide is easy to fix: September 2014 was unusually warm, with daytime temperatures reaching the mid-70s °F (low-20s °C) for much of the month. ProProbly (talk) 19:16, 2 October 2014 (UTC)

Some history: in December 2013 {{convert}} was switched from using a complex set of small templates to using a complex and large module. The old templates included a method to convert indications of temperature—some predefined ranges were defined and if you wanted one of them, it worked well (for example, "70s °F" converted to "low 20s °C"). When contemplating what the module should do I decided to not implement them because they were not used. Not everything is suitable for a template, and if "mid-70s °F" is desirable in an article, I think any wanted conversion should be done manually. Johnuniq (talk) 07:57, 2 October 2014 (UTC)

Multiple date ranges in a sentence

In the Subaru Baja article, the correct formatting of the model year range has been the subject of several different versions by several editors. The sentence currently reads: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured from 2002 to 2006 by Subaru and marketed for model years 2003 to 2006. But that doesn't appear to be MOS compliant, since there's no from predicate on the second range. The relevant section of the MOS is WP:DATERANGE and as user:OSX pointed out, also at the Dash#Ranges_of_values article. The MOS says "Use a dash, or a word such as from or between, but not both". The dash article elaborates and says "It is also considered poor style (best avoided) to use the en dash in place of the words to or and in phrases that follow the forms from … to … and between … and …".

The previous version read: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured from 2002 to 2006 by Subaru and marketed for model years 2003–06. While this seems to be MOS compliant, it looks a bit incongruous to have one range using the from … to … form and the other using the en dash, but that's what is proscribed by the MOS for a date range where from … to … (or between … and …) are absent.

Perhaps the sentence is better formed as: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured 2002–06 by Subaru and marketed for model years 2003–06. which reads nicely.

Other options are: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured from 2002 to 2006 by Subaru and marketed for model years from 2003 to 2006. which reads awkwardly for the model year range.

Or: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured from 2002 to 2006 by Subaru and marketed for model years between 2003 and 2006. which also reads awkwardly for the model year range.

Those three options all appear to be MOS compliant or is it best to WP:IAR and leave it as is? Any insight, thoughts, or preferences? Perhaps something should be added to WP:DATERANGE that says "multiple date ranges in a sentence should use matching form" or similar... Mojoworker (talk) 18:41, 1 October 2014 (UTC)

The second set of numbers is not really a date range. It refers to the names of models. HiLo48 (talk) 23:19, 2 October 2014 (UTC)

WP:CREEP! Wikipedia editors are not brainless morons who can't figure out good solutions for simple problems. (Well, most of them aren't, anyway...) This is a superb example of what MOS need not (and therefore should not) prescribe. It an obscure situation which will hardly ever come up. There's no urgent need for WP-wide consistency and little danger that large amounts of editor time will be wasted litigating and relitigating this in different articles. Just work out something that looks good with your fellow editors on the Talk page of the article. If and when a pattern of repeated dispute emerges, only then will it be time to consider adding something to MOS. EEng (talk) 04:47, 3 October 2014 (UTC)

"r." for "reigned"

I have noticed that a number of articles (like Jade Peak Pagoda and Reign) use "r." for "reigned". This does indeed seem to be a fairly widespread convention. There is only one instance in WP:DATERANGE that shows a date range for a reigning period and it uses the full word "reigned" rather than the abbreviation. Anyway, I was wondering if it would be a good idea to create Template:Reigned similar to Template:Circa to handle articles that want to use the "r." convention. It took me a moment to recall what "r." means when I recently encountered it so the tooltips the templates provide may be helpful. Jason Quinn (talk) 01:23, 3 October 2014 (UTC)

Use of spaces for grouping digits and screen readers

Inspired by a talk-page conversation with NebY, I've just added some text about how the use of spaces for grouping digits can be problematic for screen reader users such as myself. Any comments or constructive tweaks to the text would be appreciated. This issue used to be mentioned obliquely but my new text mentions this issue more explicitly. Graham87 04:55, 3 October 2014 (UTC)

What is a good separator character that looks reasonable for sighted readers but also helps those of our audience using screen readers? Is there some form of unicode space or comma that screen readers recognise? Or some form of HTML tag that gives the screen reader an alternate way to speak it? If such a thing exists then we can try to incorporate it into our templates.  Stepho  talk  05:48, 3 October 2014 (UTC)

Apart from the templates mentioned in the sentence before the one I added, the only solution I know of that works for screen reader users is the regular comma on a computer keyboard. I'm happy to test out any other symbols, however. Graham87 05:53, 3 October 2014 (UTC)

The convert module copied the technique of {{gaps}}—it uses tricky html to make a visual gap that allows the entire number to be copied without spaces.

• {{convert|12345.6789|m|mm}} → 12,345.6789 metres (12,345,678.9 mm)
• {{convert|12345.6789|m|mm|comma=gaps}} → 12345.6789 metres (12345678.9 mm)

Here is the ugly html for the output number from above:

<span style="white-space: nowrap">12<span style="margin-left: 0.25em">345</span><span style="margin-left: 0.25em">678</span>.9</span>

Some Wikipedias (like nowiki) use &nbsp; as the group separator. Johnuniq (talk) 07:14, 3 October 2014 (UTC)

There is also {{gapnum}}. It's easy to use but it lacks many of the features of {{val}}.

• {{gapnum|12345.6789}} → Template:Gapnum

We could add that regular spaces can break numbers at line ends (for example 12 345.6789) and both regular spaces and non-breaking spaces can cause numbers to arrive as text when pasted into spreadsheets (for example 12 345.6789), but would that make the advice too long? NebY (talk) 08:40, 3 October 2014 (UTC)