Misplaced Pages

talk:Manual of Style/Dates and numbers: Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages talk:Manual of Style Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 20:35, 2 February 2008 editFnagaton (talk | contribs)3,957 edits →General IT prefix discussion← Previous edit Revision as of 20:56, 2 February 2008 edit undo217.87.122.179 (talk) →General IT prefix discussionNext edit →
Line 699: Line 699:
:::::::I've changed my view upon reflection. The computer industry uses megabytes, Gigabytes, etc, the difference in UK and US definitions of a billion is irrelevant as it is unlikely that billion will be used as a description of the number of bytes.] (]) 20:20, 2 February 2008 (UTC) :::::::I've changed my view upon reflection. The computer industry uses megabytes, Gigabytes, etc, the difference in UK and US definitions of a billion is irrelevant as it is unlikely that billion will be used as a description of the number of bytes.] (]) 20:20, 2 February 2008 (UTC)
:::::::: Indeed, that's what I meant when I said earlier the point put forward "is actually shown to be a red herring". It's like saying "the sky is blue and that proves that I'm right about cell meiosis". ''']]''' 20:35, 2 February 2008 (UTC) :::::::: Indeed, that's what I meant when I said earlier the point put forward "is actually shown to be a red herring". It's like saying "the sky is blue and that proves that I'm right about cell meiosis". ''']]''' 20:35, 2 February 2008 (UTC)

::::::::: No, you didn't mean that. If you read carefully, the term billion was only a part of argument. Calling it a "red herring" makes clear that you assume bad faith, especially your "sky is blue..." blah blah shows that you are interested in facts or any kind of useful discussion. There actually over 120000 Google hits for '"billion bytes" -wikipedia'. I don't know which formula Pyrotec used to determine his assumed probability but I'd think we can all agree that this isn't the right place for speculation about the future. For the record, a billion bytes is in US-American English equivalent to a gigabyte, that's why it's already in use. I was talking about Terabyte (tera means 10^12) which is less common for now and which has no well-known -illion equivalent. So it'd be called 1000 billion or a million million but nobody knows what's the marketing industry is going to establish. Nonetheless "billion bytes" is actually used despite the assumed low probability.


== A duty of disambiguation == == A duty of disambiguation ==

Revision as of 20:56, 2 February 2008

Archiving icon
Archives
General Binary prefixes Years and dates See also

editArchive
Years and dates archives


Grouping of digits after the decimal point

See also Misplaced Pages talk:Manual of Style (dates and numbers)/Archive 87#Spacing after the decimal point

An issue has arisen in Meter. User:Greg L has quite rightly edited the article so that instead of using a mixture of styles, it now uses commas to group large numbers into groups of 3 digits. However, there is still inconsistency in dealing with digits to the right of the decimal point. One example is:

Consequently, a practical realisation of the metre is usually delineated (not defined) today in labs as 1,579,800.762 042(33) wavelengths of helium-neon laser light in a vacuum.

Another example is "0.03937 inch".

I believe the Chicago Manual of Style says to not use spaces, commas, or anything other grouping symbol to the right of the decimal point, but as far as I can see, Misplaced Pages's MOS does not address this. So what should we do? --Gerry Ashton (talk) 19:43, 15 December 2007 (UTC)

The issue of how to deal with the spacing of digits after the decimal point has arisen before. Some advocated leaving spaces every three digits and some leaving no spaces. No consensus was reached, which is why there is no guidance in the MOSNUM. Your views on that discussion are welcome. Thunderbird2 (talk) 20:22, 15 December 2007 (UTC)
My view isn't of much practical value. My view is that Bill Gates and his cronies should, in the early days of Windows, specified keyboards and software that would allow us to write SI measurements without having a PhD in computer science, which means non-breaking thin spaces, °, μ, and Ω right on the keyboard. Also, all software that accepts numbers should accept them with the agreed-upon digit grouping mark embedded.
I also believe that without grouping symbols, numbers are very difficult to read. If we can't agree to mix commas and spaces, we should only use spaces and forget about commas. --Gerry Ashton (talk) 21:26, 15 December 2007 (UTC)
Your second point sounds practical enough. I think it is important to avoid long unbroken lists of digits after the point. I see nothing wrong with mixing commas and spaces, if that's what it takes. Thunderbird2 (talk) 21:53, 15 December 2007 (UTC)
  • Advocating that Misplaced Pages abolish the use of commas to delimit digits in the mantissa would be about as successful as the BIPM trying to abolish the hour, ppm, and percent because they aren’t “part of the SI”: ‘p*ssing in the wind’. We will make better progress if we can focus our efforts on the proper treatment of digits to the right of the decimal point. Greg L (my talk) 00:49, 16 December 2007 (UTC)

Grouping of digits: Specific proposal (obsolete)

Resolved – Replaced by newer proposal below.
  • I would like to weigh in on this issue with this proposal: The overriding principal of the SI with regard to technical writing and general written communications is to unambiguously and easily communicate in a language-independent fashion using internationally and well-recognized units, symbols, and style. For instance, even though percent and its symbol (%) are not formally part of the SI, it is recognized by the BIPM and ISO for use with the SI because it is widely recognized and simplifies communications.

    There are currently two practices for delimiting numbers in the mantissa: spaces, and commas. It’s currently a free-for-all in the decimal place and only two practices are observed: 1) delimiting with a space, or 2) no delimiting whatsoever. Clearly, long chains of decimals in a row are extremely hard to parse and demand to be delimited. Trying to get all contributors to provide spaces in the decimal portion of numbers would be difficult but I would hope that official Misplaced Pages policy would be that the preferred method of numeric notation to the right of the decimal place is to delimit every three digits with non-breaking spaces {exceptions would be 1) where the last group consists of four digits and 2) where a group of five digits is delimited so the last group comprises two digits}. Further, I would propose that Wikipeida would recognize that the best practice is to permit the use of reduced-size non-breaking spaces (i.e. <font size="-1">&nbsp;</font>), which is an SI-compliant form that observes best typography practices. Examples:

    Best typography practices:

    3.141 592 6535 and 1,579,800.762 04

    Acceptable delimiting:

    3.141 592 6535 and 1,579,800.762 04

    Further of course, the Euro practice of delimiting the mantissa with non-breaking spaces (preferably reduced-size ones) would also be acceptable.

    Clearly, my proposal also holds that practices like “1.414213562373095” should be strongly discouraged or prohibited.

    Greg L (my talk) 21:53, 15 December 2007 (UTC)

Grouping of digits: Discussion

A minor objection: if someone cuts and pastes a number from Misplaced Pages (the normal article view, not the view seen when editing an article) to some computer program, there is a small chance the program will parse it properly if it use just commas or just spaces. If it has a mix, the chance of success goes from small to no chance at all. But people probably don't do that often enough to worry about it. --Gerry Ashton (talk) 22:18, 15 December 2007 (UTC)
  • Well that was an interesting point Gerry, so I checked it out and you’re right at all levels IMO. And as you further seemed to suggest, that’s not a deal breaker preventing consideration of the above proposal. “Chance” shouldn’t factor heavily into this consideration; effectively the only applications that could be impacted under this proposal are those that must “understand” numeric values. Today, that means Excel in the majority of cases. I entered the following values here in edit view, did a Show preview, and copied and pasted the following into Excel:

    1,579,800

    1,579,800.762045

    1,579,800.762 045

    1 579 800

    1 579 800.762

    1 579 800.762 045

    1 579 800.762045

    All the spaces are narrow, non-breaking ones coded as <font size="-1">&nbsp;</font>. Excel only treats the top two entries as numeric values. To see for yourself, just copy all seven entries, select a single cell in Excel, paste, and set up the adjacent column to multiply the pasted values by 2. Excel reports #VALUE! for the bottom five; Excel doesn’t care whether the spaces are regular, full-size spaces or these narrow, non-breaking ones. As you can see though, all the entries using Euro-style delimiting (spaces) in the mantissa (the bottom four entries) already aren’t compatible with Excel.

    I think it is clear that the readability benefits of delimiting to the right of the decimal point far outweighs this minor inconvenience. I’ve long edited all my articles this way and have had many occasions to copy the values to Excel. It’s easy enough to hand-delete the spaces after pasting; this paste/edit method best ensures accuracy. Too, I agree with your final conclusion: “people probably don't do that often enough to worry about it.” Note further that the only entries above that would become non-compliant under my proposal are the second one down and the last one (as well as this abomination: 1.414213562373095). Greg L (my talk) 00:27, 16 December 2007 (UTC)

I disagree. Most users have little interest in what the digits are at all. Those who do need the actual value are more likely to cut and past into a program like Excel than they are to write the digits down on paper. Removing any interfering spaces is error prone. It's too easy to accidently delete a digit in the process. This is a situation where Chicago and Redmond agree (no spaces to the right of the decimal point). That's a strong enough precedent for us to follow.--agr (talk) 03:19, 18 December 2007 (UTC)
I second what Agr writes ... which is pretty much what I said last time this came up. I prefer the look of thin spaces either side of the decimal point but the ability to copy and paste into a program like Excel trumps this in my book. Moreover, {{formatnum:}} (used extensively by templates) gives commas before the decimal point and no delimination afterwards, we should keep consistant with this. Jɪmp 08:14, 18 December 2007 (UTC)
I support the proposal. Readability results in fidelity because it allows editors to check the numbers. There is no point in facilitating a copy-pasting feature if we cannot check the numbers that are being copy-pasted. Therefore readability should come before pasteability. Thunderbird2 (talk) 09:19, 18 December 2007 (UTC)
I think needs of readers trump needs of editors. And I dare say most of the articles that contain very long decimal expansions are already written, and any change in format runs the risk of introducing new errors.--agr (talk) 10:56, 18 December 2007 (UTC)
Yes, readers' needs trump those of editors, which is why I support the proposal. The proposal facilitates a) readability and b) fidelity. Thunderbird2 (talk) 12:16, 18 December 2007 (UTC)
We can often check numbers by copying and pasting them. Talk readability but who actually reads "one point four one four two one three five six two three seven three zero nine five"? Jɪmp 15:16, 18 December 2007 (UTC)
re We can often check numbers by copying and pasting them. I doubt this practice is widespread, but if it is that would shift my position. Do you know any editors who check numerical values in this way? Thunderbird2 (talk) 15:30, 18 December 2007 (UTC)
Besides myself, no, but I can't say I know of any editors' checking numbers any other way. Do you? Nor is it only a question of checking numbers but also of using them. What of the point about conistancy with the autoformatting function inbuilt in the software? Jɪmp 16:10, 18 December 2007 (UTC)
Sorry Jimp, I didn't deliberately ignore that part. I do think that consistency is important, but I didn't understand the wiki code. Could you explain the point in plain English for me? Thunderbird2 (talk) 17:18, 18 December 2007 (UTC)
It's a "magic word" which turns an unformatted number into a formatted one, e.g. {{formatnum:123456.789012}} gives you 123,456.789012. The formatting it uses is commas before and nothing after the decimal point. Unless we also use this elsewhere we'll end up with inconsistancy. Jɪmp 19:39, 18 December 2007 (UTC)
Ah, I see your point now. But, assuming that we can agree here on how we want the numbers to look (whether ungrouped, groups of 3 or other exotic grouping), can't the code be adjusted to do just that? Thunderbird2 (talk) 22:32, 18 December 2007 (UTC)

Proposed alternative: <span style="margin-left:0.2em"> 1.234567890. requires 39 characters per group as compared to 21 for a small nbsp. And commas could be used to the left of the decimal point, so it'd only be needed when there are large numbers of digits to the right.—Random832 16:26, 18 December 2007 (UTC)

However, personally I would support not using any spaces at all, with or without commas to the left of the decimal point. —Random832 16:30, 18 December 2007 (UTC)
I'd also point out that we are not talking about a huge number of articles here. There's Category:Mathematical constants and Category:Fundamental constants and maybe some fundamental SI defs. Some of these articles follow the suggestion above, others group by five digits (which has the advantage of making the numbers to the right of the decimal point look different from those to the left) and some do not group at all, particularly when 10 digits or less. Almost all are very stable articles. At the very least, any proposed standards should be brought to the attention of the Math and Physics projects, though I think energies are best directed elsewhere.--agr (talk) 16:58, 18 December 2007 (UTC)

Part of this discussion is whether anyone actually reads all those digits to the right of the decimal. While I seldom read them, I sometimes count how many there are, so I can understand what the precision of the number is. Grouping helps with this. --Gerry Ashton (talk) 19:56, 18 December 2007 (UTC)

  • All: Please examine the following example (from Kilogram):
The straightforward adjustment to this approach advanced by the group would instead define the kilogram as “the mass equal to 84,446,890 × 83⅓ atoms of carbon-12.” This proposed value for the Avogadro constant falls neatly within the measured value (≅6.02214184 × 10 vs. the 2006 CODATA value of 6.02214179(30) × 10) and the proposed definition of the kilogram produces an integer number of atoms in 12 grams of carbon-12, but not for 1 gram nor 1 kilogram.
The above is a classic example where a numeric value isn’t just barfed out onto a page just to demonstrate that someone did some amazing work to a precision of one part in six million, sometimes numbers must be understood (not memorized), and expressed in a way that allows them to be easily parsed. Why would someone make the claim that delimiting is only important for parsing digits to the left of the decimal point and isn’t needed to the right?
In my opinion, the only valid reason remaining for treating digits to the right of the decimal point differently (i.e. not delimiting) is when it comes to copying the values into Excel. It’s easy enough to copy into Excel and delete the spaces. I would think the readability advantages for all readers all the time more than makes up for the minor inconvenience for some of the readers some of the time of having to delete the extra spaces from copied values. This common-sense reality is why the European SI writing style delimits on both sides.
I would love to see {{formatnum:141421.35623731}} modified so it automatically generates 141,421.35623731 and further, I would hope that the template would support the expression of uncertainty in ‘concise form’ (the parenthetical suffix digits). By the way, I used “0.3em” here, which I think is easier to read. Greg L (my talk) 20:50, 19 December 2007 (UTC)

Grouping of digits: New specific proposal using {{formatnum}}

UPDATE: Well, that was an interesting experiment. Jɪmp’s mentioning of span control (a feature I didn’t know about) offers a huge advantage. Please see preceding post from me for context. When numbers like this: 141,421.35623731

…are created simply by controlling pair kerning using “em”-based span control like this: 141,421.356<span style="margin-left:0.3em">237<span style="margin-left:0.3em">31

…you can paste the displayed values into Exel. This strikes me as a win/win. I would propose that the {{formatnum}} template be modified to generate ‘Excel-pasteable’ numbers like this, and further, that the template supports concise notation for uncertainties.

I’ve already updated Kilogram with span-controlled numbers. To see examples, examine the article starting here. As you will see, it will be a rare number indeed that simultaneously requires delimiting in both its mantissa and its decimal side. Values with expansive decimal sections requiring delimiting rarely have mantissas greater than three or four digits. In other words, a template that functions as I am proposing here would typically be used to generate values that are an “either/or” proposition: for any given value, the expansive portion requiring delimiting will usually only be found on one side of the decimal point.

I would specifically propose that {{formatnum:60451.02214179}} would return 60,451.02214179

…and variations of {{formatnum:6.0221417912}} would further generate the following values:
6.02214179
6.022141791
6.0221417912
6.02214179123

Further, I would propose that {{formatnum:6.02214179|30}} would return 6.02214179(30)

Go ahead, copy all four of the above maroon-colored values and paste them into Excel; works great.

