Wikipedia talk:Manual of Style (dates and numbers)/Archive 94

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents

YEAR in TOPIC

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

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

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

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

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

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

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

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

Proposal: Do not use surprise links

The albums project contains the following:

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

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

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

Re-proposal

New version to address issue raised by Woody:

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

Revised version below.

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

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

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

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

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

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

Parentheses

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

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

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

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

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

Closure

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

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

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

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

How's that?

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

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

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

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

Markup for the hard space: update

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

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

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

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

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

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

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


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

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

As for the "first contributor" rule:

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

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

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

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

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

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

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

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


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

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

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

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

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

And?

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

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

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

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


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

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

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

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

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

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

A duty of disambiguation

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

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

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

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

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

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

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

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

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

How to list assumed / adopted birthdays

Per Mustafa_Kemal_Atatürk

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

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

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


Discussion of the hard-space proposal

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

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

ISO birth/death dates in biographies

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

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

Measurement query

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

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

Grouping of digits after the decimal point

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

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

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

Another example is "0.03937 inch".

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

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

Grouping of digits: Specific proposal (obsolete)

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

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

    Best typography practices:

    3.141 592 6535 and 1,579,800.762 04

    Acceptable delimiting:

    3.141 592 6535 and 1,579,800.762 04

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

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

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

Grouping of digits: Discussion

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

    1,579,800

    1,579,800.762045

    1,579,800.762 045

    1 579 800

    1 579 800.762

    1 579 800.762 045

    1 579 800.762045

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


0.1 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

0.2 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

0.25 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

0.3 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

&nbsp;

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

0.4 em:

6.02241679
6.022416794
6.0224167942
6.02241679423

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

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





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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Universal Dating

Please, for the love of $deity, can someone point me in the write direction to put forth a recommendation that we use the international / universal dating convention of DD/MM/YYYY rather than MM/DD/YYYY as is becoming prolific. Whilst I appreciate this is due to many of our editors and authors being of American origin, and no one system is correct, the most widely used system is smallest to largest, not medium to smallest to largest and we should perhaps adhere to that more stringently. At present reverting the use of two styles for dating will be a lot of work, but the longer we leave it the worse it will get. 58.107.154.192 (talk) 02:51, 3 February 2008 (UTC)

According to this manual of style, generally dates should be written in one of the forms that spells out the name of the month. ISO 8601 dates (that is, YYYY-MM-DD) may be used in "long lists and tables for conciseness and ease of comparison". DD/MM/YYYY and MM/DD/YYYY are both unacceptable. In my opinion, there is no chance whatever that either of these formats will ever be tolerated in any Wikipedia manual of style because of ambiguity. Feel free to replace them everywhere except direct quotations. --Gerry Ashton (talk) 03:36, 3 February 2008 (UTC)
If you create an account, you can configure your date preferences to show dates in whatever format suits you. This is (unfortunately) much more practical than attempting to get the entire project to switch to one format. — Aluvus t/c 04:09, 3 February 2008 (UTC)

Single-digit centuries

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

Sounds good to me. Tony (talk) 01:23, 27 January 2008 (UTC)
As no-one else has commented in a week, I've made that change now. PamD (talk) 07:44, 3 February 2008 (UTC)

Holy smokes, archive please

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

Made two archives and cut it down to 218k. Anyone object to automated archiving through User:MiszaBot? Perhaps archive threads after no comment for 15 days, with a max archive size of 150k? Gimmetrow 08:55, 1 February 2008 (UTC)
Sounds good, Gimmetrow. Tony (talk) 06:19, 3 February 2008 (UTC)
Automated archiving, I like the sound of that—maybe even a 10-day inactivity period might be enough. Neonumbers (talk) 10:01, 3 February 2008 (UTC)

Proposal to formalise the relationship between MOS and its sub-pages

Dear fellow colleagues: the idea is to centralise debate and consensus-gathering when there are inconsistencies between the pages. The most straightforward way is to have MOS-central prevail, and to involve expertise from sub-pages on the talk page there, rather than the fragmentary discourse—more usually the absence of discourse and the continuing inconsistency—that characterises WP's style guideline resources now. Of course, no one owns MOS-central, and we're all just as important to its running as other editors. I ask for your support and feedback HERE. Tony (talk) 12:12, 5 February 2008 (UTC)

Dry quart and liquid quart

Unless an article is discussing the sale of cherries, strawberries or something similar (cherries and strawberries are what came to mind first), the likelihood of encountering a U.S. dry pint or quart is highly unlikely. I checked and I couldn't find any occurrences and dry pints and quarts are not likely enough to include a provision about them in the MOS. Also, there really isn't a need to include liquid in front of U.S. pints and quarts either. When measuring beer, motor oil, trans fluid, water, et cetera, it is somewhat clear that a liquid is being measured. That being said, I've removed the line from the style guide about "quarts". If there is an argument for keeping it in, I'd like to hear it. Regards, —MJCdetroit (yak) 16:53, 5 February 2008 (UTC)

