Wikipedia talk:Manual of Style (dates and numbers)
From Wikipedia, the free encyclopedia
| WikiProject Manual of Style | |||||
|---|---|---|---|---|---|
|
|||||
|
This talk page is for discussion of the page WP:Manual of Style (dates and numbers). Please use it to make constructive suggestions as to the wording of that page.
|
Contents |
[edit] Digit grouping
On June 3, User:TheFeds changed the digit grouping section. I endorse the spirit of the change, but I mercilessly edited it to conform to my understanding of many printed style guides (I suspect my edit reflects what TheFeds had in mind). I wish to call editors attention to the fact that the {{Val}} template does not conform to the changed MOSNUM, in that it uses commas to the left and thin spaces to the right, even in the same number (e.g. 123,456.78901). If this change is accepted, the Vals template can be changed to conform to the change. --Jc3s5h (talk) 11:53, 3 June 2009 (UTC)
- Has anybody ever seen a number written as "0.123,456" anywhere? --A. di M. (formerly Army1987) — Deeds, not words. 14:40, 3 June 2009 (UTC)
-
- Normally, I would refer to the BIPM/ISO 31-0/NIST convention which suggests spaces, on both sides—that's definitely the dominant convention in most modern (e.g. post-1980) texts with which I'm familiar. Other style guides (e.g. Chicago) just suggest grouping thousands (mathematically, 1000n) with commas, but don't specify whether n < 0 counts (as it does in the BIPM convention). It's not quite fair to cite an elementary-school introduction to these things, but the general guidance that we received involved using the BIPM convention preferentially, or using commas instead (on both sides) if desired. That seems to carry over to hand-written work with which I'm familiar. I've also seen commas used on the right of a decimal point in older books (like, early 20th century). Somewhat-recent American texts using imperial/customary units usually use the commas-on-the-left-only style, but when they convert to SI editions, they seem to adopt the BIPM convention. Tables of values often use digit grouping symbols on both sides—but they're just as likely to omit them altogether. So basically, the edit I made was referring to accepted style manuals, and when unclear, erring on the side of mutual consistency; it looks like you might prefer erring on the side of historical practice in the U.S.A. and (perhaps) Britain? Maybe we should be emphasizing the BIPM convention, because it is less ambiguous on this point? TheFeds 21:41, 3 June 2009 (UTC)
-
-
- The Chicago Manual 14th ed. (current edition is 15, but I don't have it) says on page 310 "commas should be used between groups of three digits, counting from the right....Exceptions to this rule are ...decimal fractions of less than one". Later on the page, under SCIENTIFIC COPY, it suggests the BIPM style.
-
-
-
- The Publication Manual of the American Psychological Association 5th ed. on page 130 gives the example "numbers to the right of a decimal point 4,900.0744". I wonder if the examples of using commas to the right of the decimal point mentioned by TheFeds were in English? This is, after all, an English encyclopedia.
-
-
-
- As for emphasizing the BIPM convention, I think that is unrealistic, since most Wikipedia editors are not scientists, engineers, or the like. It is really only in science and engineering that the BIPM convention has made any headway in the US. It is generally rejected when dealing with money, due to the opportunity for forgery. Far more Americans write checks than read scientific journals. --Jc3s5h (talk) 22:23, 3 June 2009 (UTC)
-
-
-
-
- I'm quoting from memory, but I'm quite sure that the Numbers section of the 15th edition of Chicago says something like 'In numbers with a thousands place, use commas to group digits in threes, counting from the decimal point'. It's possible that it also states the exception for decimal fractions less than one, but I don't remember it. It goes on to give the BIPM convention as an alternative. (If anyone happens to have access to that, they can check up; it's been a couple months since I last looked through the actual document.)
- Either way, no commas on the right of the decimal isn't a huge deal, and I'd be amenable to either style. But if we're relying upon a particular style guide as our basis for the decision, we should be clear whether or not following one recommendation in a guide is an endorsement of the rest of the guide. (I suspect that it isn't necessarily.) TheFeds 03:42, 4 June 2009 (UTC)
-
-
-
-
-
- I've deliberately avoided chigago manual of style since i am not american but my 1967 copy of the engineers number handbook (a little book full of figures and conversions) says that it should be written with commas in the integers and spaces in the decimals. i have never actually seen it written that way but that is what it says and that would come from ISO. I think WP:COMMON sometimes must prevail. SimonTrew (talk) 11:02, 6 June 2009 (UTC)
-
-
-
-
-
-
- Haven't forgotten just still unpacking books and it is such a slim volume is easily missed. It is maroon cover almost a pamphlet I would guess about 64pp. and the front is in that newfangled kinda neon font in white on maroon and I am not sure if it has an ISBN. However please could you remind me if I havenot done so by the end of the month, I am liable to forget these things. If it hasn't an ISBN (and would no doubt be out of print anyway) there's not a lot we can do as far as RS I guess, as it is probably mid 1960s, but I can at least as far as MOSNUM goes tell you what it says to give you and so give you an alternative way to toss up a decision where it differs. It has logs and trig tables and stuff but also all kinds of conversions etc. I am not sure I even have the title right, when I think of it, I think I do but I am doubting myself now. I have it in my visual memory but maybe I have not got number right it may be conversion or something like that. SimonTrew (talk) 18:24, 23 June 2009 (UTC)
-
-
-
-
-
-
-
-
-
- Found it, it's actually called the Science Data Book. My memory must be faulty as it uses spaces both sides of the point. It is totally silent on the matter of formatting actually. Anyway for completeness it is published by Olicver & Boyd 1971, ISBN 0 05 002487 6, Edited R M't Tennant. I *thought* it had a preamble with this stuff in it, but must be mistaken, just refers to various conventions on weights & measures etc. Generally it uses <3 to left of d.p. i.e. scientific/engineering notation, i.e. use 10^3, 10^6, 10^-9 etc but not 10^7 or 10^-2. (can't be bothered to type all those sups!). It does very occasionally veer from this but only when explicitly making a contrast etc. SimonTrew (talk) 07:09, 29 June 2009 (UTC)
-
-
-
-
-
-
-
-
-
- I just tracked down what the Chicago Manual of Style, online 15th ed. says on numbers:
-
9.59 Comma between digits
In most numerals of one thousand or more, commas are used between groups of three digits, counting from the right. (In scientific writing, commas are often omitted from four-digit numbers.
1,512
32,987
4,000,500
No commas are used in page numbers, addresses, and years (though years of five digits or more do include the comma.)
Punctuation conventions can be found on page 1535 of the tenth edition.
Our business office is at 11030 South Langley Avenue.
Human artifacts dating from between 35,000 BP and 5000 BP have been found there.
-
-
-
-
-
-
-
-
9.60 Space between digits
In the International System of Units, half-spaces rather than commas are used to mark off groups of three digits, both to the left and to the right of the decimal point. In numbers of only four digits either to the left or the right of the decimal point, no space is used (except in table columns with numbers having five or more digits). This system is far more common in Europe than in the United States. Chicago’s Astrophysical Journal, for example, uses commas, not spaces (see bibliog. 5). See also 9.22, 9.59.
3 426 869
0.000 007
2501.4865 (four-digit numbers require no space)
See B. N. Taylor, Guide for the Use of the International System of Units (SI) (bibliog. 2.4).
-
-
-
-
-
-
-
-
- That's mostly along the lines of what I remembered, and doesn't really talk about RHS commas, except to suggest that the Chicago Astrophysical Journal uses them in preference to spaces.
- It also looks like Chicago doesn't go into what to do about (for example) seven digits on the RHS when using thin spaces as the digit grouping symbol; it just says "four-digit numbers require no space"—which is like the BIPM's text, but not their examples. That suggests to me that they don't recommend grouping seven digits on the RHS in groups of 3 & 4, but rather would use 3, 3 & 1. TheFeds 17:55, 29 June 2009 (UTC)
-
-
-
[edit] Digit grouping consistency
Since the change to allow numbers formatted like 12345.67809 and discourage the format 12,345.67809 has not been challenged for nearly a week, let me ask a related question. If one of the numbers in an article uses gaps to group digits, should all the numbers in the article be changed to match.
For example, if an article currently reads there are 43,560 square feet in an acre and an exact SI conversion is added, should it revised to say there are 43,560 43560 square feet (exactly 4046.8564224 m2) in an international acre? --Jc3s5h (talk) 17:29, 9 June 2009 (UTC)
Being a Dane living in England, I have lived with two different ways of presenting the same information (Denmark uses a comma as the decimal separator and a point as the digit group delimiter, whereas England uses a point as the decimal separator and a comma as digit group delimiter) and I find the BIPM way the least confusing solution as 1,234.567 is ambiguous: Is it 1234.567, i.e. the English interpretation, or 1,234567, the Danish interpretation? By using spaces only as digit group delimiters, no number will be ambiguous, whether a point or a comma is used as decimal separator. —Preceding unsigned comment added by 79.78.201.76 (talk • contribs) 17 June 2009
- It is not the job of Wikipedia to promote change in the way the world works by adopting good ideas by standard bodies just because they are good ideas and come from standard bodies. Wikipedia generally simply follows the way the world really works. Truly good ideas from standards bodies usually rapidly gain traction in the real world. When that happens, Wikipedia follows suit. In other cases, such as the IEC’s proposal that the world adopt the new binary prefixes like “256 mebibyte”, the proposal falls on its face. And again, notwithstanding the compelling virtues of the IEC’s proposal, Wikipedia ignores the proposal so as to not confuse our readership.
As regards the delimiting of large numbers and/or high-precision numbers in all our general-interest articles, Wikipedia specifies the U.S. method of delimiting numbers using commas in the significand because that causes the least confusion with its readership. U.S. readers are far and wide entirely unfamiliar with other delimiting conventions whereas their European counterparts are typically comfortable with several different methods and are not in the least confused by the U.S. convention. Scientific articles are a notable exception, since the language of science is scientific papers which follow the SI method so that such papers can be read by a world-wide audience. Even then, delimiting with narrow spaces is allowed in our scientific articles—not required.
Please remember that the overriding principal on Wikipedia is to follow practices that cause the least confusion with its readership. Note also that the rule of SI is to have a space between the number and the percent symbol, such as “50 %” rather than the “50%” we are all accustomed to. So that our articles cause the least confusion and look most natural, we wisely ignore that suggestion (yes, even thought it comes from the BIPM and their SI).
I note that the two of you (The Feds and you, Jc3s5h) have been having a discussion amongst yourselves, above, and have been quietly making changes to MOSNUM without buy-in and consensus of the rest of the Wikipedian community. I know you clearly believe what you are suggesting is a better way to do things. Please bear in mind that MOSNUM guidelines are often the product of tortuous and lengthy (often very lengthy) discussions and are done a certain way for a reason. When a situation arrises where a proposal, as you wrote above, has not been challenged for nearly a week, that does not equate to acquiescence and agreement with a proposal. Please widen the discussion so there is a clear consensus before revising MOSNUM. Greg L (talk) 02:09, 13 June 2009 (UTC)
- In Norwegian we're very custom to space between the number and percentage sign (i.e. "50 %") and we're very customary to the ISO 31-0 (which says "Numbers consisting of long sequences of digits can be made more readable by separating them into groups, preferably groups of three, separated by a small space. For this reason, ISO 31-0 specifies that such groups of digits should never be separated by a comma or point, as these are reserved for use as the decimal sign.") way of writing numbers (i.e. using space as an thousand delimiter like 1 000 000,000 1, i.e. one million and a 1/10000 part). Per WP:SOURCES ("In general, the most reliable sources are peer-reviewed journals and books published in university presses; ") we should use scientific journals as our best source, and from this it follows that we should try to addhere to standards like this (used in these journals all over the world, even in the US) Nsaa (talk) 15:34, 18 June 2009 (UTC)
-
-
- The period (stop) is well-entrenched as the decimal point in the anglosphere. Gee, those full spaces look awkward on my display—no wonder many people recommend thin spaces. Tony (talk) 16:07, 18 June 2009 (UTC)
- But this isn't an 'Anglosphere' Wikipedia, our readers come from almost every country, and the use of the comma is common in South Africa and Australia it appears, so I'm not even sure it is well entrenched in the 'anglosphere'. Our article Decimal separator is a help on this.
- Nevertheless, it is the 'English' Wikipedia, and it would seem odd to adopt a convention that is not in use among the (English) sources that we use. I can find no reference to Australia using a comma as decimal separator; in fact the article you pointed to, Decimal separator, lists it with all the other English-speaking countries in using the period. The same article only lists South Africa among English-speaking countries as using the comma (and that is qualified as "officially[citation needed], but dot point is commonly used in business"). I am pretty convinced that the use of the period is very well entrenched in the Anglosphere. --RexxS (talk) 18:09, 23 June 2009 (UTC)
- But this isn't an 'Anglosphere' Wikipedia, our readers come from almost every country, and the use of the comma is common in South Africa and Australia it appears, so I'm not even sure it is well entrenched in the 'anglosphere'. Our article Decimal separator is a help on this.
- The period (stop) is well-entrenched as the decimal point in the anglosphere. Gee, those full spaces look awkward on my display—no wonder many people recommend thin spaces. Tony (talk) 16:07, 18 June 2009 (UTC)
-
[edit] Comparison of texts in "Large numbers"
This discussion came about as a result of two different versions of part of the "Large numbers" section. The first example below incorporates some clarifications I made, plus some changes Jc3s5h made. The second example is the prior version of that section. Now that we've been discussing it for a while, I'd like to see whether others feel that the first example is clearer overall, and should therefore be the basis for the eventual revision of the section. I know I'm of that opinion, principally because that version is clearer about what is permissible and in what situations, states individual possibilities in separate bullets, and covers cases that are ambiguous in the other version. Does anyone feel that the second option is clearer?
- In a number with many digits, digit grouping symbols (inserted at intervals from the decimal point) should be used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
- Commas every three digits (8,274,527) only to the left of the decimal point, with no grouping to the right of the decimal point. This is traditional usage in many English-language contexts.
- Thin, non-breaking spaces every three digits (8274527 or 0.12345). This format is suggested in BIPM and NIST style guides for scientific works, and is in common use in interlanguage contexts. The {{gaps}} template uses CSS to produce this output (using the syntax
{{gaps|8|274|527}}). The character may cause rendering problems in some browsers, and should be avoided when practical.- Other traditional digit grouping schemes, when relevant to the subject matter of the article (e.g. 82,74,527 in the Indian numbering system).
- When 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 0.9876 are acceptable).
- In large numbers (i.e., in numbers greater than or equal to 10,000), commas are generally used to break the sequence every three places left of the decimal point, e.g. 8,274,527. In scientific and mathematical contexts, {{gaps}} may be used to insert thin spaces, e.g.
{{gaps|8|274|527}}produces 8274527 (note: the thin space character and its HTML entity, , do not render correctly on some browsers). Consistency within an article is desirable as always.
If we generally prefer the first example, we should implement that change to the MOS (it got reverted during the course of our discussion), because it's generally independent of the RfC going on below. (The result of the RfC can easily be added, once it is established—until then, we can stick to the status quo for the U.S. customary style guideline) Any objections or suggestions? TheFeds 07:04, 19 June 2009 (UTC)
- The first version does not make it clear that for the thin space scheme, the thin space may be omitted to the left of the decimal if and only if there are exactly four digits to the left. But to the right of the decimal, the rightmost thin space may be omitted if the rightmost group would otherwise contain only one digit. That is, 7682533 is wrong but 0.768 2533 is OK.
- Also, neither version endorses the current behavior of the {{Val}} template. --Jc3s5h (talk) 14:23, 19 June 2009 (UTC)
-
- While I see what you're getting at, it doesn't seem to be something that NIST or the BIPM endorse (they say exactly-four-digit groups on either side are the lone exception). I'm not so sure we're well-served by having an exception to the exception (for 3n+4 digit groups on the RHS). Is it particularly advantageous to use that style on Wikipedia?
- Per the BIPM:
-
Following the 9th CGPM (1948, Resolution 7) and the 22nd CGPM (2003, Resolution 10), 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. However, when there are only four digits before or after the decimal marker, it is customary not to use a space to isolate a single digit.
-
- Regarding {{val}}, I think the best way to handle it is to decide what the preferred formats ought to be (in the MOS talk arena), and then afterward, discuss changing {{val}} so that it meets one. Alternatively, if the RfC eventually determines that the format currently used by {{val}} is acceptable, we write it in as another option (distinct from the BIPM and local styles) TheFeds 22:30, 19 June 2009 (UTC)
-
-
- TheFeds, the BIPM brochure which spells out the quote you gave contains examples where there are more than four digits to the right of the decimal, yet the rightmost group consists of 4 digits. See the number 9.109 3826 (16) × 10−31 kg on page 126. It seems that the BIPM didn't do a very good job of writing the rule that describes what they do in practice (or maybe the translation from French to English isn't very good).
-
-
-
- As for which version at the top of this thread is better, I am not willing to choose between two versions, neither of which describes a fairly popular template ({{tl:Val}}). I think we have to wait to decide what we want to say before we can decide how to say it. --Jc3s5h (talk) 10:50, 20 June 2009 (UTC)
-
-
-
-
- Quite right: I see those examples and wonder what the BIPM was meaning to say. It's not a translation error—the French means the same thing.
-
Cependant, lorsqu’il n’y a que quatre chiffres avant ou après le séparateur décimal, il est d’usage de ne pas isoler un chiffre par un espace.
-
-
-
-
-
- I guess that lends more weight to the idea that we ought to be considering what's good for us, rather than following the convention religiously. TheFeds 17:08, 20 June 2009 (UTC)
-
-
-
-
- I was browsing through the archives on this topic, and came up with several discussions that relate to our current questions:
- Archive 19#Spaces as number separators
- Archive 24#Units section, continued
- Archive 74#Commas in numbers
- Archive 87#Spacing after the decimal point
- Archive 94#Grouping of digits after the decimal point
- Archive 94#Grouping of digits after the decimal point (next attempt)
- Archive 98#{{delimitnum}} template
- Archive 122#WP:ENGVAR and Indian number format (lakh/crore)
- Archive 122#High-precision numbers
- I was browsing through the archives on this topic, and came up with several discussions that relate to our current questions:
-
-
-
- To summarize, in Archive 19 (May 2005), it was suggested that spaces, or better, thin spaces be used. ISO 31-0, BIPM and Chicago were cited. Editors were concerned about technical limitations in browsers (not supporting thin space characters). Objections to spaces included that text-to-speech was affected when used. No consensus, because of technical limitations, however it was agreed that either commas or non-breaking thin spaces were acceptable typographically.
-
-
-
- In Archive 24, as part of a larger discussion on when to use SI vs. regional units, it was suggested that the character be used for digit grouping, due to technical limitations. This didn't really get anywhere, for unrelated reasons.
-
-
-
- In Archive 74, a similar question to the above was posed: should digit grouping exist on the RHS? Consensus was that ISO 31-0 permits digit grouping with thin spaces on the RHS, and would be acceptable, but IE6 did not support them well. Some editors expressed preferences for commas, others for thin spaces (all relating their experience in English-speaking contexts). International preference was for thin spaces.
-
-
-
- In Archive 87, it was suggested that 0.249 592 9 was ugly and unfamiliar. Another editor suggested that it should be permitted, given SI standards, and the goal of reducing ambiguity. There were a few WP:IDONTLIKEIT arguments, with editors advocating against certain regional preferences. Eventually agreed that SI formatting was less familiar, but more readable, especially when using comma-based lists of numbers. Technical limitations again come up, with regard to thin spaces. Ended in proposal to allow either no spaces after decimal point (U.S.), or spaces every 3 places (SI), or no spaces with editors' judgment in special cases. No consensus between those 3 options.
-
-
-
- In Archive 94 (December 2007) the same issues were raised, but with a potential solution to the technical limitation against the use of thin spaces: CSS margins. This was apparently the origin of the proposal to group with commas on the left, and thin spaces on the right (current behaviour of {{val}}). Has advantage of being pasteable into computer programs, while still being readable. Viewed as good technically, and by proponents of allowing SI usage, but some editors still did not support using spaces (ever). Later devolved into personal bickering.
-
-
-
- But later on the same page (Archive 94, February 2008), a more technically-refined version of the previous proposal was made. This addressed details of how wide CSS margins ought to be. This also explained a rationale for using commas on the left, and gaps on the right of the decimal—mainly that Americans were familiar with commas, but that the RHS needs delimiting for readability. It was considered rare that both commas and spaces would exist in a single value, but it was suggested that this was not a problem when it occurred. It was also suggested that WP:MOSNUM policy should reflect a particular formatting style ({{delimitnum}}). In the discussion, there was broad support for a formatting function, but some expressed concern that spaces and commas should not be mixed within a number.
-
-
-
- In Archive 98 (March 2008), more details were given about the implementation of {{delimitnum}}. Here, {{val}} was introduced, as an alternative that didn't perform the spacing. (It would later use {{delimitnum}}'s spacing.)
-
-
-
- In Archive 122 (April 2009), there was a discussion about using the Indian English terms lakh and crore (derived from Hindi, etc.). Some said that these were not appropriate in English usage, others argued that there were many English speakers in India, and that their usage should be respected. It was suggested that the use of these terms be linked. There was no consensus on how to handle digit grouping (which is different in this system).
-
-
-
- Later in 122 (May 2009), concern was expressed that the text of the WP:MOSNUM#High-precision numbers was inadequate. This led to renewed discussion of why MOSNUM advocates commas on the left and spaces on the right, and that {{val}} implements this. Some felt that this compromise (to an unusual format) was better, others felt that it was contrary to any accepted external standards. No consensus was reached.
-
-
-
- One major theme throughout this discussion was that technical limitations (mainly: IE6 did not handle certain Unicode spaces properly) prevented the use of spaces. This was addressed by implementing the CSS gap method, which is apparently well-supported on all major platforms (including modern versions of IE; IE6 is now dated software, and supporting it is not such a critical issue). Similarly, there was the need to paste numerical text from the browser into number-crunching software (e.g. Microsoft Excel). The CSS gaps allow this, whereas thin spaces were unreliable. (Also, on a related note, copying and pasting chunks of text can be affected by the spacing method. By using CSS, the spacing is encoded in the markup, rather than the text; this means that derivatives of Wikipedia will end up with unformatted numbers when quoting it. I don't think this is a big issue.)
-
-
-
- I noticed that there are apparently two schools of thought about formatting numbers: SI is better or U.S. customary is better. (I've already expressed why I prefer SI.) However, given this divide in opinion, with reasonable justifications provided on both sides, it seems logical to suggest both on an equal footing, and leave the choice to the editors. The idea to use the hybrid format (commas on the left, and decimals on the right) in {{val}} and elsewhere apparently originated with Greg L, who advocates it as a compromise. Unfortunately, I (and apparently others, judging by the discussions summarized above), think that it has the disadvantage of satisfying neither camp. I'm personally of the opinion that if we continue to use that format, and people keep wondering about why it exists, and indeed whether it should exist, we invite the very long discussions for which this topic has become known.
-
-
-
- In much the same vein as I wouldn't insist that editors commit to using the de facto "international" standard (the SI), and instead would allow the current U.S./historical British comma-based digit grouping scheme, editors also should have the choice to use (for example) Indian numbering, where the article context is appropriate. If at a future date, Wikipedia wants to standardize on the SI, I wouldn't be opposed to it. But for the moment, I think that the best solution is to avoid prescribing a particular hybrid format in the MOS, and instead allow editors to choose among the two prevailing conventions at will, and to choose an appropriate regional format when the article context would permit it. That's the thinking behind the wording that I used for the MOS.
-
-
-
- So, I've made a couple minor adjustments to the text:
-
- In a number with many digits, digit grouping symbols (inserted at intervals from the decimal point) should be 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 no grouping to the right of the decimal point (e.g. 8,274,527 or 0.12345). This is traditional usage in many English-language contexts.
- 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. The {{gaps}} template uses CSS to produce this output (using the syntax
{{gaps|8|274|527}}). Using HTML entities for this purpose (e.g. or ) may cause rendering problems in some browsers, and should be avoided when practical. - Other traditional digit grouping schemes, when relevant to the subject matter of the article (e.g. 82,74,527 in the Indian numbering system).
- When 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 0.9876 are acceptable).
- In a number with many digits, digit grouping symbols (inserted at intervals from the decimal point) should be used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
-
-
-
- One consideration of this particular phrasing is that it gives equal weight to the alternatives—I think that will keep arguments over which format is most popular to a minimum. Also, the text is not overly prescriptive (this came up previously in the discussions); given that editors may ignore rules that don't improve the encylopedia, it isn't really necessary to insist that edits "must" be a certain way. Combined with the MOS caveat that exceptions sometimes apply, it's appropriate to say that certain things "should" be done. (So instead of saying "things are generally done", as if it's fait accompli, suggest that "things should be done".)
-
-
-
- I'll defer to others' experience with regard to digit grouping using commas on the RHS. It's clear that no RHS grouping is acceptable according to some major style manuals and publications that use commas on the LHS.
-
-
-
- I've retained the four-digit grouping language, because it seems that even the BIPM can't get this straight. The text is a faithful statement of what they prescribe. If someone follows the BIPM's examples (in contrast to the text of their standard) and groups the four rightmost digits of a number with seven digits on the RHS of the decimal, it would seem fair to call that an allowable exception under the MOS. If we want to, it would be straightforward to diverge from the BIPM's text and specifically allow other groupings (per Jc3s5h's suggestion).
-
-
-
- As for {{val}}, {{delimitnum}}, {{scinote}}, etc., judging by the discussions I reviewed, I think the best way to handle them is simply to have them default to SI-style spacing (given that they are designed to handle scientific numbers), with a very simple parameter to allow other styles (U.S., Indian, etc.). The real issue is that essentially nothing endorses the way {{val}} works now—it's a compromise between readability and U.S. convention, and judging by the discussions, that formatting scheme (as distinct from the rest of the issues) never really achieved any sort of consensus—it was just along for the ride as part of the overall project to improve formatting of numbers. (The comments about formatting in that manner were overshadowed by other details, most notably CSS gap widths, but were generally slightly negative.)
-
-
-
- Also, I've looked into the code of {{val}}, and it's straightforward to change; the necessary formatting already occurs on the RHS. SkyLined has suggested creating separate versions of the template for internationalization, but because of the difficulties inherent in supporting multiple sets of code—look at the discrepancies in the {{cite $thing}} templates, for example—we would want to do this in the backend of {{val}}, and make sure users get to see the template documentation as a family. (That discussion can continue at Template talk:Val; for MOSNUM's purposes, I think that's a fair resolution.) I don't know if it's necessary to require a particular template in MOSNUM (too many exceptions would apply), but it would be fine to recommend it (after the changes are made).
-
-
-
- Are there any other aspects of this discussion that I haven't addressed? TheFeds 21:23, 29 June 2009 (UTC)
-
-
-
-
- Excellent. I would have never spent all that time to dig through all those discussions. Thank you. I think the parentheses in the last sentence was supposed to say "e.g. both 9876 and 9,876 are acceptable", right? While we are at it, we might add "although four-digit serial numbers such as years and page numbers are written without spaces or commas". --A. di M. (formerly Army1987) — Deeds, not words. 23:01, 29 June 2009 (UTC)
-
-
-
-
-
-
- I concur with the change. Please consider this case: an article had some integers with five digits on the LHS, and used commas to group digits. A new number is added: 0.12345. Should the revised MOSNUM be read to mean that the article should be revised to use (the appearance of) thin spaces in the integers with five digits on the LHS? —Preceding unsigned comment added by Jc3s5h (talk • contribs) 03:38, 30 June 2009 (UTC)
-
-
-
-
-
-
-
-
- Jc3s5h, if I understand correctly, you're thinking about maintaining consistency, which is definitely an objective from the general WP:MOS. We probably wouldn't need to repeat that instruction here. A. di M., the example of 9876 and 0.9876 was intended to show that we could group four digits on either side of the decimal point. But 9,876 works too (as does 9876). TheFeds 04:33, 1 July 2009 (UTC)
-
-
-
-
[edit] Delinking dates in footnotes
When I see a linked date in a web citation template, such as "|date=April 25, 2004|title=Incomprehensible Emphasis", I feel a strong urge to delink it. I am aware of the proscription of mass delinking of dates, but cannot begin to imagine how any reader can be helped by following the linked date of an article's publishing on the Web, or, even more absurdly, the linked date that some editor accessed that site. I sure hope I don't get into trouble by delinking these, because I fix a lot of articles for other reasons, so a lot of footnote dates might get delinked while I'm at it. Have I missed something? Does anyone have a good reason to keep these links? Chris the speller (talk) 02:01, 19 June 2009 (UTC)
- See this thread regarding what constitutes "mass date delinking" and what is alright. Dabomb87 (talk) 02:11, 19 June 2009 (UTC)
- I guess I'll go with the part that says it's OK if I'm "consciously removing each bracket" and I will "not be primarily focused on delinking". There's an awful lot of quicksand in this area nowadays. Thanks for the link. Chris the speller (talk) 03:21, 19 June 2009 (UTC)
- Yes, it's clear that as long as you're not on a single-minded binge, it's acceptable. Thus, less quicksand now. Criteria that can balance the restriction against "mass" appear to be one or more of the following, going by dabomb's link above:
- delinking as a feature in only a proportion (probably the minority) of the user's edits; and/or
- other article improvement in the edit, aside from the date unlinking; and/or
- generally no appearance of a single-minded drive to unlink dates; and definitely
- politeness if challenged and the avoidance of reverting were date-unlinking to be reverted. Tony (talk) 07:55, 19 June 2009 (UTC)
- Yes, it's clear that as long as you're not on a single-minded binge, it's acceptable. Thus, less quicksand now. Criteria that can balance the restriction against "mass" appear to be one or more of the following, going by dabomb's link above:
- I guess I'll go with the part that says it's OK if I'm "consciously removing each bracket" and I will "not be primarily focused on delinking". There's an awful lot of quicksand in this area nowadays. Thanks for the link. Chris the speller (talk) 03:21, 19 June 2009 (UTC)
Time of access (date) is useful for the purpose to evaluate if the source may have changed. Esp when the source may have an interest in "editing the past" .. Electron9 (talk) 01:56, 25 June 2009 (UTC)
[edit] Date unlinking bot proposal
I have started a community RFC about a proposal for a bot to unlink dates. Please see Wikipedia:Full-date unlinking bot and comment here. --Apoc2400 (talk) 10:18, 22 June 2009 (UTC)
- We have only just finished the last date unlinking proposal. PLEASE don't start another. I oppose even without reading its merits. SimonTrew (talk) 17:36, 23 June 2009 (UTC)
- Please assume good faith on the behalf of the proposer and the proposal. The last RfC had nothing to do with the unlinking of dates; it only concerned the community's opinion on the issues of date linking and autoformatting. The community strongly indicated they were against the linking of dates, so now we're holding an RfC on the implementation of that consensus. Dabomb87 (talk) 17:39, 23 June 2009 (UTC)
-
-
- I do assume good faith. But it will end up in essentially an edit war because people seem incapable of separating date formatting from date(un)linking. If we could keep the two separate I would be more charitable, at least neutral, but I think it will descend into a quagmire of the same arguments as before and it is in my opinion TOO SOON after the previous one finished, with a great amount of good faith. I count myself out. SimonTrew (talk) 18:14, 23 June 2009 (UTC)
- Simon, I'm sorry to hear that you're upset about the bot-running RFC. Please don't be; it's a natural progression from the previous RFCs (which did not concern bots). A number of people who were previously in favour of DA in concept are voting positively for the bot-run, which will be very conservative in scope and management (BAG will make sure of that). ArbCom anticipated this process in its recent Date Delinking judgement. There are a number of safeguards through which linking and DA are distinct concepts. Please ask more on my talk page if you wish, and I'll answer to the limits of my knowledge. Tony (talk) 18:27, 23 June 2009 (UTC)
- I do assume good faith. But it will end up in essentially an edit war because people seem incapable of separating date formatting from date(un)linking. If we could keep the two separate I would be more charitable, at least neutral, but I think it will descend into a quagmire of the same arguments as before and it is in my opinion TOO SOON after the previous one finished, with a great amount of good faith. I count myself out. SimonTrew (talk) 18:14, 23 June 2009 (UTC)
-
-
-
-
-
- I am not upset, and I should have been more explicit in saying I do assume good faith because anyone who tries to make wikipedia better is good by me. Personally I just think it is too soon and you will go round the houses. Parallel arguments go on on the translation pages and elsewhere and, after the roundabouts that have been around this in the last six months on all this (and many misunderstandings that's for sure, not always in good faith) I think I can be more use there than arguing what has been hashed 101 times over the last few years. I keep an eye on MOSNUM and convert template partly because they are very important in some articles I edit and also because I can draw parallels with e.g. how short translations (individual words or phrases within articles) "should" be done, you can imagine the parallel arguments (the French write it like this, the Danes like that, should it be in Indic numerals etc). So yes very much I keep the faith I just think you have an equus de mortuiis that no amount of flagellation will help resuscitate. That being said, if you ever think I can help you on a techincal point or whatever, please don't hesitate to leave a message on my talk page; I don't mind if I am wrong if it helps someone else get it right. SimonTrew (talk) 19:17, 23 June 2009 (UTC)
-
-
-
[edit] Error in the Geographical style section
I noticed that this line appears to be wrong: "negative values may be used in lieu of S and E"
It is my understanding that negative values are generally S and W.
If you agree could you please make the change.
203.206.170.6 (talk) 02:10, 23 June 2009 (UTC)
- There is no error. In the absence of any direction letters (E or W) longitude is measured eastward from Greenwich. So the nominal center of the United States eastern time zone could be given as 75° W, -75°, or 285°. --Jc3s5h (talk) 02:43, 23 June 2009 (UTC)
-
- While of course we can all run around in circles to our hearts' content, and indeed here often do, this does seem to be at odds if it says this-- in the absence of W or E then W is negative from Greenwich (or other longitude). I don't know the section to which the OP refers cos I can't find it in MOS and no reference was given. I looked for it but couldn;'t find it. I mean in theory you can write greenwich as 720 degrees east which indeed it is, this is not useful of course in an encylopaedia but CAN be useful in the internals of computer geographical systems to save constantly having to go modulus on the coordinates. You can't really do this for latitude cos once you hit the pole you could go in any direction equally legitimately. I think OP has a point but I can't find where.
-
- Josh I think you may have missed the point, i.e. that it implies if not explicitly states that negative values go east, which is not true. But I can't find it in MOS.
SimonTrew (talk) 17:28, 23 June 2009 (UTC)
- Fixed. It was intended to mean that −72° means the same thing as 72° W (true), not the same thing as 72° E (false). --A. di M. (formerly Army1987) — Deeds, not words. 20:40, 23 June 2009 (UTC)
[edit] Numbers as figures or words
Editors may find this article offers some historical perspective.LeadSongDog come howl 18:10, 26 June 2009 (UTC)