Greg L (my talk) 22:30, 19 December 2007 (UTC)

  • Strong oppose: This weird spacing thing is only favored by mathematicians, and even then only some of them. It is not understood by most readers, and is not an appropriate usage in an general-purpose encyclopedia. Also, the code you provided is invalid. <span> must have a </span> or it must be <span ... /> And <br> should be <br /> (yes, I'm aware that the MediaWiki software is smart enough to compensate for the latter type of error, but this is no reason to use deprecated markup; our code, like our facts, ought to be exemplary. Speaking of which, it is also best to terminate CSS directives with ";", since others may be added later in which case they must be semicolon-separated: style="margin-left:0.3em;"— SMcCandlish ‹(-¿-)› 01:11, 20 December 2007 (UTC)
  • Clarification: If consensus actually comes out in favor of this spacing, I have to agree with Greg L that doing it with CSS to make the numbers copy-pastable is the way to do it, and with Jimp that the spacing should be thin, i.e. 0.2em. I still oppose this, however. — SMcCandlish ‹(-¿-)› 04:15, 20 December 2007 (UTC)
Yes, if this is adopted (and I think general readers will quail at it), the thin spaces are essential. The thinner the better. Tony (talk) 01:33, 28 December 2007 (UTC)
(Inserted mid-stream)
  • Very well, let’s examine both 0.2-em and 0.3-em spaces side-by-side. My first impression was that 0.2 em was nearly too small to be effective at its job of delimiting. So here are both styles juxtaposed next to each other:
0.2 em:
6.02241679
6.022416794
6.0224167942
6.02241679423

0.3 em:
6.02241679
6.022416794
6.0224167942
6.02241679423
Well… (let me go up and look at that again…) (*crickets chirping*) … It still appears to me that 0.2 em is too subtle. These examples are slightly different from earlier examples. I changed the above examples to omit the digit “1” next to a narrow space beause “1” uniquely gives itself some extra space. What remains here shows how most numeric strings would look. I think you will agree that without the help of the magic “1”, 0.2 em is too narrow. Maybe it’s a platform/OS thing. At least on my Mac, the 0.2-em option produces spaces that are nearly too narrow to be noticed. But if the consensus of everyone else here is that 0.2 em works and looks better, then I would accede to the group consensus. Greg L (my talk) 19:20, 20 December 2007 (UTC)
Think again, my friend. I did check 0.2 em (as well as 0.1 em) & compare it to 0.3 em before making the suggestion. A platform/OS thing ... could be. I put it to you that nearly too narrow to be noticed is far better than so wide as to be mistaken for an ordinary space and thereby making the groups of digits appear to be seperate numbers. Jɪmp 00:33, 21 December 2007 (UTC)
Show above is 0.2-em vs. 0.3-em spacing as seen in Safari under Mac OS X v10.3
  • Jimp, I don’t know why you would use seemingly charged wording such as “think again my friend”. I’m uncertain as to the tone you intended but wording like that comes across as if you think you are the only one capable of astute observations and rational thought. You must know that font handling is done far differently on different computer platforms and, even on the same platform, within different browsers. This alone might explain the difference in opinion. The purpose of my heading down this path of mentioning I’m on a Mac is it seems to me that 0.2-em spacing is too narrow. That you see the facts differently can be explained either as a difference of opinion or a difference in appearance between your computer and mine. Shown at right is what I’m seeing in the above comparison right now.

    So now the question to all of the rest of you (Jimp too) becomes: does the 0.2-em spacing shown in the picture at right match what you see?

    As for you Jimp, I just checked out your answer below. It seems I’ve accidentally gotten your hackles up and you’ve gotten steamed. I no longer appreciate your tone (it’s uncivil) and no longer care to participate here whatsoever. Goodby. Greg L (my talk) 02:29, 21 December 2007 (UTC)

I didn't intend any uncivility. Those were just words, poorly chosen but uncharged (or at least not intentionally). Sorry to have come off as I have. I don't think I'm the only one capable of astute observations and rational thought ... I'm begining to wonder whether I even am one of those so capable considering how badly I've managed to express myself. You haven't got any of my hackles up. Different systems, yeah, this could explain it. But those 0.3 em spaces in the picture still seem quite wide to me and the 0.2 em seem just right. It would perhaps also help to show us a bit of ordinary text with ordinary spaces for comparision's sake. Sorry again, Greg. Jimp 04:12, 21 December 2007

Jimp, apology accepted. Now let’s ‘get dirty’ in the technical details. Shown below are various ways of delimiting the remainder. To the right is how it appears on my system.

Show above is how various spacings appear in Safari under Mac OS X v10.3.9. I added the vertical rule to help discern the relative width of the numeric strings.


0.1 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

0.2 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

0.25 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

0.3 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

&nbsp;

6.022 416 79
6.022 416 794
6.022 416 7942
6.022 416 794 23

0.4 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

Shown above is how
delimiting appears with
live text on your
system.

As you can see, my system (at least) does not treat 0.25 em different from 0.3 em. Also on my system, 0.3 em is about midway between 0.2 em and a non-breaking space. How does this all appear on your systems? A subjective but simple way to communicate the appearance on your system is just to declare whether or not the text-based version (on the left) appears similar to the photo on the right. To my eye, the 0.2-em option on the right (what I see) seems too crowded; that is, the delimiting is hard to discern. Greg L (my talk) 06:08, 21 December 2007 (UTC)





  • Strong support: Readers have no problem understanding what they’re looking at when they see delimiting in the decimal portion. It’s been that way for years on a number of Misplaced Pages’s technical articles and even novice readers haven’t done a single one of their “drive-by shootings” to change values to a non-delimited style. And for good reason: it’s obvious what they’re looking at. It does’t matter what technical means is used within Misplaced Pages to make the template work; if there is a way to do it so values can be posted into Excel and still be numeric quantities, then that’s clearly the way to go. We also don’t have to modify an existing template; a new one could be made. Too, no one has to use the template. It would simply be available for articles that could really use it. Greg L (my talk) 01:22, 20 December 2007 (UTC)
  • Strong oppose: As per SMcCandlish, to the vast majority of Misplaced Pages readers, whitespace separates numbers from the things around them, it doesn't group digits. I can't believe we're discussing the supposed-goodness of embedded space in numbers and the supposed-evil of ISO-8601 dates in citations on this page at the same time. Shouldn't Scotty be warning us about mixing matter and anti-matter right about now? RossPatterson (talk) 02:13, 20 December 2007 (UTC)
  • Second choice: Various publications that have to deal with many digits to the right of the decimal have adopted a variety of ways to deal with it. I suggest that people are used to the idea of long strings of digits usually being grouped in some way, and are accustomed to having to figure out what each publication is up to. I would prefer to use only narrow spaces, but comas to the left and spaces to the right would be my second choice. --Gerry Ashton (talk) 02:21, 20 December 2007 (UTC)
  • Comment: I favour this weird spacing (I suppose this therefore makes me a mathematician). Actually, what I favour is the full SI style with digits grouped into threes delimited by thin spaces either side of the decimal point (i.e. no commas) ... what Gerry said. This <span style="margin-left:0.3em;"> is a perfect solution to the copy-&-pastability problem, note also that these spaces are non-breaking (an essential feature).
    I would, however, suggest that 0.2em be used instead of 0.3em: it's thin spaces rather than ordinary ones which we want, i.e. spaces a fifth (or a sixth) of an em wide (according to Space (punctuation)#Table of spaces). As Ross notes above, "whitespace separates numbers from the things around them": ordinary width spaces are too thick, we need a different space (a thinner one) if we're to use it to group digits.
    One question, though, does <span style="margin-left:0.3em;"> display correctly in common browsers? This is the consideration is that killed the use of &thinsp;. If this is to be implimented I would suggest, for consistency, that {{formatnum:}} be modified rather than have {{formatnum-therival:}} created.
    I'd support an across-the-board adoption of SI spacing ... if only it had a snowflake's chance in Hell of gaining consensus. To me it's all or nothing: all numbers (when written as decimals) should conform to one standard format. Commas before & nothing after is the standard in place. Adoption of a new standard; i.e. commas-then-thin-spaces or, better still, thin-spaces-then-thin-spaces; has my thumbs up (for what that's worth) iff (yeah, I s'pose I must be a mathematician) it's applied to everything.
    Are we going to get everyone on board? Commas-then-nothing is common practice in English. It seems to me next to impossible to change this flow & get all editors to use a new standard ... and use it via the revised {{formatnum:}} (or whatever other thing we pull out of our hat) for fat breaking non-copy-&-pasteable spaces are not what we want. Jɪmp 02:45, 20 December 2007 (UTC)
SI is clearly a wonderful thing, and it is so because it doesn’t unnecessarily push the “Euro” way of doing things over the “U.S.” way, nor visa versa. The SI acknowledges and embraces practical reality. “Full SI writing style” recognizes delimiting via either commas or narrow spaces in the mantissa because that’s the reality of the American style of delimiting numbers. Like it or not, there’s simply no fighting it; that style is extraordinarily common and well entrenched—both in print and on the Web. Misplaced Pages—like the BIPM and their SI—can’t find itself in the position of trying to promote change in the way the world works by pretending to adopt a single style of numeric notation that isn’t well recognized in the U.S. The whole point of encyclopedias is to unambiguously and clearly communicate. Intuitively easy, familiar writing customs must be observed. There is no “right” or “wrong” with regard to commas or narrow spaces in the mantissa—not according to SI and not according to common sense simply because the English-language version of Misplaced Pages is read by readers in both Europe as well as the U.S. Accordingly, Misplaced Pages (and in the SI) recognizes both methods.

We don’t have to agree that Misplaced Pages should adopt one style or the other with regard to delimiting the mantissa…nor should we. We can simply make two versions of a numbering template (or an option to check in a single template). Trying to necessarily link the treatment of the decimal portion to how we delimit the mantissa will only doom to failure any efforts here. We should address only one issue: should a template be made to make it easier to delimit the decimal portions to make long strings easier to read(?). My point would be that narrow spaces are so damn easy to read, that even a novice who has never seen it before instantly understands what it’s all about. And in articles where numbers are important, delimiting is crucial because long strings of non-delimited digits to the right of the decimal point unusable to the point of being barbaric. There should be an easy way for others to do so (rather than hand-coding it all). Greg L (my talk) 03:59, 20 December 2007 (UTC)

Somehow I'd got it into my head that SI suggested thin spaces either side ... I could be wrong. You write "narrow spaces are so damn easy to read, that even a novice who has never seen it before instantly understands what it’s all about." I agree (as long as the spaces are thin).
You mention Europe but this is the English Misplaced Pages, what they do on the European mainland is not our concern, what do we Americans, Canadians, Irish, British, New Zealanders, Australians, ... do? Of course there is no right or wrong but there is standard practice in English ... which, for better or worse (yeah, I agree, worse), is commas-then-nothing (either side of either pond, as far as I'm aware).
No, we don't have to agree on what's done before the decimal point but I'm not keen on the idea that we should just leave that issue aside. In my book these are one and the same issue. Consistency is what we should strive for. There should, I say, be one standard format and therefore one {{formatnum:}} which produces it with no optional formatting (note also that this is {{formatnum:}} not {{formatnum}} ... a "magic word" no template ... ordinary folk like us can't edit it). If "Trying to necessarily link the treatment of the decimal portion to how we delimit the mantissa will only doom to failure any efforts here.", so be it. Jɪmp 04:54, 20 December 2007 (UTC)
(Inserted mid-stream)
  • Jimp, the notion that the English-language version of Misplaced Pages is an “American thing” and therefore follows American conventions is a common misperception that editors get corrected on soon enough with their first edit war of the subject. The subject is covered in Misplaced Pages: Manual of Style: Disputes over style issues. Canada, New Zealand, Australia, the UK, and Western Europe (wherein the English language is widely spoken and serves as the “Universal Translator” bridging the different languages) all use British English. Word has, it the English invented the English language so Misplaced Pages officially allows articles to be written per British English to serve these English-speaking countries. There are a variety of differences between British and American English. Near-parenthetical asides and clauses—like this clause—are set open with spaces on both sides of the em-dash in British English. “Realize” is spelled “realise”, the decimal point is a comma and numbers are delimited with spaces. Accordingly, the “Energy” content on a food’s nutrition label is 85,3 calories. Yes, they express the energy content to greater precision than in America. And as you can see, they can't use commas to delimit the mantissa because the comma serves as the decimal marker in British English.

    Misplaced Pages policy (and the every-day practices here on all of Misplaced Pages’s articles) is clear: Both European (British) English and American English are recognized as correct. The hat is tipped to one way or another based mainly on two criteria: 1) The style the first major contributor to an article used becomes the standard for that article, and 2) if the subject is about a country or subject that is closely attached to a particular country, then that country’s spelling, punctuation, and formatting conventions would be observed. If you don’t believe me, check out Metre / Meter and note that it uses British English throughout. Go try and “correct” realise to realize. May God be with you. ;-)

    Note further that Misplaced Pages’s supposed even-handed policy regarding national conventions isn’t as even handed as it seems; Misplaced Pages has standardized on using a full-stop (.) as a decimal point. Europeans readily adapt to reading the style used in their countries and to reading the American style, which is heavily represented in print, the Web, and (especially) in scientific literature. So…

    Americans are already getting their way with the decimal point. Further, most Misplaced Pages articles use commas to delimit the mantissa. It’s the well recognized American way of doing things that Europeans readily recognize and accept. This leaves only the issue of delimiting the decimal side of things. It’s a straightforward solution.

    If, as you say, there should be one format, then IMO, it should be comma-delimited mantissa|full-stop decimal separator|narrow space-delmited remainder. That is the closest to a universal method that one can obtain. Although highly biased towards American conventions, Europeans are quite flexible because they speak multiple languages and are familiar with entirely different formatting styles.

    Lest I seem biased towards the American-way of doing things, I’m not. I just realize that there is no fighting the ever-expanding method of American writing style. I’ve worked with a Swedish-American engineer. He was bragging to a Swedish friend of his who was visiting. The engineer told him he had presented a scientific paper at an English-speaking conference. “Wow” said his friend. And he had done it in American English. “Wow” said his friend. Personally, I do all my design in metric (it’s the only way to go) and only do final conversion to inches etc. when the prints go to a machine shop. There are a variety of European conventions I like. My wife and I visited a number of European countries this summer. The ground floor on elevators are level “0” (zero). The floors above are 1, 2, etc. The first level below (the top-most) basement is -1, then -2 etc. How logical is that? My main point is that I don’t want to come across as biased for advocating an American way of doing things.

    Trying to format numbers in a European way would baffle Americans. Conversely, the American way of formatting numbers is readily accepted by other English-speaking countries simply because they are more sophisticated than Americans (don’t bother whining to me about that statement; it’s true). So it’s a simple solution: comma-delimiting of mantissas, ful-stop decimal marker, and narrow spaces for the remainder. That’s what will work best given what reality has thrown us. Greg L (my talk) 19:20, 20 December 2007 (UTC)

"the notion that the English-language ... Misplaced Pages is an “American thing” and therefore follows American conventions is a common misperception that editors get corrected on soon enough ..." Absolutely, I've been known to do such correction. "Canada, New Zealand, Australia, the UK, and Western Europe ... all use British English." ... Yeah, try tell that to an Aussie ... oh, you are ... no we don't. Australians use Australian English, Canadians use Canadian English, etc. How many Aussies, Canadians and Kiwis do you hear talking lorries and aubergines? So in British English "... the decimal point is a comma ..." I don't believe you're right there and I'd be willing to put money on it ... a lot of money. However, supposing you are right ... there's further proof that British English is different from Australian English 'cause you never see that in Austrlia (except on stuff from Europe ... mainland Europe). Misplaced Pages policy ... Misplaced Pages policy is somewhat more sophisticated than "both American and European English are okay" ... no the authors of this policy realise (yeah, that's how I spell it too) that there are more tahn two dialects of the language. Check Metre out ... Greg, are you still talking to me? 'cause, look at the history of Metre: I've edited twice this month. "Trying to format numbers in a European way would baffle Americans." Australians too ... all English speakers I believe. Yes, if any god exist, may he be with you too. Jɪmp 00:33, 21 December 2007 (UTC)
Err, no. The use of the comma as the decimal delimiter is a feature of various European languages such as French and German. In the English language the decimal delimiter is always a full stop, whatever version of English is being used. If you see a figure in an article in the English Misplaced Pages which uses a comma as the decimal delimiter and full stops to denote thousands, millions, etc., then it is an error which should be corrected immediately. -- Arwel (talk) 23:37, 23 December 2007 (UTC)
Thin space digit grouping is not part of SI; the official brochure that describes it says nothing about how to group digits, but it does use the thin space. I believe it is one of the ISO standards that specifies the thin spaces. reprints Resolution 7 of the 9th CGPM, 1948, "Writing and printing of unit symbols and of numbers" on pages 41 and 42 which states "In numbers, the comma (French practice) or the dot (British practice) is used only to separate the integral part of numbers from the decimal part. Numbers may be divided in groups of three in order to facilitate reading; neither dots nor commas are ever inserted in the spaces between groups."
An example of a predominantly American organization that uses thin spaces in its publications is the IEEE. --Gerry Ashton (talk) 05:35, 20 December 2007 (UTC), revised 19:40, 20 December 2007 (UTC)
(Inserted mid-stream)
The BIPM, at Rules and style conventions for expressing values of quantities; 5.3.4 Formatting numbers, and the decimal marker takes the formal position that the decimal marker “shall be either” the full-stop or comma. It also says digits may be grouped by a thin space but not by commas or full-stops. Here’s where reality diverges from resolutions of the BIPM. The percent and its symbol (%) are not part of the SI but the BIPM and ISO “recognize” or “acknowledge” its use with the SI because it is internationally well recognized. The same goes for the hour and minute; only the second is the SI unit of time but the BIPM recognizes the use of the other units of time because they are well recognized. The subtext of this is the BIPM knew they would be fighting a loosing battle if they tried to get the world to use a decimal-based time system. I can’t find it at the moment, but I’m quite sure the BIPM does the same with “acknowledging” the use of commas to delimit the mantissa. If they don’t, they clearly should. The simple reality is that no matter what the hell happens here in our little island within Misplaced Pages, we won’t be changing the way Americans write their mantissas or expect to see them in writting in an encyclopedia. The American style of delimiting with commas is recognized throughout the world and isn’t going away. Greg L (my talk) 19:20, 20 December 2007 (UTC)
Gerry Ashton is absolutely correct. (He shouldn't have struck out his comments, assuming without checking that he is the one who did so; if he didn't do so and someone else did it that is entirely inappropriate.) The "thin" adjective in the latest version of the BIPM brochure is an addition by the BIPM that is not supported by any decision of the CGPM or CIPM. It is a new addition in the 2006 brochure; the prior version merely said "Numbers may be divided in groups of three in order to facilitate reading; neither dots nor commas are ever inserted in the spaces between groups." It likely comes from the ISO, though an exact quote from an ISO standard would be appropriate here. Gene Nygaard (talk) 14:28, 28 December 2007 (UTC)
Note that that BIPM even couches their statement of the rule in legalese, using the terminology "Following" with respect to the 2003 CGPM resolution as an indication that it "is not contrary to" those resolution, even though not everything in the BIPM statement is supported by that resolution. The 2003 resolution deals primarily with the decimal point, and merely quotes the 1948 resolution when it 'reaffirms that "Numbers may be divided in groups of three in order to facilitate reading; neither dots nor commas are ever inserted in the spaces between groups", as stated in Resolution 7 of the 9th CGPM, 1948.' No mention of "thin" spaces. Gene Nygaard (talk) 14:45, 28 December 2007 (UTC)
Here's why I'd got that idea into my head. On another note: suppose {{formatnum:}} could be tweaked such that the user could go to his/her "preferences" and choose his/her number formatting scheme. The defualt would remain commas-point-nothing but there'd be the option of commas-point-spaces or spaces-point-spaces (or some other option, perhaps). Then we'd have the best of both worlds. Of course, it would be up to the developers to impliment such a thing ... and considering how promptly they're dealing with the disentanglement of date autoformatting and linking, let's not get our hopes up. Jɪmp 06:19, 20 December 2007 (UTC)
This should use a class rather than inline CSS - so that a user can override it in their monobook.css. —Random832 13:29, 20 December 2007 (UTC)
I still support the proposal. Thunderbird2 (talk) 09:12, 25 December 2007 (UTC)
Strong oppose. But really, this section is a total disgrace. How can anyone even work out what precise proposal is currently being considered? You'll never achieve a consensus that commands respect if you don't, as initiators and major contributors to such a discussion, keep it orderly and understandable.
Nevertheless, the proposal appears to be for some kind of spacing between groups of digits after the decimal point. I'm against that for a few reasons. The main one: it should not even be considered until other more fundamental issues are settled. Everyone's so busy pushing particular detailed proposals, and very few editors are giving sustained attention to structural, procedural, and broader substantive matters for WP:MOS and its satellite pages. But without such effort, these innumerable smaller issues will never be reliably settled. Small factions of editors will wrestle energetically in various corners until they get bored or tired; others will either know nothing about the issue they address, or look the other way in dismay, or completely fail to grasp the issue in a forest of ill-managed verbiage. Who here, apart from SMcCandlish, has so much as glanced at the hard-space issue, raised at WT:MOS and now with its own dedicated discussion page that I have set up? Yet memorable, understandable, typable markup for the hard space is a blindingly obvious requisite for well-formatted text in Misplaced Pages – especially for numeric and scientific formatting such as this section addresses. Let's get issues into some sort of order of priority, rather than just plunging forward. What we imagine is forward, that is.
– Noetica Talk 04:42, 27 December 2007 (UTC)
Well Noetica, your response is awfully damned amusing since you voted “Strong oppose” and then, given that you wrote “the proposal appears to be for some kind of spacing between groups of digits”, you professed to not really understand what exactly the proposal is that you voted on! Your confusion is doubly amusing given that the first five paragraphs that started this subsection clearly laid out the proposal and the virtues it offers; the rest was just voting and debate on implementation of the details. You should read more before being so anxious to play the role of den mother and admonish others for not being as logical and organized as you pretend to be. The above mishmash (everything that occurred after the initial posted proposal) is clearly the product of free-form debate by “many cooks in the kitchen”. If you’re going arrive late to a party, don’t complain that you don’t understand what’s going on, especially when it starts out clear enough for anyone to understand. Greg L (my talk) 00:50, 28 December 2007 (UTC)
Greg L, that is a blatantly personal attack, and should be withdrawn. Please focus on the policy page, not contributors. I agree with Noetica's points. Tony (talk) 01:37, 28 December 2007 (UTC)
You may denigrate it as merely amusing, Greg L. But as one of those responsible for the chaotic spaghetti of discourse in this section you ought rather to take note and to be ashamed. To answer one of the few specific points you have succeeded in making, I strongly opposed any proposal for spacing of numbers after the decimal point. Don't blame me if the exact proposal supposedly under consideration is not cleanly and clearly set out, in one location that all can refer to. That wasn't my doing! You say, at the location you point to (already way back), things like this: "I would propose...". For Jimbo's sake, make a proposal; lay it out in a neat paragraph or so, in bold. Set it off from everything surrounding it, and then call for comments and votes. If, in your quaint American-boyish way, you take my contribution here as that of a "den mother", then I put it to you that editors labouring away so unreadably and with such futility might indeed stand in need of overseeing. But I'm not about to undertake that task, which is both impossible and un-Wikipedian. Especially given your response, showing that you are immune to criticism from one who takes MOS matters very seriously, and is very attentive to issues that impede progress. It is ridiculous to assert as you do that anyone can follow what's happening here.
No more sophomoronic clash of personalities here, please. There are issues to address. Please address them.
– Noetica Talk 01:43, 28 December 2007 (UTC)

You’ve already made your fantastically well-considered vote and I don’t expect that anything I write here will make one twit of a difference in how you vote. I agree, the “chaotic spaghetti of discourse” is hard to track. That’s still no excuse for voting on an issue you admit to not even understanding! What’s wrong with you that you can’t see that? I didn’t do the page layout on this section; it’s the product of many people in a rapid back & forth debate. You could go in a clean it up just as well as anyone else here but I don’t see you volunteering. Given the history of your contributions (music-related topics), I also am quite skeptical that your interest in this topic is anything more than just passing. Tony: as regards alleging I made a “personal attack” here’s what the Misplaced Pages:No personal attacks article says:

There is no bright-line rule about what constitutes a personal attack as opposed to constructive discussion, but some types of comments are never acceptable:

  • Racial, sexual, homophobic, ageist, religious, political, ethnic, or other epithets (such as against disabled people) directed against another contributor. Disagreement over what constitutes a religion, race, sexual preference, or ethnicity is not a legitimate excuse.
  • Using someone's affiliations as a means of dismissing or discrediting their views -- regardless of whether said affiliations are mainstream or extreme.
  • Threats of legal action.
  • Threats of violence, particularly death threats.
  • Threats of vandalism to userpages or talk pages.
  • Threats or actions which expose other Misplaced Pages editors to political, religious or other persecution by government, their employer or any others. Violations of this sort may result in a block for an extended period of time, which may be applied immediately by any administrator upon discovery. Admins applying such sanctions should confidentially notify the members of the Arbitration Committee of what they have done and why.