U.S. cookbooks usually require that dry ingredients such as flour and sugar be measured with liquid units. However, Wikipedia has few articles about cooking, and fewer still that give recipies, so it may not merit mention in the style guide. --Gerry Ashton (talk) 21:11, 5 February 2008 (UTC)
MJCdetroit is correct, this is too rare to warrant clutter on the MoS page. The liquid units rarely need to be distinguished as such, and as evident in the discussion above, the dry gallon is rarely used by that name any more. American recipes will usually use either a count (3 apples, medium-sized) or "cups" (half a liquid pint) for fruits and vegetables.
MJCdetroit, for one occurrence, see Columbia, Maine: "2 cents a quart" and "one quart wooden firkins" (the use of firkin for a box so small seems dubious to me; a firkin is normally a quarter or a third of a barrel, perhaps something which might have been used to hold several one-quart containers?). Gene Nygaard (talk) 16:47, 6 February 2008 (UTC)

Commas in linked dates

The line for [[May 15]] [[2005]] is not correct. When there is no comma in this format in the wikitext, a comma is added for (at least some) IPs and users with no date preference. Likewise, for [[15 May]], [[2005]] the comma is removed for (at least some) IPs and users without preferences. Gimmetrow 23:16, 6 February 2008 (UTC)

You are absolutely right. I have changed the table to red-X these formats. There are only 2 acceptable formats for full dates in WP text, not 4. Chris the speller (talk) 16:46, 8 February 2008 (UTC)
I cannot agree to putting green check marks next to formats that are not "acceptable" according to this guideline. There would have to be consensus that these are acceptable; this has already been discussed, with a few editors trying to loosen the standards based on the assumption that people who care how it looks will set a preference, while other editors pointed out that it does not put WP's best foot forward for new or occasional readers. I will change the table back, for now. Chris the speller (talk) 17:18, 8 February 2008 (UTC)
According to what part of the guideline are they "unacceptable"? Gimmetrow 17:59, 8 February 2008 (UTC)
The section "Full date formatting" shows the 2 formats that are acceptable for full dates (day of month, month and year); other formats are unacceptable, and for years all but the two have been unacceptable. There have been proposals to loosen the standards, but no consensus, as many editors feel that 2 formats are enough (or even too much). Chris the speller (talk) 02:32, 9 February 2008 (UTC)
What are you talking about that is not one of the "2 formats"? Gimmetrow 02:41, 9 February 2008 (UTC)
The guideline shows 14 February 1991 and February 14, 1990 as acceptable formats for full dates. The table also shows two variations on those, one (UK-style) but with a comma added, and the other (US-style) but with the comma removed. I did not mind that the table included these for completeness, because they can be found in use within WP, but objected to the implication that these were equivalent to the accepted formats. I think the table is OK now, as it no longer equates them. Chris the speller (talk) 17:09, 9 February 2008 (UTC)
Wikitext of the form "14 February, 1991" displays as one of the "acceptable" formats, right? Gimmetrow 19:41, 9 February 2008 (UTC)
Text entered as "14 February, 1991" is displayed unaltered, and is not acceptable because there should not be any comma. Did you mean to put some square brackets in your example? --Gerry Ashton (talk) 19:53, 9 February 2008 (UTC)
We're discussing dates linked for autoformatting, with the specific context of the forms mentioned in the table under that section. I would have thought that was understood. Gimmetrow 22:36, 9 February 2008 (UTC)
  • So again, why use a dysfunctional system in the first place? No one has fixed it, and no one looks like fixing it any time soon. MOSNUM says "normally" use it; what is "normal" is impossible to define. It is not enforceable. Tony (talk) 23:00, 9 February 2008 (UTC)
Do whatever you want, but at least present how the system actually works. Gimmetrow 23:25, 9 February 2008 (UTC)

To answer Gimmetrow's question about "14 February, 1991": yes, if the brackets are inserted, as you and I understood, it does display as an "acceptable" format. If the brackets are removed (and some editors will do that), then it will display in a format that is not "acceptable". I also think that the comma acts as a "speed bump" (US translation) or "sleeping policeman" (UK translation) for some editors. I can see no reason to encourage "14 February, 1991" when "14 February 1991" is the "acceptable" format and works just fine. On the other hand, I wouldn't edit an article just to remove the comma. Chris the speller (talk) 04:00, 10 February 2008 (UTC)

Is the featured article process failing to address date formatting

