Wikipedia talk:Manual of Style/Dates and numbers/Archive 95

Archive 90

←

Archive 93

Archive 94

Archive 95

Archive 96

Archive 97

→

Archive 100

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 ^talk 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 "(''[[Xanadu]]'' 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 Wikipedia 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 Wikipedia:Reference_desk/Language#Lithuanian).

I now ask you to remedy the error in the heading of this section yourself, according to established Wikipedia 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 [1]. 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

[Noetica's summary:] 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   instead of the space bar: 19 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)[Amended.– Noetica^♬♩ Talk 03:02, 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 Wikipedia, 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)

I'm not against any MOS; a MOS that was (like other guidelines) a collection of good advice, subject to WP:IAR and policy, would be as useful as any other guideline, more useful than some. This MOS, however, attempts to make a set of rules each of which a handful of editors made up one day amd make them the Secret Laws of Wikipedia. It is failing, as it must, and it is destroying the credibility of FA in the process. Septentrionalis PMAnderson 03:25, 15 February 2008 (UTC)

• Anderson puts little value on the role of stylistic cohesion and high standards (two issues there) in giving WP articles a high degree of status and utility in the jungle of Google searches. Without such cohesion and standards, any old web page would do. This is why I see Anderson as essentially running an anarchistic line—one that, fortunately, most users here see for what it is. Possibly, on a psychological level, he hates being told what to do and is playing this out on a larger scale at WP. But clearly that hypothesis fails to explain the full gamut of his behaviour on WP (WRT freedom and rules). Tony (talk) 03:40, 15 February 2008 (UTC)
  • My major motivation seems to me to be curiosity. For example, do you have any qualifications to practice psychoanalysis? Septentrionalis PMAnderson 04:00, 15 February 2008 (UTC)
    • Nope; do you have any qualifications to write? Um ... are qualifications necessary to make such obvious comments as I did? Tony (talk) 07:35, 15 February 2008 (UTC)
      • Is this equivalent to I don't, and I don't need any? If not, you may wish to rephrase. But I'll make you a deal, Tony: keep your lay-Freudian guesswork to yourself, no matter how "obvious," as WP:CIVILITY requires, and I will draw no obvious conclusions about an editor who sees dirty hands, sabotage, anarchy whenever someone else disagrees with his desire to know which page is in control here. Septentrionalis PMAnderson 20:22, 15 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

• Noetica, to me, the context of a list of references creates quite different expectations in the reading than for that of plain running text in the body of an article. We know we're going to encounter page numbers and abbreviations for them frequently, towards or at the end of an entry, so the need to prevent line-breakage is much less. Seeing 13 hanging off the end of a long line in the main text is harder. 13 what? Will it be kilograms or people? And we're not as prepared for it aesthetically, either, just as we tend not to like numerals at the start of a sentence. Tony (talk) 03:47, 15 February 2008 (UTC)

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 Wikipedia 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 Wikipedia 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?[2]). 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 [o] 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)

Thanks, Pam. Yes, it's only slightly easier than typing it in full. We desperately need a keystroke shortcut. Tony (talk) 06:21, 3 February 2008 (UTC)

And I don't find it easier; I thought Pam meant a way to code a hardspace directly, rather than coding markup language. Septentrionalis PMAnderson 05:33, 14 February 2008 (UTC)

