Jump to content

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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:Manual of Style | Dates and numbers
This is an old revision of this page, as edited by Dabomb87 (talk | contribs) at 01:10, 27 September 2009 (archive). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 120←Archive 124Archive 125Archive 126Archive 127Archive 128→Archive 130

New-look Manual of Style

A few weeks ago there was extensive discussion on FAC talk about the vast size, complexity and instability of the Manual of Style. On reviewing the text of the MoS, I agree that the Manual is much larger than necessary to cover the areas it does: about 20 thousand words. In particular:

  • it is often wordy;
  • it provides more examples than necessary;
  • it lectures around some of its points in a way that is not strictly necessary;
  • it is a little repetitive and disorganised.

As a service to featured-content nominators and reviewers, and editors at larger, I've created a new, user-friendly version of the MoS that is only 40% of the size of the full version. There are no intended changes in substantive meaning. The new version has the following features:

  1. brevity and directness of language, including the default use of active voice and contractives;
  2. new inline headings for every point, for ease of navigation;
  3. the removal of highly specialised points about numbers and dates, which are treated by MOSNUM;
  4. the removal of a few other sections that appear to be on the fringe, including Blason;
  5. the addition of a Currency section, summarised from MOSNUM.
  6. improvements in structural organisation;
  7. the use of links by asterisk, to reduce clutter.

Any changes to the full MoS as reflected in the new version will be notified, at the start of each month. Your feedback is welcome on the talk page.Tony (talk) 03:04, 16 September 2009 (UTC)


WP:OTHERDATE

Please abide by consensus

Jc3s5h, your edits were contrary to the results of the RfC you yourself conducted here on Archive 123. The {val} template was the result of very lenghty, months-long discussions by very many editors on both WT:MOS and WT:MOSNUM.

{Val} (originally known as “Delimitnum”) had its functionality described here in WT:MOSNUM Archive 94…

…it was extensively discussed and voted upon here in WT:MOSNUM Archive 94…

…and was well received here on WT:MOS Archive 97…

…where its functionality was tweaked to achieve a compromise solution that made everyone happy on an issue regarding the look of scientific notation.

Then a number of developers and template authors worked on it.

Please don’t presume that you can come along and change it without a proper consensus. Greg L (talk) 17:17, 18 August 2009 (UTC)

Greg L misinterprets the results of the RFC. While the Val template is generally acceptable in that it can be altered to accommodate almost any format for which there is consensus, Greg L is the only one who considers the commas-left, thin-spaces-right format to be the best choice. A few others considered it acceptable but not superior to other choices. The outcome of the discussion was to avoid the commas-left, thin-spaces-right format. Val should be modified accordingly.
I also call upon Greg L to abide by the argument he has often made with respect to binary prefixes (that is, follow external consensus rather than advocate formats that have not achieved external acceptance, and choose a format that has at least limited acceptance outside of Wikipedia to a format that has no acceptance at all outside Wikipedia. --Jc3s5h (talk) 18:34, 18 August 2009 (UTC)
  • You must not have read the links I provided, above; they show widespread, overwhelming support for {val}. The consensus (not just me) on Wikipedia is that the techniques {val} uses for scientific notation and long strings is a good one that causes zero confusion. If you don’t like it, don’t use it. But please stop trying to delete mention of it or discourage its use. It serves a valuable purpose in technical articles. Greg L (talk) 18:44, 18 August 2009 (UTC)

Delimiting numbers

  • (no longer beating around the bush here): One source of periodic friction on MOSNUM is the delimiting of numbers. There are four or even five different ways of doing so. In Sweden, they teach school children three different methods (and two of them are “Swedish 1” and “Swedish 2”). To make a long story short: Wikipedia allows both British and American-dialect English (spelling) in its articles, so long as they are consistent within an article. However…

    This practice of “your way / my way… it’s all just six of one / half a dozen of the other” doesn’t apply to numbers. Why? Wikipedia has gone through all this before many times, and new editors who come here don’t have the benefit of all that history and discussion. But it comes down to this: English-speaking Europeans are familiar and comfortable with a many different ways of delimiting numbers and the American style causes them no confusion whatsoever. Comma-delimiting might not be the most common practice for English-speaking Europeans, but they recognize what it means and fully understand the numbers. However, Americans are familiar with one and only one method; as a group, they have had no exposure whatsoever to other ways of delimiting numbers. So, especially for general-interest articles, in order to cause the least confusion, the American method of using commas to the left of the decimal point is to be used on Wikipedia. Scientific articles; particularly ones directed to a professional readership, are the only exception.

    The argument that “Well, Wikipedia will just start using the Euro/BIPM method and dumb-ass Americans will simply learn” just doesn’t fly and it never will. Wikipedia doesn’t have that kind of influence; all that sort of attitude does is produce confusion. Our aborted attempt to push the world into the adoption of the IEC prefixes (kibibytes and KiB) amply demonstrated that. After three long years, the practice was no more well adopted throughout the world than before. All Wikipedia accomplished by letting itself by hijacked by a handful of editors who wanted to push the world into a new and brighter future with warp drive and membership in the United Federation of Planets™®© was to make our computer-related articles needlessly confusing. We follow the way the world works and can not presume to lead by example.

    We can’t have MOSNUM subtly edited in a fashion that tacitly allows numbers in articles, other than science-related ones, to be delimited with thinspaces in place of commas to the left of the decimal point; it is unnecessarily confusing to too many readers. This is the way it has long been done and there has been no decision to change the practice.

    As for delimiting with gaps to the right of the decimal point using {val} on high-precision numbers, particularly in engineering and scientific-related contexts where the distinction between numbers is important and the values actually have to be parsed and understood, that confuses absolutely no one—even “sheltered Americans”. A value like 1.6162523625×10−35 meters is no more confusing than the decidedly non-SI-compliant, five-digit delimiting used for mathematical constants (particularly in tables of constants), such as 3.141592653589793238462643383279...; everyone instantly “gets” it. It is a much-appreciated and much-needed touch that makes long strings of digits much easier to parse. Moreover, its technique of using thinspaces to the right is the only possible method that could be employed to solve the problem of long strings without upsetting the apple cart; it was either do nothing (and have absurdly long strings that can’t easily be parsed) or utilize the only logical available technique. Greg L (talk) 18:28, 18 August 2009 (UTC)

  • My position is that using thin spaces to both the left and right of the decimal when an article contains one or more numbers with 5 digits to the right of the decimal is preferable to Wikipedia making up its own format. It also my position that the practice of using thin spaces to the right and commas to the left looks especially asinine in the case of a number like 4,046.8564224. I will not change my position unless a reputable external source, such as a major style guide, which supports the 4,046.8564224 format, is cited. --Jc3s5h (talk) 21:22, 18 August 2009 (UTC)
  • That’s perfectly fine, Jc3s5h. Don’t write it that way then. A number like 4046.8564224 is rare anyway. With that much precision, such numbers will often be in scientific articles where scientific notation might be more appropriate. Amongst all the above-cited discussions in the archives, there was another editor who felt as you do. We go with the consensus here on Wikipedia and the approval of {val} was (very) lopsided. The guideline advising editors that numbers like 1.6162523625 × 10−35 meters are hard to parse and they should consider using 1.6162523625×10−35 m is a sound one because it makes Wikipedia easier to read and understand. Greg L (talk) 21:44, 18 August 2009 (UTC)
    • Thank you; as long as this is phrased so as to be clear that the answer to "I don't like 4,046.8564224" is "Don't use it then", not "MOS breach! MOS breach! shun this start-class article", a recommendation backed by a lopsided majority should be fine, and harmless. The present use of may be seems to achieve that, but I would value Jc3s5h's opinion. Septentrionalis PMAnderson 00:09, 19 August 2009 (UTC)

(unindent) When Pmanderson asks whether the present use of may be, I surmise he is asking about this section:

  • Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important, may be separated (delimited) into groups using the {{val}} template, which uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g. {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should delimit high-precision values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|45}} → 1.2345678901234567.

Let us set aside my objection to the 4046.8564224 format for the moment; whether my interpretation or Greg L's interpretation of consensus prevails will become apparent in due course. The present version of the guideline states, or at least strongly implies, that the Val template conforms to "ISO convention (observed by the NIST and the BIPM)", but the template at present does not conform to the ISO convention. Furthermore, every example in this section has exactly one digit to the left of the decimal, so the non-conformance is concealed.

This is a falsehood. I don't think it has been pointed out until now, so it is an innocent falsehood. But over time, as the falsehood becomes better understood among editors of this guideline, it could ripen into a lie. --Jc3s5h (talk) 00:28, 19 August 2009 (UTC)

If there is a question of fact (assertions of fact are generally undesirable on guideline pages, because it provokes exactly this sort of discussion), would both of you provide citations? Septentrionalis PMAnderson 00:34, 19 August 2009 (UTC)
  • In response to Pmanderson's request for a citation, the BIPM brochure setting for the International System of Units states "for numbers with many digits the digits may be divided into groups of three by a thin space, in order to facilitate reading. Neither dots nor commas are inserted in the spaces between groups of three."
As for proposing a text supporting the use of {{val}}, I don't support that template at all until it is modified to not allow commas and thin spaces in the same number. (I have no objection to a version that provides a parameter to choose between the BIPM format and the customary American format.) --Jc3s5h (talk) 00:50, 19 August 2009 (UTC)
I see that citation does address how to handle 4 digits (make a single group of 4); but one issue between you is how to handle 8 digits. {{Val}} divides them IIUC 3, 3, and 2; what would you do, and can you cite it as ISO? Septentrionalis PMAnderson 01:14, 19 August 2009 (UTC)
Septentrionalis, I suspect you are missing the point. Looking at 8 digit numbers, 1234.678 is fine. The format 12345678 is fine if the article does not contain any numbers with 5 or more digits to the right of the decimal. The formats 12345678 and 0.12345768 should not appear in the same article. The formats 12345678 and 0.12345768 in the same article are fine. --Jc3s5h (talk) 01:29, 19 August 2009 (UTC)
Let me get this straight. Either commas or gaps, not both. That still leaves several possibilities to object to. Do you object to
  • The use of gaps and commas in the same article?
  • The use of gaps and spaces in the same number?
  • The claim that (which of the above?) is ISO?
  • All three?
Are you willing to let Greg use his preferred format, if you can use yours? Septentrionalis PMAnderson 01:41, 19 August 2009 (UTC)
My two cents: there's no problem if the lead of LHC reads "over 10,000 scientists and engineers" and a paragraph deep down inside it says, "At this energy the protons have a Lorentz factor of about 7500 and move at about 99.9999991% of the speed of light." They are different contexts: the former is something even my grandmother could read (if he spoke English), the latter is an advanced technical detail. But I'd prefer avoiding both styles in the same contexts: after all, contexts in which you want to use the traditional American style not to confuse American readers are very, very, very unlikely to contain any number with a large number of digits after the decimal point. (Personally, when I see a number with more than three significant figures I ask myself where the hell the last ones were taken from, and if I can find no answer, that confuses me much more than an unfamiliar format would.) These generally occur in scientific and engineering contexts, where using thinspaces is OK. Of course, these are generalizations and exceptions may occur. --___A. di M. 02:16, 19 August 2009 (UTC)
In response to the items questioned by Septentrionalis,
  • The use of gaps and commas in the same article? Object Neutral.
  • The use of gaps and spaces in the same number? Strongly Object
  • The claim that (which of the above?) is ISO? The claim that {{Val}} conforms to ISO/BIPM/NIST format is not compatible with the use of the comma as a separator at all. This wording will have to change if {{Val}} is capable of using commas as a separator.
I do not support the use of made-up formats when an acceptable format is already in use in non-Wikipedia publications. Gaps and spaces in the same number is certainly a made-up format. Mixing numbers with commas and numbers with spaces in the same article is, in my view, also a made-up format, but I suppose others could argue to the contrary. --Jc3s5h (talk) 02:09, 19 August 2009 (UTC)
Greg? The third bullet point above is a call for citation; please give one. I cannot help with this otherwise without proposing a compromise text, and I do not see one. If one of you bends to the breaking point, the other may see the result as marginally acceptable. Septentrionalis PMAnderson 02:14, 19 August 2009 (UTC)
  • Quoting Jc3s5h: The present version of the guideline states, or at least strongly implies, that the Val template conforms to "ISO convention (observed by the NIST and the BIPM)". Fact: It does (and says) no such thing. Read the text. It says as follows:

Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits.