Please look at Norwich City F.C. and its recent edit history. It is a featured article but I believe that the way it handles dates is poor. For example some date links are broken and it had solitary months linked. It would be relatively easy for a few editors to correct this. However as a general point I wonder if the featured article process is allowing these things through? Lightmouse (talk) 12:40, 7 February 2008 (UTC)

Better to remove the auto-splotches altogether, for a cleaner appearance and so we can see what unregistered users—the vast majority of readers—see (a WYSIWYG approach). Tony (talk) 12:53, 7 February 2008 (UTC)
No, better to follow the guideline than Tony's personal taste. Chris the speller (talk) 16:48, 8 February 2008 (UTC)
Chris the speller, please avoid personalizing the discussion; it's not appropriate. Lightmouse, Norwich was promoted last April (2007). The "featured article process" is, well, you, me, all of us. The best way to address concerns about what it is "letting through" is to review articles there. You might want to transclude User:Deckiller/FAC urgents to your talk page. SandyGeorgia (Talk) 16:52, 8 February 2008 (UTC)
I don't think advising people to follow the guideline is personalizing the discussion. Tony knows that I admire his ideas and value his contributions, however much we disagree about autoformatting. Chris the speller (talk) 17:10, 8 February 2008 (UTC)
Interesting, and it is a fair point about the process being all of us. I must admit, the MOS is a bit too large and complicated for many people to follow. I would be all for a trim on the basis that a guideline should:
  • address a significant problem. This might be like the phrase 'clear and present danger'. There are multiple guidelines that are reasonable but get added as a result of concern over infrequent or relatively insignicant issues.
  • address a problem that would not be solved routinely by the wiki without a guideline. There are fixes that happen without guidance.
  • make a difference to editor action. Sometimes editors just ignore guidance.
What does User:Deckiller/FAC urgents do that the FAC page does not do? Lightmouse (talk) 17:56, 8 February 2008 (UTC)
  • Chris, despite your attempt to personalise the issue, I still hold that it's much better not to autoformat. MOSNUM, after all, says that this is done only "normally". Just what "normal" is is impossible to define. Just as well. Tony (talk) 22:59, 9 February 2008 (UTC)
You yourself advocated the "normally" phrasing when it was previously (most recently?) brought up, so I am not clear on what your complaint is here. I am still all for rewriting it to "should" or "should generally". — Aluvus t/c 00:05, 10 February 2008 (UTC)
The "normally" phrasing is highly desirable, because it allows people not to use this dysfunctional system when they prefer not to suck on all of its disadvantages. Tony (talk) 07:37, 10 February 2008 (UTC)
Adding square brackets to dates is optional and the MOS should be clear about that. We should make more efforts in the MOS to explain its failings. There are far too many instances of well-meaning editors that add blue to pages in the false belief that the MOS requires it, even if the date format is broken. Here is what one editor told me:
  • I have now made it linked for both dates, i.e.: "[[January 19]] and [[January 20|20]], [[1999]]". This seems to me to follow the linking of full dates requirement of MOS
Regardless of whether you are for autoformatting or against it, nobody wants broken dates like that. The irony is that we rarely see end-user complaints about broken dates... perhaps because there aren't many end-users. Not only is the cure worse than the disease, the disease is rare.
It is about time we had a very strong and clear explanation in the MOS that if you choose to add square brackets, you must not break the format and you must not think it means link all date fragments. In addition, we need a full time bot to clear up the broken date formats that editors are continually adding. Lightmouse (talk) 11:16, 10 February 2008 (UTC)

Why we should all be supporting the proposal to coordinate MOS and its sub-pages

Please see this example. Tony (talk) 12:51, 7 February 2008 (UTC)

It might be helpful to give slightly more information. The issue is the placement of AD (anno Domini). This page says that we should write "AD 1066" while WP:MOS says that both "AD 1066" and "1066 AD" are acceptable. The discussion in the section that Tony linked to has strayed a bit from the topic, but I hope that the section Wikipedia talk:Manual of Style#Resolving the AD issue itself will stay on the narrow issue of where to place AD. Your comments there would be most welcome. -- Jitse Niesen (talk) 21:58, 9 February 2008 (UTC)

At the time of my post, it hadn't gone off-topic. We still need to determine which guideline should prevail. At the moment, MOSNUM and MOS say different things. Tony (talk) 07:35, 10 February 2008 (UTC)

Grouping of digits after the decimal point (next attempt)

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

Overview

Below are the latest specifics of the proposal:

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

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


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


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


  • As can be seen in the above code, the template/parser function uses non-breaking spaces (&nbsp;) on both sides of the “times” (×) symbol and just before the unit symbol. Thus, there would be no line-end occurrences like the following:
The Planck constant would be fixed, where h = 6.62606896 ×
10–34 J·s,

or…