I just want to point out that it's now a violation of the Geneva Convention to force any one person to read everything that's been written about the no-break space over the last two months. Also that the right approach may be not to get too worked up over this, because there are two possible changes coming that might ease tensions, without usurping any powers of the uptight diligent MOS-aware editor. Jimbo and friends are putting money and time into search.wikia.com these days, and despite the dreaded wikia.com url, this project actually concerns Wikipedia more...size matters. As a result, many have concluded that there will be two edit screens at Wikipedia instead of one in the future, possibly user-togglable (surely that's not a word), so that people who care about all the tags relevant to search results will see them and others won't. It has been suggested that many other things could go into the higher-octane edit window, and I would think the double-comma or &nbsp; would be a perfect example of the kind of markup that some of us want to see and most people wouldn't even want to think about. No promises, no inside information...I'm just saying, sit tight. Another thing to consider is that if you type in and then pull up the following in your browser source..."X !"...you'll see that Mediawiki has just inserted, without so much as a by-your-leave, a no-break space where you thought you were typing a space. This is, after all, the way the rest of the copyediting world handles this problem...do you think every Newsweek editor inserts &nbsp; in "p. 1"? Most insertions of no-break spaces in journalism are handled by software (presumably with oversight, but usually by software), and it's always possible we could expand the Mediawiki rules so that no-break spaces are automagically inserted more often. It wouldn't make the problem go away, but it would turn the heat down. - Dan Dank55 (talk) 22:27, 4 February 2008 (UTC)

I'm sorry, I should have made it clear for those that don't know me that I'm one of the uptight diligent MOS-aware editors of whom I speak, I'm not being unWP:CIVIL. - Dan Dank55 (talk) 22:41, 4 February 2008 (UTC)

I'm so glad I blundered into this part of the catacombs at last. I'm the editor who, determined to head off possible MOS objections at FAC, produced many if not all of the strange nbsp effects in the citations of Ernest Shackleton. With the best of intentions, I have done similar things elsewhere, going so far as to put nbsp between such constructions as "five" and "onions", although I reckoned it was an odd thing to be doing. I will ease back on this obsession. Finetooth (talk) 19:47, 11 February 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 Wikipedia's mission to promote a failing standardization effort. If the IEC binary prefixes gain significant support Wikipedia could consider using them. -- SWTPC6800 (talk) 01:55, 18 January 2008 (UTC)

Now that's one horrible misuse of a quote. Did you think it applies because the headline looks fitting? I suggest you actually read this policy. It's also not legit (and I don't need any policy to back this up) to use arbitrary made up numbers like "0.5%" in a discussion. --217.87.122.179 (talk) 22:03, 2 February 2008 (UTC)

0.5% is not arbitrary and is not "made up".

Historical use search terms	Results
kilobyte -wikipedia	1,940,000
megabyte -wikipedia	6,190,000
gigabyte -wikipedia	3,640,000

Total: 11,770,000

IEC Search terms	Results
kibibyte -wikipedia	28,800
mebibyte -wikipedia	17,100
gibibyte -wikipedia	19,000

Total: 64,900

Consensus for historical use: 99.449%

Fnagaton 22:51, 2 February 2008 (UTC)

It's good that you explain how this figure was determined. This shows that the value is less than useless. Many results may to a certain extent show that something is widely known. The opposite is not true. Lack of results does not prove anything. Not to mention that this method is still arbitrary because it excludes the short forms which are far more common in my experience. Of course it's obvious that MiB has more meanings than Mebibyte and MB has also many meanings in different areas. Last but not least, this method excludes not only results from wikipedia or citing wikipedia, it excludes any kind of result which mentions or links wikipedia which may have nothing to do with this topic. --217.87.122.179 (talk) 00:15, 3 February 2008 (UTC)

The preponderance of evidence shows that real world consensus is against your point of view. What evidence have you given in reply? Nothing, no evidence, you've just written waffle about "less than useless". The numbers are facts that do not support your point of view so you are wrong again because when you claim "it's less than useless" does not make it so. Wikipedia is excluded for the very good reason that a while ago someone made many hundreds of changes to use kibibyte etc and that means including Wikipedia would contaminate real world results. Also Wikiepedia is excluded from the results to show real world use. You also showed a search earlier on that did "-wikipedia", unless you now want to retract your earlier post? Trying to do a search for the much shorter versions like MiB ("Men in Black" for example) is also much more likely to pickup use of those three letters that has nothing to do with computers so your point is not well thought out because your proposal would have less much meaningful results. Fnagaton 01:07, 3 February 2008 (UTC)

It is Wikipedia'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)

No, "2 KB (2^11 bytes)" is not unambiguous at all because there is always the possibility of mistakes. In this case, I'd assume the editor forgot the "i" and typed KB instead of KiB. Or worse, maybe someone added (2^11 bytes) because he assumed 2 KB was meant to mean 2048 when in reality it's really 2000. You might think it's "obvious" from the context, but context can only provide a rule of thumb. In many cases, the editor was just careless and typed "KB" instead of "kB". Many people don't know that SI prefixes are case-sensitive and that 'K' is incorrect as abbrevation for kilo (1000, one thousand). Thus, a chain of errors and "well-meant" edits can cause the following: 2000 bytes -> 2kB -> 2KB -> 2048 bytes. Same applies to "bits". Last but no least, this kind of hint reinforces the idea that KB absolutely means 1024. Sometimes less is more. If you think writing "(2^11 bytes)" is useful at all, why don't you drop the "2 KB" completely? It's not common practice in Wikipedia to write the same twice in different words. --217.87.122.179 (talk) 21:13, 2 February 2008 (UTC)

You are incorrect because "2 KB (2^11 bytes)" is not ambiguous and because it expresses exactly the number of bytes that are used. You are also incorrect because your "what if there is a mistake" scenarios are also irrelevant red herrings because as already stated in the guideline "...one must be certain... before disambiguation" and trying to throw out using a particular unit just because someone might edit an article incorrectly is no valid reason at all. Taking your point of view that would mean nobody changing anything because there might be a mistake somewhere. Thus your "many people" point is also irrelevant because if someone is not certain then they shouldn't be editing on a topic they are not certain about. Also changing KB to KiB when in the uncertain "many people" scenario you use is also wrong because the person is not sure what they are doing and could change something incorrectly. Dropping the "2 KB" completely is also not correct since as I have posted before consistency with the terms used in the reliable sources relevant to the subject is important. You are also wrong because disambiguation, "writing the same twice in different words", is very common. Fnagaton 21:24, 2 February 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^3x, means that everything is rounded in thousands; and powers of ten in binary, e.g. 2^10x, 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×10³bytes)" Fnagaton 18:09, 18 January 2008 (UTC)

How about: "This memory stick from company X is labelled as 1MB (2¹⁰×10³bytes)" (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 Wikipedia 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 Wikipedia 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)

You are reacting on trigger words again instead of reading carefully and responding adequately. First came decimal metric prefixes (which I wrote about), then came bits and bytes (and octets and words), then came binary “adaptation” of SI prefixes in IT – with the side effect of capital k which I welcome –, then came disambiguity, then came IEC prefixes, then came Wikipedia. Where am I wrong here?

There is no such thing as common sense, never use it as an argument. The MOS is not prescriptive in the sense that it would say people what to do, but it’s prescriptive in the sense that it says what articles should look like in the end. (And yes, it’s often watered down in that regard, which I consider a failure.)

The IP users said, a unit with multiple meanings was not a unit by definition. You say that (he’s wrong and) the units under discussion were being used with multiple meanings, trying to prove your but actually also proving his point. His definition can’t be wrong, it just may not match yours.

The (here logical, not empirical) expectations of the readership are quite the opposite of a “red herring” argument in a discussion about our style guide! If the prefixes, when applied to bits and bytes, always were used in a binary sense (and decimal everywhere else), your point might stand, but they ain’t, e.g. in rates (kbit/s etc.).

I tried to limit my response (after I couldn’t suppress it completely), because I think everything has been said on the matter, although people still come to different conclusions, because their views about the role of Wikipedia and its MOS differ. (You try, intensional or not, to devalue the other position by calling it prescriptive and neological, which aren’t bad things per se, neither is de facto.) If I agreed with your presuppositions I would probably come to the same conclusion, because I don’t contest most of the facts you bring up again and again, thinking or at least implying that this was what needs to be discussed when actually we disagree on a higher level, which makes your points irrelevant – weak probably was an inappropriate or misleading term.

You’re in no position to demand anything from me (nor anyone else here), but, please, feel free to correct or at least discredit my summary, my view of the process.

Gee, I wish there was anything besides carnival outside so I hadn’t felt the temper to engage in this again. — Christoph Päper 01:24, 3 February 2008 (UTC)

You are incorrect because you are at fault here for not "reading carefully and responding adequately" (as you put it). This is because you misrepresent what I write and you attempted to misrepresent my motives in your summary of the history of this topic when you wrote "because some article authors, like you, didn’t like to adapt their habits". You are utterly wrong to try to misrepresent what you think are my motives. You are also wrong when you say there is no such thing as common sense because common sense is a large part of building consensus. Next we get onto you misrepresenting what I write. This is because I point out his "argument" (from 06:07, 2 February 2008 (UTC)) is a red herring and yet you insist on trying to rewrite my point to mean something else entirely. Just so you are perfectly clear, what you wrote is rubbish because I never wrote what you claimed I wrote. You are using a straw man, so your "point" is irrelevant and false. Fnagaton 02:01, 3 February 2008 (UTC)

I’m sorry it took me so long to respond, but I had much more important, non-WP things to do lately. Actually, I’m just taking a break from them.

So you think I misunderstood you or your motives. Maybe I did, big deal, happens all the time. You wouldn’t even have noticed if I hadn’t paraphrased what I understood and remembered (“misrepresent” you call it), just like I noticed your misreading. It doesn’t help, though, that you don’t explain where and how I misunderstood exactly. I assume it’s only about the changing habits part.

Nobody denies that kilo, mega and giga (at least) with bit or byte are often being used and understood in a binary sense instead of their classic, metric decimal one. Nobody denies that this occasionally results in ambiguity (in any imaginable way). Nobody is happy with the situation, although many take it as a given. Nobody intends a unit (or prefix) to have more than one meaning, although in practice (i.e. your de facto) occasionally one does. The IP user raises this point to a defining quality of a unit, you pragmatically don’t and call this (intentionally) irrelevant to the discussion (“red herring”). Am I right so far?

My main argument, which you ignored, still stands: We have different ideas of the purpose and foundations of this style manual. Therefore we cannot come to the same conclusion! So every argument is moot until we agree on the basic principles.

Whenever you claim the MoS was descriptive not prescriptive you are right and wrong at the same time, because a descriptive observation once published becomes a prescriptive rule in the understanding of many. This is how grammar and orthography “rules” came to be (for most natural languages).

Anyhow, a suggestion for compromise for the time being, although I would much prefer consensus in the long run:

SI prefixes are decimal and do not need disambiguation in general, but when applied to bits or bytes (incl. words and octets) without composition with any other units (as in rates, e.g. kbit/s) their meaning has to be disambiguated (one possibility is the replacement by IEEEIEC prefixes, which are always binary), except for RAM chips [and?] when used with a preferred number based on a power of 2 where they take a binary default meaning and only need disambiguation when having a decimal meaning. — Christoph Päper 19:36, 21 February 2008 (UTC)

I can see you are continuing to misrepresent me because I did not ignore your argument, your "argument" is fallacious for the reasons I have already given above and previously on this topic. Your compromise is not good because it does not represent real world consensus. Your "compromise" chooses IEEE which you prefer, which is not a compromise at all, it is pushing your own point of view. For example it is disingenuous to say "SI prefixes are decimal" and not mention the fact that the JEDEC defines K = 2¹⁰, M = 2²⁰ and G = 2³⁰ when being used for semiconductor storage capacity and also because recent legal rulings have stated that despite what SI/IEEE/IEC claim the de facto standard is different. RAM chips commonly use the units KB, MB, GB in the binary sense, for example and this is defined in the JEDEC standard. If you really want to get into the whole "orthography" argument then you're going to be refuting your own point of view because orthography is to use correct spelling according to what is considered to be accepted (i.e. generally approved) and established use. In this case orthography easily refutes using the -bi prefixes because it is obvious they are not accepted and established use. Fnagaton 08:42, 22 February 2008 (UTC)

Gosh, either my English is worse than I thought or productive discussion with you (on this subject) is close to impossible.

I don’t care whether we use IEC prefixes for disambiguation. I just want to limit ambiguity inside and among WP articles. (Ambiguity outside WP is outside the scope of this style manual.) To achieve this we can either

1. adopt something with mutual exclusive meanings (e.g. SI and IEC prefixes, despite ambiguous usage outside WP),
2. disambiguate (SI prefixes) inline each and every time or
3. specify in MoS where we assume which default meaning (for SI prefixes), that wouldn’t have to be disambiguated, and where it’s too dubious to choose a default.

The current guideline does nothing to achieve the goal, uses only partially the second option. My suggestion for compromise does the third, although I very much prefer the first. Maybe I set the requirements for a binary meaning of SI prefixes higher than you would like, but with preferred numbers in the field of semiconductor storage capacity most cases would still be covered to your satisfaction. I see no good solution for file sizes, though, because files can be stored on different media (binary or decimal) and can be transmitted (decimal). — Christoph Päper 17:10, 22 February 2008 (UTC)

I note your continued misrepresentation and use of weak personal attacks, this shows that you are not interested in valid debate. You are also wrong because the current guideline fixes what you think is ambiguous by encouraging the exact number of bytes to be specified in the disambiguation or in footnotes. For example "256 KB (256×2¹⁰ bytes)". The first option "adopt something with mutual exclusive meanings" ignores real world consensus and makes articles inconsistent with their sources and actually doesn't solve the problem of using -bi units that can also be ambiguous. The second option "disambiguate (SI prefixes) inline each and every time" is not logical since the purpose of disambiguation is not to include brackets (or similar inline text) after every number in an article, it is usually the case that only the first occurrence of any such number needs disambiguation. The third option "specify in MoS where we assume..." is only going to get my support if it follows the real world consensus, i.e. not use -bi. Otherwise it is just going to be pushing point of view against consensus. The best option, which you don't list, is to use the terms found in the majority of reliable sources relevant to an article. This means internal consistency for articles over and above consistency for the whole of Wikipedia. Fnagaton 17:33, 22 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. Wikipedia 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)

• That difference is irrelevant everywhere, except perhaps nursing homes in the UK. Tony (talk) 23:28, 2 February 2008 (UTC)

Maybe you don't know that "billion" is not only an English word. Billion is still frequently mistranslated as "billion" when it actually means 10^9 in one (European) language and 10^12 in the other like French or German. The UK might have adopted the US meaning by now, that's not true for any other country. You see it's almost the same issue as Megabyte vs. Megabyte. One is 10^6 and the other is 2^20. Keep in mind that this neither the American nor the British Wikipedia, it is an international effort. As there is no official authority for the English language, really nobody can decide which meaning of billion is correct but it is trivial to avoid these few well-known sources of confusion. --217.87.122.179 (talk) 00:00, 3 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. —Preceding unsigned comment added by 217.87.122.179 (talk) 20:56, 2 February 2008 (UTC)

Yes I did mean that so do not presume to tell me what you think I really meant because when you do so you are misrepresenting me and what I wrote. Also your incorrect accusation of "bad faith" shows you have not presented a valid argument because the term "red herring" is actually referring to the logical fallacy, which your "argument" is actually using. This is also pointed out by Pyrotec as being irrelevant. Fnagaton 21:08, 2 February 2008 (UTC)

Okay, then I'm relieved that I could help in making clear what you actually meant because it wasn't obvious at least to me. I don't quite agree with your presumed definition of red herring but discussing this would be another one and off-topic anyway. --217.87.122.179 (talk) 21:58, 2 February 2008 (UTC)

Red herring fallacy also known as irrelevant thesis or conclusion. You'll see what I wrote is correct. Fnagaton 22:43, 2 February 2008 (UTC)

Not taking either side, but the Google test is worthless. As is citing voluntary standards (as are the IEEE's, IEC's, and JEDEC's) as examples of "policy". Voluntary standards are just that, and it's hardly surprising you can find standards which reflect common usage. Consider:

mile -wikipedia - 24,300,000

kilometer -wikipedia - 1,520,000

inch -wikipedia - 26,000,000

centimeter -wikipedia - 6,800,000

pound -sterling -wikipedia - 11,200,000

kilogram -wikipedia - 8,240,000

acre -wikipedia - 3,420,000

square kilometer -wikipedia - 1,660,000

Can these results be used to argue that preference should always be given to imperial units of measure, since apparently more English-speaking people will be familiar with them? Can they be used to decide on a case-by-case basis which units are preferable? Can you say that common use is universally more important than standardization in every case or vice versa? No matter how you concoct the Google Test argument, it is always flawed.

Experience with Wikipedia should tell you that no amount of dialog on this will ever settle the issue wholly in favor of or against IEC prefixes. There's zero editorial direction on this site, and unfortunately the MOS as a whole is more or less a farce (used merely when it is convenient in an argument), so fights like this will keep breaking out. I strongly suggest you look for a middle ground where the use of IEC prefixes is accepted in some contexts and the common prefixes are accepted in others. Pages like the one on floppy disks really do need some concise method to deal with the prefix ambiguity, and the IEC prefixes are one such way.

Basically, the way the MOS currently reads is the only way it can read. In reality there's no such thing as standardization on Wikipedia, so that argument won't work. The current reading explains the history of the debate, lays out the facts (common use versus ambiguity) and doesn't take any strong position. The only change that might be useful is provision for changing prefixes to IEC variants where appropriate and discussed beforehand. This excludes contentious en masse changes, but still acknowledges that there are some circumstances in which utilization of IEC binary prefixes might be useful. (maybe also remove the mention of the JEDEC, which is utterly comical since their standards have nothing at all to do with standard prefixes for unit measures)

You will never convince each other. You will not be able to defeat the common usage argument. You will not be able to defeat the ambiguity argument. You will never end this debate by brow beating the same tired and cyclical arguments into one another. I humbly suggest just leaving the dead horse alone and letting the editorial ebb and flow take its course. Otherwise you're just wasting your own time in neverending trite rhetoric. -- 74.160.99.252 (talk) 20:27, 11 February 2008 (UTC)

Unfortunately the IP user from Germany (not you 74.160.99.252) but the other user from 217.87.122.179 above (and their other IPs in that ISP range) decided that instead of trying dialog they would vandalise ANI, several talk pages including mine and an admin. Eventually leading to several semi-protects and range blocks. The ambiguity argument has been refuted since it relies on the false premise "nobody uses -bi in other ways except binary" because it has been shown that -bi has been used in the decimal sense. Fnagaton 20:39, 11 February 2008 (UTC)

I'm pretty sure 74.160.99.252 is the same person you're talking about. --85.25.12.31 (talk) 21:28, 11 February 2008 (UTC)

Years linked in a list

Years should not be linked in lists. I was working on a list of films and removed all of the year links since it is possible that the list could possibly be linked to every year since motion pictures was invented (or shortly thereafter). I think that year links in lists is a really bad idea. If this has been covered before, I couldn't find it. - LA @ 02:44, 9 February 2008 (UTC)

List of disaster films? I agree linking every "Year in film" article looks peculiar, but in short lists or tables it's common to link years to "Year in film" articles (See Austin Nichols#TV and filmography, for instance). It seems to me a question of scale. Gimmetrow 04:21, 9 February 2008 (UTC)

For authors bibliographies or actors' filmographies I agree, linking to the years is good. However, if the list of items by a subject which could be extremely long, it is a bit much. That is my opinion anyway. - LA @ 05:39, 9 February 2008 (UTC)

Please don't link years unless piped; even then, hardly any reader will bother to click it, since it looks like one of those useless plain-year-links we've spent a long time trying to weed out of WP. Consider spelling out the first one (1901 in film) to suggest that the subsequent blue years are piped. Tony (talk) —Preceding comment was added at 08:15, 9 February 2008 (UTC)

Actually Tony, I got rid of the (XXXX in film) year links.

Let me give you an example...Let's say that someone starts a List of red widgets. Each red widget on the list has a year in which it was released. There are hundreds of widgets out there, so someone makes the XXXX in widgets lists. Each widget's article has a link to that year in widgets. So, the first batch of widgets was released in 1901. There are a hundred or so, a dozen or more are red. Each widget gets an articles because widgets are notable on principle. So, now there are dozens of red widgets released every year. The new widgets are added to the list and are linked to the years in their articles. The list of red widgets doesn't need to be linked to those year in widgets lists because of the fact that the articles are already linked.

I hope that made sense. - LA @ 08:58, 9 February 2008 (UTC)

So is this accepted or not? I don't want to do a lot of year link removals if this is not accepted. What I am looking for is a general guideline, such as "Editors should not link years on list pages." - LA @ 07:07, 16 February 2008 (UTC)

Do the year links help readers to understand the topic (as required by the guideline)? If not, get rid of them. They're ungainly and harder to read than normal text. Tony (talk) 10:12, 16 February 2008 (UTC)

I'm a bit conflicted about this one. If the "[Year] in film" articles aren't linked as years within film articles, then will this put these articles at risk of being orphaned? If so, then how are we to create a useful linkage situation for these articles? Girolamo Savonarola (talk) 08:11, 24 February 2008 (UTC)

Links to "As of xxxx": how large a benefit?

Links to "as of xxxx" lead to solitary years. According to Wikipedia:As of, it is supposed to be used if you "want to ensure that people will update it". I do not believe that it actually works like that. For it to work, a reader would have to start at the redirect page and see an article, go to the article and then identify that they know something more than is already there. There are far too many unlikely human actions for me to believe that it has a significant effect on Wikipedia. There are doubts expressed on the Wikipedia:As of talk page too. Is this simply another variation on date linking where there are believers and non-believers? How large is the benefit that is claimed and is it worth the added blue noise that makes good links harder to see? Lightmouse (talk) 15:09, 15 February 2008 (UTC)

I read that about three times and I hope you'll forgive me for first asking for clarification.

I think it's to ensure people update the sentence with the link in it, for example, in "As of 2008, John Key is the Leader of the Opposition in New Zealand", that people will update it to "As of 2009, Joe Bloggs is the Leader of the Opposition in New Zealand" or "As of 2009, John Key is the Prime Minister of New Zealand" if it changes from year to year (that sentence was not an election prediction, btw).

I suppose the linking helps people who specifically want to track down those sentences do so, so they can update them? Neonumbers (talk) 10:00, 17 February 2008 (UTC)

• I'm unconvinced that the reasons are so well thought out, and am suspicious that linking such items is little more than a carry-over of the obsession with linking plain years. At least there's a rationale for the "as of" linking; but it's a flimsy one: editors at a centralised list of as-ofs are not in the best position to know when and in what way such time-tagged information should be updated. It is the guardians of the articles in which it occurs who are best placed, and we must continue to rely on them—and knowledgeable casual users—to update as-of information, just as we rely on them to update articles in so many other ways. The disadvantage of bright-blue splotches is not easily outweighed by the chance that an as-of editor will monitor, alert, tend to, or themselves update the item at the right time in the right way. Best not to link, I say. Tony (talk) 10:39, 17 February 2008 (UTC)

Neonumbers, let me try and clarify what I think is going on. Yes, it is often stated that it helps people who want to update the information but have you considered how you would actually do this? I can only see two ways in which a link to an 'As of' article would work:

• 1. Links to 'As of xxxx' redirect to 'xxxx'. This seems to me to be consistent with the idea that they have no real function. However, you could argue that an editor determined to update an 'As of xxxx' fact can go to the redirect and look at 'what links here'. Then you need to pick an article that you think you know something about. You can then read the article and see if the 'as of xxxx' link in the article can be updated with something you know better. This seems an inconvenient and unlikely set of events that I cannot imagine it is a routine process for Wikipedia, if it happens at all I would be surprised. Yet there are thousands of 'As of xxxx' links. I can't imagine wanting to do such a thing but if I did, I would not waste my time with the unfocussed Wikipedia redirect. I would want a focussed search on a specialist topic. I could go to google and search Wikipedia for 'as-of-2008 New-Zealand politics'.
• 2. Links to 'As of xxxx' are a highlight within the article. Any reader passing by will see the highlight. Thus we could use bold highlighting As of xxxx and achieve the same effect. Again, I do not believe that such highlights are proportionate. Any editor is capable of reading 'As of xxxx' without a highlight and knowing that it is capable of being edited just as any other piece of text.

My belief (like Tony's) is that these are a carry-over from the obsession with linking plain years and should be treated as such. Lightmouse (talk) 11:15, 17 February 2008 (UTC)

WP:As of has a point. Anyone reviewing an article with 1991 census statistics should now update them to 2001. (This may not be what the article needs most; but it is one of the things it needs.) The link is, and may work as, a reminder to do this. Septentrionalis PMAnderson 17:08, 17 February 2008 (UTC)

Ah right I get you now Lightmouse. I don't have much to say on it—I'd want to hear from someone heavily involved in those links, I simply don't have an opinion on their usefulness because I'm not involved with updating dated statments—but I just wanted to say thanks for the clarification, I appreciate that. Neonumbers (talk) 06:08, 21 February 2008 (UTC)

• Excuse me, why on earth is a link necessary to "remind" people that measurements from 1991 need to be updated? Doesn't "1991" itself suggest that? Tony (talk) 09:33, 24 February 2008 (UTC)

• The as of solo year linking silliness should be done away with. If we want to encourage people to update (example) this information after January 2008, the {{update after}} template can be added with {{update after|2008|01|01}}. The inline flag remains invisible in the text until the date specified in the template is triggered. That's what we should be encouraging. See 7 World Trade Center#Building opened. There is nothing helpful added by the use of the as of links, while the update after template is quite useful. It's invisible until the date triggers it to show. As of is covered by WP:MOSNUM#Precise language, and the year link adds nothing. SandyGeorgia (Talk) 14:54, 24 February 2008 (UTC)

Ordinal centuries in WP:MOSNUM

Where is the discussion regarding this? As I noted in the edit summary, the edit that made this change was based on the mistaken assumption that the spelling out of century numbers was disfavored prior to the re-organization of the page, but this is incorrect: prior to the re-organization the MOS allowed for either "17th" or "seventeenth", which was the long-standing consensus for several years over numerous discussions. —Centrx→talk • 08:09, 24 February 2008 (UTC)

I can't remember where the discussion was, or even whether it was at WT:MOS or WT:MOSNUM. That's a consequence of the present chaotic way in which MOS discussions are conducted. (Join the push for coordination! See Wikipedia_talk:MOS#WikiProject_Manual_of_Style.) But note this wording, from the current provisions of WP:MOSNUM:

Ordinal numbers are spelled out using the same rules as for cardinal numbers. The exception is ordinals for centuries, which may be expressed in digits (the 5th century CE; 19th-century painting).

That is vague! And it is replicated at WP:MOS. What is the force of that may, exactly?

I suggest you raise the matter for discussion at WT:MOSNUM, once more. Never mind that there may have been a spurious consensus one way of the other in the past. Just about every such consensus turns out to be equivocal. With respect, if you want to change a current provision, do it with current discussion.

– Noetica^♬♩ Talk 08:37, 24 February 2008 (UTC)

The meaning of the word "may" is the same here as its English definition, and the same as used in every other recommendation, regulation, RFC, legal document, etc. See, for example RFC 2119. "May" does not mean "must" or "must not". There is nothing vague about it.

The MOS has never disclaimed the use of spelled-out numbers for centuries, in all its seven years. There was no discussion to have it do so, as you can see in the archives around that time period; the change to have it do so was made as a result of a misunderstanding, in this edit. —Centrx→talk • 09:07, 24 February 2008 (UTC)

Above copied from [3]

I've started a discussion of ordinals in centuries and millenniums here.

--ROGER DAVIES ^talk 09:28, 24 February 2008 (UTC)

Context should influence style

In scientific contexts, the trend to express numbers in numerals goes much farther than in literary ones. I find "three," "two," and sometimes, even "one" (!) expressed consistently, within text passages, in numerals, in both popular and scholarly scientific publications. The rule in ordinary English composition that was taught almost universally in America, and appeared in Wariner's, prescribed (if I recall correctly) spelling out words for numbers which consisted of single words, like "seventeen" and "sixty-five." "Newspaper style" was considered exceptional. As far as I know, there's no reason to discard that rule, except in articles on technical and scientific topics, where spelled-out numbers would seem strange and archaic. I advocate amending this manual of style to reflect the rules of common usage and their dependence on subject matter. "There were 6 icebergs" would be correct in Science, but wrong in The Hudson Review. Unfree (talk) 20:02, 24 February 2008 (UTC)

This used to be in the style guide but was lost at some point. Do note that this is not universal for any scientific usage. If the number is a measured unit directly relevant to an experiment or a physical description, then the numeral is common, but not if the number is used as a common number. For example, "10-foot pole" only if the pole was measured to be 10 feet, but "ten-foot pole" if it is a common pole of this variety; or "In a mapping of region X, there were 6 icebergs" but "We encountered six icebergs on our expedition". —Centrx→talk • 23:09, 24 February 2008 (UTC)

Uncertain but sandwichable dates (x/×)

Another user from the GA review of Albin of Brechin suggested that I take the issue of x/× dating here in order to established notes on the MoS guide regarding these. I use em all the time, as they are necessary for historical clarity and accuracy in many of the article upon which I work, but I too cannot find anything. Any thoughts people? Regards, Deacon of Pndapetzim (Talk) 21:35, 15 February 2008 (UTC)

I.e., "began to reign in 86x" or "8xx". Do we want to advise on these? They are (semi-)standard usage; but they are writing for specialists, not for the general reader. Except in the rare case where a last digit is known and a middle digit is uncertain, they are usually replaceable by "in the 860's". Septentrionalis PMAnderson 17:42, 16 February 2008 (UTC)

I don't think that's what Deacon of Pndapetzim meant, I think (s)he meant the use of "died 1286 × 1292" to mean, "died between 1286 and 1292".

I've never seen that before, but if it's standard practice that would generally be useful, I don't mind seeing it in the manual—but I would need to be convinced it would be readily understandable by most educated readers. Neonumbers (talk) 10:18, 17 February 2008 (UTC)

I've never seen it before either; I think "between" or, for the actual case, "1244 or 1245", would be better. If a symbol were used, I would expect a hyphen or dash, but I suppose that would overexcite the WP:MOSDASH enforcement unit. A virgule "1244/5" is usual when the event is dated to a period of twelve months that doesn't begin in January, but that is ambiguous (with the equally conventional use of the virgule to mark the period between January and March 25). Septentrionalis PMAnderson 17:04, 17 February 2008 (UTC)

It's an essential part of some types of historical writing ... and you can communicate a lot of information very quickly with it. It doesn't really mean "between", as it includes the dates/years which enclose it. It's a wee bittie similar to the way ≤ is used in Maths. I'll give you an example of a text, Watt's Fasti Ecclesiae, p. 152, Deans of Glasgow, s.v. Salomon:

"Not yet dean Mar. x May 1159 (RRS, i. 194); occ[urs] 6 Jan. 1161 x 20 Sept. 1164 (...[source]...); occ. 1 Nov. 1164; occ. 7 Mar. 1175 (...[source]...)".

s.v. Herbert:

"Not yet dean 1179 x 1196 (...[source]...); occ. 1188 x 1189 (...[source]...); occ. 1179 x 1221 (...[source]...); occ. 1204 x 1207 (...[source]...)"

That's a pretty specialist book, but you encounter is often enough in normal scholarly works. In say an article on Albin of Brechin, where it was brought up for the first time, it may get a little tedious to keep saying between and etc every sentence, when you can say "he occurs DATE x DATE, DATE x DATE and DATE x DATE". At any rate, this is used extensively in the lingua anglica and so the MoS should definitely cover it in some way, even if it's to forbid its use. Regards, —Preceding unsigned comment added by Deacon of Pndapetzim (talk • contribs) 11:41, 28 February 2008 (UTC)

Years and dates

BCE/CE is not a good notation. Most people don't recognize it as they do with the BC/AD notation. The reson for using BCE/CE should be that is less religiously controversial, but it only common for christians and jews. I suggest trying to find a new meaning for the abbreviations without mentioning especially Domino (Latin for Lord) which I've understood is the most controversial word.

To be a bit constructive I should probably come with some suggestions:

BC/AC : Before Counting/After Counting or Before Ciphr/After Ciphr (Ciphr=latin for zero) Magnus Andersson (talk) 17:18, 26 February 2008 (UTC)

Allow me to ascertain that I have understood your proposition correctly, my dear fellow: are you suggesting that we should create a new chronology system?

This is inadvisable for many reasons. The most basic one is that we are an encyclopaedia; we only use existing means of noting the passing of time. It is not our job to create any new such means, or different ways to interpret them, and even if we did, nobody would understand them anyway, so it would be pretty useless. Besides, the Common Era notation enjoys wide usage and recognition in the scientific community, as any serious scientist would tell you; in addition, good articles using this notation should link to the Common Era article in its first instance, so people unfamiliar with it can learn what it is (and know about it thereafter).

The International Organization for Standardization is probably the institution you ought to contact for such suggestions. Who knows, they might even be interested. ;-) Wikipedia, however, is an encyclopaedia: we record, we do not create. Waltham, The Duke of 18:00, 26 February 2008 (UTC)

Don't wikilink units in infoboxes & tables?

This change was just made (change in bold):

• In tables and infoboxes, use unit symbols and abbreviations; do not spell them out. They should not be internally linked with wikipedia pages.

Why not? Was this change discussed anywhere? —Preceding unsigned comment added by Gerry Ashton (talk • contribs) 18:42, 13 February 2008 (UTC)

added line - is there a better way to phrase it. CorleoneSerpicoMontana (talk) 21:25, 13 February 2008 (UTC)

I don't understand the need for this change. Please explain. Thunderbird2 (talk) 21:31, 13 February 2008 (UTC)

I'm opposed to this change. In infoboxes and tables, space is at a premium, so there no room to explain units. Hence, the need for wikilinks is greater than in the text of articles, not less. --Gerry Ashton (talk) 22:00, 13 February 2008 (UTC)

I agree with Gerry Ashton. Thunderbird2 (talk) 22:09, 13 February 2008 (UTC)

I'd rather see links to unit articles in the text but if the unit does not appear in the text & needs linking, why not link from an infobox or table? Generally, yes, in tables & info boxes should use abbreviations but not always, obvious examples are where the abbreviation is not well recognised, could easily be misread or doesn't even exist. Shall we not look into a rephrasing of the whole point? Jɪmp 02:53, 14 February 2008 (UTC)

re-worded. This comes from working with alot of sports infoboxes where the weights and heights are detailed in both imperial and metric systems. CorleoneSerpicoMontana (talk) 08:40, 14 February 2008 (UTC)

Can you point us to a specific example that causes a problem? Then we can try to help you solve it. Thunderbird2 (talk) 09:02, 14 February 2008 (UTC)

The articles from the UK, and Australia at least work in st, lb, & kg, along with ft, in & m. I don't believe the need to be linked as it only makes the infobox garish. The units themselves are described in metric and imperial units and it seems that were someone not used to using either system, which frankly seems unlikely they can go through the search feature. This is a small problem as it is only a very small percentage that currently link units. CorleoneSerpicoMontana (talk) 09:08, 14 February 2008 (UTC)

See: Wikipedia:Only make links that are relevant to the context "What generally should not be linked" "Plain English words, including common units of measurement." Lightmouse (talk) 10:30, 14 February 2008 (UTC)

My view is that non-SI units should be linked somewhere in the article, and preferably on first use. If they are linked outside the infobox, there is no need to do so again inside it. Thunderbird2 (talk) 17:55, 14 February 2008 (UTC)

Depends on the unit. Rods and perches should be linked, simply as rare words, independently of this guideline; linking ton is one way to deal with ambiguity (although explanation, perhaps in a footnote, would be better). But linking foot is as unnecessary as linking leg. Septentrionalis PMAnderson 03:17, 15 February 2008 (UTC)

In that line, the "stone" as a unit of measure mentioned by CorleoneSerpicoMontana is a rare word to most native speakers of English, let alone to almost all of the many readers we have who are not native speakers of English.

But to say that in infoboxes and tables, units should not be linked is nonsense. There are many SI units which should be linked as well (how many of you understand joules and katals and kelvins and luxes and becquerels well?), as well as hundreds of Fred Flintstone non-SI metric units, English units, and units of a number of other old systems of measurement from all over the world. "Infoboxes and tables" include more than those just listing an athlete's height an weight. They use all sorts of strange and uncommon units.

Like Pmanderson/Septentrionalis says, there is usually not any real need to link feet. There is also not any good reason to link inches or meters or kilograms. But pounds often need to be linked for disambiguation purposes, especially in the thousands of articles we have using both the pound and the pound, as well as to disambiguate both of them from the various currencies of the same name). But even for pounds, when it is a listing of a persons height and weight, there is no crying need for any link. We aren't going to be thinking these are pounds sterling nor wondering what they are in terms of euros, and while some miseducated science-trained people might be confused enough to think they are pounds-force, that's their problem not ours. One little link isn't going to remedy their miseducation, if they've already ignored the evidence of the conversion to kilograms rather than newtons and everythig else.

I agree with Gerry Ashton's point that linking of units is slightly more necessary in infoboxes and tables than in running text. Furthermore, linking in text should not necessarily preclude linking on first appearance in boxes and tables, nor vice versa. For one thing, it isn't always clear which comes "first" in everybody's reading habits, and boxes and tables are likely to be considered in isolation without even reading the text by some, while others will be reading the text and paying little attention to everything else. Gene Nygaard (talk) 14:23, 29 February 2008 (UTC)

Prices are numbers too

We often don't bother to give numbers to four significant figures, and, wishing to avoid pedantry and the wasting of space, I therefore changed

for US$19.99, £12.99 in the UK or AU$24.99 in Australia

to

for US$20, £13 in the UK or AU$25 in Australia

in this edit. Realizing that this might be controversial, I immediately announced the change on the talk page of this popular article. To my surprise, it got just one (unfavorable) response. What do you people think? -- Hoary (talk) 10:04, 4 March 2008 (UTC)

For some purposes exact numbers are preferable, and for others they are unnecessary. Unnecessarily reducing the accuracy of data can make it less useful to some people. In the case of prices, the difference between £12.99 and £13 is negligible; but there is no advantage in changing £12.99 to £13. If you are writing an article and you want to say £13 instead of £12.99, fine; but don't edit other people's work to make this change as you just annoy people and potentially make the data less useful.--Toddy1 (talk) 19:19, 4 March 2008 (UTC)

I am trying to think of when it would be necessary to quote the cents/pence/koupek... As WP:NOT#DIRECTORY, we are discouraged from putting retail prices except when they are historically relevant. Use of the units after the decimal place appears to matter the most from the sales (price pointing) perspective for any given product, although occasionally one may be called upon to cite a historical high or low share price or discuss the psychological impact of this type of price pointing in same, but generally the simplicity of $13 over $12.99 within wikipedia is a clear advantage, AFAICT. Ohconfucius (talk) 03:57, 5 March 2008 (UTC)

The size of a thousand

Commas are used to break the sequence every three places left of the decimal point; spaces or dots are never used in this role (2,900,000, not 2 900 000).

says the manual under the heading Large numbers. We do intend this to start a 1,000, don't we? I'm suggesting we tighten the language to make it clear what exactly we mean by large. Are we considering numbers in the range of 10,000 > x ≥ 1,000 to be large here? Jɪmp 14:36, 4 March 2008 (UTC)

DWT

The shipping term deadweight ton refers to a long ton (2240 lb) of deadweight. It is abbreviated as "DWT". A similar term, deadweight tonne, refers to the same but this time in tonnes (1000 kg). The problem is that it seems that the same abbreviation, "DWT", is used. Russ Rowlett's Dictionary of Units of Measurement has this to say.

deadweight ton (dwt)
a traditional unit of weight or mass used in the shipping industry. The deadweight tonnage of a ship is the difference between its weight when completely empty and its weight when fully loaded. This includes the weight of everything portable carried by the ship: the cargo, fuel, supplies, crew, and passengers. The deadweight ton is traditionally equal to the British ("long") ton of 2240 pounds (1016.047 kilograms). However, more and more often it is being taken to equal the metric ton (exactly 1000 kilograms, or 2204.623 pounds).

How do we go about dealing with the ambiguity? It has been suggested, by Haus, that we choose a standard for Wikipedia. Other means of disambiguation have also been suggested. So far four approaches have been considered. Symmetry would have us consider a fifth (I do like symmetry). Let me list them.

1. Let "DWT" always stand for long tons of deadweight and spell deadweight tonne(s) out whenever necessary.
2. Let "DWT" always stand for tonnes of deadweight and spell deadweight ton(s) out whenever necessary.
3. Avoid the abbreviation, "DWT", altogether and always spell both terms out.
4. Use "DWT (metric)" and "DWT (long)" for tonnes and long tons respectively of deadweight.
5. Use "DWT_metric" and "DWT_long" for tonnes and long tons respectively of deadweight.

Here are some of the advantages and disadvantages that I see with these.

1. This follows tradition. As far as I can tell, this is the most common meaning of "DWT". However, I've got only my own Googling to to support this and we're aware of the American dominance of the web. Also, as the decades, centuries ... millenia ... wear on ... Wikipedia is forever, right. The long ton meaning of "DWT" might fall out of favour.
2. Against tradition & common use but may be forward-looking, this has the added advantage of naturally conforming to standard Wikipedia practice in which conversions to metric are generally given whereas conversions to avoirdupois are generally not and in which (in text as opposed to infoboxes) the units converted from are generally spelt out and the units converted to are generally abbreviated: in other words 2. allows "125 deadweight tons (127 DWT)" whereas with 1. we can only have either "125 DWT (127 deadweight tonnes)" or "125 deadweight tons (127 deadweight tonnes)". Of course, both 1. and 2. require that readers and editors be familiar with the Wikipedia standard — this may be a big ask.
3. This avoids any possibility of ambiguity and is unbiased towards this or that system of measurement but means that we have to have a lot more text.
4. This again avoids the ambiguity and bias. It allows both terms to be abbreviated. It makes it clear to those none too familiar with shipping that it is a long ton rather than a short ton (or even a metric ton) which is being refered to. However, it is kind of ugly especially if you're a conversion, e.g. "125 deadweight tons (127 DWT (metric))", even more so if you want to abbreviate both units, e.g. "125 DWT (long) (127 DWT (metric))".
5. This has the advantages of 4. whilst avoiding the ugliness, however, it could be argued that a subscript is part of the symbol therefore "DWT_metric" & "DWT_long" could be seen as being symbols of our own invention.

So, what say you? What do we do here? My preference is going to 5. (I had been keen on 4. until I started typing examples out & saw how it looks). Jɪmp 07:29, 4 March 2008 (UTC)

Just to point out that we're not the only ones having difficulties with this, the GPO uses inconsistent deinitions where "ton=long ton," "t=metric ton (or tonne)," but "dwt"="deadweight ton." My inclination is also orbiting #4 and #5 above. On the surface, it seems that a clever use of wikilinks could be used to stave off confusion, but it seems to work poorly on long pages with many uses of the forms "DWT_metric" & "DWT_long" Cheers. Haus^Talk 15:05, 4 March 2008 (UTC)

Overall I too would prefer #4 or #5 (the latter being better due to being prettier). It should be remembered however that the problem of ambiguity also extends to sources - for instance this very useful website lists a DWT figure for mosts ships but I've no idea whether they're in tons or tonnes (presumably the metric ones, but is that an assumption I can make?). -- Kjet (talk · contribs) 15:32, 4 March 2008 (UTC)

Of course, your linking could go like this "DWT_metric" & "DWT_long" but, yes, disambiguation via links is problematic not only for the reason mentioned above but also because it requires the reader to click on the link (unless they're familiar with the tool-tip-hover-over trick), which can be a great distraction and which will be impossible if you're sitting on the train with a copy of the article you'd printed during lunch. Jɪmp 16:23, 4 March 2008 (UTC)

My two cents.

Avoid "DWT" entirely. Spell out deadweight when appropriate.

• For what it's worth, you also see "dwt tons"; the "t" at the end of dwt doesn't even have to come from "tons" or "tonnage" in any flavor; rather, some look it as the "wt" being a common abbreviation of "weight" with a d stuck in front to identify "deadweight".

Any discussion of using "tonne" is inappropriate without also considering American English, where it is a metric ton not a "tonne", and French, where tonne is as ambiguous as ton is in English.

What is needed with all the ton of different "tons" used in shipping is more clarity in what is being measured. More clarity on the meaning of "light weight" and various other things used as well as dead weight. More clarity on basics such as whether the measurement is a measurement of volume or one of mass. For example, what do we do with submarines? Their surface displacement is a normal measurement of mass, but their dived displacement is essentially a measure of volume: Archimedes' principle, a floating object displaces its mass and a submerged object displaces its volume.

It is truly unfortunate that the BIPM and other standards agencies consider any tons acceptable for use with SI, and doubly unfortunate that they choose to specify a symbol for it (t) that is also used for long tons or for short tons.

• Therefore, let's just stick with unambiguous megagrams (Mg), gigagrams (Gg), teragrams (Tg) and the like for the units. Gene Nygaard (talk) 18:45, 4 March 2008 (UTC)

To be more specific on my first point. I especially mean not to use "DWT" (nor the more appropriate lowercase "dwt") as a symbol for a unit of measure. It is less objectionable to use it as part of the identification of the quantity being measured, but you should not have a number followed by "dwt" used as a unit symbol, whether standing alone or the subscripted suggestions above. It's part of the general rules about not attaching information to the units of measure, and especially not to the metric units. Using something like psia or psig is frowned upon for the same reasons.

• Unacceptable: The ship is 9,400 dwt_long (9,400 dwt_metric)
• Acceptable: The ship has a dwt of 9,400 long tons (9,550 t) [at least on first use in an article, I'd say that it is better to spell out "deadweight tonnage" than to use "dwt" in this case]

Gene Nygaard (talk) 18:55, 4 March 2008 (UTC)

So, we have a sixth option.

6.	Don't use "DWT", use "dwt". However, "dwt" is an abbreviation of "deadweight" not "deadweight tonne" or "deadweight ton". Neither use "deadweight tonne" nor "deadweight ton" but treat "deadweight" like "height", "length", "speed", etc.

Of course, "dwt" (lower case) is the symbol for the obsolete pennyweight (here's another example of "wt"'s standing for "weight" ... also "cwt") but if (when we're talking about deadweight tonnage) we're not using "dwt" as a symbol for a unit of measure, there can be no confusion.

One must admit that Gene's approach is the easiest to comprehend as it follows the norms of English — "The ship has a dwt of 9,400 long tons (9,550 t) and the captain has a height of 6 foot 2 inches (188 cm)." We'd also avoid the temptation to use the fancy unconventional linking I suggested above (linking "DWT" to Tonnage and the subscripts to articles on their respective unit).

Gene, I suppose this means that the likes of "bhp", "shp", etc. is also frowned on.

Jɪmp 01:14, 5 March 2008 (UTC)

I like the #5 option. I wouldn't use dwt because of the pennyweight measurement. —MJCdetroit ^(yak) 02:00, 5 March 2008 (UTC)

Trying to distinguish "dwt" meaning deadweight from "DWT" meaning deadweight metric tons (or deadweight long tons, whatever) is just sheer lunacy. We have enough articles tainted by Wikipedia usage already, without having to create a new way of accomplishing this.

And worrying about a unit the Brits—and by extension, most or all of the Commonwealth—outlawed over 129 years ago (as of 1 Jan 1879, together with its pound, while retaining its ounce as an official exception to metric conversion in the 21st century), is not far behind. Especially when it is ³⁄_1960000 as large; anyone who thinks for more than a millisecond that these ships might be weighed in pennyweights probably ought not be allowed to use an encyclopedia in the first place.

These are not different units of measure. We should not have different unit symbols depending on the particular application in which they are being used. These proposals are like using "French degrees Celsius" and inventing a Wikipedia symbol ^FC for them in articles related to France, and "Swedish degrees Celsius with a symbol ^SC for them in articles related to Sweden. Gene Nygaard (talk) 14:46, 5 March 2008 (UTC)

I'd be interested in seeing a reference which defines "dwt" as "deadweight" and not "deadweight tons" or "deadweight tonnage." Various forms including "DWT," "dwt," "d.w.t." are used to indicate "deadweight tons" or "deadweight tonnage" at the GPO as I mentioned earlier, 6 dictionaries and the three industry-specific technical manuals I have at hand. Haus^Talk 15:05, 5 March 2008 (UTC)

←outdent← Weighing ships in pennyweights ... hilarious. No, anyone with half a brain could tell the difference. My concern, however, was that a template can't. Jɪmp 15:50, 5 March 2008 (UTC)

Not much different from the half-baked notion that we should not use "kt" as a symbol for the unit of speed for those same ships, because somebody might confuse it with a symbol for non-SI and not-acceptable-for-use-with-SI units of energy, is it?

I realize where you are coming from. My main point is that a template for converting measurements should not be concerning itself with what those units are being used to measure. It is the same "tons" that are used for "light weight" of a ship as for "deadweight" of a ship, the those same tons are also used for "standard displacement" and for "full load displacement" and various other weights. Two or three different units all called "tons", to be sure, (plus a ton of other tons measuring volume and energy and force and power and whatever) but not 15 or 24 or whatever different units of mass.

But for those who do not realize where you are coming from, let me explain. User:Jimp is the one and only person on the planet Earth who is capable of editing the monster template {{convert}}. It can do lots and lots of different things, most of them quite well. It also does many other things very poorly. But it is so bloated, so convoluted, that nobody other than its chief creator (at least since the early days as a simple template) can figure out how to fix it if it isn't working as well as it should. He has total control; no fixes can be made without going through him, even if the template weren't "protected". Even ordinary users would have to study it for the equivalent of a 6-semester hour college course in order to be able to understand its intricacies and use that black box well in all situations. To show just the tip of the iceberg:

• The Category:Subtemplates of Template Convert has 1,024 articles.
• Special:All pages for the template namespace has somewhere in the neighborhood of 3,033 subpage templates and subpage template redirects under the main convert template.
• Yet, despite all this complexity (or perhaps more properly because of this unbelievable complexity), you can

Apparently convert nautical miles to siemens per tesla:

• {{convert|1347|nmi|S/T}} → {{convert|1347|nmi|S/T}}
  1. That's not an accurate conversion, of course. And in any case, even when you figure out that the "S/T" symbol isn't intended to represent siemens per tesla (whose dimensions are the inverse of those of acceleration, L⁻² T), you still have the problem that despite its overwhelming complexity, the convert black box does no dimensional analysis of the units, and lets you blithely convert apples to oranges. Perhaps not literally, or I just don't know the symbols for 1,347 apple, one of the few missing on that Special:All pages list. But, in this case, the eguivalent nautical miles (dimensions: L) to short tons (dimensions: M) does not produce an error message, unlike the attempt to literally convert from apples.
  2. What that "S/T" is intended to represent indicates a significant need to expand the scope of the current discussion beyond the original "DWT" issue.

Or, suppose you have a product with nutritional information "per 12 ounces" and you want to convert it. Using "per {{convert|12|oz|mL|disp=/|sp=us}})" looks reasonable, doesn't it?

• If you want to see what happens, go look at the article where I added exactly that conversion 3½ months ago. It is still there as I write this.
• Once again, bitten by a failure to do dimensional analysis.

Furthermore, the template has a strong bias against the use of American English, requiring explicit addition of a parameter (sp=us) to achieve it. Yet, when it comes to "metric tons", that parameter doesn't work. Instead, the spelling setting is ignored and what is spelled out depends on the unit parameters used.

Maybe this discussion should instead branch out to a more general discussion of whether or not the use of complicated black boxes of this sort is appropriate on Wikipedia. Gene Nygaard (talk) 17:18, 5 March 2008 (UTC)

I sympathise with Gene's statement that "a template for converting measurements should not be concerning itself with what those units are being used to measure" as a logical consequence of "the general rules about not attaching information to the units of measure", which, in turn, seem quite reasonable to me especially when looked at from the point of view of comprehensibility. However, if people are going about breaking these rules we either have to enforce them or work around the situation. Now, I was lead to believe that the terminology "deadweight tons", either long or metric, was what is in use and started to add such a work-around to {{convert}}. If instead we could somehow get editors to follow those aforementioned rules against this type of terminology, I'd be more than happy to trim the deadweight out of the black box. "1000 tons of deadweight" is a whole lot easier to comprehend to those unfamiliar with shipping terminology than "1000 deadweight tons" (better still if we specify what flavour of ton we mean). As for "DWT", "dwt", "d.w.t." or however you write it; if we can't make up our minds on what it's meant to stand for, why don't we just ban it? Thus a seventh option:

7.	Do not attach information to units of measure. Therefore don't use "deadweight (long/metric) ton(ne)(s)". Treat "deadweight" like "height", "length", "speed", etc. Don't abbreviate "deadweight", always spell it out.

As for Gene's comments regarding {{convert}}, some of them he has already voiced on the template's talk page and I have responded there; but, for those who might not feel like searching the template's talk archive, let me breifly recap. To that which we haven't yet covered there I'll respond here but again briefly, let more detailed discussion be carried out there.

Others can and have edited the monster (including Gene), though, yes, anything more than minor edits would require more patience in getting familiar with a rather complex template than most editors probably have. It is complex, it was, however, never my intention to make it so complex that I'd be the only one editing. If there is a significantly simpler way to get it to do what it does without increasing the pre-expand size, I'll be happy to see it replace the current version. I'd be only too happy to relinquish my "total control".

The lack of dimensional analysis is a down fall in the template. If this is a real problem, it could be fixed. Fixing it would, of course, require more code & therefore more complexity. I was aware of this as I wrote the template but I thought "Garbage In, Garbage Out" — if you try to convert litres per hundred kilometres to hectares, expect nonsense. I left it up to the template users to know what they're doing. Yes, unfortunately, this means that an editor might plug in oz hoping for fluid ounces but get avoirdupois instead. Then there's "PS" which the template takes to be metric horsepower as opposed to petaseimens and "S/T", mentioned by Gene, for short tons.

The template has a bias against ... [[WP:ENGVAR|? ... American English. How is it strong? What are our options? Unless we make it such that there is no default, requiring explicit addition of the sp parameter either way (which would benifit nobody); the bias has to go one way or other. I cannot see how a bias against American spelling is any worse than a bias against the way the rest of us spell.

Connect the whether the template gives "tonne(s)" or "metric ton(s)" to the spelling parameter, that could be done easily enough. It hadn't occured to me. I guess I think of "tonne(s)" and "metric ton(s)" to be completely different terms rather than simply different spellings of the same term.

Maybe a more general discussion of whether or not the use of complicated black boxes of this sort is appropriate on Wikipedia is in order. Maybe it should find its own section. Maybe this discussion should get back to how we want to deal with expressing deadweight tonnage.

Jɪmp 07:47, 6 March 2008 (UTC)

The only difficulty with #7 is that it inhibits succinctness. "DWT" occurs over 15 times in articles like Bulk carrier and Oil tanker. (There either are or will be lists where the term will be used many, many more times.) Reading back over this thread, an approach of "define it, then use it" emerges. In this edit, I worked a short definition into the first use in the article: "coastal tankers of a few thousand long tons of deadweight (DWT) to the mammoth supertankers of 650,000 DWT." Any feelings? Haus^Talk 11:51, 6 March 2008 (UTC)