As you can see, saying that I think what you wrote is hogwash and is without merit falls about a light-year short of “personal attack” as defined by A) common sense, and 2) Misplaced Pages. I’m saying your idea sucks, as was your fundamental position on this subject, as was the way you went out of your way trying to take the high road and seek out ways to criticize others who don’t produce well laid-out discussions pages so you can arrive late in the game and have to actually read and parse what’s here to understand it! Too bad. I have my opinion on the constructiveness of what I call your “drive-by shooting” on this topic: just enough of a cursory visit to make a glib pronouncement of how everyone hasn’t done a good enough of a job to meet your lofty standards. A “total disgrace”(?) P-u-h-l-e-e-z-e. Do you think the people here trying to hammer out technical details of delimiting numeric strings need some sort of benediction from you when you arrive late to the discussion? Just who in the world do you think you are? You want me to retract what I truly feel? That’s my opinion of what you wrote above and I’m sticking to it. Do you think Misplaced Pages gives you the entitlement of being free of well-deserved criticism and critical commentary on every damn thing you write? Everyone on Misplaced Pages deserves to be free from “personal attacks” as defined as Misplaced Pages above, and everyone needs to be treated civilly. Simultaneously, I can call B.S. garbage that anyone writes as I see it: “garbage”. If you disagree with me on this, then we’ll have to agree to disagree.

Finally, I am quite done dealing with you—or anyone else for that matter—here in this forum. Don’t chase me down and leave messages on my talk page. I don’t have to deal with you any more and I don’t have to deal with this topic here any more. OK? You won’t have to be all indignant over how Greg L didn’t give you a pat on your head for what you wrote because I’m done here. Goodbye. Greg L (my talk) 06:07, 28 December 2007 (UTC)

<giggle> Tony (talk) 06:30, 28 December 2007 (UTC)

Oh dear, a perfectly good proposal was being discussed here, and now it's gone to rats. Is Noetica seriously suggesting that we first must participate in MOS before gaining the right to discuss numbers here? (I don't see how else to interpret
  • Who here, apart from SMcCandlish, has so much as glanced at the hard-space issue, raised at WT:MOS and now with its own dedicated discussion page that I have set up?)
If so, I certainly hope that is not the point that Tony is agreeing to. Thunderbird2 (talk) 12:09, 28 December 2007 (UTC)
T-Bird, almost two weeks ago you wrote, in this very section:
The issue of how to deal with the spacing of digits after the decimal point has arisen before. Some advocated leaving spaces every three digits and some leaving no spaces. No consensus was reached, which is why there is no guidance in the MOSNUM. Your views on that discussion are welcome.
The first thing to observe about this is that your link takes us nowhere. Presumably the material has been archived; but it is a mark of the way this discussion has been conducted that no one seemed to notice – until I point it out now. I made a reasonably diligent search, and could not read or even find the relevant earlier discussion. Why is this so? Why did you not check your link, and fix it? How can I be accused of not following things up?
Second, it is interesting that no consensus was reached that last time. Why do you suppose that is? And, much more importantly, what lessons has anyone here learned from that failure? As I have more or less pointed out, you need to structure things so that such history can be retrieved and learned from.
Third, there is a great deal of bumbling here about what various authorities say. A passing mention of CMOS (Chicago Manual of Style), and no mention of any British authority (though I myself consulted Hart's Rules before making my contribution above). As for the SI side of things, I see that a 1997 document eventually got on the table. Better, I think, to consult something more recent, as I did myself before commenting here (see Bureau International des Poids et Mesures: The International System of Units (SI), 8th edition, 2006). Of course, it's possible that I missed something else: but my point then is that it's very hard to find these things, among all your words.
Fourth, if "a perfectly good proposal was being discussed here", let's see the damn thing, in all of its perfect clarity. That way there just might be a coherent discussion that has some wan hope of gaining consensus for or against, and which others will later respect. If you don't do that, this will be just another time-wasting talk-fest that falls into the same black hole as the earlier discussion that we can't seem to unearth any more.
– Noetica Talk 12:43, 28 December 2007 (UTC)
Noetica, I do not pretend that all is well laid out, but the first line of the discussion reads
That link will take you to the archived discussion. What was proposed then (you won’t find an explicit proposal because it took the form of this edit directly to MOSNUM) was the deprecation of spaces after the decimal point.
The new proposal by Greg L is the opposite one: a preference for spaces (every three digits) after the decimal point.
In both cases I am paraphrasing, but I think I have captured the essence. The reason that no consensus was reached (then and so far again now) is that some editors favour the spaces and some don’t. I see nothing wrong in that, although an unfortunate consequence is that MOSNUM remains silent on the issue. That we continue to discuss it at all is a good thing, and certainly not a “time-wasting talk-fest”.
Thunderbird2 (talk) 17:55, 28 December 2007 (UTC)
  • Support I admit I can't tell whether the proposal was lost in the fighting, or consensus was reached for no change, or what, but just in case, I support it. As for exactly what I'm supporting: any automatic, preferably user-preference configurable but I'm still in favor if we can't do it, that defaults to commas to the left of the decimal, hard spaces or 0.3 em spaces (I don't care) to the right. This is readable, will not be so unfamilar to anyone as to be offputting, and will clarify an otherwise-unclear area of editing. Good things, all. atakdoug 04:05, 10 January 2008 (UTC)

Nutshell of what is being contemplated (next attempt)

Overview

Well, some friends and I went off and spent the last month working on this issue here on my talk page. Temporarily moving to a forum where I had greater liberty to rearrange and revise things after-the-fact kept things much more manageable and understandable and allowed rapid and constructive progress. Unfortunately, it takes things off the radar too much and makes it impossible to obtain a consensus here. So I’ve transplanted the below work product from my talk page. To avoid the confusion that Noetica pointed out above, I will, where necessary, take the liberty here of rearranging things after-the-fact (after people have responded) but will do so in ways that make it clear who was responding to what. I think this will be necessary to keep this complex topic organized and understandable.

Below are the latest specifics of the proposal:

  • We’ve been discussing the details and merits of a template/parser function (magic word) to make life easier for editors when expressing delimited numeric equivalencies—with and without physical units. The fundamental motivation underlying this effort is this obvious truth: delimiting numeric strings to the right of the decimal marker serves precisely the same purpose as does doing so to the left of the marker and is very much needed on Misplaced Pages. It would avoid number strings like this: 2.718281828459 which actually appeared in Natural logarithm until a few weeksa go. A full-featured use of the template/parser function would allow an editor to type {{delimitnum:6.02246479|30|23|kg}} in order to obtain the following: 6.02246479(30) × 10 kg

    The parenthetical (30) in the above value denotes the uncertainty at 1σ standard deviation (68% confidence level) in the two least significant digits of the significand.


  • In summary, the above template/parser function functions as follows: {{magic word: significand–delimiting | uncertainty | base–ten exponent | unit symbol}}


  • The use of a template/parser function like this greatly simplifies things for editors. To generate the above value, one currently must hand-code the following: 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79(30)</span>&nbsp;×&nbsp;10<sup>23</sup>&nbsp;kg (*Phew*)


  • Although highly capable and feature-rich, this template/parser function wouldn’t be cumbersom for simple tasks. It would work similarly to how {{frac|2}} produces 1⁄2 and {{frac|10|11}} produces 10⁄11. For instance, one need only type {{delimitnum:6.022464}} to obtain 6.022464 or they could type {{delimitnum:1579800.298728}} to obtain 1,579,800.298728

    You could also pick and choose just the features needed. For instance {{delimitnum:1.356392733||50|Hz}} yields 1.356392733 × 10 Hz and {{delimitnum:0.45359237|||kg}} yields 0.45359237 kg


  • One of the things that has been standardized by the ISO, the BIPM, NIST, ect. is that delimiting in the decimal shall not leave a single dangling digit, like “0.001 4”. Accordingly, the progression of delimiting goes as follows:

    2.123
    2.1234
    2.12345
    2.123456
    2.1234567
    2.12345678
    2.123456789

    This template/parser function will avoid future occurances of editors hand-coding improper, hanging digits—as exemplified in this section of Font size, which features this numeric string: 0.187 985 755 2 mm


  • Even nicer, the template/parser function wouldn’t use “spaces” to delimit the fractional portion of the significand (the portion of the significand to the right of the decimal marker). Instead, it would use what typographers refer to as “pair kerning” via em-based control of margins (e.g. <span style="margin-left:0.25em">). Margin positioning is part of what the Web-authoring community calls span tags, which, in turn, is part of Cascading Style Sheets (CSS). Effectively, what appears to be a space would really only be a visual effect caused by the precise placement of the digits; the “spaces” wouldn’t be separate, typeable characters.

    To see the difference, slowly select the two values below with your mouse:

6.022464342 (via em-based span tags, note how the cursor snaps across the gaps)
6.022 464 342 (via non-breaking spaces, note how the spaces can be individually selected)

One might ask “Why is em-based margin control via span tags nice?” Note how, as you select the two values above, the lower version has spaces that can be selected because they are distinct characters. By using the technique illustrated in the top example however, people will be able to select entire significands from Misplaced Pages and paste them into Excel, where they will be recognized as real numbers! This beats the hell out of the current system, where (as exemplified at Font size) simple regular spaces and non-breaking spaces are used to delimit numbers. These values can’t be copied and used in Excel without first hand-deleting each of the spaces from every value. Until the spaces have been deleted, Excel treats the numbers as text strings upon which mathematical operations can’t be performed.

  • In summary, here is a concise list of examples highlighting the flexibility and convenience of this template/parser function. All the editor does is follow the parsing map:
{{delimitnum: (value) | (uncertainty) | (base–ten exponent) | (unit symbol) }}
Leave feature blank if not required
Separator bars are not required if you input only the value
{{delimitnum:6.02214179|30|23|kg}} → 6.02214179(30) × 10 kg
{{delimitnum:1579800.298728}} → 1,579,800.298728
{{delimitnum:1.356392733||50|Hz}} → 1.356392733 × 10 Hz
{{delimitnum:0.45359237|||kg}} → 0.45359237 kg
{{delimitnum:6.022461}} → 6.022461
{{delimitnum:6.0224613}} → 6.0224613
{{delimitnum:6.02246134}} → 6.02246134
{{delimitnum:6.022461342}} → 6.022461342


  • This proposal is founded on the following assumptions: 1) commas should be used to delimit the integer portion of the significand, 2) narrow gaps should be used to delimit the fractional portion, and 3) a template/parser function should be made to facilitate delimiting the significand and to also simplify the formatting of the rest of numeric equivalencies (such as relative standard uncertainty in concise form, base-ten exponents, and setting off unit symbols with a non-breaking space). The reasoning underlying this is addressed in Rationale for using “comma delimiting” with “narrow-gap delimiting”, below. As regards how Misplaced Pages readers already recognize and accept gap-delimiting to the right of the decimal marker, see Making a case for why narrow gaps are already well-accepted on Misplaced Pages, below.
Greg L (my talk) 03:46, 2 February 2008 (UTC)

Gap width details

  • I looked at this page using Firefox on Mac and saw how 0.3-em gaps appeared larger than in Safari. It’s a bit of a jump, but I suspect (hope) that what I’m seeing in Firefox is representative of what Windows users are seeing. I also discovered something really neat. Safari treats 0.25 em as 0.3 em. However, Firefox displays 0.25 em narrower than for 0.3 em. Thus, by coding 0.25 em, Windows users should see 0.25 em, yet Safari users, who can see either 0.2 em (too narrow) or 0.3 em (just right) will continue to see the rounded-up, 0.3 em space. For convenience, I’ve reproduced some examples chosen from Kilogram and modified them all per this new convention so you can see a complex variety of delimited numeric strings in context. Please tell whether this technique produces acceptable looking strings in these following examples:
  1. This proposed value for the Avogadro constant falls neatly within the measured value (≅6.02214184 × 10 vs. the 2006 CODATA value of 6.02214179(30) × 10)
  2. The avoirdupois pound is defined as exactly 0.45359237 kg, making one kilogram approximately equal to 2.205 avoirdupois pounds.
  3. The meter’s length is delineated—not defined—as 1,579,800.298728 wavelengths of light from this laser.
  4. The Avogadro constant, is an experimentally determined value that is currently measured as being 6.02214179(30) × 10 atoms (2006 CODATA value).
  5. …has a relative standard uncertainty of 50 parts per billion and the only cube root values within this uncertainty must fall within the range of 84,446,889.8 ±1.4; that is…
  6. As such, the kilogram would be defined as 1000/27.9769271 × 6.02214179 × 10 atoms of silicon-28 (≅35.7437397 fixed moles of silicon-28 atoms).
  7. The Planck constant would be fixed, where h = 6.62606896 × 10 J·s
  8. The kilogram would be defined as “the mass of a body at rest whose equivalent energy equals the energy of photons whose frequencies sum to 1.356392733 × 10 Hz.”
  9. From Natural logarithm: …where e is an irrational constant approximately equal to 2.718281828459.
If this doesn’t fix platform-dependent differences, maybe there will be a perl or parser function-based method to check the O.S. of the viewer and adjust accordingly. I don’t know; these are details that can be resolved on-the-fly. Greg L (my talk) 20:45, 29 January 2008 (UTC)
  • Since the above post regarding sizes, Jimp, Atakdoug, and I have examined in-depth details of gap width. We exchanged e-mails with attached screen shots showing how various gap-width strategies appear on different platforms (operating systems and browsers). Atadoug even looked at how things look on an iPhone! The current delimiting seems to be the best compromise. I don’t have time at the moment to here-capture all of his work and mine but would be more than pleased to do so if we can constructively get to a stage where such detail is needed. Remember, that if the gap widths appear slightly narrower or wider than optimum, I can guarantee you that it looks the opposite on someone else’s system; different platforms do font management differently that others.

    In the mean time, the logic tree for delimiting to the right of the decimal marker would be as follows:

Q1: Are there five or more undelimited digits remaining after the decimal marker? No=Stop / Yes=Advance three digits and prepare to add span gap. Goto Q2.

Q2: Is the span gap to be added following the digit “1”? No=Add a span gap of 0.25 em and then goto Q1 / Yes=Add a span gap of 0.2 em and then goto Q1.

Greg L (my talk) 20:51, 1 February 2008 (UTC)

Rationale for using “comma delimiting” with “narrow-gap delimiting”

In any discussion of delimiting numbers to the right of the decimal marker with gaps, we must also settle on what to do to with the integer portion of the significand (the left-hand side of the decimal marker). I advocate using commas for two reasons:

1) Most articles on Misplaced Pages already use commas. It’s what U.S. readers expect and is a convention that Europeans are accustomed to encountering. Trying to do the integral any other way wouldn’t be well received and the template/parser function simply wouldn’t get used.
2) Few numbers simultaneously require delimiting on both sides of the decimal marker. In other words, it will be a rare number where commas (a U.S. style) and narrow spaces (a European/SI style) are juxtaposed within a single value.

Note the above examples (copied from Kilogram and Font size). In those examples, only the third example (the definition of the meter) has five or more digits in both the integral and fractional portions of the significand. All the others require delimiting only on one side of the decimal marker or the other, but not both. Greg L (my talk) 20:06, 31 January 2008 (UTC)

Making a case for why narrow gaps are already well-accepted on Misplaced Pages

I’ve seen many Misplaced Pages articles that feature space-delimited numbers to the right of the decimal marker and they’ve been stable for years without one single “drive-by shooting” by an unregistered editor-in-a-hurry attempting to “fix” the ‘funny-looking’ values. Font size is just one such example; there are too many Misplaced Pages articles to count. This is clear proof that essentially all readers readily recognize that what they’re looking at are space-delimited numeric values. If this can occur with full-width spaces, then reduced-width ones—which just look “right”—will be even easier and more natural for readers. Delimiting numeric strings to the right of the decimal marker serves precisely the same purpose as does doing so to the left of the marker and is very much needed. Greg L (my talk) 19:42, 1 February 2008 (UTC)

Continuing Discussion, specifically regarding latest nutshell proposal

  • I have always supported this proposal and continue to do so. Groups of 3 are an advantage for both editors and readers because they are much easier on the eyesight than long unbroken strings of digits. The improved solution offered by Greg L, Jimp and Atakdoug just make it better. Thunderbird2 (talk) 06:48, 30 January 2008 (UTC)
  • Makes sense to me. Seems well thought-out and practicable to implement. Formatnum already seems to work well, and can be tailored to locales, and this is a logical extension of that concept. --Slashme (talk) 07:25, 30 January 2008 (UTC)
  • And I’ll formally throw my hat into the ring. Delimiting long strings of digits to the right of the decimal marker is already a common practice on Misplaced Pages but isn’t always done properly. Further, hand-coding is cumbersome. The authoring community needs a template/parser function to automate this, standardize appearance per ISO and the SI, and make values pasteable into Excel to boot. Greg L (my talk) 20:12, 31 January 2008 (UTC)

YEAR in TOPIC

Unresolved – Proposal still open (re-re-proposed replacement language)

This is merger of several related discussions and proposals. — SMcCandlish ‹(-¿-)› 00:07, 19 December 2007 (UTC)

Clarification about when to link to dates? (according to MOS)

I'm looking for some clarification about when dates should be linked. In the Autoformatting and linking section of the MOS, the last bullet reads:

"Misplaced Pages has articles on days of the year, years, decades, centuries and millennia. Link to one of these pages only if it is likely to deepen readers' understanding of a topic. Piped links to pages that are more focused on a topic are possible (]), but cannot be used in full dates, where they break the date-linking function."

Does the sentence in boldface (my emphasis) mean:
1. That dates (using any combiations of days, months, and year) should only be linked if the linked date will add to the reader's understanding.
2. That only full dates (i.e. November 1, 2007) should be linked, but not dates like November 2007.

Another Wiki user has been trying to tell me that the latter is the case, while I have been trying to indicate that the first meaning is correct. (The discussion can be viewed here: User_talk:NatureBoyMD.) Which is correct? -NatureBoyMD 21:26, 11 October 2007 (UTC)

The second is close to correct. Full dates, like November 1 2007, as well as just months and days, like October 14, should always be linked. This allows a user's date display preferences to work. TomTheHand 21:37, 11 October 2007 (UTC)
"Should always be linked"? No, the wording is "are normally linked", after a lot of tension several months ago about the dysfunctional state of the dateformatting script. See archives here for a discussion of the ?five key disadvantages in using it. As I've loudly trumpeted here and elsewhere, I now actively discourage the use of the autoformatting function, and will continue to do so until it's fixed.
Number 2 above, second point is a different issue: autoformatting applies only to full dates, not years alone and years and months. Please avoid linking those items unless there's a COMPELLING reason to do so. Tony (talk) 03:46, 14 October 2007 (UTC)
Agreed with Tony. Misplaced Pages is awash in pointlessly linked dates. Linking a date for no particular reason is no better than linking to Wiktionary for definitions of every single word in an article. — SMcCandlish ‹(-¿-)› 19:35, 14 October 2007 (UTC)

Proposal: Do not use surprise links

The albums project contains the following:

  • Quote: Do not use piped links to "years in music" e.g. ], instead add (see 1991 in music) where you feel it is appropriate.

I propose that we make that generic and include it. Lightmouse 11:09, 15 November 2007 (UTC)

It's a good idea, since most readers will assume that piped year-links are of the trivial type (which shouldn't be linked at all) and won't bother to follow them. Tony (talk) 11:43, 15 November 2007 (UTC)
Any suggestions for generic wording? Lightmouse (talk) 12:35, 18 November 2007 (UTC)
We could expand further; surprise links masked as single words are as bad as ones masked as years. But this should be a recommendation; ] can make perfect sense in a table, for example. Septentrionalis PMAnderson 06:32, 23 November 2007 (UTC)
It depends on the word that represents the pipe. The problem with years is that because they have been commonly linked but unpiped, readers tend to ignore the piped ones because they can't be bothered to check each blue-spattered year on the off-chance that it's piped to somewhere useful. The same does not generally apply to other words that are piped, although I concede that in some cases the principle is similar ("restaurant" --> "Chinese cuisine" in a recent FA, I seem to remember). Tony (talk) 12:07, 23 November 2007 (UTC)
If you would like to modify the scope that is fine by me, as long as this date problem is dealt with succinctly and strongly enough to have a real effect on editors. My proposal is to replace the following wording:
  • Piped links to pages that are more focused on a topic are possible (]), but cannot be used in full dates, where they break the date-linking function.
with
  • Do not pipe a link from "year" to "year <something>" or "<something> year" e.g. ]. Use "(see ])" if appropriate. Note that piped links break the date-linking function if used in full dates.