The avoirdupois pound is defined as exactly 0.45359237
kg, making one kilogram approximately equal to 2.205 lb.


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

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


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

    2.1
    2.12
    2.123
    2.1234
    2.12345
    2.123456
    2.1234567
    2.12345678
    2.123456789
    2.1234567890
    2.12345678901
    2.123456789012
    2.1234567890123

    The logic tree underlying this parsing method is shown in Digit-counting parsing logic, below.

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


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

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

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

  • The use of spans requires that they be closed with an equal number of </span>. Note the example code shown in the third bullet item down in this list.

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


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

Gap width details

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

Digit-counting parsing logic
In the mean time, the logic tree for delimiting to the right of the decimal marker would be as follows:
Q1: Are there five or more undelimited digits remaining after the decimal marker? No=Stop / Yes=Advance three digits and prepare to add span gap. Goto Q2.

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

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

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

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

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

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

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

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

Proposed policy for adoption

In “Continuing Discussion” below, Tony asked whether MOSNUM policy regarding the use of this template/parser function should be “framed as mandatory or optional”, my suggestion would be a formal policy as follows:

Per current MOSNUM policy, numeric values must have the integer portions of their significand (the digits to the left of the decimal marker) delimited with commas and the decimal marker must be a full stop (.), e.g. 1,234.567. Further now, the use of the {{delimitnum}} template/parser function (magic word) is “encouraged” and is the “preferred” method for delimiting numeric strings with five or more digits in the fractional portion of the significand (the digits to the right of the decimal marker). The use of {{delimitnum}} delimits values like 6.022461342 so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as Excel-pasteable numeric values.

In furtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or non-breaking spaces (e.g. coding 0.187&nbsp;985&nbsp;755 or 0.187 985 755 to produce 0.187 985 755) because such text strings can break at line-end word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of {{delimitnum}}. “Irreversibly” means that it is impermissible to convert a value that is delimited with {{delimitnum}} to a simple, non-delimited numeric string.

Further, numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 106) that were neither created with the {{e}} template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the {{nowrap}} template, or 3) use of {{delimitnum}}—exclusively so if the value has 5+ fractional-side digits.


The effect of this is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which use the non-Excel-pasteable non-breaking spaces (and also leave dangling single digits) would become “incorrect” and should be irreversibly upgraded. Greg L (my talk) 07:59, 13 February 2008 (UTC)

Continuing Discussion, specifically regarding latest nutshell proposal

  • I have always supported this proposal and continue to do so. Groups of 3 are an advantage for both editors and readers because they are much easier on the eyesight than long unbroken strings of digits. The improved solution offered by Greg L, Jimp and Atakdoug just make it better. Thunderbird2 (talk) 06:48, 30 January 2008 (UTC)
  • Makes sense to me. Seems well thought-out and practicable to implement. Formatnum already seems to work well, and can be tailored to locales, and this is a logical extension of that concept. --Slashme (talk) 07:25, 30 January 2008 (UTC)
  • And I’ll formally throw my hat into the ring. Delimiting long strings of digits to the right of the decimal marker is already a common practice on Wikipedia but isn’t always done properly. Further, hand-coding is cumbersome. The authoring community needs a template/parser function to automate this, standardize appearance per ISO and the SI, and make values pasteable into Excel to boot. Greg L (my talk) 20:12, 31 January 2008 (UTC)
  • Tony and SMcCandlish: are you two OK with the latest proposal? Greg L and Jimp have put in a lot of work to address your concerns. Thunderbird2 (talk) 18:08, 9 February 2008 (UTC)
  • Me, I love the thin spaces, and was disappointed that Jimp's combined nowrap and thin-space template doesn't work on stupid Internet Explorer, and thus had to be dropped. If this one works on IE, sure, why not? WIll it be framed as mandatory or optional? Tony (talk) 07:43, 10 February 2008 (UTC)
  • Tony, thanks for weighing in. You brought up a good question as to whether use of this proposed template/parser function should be “framed as mandatory or optional”, so I added a new subsection, Proposed policy for adoption, above, to address this issue. I hope that you and the others would comment on that too. Greg L (my talk) 05:48, 13 February 2008 (UTC)
  • I'd rather see visual spaces (however they are produced) rather than commas on one side of the decimal point and visual spaces on the other. Leaving that aside, I will feel free to allow a break between an unusually long number and a long unit of measure (whether the unit is long due to being spelled out, or because it is a long series of symbols). When a long line gets too long, it has to be broken somewhere. --Gerry Ashton (talk) 16:27, 13 February 2008 (UTC)
  • I too would prefer to see spaces both sides of the decimal point. I don't believe that this is too unfamiliar, see here, for an example. That aside, though, we've got three options:
    1. commas then no delimiting,
    2. commas then spaces or
    3. a haphazard combination of both.