It’s 1.2345678, not 1.2345678. That’s what it says. That’s all it says.
Following the logic of Jc3s5h, if there are any numbers in an article that have the right hand side delimited (for clarity of parsing), then that gives him carte blanche freedom to use spaces to the left of the decimal point. Perhaps. But only if the article is on a scientific subject. There is no reason for this majorly-conflicted dilemma. It seems Jc3s5h rather wants to expand the Euro-style way of delimiting and is exploiting the existence of {val} to push this view. That would be a mistake if it’s the case. But, if it’s just a matter of WP:IDON'TLIKEIT, then don’t use it, because many others do like it.
Count the number of readers who are confused by the use of {val} on Kilogram. Zero. Zip. Count the number of readers who would be unnecessarily confused if we expanded the use of comma delimiting outside of the realm that it is currently limited to (science). How many American readers are going to be baffled if we started delimiting with thinspaces to the left of the decimal marker?? A metric butt load; that’s how many. It would be foolhardy to contemplate any such change. Like A. di M. wrote, above, …there's no problem if the lead of LHC reads "over 10,000 scientists and engineers" and a paragraph deep down inside it says, "At this energy the protons have a Lorentz factor of about 7500 and move at about 99.9999991% of the speed of light." Even his grandmother wouldn’t be confused.
And, Jc3s5h, don’t bother quoting how the BIPM says numbers ought to be delimited to the left of the decimal marker in documents for a world-wide audience. That isn’t the first advise from the BIPM that Wikipedia (and the rest of the world ignores) and it won’t be the last. Notably—perhaps very unfortunately—America ignores that advise. Perhaps you find that to be an unfortunate shame. I might agree with you. Perhaps you think we will Make the world a better place by leading by example.®™© No. That is not what Wikipedia can or should do. This flouting of standards applies to the IEC and many other standards bodies: sometimes proposals fly like a wet noodle. However, the good ones that solve a problem rapidly gain traction in the world. And when the rest of the world changes, Wikipedia will follow suit. Note also, en.Wikipedia is not intended to be read by all cultures throughout the world; just English-speaking ones (either first or second language). As I’ve patiently explained above, the rest of the English-speaking world “gets” the American-style way of delimting. However, Americans don’t “get” other ways of delimiting. Not… in… the… slightest. That’s why en.Wikipedia has adopted the comma to the left. Please accept that and stop seizing on {val} as a reason why thinspaces ought to be expanded. Greg L (talk) 03:07, 19 August 2009 (UTC)
  • The idea behind Wikipedia allowing the BIPM method of delimiting in its science-related articles was borne out of the fact that professional, peer-reviewed articles in science are typically written that way, as required by the manuals of style of the respective journals. They have an international audience and the journals try to make the papers as easy to digest for an extraordinarily wide, professional audience. The “science” exception has often been used as a window of opportunity to be exploited by some Wikipedians in an effort to expand the practice into just about anything (“well… water is a ‘sciency’ subject.”).

    IMHO, the objective on Wikipedia should always, always be about writing in a way that is clearest and causes the least confusion. There are many distasteful practices that come with that philosophy, including using feet and inches and pounds in American-related articles like Boston Red Sox. Too often, editors want to do things a certain way because… well… editors simply like doing it that way and always have done it that way. It ends up being more about writing to please the Wikipedian rather than do what is best for the readership. Greg L (talk) 04:35, 19 August 2009 (UTC)

A break after the boxed sentence puts ISO and {{val}} into different and shorter paragraphs; that should remove any implication of connection where none is intended. Septentrionalis PMAnderson 00:59, 21 August 2009 (UTC)
I was trying to think of something that would remove (or at least greatly reduce) the implication without being too bulky. This is an elegant change. --Jc3s5h (talk) 01:05, 21 August 2009 (UTC)

Proposal

To resolve the issue I offer a two part proposal:

Part 1: {{Val}} is altered so that by default, it produces commas to the left and no separation to the right of the decimal point (customary American style). A parameter is added, BIPM=y or yes which produces thin space separators on both sides of the decimal point.

Part 2: The "Delimiting (groups of digits)" be altered to read as follows:

  • Numbers with five or more digits to the left of the decimal point; i.e. 10,000 or more, should be delimited (separated into groups so they can be easily parsed visually) using commas every three digits; e.g. 12,200 and 255,200 and 8,274,527 etc. Exception: articles containing numbers with five or more digits to the right of the decimal point, e.g. 3.141593 (as such articles should delimit numbers as for scientific articles—described below).
  • Numbers with four digits to the left of the decimal point may be delimited with a comma; that is, there were 1250 head of cattle and there were 1,250 head of cattle are both acceptable. The same exception as for five digits to the left of the decimal point applies.
  • Numbers are not delimited when they are part of mailing and shipping addresses, page numbers, and years with four or fewer digits. Years with five or more digits (e.g. 10,400 BC) shall use commas.
  • In scientific articles, particularly those directed to an expert readership, numbers may be delimited with thin spaces using the {{gaps}} template. Coding {{gaps|8|274|527}} produces 8274527 (note: the thin space character and its HTML entity, &thinsp;, do not render correctly on some browsers). Articles containing numbers with five or more digits to the left of the decimal point should delimit numbers with thin spaces.
  • The style of delimiting numbers should be consistent throughout an article.
  • Mathematical constants in math-oriented articles may be grouped into groups of five; e.g. 3.141592653589793238462643383279....
  • Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important, may be separated (delimited) into groups using the {{val}} template, with the BIPM parameter set to "y" or "yes"; {{val}} uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g. {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should delimit high-precision values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|45}} → 1.2345678901234567. Also note that when the BIPM parameter is omitted, {{val}} does not conform to the ISO/NIST/BIPM format; instead it uses the customary American format of grouping digits to the left of the decimal with commas, and not grouping digits to the right of the decimal.