Lightmouse (talk) 09:40, 23 November 2007 (UTC)
I have to strenuously disagree. While I'm aware that somewhere in one of these guidelines there is an old recommendation to never use so-called "surprise links", this advice, which I surmise dates to around 2003 or so, has been completely abandoned in actual practice by the community. E.g. there is no longer any consensus at all that there is anything wrong with "composed of silica and aloxite". Piped links exist for a reason. I don't see any rationale at all for enshrining a weird date-specific exception, and (Tony are you listening? ;-) I think it would be detrimental to our goals of ending the wikilinking of random bare-year dates, by removing any reader expectation that linked years every go anywhere vaguely useful. Rather, I think that we need to do the exact opposite and recommend not only that bare year dates never be linked as 1996, but also that the only time that such years should be linked is when the do go to a topically-relevant and -specific year article (1996 in baseball, or whatever). For WikiProject Sports I've been been formulating a guideline on when and when not to use such links (e.g.: "won third place in the 1996 World Championship" vs. "won the 1996 World Championshiop"). Agree that mentioning that piped links break the date-linking function if used in full dates is good to mention. Really, I think that proponents of this move simply do not frequently edit articles in which these sorts of links are useful (especially sports and entertainment stats tables come to mind, despite the music project's own advice). If I get shouted down on this, I might be able to compromise on their being permitted in tables, since I don't think they particularly are (or aren't) useful in general article prose, but do find them particularly useful in tables. Cf. WP:MOSFLAG - pretty much the same dividing line (except that the majority of editors, myself included, find flagicon use in main prose genuinely detrimental while sometimes useful in tables.) — SMcCandlish ‹(-¿-)› 15:19, 24 November 2007 (UTC)
PS: Don't mistake me for an overlinker of dates; see my comments at the end of #Clarification about when to link to dates? (according to MOS), above. I don't advocate that "Year in X" date linking be done very much, only when it is truly germane. — SMcCandlish ‹(-¿-)› 16:08, 24 November 2007 (UTC)
OK, I'm all ears; I hear you! Tony (talk) 07:11, 28 November 2007 (UTC)
I am also listening. My proposed wording was just a suggestion, I would be interested to see other suggestions. Lightmouse (talk) 20:40, 28 November 2007 (UTC)
SMcCandlish, I think your (compromise) proposal that they be permitted in tables is a good one. I disagree that the existence of piped links justifies these types of links in body copy, as I consider that too much of a "surprise". What if we changed the wording to discourage their use in copy (as above) but encourage their use in infobox and other tables where it makes sense? -- Renesis (talk) 00:49, 29 November 2007 (UTC)
OK, how about:
  • Do not pipe a link from "year" to "year <something>" or "<something> year" e.g. ] in copy text. Use "(see ])" if appropriate. In tables, piped links are permitted if they make the table compact. Piped links must never be used in full dates because they break the date formatting function.
Lightmouse (talk) 09:11, 29 November 2007 (UTC)
What about links in football articles such as 1987–88? Woodym555 (talk) 11:33, 29 November 2007 (UTC)
Alt. version:
  • Avoid piping links from "year" to "year <something>" or "<something> year" (e.g., ]) in the main prose of an article. Use "(see ])", if it is appropriate to link a year to such an article at all. In places where compact presetation is important (some tables, infoboxes and lists), piped links may be useful. Piped links must never be used in full dates (e.g. ], ]) because they break the date-formatting function. Piped topical year links should only be made when the event in question is genuinely notable in the context of the year article to which would link.
— SMcCandlish ‹(-¿-)› 11:54, 29 November 2007 (UTC)
  • I think that would indeed be an undesirable result. The point seems to be that such links shouldn't be used at all the main article prose. I'm honestly not sure I can agree with that, so it looks like we are right back to the drawing board. Some are opposed to "surprise links", period, others like me and I think you see them as very useful ways of avoiding redundant clutter wording in ever other sentence. Others think they should only be used in tables/lists of tabular data. I accidentally supported that viewpoint, but don't actually share it. I do think that "surprise" links should be used in such cases, but not that those should be the only cases. Anyway, it strikes me that we don't have consensus on this one way or the other yet. The proposal, and the language in MOSNUM presently both do not adequately deal with the situations that arise. — SMcCandlish ‹(-¿-)› 20:48, 12 December 2007 (UTC)
You read my feelings perfectly. I am currently of the opinion that they do no harm. I don't think that consensus will be very forthcoming, given that peoples views vary differently. Trying to accomadate everyone's views leads to watered down text that actually helps no-one.

Re-proposal

New version to address issue raised by Woody:

*Avoid piping links from "year" to "year something" or "something year" (e.g., ]) in the main prose of an article. Use an explicit cross-reference, e.g. ''(see ])'', if it is appropriate to link a year to such an article at all. In places where compact presentation is important (some tables, infoboxes and lists), piped links may be useful. Another exception is the main prose of articles in which such links are used heavily, as if often the case with sportsperson biographies that link to numerous separate season articles, in which the ''(see ...)'' phrasing would rapidly become repetitive and cluttering; in such a case it is best to make it clear that the link is to such a topical date article, e.g. in ], rather than in ]. Piped links must never be used in full dates (e.g. ], ]) because they break the date-formatting function. Topical date links should only be used when the event in question is genuinely notable in the context of the year (or month, etc.) article to which would link.

Revised version below.

I think this will adequately address the cases that need to be addressed so far, and would actually slightly help advance the growing consensus that a replacement for the date formatting function is needed so that dates are only linked when there is a contextual/informative reason for linking them.

PS: If we wanted to address piped links other than dates, I believe that is a way bigger matter, and should be discussed at WT:MOS, probably with an RfC, since it is bound to be highly controversial.

— SMcCandlish ‹(-¿-)› 21:00, 12 December 2007 (UTC)

I agree with almost all of those points. That addresses all cases brought up so far, but this is a very insular forum for something like this. If the discussion were to be broadcast, I think you would find a wide variety of subjects where these links are useful. The date formatting function is a whole different kettle of fish. (metaphor about barge pole comes to mind). Also agree that "hidden links" is a topic that needs wider discussion. Your text seems fine for what it is, yet to me it seems complicated and too wordy. There are too many exceptions for it to be a useful editing guideline. (IMO of course). Woody (talk) 21:13, 12 December 2007 (UTC)
It can be made more readable with indented bullet points. The insularity is intended, because we're only trying to address over- and inappropriate date linking without opening a larger can of "hidden links" worms. I'm sure there are other cases where such date links arise, but isn't mentioning both music and sports good enough to get it across that we're speaking in generalities? I wouldn't want to see us list 15 "different" exceptions that aren't really different in a meaningful way. :-) Here's a revised version:
  • Avoid piping links from "year" to "year something" or "something year" (e.g., ]) in the main prose of an article in most cases. Use an explicit cross-reference, e.g. ''(see ])'', if it is appropriate to link a year to such an article at all. Exceptions:
  • Piped links may be useful in places where compact presentation is important (some tables, infoboxes and lists).
  • Piped links may also be useful in the main prose of articles in which such links are used heavily, as is often the case with sportsperson biographies that link to numerous separate season articles.
Piped links must never be used in full dates (e.g. ], ]) because they break the date-formatting function. When using piped links, it is best to clearly indicate that the link is to such a topical date article, e.g. in ], rather than in ]
A topical date link should only be used when the event in question is genuinely notable in the context of the year (or month, etc.) article to which it would link.
How's that? — SMcCandlish ‹(-¿-)› 00:44, 13 December 2007 (UTC)
Looks good to me. Lightmouse (talk) 13:20, 15 December 2007 (UTC)
As good as it is going to get I think. Well done. (The insular was referring to the limited number of people who look at, and comment on this particular forum.) Woody (talk) 13:41, 15 December 2007 (UTC)
Sounds good. -Freekee (talk) 17:05, 23 December 2007 (UTC)

I think input from more editors is required before removing "surprise links" from every article. It should be discussed at the village pump. --Pixelface (talk) 12:33, 16 December 2007 (UTC)

I would much rather see a piped link than have a random (see....) after some sentences. Piped links are extremely common on the English wikipedia, and (see...) is not. In my opinion, navigation should either be in a See Also section or through wikilinks embedded in the text (whether they are piped or not). Karanacs (talk) 22:31, 17 December 2007 (UTC)
To be honest, that is also my opinion. It is also why I have argued for the inclusion of "escape clauses" and some ambiguity in the text. The word heavy is always open to interpretation. Within the prose of an article "hidden links" are useful and help to keep the prose flowing. The links do provide context as well. Woody (talk) 22:45, 17 December 2007 (UTC)
Right. That is pretty much the largest point of this exercise. I know that some guideline somewhere, probably a MoS page (I can't actually find it yet, so it may have already been deleted), argues against any and all so-called "surprise links" generally, and it is my contention that it does not in fact represent consensus at all, since the utility of such links is obvious, as is the plain fact of their use in hundreds of thousands of WP articles with no sign of them being deprecated by the general editorship. The other point, of course, is to lay out some sane guidelines on usage of such links within the scope of WP:MOSNUM, at least with regard to years. We might later need to cover other cases, but for now I think that the years case is sufficient, per WP:CREEP and WP:BEANS (i.e., do not attempt to create a guideline about something on which the editing community doesn't genuinely need guidance.) — SMcCandlish ‹(-¿-)› 23:17, 18 December 2007 (UTC)
Yep, completely agree. In that vein, lets add the text in, barring any further objections. Woody (talk) 23:29, 18 December 2007 (UTC)
Pixelface, I honestly don't understand what you are getting at. There is no proposal to remove "surprise links" from every article. This proposal is actually quite opposite that, and sanctions the use of such links where they are genuinely useful and explains somewhat what the criteria of that usefulness might be. There is already, somewhere else that I seem unable to locate right now, a more general condemnation of piped links, which I contend is nonsense and hope to change into something more reasonable when I actually find it (and of course after another but more general discussion of this sort). — SMcCandlish ‹(-¿-)› 23:22, 18 December 2007 (UTC)
Lightmouse proposed it on November 15. And if you look at his contributions, he's been removing "surprise links" quite actively. --Pixelface (talk) 02:46, 27 December 2007 (UTC)

Parentheses

If you do this, then I think that, if a date appears within parentheses, it should automatically be replaced with "(see XXXX in music)" (or "video gaming" or whatever). SharkD (talk) 03:49, 17 December 2007 (UTC)

That would in way, way too many cases auto-violate the the principle that such "YEAR in TOPIC" links should only be made when the linked-from item is genuinely significant within the context of that year. For example: SOME_RANDOM_FILM_NAME (1993), on one hand, versus SOME_VERY_SIGNIFICANT_FILM_NAME took the 1993 "Best Picture" Oscar on the other. And that probably isn't even a good example, really. It is hard to come up with a generalized case for when one should make such links; it is much easier to say that most of them should simply be deleted, as blue-link "noise". — SMcCandlish ‹(-¿-)› 23:09, 18 December 2007 (UTC)

Any reason the remaining dispute tag can't be removed?

It's on "Autoformatting and linking". Can't see the point of the continued presence of the tag. Tony (talk) 08:34, 24 September 2007 (UTC)

The overall discussion topic still seems to be open on it, and someone even cross-listed the discuss at WT:MOS. Better to let it stand until that discussion settles out, I think.

Closure

Just for the record I want to call for any last discussion/debate that anyone feels is needed. The #Re-proposal above seems to not be truly objectionable to anyone, even if it not a bright line in the sand, if I may mix a few metaphors. A possible exception is SharkD, but I think the concerns raised by that editor are addressed (and I speak only for myself on that observation). I think that the re-proposal (as re-re-proposed; follow the boldface) does represent actual consensus on the usage, and also feel that consensus may change on the matter to make the line brighter, one way or another, some time in the future. It is better to have some advice on the issue than either no advice, or, worse yet, advice so obsolete that everyone ignores it (since the latter case simply weakens MoS as a whole - the more it is treated as optional or theoretical, the more wildly inconsistent WP articles will become). — SMcCandlish ‹(-¿-)› 00:10, 19 December 2007 (UTC)

Where is the proposal? Can we repeat it in it curent form? Rmhermen (talk) 18:14, 23 December 2007 (UTC)
It is now just below, in further-improved form. — SMcCandlish ‹(-¿-)› 16:39, 24 December 2007 (UTC)
I note that there is guidance at wp:moslink. Lightmouse (talk) 14:41, 24 December 2007 (UTC)
Will go look at it. Did. It makes some reasonable points, but they are not tremendously applicable to dates. It is clear that the date-specific language in it was simply borrowed from here. I think I can make a re-re-re-proposal that will address this all, but and really tired right now so I should do it tomorrow or more like after Christimas. If I don't do it by Boxing Day, someone ping me one my talk page about it? I've already got it worked out half in my head but my eyes hurt, and the words aren't quite going right. — SMcCandlish ‹(-¿-)› 15:36, 24 December 2007 (UTC)
Nah, actually I think I've got it already:
  • Avoid piping links from "year" to "year something" or "something year" (e.g., ]) in the main prose of an article in most cases. Use an explicit cross-reference, e.g. ''(see ])'', if it is appropriate to link a year to such an article at all. Exceptions:
  • Piped links may be useful in places where compact presentation is important (some tables, infoboxes and lists), when they are notable enough, and not deceptive, per the below criteria: Best Rock Album ]: ].
  • Piped links may also be useful in the main prose of articles in which such links are used heavily, as is often the case with sportsperson biographies that necessarily link to numerous separate season articles containing relevant information, again per the below criteria.
  • Piped links must never be used in full dates (e.g. ], ]) because they break the date-formatting function.
  • When using piped links, especially in general prose, it is best to clearly indicate that the link is to such a topical date article, e.g. ...in ], rather than ...in ]. In particular, keep in mind that readers print out Misplaced Pages articles, so one must never use "easter-egg" links, that hide the nature of what they link to, as in ...since his ] to remain in the top-16.
  • Do not overlink, as in ] ] or worse yet the ] ] – if a very specific dated article exists, e.g. for an event, do not also link to the more general topical or regional one.
  • A topical date link should only be used when the event in question is genuinely notable in the context of the year (or month, etc.) article to which it would link. Typically, this means winning – not simply being nominated or a competitor for – a top award, trophy or other no.-1-level achievement that is itself notable on an international level, or a narrower level appropriate to the nature of the date article (e.g. nationally in the case of 2007 in Canada).
That should take care of most of it, plus some other issues I thought of in the course of re-editing it, though now I have discovered more stuff to take account of, at Misplaced Pages:Overlinking#Dates, but now really am too tired to work on it further; I did start on that integration (see Country Music Awards example now included), but it needs more integration think-through that I'm just not capable of right now. So this one isn't quite the final release candidate yet after all. <sigh>. Also, it should be obvious that both of the "rediscovered" documents may need minor changes of their own to conform to this one, though I'm more trying to make this conform to them. — SMcCandlish ‹(-¿-)› 16:39, 24 December 2007 (UTC)
That is quite long and hard for me to understand. A guideline should only exist if it will have an effect on articles. I suspect complicated rules have less effect than simple ones. I propose the following:
In general, do not pipe links from "year" to "year something" or "something year" (e.g., ]). Use an explicit cross-reference, e.g. ''(see ])'', if it is appropriate to link a year to such an article at all. Cases where piped date links might be tolerated are:
  • Where width restrictions make unpiped links difficult to fit. This can sometimes occur in tables, infoboxes and lists.
  • Where multiple repetition of unpiped links would be difficult to read. This can sometimes occur in sport articles that mention multiple relevant seasons.
Piped links must never be used in full dates (e.g. ], ]) because they break the date-formatting function.
Comments? Lightmouse (talk) 14:06, 4 January 2008 (UTC)
I agree it could be trimmed some, but that version lost too many points (which are not WP:BEANS or WP:CREEP - they are addressing current and common worst practices). It is possible that some of these points need to be addressed elsewhere, but I can't think off the top of my head of a better place to address over-linking and just plain mis-linking of dates than Misplaced Pages:Manual of Style (dates and numbers).
Since this will be its own subsection length is not particularly an issue. Completeness and consistency of guidance to editors is more imporantant, because MOS pages are references works for editors, and are not articles or other light reading.
That said, I like some of the clarifying language. Will try a stab at a merged version when I get around to it. — SMcCandlish ‹(-¿-)› 18:13, 4 January 2008 (UTC)

Here's an attempt to merge the original, but pared down somewhat, and Lightmouse's new wording (modified in some cases where it lost important distinctions):

===Piped date links===
Avoid piping links from "year" to "year something" or "something year" (e.g., ]), in most cases. Use an explicit cross-reference, e.g. ''(see ])'', if it is appropriate to link a year to such an article at all.
  • Exceptions:
  • Piped links can be appropriate where width restrictions make unpiped links difficult to fit. This can sometimes occur in tables, infoboxes and lists. Example: Best Rock Album ]: ].
  • Piping may also be useful in the main prose of articles in which repetition of unpiped links would be difficult to read, as is often the case with sportsperson bios that link to numerous separate season articles.
  • Piped links must never be used in full dates (e.g. ], ]) because they break the date-formatting function.
  • When using piped links, especially in general prose, it is best to clearly indicate that the link is to such a topical date article, e.g. ...in ], rather than ...in ]. Some readers print out Misplaced Pages articles, so we do not use "easter-egg" links, that hide the nature of what they link to, as in ...since his ] to remain in the top 16.
  • Do not overlink; if a highly specific dated article exists, e.g. for an event, do not also link to the more general topical or regional one, as in the ] ].
  • A topical date link should only be used when the event in question is genuinely notable on an international level (or a narrower level appropriate to the nature of the date article, e.g. nationally in the case of 2007 in Canada), in the context of the year (or month, etc.) article to which it would link.

How's that?

Just to be clear, the point of all of this is to address all of the following:

  • Don't use piped links, generally
  • But you can use them where space is an issue, as in tables
  • And you can use them in prose when to not do so would annoy the hell out of the reader
  • This is really common in sports bios (and "sportsperson" was used instead of "sports" or "sport" to avoid the US/UK English conflict)
  • Don't break the date-formatting function
  • Don't obfuscate or mislead
  • MOSLINK has more info on this
  • People print this stuff, so it has to make sense w/o the link being available
  • Especially, don't "easter-egg"
  • Don't overlink
  • We have a guideline about that
  • Especially don't link the year to one thing and the descriptor to another (a common malpractice)
  • Don't link everything, only truly notable things (to address a very common malpractice)
  • Explain what "notable" means in this context
  • Provide examples so that editors know precisely what this section means and doesn't mean.

If it can't address all of these points, then it is leaving something out, and shouldn't, in my opinion. — SMcCandlish ‹(-¿-)› 18:40, 4 January 2008 (UTC)

  • Support I think the latest proposal covers all teh bases, and will be valuable. I remember when I first used (not edited) Misplaced Pages, how confusing those piped links were, and I'm the sort of user who regularly does look at the status bar to check link targets -- most don't. A bit of cleanup: remove the comma after the easter-egg links link, and I don't see why we need to split the infinitive in "to clearly indicate" (why not "to indicate clearly"?), but either way, I think this will be an improvement. atakdoug (talk) 04:20, 10 January 2008 (UTC)

Markup for the hard space: update

I am pleased to announce that we have a complete draft proposal for you to inspect, comment on, and modify.

Just go to the working group's development page, read the instructions at the top, and take it from there.

Or click "show" to see a draft, right here:

See a full draft of the proposal

User:Noetica/ActionMOSVP/StableWholeProposal

– Noetica Talk 07:05, 16 January 2008 (UTC)

Omegatron's recent changes to the main page involving binary prefixes

Omegatron has recently made some changes to the main page however Omegatron did not first discuss those changes, i.e. he did not gain consensus for those changes. Since his changes remove certain important portions of the guideline I am reverting them as is correct and proper. Fnagaton 14:54, 16 January 2008 (UTC)

The changes involved binary prefixes (diff here) —MJCdetroit 15:46, 16 January 2008 (UTC)
Moved from Omegatron's talk page:
Someone else just pointed out to me that you made this change recently. This change was not talked about and also includes changes that change the meaning beyond the consensus that was agreed. For example you completely removed the phrase "When in doubt, stay with established usage in the article, and follow the lead of the first major contributor." but your other changes also were not agreed. Please do not make such changes without talking about them first. Fnagaton 11:42, 16 January 2008 (UTC)


I'm sorry, but I'm not required to ask your permission before fixing a spelling error or smoothing the wording of a sentence. You don't own this page, and you don't make policy by yourself.

If you or anyone else has a problem with one of my small changes (such as clarifying the bit that was tagged with {{clarifyme}}, or moving "in 1999" to a different part of a sentence), improve on it by further editing the guideline directly, or discuss it here. Revert warring every change I made is antagonistic and unproductive.