It seems to me the third option is to be avoided if at all possible, however, this is exactly what we currently have. My first inclination was to push for standardisation on the first option, ruling the second option out. The reasons being as follow.
   a.  Numbers cannot be copied and pasted as numbers into another application if they contain spaces.
b. Commas then no delimiting is the accepted standard on Wikipedia.
c. Commas then no delimiting is the the norm in English.
Greg's spaces eliminate reason a: numbers delimited using these can be copied and pasted without copying and pasting the spaces too (since these spaces are not characters) ... (Here we see an argument for spaces then spaces: sometimes commas are not acceptable either, e.g. {{#expr:1,234*56}} won't work).
How true is reason b.? These discussions have made me take note of the way in which numerals are written in Wikipedia. I'm finding that delimitation via spaces after the decimal point is not something which occurs in just a handful of articles. It's very common. These spaces are here and are probably here to stay. On the other hand, {{formatnum:}} produces no spaces after the decimal point.
What we now have is the haphazard combination of formatting styles. Standardisation is needed. I'd be happy to see commas then spaces adopted as the standard. It could be more productive to do this than to try eliminating these spaces where they occur.
Reason c. is still valid, however, we don't have to follow the norm. The relative abundance of delimitation using spaces on WP seems to indicate that this is not so strange a way of writing numbers and that readers easily understand what's going on.
One of these days I'll have to get around to rewriting {{thinnbsp}} using Greg's spaces but I'm not suggesting we use this template for general number formatting. For that, a parser function would be best. In fact, it seems to me that, if this is adopted as the standard formatting then we should push to have {{formatnum:}} adapted accordingly.
Jɪmp 06:51, 14 February 2008 (UTC)
  • Thanks, Font size is an interesting example, but I find

       15 625 / 83 118 ≈ 0.187 985 755 2 mm

    hard to read. It took me a second to realize the left-hand side was the ratio of two five-digit numbers, and more time to realize that both sides were intended to be in mm. Septentrionalis PMAnderson 15:27, 14 February 2008 (UTC)

  • I agree with PMAnderson. Current MOSNUM policy requires that commas be used for delimiting to the left of the decimal point. I haven’t researched the MOSNUM archives but I have no doubt that the rationale for this policy was thoroughly hashed out and was arrived at for good reason. This policy (totally ignored in Font size with its 15 625 / 83 118) has served well since.

    We should limit our efforts here to agreeing on a policy—and developing a tool—that avoids instances of 0.187 985 755 2 mm, which (*sound of “raz” buzzer noise*) leaves a hanging digit and (*buzz*) uses full-width spaces and (*buzz*) can’t be pasted into Excel. A tool that automates delimiting to the right of the decimal marker will also make expressions such as e = 2.718281828459 far more readable. Greg L (my talk) 18:32, 14 February 2008 (UTC)

  • I hate to disagree with someone who agrees with me; but I like the effect of the spaces to the right of the decimal point, and oppose the use of a tool to force Wikipedia into being the feedstock of a broken Microsoft product. (Sorry, Tony, I don't mean to be redundant.) We have many users, who have many purposes; some of them just want to read the digits, or to transcribe them by hand. Septentrionalis PMAnderson 19:27, 14 February 2008 (UTC)
  • Oops, I now see my previous post was ambiguous ;-) when I was “agreeing with you.” As the author of this entire proposal advocating the creation of the template/parser function, I too very much “like the effect of the spaces to the right of the decimal point” and couldn’t agree with you more that some users need to actually “‘read’ the digits.” Perhaps above, I should have written the following in my second paragraph:
…We should limit our efforts here to agreeing on a policy—and committing to the development of—a parser function (not a template) that avoids instances of 0.187 985 755 2 mm, which (*sound of “raz” buzzer noise*) leaves a hanging digit and (*buzz*) uses full-width spaces and (*buzz*) can not be pasted into Excel. By using this proposed parser function, such values will properly appear as 0.1879857552 mm, which has the virtues of 1) using thin gaps, 2) doesn’t leave a single dangling digit, 3) doesn’t word-wrap, and 4) is Excel-pasteable to boot! This parser function will make cumbersome, non-delimited expressions such as e = 2.718281828459 far more readable by making them appear as e = 2.718281828459.
What I was referring to in the first paragraph of my previous post is that using gaps to delimit digits to the left of the decimal marker isn’t in accordance with current MOSNUM policy. That policy requires that commas be used to the left of the decimal marker. My proposal holds that we should not upset the apple cart by attempting to diverge from this now-well entrenched and well accepted practice. I’m pleased that Jɪmp, while writing his extremely thorough analysis of the options above—despite his own personal preference—acknowledged this reality when he wrote “I’d be happy to see commas then spaces adopted as the standard.”