--Jc3s5h (talk) 03:01, 19 August 2009 (UTC)

  • As I said above, there is well established reason why en.Wikipedia uses commas to delimit numbers to the left of the decimal point: it results in the least confusion in our readership. Please stop using {val} as an excuse to advocate that we diverge from this well-entrenched principle. If you don’t like {val}, don’t use it. It solves a legitimate problem when you have really long, hard-to-parse strings of numbers to the right of the decimal point. It is not a vehicle to be used to try to use Wikipedia to enlighten Americans to the One True Way that numbers really ought to be delimited. Greg L (talk) 03:12, 19 August 2009 (UTC)
  • I reject the claim, unsupported by any scientific survey or by adoption by any external publication, that commas to the left of the decimal point and thin spaces to the right are less confusing than a format that uses the grouping method, thin spaces, on both sides of the decimal. --Jc3s5h (talk) 03:17, 19 August 2009 (UTC)
  • Well, you clearly aren’t familiar with America, are you? How many methods of delimiting numbers do you think American school children are taught? Just one. In Sweden, they teach elementary kids three different techniques, including the American method. You are certainly free to choose to believe what you want to believe. Greg L (talk) 03:23, 19 August 2009 (UTC)

    P.S. I’ve been to England, Scotland, Wales, Ireland, Antigua, Moroco, Spain, Monaco, France, Italy, Austria, and Hungary—and Canada, if you can count that as not being part of the U.S. ;-). Notwithstanding that I am American, I do all my engineering in hard metric. Have you been to the U.S.A? If so, how long? Because, as an engineer, I can assure you I have keen insight into what causes confusion in Americans. The current practices of Wikipedia were no accident. Greg L (talk) 03:42, 19 August 2009 (UTC)

  • I have found that the current edition of the U.S. Government Printing Office Style Manual, in rules 12.9e and 12.14, calls for the use of commas to the left of the decimal and thin spaces to the right. (Although the manual does not say "thin spaces", the spaces in their example look thin to me.) Therefore I withdraw my contention that this is a made-up format. This manual does not address the question of what to do when one number has 5 or more digits to the left of the decimal, and also 5 or more digits to the right of the decimal. In most cases this could be handled by putting the number in scientific notation. --Jc3s5h (talk) 04:31, 19 August 2009 (UTC)
  • Jeez! I didn’t know that. That was big of you. You did the homework and declared an “inconvenient truth” that I didn’t even know about. Damned big of you; I’ll remember that. Like the guideline says, editors may use {val}. If you think it is important for readers to be able to easily parse the digits to the right of the decimal point in a particular value, and if scientific notation doesn’t seem suitable for some reason, then use {val}. Otherwise, don’t. Cheers. I’m done for the evening. Greg L (talk) 04:43, 19 August 2009 (UTC)
  • I think that the proposed changes to {{val}} would be straightforward and reasonable.

    As for the proposal, it's on the right track—but let me raise some issues. I think the current text is a bit cumbersome, in that it has a lot of exceptions and places where the text diverges into subcases. I think we can state the exceptions a little more clearly, and make them general in application.

    There's also the question of whether to treat the U.S. and BIPM delimiting schemes as similarly-acceptable, or not. I don't buy the idea that Americans don't understand the BIPM format—any literate English speaker ought to be able to figure out the meaning of either the U.S. customary or BIPM formats (or for that matter the meaning of an undelimited number), with minimal effort. (And for subsequent occurances, zero effort.) It's not a significant issue of understanding at all—it is straightforwardly stylistic. And given that an English-speaking Canadian or European would probably default to the BIPM format, and would certainly understand it, it's not appropriate to direct those users to use an unfamiliar method despite the conventions of English-language style that are typically employed in their regions. (It's the same can of worms as telling them to spell it color instead of colour, or vice versa.)

    It also follows that there needs to be an exception for special regional contexts that would be unintelligible to the majority of English speakers, but which are still in widespread use. (This particular exception could use further discussion, and might be relevant in so few cases as to be omitted, but I'll suggest something below anyway.) For example: English is a second language of hundreds of millions of Indians, Pakistanis and Bangladeshis, and they often use the Indian numbering system when communicating in English. For articles specifically about an Indian topic, if we're to be faithful to the idea of avoiding regional bias, we have to acknowledge that their method is widespread enough to consider in the MOS.

    There's also the matter of splitting the technical details out into their own subsection. I think things were getting a bit convoluted with the mixing of implementation details with stylistic concerns, so I think that we should separate them from the main text.

    So with that in mind, I've spliced portions of the various versions of this section (by Greg L, Jc3s5h and myself) together, and come up with this:

===Digit grouping===

  • In numbers with many digits, digit grouping symbols (inserted at intervals from the decimal point) are used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
    • Commas every three digits to the left of the decimal point, and thin, non-breaking spaces every three digits to the right of the decimal point (e.g. 8,274,527 or 0.12345). This is traditional usage in many English-language contexts, and recommended by the U.S. Government Printing Office.
    • Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides for scientific and engineering works, and is in common use in interlanguage contexts.
    • Mathematical constants in math-oriented articles may be grouped into groups of five digits on both sides of the decimal point; e.g. 3.141592653589793238462643383279....
    • Other traditional digit grouping schemes, when relevant to the subject matter of the article; e.g. 82,74,527 in the Indian numbering system. (An explanation of the digit grouping scheme should be provided, typically by way of a link or brief summary. Also or instead, parenthetical conversions to another acceptable scheme may be used.)
  • The style of grouping digits within numbers should be consistent throughout an article.
  • When grouping digits by threes, and a number has exactly four digits on any side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable.
  • Digits are not grouped when they are part of addresses, page numbers, and years with four or fewer digits. However, years with five or more digits (e.g. 10,400 BC) are delimited as any other large number.

====Technical implementation====

The {{gaps}} template uses CSS to output thin spaces (using the syntax {{gaps|8|274|527}}). Using HTML entities for this purpose (e.g. &thinsp; or &#8239;) may cause rendering problems in some browsers, and should be avoided when practical.

The {{val}} template handles digit grouping automatically, in the American style (by default) or in the BIPM style (by using the BIPM=y parameter). In both cases, CSS is used to output the thin spaces. For example, {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should manually delimit values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|45}} → 1.2345678901234567.

TheFeds 07:08, 19 August 2009 (UTC)
Good, except for a few points:
  • To address Greg's concerns about the "BIPM" system, you might consider to add something like In some major English-speaking countries, this format is unfamiliar most persons without advanced scientific or engineering education, so avoid using it in general-interest topics.
  • I'd replace "throughout an article" with "within a context": as I said above, the lead of LHC is a general-interest topic (as it made major appearances in the media last year), and so you'd want to use the "American" style; the sections about technical details are advanced scientific topics, and so you'd want to use the "BIPM" style. (Probably a better example than that could be found.) BTW, in the former type of contexts you'd seldom use numbers with more than three or four significant figures anyway (if you do, you're likely to be breaching the second bullet in "Large numbers"), so issues of long strings of digits won't occur; and laymen are unlikely to want to read stuff in the latter type of contexts.
  • Don't see the point of making {{val}} use the "American" style by default. It is a template with facilities for scientific quantities and it is far more likely to be used for the mass or magnetic moment of the electron than for the population or GDP of the US: the latter type of numbers are normally hard-coded in articles without using templates. (BTW, look at the last example. I'm going to fix it in the actual MoS text where it's also found, but I don't generally edit other people's comments.) --___A. di M. 12:24, 19 August 2009 (UTC)
I hadn't read that the "American" style does include spaces after the point. Given that, the "long string of digits" issue is moot, so the grounds for replacing "throughout an article" with "within a context" are weaker than I believed: 99.9999991% conforms to the "American" style, too. --___A. di M. 15:07, 19 August 2009 (UTC)


(unindent) As one of the guys who take care of the {{val}} template, the sensible solution as far as the template is concerned is to leave the default behavior of {{val}} as-is, because otherwise you will screw up a million articles and remove the ease of using {{val}} in >90% of cases. Then for all those who hate gaps, or hate commas, two parameters can be added, |gaps=no (producing 1,232,345.0023234) and |commas=no (producing 1232345.0023234). You can then write exactly what you want, and you'll have the choice of picking whichever format is best suited for the article.Headbomb {ταλκκοντριβς – WP Physics} 15:18, 19 August 2009 (UTC)

"Scientific articles; particularly ones directed to a professional readership, are the only exception."
  • ... plus mathematical articles, articles about technology (computing, etc.), articles about measurement, etc.
I have to say that I've never really been a fan of the commas+gaps hybrid formatting that val uses. I'd rather have either gaps+gaps or commas+nogaps consistently throughout the article perhaps with a few exceptions based on context as mentioned above.
Rather than having the default behaviour of {{val}} produce 1,232,345.0023234, I'd have it produce 1232345.0023234 but that's my preference & would probably not be what many would consider appropriate in many cases.
However, I'd be happy with the suggestion by Headbomb. Between three and four thousand pages use the template, many maths/science/technology related, many not. It wouldn't be impossible to send a bot round adding |gaps=no and |commas=no where appropriate.
On the other hand, instead of a hybrid format that happens to turn out perfectly acceptable in 90 or so percent of cases (i.e. not too many numbers on WP are both greater than a thousand and have more than four digits after the decimal point), we might consider a hybrid default. For example, the template could produce gaps+gaps if there are more than four digits after a decimal point and commas+nogaps otherwise. That shouldn't screw up a million articles and it might even make the template a fraction easier to use. JIMp talk·cont 20:49, 19 August 2009 (UTC)
  • That’s what {gaps} is for. Nothing is broken. This “dump on {val}” thing was just a vehicle to promote the point of view of an editor who wants to use gaps left and right—perhaps even outside the strict field of science. Now I see “engineering” being proposed to add into the mix, which is most unwise and unnecessary. And Jimp just described it as “maths/science/technology”—almost like “smart-like articles.” We often get that on Wikipedia—encroachment because it makes editors happy because they can edit in a fashion they are accustomed to in their country; the practice seems truly “right” in some way to them. That’s fine with dialect/spelling. It is a can of worms with numbers for the reasons I’ve stated above and unnecessarily creates confusion in our readership. The exception of using thinspaces to the left of the decimal marker is currently limited to “science” and needs to stay that way for good reason. Greg L (talk) 20:58, 19 August 2009 (UTC)
That's what I use {{gaps}} for but I'd rather use {{val}}. I'm not trying to water things down to "smart-like articles". Perhaps gaps is not appropriate for technology articles, I'm sure its not appropriate for all of them, it may be appropriate for some. I'm just suggesting that the scope is broader than just science articles. Here's a maths article using spaces both sides. It looks fine to me. JIMp talk·cont 21:18, 19 August 2009 (UTC)
  • IMO, that math article ought to be conforming to the general rule of using commas to the left. Fortunately, it is an obscure enough of an article (only 700 hits per day). Was there ever a manual of style on Wikipedia saying that that math articles ought to to be delimiting numbers to the left of the decimal marker with gaps or did that article just happen that way? Just because there are math articles that have been done this way does not mean it is a wise idea. I can point to articles that have countless quantities of ending sentences with a preposition; that doesn’t mean we need to change WP:MOS. Greg L (talk) 21:30, 19 August 2009 (UTC)
Actually that article is itself inconsistent, using sometimes commas and sometimes spaces. I'm going to fix it to all-commas before and all-spaces after, as I think it was intended for a lay readership. (I don't think they'll ever appear in the same number or even section, given the structure of the article.) --___A. di M. 18:11, 20 August 2009 (UTC)
Please change it to all gaps, which seems to predominate; that works better to my eye. Septentrionalis PMAnderson 18:30, 20 August 2009 (UTC)
To me it seems that the powers of ten immediately below the section headers mostly have spaces, but the actual examples mostly have commas. --___A. di M. 18:52, 20 August 2009 (UTC)
It looks to me like that double rule is exactly true, except for the scientific notation and one glitch at 1 000, which I fixed. Let's leave it alone -unless there are other glitches. The gaps in the headers are what is useful. Septentrionalis PMAnderson 19:24, 20 August 2009 (UTC)
It used normal space characters, which are too wide (at least with my font and in my eye), and it had a couple numbers with spaces within the actual lists, which I fixed until the 10^39 section. But there's another issue: the last sections have gargantuan exact integers, currently delimited with normal spaces. Using commas or {{gaps}} would blow up the line width, forcing horizontal scrollbars on any window of any reasonable width. --___A. di M. 10:48, 21 August 2009 (UTC)

I'll go along with TheFeds proposal, once one technical issue is ironed out. This bullet:

  • When grouping digits by threes, and a number has exactly four digits on any side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable

is not compatible with the example 1.1234567 because the example has exactly seven digits to the right of the decimal, not four.

Also, the style implemented by {{Val}} should really be called the GPO (Government Printing Office) style, because the prevalent American style is to not group digits to the right of the decimal point. (The Chicago Manual of Style is one publicaton that advocates no separation to the right of the decimal outside the realm of science and technology). --Jc3s5h (talk) 22:36, 20 August 2009 (UTC)

  • And the Chicago Manual of Style probably gives the same guidance as the Associated Press’ Manual of Style; both wouldn’t delimit to the right for non-technical articles directed to a general-interest readership, now, would they? The {{val}} template probably isn’t a good fit for an article on Wham‑O’s Super Ball: Super Balls have amazing rebound kids! Yet it has a specific gravity of only 1.25864(16) g/ml (which is how much a fifth of a teaspoon of a Super Ball weighs). High-precision values will most frequently be found in technical articles, won’t they? The only noticeable legitimate exception that comes to my mind at the moment is high-precision numbers intended to impress, such as French scientists in 1799 measured the density of water to within 99.997495% of the currently accepted value. Wow!

    The current guideline reads, in part, as follows:

The whole section seems clear enough to me—even for editors who are disinclined to bring much common sense to the party. It reflects what we ought to be doing in order to communicate without confusion, and, after A. di M. got through with it, seems to be capturing the all the known exceptions to the general rule. Greg L (talk) 03:57, 21 August 2009 (UTC)
  • Regarding the groups of four issue, recall that stemmed from an unclear recommendation from the BIPM manual. They said groups of four were the exception, but didn't explicitly provide for a group of four followed or preceded by a group of three on the same side of the decimal separator. (But gave examples in-text that seemed to support that style.) I don't think it's a huge deal, so I'd be fine with a revised version of that sentence. Do you want to suggest the wording? It would be good to consider whether a case like 9876543 is permissible or too ugly to let stand—contrast that with 9876543 (which is grouped 1/3/3 instead of 4/3). TheFeds 03:34, 21 August 2009 (UTC)
  • Are we having a “consensus of two”-thing going here again? This issue of number delimiting, as I wrote (abundantly) above, was thoroughly discussed by a very wide group of participants. Moreover, A. di M. and I got deep into the ISO and BIPM recommendations and sorted out—and documented—why things are being done that way. The current MOSNUM guidelines reflect proper practice and there is no good reason to diverge from the practice, notwithstanding your musings as to what sorts of alternative delimiting strikes you as “too ugly to let stand.” Greg L (talk) 03:59, 21 August 2009 (UTC)
    The problem with what BIPM say w.r.t. numbers with seven digit after the point is that it differs from what it does. They say that you should use 0.1234567, but their examples use 0.1234567. As for ISO, their standards aren't available for free; a 2008 draft of ISO 80000-1 I found somewhere on the Web explicitly forbids 0.1234567 in favour of either 0.1234567 or no delimiting at all, but judging at this I think it hasn't been accepted. So we'd better ditch the question of what they say and think about what is better. The IUPAP Red Book clearly says "Instead of a single final digit, the last four digits may be grouped." (But above it has unclear wording which doesn't seem to allow delimitation with four digits as in 1987 or 0.1234.) In actual usage, 0.1234567 seems to be more common than 0.1234567 (even because it's not clear how you'd use the latter with two digits uncertainty as in 0.1234567(89)). So I'd keep the convention as it is, but I wouldn't call it "ISO convention" unless someone has access to ISO 31-0 and can confirm that they say that, and is willing to buy ISO 80000-1 when it's officially published to check if it continues saying that. Let's just drop "According to ISO convention (observed by the NIST and the BIPM)"; most people won't even actually care. Also, is "to within 99.997495%" supposed to mean "to within 0.002505%"? BTW, you could impress the reader by writing "99.9975%" or "0.0025%" as well, and neither would have more than five digits after the point. --___A. di M. 10:20, 21 August 2009 (UTC)
    BTW, I'd support this:

A. di M.'s proposal

===Digit grouping===

  • In numbers with many digits, digit grouping symbols (inserted at intervals from the decimal point) are used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
    • Commas every three digits to the left ofbefore the decimal point, and thin, non-breaking spaces every three digitsno delimiting to the right ofafter the decimal point (e.g. 8,274,527 or 0.123450.12345). This is traditional usage in many English-language contexts, and recommended by the U.S. Government Printing OfficeThe Chicago Manual of Style and the AP Stylebook for non-technical articles.
    • As above, but with thin, non-breaking spaces every three digits after the point (0.12345). This is recommended by by the United States Government Printing Office.
      • Usually there is no difference between the two styles above, because non-technical articles should avoid using excessively precise values: see the second point in {{Section link}}: required section parameter(s) missing, below.
    • Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides for scientific and engineering works, and is in common use inand is in common use in scientific and engineering works and interlanguage contexts.
      • In some major English-speaking countries, this format is unfamiliar most persons without advanced scientific or engineering education, so avoid using it when discussing general-interest topics.
    • Mathematical constants in mathematics-oriented articles may be grouped into groups of five digits on both sides of the decimal point; e.g. 3.141592653589793238462643383279....
    • Other traditional digit grouping schemes, when relevant to the subject matter of the article; e.g. 82,74,527 in the Indian numbering system. (An explanation of the digit grouping scheme should be provided, typically by way of a link or brief summary. Also or instead, parenthetical conversions to another acceptable scheme may be used.)
  • The style of grouping digits within numbers should be consistent throughout an article.
  • When grouping digits by threes, and a number has exactly four digits on anyeither side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable. Additionally, after the decimal point a final group of four digits can be grouped together, e.g. 0.1234567 or 0.1234567. The latter style is more common, and is recommended on Wikipedia.
  • Digits are not grouped when they are part of addresses, page numbers, and years with four or fewer digits. However, years with five or more digits (e.g. 10,400 BC10,000 BC) are delimited as any other large number.

====Technical implementation====

The {{gaps}} template uses CSS to output thin spaces (using the syntax {{gaps|8|274|527}}). Using the thin space character or its HTML entities for this purpose (e.g. &thinsp; or &#8239;) may cause rendering problems in some browsers, and should be avoided when practical.

The {{val}} template handles digit grouping automatically, in the American style (by default) or in the BIPM style (by using the BIPM=y parameter)in the U.S. GPO style automatically. In both cases, CSS is used to output the thin spaces. For example, {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should manually delimit values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|456}} → 1.234567890123456.

Differences from TheFeds' version are marked. --___A. di M. 11:15, 21 August 2009 (UTC)

"This format is suggested in BIPM and NIST style guides for scientific and engineering works" misrepresents the position expressed in the BIPM brochure (and the NIST brochure is, with minor variations, just a translation). The brochure states on page 133

The practice of grouping digits in this way is a matter of choice; it is not always followed in certain specialized applications such as engineering drawings, financial statements, and scripts to be read by a computer.

So as far as NIST and BIPM are concerned, the thin space format should be used for everything except "certain specialized applications". --Jc3s5h (talk) 12:16, 21 August 2009 (UTC)
Amended to reflect this. --___A. di M. 12:24, 21 August 2009 (UTC)


  • A. di M., thank you for stepping in here. Please insert, somewhere in your suggestion, something along the lines of this: “In technical articles such as engineering and science, where distinctions in the magnitude of numeric expressions are important, editors should consider using the {{Val}} template to delimit numbers that have many digits to the right of the decimal point in order to make them easier to parse.” Greg L (talk) 19:21, 21 August 2009 (UTC)
  • I strenuously object to the clear objective of the proposed verbiage that reads

Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides and is in common use in scientific and engineering works and interlanguage contexts.

The current wording, (“scientific articles, particularly those directed to an expert audience”) is the proper limit. The clear objective with that proposed wording is to expand the “Europeanizing” of Wikipedia’s numbering into anything remotely ‘technical’ in nature. Unlike dialect (spelling), delimiting with gaps to the left of the decimal point is far too confusing to American readers who are not taught any other methods of number delimiting. Conversely , the typical Swedish school child is taught three different ways to format numbers and are not in the least bit confused when they come across numbers with the American-style of delimiting.

I’ve made this point numerous times, above, and the best counter-argument I’ve yet to see is a demand to see scientific proof or studies showing that alternative numbering formats would be confusing to Americans. Commons sense does not need to be legislated. This is hopeless. This is simply nothing more than an attempt by some Europeans, who are absolutely convinced that their BIPM-endorsed, European way is superior (perhaps it is) and should be adopted here on Wikipedia and dumb ol’ Americans will learn it here, if nowhere else. These editors need to drop this agenda to change what has long worked here. Wikipedia is not to be exploited as a vehicle to promote change by educating Americans to conventions with which they are entirely unfamiliar. The current guidelines are fine.

And, a final note: Just because something is endorsed by the BIPM doesn’t mean it enjoys world-wide adoption. The BIPM wants 75% written 75 %, but Americans (and as far as I know, no one else) don’t do it that way so Wikipedia goes with the flow and ignores the BIPM so we don’t confuse people for God’s sake. Greg L (talk) 23:35, 21 August 2009 (UTC)

I have to say, having read this thread I am not at all persuaded by the BIPM-rules-all feeling that's about. What is being proposed here seems controversial and is unlikely to gain broad consensus. I see no reason to change the current guidelines, which have long been on MOSNUM and have served us well. Tony (talk) 00:12, 22 August 2009 (UTC)

As someone who has lived in France for many years, I am familiar with that convention. It appeared bizarre to me when I first arrived there. Now it is pointed out that this is also adopted in some scientific contexts. Before this is imposed on the unwitting WP public, I would point out that it is a convention I have never seen before in the Anglo-Saxon world. Being able to understand it is one thing, but to insist that this professional technical standard be adopted in any form in a general knowledge encyclopaedia is quite another. - BTW, the French also use the comma in place of the period as the decimal delimiter. Even if we were not to adopt this last 'quirk', it is unlikely to find widespread acceptance. Implementation is likely to meet with bewilderment, and be universally reverted to the comma delimiter which all English-speakers are familiar with. Ohconfucius (talk) 06:37, 22 August 2009 (UTC)

  • Regarding Greg's oft-repeated assertion that Americans would be confused by the BIPM style, let me also reiterate my feelings. I don't believe that someone with a working comprehension of written English would be so hopelessly confused by that format as to fail to comprehend the meaning after a short pause to think about it. To me, the worst reasonable case is that someone will assume that a previous editor neglected the commas.

    To consider an analgous case, an American reading about a boot and a bonnet might picture articles of clothing, rather than car parts—yet we would not expect articles to generally defer to the American's preferred vocabulary, even though Britons are somewhat accustomed to American vocabulary (e.g. because of the pervasiveness of American culture and media in Britain, vs. the opposite), and would grudgingly understand "trunk" or "hood" in the context of an automobile. In fact, with numbers, at least there's a contextual clue to the meaning—the numerals are the same, after all. With "boot" vs. "trunk", we have to resort to things like linking the first occurrance, to avoid misunderstandings; the case of dialect is more, not less confusing than numbering style. Yet despite that slight inconvenience, the well-established principle is to accept such regional eccentricities as part of the language, and accomodate them in the interest of avoiding the imposition of one region's style over another. Just because the Swedes often understand either format—to recall Greg's example—does not mean that their preference ought to be be moot.

    And let me just point out that I was not the one who demanded a study or scientific proof of the alleged incapacity of Americans to use other formats—I simply expressed my doubt. My common sense appraisal doesn't agree with Greg's, and I suspect that when it's nothing but assertions of common sense on either side, there's nothing in particular to refute. (And of course, repeating something doesn't make it true; neither argument is any stronger upon retelling.)

    I've also got to take issue with the idea that Europeanization is the motive. ("This is simply nothing more than an attempt by some Europeans, who are absolutely convinced that their BIPM-endorsed, European way is superior (perhaps it is) and should be adopted here on Wikipedia and dumb ol’ Americans will learn it here, if nowhere else.") I doubt that it was an intentional strawman, but for the sake of keeping this discussion on track, let's drop the idea that there's any effort to force-feed Americans with foreign concepts, because there's no evidence that any editors presently commenting on this matter are attempting to engage in any such scheme.

    To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions—not just in science or engineering, but in any English-language usage. That's the way things tend to work in Continental Europe (and maybe that's why this "Europeanization" allegation arose), where several states and languages have their own incompatible digit grouping schemes, and where English is the de facto language of international commerce and collaboration. There is no ulterior motive: it's simply an acknowledgment of European English style. Consider the European Commission English Style Guide, which calls for BIPM-style digit grouping. That guide is "intended primarily for English-language authors and translators" and "serve[s] a wider readership as well" (speaking in terms of the EC and of EU institutions)

    The fact that things like scientific journals and engineering handbooks have also adopted the BIPM convention is a secondary component of the issue—when we say "in common use in scientific and engineering works", that's just an acknowledgment that scientific usage of this convention is worldwide, versus the regional adoption of the convention for general use. If we wanted to capture that reasoning in detail, we could say that BIPM style is limited to topics in the fields of science and engineering, plus topics dealing with Continental Europe and other regions that enjoy significant adoption of that style.

    But what's the point of being needlessly precise? It's much simpler to acknowledge that both the U.S. and the BIPM convention are in general use in large regions of the world, and each preferred by major fields of study (as evidenced by style manuals). On balance, the MOS is clearer by just allowing either one (though calling for consistency within an article), without complicating the issue with topic-related stipulations (and the consequent discussion of what belongs to which topic, or what dominates in which region). This is easier to understand, and easier to enforce—that's a useful thing, given the level of complexity of the MOS and Wikipedia policy in general. TheFeds 19:46, 22 August 2009 (UTC)

  • Quoting you, TheFeds: I don't believe that someone with a working comprehension of written English would be so hopelessly confused by that format as to fail to comprehend the meaning after a short pause to think about it. You might well be right. After a moment of looking at the unfamiliar-looking number, many—perhaps most—Americans would eventually figure it out. So what? Do you think that is the litmus test the Associated Press uses in judging what to put into their manual of style(?): whether readers, who are initially confused by the written word, will for the most part eventually figure it out??? The point of all technical writing is to write with the least confusion. Your arguments of how the BIPM recommended this ‘n’ that so their recommended method of delimiting numbers has been anointed with holy oil and ought to be adopted here is entirely beside the point.

    Frankly, your arguments that we should follow whatever the BIPM says the world ought to do comes right out of the four-year-old playbook used by proponents of the IEC prefixes (see the B0–B16 archives, above). That whole stink (seventeen entire archives dedicated exclusively to that one fiasco) was because a small handful of editors banded together and decided to start using terms like “256 kibibyte (KiB)” instead of the “256 kilobyte (KB)” used by computer manufacturers and computer magazines throughout the rest of the planet. Then one of those editors ran around and changed hundreds of articles over a period of a few weeks and the group blocked anyone from reverting all those edits, citing “lack of consensus”. That this could have occurred that way, that such stupidity lasted for three years, and that it took three months of bickering to put an end to it speaks volumes to how broken MOSNUM can be at times. And all because it was a proposal by some vaunted standards organization. The end result(?): needles confusion in readers who had the misfortune for three long years to come here and read many of our computer articles. I’m sure there were a number of people read up on computers here on Wikipedia and then went into computer stores where they announced they were looking for a computer with “512 mebibytes of RAM.” They were no-doubt met with blank looks (at best) or snickers.

    Quoting you again: To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions. Yeah, I got that much. I figured that bit out in the first four seconds after seeing what you were trying to do. And, as I’ve explained, it unfortunately isn’t a two-way street. There are many ways the Europeans format numbers. In Sweden, the “Swedish1” technique (there’s yet another) is to write the population of America as “285.865.855” so why don’t we just go ahead and let articles here use that system too(?), right along with the BIPM method (which Swedish school children are also taught)? That’s a rhetorical question, please don’t answer it. The answer is because Swedish school children are also taught to recognize the American-style of delimiting numbers. In fact, Europeans by and large are not in the least bit confused when they encounter numbers with American-style delimiting. The trouble is that American’s know of only one way; they’ve been taught no other. Your argument that Americans’ confusion will be short-lived because *Wikipedia* will just teach them using an “oh… didn’t-cha know?”-fashion (and only the galactically clueless and retarded will be left in the dust) is wholly uncompelling.

    With regard to how numbers are written here on Wikipedia, it doesn’t matter in the least what the proposal is or who proposed it. When the American style of delimiting numbers is no longer the dominant numbering format universally recognized throughout the English-speaking world, and when Americans have as much familiarity with alternative numbering styles (like “Swedish1” and “BIPM”) as Europeans do with the American style, then Wikipedia can change over. Wikipedia follows the way the world works and never, ever tries to promote change in the way the world works by presuming we can somehow lead by example. Wikipedia wisely decided to use American-style delimiting in our numbers so there is minimal confusion. Greg L (talk) 21:50, 22 August 2009 (UTC)

  • With regard to your first point, we're writing with a different set of rules than the AP (to use your example). They are free to insist that their writers use "truck" instead of "lorry", or group digits with commas rather than thin spaces, because they have no mandate to consider the issues summarized in WP:ENGVAR, and choose instead to cater to one region's preferences. Wikipedia is written for an international, English-reading audience. That means that we need to accept that occasionally, a user may encounter a term or convention from elsewhere, and be briefly confused. But this is not a critical flaw, because most readers don't just shut down at that point; they keep reading the sentence or paragraph. And the context generally makes clear what is meant, without loss of information. I submit that if we presented a number all alone in the BIPM format, there might be unacceptable confusion among Americans, but that if it was placed within prose or a table, the context would make the meaning accessible to all.

    Let me stress that there is no implication of "teach[ing] them using an “oh… didn’t-cha know?”-fashion". Readers are free to assume that the formatting was a stylistic error, rather than another valid convention, and be none the wiser. The content of the article still gets across. (In other words, I am absolutely not advocating some sort of patronizing policy that would educate the savages of the world about Europe's genteel ways.)

    My concern here that by mandating a convention that represents the preference of a subset of English speakers, we would imply that other accepted English-language usage is inappropriate. It would be like saying "because the British spelling of words like 'harbour' is recognized throughout the world"—despite the American spelling "harbor"—"this spelling convention is mandatory (unless quoting a source or explaining foreign usage)". Wikipedia has not gone this route, instead permitting either form.

    Regarding your Swedish example, I assume that Swedish-1 and Swedish-2 are used in Swedish-language works? This being the English Wikipedia, one would expect them to use the style that is typically used in their region for writing in English. (Which is most probably the BIPM style.) If the Swedes don't use their native styles when writing in English, then there's no need to deal with them here.

    When you say with certainty that "Wikipedia follows the way the world works and never, ever tries to promote change" by example, I think you're misinterpreting what's going on here. Maybe during the binary prefix debate, some editors advanced the idea of promoting IEC usage to the world. Nobody's said anything of the sort here. Furthermore, we usually follow bits and pieces of what influential parts of the world do, but only because consensus among editors often ends up settling upon that course of action. Sometimes that means following or ignoring a particular standard or widespread convention, but the key is that Wikipedia does what the editors agree upon. It's coincidence rather than design that consensus usually settles upon permitting what's popular in the world.

    Lastly: you're definitely mischaracterizing my motives. I'm not waging some promotional campaign that serves to advance the interests of the BIPM, or Europe, or any other entity. Specifically, despite your assertion above, I have not stated or implied that "we should follow whatever the BIPM says the world ought to do". (I have previously stated that I tend to use the BIPM style in my outside work—which is immaterial to your allegation.) TheFeds 00:18, 23 August 2009 (UTC)

  • Quoting you: I am absolutely not advocating some sort of patronizing policy that would educate the savages of the world about Europe's genteel ways.) {{smiling, very amused emoticon}}. Perhaps you aren’t. But it seems you are mightily crossing your fingers that mixing things up here and allowing editors to use different types of numbering formatting if they feel like it won’t cause needless confusion with our readership. Better cross two fingers.

    I’m an American engineer. I do all my design in hard metric. In fact, only a half hour ago, I was busy calibrating a celsius-only thermostat that I’m going to retrofit into my otherwise-gaugeless, Italian-made Rancilio espresso maker. The boiling point of distilled water was 97.8 °C at that moment (barometric pressure) at my altitude (about three meters above the sewer cover outside my house). I’m also installing a pressure gauge calibrated only in bar. I am as “BIPM” as they come for an American. However, as an engineer who has done far more than his share of technical writing (owners manuals, white papers, etc.), I am fully aware of what Americans know and don’t know technically. I am also keenly aware of how utterly stupid it is to needlessly confuse readers.

    Here’s how to speed America’s adoption of all-things-BIPM (e.g., their SI (metric) system, their numbering system, etcetera): Just run for elected office while promising that if America adopts BIPM into their way of life, they’ll loose weight while they sleep and their taxes will go down due to less government waste. You’ll get into office. Moreover, you’d stay there; all you’d have to do is repeat the promise each election cycle; they’ll buy into your promise each time.

    America is big and homogenous; a drive that would take you clean across the whole of Luxemburg won’t even get you across Harris County, Texas. This is a source of strength and weakness. For one thing, we can drive across Harris County and not require a pocket-full of plug adapters to plug our iPhones into the outlets in the next county (or state for that matter). We could design a big-ass airplane in the late 60s and not get all confused because Californians can’t speak French whereas Oregonians right next door can’t speak German. But this homogeneity also means that Americans would be surprised to get into an elevator on the ground floor and see that they are at floor “0”.

    Indeed, Americans are certainly not as “genteel” and worldly as Europeans (that’s a friend of the guy who owns a tool & die shop I frequent); there’s this big-ass pond that shelters us from being exposed to other languages and other ways of doing things. Therefore, it’s a damned-seldom American indeed who is fluent in two or more languages and easily recognizes two—even three—ways that numbers can be delimited. Europeans “get” “285,564,125” in a nanosecond. The typical American would be needlessly confused by “285564125”. So, you Europeans have a leg up on Americans when it comes to understanding other cultures and practices.

    Please take note of the following three expressions. The first is “A civilized man can convincingly imitate a barbarian, but a barbarian can not convincingly imitate a civilized man.” The second is “Never try to teach a pig to sing; you only waste your time and annoy the pig.” The third is “The goal of all technical writing is communicate with minimal confusion.” What you are proposing handily ignores all three. Greg L (talk) 03:52, 23 August 2009 (UTC)

  • Well, now that Greg and I have said plenty about our respective opinions, are there any comments from interested individuals? Did either of our statements change your opinions about the proposals? (Or did we bore you all with too many words?) TheFeds 03:15, 26 August 2009 (UTC)
…besides Greg L, A. di M., Tony, and Ohconfucius? Anyone else?… Anderson? Bueller? Greg L (talk) 03:48, 26 August 2009 (UTC)
I just want to clarify once again that I have no view on what takes place after the decimal place. However, Greg has demonstrated that trying to get a minority European notation system is just too far from wide acceptance. The use of commas as delimiters is pretty much universal – the comma separator is not only American, it's Canadian, British, Australian, Irish, South African, Singaporean - which should take care of about 95% of the native English-speaking population. As this is English Wikipedia, I think that just about makes the case for not embracing BIPM with even tepid reception. Ohconfucius (talk) 04:13, 26 August 2009 (UTC)
  • Well put and succinct. Thanks, Ohconfucius.

    Those English-speaking Europeans who want to come to en.Wikipedia can, while they learn about the subject matter in our articles and brush up on their English-language skills, also get even more comfortable with the accompanying number delimiting technique whereby native speakers of English (U.K., America, Australia, and aothers) use commas to the left of the decimal point.

    That is all part of the “experience” for many visitors to en.Wikipedia for whom English is their second language: immersing themselves in the culture, including such nuances as idioms. That approach is much more realistic (when in Rome, do as the Romans do) than assuming that Wikipedia can somehow change the way the English-speaking world works.

    While it might be *pretty* to think that we wouldn’t be creating unnecessary confusion in our readership by using a wholly unfamiliar number formatting technique here, such a notion doesn’t seem grounded in reality. Nor is such a confusing change in the least bit necessary.

    TheFeds, I ask you to drop the stick and back away from the horse carcass. This issue has been flogged to death and your persistence is becoming tedious. There is clearly not the remotest chance that a consensus might form for adopting the BIPM method of delimiting numbers for use on en.Wikipedia or expanding its mixed use beyond the confines within which it is currently limited. Far from it; it seems the general consensus is to leave things the way they are. Greg L (talk) 16:13, 26 August 2009 (UTC)

  • My persistence is becoming tedious? Aren't you the one responsible for 53 of the last hundred edits to this talk page?

    Also, despite prior implementation and positive discussion of a similarly-worded edit to the MOS, you reverted it, and prompted this discussion in the first place. You can't just handwave away a discussion that you caused. How can you assert that "it seems the general consensus is to leave things the way they are", when the discussion on this point has largely been limited to you and I? If anything, the previous discussion about the MOS changes was more representative of consensus than our current conversation.

    I'm receptive to your ideas, and have constructively disagreed, but you need to quit mis-stating my position regarding "chang[ing] the way the English-speaking world works" as fodder for your argument.

    Given that the Romans use the BIPM convention (in English), why should they avoid using it when describing a Rome-related topic (in English)? As I stated previously, we have the option of writing a complicated regulation that takes into account WP:ENGVAR for articles dealing with regional issues that "belong" to places that recognize the BIPM style, and additionally acknowledges its prevalance in modern science and engineering. I think that my proposed language provides a less complicated policy statement with the same objectives, but it would essentially allow any user to choose to employ the BIPM style, even in new articles absent a topical or regional connection. That's a side effect, but given that that WP:ENGVAR cuts both ways (in that topics with a connection to a region that employs a non-BIPM convention could reasonably be changed to follow local style, even if the article style was initially BIPM), there's clearly nothing that would obstruct the ability of editors to choose an appropriate English-language convention for the article, or write neutrally when no regional or topical connection exists. TheFeds 17:55, 26 August 2009 (UTC)

  • TheFeds: The change I reverted was nothing more than a tag-team effort comprising just you and Jc3s5h, who were feeding off each other (“say… that’s a campy idea of yours TheFeds, why not suggest some wording and I’ll put it in”–sorta stuff). That amounted to a stealth edit and did not enjoy a proper consensus that such an important change requires.

    You two’s change was to a long-standing guideline governing how something as fundamental as the formatting of our numbers are done on en.Wikipedia. It is utterly absurd to start mixing up our numbering style in an encyclopedia geared for our English-speaking readership. As A. di M. pointed out, WP:ENGVAR doesn’t and shouldn’t and can’t be applicable here. You are grasping at straws trying to make a case for what amounts to nothing more than “I like ta and wanna sanctify my practice in MOSNUM by changing MOSNUM.” Please stop. I couldn’t care less if some member of an African tribe that speaks using *!* tongue pops and counts in base-seven numbering system comes here because he or she also happens to know English as a second language. Those countries wherein English is the primary language delimit numbers to the left of the decimal point only with a comma. This practice is memorialized in the U.S. Government Printing Office Style Manual and is what is used here. So it doesn’t matter if the BIPM says it should be “75 %” and not “75%”, nor does it matter if the BIPM says it should be “a population of 285568654”. Why? Because in those countries where English is a primarily the first language, those two things aren’t done the BIPM way. It’s just that simple.

    If we headed down the path you and Jc3s5h wanted, which amounts to “let editors use either commas or thinspaces to the left of the decimal point whenever they want if the article is sorta ‘techie’ ”, then Wikipedia would once again be repeating the fiasco of our now-aborted experiment with the use of the IEC prefixes, where some articles said “256 kilobytes (KB)” and still others said “256 kibibytes (KiB)”. Given that readers were entirely unfamiliar with the latter, this accomplished nothing more than to confuse readers. It’s interesting to note that the proponents of the IEC prefixes used exactly the same arguments you two are using: “They’ll figure it out from context and… and, the (totally conjectured and unproven) confusion will be short lived, and… and, a *standards organization* has proposed it, and… and, it solves an ambiguity or shortcoming of some sort, so our use here on Wikipedia is nothing but goodliness and will make us look all futuristic and smart.” Uhm… no. All it did was unnecessarily confuse our readership.

    I appreciate your above candor. You’d like to see the use the Euro/BIPM method of delimiting numbers in an article on Rome, since—by your argument—Italian-speaking Romans who also speak English could visit the en.Wikipedia Rome article and feel all warm and fuzzy about seeing the BIPM method of number-delimiting here too. Except your argument falls somewhat flat because in Italy (at least it.Wikipedia), they format numbers like this: “Con i suoi 2.726.539 abitanti distribuiti su una superficie di 1.285 km², è il più popoloso e più esteso d'Italia.” A. di M. will no-doubt be able to flesh in some detail on this. But I have every faith that Italians recognize the method of delimiting seen on it.Wikipedia, and the BIPM method, and the English-speaking method.

    I will no longer waste my time arguing this point with you, TheFeds. Count how many editors, above, support what you are proposing. Do you see a consensus for what you desire? Or do you just hope that by not dropping the stick that we will all just come around? I’m going to leave this to Tony, A. di M., and Ohconfucius for a while. Don’t count my absence from this discussion as acquiescence; I simply tired of arguing with you.

    Frankly, if I had my way, the use of gap-delimited numbers to the left of the decimal point would be limited strictly to when text is being quoted directly from a scientific paper. The practice has no place in an article like Moon, for text like “The Moon is 384403 km away from the Earth” and MOSNUM should clearly reflect that. Greg L (talk) 20:57, 26 August 2009 (UTC)

  • A. di M., I've got to disagree with the idea that WP:ENGVAR applies strictly to nations where English is the dominant native language. Germany has around the same number of English speakers as England has people. France has tens of millions as well. (Not to mention that India has something like 100 million English speakers, and Nigeria probably has over 50 million.) I don't think it makes sense to assume that WP:ENGVAR can't apply to those English-speaking populations. When those people communicate in English, they often employ particular regional conventions—loan words in Indian and Nigerian English are perfect examples. (In other words, there's no good policy reason to believe that "English-speaking" in WP:ENGVAR means "natively-English-speaking".)

    If Wikipedia's policy was to always employ the most popular variety of English uniformly, perhaps it would minimize confusion. And then it might logically follow that the most popular numbering scheme should always be employed as well (despite regional eccentricities). But that's certainly not the way most similar cases were decided, and the policy guidelines reinforce the idea that regional preferences matter.

    Greg, I think you missed the point of the Roman example: this is about English-language usage, not Italian-language usage (as I clearly specified). I'll of course defer to A. di M.'s presumed experience with Romans, but in my experience, Continental Europeans writing formal English prose will employ the BIPM style, irrespective of the conventions used in their native language. (And with English being the dominant language for international communication in Europe, there's no shortage of usage.)

    With regard to Greg's paragraph citing the IEC prefix dispute, I'm accused of using their arguments ("They’ll figure it out from context", "a *standards organization* has proposed it" and "it solves an ambiguity or shortcoming").

    The first argument, as I noted earlier is logically equivalent to Greg's argument that many Americans will struggle to figure it out—both my assertion (that context will make most usage clear) and Greg's are conjecture, though both reasonably well founded. Absent actual evidence, you can't accept one and reject the other on a logical basis.

    The second is a strawman, as I reminded Greg prior to his reiteration of it. It's immaterial that the BIPM is a standards organization, just as it's immaterial that the U.S. Government Printing Office authored a standard that encapsulates Greg's preference. Regional usage is at issue.

    The third would be a fair point, if it weren't for the inflammatory corollary that Greg appended ("so our use here on Wikipedia is nothing but goodliness and will make us look all futuristic and smart"). Notwithstanding Greg's misrepresentation, it does address a shortcoming. As I noted above, Wikipedia could have solved the question of how to deal with variations in English usage by mandating a fixed house style (for numbers, spellings, synonyms, etc.)—but that was not adopted. Instead, consensus dictated that regional usage was permitted within an appropriate sphere of influence. MOSNUM ought to reflect the outcome of that high-level consensus. As I explained before, my proposal was more permissive than that—but the crux of the issue is that regional English-language styles are appropriate on the English Wikipedia. The additional permissiveness in my proposal reflects my belief that adoption of the BIPM style is sufficiently widespread that the effect of adding it on an equal footing with either of the comma-based styles would be essentially harmless. It's much the same as the difference between the two comma-based styles (listed at the top of A. di M.'s proposal)—readers will understand either one, even if they think one or the other is in error (because they have not been exposed to it).

    That additional permissiveness also has the effect of simplifying the MOS regulation—but if that prospect is so abhorrent, the formulation that permits the BIPM style only when regionally or topically appropriate (e.g. Continental Europe, Canada—especially French Canada, science, engineering, etc.) would minimally satisfy the existing guidelines, and would be acceptable. TheFeds 23:21, 26 August 2009 (UTC)

The traditional way to delimit numbers in Italian in handwriting is a superscript dot; but since no-one knows where to get that character, it is approximated with either a period or an apostrophe ("10.000" or "10'000"); the former is more common in Italy and the latter is in Switzerland. Recently the BIPM way is becoming common too; I guesstimate that approx. 70% of stuff published in 2009 use periods and 30% use thin spaces. But I've seen that my cousin's elementary school textbook only mentions the thin space method. There are many Italians who are unfamiliar with the comma as a thousand separator and wouldn't realize that "40,125" can mean anything else than forty and one eighth, but those Italians don't understand English enough to read an encyclopaedia article in it, so I don't see the need to cater with them in the English wiki. As for "continental Europeans writing formal English prose will employ the BIPM style", that's true, but only because an Italian is more likely to write a scientific paper than a novel in English. (And as of 2009 there's no real ground to consider India an English-speaking country; it has fewer native English speakers than Germany, and a smaller percentage of people able to speak English than the whole world.) --___A. di M. 12:51, 27 August 2009 (UTC)

Choosing a resolution

  • Alright, it looks like Greg and I cannot agree on the specific details that we'd like to see in this section. We've both dropped the issue for about a week—I think out of some measure of frustration, rather than satisfaction.

    But there are still proposals on the table, and we have yet to see any conclusive resolution that approximates a consensus.

    So my suggested resolution is as follows:

    1. I'm willing to compromise by going along with A. di M.'s proposed text, with two changes: omit the first 3rd-level-bulleted sentence (redundant, though not objectionable), and omit the recommendation portion of the second 3rd-level-bulleted sentence "so avoid using it when discussing general-interest topics" (as described above, that's contrary to the principle of following topical English conventions in appropriate articles).
    2. If other editors feel it necessary, I would be (marginally) willing to support the insertion of a neutrally-worded sentence stating that BIPM style is recommended only when regionally or topically appropriate (but not the converse—I object to a statement prohibiting it except in specific cases).
    3. If we're uncomfortable with that compromise, we can get to the root of some of the objections by making a policy inquiry. I'll ask the contributors at Village Pump (policy) what they think of the proposal, what they think of the discussions we've had (now and previously), and what they think about the specific item of contention between Greg and I—namely confusion of some readers versus regional style preferences, and the broader history and implications of advocating for one or the other through the MOS.
TheFeds 06:56, 3 September 2009 (UTC)
Yes, having a RfC is the way to go. As well as WP:VPP, I'd advertise it at WP:VPR, WP:CENT and WP:PHYS (physicists are the ones most likely to ever use any number with more than four significant digits; maybe WP:MATH and WP:SCIENCE as well?). But someone has to summarize the points made so far so that a newcomer needn't reed hundreds of kilobytes of discussions. --___A. di M. 10:02, 3 September 2009 (UTC)
  • Quoting TheFeds: Alright, it looks like Greg and I cannot agree… You’ve notably truncated the list from “Greg L and A. di M. and Tony and Ohconfucius”, to just “Greg L.” Choice.

    Please don’t confuse my apparent willingness to engage you on this issue and the relative silence from the others, as signaling that they are somehow in major agreement with you. The words of Tony and Ohconfucius, above, are short and sweet and seem to convey their sentiments clearly enough (unsupportive) as to what you propose. However, I would be exceedingly pleased if you would start an RFC so we can be done with this and I don’t have to periodically check back here, only to discover that you have again reprised this issue.

    A consensus is not arrived at by seeing who harps the longest and mostest on a given subject. Nor does one get his or her way on Wikipedia by catching people sleeping, nor by changing the documentation on templates to convey something along the lines of “better not use this template because—boy—is it gonna change soon…” nor by changing templates without having had any real discussion beyond tag-teaming with one other editor where you both go “campy idea—cup of tea?” to each other.

    Judging from the reception of me and several others, above, turning Wikipedia into a mix of numbering styles by greatly expanding the use of a number format that isn’t even used by those general-interest readers for whom English is their first language, has pretty much no chance of being adopted. And it shouldn’t, for it ignores the most basic fundamentals of Technical Writing 101. If you have to prove this through an RFC rather than examine the reception your proposal has received so far, by all means.

    As for I'm willing to compromise… language, uhm… we all have to accept the consensus of the community—period; it doesn’t much matter what you are I are “willing to compromise” on.

    Someone please e-mail me if this goes to an RfC. I don’t make it a practice to keep following TheFeds wherever he goes on Wikipedia with this idea of his. Greg L (talk) 02:23, 4 September 2009 (UTC)

  • Greg, do you seriously believe that I'm trying to imply that Tony and Ohconfucius are somehow in agreement with me?

    You might have noticed that while Tony and Ohconfucius both made short comments concerning portions of this discussion, you and I wrote at length—and my post addressed that conflict. You might also have noticed that I also excluded mention of Jc3s5h's comments in support, and did not state that A. di M. disagreed in part and agreed in part.

    And when you list several ways in which "A consensus is not arrived at", are you making an accusation, or just introducing examples that are irrelevant? I've repeatedly warned you during the course of this discussion not to jump to inaccurate conclusions about my motivations, and now I feel that I need to warn you to avoid baseless accusations of things like "catching people sleeping" and screwing up template documentation, and to avoid flippantly misrepresenting legitimate discussion as “campy idea—cup of tea?”.

    You said "uhm… we all have to accept the consensus of the community—period; it doesn’t much matter what you are I are 'willing to compromise' on"; but I don't see any basis for your objection. When we make proposals, we are free to discuss and make compromises among ourselves, in order to establish mutual support for a compromise proposal. (As an illustrative example, consider how a legislature generally works: mundane issues are discussed in committee, leading to one compromise bill, rather than by taking up-and-down votes on opposing ideologically extreme proposals.) Nothing of that process prevents a "consensus of the community" from existing. TheFeds 17:23, 4 September 2009 (UTC)

  • Quoting you: Greg, do you seriously believe that I'm trying to imply that Tony and Ohconfucius are somehow in agreement with me? I’m trying to point out that it’s not just “you vs. me” and that, given the above reaction of others, it seems exceedingly improbable that what you propose will be well received by the community. It’s a hint that you are likely wasting your time by persisting at this.

    One sort of thing that has been the source of spectacular amounts of vitriol on Wikipedia (and the Wikipedia-equivalent of suicide bombers and Turkish butt-stabbings), has been the launching of RfCs by a lead advocate on one side of an issue. This resulted in RfCs that suffered from unconscious bias and were not respected by the other side. If you seriously think your proposal has a snowball’s chance of being accepted with a clear consensus (that’s a big “IF”), then the next step is an RfC. So the proper step, IMO, is to not launch an RfC, but to propose RfC wording, we all discuss the proposal and tweak it until everyone is clear on what is being proposed and how it would change things and are mutually satisfied the “package” wording is sufficiently neutral, and then we launch an RfC.

    I have zero interest in starting all that. It’s time-consuming and, ultimately, a waste of time if it goes as I expect. I suggest you seek some assistance from Headbomb and Ryan Postlethwaite (I have no idea if they might be interested) since they both have experience in RfCs.

    Perhaps, an even better course of action would be to privately contact an editor or two that you feel are relatively unbiased and whom you have a respect for their opinions. Just ask them if they think there is a fair chance of your succeeding at what you desire. I think that is much fairer given that your persistence at this means that everyone else has to *sigh* and start jumping through hoops once you start things rolling. Greg L (talk) 18:43, 4 September 2009 (UTC)

  • I've taken some time to follow Greg's suggestion, and conferred with another editor about this topic. They felt that going through the complete process for creating a formal RfC, with another round of proposals to determine the question itself, would be a little absurd and "pointlessly bureaucratic". I concur, and like Greg, don't really want to argue about meta-proposals.

    As for asking around (less formally), they thought that it could plausibly be well-received elsewhere on Wikipedia, with the main concern being that other venues might not be interested enough in minutiae of style to comment constructively. They figured that it would be harmless enough to just ask, rather than attempting to predict the outcome.

    So, we discussed what I had in mind, and through a couple of revisions, we pared the essential question down to something general ("On Wikipedia, should the selection of digit grouping styles depend upon regional and topical conventions used in the English language?"), with a neutrally-phrased explanation of context. The question is posed at WP:VPP, in the section Digit grouping style question (from WT:MOSNUM), and I'm placing notices on some other talk pages directing users to WP:VPP for comment. TheFeds 03:46, 9 September 2009 (UTC)

Continuing discussion

This is the proper place to further discuss matters pertaining to MOSNUM.
  • TheFeds: What you call a “pointlessly bureaucratic” step is a valuable one to ensure the right thing is done on Wikipedia. You are now gaming the system by framing the nature of the problem and the nature of the solution on your own. Moreover, you did so by jumping over to an entirely different venue clearly hoping to drum up support with a different group (were you trying to drum up opposition there?). That is not how things are properly done on Wikipedia; it is venue-shopping.

    You clearly want your way, didn’t like what the others had to say, above, on this issue, and you now put us all in the position of having to chase you over to WP:VPP. No. I won’t chase you to some other venue as you hop-scotch across Wikipedia with this agenda to change MOSNUM. I even wrote above Someone please e-mail me if this goes to an RfC. I don’t make it a practice to keep following TheFeds wherever he goes on Wikipedia with this idea of his. Yet, you conveniently elected to not alert me to this “RfC” of yours; I had to do one of my periodic checks on this thread to see what you are up to. This sort of move deprives that RfC discussion from the input of the editors here who have already weighed in on this issue and are no longer paying attention to this thread nor following your every move. You can hop-scotch over to Jimbo’s page and pitch what you want there. But even he doesn’t determine what occurs here on WT:MOSNUM; he has an abiding respect that the “community consensus is always the right thing to do.”

    Discussions of how to change WP:MOSNUM must occur here on WT:MOSNUM. Period. Please drop this. You don’t win by being persistent to the point of a fault. When you have a consensus here to change WP:MOSNUM, then WP:MOSNUM will be changed. If you just want to get input from a new group that has less day-to-day familiarity with the goings-on here on MOSNUM and this talk page, then, be my guest. There is nothing wrong with that. But, please don’t commit the colossal error of running off to some other forum, obtaining a result you find favorable with a new audience, and then start making your edits to MOSNUM. Pages have their associated talk pages for a reason and you might well find yourself sanctioned if you try to change MOSNUM as a result of venue-shopping. What occurs over on the Village Pump may be interesting to you, but it is not binding on the content of MOSNUM.

    In the end, I think you are wasting your time. If you want to change MOSNUM, you must achieve a clear consensus here. Greg L (talk) 18:38, 9 September 2009 (UTC)

  • (inserting response) Greg, your accusations of abuse of process are utterly ridiculous.

    First, with regard to alerting you: presumably you watch this page and visit often, given your numerous contributions to this talk page? I notified everyone of my action, right where one would expect to see it—in the discussion thread. (Only absent my not-so-stealthy post and link, might you have had a reasonable cause for concern.)

    With regard to your concern about venue shopping, the discussion on WP:VPP is a simple and straightforward way to discuss one sticking point (among the many facets of the MOSNUM proposals), without attaching the trappings of our prior argument. The idea is to keep things on-topic, without having to saturate the discussion with refutations of alleged "Europeanization" or the like.

    It is also completely proper to ask relevant questions elsewhere, when the discussion here is deadlocked without consensus or compromise. I shouldn't have to explain that that is not a substitute for the detailed proposals at MOSNUM. Rather, it is a way to inform our discussion with the opinions of interested and relevant contributors (who frequent the policy- and science-related forums rather than MOSNUM). Unsurprisingly, that that's exactly the point of the Village Pump. This can lead to a viable consensus on an issue of mutual interest to VPP and MOSNUM, but that consensus would obviously only deal with the specifics of the VPP question, rather than forcing the adoption of a MOSNUM proposal.

    As for depriving others of input from this thread: no, I clearly linked to this thread, and advised readers that they could consult it for further information, or comment in it if desired.

    The words "pointlessly bureaucratic" were not mine—that's why they're in quotation marks. But I do sympathize with the sentiment. (I think it's overkill to make endless proposals about the question to pose—would you find that discussion particularly enlightening, and do you really foresee anything but a deadlock there as well?)

    If you object to the framing of the question, that's fair enough. I made a good faith effort to seek advice (per your suggestion) and work out a concise, neutral phrasing with an uninvolved party. You suggested having a round of discussion to decide the question for a formal RfC, but then stated that you had no interest in participating—you can't really have it both ways. TheFeds 04:34, 10 September 2009 (UTC)

  • Quoting you, TheFeds: I don't believe that someone with a working comprehension of written English would be so hopelessly confused by that format as to fail to comprehend the meaning after a short pause to think about it. You might well be right. But, it doesn’t matter. The whole point of technical writing is to communicate with minimal confusion. What you are proposing is inconsistent with the teachings of Technical Writing 101.

    Quoting you again: To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions. Yeah, I got that much. I figured that bit out in the first four seconds after seeing what you were trying to do. MOSNUM and the editors who comprise it simply don’t care about how things are done “in some regions.” What matters is how things are done for the vast majority of readers for whom English is their first language. Italians, for instance, have their own Wikipedia and en.Wikipedia needn’t be unnecessarily muddling things up for those English-speaking Italians that choose to visit an article here. The whole point of technical writing is to communicate with minimal confusion.

    Let’s touch upon why en.Wikipedia shouldn’t be kludged-up with multiple numbering systems in our general-interest articles in order to better accommodate readers for whom English is their second language. As I’ve previously explained, cross-Atlantic (or Pacific) recognition of alternative number-delimiting schemes unfortunately isn’t a two-way street. There are many ways the Europeans format numbers. In Sweden, the “Swedish1” technique (there’s yet another) is to write the population of America as “285.865.855” so why don’t we just go ahead and let articles here use that system too(?), right along with the BIPM method (which Swedish school children are also taught)? That’s a rhetorical question, please don’t answer it. The answer is because Swedish school children are also taught to recognize the American-style of delimiting numbers. In fact, Europeans by and large are not in the least bit confused when they encounter numbers with American-style delimiting. The trouble is that American’s know of only one way; they’ve been taught no other. That is why Wikipedia has long-used the most widely recognized method of delimiting numbers: it causes the least confusion (by far) over other methods that aren’t recognized by many English-speaking readers. The whole point of technical writing is to communicate with minimal confusion.

    Quoting you: [Editors are given spelling freedom via] WP:ENGVAR, and choose instead to cater to one region's preferences. Wikipedia is written for an international, English-reading audience. That means that we need to accept that occasionally, a user may encounter a term or convention from elsewhere, and be briefly confused. But this is not a critical flaw… I see you don’t seem to mind (you don’t see it as a “critical flaw”) that readers might be “briefly confused” with multiple numbering systems. I do. And, why would we cause this confusion? So that editors from all walks of life (perhaps some editor from Africa who speaks in *!* tongue pops and also speaks English as his second language) can merrily write The population of Congo in year so ‘n’ so was 66020000 because he was the first major contributor. Given that Wikipedia is has an all-volunteer contributing authorship, allowing “lorry” in some articles and “semi-truck” in another is a reasonable and necessary compromise to address how editors in England spell differently from those in the U.S. and use different words—notably for nouns. Note however, that these are differences within the English language for those editors for whom English is their first language. It is patently absurd to think that an article on the Democratic Republic of the Congo is going to have a different numbering technique that is foreign to many native-English speakers because the first major contributor to the Congo article uses that numbering technique. WP:ENGVAR does not, should not, and can not apply here. Believe it or not, Wikipedia is not about us, the editors of Wikipedia; we write for our readership. The whole point of technical writing is to communicate with minimal confusion.

    Even though you might not like to listen to others, please read comments from others, above, such as the words of Ohconfucius (04:13, 26 August 2009 (UTC) post), where he wrote The use of commas as delimiters is pretty much universal – the comma separator is not only American, it's Canadian, British, Australian, Irish, South African, Singaporean - which should take care of about 95% of the native English-speaking population. Things are done on the en.Wikipedia version of MOSNUM for a reason. Even if you don’t understand or agree with those reasons, you must accept the consensus view here. The whole point of technical writing is to communicate with minimal confusion. Is that sinking in yet? Your argument that “brief confusion” is “not a critical flaw” is bizarre and wholly uncompelling. Greg L (talk) 23:00, 9 September 2009 (UTC)

  • You're needlessly repeating your statements from above (almost verbatim in places). Repetition doesn't bolster your arguments.

    Your invocation of the Italian Wikipedia seems to me like a fundamental misunderstanding—nobody is proposing using Italian-language style here. As I pointed out above—and you overlooked again—English-language usage is at issue. (Do the Swedes use Swedish dots in English? Probably not. BIPM with spaces? Probably.) And you're stating that English as a first language is the determining factor. That's not what "English-speaking" means. (I've already presented several counterexamples, like India.) If you mean to advance that as a proposition, then do so, but avoid presenting it as axiomatic.

    When, in reference to things like "truck" and "lorry", you say "these are differences within the English language", you make a false distinction: consider digit grouping schemes mentioned in the European and American manuals of style—they are obviously both "within the English language". And that fact is not influenced by whether or not some editors have English as a first language, or otherwise.

    You're also implying that Wikipedia 101 = Technical Writing 101. Unfortunately, you're wrong. In short, technical writing can often be geared to a specific and generally well-educated audience with easily-ascertained expectations. Wikipedia, because of its diversity of readers and contributors, has chosen (by way of guidelines and precedents) to use regional (or other) styles in some instances. If you disagree with that, it's incumbent upon you to raise that discussion at an appropriate level.

    I will, however, grant that your opinions about minimal confusion are a convenient approximation, though not a well-formed universal solution to the issue of how to present text in a manner that is effective and appropriate. If "minimal confusion" was an obvious and infallible dictum, we wouldn't need to have discussions about much of the MoS. The fact that we disagree on certain points of style—just as others have disagreed before on other topics—is ample demonstration that your doctrine does not make conclusions about style self-evident.

    So what of the "brief confusion"? Although we both know what a lorry is, you must concede that an American reader might not—he might be briefly confused, until he clicks the wikilink, or figures out from the picture of a truck what is being referred to. That is more confusing than number formatting (a wholly-unfamiliar word vs. groups of digits that might be read as a number), and yet, for good reason, it is permitted on Wikipedia, even in an article that has nothing to do with Britain, but which speaks of lorries in some other context. Minimal confusion would dictate that we prescribe the most common form among our readership—which would probably be "truck" in deference to the plurality of American readers of Wikipedia. Because this is an unacceptable simplification to many readers and editors alike, regional and topical conventions that enjoy wide English-language adoption should likewise be accorded latitude despite the potential to briefly confuse whatever other group might be slightly disadvantaged.

    Furthermore, by exclusively requiring one region's style (even granting its greater adoption), you systematically disadvantage the significant set of English speakers who do not employ that convention in properly-constructed English-language usage. That can be construed as a bias, and has been the subject of many arguments. By having MoS guidelines that account for regional or topical conventions, we assure readers that they will receive an acceptable format for the subject of their inquiry, and for the editors, specify a reasonable link between the style and the content to minimize ambiguity. We therefore avoid controversy about why a British subject is described in American style. By extension, this implies that the most interested editors will have justification for employing the conventions that are most appropriate to their area of interest or expertise.

    To extend that principle, for the articles that do not have well-defined regional or topical links, one could perhaps prescribe a house style, and still present the topic in an appropriate format and avoid the potential for formatting disputes. (This seems to be what you're suggesting with your Congolese example.) But based on precedent, Wikipedia has specifically chosen not to do that—it instead falls to the first or major contributors to pick formatting conventions for the article. (That precedent and its associated consensus are clear and directly applicable to the present discussion.) This also has the side-effect of allocating bias in rough proportion to the number of major contributions by various groups, rather than biasing all such articles in favour of one popular style.

    I'm citing well-founded precedents like WP:ENGVAR, and describing a balance between the competing objectives that must necessarily be considered when policy is at stake. I think that this represents a fairer approach to Wikipedia policy than steadfast and singleminded advocacy for "minimal confusion" as the principal doctrine of the MoS. TheFeds 04:34, 10 September 2009 (UTC)

  • Fine. We’ve both had our say. Now, please convince the others here that using a numbering system that isn’t used by some 95% of readers for whom English is their first language is the right thing to do on en.Wikipedia. Your aren’t convincing me with your arguments, which I find to be shear nonsense. Moreover, your responses are revealing a colossal inability to absorb the simple basics of my points, such as Italians and English and readers for whom English is their first language. So it is quite clear that I am wasting my time by further arguing with you. If I or the others here don’t want to respond to you any more, please don’t consider that to mean that we concur with you; it just means we’ve tired of this. If you run off to some other venue and find three editors who will soon graduate from junior high school who agree with you, don’t confuse that with having achieved the necessary consensus; you need to obtain a consensus here on MOSNUM’s talk page. Merely because you demonstrate an uncanny willingness to flog a dead horse until the heat death of the universe isn’t going to give you a *win* here. The only clear consensus so far is for MOSNUM to stay as it currently is and long has been. Your persistence in the face of this simple reality is troubling. Greg L (talk) 14:36, 10 September 2009 (UTC)

← I believe TheFeds' question on VPP was way too vague to be of any use, and that discussion doesn't seem to be going anywhere, anyway. I'd go with a two-step schedule as was done on WP:DATEPOLL or WP:IECVOT: in step 1, we create a page (I'd use a subpage of this talk page) where an editor can make a proposal, discuss about other editors' proposals, and tweak his/her proposal to address the points made by other editors. In step 2, no further edit is allowed to the proposal, and editors will be allowed to vote for proposal using a decent voting system (I'd go with the Schulze method). The first step should be advertised here, on WT:MOS, on WP:CENT, on WP:VPP and WP:VPR; the second step should be advertised as widely as possible on Wikipedia, including a watchlist notice. As for the time schedule, I'd go with seven days for each step. After the second step is concluded, the proposal which wins according to the chosen voting system will be incorporated in WP:MOSNUM to stay unchanged for six months. Or something like that. --___A. di M. 15:09, 10 September 2009 (UTC)

  • I'm a little curious about your objection, because as I explained to Greg, the intention is not to mandate a particular style proposal through WP:VPP. The question is phrased that way because VPP is the most appropriate place to discuss policy implications that affect the site, and limited in scope because the specific proposals from above should not be discussed at VPP.

    As for the RfC mechanism you've outlined, that level of formality is—I think—inappropriate for the limited question asked at VPP. The RfC process you outlined tends to be used for votes on fully-formed proposals—and I could support that procedure if we were voting on entire MOSNUM proposals. But for a policy consultation, it's not a good fit. TheFeds 16:33, 10 September 2009 (UTC)

  • Indeed, I think that discussing specific wordings would be more useful than discussing vague general principles. (Two persons might agree on a principle but disagree on the way to implement it, or they might agree in giving some recommendation of style but for different reasons.) --___A. di M. 17:54, 10 September 2009 (UTC)
  • (inserting response) That's a fair comment, and I accept the possibility of different interpretations arising from the policy consultation. However, I think that the comments on VPP are, despite their limited scope, valuable as a sanity check against the unsupported assertions made in this thread (especially the opposing common-sense interpretations that Greg and I have offered). Let me reiterate that the VPP process complements the MOSNUM process, but does not replace it. (Despite Greg's unjustified insistence that I subscribe to that theory.) TheFeds 00:22, 11 September 2009 (UTC)
  • I agree with A. di M. I told you this once, TheFeds, about how to properly conduct an RfC but you didn’t take the advise and ran off to the Village Pump to do your thing all by yourself. Ill-considered, biased RfCs are nothing but pure trouble on Wikipedia. You have two choices now. 1) drop it, or 2) do things the right way and begin the process of creating an RfC that both sides work on until it is fair, complete, clear, and balanced. And then the RfC, which must be conducted here if it the result is to be a change to MOSNUM, goes live and the editors who frequent MOSNUM (and anyone else who wants to come here) can register their opinion. As to why you would persist at this seems wholly unrealistic given the above reaction of many of the editors here. But if there is to be an RfC, then we should do what worked well with Ryan’s date-linking RfC:
  1. A simple, unbiased preamble explaining the essence of what it’s about
  2. Statement of the existing wording.
  3. Statement of the proposed wording.
  4. A 300-word “for” essay
  5. A 300-word “against” essay
  6. Room for editors to state how they feel about the proposal (you know, what the losing side calls “!votes”)
If you want to waste your time (and that of others), you can kick it all off and take care of points 1, 2, 3, 4, and 6. I’ll volunteer to be the lead shepherd with #5 (with help from others).
I suppose there is a third option for you: to endlessly keep on arguing this on the assumption others will come around to “see the light of your reasoning”. If that’s the case, then it might be time to just let you rant here all by yourself. There is no rule that says anyone has to respond to you. Greg L (talk) 19:26, 10 September 2009 (UTC)
  • Greg, are you overlooking what I wrote above? I've already explained to you that I see a distinction between the RfC procedure above, and a policy reference question on VPP. You pretend to speak with authority about RfCs, when it appears that you're just substituting that procedure for a process you dislike. You had a perfectly good chance to express your opinions, and make constructive suggestions, and instead you expressed disinterest in further discussion and wanted this thread to go away without consensus or compromise. TheFeds 00:22, 11 September 2009 (UTC)
  • Given all of the above, in lieu of the discussion and compromise on the MOSNUM proposals that I referred to in the previous subsection, is there now interest in conducting an RfC offering a choice between proposed changes to WP:MOSNUM? (Let me distinguish that from the question that I posed at VPP, which was clearly not a question about one proposal versus another, and was not intended as such.)

    To be perfectly honest, I'm not sure that there's strong enough interest to expect a meaningful RfC result (as in, a response from people other than those who have already clearly expressed their opinions).

    I am ambivalent about the need to go through all of that formality over a paragraph in the MOS: I would be weakly opposed on those grounds. But I'm also concerned because I believe it will become mired in meta-debate. And that meta-discussion, especially if conducted by Greg in the style he's employed to date in this thread, will probably be marked by the same incivility, unwillingness to compromise, and tritely-phrased misrepresentations that he employed above. If it's likely to end up like that, I would oppose it.

    There's also the broader question of whether we tacitly support a proliferation of RfCs to resolve simple changes that lack clear consensuses. I'd say that this debate is somewhat unique, in that it's lacked widespread input, is not of critical importance, and yet has consumed a lot of text. Are we saying that when mundane proposals go bad, we should proceed to an RfC, rather than first trying less formal tools for advancing the discussion? TheFeds 00:22, 11 September 2009 (UTC)

  • Quoting you: Are we saying that when mundane proposals go bad, we should proceed to an RfC, rather than first trying less formal tools for advancing the discussion? Uhm… yeah… apparently. It’s clear as glass from the responses from me, A. di M., Ohconfucius, and Tony during these “less formal” debates that there isn’t much enthusiasm for what you are proposing. Yet, here you are again, hammering away on the same ol’ issue. If you have to go to a properly-conducted RfC to smell the coffee, then I guess that’s what it takes. Wearing out your keyboard until everone’s eyes glaze over and we all cry “OK, I can’t take it any more so you get your way” isn’t in the cards. After over 100 kilobytes (really) of verbiage on this, you are no closer to achieving a consensus here to introduce a mishmash of two different numbering schemes in the general-interest articles of the English-language version of Wikipedia than you were from the start. Nothing’s broken so there is no enthusiasm to fix anything. Greg L (talk) 05:52, 11 September 2009 (UTC)

Back to the point. I come fresh to this debate, and was not aware until now that it was going on. User:Greg L is correct in proposing that numbers (to the left of the decimal point) be delimited by commas. But contrary to what Greg L perhaps assumes, it is not only an American thing, it is normal practice here in Britain too, so covers most of the mother-tongue-English-speaking world, in terms of population (apologies to Canadians and Australians). If it is true as alleged that the BIPM style is dominant in some English-speaking regions, they must be very much in a minority.

BIPM (of which I had never heard until today), based in France, appears to be trying to impose French practice on the rest of the world. I can reveal from personal experience that the only reason the European Commission translation service's English style guide lays down the BIPM policy in this particular respect (it does not do so in many others) is because they are translating thousands of documents every day from French to English, and for purely technical reasons it makes their lives much easier just to leave the numbers in the French format. The people who work there are well aware that this isn't normal British practice, and is a departure from the usual EU policy of using British English, but they have adopted a pragmatic compromise to save time and money in their particular special circumstances.

The Oxford Dictionary for Writers and Editors (a British publication) says:

Use commas to separate each group of three consecutive numerals, starting from the right, when there are four or more, except in math. work and pagination; in scientific and foreign-language work thin spaces are used instead of commas.

-- Alarics (talk) 13:35, 13 September 2009 (UTC)

Al, Canadians use the same numbering system, and as to BIPM, according to a recent press release, the Republic of Kazakhstan acceded to the BIPM on 31 December 2008, which kind of makes it seem that nations are "coerced" into the accord, one by one? FWiW Bzuk (talk) 13:53, 13 September 2009 (UTC).

Right, so even if we assume that the French-speaking Canadians use the French system, that's another 20 million English-speakers on our side. Can we ask User:TheFeds, when he writes of the BIPM style that "it is the dominant English-language usage in some regions", which regions he has in mind? -- Alarics (talk) 16:03, 13 September 2009 (UTC)

  • That applies primarily to Continental Europe, where people use dozens of languages with regularity, but where English (as a second language) is a common denominator across most regions. There are, conservatively, at least 100 million English-speaking Europeans, not counting the British and the Irish (and by some estimates, over 160 million).

    And at least in my experience, publications written in or translated into English in Europe use the BIPM style. (To cite a particular example, many French graduate schools use English as the language of instruction, and students write their theses in English.)

    It might well be that the EU wishes to simplify their transcription of documentation from French to English by prescribing that style—but I suspect that the motivation goes a little beyond economy. In my estimation, because many European regions have their own traditional conventions in their native languages, and just as Europeans have settled upon English as a de facto language of collaboration and commerce (albeit while trying to maintain their regional dialects for culture's sake), they've settled upon the BIPM-style digit grouping to reduce ambiguity in communication. For example: the traditional French convention was commas for the decimal place and periods for digit grouping—the inverse of British usage, and obviously confusing. (In other words, I don't think the EU or BIPM is trying to push French style on everyone.)

    Additionally, the BIPM convention is understood in English Canada, and has been taught in their schools for many years. (As well as being universally used in French Canada.) You're quite right about Britain, though; they do prefer the comma-based style. I'm not completely certain about the rates of usage in Australia and New Zealand, but I can scarcely imagine that either convention would be unfamiliar to them—I'd speculate that they are somewhere between Britain and Canada in terms of usage. TheFeds 04:25, 14 September 2009 (UTC)

  • Let me also add that the question of first-language usage versus other-than-first-language usage came up above, and that it's a source of disagreement. I'm of the opinion that the existing Wikipedia guidelines are not intended to make such a distinction, and that it is reasonable to consider significant usage among major English-speaking populations, rather than sticking strictly to official languages.

    As for the bigger picture, it's an open question whether Wikipedia should allow regional usage in region-neutral articles, or insist upon a fixed style—but that's not really even the heart of the issue as it relates to MOSNUM. TheFeds 05:47, 14 September 2009 (UTC)


Conclusion

It's pretty apparent that the discussion above has been inconclusive. The discussion ended up as a back-and-forth between myself and Greg L, and my attempt to seek policy advice from WP:VPP didn't shed any light on matters.

If the proposals are stale, then there's only one more order of business: establishing what the consensus was for digit grouping, so that we can revert to it.

Let me preface by saying that this is in no way a personal attack—quoting Greg L:

...One other note: en.Wikipedia adopted the U.S. style and standardized on delimiting to the left of the decimal marker using commas. Let’s please accept that nothing in this debate can change that and limit the discussion to the number of digits per group.

— Greg L, 15:16, 8 October 2008 (UTC), WT:MOSNUM Archive 112

...Now, Gerry, let’s get real shall we? I’ve mentioned several times above that en.Wikipedia adopted the US convention of delimiting to the left with commas. Nothing we’re discussing here is ever going to change that fact. The people over on fr.Wikipedia will keep doing as they like. As I wrote several times above (it would be nice if you actually read some of the goings-on here because I’m way ahead of you here) this practice of comma-delimiting to the left is far too entrenched in the U.S. and across the Internet for you to change that with your above epiphany. None of us here in this debate on this mote of a backwater discussion is going to change the way the U.S. works in this regard nor en.Wikipedia’s adoption of that widespread convention. As I also wrote above, this is an issue of simply adhering to the three-digit practice that is common throughout Europe and which has been standardized for use with the SI....

— Greg L, 18:07, 9 October 2008 (UTC), WT:MOSNUM Archive 112

That is from the discussion that brought about the phrasing that Greg reverted to (kicking off this lengthy discussion). It's focused on the RHS of numbers, rather than both sides of the decimal point. When other users mentioned that SI/BIPM prefer spaces on both sides, there was really only one argument for (what we later discovered to be) the U.S. GPO style—Greg asserted that it was a fait accompli that commas were used on the LHS by Americans, and said that Wikipedia might as well go along with that well-entrenched usage.

But because of that, the thread avoided discussion establishing why commas-on-the-left should (or should not, or should sometimes) be the preferred format. It bypassed the concern that SI compliance would entail spaces on both sides, and instead dealt with the RHS digit grouping to define the behaviour of {{val}}. As a result, no consensus was formed about what to do with the LHS.

It is, however, where the (permissive) technical usage clause comes from (courtesy of A. di M. as Army1987)—that part seems affirmed by consensus.

To find a discussion that arrived at a consensus on how to group the LHS of numbers, or to find an overarching agreement on both the left and right sides, we're sort of out of luck. Going back much further, MOSNUM used to say to use commas only (without regard to any special cases)—but that was basically just an arbitrary convention that hadn't been extensively discussed, and wasn't uniformly followed. Even in Archive 19, and Archive 74, consensus was absent, and the issue was dropped without formal proposals or major revisions to WP:MOSNUM.

On another note, I'm going to quote Greg L again here:

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, 03:59, 20 December 2007 (UTC), WT:MOSNUM Archive 94

Strangely enough, that's a lot like what I was talking about. Yes, there are distinctions, but they are minor; that argument was used in a discussion about how to deal with the RHS of numbers—group in threes, fives, or don't group at all. (I'm wondering what's so false about Greg's previous argument that it doesn't apply any longer.)

In any event, the question of what level of confusion will result, or is acceptable in this case is not settled. And we haven't done justice to weighing the need to limit confusion versus other objectives on Wikipedia.

Later on, when Jc3s5h and I were allegedly trading campy ideas, there was in fact a substantial discussion about digit grouping (related to my edits). After a shaky start, where we got sidetracked over some possibly-misremembered standards, we consulted style guides, got input from a few editors (in addition to the regulars), looked at the archives, and managed to formulate a proposal that was not opposed. Now that's not necessarily the same as a clear consensus—because there were really only three of us commenting upon and implementing the final draft.

But it's certainly better on basing our treatment of delimiting in general on the results of a series of discussions that were specifically framed to deal only with RHS delimiting and templates, or which (going back several years) were more concerned with the thin-space handling in IE6 than digit grouping per se.

The take-home message is therefore this: the long discussions on MOSNUM were primarily based on how to handle {{val}} and its relatives, not to set a policy for numbering styles in general, and certainly not to require a particular convention. The question of regional usage per WP:ENGVAR is not settled—the VPP reference question was split, and we've hardly resolved any of that here. The question of technical usage was agreed upon previously.

Unless someone wants to resurrect the proposals, maybe we should just call this a "dismissal without prejudice": one of these days, when someone works up the courage to propose a resolution (maybe even through an RfC, if that option is more popular than traditional discussion), we can revisit this topic properly, with a more thorough and civil discussion, and buy-in from a sufficient cross-section of editors to establish a clear consensus one way or another.

In the meantime, all we've really got is consensus on how to make the RHS work (especially in templates), and how to use SI-style notation in technical articles. Let's accept that at face value, and move on. TheFeds 06:33, 21 September 2009 (UTC)


For the digits to the left of the decimal point, MOSNUM currently says:
  • Numbers with five or more digits to the left of the decimal point (i.e., 10,000 or more) should be delimited (visually separated into groups so they can be easily parsed) using commas every three digits; e.g., 12,200 and 255,200 and 8,274,527 etc.
  • Numbers with four digits to the left of the decimal point may be delimited with a comma; that is, there were 1250 head of cattle and there were 1,250 head of cattle are both acceptable.
  • In scientific articles, particularly those directed to an expert readership, numbers may be delimited with thin spaces using the {{gaps}} template.
  • The style of delimiting numbers to the left of the decimal point must be consistent throughout an article.
This appears to coincide almost precisely with the instruction I quoted some way up this page, from the Oxford Dictionary for Writers and Editors:

Use commas to separate each group of three consecutive numerals, starting from the right, when there are four or more, except in math. work and pagination; in scientific and foreign-language work thin spaces are used instead of commas.

Is TheFeds now saying we can leave that as it is? That would suit me fine. -- Alarics (talk) 11:32, 21 September 2009 (UTC)


It's not that I've changed my opinion on this subject, only that I don't feel this particular thread is going to lead us to a resolution. Basically, I'm expressing the fact that we haven't found a consensus for many of the issues that came up in this and previous discussions. Most importantly, there's no basis (past or present) to declare that any one (or any set of) digit grouping schemes enjoy consensus for anything other than technical articles.
However, this wouldn't be the only thing in the MoS that exists despite a lack of specific, widespread consensus, but which is unchallenged due a feeling that it has a low priority, or outright disinterest. As long as it is very clear that it is a permissive, rather than prescriptive guideline (e.g. "may" rather than "must", etc.), I expect that we won't see undue pressure to reject or apply one style or another.
So, I'd say the text should be minimally amended to say "...should be delimited (visually separated into groups so they can be easily parsed), such as by using commas every three digits..." to avoid the impression that a consensus exists on the minutiae of the issue. TheFeds 04:01, 22 September 2009 (UTC)

xt?

Wasn't there a proposal to do an uplift of the use of {{xt}} on the MOS/MOSNUM just a while ago? Did that die? Headbomb {ταλκκοντριβς – WP Physics} 20:12, 9 September 2009 (UTC)

  • What does “uplift of the use of”… mean? Use it more extensively throughout the two style guides? I started to update MOSNUM with more of it, but it is damned slow and tedious. Greg L (talk) 20:19, 9 September 2009 (UTC)
    • Greg, paste into Word and use a macro (comprising open finder, type " into the find box, search next, delete, type in the xt opening option-right-arrow, etc ...: so easy! MoS main needs the same treatment, but don't worry: all is in hand. I think an editorial note at the top reminding users of the xt thing would be desirable. Tony (talk) 09:58, 10 September 2009 (UTC)
By "in hand" do you mean someone is doing it? If you want, I am happy to convert most "Do it like this." examples to "Do it like this." (using something better than Word). What about this existing text: There is no such ambiguity with recurring events, such as "January 1 is New Year's Day". Should the text in quotes be in an {{xt}}? Johnuniq (talk) 10:31, 10 September 2009 (UTC)
  • This is a little besides the point, but I just find the existing shade of green rather ugly and hard to read on the existing default background color (a sort of very faint aquamarine or sky-blue) that most editors (and I) keep. —— Shakescene (talk) 23:37, 10 September 2009 (UTC)
  • The {xt}-shade of green is a compromise that has been tweaked and tweaked so the loud din of complaints has largely diminished to a mild case of tinnitus. Tony, for instance, has a 24-inch iMac and to listen to him, {xt} produces a Liberace/fluorescent-green that could only be produced by an explosion at the Disney factory. Simultaneously, still other editors with Barbarian-OS PCs and horribly tuned monitors with gammas set to near-infinity sometimes complain that the {xt}-green is nearly indistinguishable from regular black text. The current compromise value—while perhaps not perfect—seems to have minimized (though not entirely eliminated) objections. Greg L (talk) 05:19, 11 September 2009 (UTC)
    FWIW, the standard gamma approved for use with the World Wide Web is the one used by PCs (in which the squares in have uniform luminosity), not that used by Macs. Browsers running on OSs using different gammas are supposed to compensate. --___A. di M. 08:49, 11 September 2009 (UTC)
  • Hmmm… I switched my gamma setting from “iMac” to “Wide Gamut RGB” and the center squares disappear without the need to tilt my LCD display at what appears to be a 30° angle. In fact, they disappear when the monitor is tilted just about dead-on square with my eyes. That suggests there is some technological “magic” underlying this. Unfortunately, neutral grays take on a distinctly bluish cast. And (no surprise here), {{xt}}‑generated text is quite a bit darker. The display also went much darker but I easily compensated for that via a brightness boost. I’m going to try this for a few days—if I can.

    Truth be told, accurate color work is impossible on this 17-inch iMac because the parallax change caused simply by scrolling the above color-swatch from top to bottom of my screen causes the center squares to go from noticeably too-dark to too-light. My really, really good Sony 21-inch CRT monitor is still attached to my old Mac, which will forever be “Peter Pan”ed at OS 7.5.5 so I can continue to use a certain CAD program (I really scream on that old wire-frame application). Now that monitor is for high-fidelity work with color. Greg L (talk) 18:30, 12 September 2009 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_126&oldid=316402589"