As for the "first contributor" rule:

Without consensus for a site-wide guideline on the use of binary prefixes, the issue is decided on an article-by-article basis. If there is an issue with units on a particular article, that issue is decided on the talk page for that article. There is absolutely no reason why we would choose the "first contributor's" favorite style over one that makes more sense in a certain context.

I'm sure this was invented based on the English varieties rules. In these, the "first contributor" rule is a last resort, used when there isn't a better reason to choose one over the other. It's not a precedent to jump to whenever three people disagree with something, and it doesn't necessarily carry over to unrelated issues like units or punctuation or grammar.

The use of units isn't an issue where the differences are merely aesthetic and can be decided by an arbitrary rule. The different ways of using units have different purposes, and one may be more applicable than another in different contexts (just like British English is used in articles about Tolkien, even if the first contributor happened to prefer American).

If this really were the rule, it would enable editors like Sarenne or Fnagaton to go around creating articles in their preferred format and then telling others that it couldn't be changed because they were the "first contributor". (I wouldn't be surprised if this was the original intention behind trying to squeeze it into this guideline.) This is not how Misplaced Pages editing works.

Please try to edit productively and cooperatively. If you continue revert warring without justification, you'll be blocked. — Omegatron 15:50, 16 January 2008 (UTC)

First off, I am not revert warring, you are. I also note your attempts to write bad faith accusations, for example "I wouldn't be surprised...". My justification is that I am correctly reverting your attempts to change MOSNUM that do not have consensus. You have failed to show you have consensus for your changes. You don't own the page either and you don't make policy on your own either. You go far beyond fixing spells errors or "smoothing" other such content in the guideine, you removed parts which affect the content and meaning of the guideline and you did not discuss those changes. For example you changed "There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles to represent binary units" to "There is no consensus on whether to use the historical prefixes or the newer IEC standard in Misplaced Pages articles to represent binary units" and you are incorrect to do so since you do not demonstrate consensus. This is because you are trying to change the equivalent of "There is no consensus to use apples in Misplaced Pages articles" to "There is no consensus to use oranges or apples in Misplaced Pages articles", it is obvious you introduce an entirely new item along with an extra "or". Do not make threats of "blocking" just because you want to push through your edits that do not have consensus. You are the person who is acting against consensus here and you are at fault. I revert you because you do not have consensus to make those changes, that is also correct justification. If you continue to edit war I will report you for 3RR violation. If you think you have consensus for your changes that please do show diff of your discussions on the talk page. I checked your edits until the start of December, nowhere have you gained consensus for your changes. Your post above ignores the consensus that was reached. If you fail to show where you have consensus, by supplying any diffs from the last two months, for removing the "first contributor" rule then you admit, by default, that you are in the wrong here. Fnagaton 16:12, 16 January 2008 (UTC)
I have made a 3RR report against Omegatron because his edits are disruptive and warned him that any further reverts will be added to that report. Fnagaton 17:26, 16 January 2008 (UTC)

Too much text in the above. What is the specific complaint with Omegatron's edit? "Does not have consensus" is not informative, especially when only one editor seems to have any objection. Going to Talk first is not some mandatory requirement for every last edit. If you specifically object to some part of the edit, then state that objection succinctly and let's skip past this "block him, no block him" business. — Aluvus t/c 23:55, 16 January 2008 (UTC)

He changed the guideline in several places without talking about it first. For example:
  • He removed this section "When in doubt, stay with established usage in the article, and follow the lead of the first major contributor."
  • He changed "Most publications" to "Many publications".
  • He changed "There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles to represent binary units", basically he changed it from "There is no consensus to use X" to "There is no consensus to use X or Y".
Apart from completely removing a section the other changes he has made are language changes designed to try to lessen or water down the meaning of the guideline. The guideline has been stable in its current form for months now after the last round of binary prefix discussions which have been archived. To change it now in such substantial ways without talking about it is not following procedure. As for the "goingto talk is not some mandatory requirement" I'd disagree since on the guideline page is says "When editing this page, ensure that your revision reflects consensus. When in doubt, discuss first on the talk page". Of course for tiny spelling changes or changes that do not affect the substance of the guideline then talking about it is not usually required, however his changes go way beyond such tiny changes. Fnagaton 00:06, 17 January 2008 (UTC)


He changed the guideline in several places without talking about it first.

Editors are not required to "talk about it first" before editing a page, even a guideline. You seem to be confused about how editing works. If someone has a problem with someone else's edits, they discuss what's wrong with those edits (the content of those edits) and come to an agreement.

He removed this section "When in doubt, stay with established usage in the article, and follow the lead of the first major contributor."

This "first contributor" rule was added without any consensus support. It is inherently anti-consensus, as described above. There is no site-wide consensus on the use of units, so the issue is decided independently for each article.

He changed "Most publications" to "Many publications".

And?

He changed "There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles to represent binary units", basically he changed it from "There is no consensus to use X" to "There is no consensus to use X or Y".

Unless I'm mistaken, there is no site-wide consensus on which system to use. Do you think that there is? What, specifically, is wrong with this wording?

the other changes he has made are language changes designed to try to lessen or water down the meaning of the guideline.

????
The only substantial change here is the removal of a clause snuck in without consensus support. If you have a problem with the other changes, edit them further or discuss why you have a problem with them, instead of just claiming that I haven't followed some imaginary procedure for making edits to guidelines. You might want to read through Misplaced Pages:Consensus first. — Omegatron 02:50, 19 January 2008 (UTC)
The fact is you made changes that do not have consensus which is against what it says at the top of the guideline page "When editing this page, ensure that your revision reflects consensus". Where did you ensure your edits have consensus? You did not, you are wrong. The discussions here and on your WP:ANI entry show that your edits still do not have consensus. I note you failed to show diffs for your attempts to show any kind of consensus for your changes. "If someone has a problem with someone else's edits, they discuss what's wrong with those edits (the content of those edits) and come to an agreement." is just an attempt to stall the process and leave your edits on the guideline longer than they should be. I did try to get you to talk about your changes by pointing out your lack consensus and putting an entry on your talk page saying you should talk about these changes first and you still insisted on revert warring. "The only substantial change here is the removal of a clause snuck in without consensus support." you are completely wrong for the reasons already given. The truth is that it does have consensus but that you disagree with it, your lone disagreement does not alter the fact it does have consensus. The guideline has been stable for months before you came along and tried to change it on your own. You are in the wrong here and at the very least you should apologise for your actions. Fnagaton 10:39, 19 January 2008 (UTC)


Fnagaton: Please address what you think is wrong with the content of my edits. Consensus is decided by people addressing the content of each other's edits and discussing them. It is not decided by vote, or majority rule, or revert warring, or "procedure", or wikilawyering. You need to address what, specifically, you dislike about my edits or you have not demonstrated consensus for removing them.

No one person, and no (limited) group of people, can unilaterally declare that community consensus has changed, or that it is fixed and determined. ... Misplaced Pages's decisions are not based on the number of people who showed up and voted a particular way on a particular day. It is based on a system of good reasons. Attempts to change consensus must be based on a clear engagement with the reasons behind the current consensus.

Here. I'll help you out by spelling them out for you so you can address each individually:

  • "introduced new prefixes including kibi-, mebi-, gibi- ... in 1999 " → "introduced in 1999 new prefixes such as kibi-, mebi-, gibi-..."
  • "Most publications, ... continue to use the historical binary units" → "Many publications, ... continue to use the historical binary units"
  • "There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles" → "There is no consensus on whether to use the historical prefixes or the newer IEC standard in Misplaced Pages articles"
  • "editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate" → "editors should not change prefixes from one style to the other if there is uncertainty"
  • "for example, "256 KB (KiB)" is acceptable" → "for example, "256 KB (KiB)" is also acceptable"
  • Removed "When in doubt, stay with established usage in the article, and follow the lead of the first major contributor" which is anti-wiki and was added by Fnagaton without consensus support so that he could go around overruling consensus opinion on individual articles.
  • Clarified what is meant by "some storage media", since there was a {{clarifyme}} tag on it.

That's all of the edits that you are revert warring without discussion. Please address each edit and explain what specifically is wrong with that edit. In other words, explain how the edit harms the project or misrepresents consensus on the use of units in Misplaced Pages. If all you're going to do is repeat "but you edited without discussing it first!" over and over, and revert all of my edits en masse without addressing what's wrong with them, then there's no point in me trying to discuss this with you further. — Omegatron 15:48, 19 January 2008 (UTC)

Firstly, you are revert warring I am not. You are being disruptive, I am not. This is shown by the comments here and on your ANI section. Learn from your mistakes. Secondly, you are asking the same questions that have already been answered. For the avoidance of any doubt I refer you to the answers I have previously given on this subject at 16:12 16 January 2008 and 00:06 17 January 2008 because those answers already fully answer the questions you have just made. Lastly, I demand that you retract your misrepresentation because I did not add "When in doubt, stay ..." because that part was added by User:Radiant!. Your edits as pointed out by myself and other editors are not wanted and that is one reason why you have been reverted. Another reason is that you do not have consensus for your changes. Another reason is that the guideline has been stable for many months. I don't know how it can be made any simpler for you to understand, you do not have consensus for your changes so do not make them. Fnagaton 17:16, 19 January 2008 (UTC)
If I were to copy your example I could right now make changes to the guideline to make it clear that IEC prefixes are not to be used. If you reverted those changes I could then throw my arms up in the air and claim you are edit warring and that you have to take it to the talk page before reverting any changes I just made. Obviously what you think on this subject is wrong and you are just trying to bully (by making your threats regarding blocking) and push your changes onto the guideline page regardless of the consensus. You are in the wrong here. Fnagaton 17:39, 19 January 2008 (UTC)
Omegatron I suggest you take time to think about your actions and step back from editing here and on my talk page for about a week, then come back and re-read all of the attacks and bullying you've made against me without any provocation. My talk page is not some place you can go to misrepresent me and this talk page is also not a place where you can misrepresent me. Quite frankly your tone shocks me and I hope that if you come back after a week cooling off period you will also be shocked at what you wrote. Fnagaton 18:31, 19 January 2008 (UTC)
I am not revert warring at all. I am trying to discuss the changes with you. You obviously refuse to discuss them, so we'll have to try something else. — Omegatron 18:43, 19 January 2008 (UTC)
You are wrong, I do discuss your changes but you then turn around and attack me instead of tackling the argument. I am still interested in discussing your changes but not when you are just going to attack me because as I have shown you are not interested in proper debate since you keep on attacking me here and on my talk page. You have been revert warring as well as violating WP:AGF by accusing others of revert warring when you actually do the reverts in the first place and now your edits are bordering on harassment because you continue to misrepresent me. I gave you a chance to retract and apologise for your misrepresentation and you did not. Consider this fair warning that if you are not interested in stepping back and taking a break from your repeated misrepresentation and attacks here and on my talk page then you will leave me no choice but to report you for harassment. Fnagaton 19:00, 19 January 2008 (UTC)

General IT prefix discussion

The IEC prefixes were approved in January 1999. After nine years, virtually nobody uses them. Esperanto is in wider use. When Steve Jobs introduced the MacBook Air (skinny notebook) at Macworld he did not use the term gibibyte once. The news reports give the RAM size as 2 gigabyte, 2GB or 2Gbyte. The Manual of Style should reflect what the outside world is doing. The computer industry and the publishing world have ignored the IEC prefixes. -- SWTPC6800 (talk) 06:09, 17 January 2008 (UTC)

Do you have any opinion on the topic that is being discussed here? — Aluvus t/c 13:02, 17 January 2008 (UTC)
Yes I do. A few peoples here are trying to get the Manual of Style to adopt an obscure method of measuring computer storage. This edit war has been going on for several years. You are arguing over the rules of the edit war. The real question is should the Manual of Style follow a standard that had not reached 1% adoption in the real world after 9 years. -- SWTPC6800 (talk) 14:52, 17 January 2008 (UTC)
Just let me extract the interesting parts of your text: "few people", "an obscure method of measuring computer storage", "war", "1% adoption", "real world". Hopefully people will realize how pointless this discussion is. Don't waste your time, don't let them trick you. As long as this topic is under tight control of certain individuals, you can't win. Again don't waste your time with facts. They shall be ignored, absolutely, without remorse. --217.87.122.179 (talk) 05:57, 2 February 2008 (UTC)
You are wrong and do not attempt to misrepresent other editors with your incorrect anonymous rants about "certain individuals". Fnagaton 10:03, 2 February 2008 (UTC)


Whether manufacturers are using these units is irrelevant. Fact is that the units are used inconsistently. Sometimes they have a binary meaning, sometimes a decimal one. Many of the readers wil not be aware which meaning is applicable in a specific mention of the unit. Therefore it is the task of an encyclopedia to make sure the reader is able to draw the correct conclusion. This can be achieved by always adding a conversion to (or a confirmation of) a standardised and well documented unit. We achieved consensus to do it that way a while ago. According to the guidelines units from a primary source should come first. So the usage would be:
  • with decimal meaning: 64 MB (61 MiB)
  • with binary meaning: 64 MB (=MiB)
−Woodstone (talk) 19:42, 17 January 2008 (UTC)
Fact, KB, MB, GB are defined by standards organisation to be power of two. Fact, some manufacturers use other meansing. Lets say for the sake of argument some manufacturers started using KiB but in a decimal sense, that would be inconsistent use, so what then? It's not *always* needed though, just disambiguate (if you need to at all) the first occurrence in an article. Fnagaton 22:18, 17 January 2008 (UTC)
Regardless of how inconsistent sources are, a conversion to standard units would always tell the user unambiguously what the correct meaning is. I agree that if the same number is used several times, one conversion might be enough. But it is just a welcome service to the reader to convert every number at least once. −Woodstone (talk) 22:31, 17 January 2008 (UTC)
I'm just going to quote "Fact is that the units are used inconsistently" and "Regardless of how inconsistent sources are" then grin for a while because I find it funny. ;) Seriously though the JEDEC, who are the standard organisation for memory and who have majority consensus, do define kilobyte etc in their standard. So which standard body is the better one to choose, the one that has a tiny 0.5% use (no consensus) in the real world or the one that has the huge majority consensus? And then if there is any use that differs from the JEDEC standard then make a point of disambiguating it with exact numbers of bytes. Fnagaton 22:56, 17 January 2008 (UTC)
I see your point about fun: it is funny: the more inconsistent usage is, the more there is a need for conversions. You may know exactly in which cases a particular interpretation is standardised by JEDEC, most people have never even heard about JEDEC. Why not help them by addding a conversion? −Woodstone (talk) 23:03, 17 January 2008 (UTC)
Because according to the JEDEC it's not inconsistent, it is powers of two in size. Following on from the above I could point to companies using KiB but in the decimal sense. Then I could say "inconsistent" and then you'd have to drop pushing for KiB to be used, to ape the arguments used by some IEC supporters for example. Pushing for a particular style of prefix isn't actually the point, as we'll see in a second. What happened is that some other "standards organisation" came along and invented a new term, but it's not used except by a microscopic minority. However the question isn't about what standards organisation is best or whatever, no matter how tempting that is it doesn't actually tackle the real issue and it just causes people to sit behind their preferred camp. Remember you cannot say IEC is consistent since it has been shown IEC is inconsistent with the consensus in the real world. Also remember you cannot say IEC is not ambiguous because of the companies that use KiB in the decimal sense and also because JEDEC define it to be not ambiguous. The question is, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 23:09, 17 January 2008 (UTC)
Well, a kilobyte appears to be 2 raised to the power 10 (=1,024) in most systems and one megabyte can be either 1,000 kilobytes or 1,024 kilobytes; it gets a bit difficult to determine how many bytes there are in a particular wiggit. Some system is need to sort it out. I've lost track of the arguments, what's your proposal to sort it out - I don't think context is a valid approach.Pyrotec (talk) 23:45, 17 January 2008 (UTC)
The most common use being power of two. The only non-ambiguous way which also doesn't use neogolisms, i.e. is consistent with consensus, would be the following: Follow JEDEC or be consistent with the sources relevant to the article. If something uses JEDEC specified prefixes but in a non-standard sense then use the units found in the source but disambiguate by stating the exact number of bytes in brackets. Otherwise (and rarely) if some other units are used (like IEC) in the article due to being consistent with sources then disambiguate with JEDEC. Fnagaton 00:00, 18 January 2008 (UTC)
Or we forget it all for now and just make sure the guideline stays as it is in its stable state. Fnagaton 00:02, 18 January 2008 (UTC)
There is some confusion on binary versus decimal units of computer storage. However the computer industry and the technical press do not think is significant enough to change to a new units system. Fnagaton is very generous to say that the IEC prefixes have 0.5% acceptance. The industry treats kibi and gibi as something the IEC made up one day. It is not Misplaced Pages's mission to promote a failing standardization effort. If the IEC binary prefixes gain significant support Misplaced Pages could consider using them. -- SWTPC6800 (talk) 01:55, 18 January 2008 (UTC)
It is Misplaced Pages's mission to provide clear and accurate information to the general readership. If unit like MB is met, it is never obvious what quantity this represents. Usage depends on the context (e.g. disk, memory chip, data tranfer). Many people do not know which is used when, and even less what JEDEC is and if it applies to the particular occurrence of the unit. The solution is giving a conversion to a world standard. Even if that standard not often used, it is still well documented and unambiguous—just what is needed to eliminate uncertainty. −Woodstone (talk) 09:33, 18 January 2008 (UTC)
Woodstone, as explained above what you see as "never obvious" is a red herring because what you call "the world standard" is not actually a "world standard" and it is not unambiguous. The real question is this, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 12:04, 18 January 2008 (UTC)
No, the real question is: how can we inform the reader clearly and unambiguously about the meaning of quanties given. Just using MB does not do that, because its meaning is context dependent. So what device are you proposing to achieve the goal of being informative. −Woodstone (talk) 12:41, 18 January 2008 (UTC)
Like I said above, express the exact number of bytes as disambiguation in brackets. For example 2KB (2 bytes) is the only unambiguous way of stating the number of bytes without using neologisms and it also shows that in this case it is using the binary context. Fnagaton 13:27, 18 January 2008 (UTC)

(unindent) That makes sense. Perhaps more recognisable would be to use only multiples of 3 for decimal and of 10 for binary powers:

  • with decimal meaning: 64 MB (64×10 bytes)
  • with binary meaning: 64 MB (64×2 bytes)

−Woodstone (talk) 16:15, 18 January 2008 (UTC)

I really like the way this is heading, if it can be made to work. If there were such a guideline, I wonder whether it would actually be followed though. I think it is worth trying. Thunderbird2 (talk) 16:30, 18 January 2008 (UTC)
Yes using 2 and 10 notation would make it completely unambiguous and it also gives a very good hint as to what format is used for binary or more rarely decimal. Also it lets articles use the type of units that are used in the sources. Which is a bonus since maintaining consistency with sources as well as following the real world consensus is a really important issue for me and I suspect many others think the same. Of course as with disambiguation it need not be everywhere, just so that the article makes sense. Fnagaton 17:00, 18 January 2008 (UTC)
The suggestion appears to have some merit. Note: powers of three in decimal, e.g. 10, means that everything is rounded in thousands; and powers of ten in binary, e.g. 2, means that everything is rounded in kilobytes (=1,024).Pyrotec (talk) 17:11, 18 January 2008 (UTC)
I'm not sure how many readers wil be comfortable with this notation. In any case, I think what is being suggested is that for the binary meaning of the prefixes, it should be written as a power of 2, where the exponent is a multiple of 10. For the decimal meaning of the prefix, it should be written as a power of ten, where the exponent is a multiple of 3. --Gerry Ashton (talk) 17:28, 18 January 2008 (UTC)
I'm not sure whether Gerry Ashton's comment relates to my comment above, or an early one. My comment related to a question by Fnagaton which has since been edited, so it reads differently now & is no longer a question. My interpretation of Woodstone's comment, was a sequence of thousands & kilobytes, e.g 0.02*10, 0.2*10, 2.0*10, 0.02*10, 0.2*10, 2*10, etc, and a similar sequence for kilobytes (sorry I'm too lazy to do the binary sequence in kilobyte sequences). But if someone wants to see it?Pyrotec (talk) 17:43, 18 January 2008 (UTC)

Yes, of course. Very simple: keep the number as it is (no rounding needed) and convert, depending on context:

  • KB to ×2 bytes or ×10 bytes
  • MB to ×2 bytes or ×10 bytes
  • GB to ×2 bytes or ×10 bytes (etc)