Note that 2.718281828459 had long appeared in Natural logarithm until only a few weeks ago. When I changed it and explained that the value is now delimited and Excel-pasteable, it has been readily accepted even though the code required to do so is expansive. Giving authors a tool so all they have to type is {{delimitnum:2.718281828459}} will be extremely well received in my opinion.

The proposed {{delimitnum}} parser function wouldn’t change the way digits are currently delimited to the left of the decimal marker. What it does do is allow authors to quickly and easily produce easy-to-parse, non-wrapping, Excel-pasteable, properly delimited numeric values when they have five or more digits to the right. Greg L (my talk) 01:09, 15 February 2008 (UTC)

  • In general, I prefer an evolutionary approach. If every editor corrects things that bother him as he meets them, without going on a crusade, we should converge to a range of usage which reflects our editors' preferences; if there is consensus, it will be self-enforcing, without needing enactment here. Septentrionalis PMAnderson 15:31, 14 February 2008 (UTC)
15 625 / 83 118 ≈ 0.187 985 755 2 mm
is mathematically incorrect. The units must appear on both sides. As for the fraction's not looking like a fraction, {{frac}} would fix this up. Using this & the delimiting scheme under discussion we'd come up with this.
15,625⁄83,118 mm ≈ 0.1879857552 mm
Even with spaces to the left of the decimal point it still looks okay.
15625⁄83118 mm ≈ 0.1879857552 mm
But that's not what what's being promoted at this stage. Jɪmp 03:05, 15 February 2008 (UTC)
Simpler to wrap the "≈ 0.187 985 755 2" in parens, as I basically did at the article. But yes, the mathematical error is half the comprehension problem. The other half is that 15 625 / 83 118 is ambiguous; it can be read as two integers around the fraction 625 / 83. (This makes no sense, but that doesn't make reading it any faster.) Septentrionalis PMAnderson 03:13, 15 February 2008 (UTC)
True, whilst we're formatting the numerator & denominator on the same level it is ambiguous. That article needs work, though.
As for opposing "the use of a tool to force Wikipedia into being the feedstock of a broken Microsoft product" ... I can relate to this sentiment but I'd suggest we're only using Excel as an example. Numerals sprinkled with regular spaces generally don't get recognised as numerals no matter where you copy and paste them, e.g. copying and pasting them into a Wikipedia template to be used in some calculation (though commas don't work either here). Some of use just want to read/transcribe the numerals, others want to copy and paste them into some computer application; who gets their way? With the type of space under discussion here both of us get our way.
Evolution has its merits. It does show us trends. As Greg has pointed out there does seem to be a trend towards the use of spaces after the decimal. Greg has come up with an excellent way of producing these spaces but it takes a lot of typing. It could be done with a template but such a template would be a little heavy on pre-expand size. The best solution would be to have it done with a parser function, either a new one or, far better in my opinion, with an adapted {{formatnum:}}. How would we be able to make such a thing possible? Unless this is adopted as the standard formatting I don't believe we've got a chance. Jɪmp 03:41, 15 February 2008 (UTC)
Such a parser would be very useful. I shall oppose any efforts which may be made by editors with limited imaginations to make it mandatory. Septentrionalis PMAnderson 04:05, 15 February 2008 (UTC)
  • I suppose that it’s not over until the fat lady sings. But given that a consensus seems to be forming here, it’s natural to wonder how one actually gets the {delimitnum} parser function made. From Jimp’s earlier posts on my talk page it appears that pulling this off with a template would be suboptimal due to its complexity and the fact that numeric values may occasionally exceed 12 digits. A parser function (magic word) is supposedly the best technique to handle this. Parser functions are apparently written by “developers” (the programmers who make Wikipedia’s inner working and GUI magic possible). Is there someone here at Talk:MOSNUM who check-marks issues as “resolved” and then forwards issues like this to a developer so it can be addressed? Really, my bottom-line question is this: if it becomes clear that a consensus has been reached and action is warranted, will someone automatically step in and run with the ball or am I supposed to ensure this moves forward to an appropriate party? I believe for instance, that Random832 can handle this. But when? Greg L (my talk) 05:11, 15 February 2008 (UTC)
    • Like everything else around here, you gotta do it. See WP:BUGZILLA for how to file a request. A link to this section may help to persuade a developer there is actual demand for this. Septentrionalis PMAnderson 05:17, 15 February 2008 (UTC)
      • Thanks! Will do. Greg L (my talk) 05:22, 15 February 2008 (UTC)
  • Some queries on [2]. Shouldn't the span tags be closed, and why is one space not like the others? Does this proposal intend to modify the existing formatnum magic word? Gimmetrow 05:58, 15 February 2008 (UTC)
  • Gimmetrow, indeed the spans are closed with </span>. I realize I didn’t explicity point out the closing of spans out so I’ve taken the liberty of adding a bullet point regarding this into the “Overview” section, above. But let it be noted here that this information wasn’t there before your above-posted question. Thanks.

    Regarding why a 0.2-em gap is occasionally used rather than the more common 0.25-em gap, see Gap width details, above (scroll to the bottom of that subsection). The short answer though, is that the 0.2-em gap follows the digit 1. It slightly tightens the gap following the digit 1, which is important because the eye is sensitive to overly wide gaps, which can begin looking like separate numbers if not kept tight. P.S. Noting that this too wasn’t nearly explicit enough, I added a short paragraph to that section regarding the slightly thinner gap following the digit 1. Let it be here-known that this too wasn’t there until after your question.

    As to your last question (is {{formatunum}} going to be messed with), not to my knowledge. I don’t think anyone is proposing such and I am certainly not advocating it since doing so might have deleterious effects in existing articles. It would simply be a new magic word called {{delimitnum}}. Greg L (my talk) 07:39, 15 February 2008 (UTC)

  • I thought each span tag had to be closed for valid xhtml. There are three span tags, but only one close. Gimmetrow 23:34, 15 February 2008 (UTC)
  • You might be right as far as what is considered “valid” (or proper) Gimmetrow. I quickly found that if didn’t use the </span>, then the very next paragraph would be indented. But if I used a single </span> tag, then that problem disappeared and I usually have no other problems. This discussion is really more for intellectual stimulation and my edification because when it actually comes time for a developer to write the parser function, they’ll know exactly what to do. That’s also why I was so general specifying the location of the close-tag: why bother(?), the developer will undoubtedly do it a different way.

    I have noticed that I sometimes have odd problems when bolding and italicizing using '' (straight single quotes) if I have span-based delimiting in the paragraph. So what you’re saying might well be the case. Thanks. Greg L (my talk) 00:06, 16 February 2008 (UTC)

  • Closing all span tags is mandatory in both XHTML and HTML. MediaWiki lets you get away with doing the wrong thing because it automatically closes open span and div tags on final rendering of the page (in natural logarithm, it closed them at the end of the paragraph). This is not a standard (X)HTML feature and I believe not even a 100% standard MediaWiki feature (MW will automatically close some tags some times but not others, depending on settings and extensions), so other MediaWiki projects may puke on the same input. I have adjusted natural logarithm to remove this issue, although I don't love the notion of using spans in this way. — Aluvus t/c 01:26, 16 February 2008 (UTC)
  • That makes a lot of sense. Thanks for the fix Aluvus. And thanks Gimmetrow for pointing this out to me. This “span-based” business is only temporary since this proposal has moved forward to a developer. In the mean time, while the code is cumbersome, the results look and function well. I note that you salted each occurrence of </span> at the earliest opportunity after each span. On Natural logarithm, your fix (which produces “2.718281828459”) appears as 2.718<span style="margin-left:0.25em">281</span><span style="margin-left:0.2em">828</span><span style="margin-left:0.25em">459</span>. Although it’s the same amount of finger wear, would placing the close-spans all at the end, like this: 2.718<span style="margin-left:0.25em">281<span style="margin-left:0.2em">828<span style="margin-left:0.25em">459</span></span></span> be OK too? The only virtue is—for some people—it might make it a little easier to parse the code one writes. You take a number, paste the spans every three digits, and then paste the required number of close-spans. This method also generates the value “2.718281828459”. So let me check alignment after a font check of italicizing and bolding and italicized bolding. That all seems to work bug-free. What if I try to bold the delimited value: 2.718281828459. I think that one would have given me flack before. And what about alignment of a new paragraph?

    Yup, a new paragraph aligns well. Is this “save ‘em to the end” method OK too? Greg L (my talk) 02:29, 16 February 2008 (UTC)

    P.S. I’ve revised the third and eighth bullet items in Overview, above per both your teachings. Greg L (my talk) 05:27, 16 February 2008 (UTC)

