Wikipedia talk:Manual of Style/Dates and numbers

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

Microsoft is more important than IBM and Toshiba[edit]

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

For further clarification, according to IBM:

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

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

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

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

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

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

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

MOSNUM history on IEC binary units[edit]

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

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

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

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

The IBM style guide[edit]

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

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

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

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

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

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

Modified proposal ...[edit]

... addressing the comments of Vegaswikian and Jc3s5h

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

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



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

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

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

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

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

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

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

Yep. Why do we insist on taking something that is clear, readable and probably makes sense to all readers and change it? I don't think I participated in the discussion that made the change, but seeing the results, maybe I will if it comes up again. Vegaswikian (talk) 23:45, 23 August 2014 (UTC)
I find 2001-12 slightly ambiguous and 2001-2012 to be clear. I see no advantage to the shorter form except perhaps rarely in tables or infoboxes. I'd support a change to the MOS to specify use of full years. SchreiberBike talk 23:50, 23 August 2014 (UTC)
The OP refers to the "new" style, but MOSNUM has endorsed year ranges such as 2005–09 for ten years ([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 Farmbrough19: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)

Years at beginning of sentences[edit]

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[edit]

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[edit]

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?[edit]

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[edit]

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[edit]

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

Preferred format of section titles?[edit]

1. First, note I'm not talking about how sections appear to the general readers (all of this looks the same there). I'm only talking about how they appear in edit mode.

Now that I noticed how the MoS itself is formatted (first example vs how Talk pages are formatted) I wander is it preferred?:

==General notes==
===<span id="ExternException" />Quotations, titles, etc.===
{{see also|WP:MOSQUOTE}}
Quotations, titles of books and articles,

vs.

==General notes==

===<span id="ExternException" />Quotations, titles, etc.===

Quotations, titles of books and articles,


That is, is a blank line before the general text (after previous section title) NOT preferred? I know the bytes (disk space) do not cost much (but add up..) but mostly I would want the newlines gone for other reasons.. Because then more content lines fit on a page but Talk-page sections are created with newlines (can it be "fixed" as it sets the tone?). [Of course space after a section, before a header are mandatory for clarity.] I try to fix sections to a consistent format within articles but go either way as often either format is used (mostly) and I just fix the few "errors". I do however add newline after a section header with "no text" such as "General notes" for clarity (eg. a hybrid of formattings above)..

2. Another thing, often spaces are added before and after the title itself ("== General notes =="), I at least try to keep either format in an article, but do not like or find the spaces helpful.

3. In cases with * or # I, however, prefer spaces after.. (and what about a newline after the colon):

  • bla bla
  • bla bla bla
  1. first
  2. second

4. [While I'm asking, I've seen "anchor" (also below section title) and now "span id" in section titles, not sure what the latter is or if including is preferred.]

comp.arch (talk) 09:55, 22 September 2014 (UTC)

Edit[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[edit]

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[edit]

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)

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

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)

Temperature ranges, e.g "mid-70s"[edit]

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)