Furthermore, it is not very important if all editors follow up on the guidelines. There will always be volunteers that will add proper conversion. Having it in the MOS will hopelfully prevent reversions. We still have to find a way out of the occasional MB = 1024,000 bytes. −Woodstone (talk) 18:03, 18 January 2008 (UTC)

How about: "This memory stick from company X is labeled as 1MB (1024×10bytes)" Fnagaton 18:09, 18 January 2008 (UTC)
How about: "This memory stick from company X is labelled as 1MB (2×10bytes)" (not "*" as above). Rich Farmbrough, 14:03 1 February 2008 (GMT).
or "This memory stick from company X is labelled as 1 MB (1.024 million bytes)" Thunderbird2 (talk) 14:10, 1 February 2008 (UTC)
No. These are the worst options. In one regard it fails as soon as you get to a billion and especially beyond because US and European billion differ. The next higher magnitude which will be common in 2-4 years (tera respectively tebi) has no layman equivalent. If you write "1 MB (2^30 bytes)" any sensitive reader would assume that 1 MB is always exactly 2^30 bytes. There is no reason to assume a unit would differ depending on context. The solution is very simple, use units correctly or don't use them at all. If a unit has supposedly more than one meaning, it is by definition not a U-N-I-T. unit comes from unity. No unity, no unit. Kindergarten logic suffices. --217.87.122.179 (talk) 06:07, 2 February 2008 (UTC)
You are wrong 217.87.122.179 because the units are de facto standards used in the real world and Misplaced Pages is descriptive not prescriptive. To use neologisms that are very rarely used in the real world (<1%) only confuses the matter even further. Fnagaton 09:53, 2 February 2008 (UTC)
He is right in so far that the IT industry’s adoption of metric prefixes, beginning 40 years or so ago, in a different than standardised sense is the root of the problem. Only that made ambiguity possible. Separate binary prefixes should have been developed back then, but they weren’t, leaving us with the mess.
You are right that Misplaced Pages is descriptive – in intention at least, by its importance and influence nowadays, being part of the real world, it is defacto quite prescriptive! –, but you are also wrong, because its style guide, unlike encyclopaedic information, has to be prescriptive to some degree. MOS may very well choose to adopt a rule by reason that would not have been derived from observing common usage. IT prefixes used to be such a case, where MOS editors came to the conclusion that it’s better to diverge from common and source usage, adopting an international public standard instead to make the project less ambiguous and more homogenous. Some months ago this changed (after epic-length, tiresome discussions), because some article authors, like you, didn’t like to adapt their habits. The descriptivism myth evolved.
You are also wrong in that you didn’t respond to any of the points the IP user raised; just called him wrong, repeating your weak arguments once again. He does have at least one very valid argument: “There is no reason to assume a unit would differ depending on context.” — Christoph Päper 14:07, 2 February 2008 (UTC)
The IP user and you are wrong because it is fallacious to try to claim something is "different than standardised sense" just because a so called standards body decides to produce something contrary to what is the de facto standard. You are also wrong because the MOS is not prescriptive beyond what is actually common sense. You are also wrong because I did respond to the "points" the IP user raised, you will note this is the case since I wrote "because the units are..." giving a perfectly valid and correct reason. What you claim is the IP user's "valid argument" is actually shown to be a red herring by the very fact that the units have well known use. You are also wrong because the arguments put forward by me are stronger than what you have put forward and just because you disagree doesn't mean you are correct. Actually I'm giving you the benefit of the doubt here because you have put forward no such counter argument, instead you have attempted to question my motives and claimed a valid logical reason is somehow "repeating your weak arguments" without giving any supporting evidence. You are also wrong in your summary of the history of this topic and I demand that you retract your misrepresentation about what you think my motives are. Fnagaton 18:39, 2 February 2008 (UTC)
The IP user raises only one valid point, that even more confusion will arise when larger memory becomes available. In respect of (computer) memories, in the real world units do change depending on context - read the discussions above: a million can mean 1024 x 1000 and 1024 x 1024 depending whether is a megabyte of storage on a hard drive, memory stick, etc - go and look at amazon.com. The IP user appears to be confused, it is not misuse of units in wikipedia that causes problems it is inconsistent use of units in the computer industry that causes the problems. Misplaced Pages MOS is attempting to add clarity to the confusion that already exits.Pyrotec (talk) 19:52, 2 February 2008 (UTC)
I've changed my view upon reflection. The computer industry uses megabytes, Gigabytes, etc, the difference in UK and US definitions of a billion is irrelevant as it is unlikely that billion will be used as a description of the number of bytes.Pyrotec (talk) 20:20, 2 February 2008 (UTC)
Indeed, that's what I meant when I said earlier the point put forward "is actually shown to be a red herring". It's like saying "the sky is blue and that proves that I'm right about cell meiosis". Fnagaton 20:35, 2 February 2008 (UTC)
No, you didn't mean that. If you read carefully, the term billion was only a part of argument. Calling it a "red herring" makes clear that you assume bad faith, especially your "sky is blue..." blah blah shows that you are interested in facts or any kind of useful discussion. There actually over 120000 Google hits for '"billion bytes" -wikipedia'. I don't know which formula Pyrotec used to determine his assumed probability but I'd think we can all agree that this isn't the right place for speculation about the future. For the record, a billion bytes is in US-American English equivalent to a gigabyte, that's why it's already in use. I was talking about Terabyte (tera means 10^12) which is less common for now and which has no well-known -illion equivalent. So it'd be called 1000 billion or a million million but nobody knows what's the marketing industry is going to establish. Nonetheless "billion bytes" is actually used despite the assumed low probability.

A duty of disambiguation

There are many units in common use that have slightly different meanings, depending on the context. Some examples, to name but a few, are gallon, megabyte, mile and ton. A specialist will be aware of the ambiguity and can often tell which meaning is intended. We are not writing for specialists though, but for a general audience that may not even realise that an ambiguity exists. The onus is on WP, and by implication on its editors, to make it clear from the outset.

Someone (it may have been Gene Nygaard) made the comment a while back that we should not forget our own real world knowledge just because we are writing for WP. I agree with him; we should use that knowledge to make WP less ambiguous.

Let me give an example to illustrate my point. The most common meanings of the unit ‘ton’ that I know of are long ton, short ton and metric ton. With or without context, I would have no idea which was intended myself in each case (and I imagine the same holds for our average reader). But an expert editor, familiar with standard practice in the shipping industry, would know that (TomTheHand, 2 Dec 2007)

  • ‘U.S. naval ships use long tons (2,240 lb), not short tons (2,000 lb) or metric tons (1,000 kg) (except for the very newest ships, which do use metric tons). Metric tons, or tonnes, abbreviated "t", are often used today by European navies, and are not the same thing as "short tons," which are the 2,000-lb tons used in the U.S. civilian world.’

Now, let’s say that an expert editor is editing an existing WW2 article about a US naval ship. He’s an expert so let’s assume he knows that the word “ton” means “long ton” in this context. Well, in that case our expert editor can improve the article by stating on first use that by “ton”, “long ton” is intended throughout, and WP will have improved by becoming an iota less ambiguous.

Specifically, what I would like to see is something like this:

  • Editors are encouraged to identify and define ambiguous units on their first use in an article.

On its own a link to ton would not be enough. That points out the ambiguity but does little to help the reader work out which meaning is being used. A simple statement on first use like “The ship's displacement was 2,000 tons (long tons)” would suffice in most cases. The bullet could be followed by a helpful list of ambiguous units in common use. Thunderbird2 (talk) 22:09, 17 January 2008 (UTC)

When updating ship articles, I usually link my first use of "ton" to "long ton", but I have not stated outright that I'm using long tons. I do this because sources on the topic almost always use ton to mean long ton without explanation; I think it's simply taken for granted that in the context of displacement "ton" means 2,240 lb. However, I can see how simply linking is not as clear as it could be, and Thunderbird2's proposal would not take much extra space or time.
I am concerned about cases like this displacement figure from the infobox of USS Gato (SS-212):
1,525 tons (1,549 t) surfaced
The following, which is in line with Thunderbird's proposal, looks awkward to me because of the two parenthetical entries side-by-side:
1,525 tons (long tons) (1,549 t) surfaced
Not a big deal, but I welcome suggestions about how to make it look better and still be unambiguous. TomTheHand (talk) 22:32, 17 January 2008 (UTC)
How about making it "1,525 tons (long tons, 1.549×10 kg) surfaced"? No need to link to standard units. −Woodstone (talk) 22:42, 17 January 2008 (UTC)
I don't think that kilograms are appropriate. They are not usually used to measure the displacement of ships, while metric tons are commonly used for that purpose. I believe metric tons/tonnes are uncommon enough to benefit from linking. I feel that your suggestion is also awkward. You're including two different types of information in parenthesis: what units you meant when you said "tons", and a metric conversion. To me it's jarring. TomTheHand (talk) 22:51, 17 January 2008 (UTC)
(edit conflict) Why use a million kg? "1,525 tons (long tons, 1,549 tonnes) is far more convenient.Pyrotec (talk) 22:55, 17 January 2008 (UTC)
As is apparent from the above, a "ton" is ambiguous. A "kg" is not. A link alone is not obvious enough. That's why using "kg" is clearer. To avoid the jarring effect of two different kinds of information in one pair of brackets and avoid having two bracketed expresssions next to each other, one could use: "1,525 (long) tons (1.549×10 kg) surfaced"? −Woodstone (talk) 09:22, 18 January 2008 (UTC)
I disagree in part. There is confusion over the ton, it boils down to the differences between the number of pounds in a ton in the UK and US definitions. There is no confusion over the tonne, which is an accepted metric unit, but not an SI unit, representing 1,000 kg. In the UK, a one ton is 2,240 pounds, so "1,525 tons (1,549 tonnes)" or even "1,549 tonnes (1,525 Imperial tons)" is a far more logical approach than "1,525 tons (long tons, 1.549×10 kg). Even the "short ton" and the "long ton" are relatively unusual terms, as the metric tonne is more common. Forcing the use of millions of kg instead of the more usual thousands of tonnes, is taking the use of SI units to nonsensical extremes.Pyrotec (talk) 11:16, 18 January 2008 (UTC)
1,525 long tons (1,549 t)
1,525 long tons (1,549 Mg)
1,525 long tons (1,549 tonnes)
1,525 tonslong (1,549 t)
1,525 tons2240 (1,549 t)
1,525 tonsL (1,549 t)
…
But I thought the point of this section was a broader one; to get to a general rule on ambiguity from which specific or exemplary ones would be derived. (Probably inspired by the narrowed IT prefix discussion above.) Christoph Päper (talk) 13:08, 18 January 2008 (UTC)
Looking at it carefully, I think that TomTheHand's original version (1,525 tons (1,549 t) surfaced) already meets the proposed guideline, because it includes a conversion to the unambiguous unit tonne. As Crissov suggests though, I was hoping for a discussion on the principle rather than detailed implementation. If that is generally accepted, what about the detailed wording? Thunderbird2 (talk) 17:29, 18 January 2008 (UTC)

ISO birth/death dates in biographies

What's the preferred way of doing birth/death dates? Misplaced Pages:Manual of Style (dates and numbers)#Dates says ISO dates are not common within prose but the birth/death dates in the first sentence of a typical biography — "Joe Bloggs (January 1 1900 – December 31 1980)" — aren't really prose per se. On the other hand, Misplaced Pages:Manual of Style (dates and numbers)#Dates of birth and death doesn't give any ISO examples either. What is the community consensus about this? Thanks. howcheng {chat} 01:34, 18 January 2008 (UTC)

  • I commonly use ISO dates for birth/death when I create a new bio article. I always thought if someone didn't like how that looked they could always just change their date preferences to have it appear in the format they prefer. Snocrates 03:24, 18 January 2008 (UTC)
    • I would consider the dates birth/death dates to be part of the articles' prose, and putting them in ISO format will jar the large numbers of non-logged-in readers who use Misplaced Pages and therefore don't have preferences set. -- Arwel (talk) 08:50, 19 January 2008 (UTC)
That's not a bad question—I would consider those dates to be part of the prose, even if they are in parentheses, because they are part of what is read by the reader in the prose (as opposed to, say, a table). Neonumbers (talk) 10:35, 27 January 2008 (UTC)

How to list assumed / adopted birthdays

Per Mustafa_Kemal_Atatürk

  • Mustafa Kemal Atatürk, born Ali Rıza oğlu Mustafa (May 19, 1881 (adopted) – November 10, 1938)

How should an assumed birthday (which may be correct), be listed? -thanks Byzerodivide (talk) 01:44, 19 January 2008 (UTC)

I would use "c. 1881" and explain in the article. I wouldn't use the word "adopted". Readers might think his birth date is unknown, but he was adopted by people who were not his natural parents on May 19, 1881. --Gerry Ashton (talk) 01:59, 19 January 2008 (UTC)


Discussion of the hard-space proposal

Editors are invited to join a discussion at WT:MOS. We present the working group's completed proposal for new hard-space markup, and call for your suggestions.

– Noetica Talk 03:46, 21 January 2008 (UTC)

Single-digit centuries

An editor has recently changed "9th century" to "ninth ..." and several similar changes, in Bath, Somerset. MOSNUM says "Use numerals for centuries (the 17th century); do not capitalize century. " The example isn't as powerful as it could be, as "17" would be written as a number in any case. Could we change the wording to "Use numerals for centuries (the 9th century); do not capitalize century."? PamD (talk) 00:43, 27 January 2008 (UTC)

Sounds good to me. Tony (talk) 01:23, 27 January 2008 (UTC)

Measurement query

Which of these is correct: "the 5 mile (8 km) road" or "the five-mile road"? Thanks. Epbr123 (talk) 19:35, 29 January 2008 (UTC)

It depends; what article are you thinking of putting it in? --Gerry Ashton (talk) 19:38, 29 January 2008 (UTC)
I made these changes to Tumbler Ridge, British Columbia, but I'm not sure if I was right. Epbr123 (talk) 19:43, 29 January 2008 (UTC)
Spelling out the number is correct for small numbers. The hyphen between the number and the unit is not addressed in Misplaced Pages's Manual of Style, as far as I can see. A style guide from NIST says "When a metric value is used as a one-thought modifier before a noun, hyphenating the quantity is not necessary. However, if a hyphen is used, write out the name of the metric quantity with the hyphen between the numeral and the quantity." The Misplaced Pages MOS allows, but does not require, two word numbers to be spelled out (for example, fifty-six). If a hyphen were also used for the unit, the result might look awkward (for example, fifty-six-kilometre road), so I wouldn't use the hyphen except in situations where there are several numbers near each other, and I want to avoid confusion. --Gerry Ashton (talk) 20:10, 29 January 2008 (UTC)
Ok, thanks. I'll revert the changes I made. Epbr123 (talk) 21:33, 29 January 2008 (UTC)
The hyphen is discussed. Numbers are spelt out but this is a distance we're talking about here. General practice (at least on WP) is to write measurements out in numeral form, though spelt-out forms seem to be acceptable. Thus use either "the 5-mile road" or "the five-mile road". As for the metric conversion, why not include it? Conversions are generally not spelt-out (neither the numerical value not the unit name). Hyphens are not used abbreviations so the above would become either "the 5-mile (8 km) road" or "the five-mile (8 km) road". Jɪmp 01:46, 30 January 2008 (UTC)

Non-breaking spaces in citations

Actually, ridiculous; the kind of overkill that gives MOS a bad name. I'm seeing citations throughout articles cluttered up like this:

  • <ref>Rubin, pp.nbsp;42–55</ref>

per this addition to WP:NBSP:

  • With page numbers, p. or pp. should be followed by a non-breaking space. Similarly for related numbers (like series, volume, section), in citations and in text.

The point of a non-breaking hard space is to prevent line wrap. There is no chance these short ref lines will ever wrap, and the addition of NBSP is an unnecessary burden to the editor. This kind of MOS nit-picking irritates editors. SandyGeorgia (Talk) 17:30, 30 January 2008 (UTC) Please simplify; short citations don't need nbsp. SandyGeorgia (Talk) 17:32, 30 January 2008 (UTC)

Wholeheartedly agree./ Well said, --ROGER DAVIES  18:41, 30 January 2008 (UTC)
The more I think about it, I don't think we need nbsp on longer citations either; it's just an unnecessary editing burden. They are citations; let 'em wrap. SandyGeorgia (Talk) 18:56, 30 January 2008 (UTC)
Support (unless this will cause Sandy to change her mind ;->). Septentrionalis PMAnderson 19:09, 30 January 2008 (UTC)
I very much agree. Unless this will cause PMA to change his mind :) Haukur (talk) 19:48, 30 January 2008 (UTC)
Is that a double negative?  :-) SandyGeorgia (Talk) 19:49, 30 January 2008 (UTC)
I agree. Let them wrap. It is totally unnecessary clutter. Gene Nygaard (talk) 21:28, 1 February 2008 (UTC)
Thank you for bringing this up Sandy. This is a new change (I think) and it is a royal pain in the behind that doesn't provide an obvious value to the readers. Karanacs (talk) 20:39, 30 January 2008 (UTC)
I'm sorry I didn't notice it sooner (bad month :-); I actually first saw it mentioned in one of your reviews, Karanacs, and today I saw the awful effect at Ernest Shackleton. Everyone knows I'm a strong MOS enforcer, but this sort of absurdity turns editors against MOS and is just an unproductive burden on editors. SandyGeorgia (Talk) 20:42, 30 January 2008 (UTC)
I am delighted that people are now speaking out against excessive use of the nbsp. Line wrapping is a *good* thing and is vital for small screens. Lightmouse (talk) 21:19, 30 January 2008 (UTC)
Yes. Leave this insanity and mind-numbing inanity to software. From small screens to large screens, there are different choices to be made with regard to nbsp. Either way, this detracts from creating quality articles.-BillDeanCarter (talk) 21:28, 30 January 2008 (UTC)
Part of this problem with the overuse of non-breaking spaces results from an earlier undiscussed changed in wording which was sneaked in during some shenanigans about combining MOSNUM with the main MoS page and then back again, if I recall correctly.
The current vague wording about "numerical and non-numerical elements", whatever the hell that is intended to mean, can be interpreted in various ways. It used to deal with a space between a number written in numerals (not in words) and a unit symbol (the standards people like to distinguish these symbols from language-dependent "abbreviations") in measurements. That isn't so bad, except for being based on naive assumptions that we don't ever have measurements more complicated than "57 ft" and the like.
What changed after the rewording is a bunch of editors now running around and insisting on slapping in non-breaking spaces in many cases where they are totally unnecessary, such as
  1. Between a numeral and a spelled out unit of measurement: 37&nbsp;kilometers
  2. Between a spelled out number and a spelled out unit of measurement (or a symbol, but while MOSNUM may not proscribe such usage of numbers in words with units in symbols, it is highly frowned upon by most measurements standards)
  3. In cases not involving units of measurement (there may be some where nbsp would be appropriate; the problem is the editors who insist they should be there in all such cases): five&nbsp;sheep
But both the old version and the current version entirely fail to address the real places where non-breaking spaces should be used in measurements:
  1. There should be no break within a number itself: 0.453&nbsp;59 kg, 15&nbsp;3/8 in.
  2. There should be no break within the unit symbols: 23.73 J&nbsp;mol&nbsp;K
But there is really no big reason not to allow a break between the "numerical" part and the "non-numerical" part. In fact, with a fairly long number and a unit comprised of a fairly long string of symbols as in my last example, between the numerical element and the non-numerical element is the only logical place for a break to occur. Note that neither of these cases are "between numerical and non-numerical elements"; one is between two numerical elements, the other between two non-numerical elements. Gene Nygaard (talk) 21:57, 1 February 2008 (UTC)

On a separate issue, something needs to be done about these ongoing changes so that they will at least be noticed on a regular basis to WT:FAC. Who knew such an absurd change was put in place? I didn't know until I saw it in a Karanacs FAC review, and I thought I followed MOS pretty closely. SandyGeorgia (Talk) 20:55, 30 January 2008 (UTC)

Sandy, since that is a separate issue it should be raised separately. I hope you will put in a separate section – not here, but at WT:MOS. The matter of such notifications is very important, as I have agreed before. But it is general, and therefore not a matter for WT:MOSNUM.
Now, about your recent edits here (replicated at WP:MOS). The first sentence concerning non-breaking spaces was, and remains:

In compound items in which numerical and non-numerical elements are separated by a space, a non-breaking space (or hard space) is recommended to avoid the displacement of those elements at the end of a line.