Broader consensus needed

I believe broader consensus is required before asking for someone to devote time to coding this. So far as I know, outside Wikipedia, the appearance of number separations may be outlined thus:

  • Use comma as decimal separator (rejected in English Wikipedia).
  • Use full stop as decimal separator
    • No separators in integer or fraction parts
    • Comma separators every three places in integer part, none in fraction part
    • Space (thin or thick) every three places in both integer and fraction part
    • Ad-hoc methods adopted for a particular table or a particular publication

The existing rules in WP:MOS and WP:MOSNUM were chosen from the above options. Since no one uses comma separators in the integer part combined with thin space separators in the fraction part (remember, I'm talking about appearance) the existing rules should not be read to mean that the fraction part is fair game. It would be necessary to gain consensus on both talk pages for the concept of the appearance of thin spaces in the fraction part. --Gerry Ashton (talk) 06:09, 15 February 2008 (UTC)

  • This discussion is getting lengthy and it is apparently becoming tortuous to try to keep current with it all. However, these issues have already been addressed above. Current MOSNUM policy for English Wikipedia requires that commas be used for delimiting to the left of the decimal marker and that the decimal marker be a full stop. It is wholly unrealistic to upset the apple cart by attempting to diverge from this deeply entrenched and well accepted practice.

    As also addressed in the proposal at Rationale for using “comma delimiting” with “narrow-gap delimiting above, “it will be a rare number where commas (a U.S. style) and narrow spaces (a European/SI style) are juxtaposed within a single value.”

    What has also been covered in Making a case for why narrow gaps are already well-accepted on Wikipedia, above (and elsewhere throughout these discussions) is that the use of spaces to delimit values on the fractional side is today a common practice on the English Wikipedia pages. And why are editors using spaces to delimit the fractional portion? Because of this obvious truth: delimiting numeric strings to the right of the decimal marker serves precisely the same purpose as does doing so to the left of the marker and is very much needed on Wikipedia. However, it’s very often being done incorrectly and the resulting efforts are 1) inconsistent, 2) don’t look good due to the full-width spaces, 3) occasionally improperly leave single dangling digits, 4) often do line-end word wraps within the value, and 5) the values can’t be copied and directly pasted into Excel.

    Hand coding 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>&nbsp;×&nbsp;10<sup>23</sup>&nbsp;kg to produce 6.02246479 × 1023 kg address all these shortcomings but is extremely cumbersome and inflates the size of articles.

    All these shortcomings—with a practice that is already widespread on the English Wikipedia—are addressed with this convenient tool.

    Finally, as regards your assertion that it is “necessary to gain consensus on both [WP:MOS and WP:MOSNUM] talk pages,” that makes no sense whatsoever and frankly strikes me as a metric ton of weapons-grade bullonium. Wikipedia would grind to a complete halt and nothing could ever get accomplished if simultaneous and/or duplicate discussions had to occur across multiple forums! Talk:MOSNUM is clearly the proper and logical forum for this topic; that’s why it exists. Greg L (my talk) 08:26, 15 February 2008 (UTC)

  • The section "Making a case for why narrow gaps are already well-accepted on Wikipedia" is an expression of one editors impression of what is tollerated. Assuming the impression is correct, it only shows that both spaces and commas are widely used as separators; it presents no evidence that using commas in the integer part and spaces in the fraction part of the same number, or in the same article, is accepted as good style.

    I oppose this proposal on the grounds that it is a bastard. --Gerry Ashton (talk) 17:39, 15 February 2008 (UTC)

  • OK, that’s fair enough. Greg L (my talk) 20:24, 15 February 2008 (UTC)
  • If this does get implemented, there is one good point: if consensus were ever established to use the appearance of spaces for both the integer and decimal parts, it would be trivial to modify the template/parser function accordingly, and all the numbers written with that function would instantly take on one of the styles that is recognised outside Wikipedia. In fact, I like the template/parser function fairly well, except for the comma. --Gerry Ashton (talk) 06:03, 16 February 2008 (UTC)
  • “In fact, I like the template/parser function fairly well, except for the comma.”  I was hoping you’d come around Gerry—if only a bit. No worries, mate. In the Kilogram article, there are a boat-load of numbers delimited using this span-based technique. Yet, out of the entire article, there is only a single value that simultaneously required delimiting on both sides. I’d guess that 95% of the time, other editors will use {{delimitnum}} for the types of values typically seen in Kilogram. As I stated above, “it will be a rare number where commas (a U.S. style) and narrow spaces (a European/SI style) are juxtaposed within a single value.”  At least on those rare occasions, the value’s left-hand side will conform to the comma-delimited (U.S.) style officially endorsed for use on en-Wikipedia and won’t stand out like a sore thumb. Greg L (my talk) 19:35, 16 February 2008 (UTC)

NOTICE: Accepted and advanced for development

Congratulations to all; the proposal was accepted and presented to a developer on 02-15-08 to be made into a parser function. Thanks for your passionate and hard work on this {{delimitnum}} proposal. As many of you have no doubt noticed, the debates and comments here resulted in my having to go back to the Overview section many many times to modify and/or add bullet points to incorporate your many observations and suggestions.

It might be a bit premature to check-mark this as resolved (and move it to an archive) as technical issues may arise during the developer’s work. Currently, the Overview section serves as a concise central reference source/depository that can be conveniently updated when corrections and additionals are required. I suggest we leave this here and archive it after the parser function is delivered.

In advance, thanks to the anonymous developer(s) quietly volunteering their time in the background to provide us the tools that make our editing life easier.

Greg L (my talk) 05:56, 16 February 2008 (UTC)

New business

Any new business, such as that pertinent to the development of the parser function, may be entered below.