This still requires that a hard spaces be applied in p. 5, Vols. 3–5, and all similar items, just as much as it applies for Charles II. In all of these the first element is non-numerical and the second is numerical; but the same principle applies for Jnr appended to a name, and between initials if they are separated by a space (see for example New Hart's Rules 2.5.1, and CMOS 7.40). By a perfectly rational extension it applies in a wide range of other cases. We have not covered these at MOS, but perhaps we should, to accord with common practice and the consensus of the major style guides. Most of all, we need these guidelines because the text we produce is dynamic, and also because no one can predict how it will appear at any particular viewing.
That is why little discussion was needed for the material that you deleted (without discussing first). It was merely an inevitable consequence of a principle that we had there already. You have removed a clarification.
If it is to be deleted, let's also delete the root guideline that it interprets, and not call for hard spaces at all. I'll delete it now, since its inevitable consequences are deleted. If we are to reinstate anything, let it be this guideline with its clarifications, or nothing. Clarity and consistency.
– Noetica Talk 22:06, 30 January 2008 (UTC)
Amended above. Not deleted, in fact: Sandy's edit has been reverted as undiscussed.
– Noetica Talk 22:14, 30 January 2008 (UTC)
We don't need nbsps in citations. Where is this discussion which caused this to be added? I'm seeing some mention in lots of places about discussions occurring off of these talk pages; that should stop. Who proposed this? Something like this has such an impact on people who actually write articles, that it doesn't appear that this proposal was generated by or reviewed by people who contribute a lot of content. We had no problem with MOS before this addition; simply deleting the new wording is no isssue. There's no need to complicate this with verbosity; there was no problem with the previous wording. SandyGeorgia (Talk) 22:10, 30 January 2008 (UTC)
Sandy, you seem not to have read what I took the trouble to say in thoughtful response to you. Have another look. There has been scattered discussion, yes. But essentially the guideline already ruled on page numbers and the like. The text you removed simply clarified that. Why do I bother to explain, if my explanation is not read?
– Noetica Talk 22:20, 30 January 2008 (UTC)
Brevity helps :-) The guideline didn't rule in practice; I spend most of my editing time in ref cleanup and I had never seen an nbsp in a citation until this week. SandyGeorgia (Talk) 22:22, 30 January 2008 (UTC)
Disagree it's overkill. (after several edit conflicts) Having the abbreviation and number separated by a space, but not a line just makes pleasant reading and good looks. The small effort needed from the editor is worth it. There is no requirement that every editor inserts the hard space. Just enter references as you like and some other editor with more liking for such details will polish it later. −Woodstone (talk) 22:12, 30 January 2008 (UTC)
From someone who probably does more citation/reference cleanup than any other editor I know, it is not a small issue. It's massive and unnecessary. We're not talking about readability of text; we're talking about cluttering already difficult to write citations with something that provides very little return. MOST citations don't wrap because they're short. SandyGeorgia (Talk) 22:15, 30 January 2008 (UTC)
And when the first editor comes back to the article it now has some ugly unnecessary html code. We should try to make the way our pages look in edit mode more accessible to new editors, using nbsp is a step away from that. Haukur (talk) 22:17, 30 January 2008 (UTC)
It is wholly unneccessary, and as someone who occasionally does ref clearup, I agree with Sandy. (If anyone would know the effort involved, it is Sandy). Woodstone, it looks good yes, but it would with or without the nbsp because those refs will virtually never wrap. Woody (talk) 22:21, 30 January 2008 (UTC)
  • Haukur gets to the point here; it produces unreadable html code to avoid a a quite rare problem. Depending on the phrasing, it may never occur (for example, if a paragraph begins "In Xanadu, l. 23, Coleridge...", it will be a very small screen indeed that will break before 23); and when it does occur, its effect is minor. If an editor wants to fix this, fine; but why mandate? Septentrionalis PMAnderson 22:28, 30 January 2008 (UTC)
Anyone who thinks it's easy, simple should look at a typical article like those I clean up at FAC/FAR. Check DNA or Gettysburg Address or Tourette syndrome and tell me that inserting nbsps would be easy and wouldn't completely destroy the readability of the citations. And, since you can't insert them into cite templates, it's foolish anyway. This is unnecessary make-work, to solve a non-problem. Simple solution; remove the statement, insert that the guideline applies to text, not citations. Fixed. The sooner the better please because this is affecting FACs. SandyGeorgia (Talk) 22:34, 30 January 2008 (UTC)
It is unnecessary if the line will not break, sure. So the suitable addition would be this: "unless there is no chance of the line breaking", or similar.
This will be the case in short citations, sure. And all of this would be much easier if we had simple, accepted markup for the hard space – which is exactly what I and other editors have been pushing for, at great cost of time and effort. It is interesting that we have had no support from those commenting above (including Sandy), who say that inputting and editing &nbsp; is a burden. We agree with them! But we are doing something about it, rather than simply ignoring the widely acknowledged need for the hard space.
– Noetica Talk 22:35, 30 January 2008 (UTC)
I was mostly involved in another matter for the last month. At any rate, whatever the proposal, we don't need it in citations. SandyGeorgia (Talk) 22:37, 30 January 2008 (UTC)
And I'm not convinced we need it in text. Most text will work out, most of the time, like the Xanadu example above. If an editor sees a problem on his machine, and chooses to fix it, fine; but I see no great advantage to parenthetical citations of the form "('']'' l.&nbsp;23)" either.Septentrionalis PMAnderson 22:48, 30 January 2008 (UTC)

(unindent) There are some things that both this MOS and external style guides agree, for example, numbers should not be broken if at all possible, numbers should be kept with abbreviations, and personal names should be kept with numerical suffixes. Departing from these rules requires consensus. If there is a consensus for citations but not for running text, this MOS should be modified accordingly; it wouldn't be appropriate to make a change because of awkward citation but fail to mention the change only applies to citations.

Personally, I don't think it will be much of an issue until Misplaced Pages and Wikimedia are repaired so there is a reasonable way to add and edit no-break spaces. (That's right, I regard the vast majority of the computer hardware and software that employ the Roman alphabet as defective with respect to no-break spaces, and in need of repair.) Until the repair is made, most editors will just ignore this MOS and use ordinary spaces. --Gerry Ashton (talk) 23:15, 30 January 2008 (UTC)

I can't figure out what position you're taking ("consensus for citations but not for text"?, it's the opposite), but FA editors won't ignore MOS, because it's part of WP:WIAFA. SandyGeorgia (Talk) 23:36, 30 January 2008 (UTC)
Which is why it should not be a part of WP:WIAFA. Septentrionalis PMAnderson 23:41, 30 January 2008 (UTC)
Reading through this whole conversation, I realise one thing...
...if the double-comma proposal passes, this entire problem will simply disappear—we shall suffer neither the intrusive HTML markup in the edit box, nor the loss of the hard space's advantages. I challenge the fellow editors to disagree with me (and prepare the umbrella I carry with me for all eventualities). Waltham, The Duke of 00:27, 31 January 2008 (UTC)
I have reverted recent changes that were made without consensus. What we had stood for a long time, and that, even by itself, is evidence that it was founded on consensus. Changes in recent weeks were simply informative (warning about the behaviour of {{nowrap}} or clarifying (pointing out immediate consequences the general principle given at the start).
It is not good practice to change the substance of a guideline until there is a new consensus. I call on editors to respect that well-established convention, which is enshrined at the very top of MOS pages.
I have also given this section an informative title, so that people will know straight away what we're talking about: now, and when the page is archived.
– Noetica Talk 02:24, 31 January 2008 (UTC)
The page was altered within the last month; it did not have long-standing consensus. Eight editors to two, so far, agree that the change was not a good one. You have reverted against consensus, to a change made without consensus. I'll place a disputed tag, since consensus isn't being respected and we can't have GA and FA writers chasing their tails on a make-work project. SandyGeorgia (Talk) 02:33, 31 January 2008 (UTC)
First, are you happy that we should change the name of this section to an informative one? I have taken the liberty of restoring my explained alteration which was reverted without explanation. Revert again if you like: but doing so will mean that people are not told what the section is about.
Second, you have ignored the explanation I have given directly above for those changes you refer to: they warned of a deficiencies in {{nowrap}}; and they helped by pointing out the direct consequence of the main principle in the section. If you want brevity, read what is said briefly. Otherwise I shall have to repeat, and explain at length.
Third, Sandy, you have not wanted instability and rapid changes at MOS. I agree! So please do not contribute to that capriciousness. Let's discuss, wait more than a mere few hours for discussion, and consider the consequences of any changes, so that we maintain rational consistency. And clarity.
– Noetica Talk 02:46, 31 January 2008 (UTC)
Noetica, let me be clear. Please see WP:TALK; do not alter other person's edits. The capricious change at MOS was to require arbitrary, silly, make-work nbsps on page numbers, which has GA and FA editors needlessly chasing their tails. We've gone over this already, consensus is clear, no need to keep repeating. SandyGeorgia (Talk) 03:06, 31 January 2008 (UTC)
Once more, Sandy, you show no evidence of having read or understood the explanation I have twice laid out here, in plain English. There is no point engaging in discussion if we don't read, think, and then respond.
– Noetica Talk 03:25, 31 January 2008 (UTC)
Sandy, concerning WP:TALK. Here is one guideline there: "Keep headings neutral: A heading should indicate what the topic is, but not communicate a specific view about it." This is further elaborated: "Don't be critical in headings: This includes being critical about details of the article. Those details were written by individual editors, who may experience the heading as an attack on them." You breached both of these principles, because (1) you did not indicate what the topic was, and (2) you were critical about details of the article in question. (Strictly, a page, not an article. But the meaning is clear.) For that reason I "refactored", conservatively and informatively. This is common enough when a meaning is not clear in a heading; I have recently been praised for it (see Misplaced Pages:Reference_desk/Language#Lithuanian).
I now ask you to remedy the error in the heading of this section yourself, according to established Misplaced Pages guidelines.
– Noetica Talk 06:34, 31 January 2008 (UTC)

I don't know where to put this, but I strongly agree with Sandy, and am glad she brought up the point. Very little return is provided by adding non-breaking spaces, most especially in short citations, and the readability and searchability of the wiki-text suffers tremendously. I've already been confused by the "&nbsp" once while trying to amend an article, unable to search out the text I saw on my screen in the wiki-text. –Outriggr § 01:16, 1 February 2008 (UTC)


Arbitrary break

This was added to WP:MOS (in 3 edits) and WP:MOSDATE at approximately 20:39 to 20:50, 31 December 2007. Where is the discussion for this? I don't see it Wikipedia_talk:Manual_of_Style#Non-breaking_spaces nor at User:Noetica/ActionMOSVP and subpages. Where did anyone discuss and approve changing the MOS to say nbsp should be used with page number? This edit summary calls this an "important case of the first ruling re numerical and non-numerical elements". A "ruling"? This seems to mean the first part of the nbsp section, which talks about "compound items", but it appears that one user applied this statement to a specific case that most WPians do not agree with. Gimmetrow 04:02, 31 January 2008 (UTC)

Would you like me to run through it yet another time, Gimmetrow? Perhaps at greater length?
There was no particular discussion at the time. The problem of hard spaces has come up in many guises both here and at WT:MOS, but without specific focus on the particular matter of page numbers (pp. 17–19, and the like) in recent months. The reason behind the edits that I made a month ago, at WP:MOS and WP:MOSNUM, was clearly stated at the time. You have cited one of my edit summaries. Here is another one: "Specificity: 'With page numbers, p. or pp. should be followed by a non-breaking space...' (important case of the first ruling re numerical and non-numerical elements". Now, this doesn't change anything of substance. It merely clarifies something we already had: "In compound items in which numerical and non-numerical elements are separated by a space, a non-breaking space (or hard space) is recommended to avoid the displacement of those elements at the end of a line." Since pp. 17–19 is such a compound item, it is already covered by that principle. All I did was make this clear! Is clarifying the same as editing without consensus? I had thought not.
As for User:Noetica/ActionMOSVP, this matter was never on the agenda at that page. Nor was it discussed there; nor would that have been a proper forum for establishing or changing consensus on the contents of MOS. The very focused purpose of that page is clearly stated at its head.
So I did not alter the substance, I only clarified what was entailed by the general principle in the section on the non-breaking space. If editors object to that principle, let's talk about that. If editors want to work out and list exceptions to it, let's talk about that. Let's do so bearing in mind established practice in good publishing, as condensed in the major style guides used in publishing. We need not adhere to established practice, of course. But at least let's take it into account as we deliberate.
Meanwhile, far from most Wikipedians disagreeing or agreeing about anything here, the vast majority do neither. None of this has ever occurred to them. The same seems to apply to developers. Generally speaking, they seem not to be experienced copyeditors who have studied major style guides. (Why should we expect that that are?) We have to work on this: analytically and accurately.
And then let's ask ourselves this: exactly what don't we like? The current clunky markup, or the fact that we have to use any sort of hard space? If it's the current markup, join in fixing that! Some of us are making a major effort to do that, and you have ignored it.
Why not all work together instead? First identify current problems – accurately! Then discuss ways of addressing them. Rationally, and not hastily.
– Noetica Talk 06:14, 31 January 2008 (UTC)
Great, you've "run though it" exactly as I described. You saw the point about "compound items", which is written in general terms. Those WPians aware of MOSDATE apply this to numbers followed by units, and that's about it. You applied it to page numbers, which you thought implicit in the general statement about "compound items". While your initial desire to specify what you thought the guideline said was fine, it seems pretty clear Noetica's specification doesn't have consensus among those commenting here. Gimmetrow 21:22, 31 January 2008 (UTC)
Support - I would agree as well. Since Firefox has a spell-check device, it would mark any word preceding nsbp; with a red underline mark. Now imagine a whole edit screen filled with those! It would be impossible to differentiate between "real" and "nsbp" spelling "mistakes." I'd say leave the nsbp's where they are (to change them all to spaces would in itself be overkill), but use only spaces in the future. -- King of ♥ ♦ ♣ ♠ 06:38, 31 January 2008 (UTC)
That is a weak argument, King of Hearts. Marked-up text is not ordinary text, and we should not expect a spell-checker to work with it in a standard way. Of course it will find all sorts of strange things to underline in red! To check the spelling usefully you should copy the standard output text into some place where it will be spell-checked, and inspect the results there.
So you are against all use of &nbsp;, and you would have a guideline suggesting that it not be used at all? Good to have your opinion recorded here!
But please: after discussion, let's have a specific, considered proposal for any change; and then let's support or oppose. Things are all over the place right now.
– Noetica Talk 06:51, 31 January 2008 (UTC)
Nothing is all over the place; the current consensus is quite clear, and the previous situation was clear. NBSP has never been used on page nos. I have an app't this morning, but will adjust the section heading later; what I object to was you changing someone else's heading without regard to the other places where it is linked. I'll fix them all later today. SandyGeorgia (Talk) 12:17, 31 January 2008 (UTC)
Sandy, I made that change before you imposed the tags that linked to this section.
– Noetica Talk 15:11, 31 January 2008 (UTC)
Noetica, are you having control issues over this section heading? I told you I had an app't, would be back, and would fix it; you've changed it again. It isn't only linked in the tag; it's linked at FAC and at the other MOS page. Do you mind? SandyGeorgia (Talk) 15:28, 31 January 2008 (UTC)
Sandy, please publicly withdraw the assertion that I have changed your heading which was in breach of WP:TALK, after your undertaking to fix it. It is wise to check the record first. Someone else made that change, probably for the same reason I had earlier. Please also withdraw the concomitant suggestion that I have "control issues". I have respected process throughout, and will continue to do so. I have explained and documented every move I have made, and these have been conservative and few. I have answered every point of substance, except perhaps where others have themselves refused to respond to what I have written, whether in summary or in detail.
– Noetica Talk 22:41, 31 January 2008 (UTC)
I see . I withdraw and apologize for the mistaken assumption, Noetica. The environment on these MOS pages is a huge timesink. I hope the point of not making endless nitpicky changes that affect FA writers and give MOS a bad name is registered, as well as the need to keep the FAC page apprised of major additions that affect most FAs (that may have seemed like a small change, but it had a major effect). SandyGeorgia (Talk) 23:58, 31 January 2008 (UTC)
Thanks Sandy. Accepted. As for nitpicking, one editor's nitpick is – notoriously – another editor's core issue. I have previously agreed with you about reform of process, so that everyone knows what's going on at MOS. I have called for a register of changes, to help with your FA work. The present unfortunate contretemps beautifully illustrates the need for changes in how we manage many things at MOS.
– Noetica Talk 00:16, 1 February 2008 (UTC)
Thanks for graciously accepting my apology. That's what I get for editing around an app't. SandyGeorgia (Talk) 00:20, 1 February 2008 (UTC)

I count fourteen people commenting, with eleven against the addition. Marskell (talk) 12:10, 31 January 2008 (UTC)

That's nice, Marskell. And relevant. But are those editors you count all addressing the same issue, in a uniformally considered way, having been been shown what the issue is, with its pros and cons? (How did you count Gerry Ashton's opinion? How did you count King of Heart's "vote"?) Is there a single clear proposal for the text? As it stood before the change that I made a month ago, simply for clarifying the implications, the effect of the section was exactly the same as after the change. Have you attended at all to the matters that I raise, and the complexity that others seem not to have discerned? And then, how can we even think that there is a proper consensus developing when this section is given a cryptic heading, so that editors scanning their watchlists are not alerted to the topic under discussion?
Very disappointing.
The questions I have just posed are not simply rhetorical. I await your answers.
I strongly suggest that anyone proposing a change to the current text put up a complete, coherent, alternative for discussion: in a new section with an informative title.
I for one will happily abide by any consensus that is rationally arrived at.
– Noetica Talk 13:43, 31 January 2008 (UTC)
Noetica, AFAICS, you changed the text. Sufficient consensus for the original insertion needed to be provided, and wasn't. We have just gathered comments: clearly people don't think it necessary. I have attended to the matters insofar as I have made thousands of mainspace edits, including many striving for MoS complaince. "Can you make this tedious change for little real benefit" is not something we need more of at FAC. Marskell (talk) 14:09, 31 January 2008 (UTC)
No, I did not change the meaning of the text. I provided clarification by pointing out what the principle given in the text entailed, explaining my action in a very full edit summary. No consensus is needed for clarifying something that needs clarifying, is it? (If we all did that all the time, there'd be no end of tedious talk.) Obviously, if people don't like those entailments, they ought to discuss the principle itself. Neither I nor anyone else can alter what in cold hard logic that principle has as a consequence: so let's address that principle itself.
If we read through this section, and look at the edits made during our discussion, we see that the ground has shifted. Sandy started by simply deleting the clarifying addition concerning page numbers and the like. Fine! That can be looked at. But then there was a very specific exception introduced instead: to exclude page numbers in a particular context. That is a substantial change, where mine was not as I have now explained more than once, without argument against me. For this reason I have called for clear and rational discussion.
– Noetica Talk 14:49, 31 January 2008 (UTC)
Noetica, I see how you thought that the text also applied to citations and page numbers, but in actual practice no one else has used non breaking spaces in citations. We have extremely experienced editors who know the ins and outs of the MOS bringing articles to FAC, and not once before this "clarification" was added did their citations include a nonbreaking space. I would argue very strongly that consensus on wikipedia (in the past and now), is that this rule does not apply to citations, and if clarification is needed in the MOS, it should explicitly state that this applies only to text, not to citations. As this is consensus (which the recent edits ignored), adding the exception should not require further discussion. Your addition says the opposite, which is against consensus. Karanacs (talk) 15:26, 31 January 2008 (UTC)
Further clarification: I'd prefer to have a specific exception for citations so that we don't run into this problem again, but I'll be happy with the original wording that didn't mention citations one way or another. Karanacs (talk) 15:29, 31 January 2008 (UTC)
I would like to add my voice to the growing chorus here. I have seen no good case made for nbsp in citations. And, I might add, it is the burden of those making the proposal to demonstrate that the change is necessary and beneficial. Awadewit | talk 15:39, 31 January 2008 (UTC)
Either works for me, but in any case, I think we're done here. A change was inserted that unfortunately put a couple of new FA writers through the wringer before we realized it, now we're back to normal (assuming someone has fixed the main MOS page), meaning we won't be imposing nitpicky MOS changes like this on editors at FAC and FAR. Hopefully changes will be better noticed at FAC once Tony1 is less busy, since he always keeps us apprised. SandyGeorgia (Talk) 15:41, 31 January 2008 (UTC)
FWIW, the page= and pages= fields in the citation templates DO (or try to) insert a non-breaking space. Perhaps a templates {{cite page}} and {{cite pages}} might be written. (Or perhaps {{p.}} and {{pp.}}. That's not so bad, is it? {{p.|45}} instead of p.&nbsp;45 or p. 45. — Arthur Rubin | (talk) 16:17, 31 January 2008 (UTC)
  • One more point. The general statement on nbsp refers to "In compound items in which numerical and non-numerical elements are separated by a space". I think most editors who are aware of this statement interpret it to mean numerical elements followed by non-numerical elements, of which the main examples are numbers and units. I can't recall this being used the other way around, with non-numerical elements followed by numerical elements. There are no nbsps after the names in Charles II of England or Elizabeth I of England, although the Charles II article does use nbsp for some units. Gimmetrow 21:39, 31 January 2008 (UTC)

Format

Independently of all other issues, there is the question of the format of the section. At the moment, it consists of four bullet points:

  • One the rule we are discussing.
  • One a long instruction on how to put in non-breaking spaces.
  • Two potential display problems.

These are not parallel; only one of them is a recommendation. Making them all bullet points is purposeless and makes them hard to read. Why do so?

Can we please make this one bullet point or blockquote, followed by two paragraphs, one on howto, and one on the problems? We can then discuss the rule on its own. Septentrionalis PMAnderson 23:25, 31 January 2008 (UTC)

 Done. I have also changed example to sentence in indicating the instance of {{nowrap}}, because I find it clearer; I had to look around ("what example?") with the old word; if anyone finds the change of wording undesirable, please change the word back without the format. Septentrionalis PMAnderson 00:10, 1 February 2008 (UTC)

One way of summarising

I see nothing of substance that is new in additions since my last posting in this section. Some of them ignore points that I have already made. I'll therefore just summarise things from my perspective at least, in a collected and orderly way, bearing in mind those additions and everything preceding them. As for PMAnderson's suggestions on formatting, I touch on this below.

I am very pleased that the text concerning hard spaces at WP:MOS and WP:MOSNUM has been subjected to wider scrutiny, at last. I had edited it, with full annotation, one month ago. No one commented for four weeks. My edit drew attention to a clear entailment of the principal guideline that had not been made explicit. No one has since shown that it was not a clear entailment, and major style guides certainly take it that way, implicitly and sometimes explicitly. Some editors have pointed out that this consequence to which I draw attention is not supported by consensus. I have never disputed that for a moment; rather, I have said that I want to find reasoned consensus, and that of course I will happily abide by it.

The discussion earlier in this section is mixed up. Sometimes hard spaces in general are discussed, sometimes hard spaces in citations (sometimes implying all citations, sometimes only short ones); sometimes the issue is the universally acknowledged difficulty of inputting and editing current markup (with &nbsp;), sometimes it is whether hard spaces are needed at all, anywhere. I have more than once asked for focus, but we did not achieve focus.

Now that we have at least looked at the issues, and have reverted to an earlier text, we are in a better position to reconsider the wording, more informed about subtleties that escaped some editors' attention before. I intend to open a new discussion so that we can achieve that, when the present strong feelings and ill-considered accusations and assumptions of bad faith are behind us.

All of this intersects with the question of proposed alternative markup for the hard space (see discussion at WT:MOS), and perhaps the whole question should be looked at freshly with that in mind also.

Meanwhile, of course, the relevant section at WP:MOSNUM and WP:MOS should stay as it is, since there is no clarity on the detailed points raised above, and therefore no consensus to support any alterations that change the effect of that section. PMAnderson has suggested changes to the format of the section (see preceding subsection). They are indeed independent of the substance. My own preference would be that format be left alone for now also, to give time for things to settle. But I will not object if form is altered, provided that substance is not altered till we have a fresh and cooler discussion.

– Noetica Talk 23:41, 31 January 2008 (UTC)

A shorter summary

The present rule is:

    • In compound items in which numerical and non-numerical elements are separated by a space, a non-breaking space (or hard space) is recommended to avoid the displacement of those elements at the end of a line. A hard space can be produced with the HTML code &nbsp; instead of the space bar: 19&nbsp;kg yields a non-breaking 19 kg.

At least the following questions have been raised:

  1. Should this apply to footnotes at all?
  2. Should this apply other places where text is unlikely to break?
  3. Should this apply to the construction "pp. 13-15" anywhere?
  4. Should this be mandatory (i.e. be a reason to fail an FA) where it does apply?

As far as I can see, only Noetica supports (1), which is a reason to immediately reword the text. My opinion is that this is a matter of editorial judgment, a balance between nice-looking text and an edit screen filled with control characters, and should remain so until we get a better markup language.

If these issues are going to be discussed separately, four more subsections are probably in order. Septentrionalis PMAnderson 00:23, 1 February 2008 (UTC)

PMA, you misrepresent me. Must I say it all again? I only drew attention to a consequence of what was already in place. I have written, early in the section above: "It is unnecessary if the line will not break, sure. So the suitable addition would be this: "unless there is no chance of the line breaking", or similar. This will be the case in short citations, sure." Why plunge in, incorrectly invoking the chaotic discussion above? Why not let things settle and cool down, as I have suggested? We can then discuss without misunderstandings.
– Noetica Talk 01:01, 1 February 2008 (UTC)

Footnotes

This is where we began. Sandy, Roger, Karanacs, Haukur, and I clearly agree that requiring &nbsp; in citation footnotes is more trouble than benefit. Noetica disagrees; can he explain clearly why? Septentrionalis PMAnderson 00:37, 1 February 2008 (UTC)

I can explain. I have explained. I do not simply "disagree". I detest &nbsp;, and I work hard to replace it with better markup. You do not. Don't misrepresent me. Leave it. Let's discuss later, with a clean slate, having learned from the chaos above.
– Noetica Talk 01:04, 1 February 2008 (UTC)
Fine. What do we do until it's fixed? Septentrionalis PMAnderson 01:13, 1 February 2008 (UTC)

No nbsps in citations, and this amount of discussion over something (nbsps) that has miminal impact on readers is a waste of time. I know there are more important issues to be dealt with at MOS; I see no problem with the page as it stood with the sentence about page nos removed, and I prefer bullets for readability. SandyGeorgia (Talk) 01:18, 1 February 2008 (UTC)

I agree with you on that as interim policy, Sandy: only as a makeshift at FAC, not as a change in MOS or MOSNUM at this stage. Eventually we will have to confront the general hard space problem in full. Rationally, later. Look at the discussion earlier on this page about spaces within numbers (which follows vast tracts of earlier discussion). Things get amazingly protacted, if we don't take care to start and maintain discussion in orderly fashion.
– Noetica Talk 01:33, 1 February 2008 (UTC)

Unlikely to break

The justification for having this rule in the first place is to avoid bad breaks. Why should we require it where the reason does not hold? This might be done by adding, perhaps, this:

There is no reason to add a non-breaking space where text is unlikely to break, or the difference in appearance in unimportant. For example, citation footnotes will normally not require it. Septentrionalis PMAnderson 00:37, 1 February 2008 (UTC)
Entirely premature. Has anyone given a moment's thought to what happens in the last column of a multi-column reference list, using the template {{reflist|3}} for example?
Let's all stop, do other things, learn the lesson that things are more complicated than they had seemed, and reconvene later.
– Noetica Talk 03:10, 1 February 2008 (UTC)
Going off-topic, but I always object to reflist 3 at FAC. SandyGeorgia (Talk) 03:12, 1 February 2008 (UTC)
Well you might, Sandy. I can understand that, as I'm sure you can understand that MOS has to cater for all of Misplaced Pages, not just the select articles that come to FAC. Hence the complexity of the discussion we should eventually have.
– Noetica Talk 03:17, 1 February 2008 (UTC)
If things are more complicated than they seem, that is a reason to expand editorial discretion, so individual editors can deal with problems as they arise. Septentrionalis PMAnderson 03:40, 1 February 2008 (UTC)
It is not necessarily the case that breaks are unlikely in footnotes. Breaks are only unlikely in articles where there are both a notes section and a references section, and the notes are confined to shortened notes that rely on the references for full details. Articles that put the full information in the notes are prone to having breaks in the notes. --Gerry Ashton (talk) 03:57, 1 February 2008 (UTC)
That is possible, rarely. But the proposed text deals with that; footnotes are also utilitarian, and the balance between looks and readable html code is therefore biased against &nbsp;. Septentrionalis PMAnderson 04:07, 1 February 2008 (UTC)
PMA:
On your last point: wrong! (See below.) On your earlier point: perhaps, but this is not a United Nations Declaration, it is MOS. If you're all for liberty at any cost, don't have an MOS; or make MOS a mere collection of pithy sayings about the cottage art of editing. Make your separate point elsewhere: but since you have raised it here, it is equally the case that complexity calls for well-constructed guidelines, from editors who have thought things through with patience and care, to help those who have not.
Gerry:
Absolutely right. In restricted cases (single column, short-format entries) the text will not break. In other cases (several columns, or multiple entries, or fuller entries with volume numbers, or with text preceding the citation proper) breaks will occur even more than in plain running text.
– Noetica Talk 04:13, 1 February 2008 (UTC)

Words first

Gimmetrow's point: this rule is in WP:MOSNUM because it applies to 9 kg. Do we want to apply it to p. 13? Why? Septentrionalis PMAnderson 00:37, 1 February 2008 (UTC)

Answers are given above PMA. More than once. Major style guides apply it that way; and most quality publishers do too. The reasons are even more compelling in democratic and dynamic HMTL work, because no one can control how users will display what we edit. The reasons are pretty much the same for 9 kg and for p. 13. To put the onus the other way, why distinguish these two types? But are we ready for this discussion? I don't think so.
– Noetica Talk 04:27, 1 February 2008 (UTC)
I'm having a difficult time recalling any significant use of nbsp in articles under this rule, except with numbers/units, and deep in some cite template code. (It's occasionally used to avoid breaking a phrase composed solely of words, but that's not related to this rule.) Can you point to any other general situations where nbsp is used at present under the "compound item" statement? Gimmetrow 04:45, 1 February 2008 (UTC)
Gimme, in all my FAC/FAR cleanup, I've seen and added nbsps both ways many times. I can't recall an article off the top of my head, but chemistry and biology articles come to mind. I insert nbsps wherever they are needed to prevent linewrap, whether the number is first or last. Ah, I can think of an example: Space and aviation articles (Saturn V, Boeing 747). SandyGeorgia (Talk) 04:50, 1 February 2008 (UTC)
All instances I see in Saturn V are numbers followed by units. Boeing 747 has a few interesting uses: 4 million&nbsp;cubic&nbsp;yards (and its metric conversion, both curiously with no nbsp between the number and unit), one instance of four&nbsp;inches, and a couple instances of something like Mach&nbsp;0.84, All other instances in both articles are numbers followed by units, as far as I can tell. The first is an mostly keeping a multi-word phrase from breaking, and the second is just a number written out. Only the third is directly relevant, and it seems rare enough not to be worth a general rule. Pending further investigation, I suspect this rule could be phrased only to apply to numbers and units, and "other situations at editors' discretion". Gimmetrow 05:09, 1 February 2008 (UTC)
Right, common sense and consensus. I asked for nbsps on 7 World Trade Center because the first time I saw it at FAC, there were dangling 7s everywhere. I explained my reasoning; it was done. SandyGeorgia (Talk) 05:14, 1 February 2008 (UTC) Also, not sure you followed what I was saying above; I join Boeing and 747 with an nbsp or nowrap. SandyGeorgia (Talk) 05:17, 1 February 2008 (UTC)
Hmmm. forgot about nowrap. Doesn't nowrap do things with phrases? I see a lot of uses in 747 without any spaces: The {{nowrap|-400}} was offered... Gimmetrow 05:32, 1 February 2008 (UTC)

To reply to Noetica, the reason we might distinguish numbers/units from other cases is that numbers/units may very well be the largest case on WP where nbsp is useful in practice. I'm sure PMA will object to me making up numbers, but let's say numbers/units cover 90% of the cases where nbsp is useful - covering that takes care of most of the problem with essentially no effort (due to existing scripts), and the benefit, however little, is arguably worth that small effort. Although a few cases (like Mach 0.84) can be added to the scripts, the rest may take more effort than they're worth. Something as straightforward as "all numbers are followed by non-breaking spaces" could potentially be implemented in mediawiki's page rendering, and we would never have to think about it again. Gimmetrow 05:32, 1 February 2008 (UTC)

I have no objection to hypothetical numbers, unless they're preposterous; anecdotal evidence is all we are likely to get. The proposal to tweak the page rendering will produce minor collateral damage in such sentences as "1093 and 3511 are the only known Wieferich primes." but this may be worth it. Septentrionalis PMAnderson

Recommend

The present text says we recommend, not we require. Does this actually make the change mandatory, or is it a work of supererogation? Is this worth hassling articles for at FA? More seriously, is it right to pass an article because energy has been devoted to changing the spaces, while the substance and clarity are unimproved? Septentrionalis PMAnderson 00:37, 1 February 2008 (UTC)

The MOS as a whole is a guideline, making it a recommendation. At this point, the FA Criteria require that the article adhere to the MOS. Whether that is a good idea or not is something that should be discussed at WT:FAC, not here. Karanacs (talk) 01:14, 1 February 2008 (UTC)
I agree, Karanacs.
– Noetica Talk 01:33, 1 February 2008 (UTC)
How the MoS is used in the rest of the Misplaced Pages guidelines is not in the least irrelevant to our discussion. Nor is the fact that the "recommends" is interpreted by a whole horde of editors as carte blanche to run around slapping on those nbsps where they are neither helpful nor wanted by the editors who care about the article itself.
If it is intended to be something less than "require", that needs to be specifically spelled out in the MoS. In other words, if it means that I am acting reasonably to revert someone's edit adding nonbreaking spaces by saying it is not required by the MoS, then make that clear.
In any case, that's the way I'm going to start treating it now; while in the past I haven't added nbsp when I see no reason to do so, from now on I will be actively removing them when there is no good reason to use them. Gene Nygaard (talk) 22:16, 1 February 2008 (UTC)
Gene, the standing of MOS within Misplaced Pages cannot be settled at MOS. MOS can only offer guidelines, and it can give them in various strengths: one is utterly required because it reflects universal practice (a sentence cannot start outside brackets and end within brackets); another is a matter of preference (serial commas are advisable where ambiguity may be possible without them). The standing of MOS is indeed relevant to our discussions, but we cannot affect it here – except by making MOS worthy of respect and compliance. PMA's original point, above, starts off about the strength of the proposed guideline; but it then moves subtly towards the question of standing.
– Noetica Talk 22:34, 1 February 2008 (UTC)

Summary?

I'm lost. I vaguely (mis) understand that you people have been arguing over "pp. 23–27" versus "pp.&nbsp;23–27" (etc.), or perhaps whether the latter should be recommended, or perhaps whether it should be recommended other than in footnotes, or perhaps whether people should be warned off it other than in footnotes. Or something. I might have an opinion. It's probably worth no more than anybody else's, but who knows. I suspect that other people might have at least moderately intelligent opinions too. But you have to be a very special kind of person to have been sufficiently interested to follow all the kilobytes above, and many of us aren't that special kind of person: I for one started to read it, but soon nodded off (which of course might just mean that my IQ isn't up to it). Can somebody who's actually gone through it all produce a summary for busy/lazy/stupid people such as myself? -- Hoary (talk) 04:06, 1 February 2008 (UTC)

Start with #A shorter summary and work down. What points are still unclear? You will miss most of the recriminations, but at least one set has been retracted anyway. Septentrionalis PMAnderson 04:09, 1 February 2008 (UTC)
Thank you for inadvertently supporting my main point, Hoary. We need to be have clear focused discussion, with informative headings and a careful procedure that we all respect. We should learn that lesson (and others), and start again. Later. See my summary (above) for fuller reasons.
– Noetica Talk 04:20, 1 February 2008 (UTC)

Ah, mm, thank you both. I find myself agreeing with one of you (A), and then agreeing with the other of you (B) where B amends (but seems to accept the gist of) what A is saying, but then being quite puzzled when B then seems to disagree totally with A, implying that he doesn't accept the gist of what A is saying. I confess that I've never heard of reflist3. Meanwhile, I do know of some plain old "references" (footnotes that use the references tag) that are long (even discursive) and include, or lead up to, page references: these would seem to benefit from nbsp about as much as anything else would. Incidentally, I've been using nbsp a lot without having even noticed that MoS mentions it. Ah well, I'll try again to read what's above. Thank you for your time. -- Hoary (talk) 04:28, 1 February 2008 (UTC)

Thank you, Hoary. I hope to see you here when we've all calmed down and are ready to begin again constructively.
– Noetica Talk 04:36, 1 February 2008 (UTC)
Hoary, here's my summary. The MOS buck stops at FAC/FAR, because it's enforced at FAC/FAR, so keep FAC/FAR informed when changes are proposed and made (this one was made without discussion, and it took a month for us to realize). Cite templates already insert non-breaking spaces; most other citations are short and asking FA writers to insert nbsps into other citations, which are typically very short (example, Le Père Goriot) is a burden to FA writers that will generate little benefit for readers. So what if 1 in a 100 citations happens to wrap (although I can't remember ever seeing problematic wrap in a citation)? NBSPs are not needed in citations; line wrap in citations is very rare, and the extra work isn't worth the benefit. There are more important MOS matters to attend to (like how come every WikiProject gets to randomly add their guidelines to MOS without community consensus or input?). Burdening FA writers with make-work nbsps isn't our best use of time. On all the other issues raised, nbsp should continue to be applied as it is currently applied at FAC and FAR; you add nbsp wherever it's needed and makes sense to prevent linewrap. Common sense. That's how it's used now. SandyGeorgia (Talk) 04:43, 1 February 2008 (UTC)
Hoary, I'm glad Sandy has summarised now from her point of view, with which I am very much in sympathy. Especially concerning &nbsp; – dreadful markup! It would put anyone off. See WT:MOS.
– Noetica Talk 04:56, 1 February 2008 (UTC)

Thank you all. I think I understand. I agree with much of what has been said in the last few paragraphs, and disagree with a bit of it. But I'm pretty sure that my disagreement would bring nothing new to the discussion, even if the discussion is continuing. If this is restarted, I may contribute; till then, I'll shut up. -- Hoary (talk) 08:17, 1 February 2008 (UTC)

Strange wrap example

Wow, following Gimme around Wiki, I just saw the strangest line wrap ever. I added a nowrap here. Who knew that brackets caused a line break? SandyGeorgia (Talk) 05:38, 1 February 2008 (UTC) The was separated from the ne. SandyGeorgia (Talk) 05:41, 1 February 2008 (UTC)

Yes, it does in some browsers. This was an issue with the fact and related inline maintence templates. (May still be.) Gimmetrow 06:03, 1 February 2008 (UTC)
I think I've seen it do so: the first bracket splits from the rest of the superscript. Not a major problem; {{fact}} is not intended to be a permanent part of the article. Septentrionalis PMAnderson 13:53, 1 February 2008 (UTC)

Practical point re nbsp

Tiptoeing very gently into the fray... Would it be useful to include, somewhere in the discussion of non-breaking spaces, the fact that they are available on the toolbox which appears below the edit window? I have a feeling they weren't there in the past, but they are certainly there now and it's possibly quicker to move from keyboard to mouse, move and click, rather than type two shifts and 6 characters! Another small point - someone asked above just where non-breaking spaces were used, and one place I've used them is in UK postcodes (eg in infoboxes), which contain a space and look dreadful if split (eg LS2 9JT). PamD (talk) 15:12, 1 February 2008 (UTC)

It would be very useful; I'm looking at the edit box and I still don't see them. (As for UK postcodes; they need a space, but why not a line-break? I believe I've seen them split in professionally published text.) Septentrionalis PMAnderson 17:48, 1 February 2008 (UTC)
nbsp is in the "Wiki markup" section of edittools, near the top, to the right of Redirect. — Aluvus t/c 04:01, 2 February 2008 (UTC)

Holy smokes, archive please

This page is 657KB; every time I try to edit I get an edit conflict or hung on load time. SandyGeorgia (Talk) 05:00, 1 February 2008 (UTC)

Made two archives and cut it down to 218k. Anyone object to automated archiving through User:MiszaBot? Perhaps archive threads after no comment for 15 days, with a max archive size of 150k? Gimmetrow 08:55, 1 February 2008 (UTC)
Misplaced Pages talk:Manual of Style/Dates and numbers: Difference between revisions Add topic