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

Archive 145

←

Archive 149

Archive 150

Archive 151

Archive 152

Archive 153

→

Archive 155

Grouping of digits

Acceptable number formats

According to wide-spread use on Wikipedia and in written English in general, and to what seems to be long-standing consensus, there are two basic ways of delimiting numbers: with commas and with thin spaces. Each of these have two variants giving four styles of grouping as follows.

1a) Separate four or more digits to the left of the decimal into groups of three using commas. Don't group digits to the right.

1b) Separate five or more digits to the left of the decimal into groups of three using commas. Don't group digits to the right.

2α) Separate digits both sides of the decimal into groups of three using thin spaces, except that a space should not be added if it leaves a lone digit on the left.

2β) Separate digits both sides of the decimal into groups of five using thin spaces.

It's a well-established principle that grouping style should be consistent throughout a given article but what exactly does this mean? Obviously we don't want one style to the left and another to the right of the decimal point. I think it also goes without saying that if we're using commas we shouldn't use spaces and vice-versa. Also, we should be consistent with regard to whether to delimit exactly four digits to the left. However, since grouping by fives is intended only for numbers with very many digits we should not have to use this style throughout an article simply because we use it once. Therefore consistency would mean a choice between using 1a, using 1b and using one or both of 2α and 2β. Jimp 14:30, 14 April 2015 (UTC)

The current wording

It seems that the above is the intended meaning of the text of Grouping of digits, as posted below.

However, I don't think that this is made clear. By looking at the left and right sides separately it would appear that hybrid styles are allowed. For example, it seems to permit a number with commas to the left and spaces to the right (e.g. 12,345.67890) or spaces to the left and no delimitation to the right (e.g. 12345.67890). To make matters worse, it's suggesting an inconsistent grouping of digits in mathematical articles; digits are allowed to be grouped by fives to the right but not the left of the point (e.g. 12345678.90123456789012345678).

Of course, it should be obvious that delimiting style should be consistent both sides of the decimal point but I don't think that the current text makes it obvious and it should. The problem arises, it seems to me, that the current text doesn't exactly define what a style is (or misdefines it). I don't think that this is just some kind of non-issue; I've seen, for example, a suggestion that MOSNUM is recommending 12,345.67890. So, I'd suggest that the text be rewritten to make it clear what is and what is not acceptable. Jimp 14:30, 14 April 2015 (UTC)

An unreasonable ban on thin spaces

The current text restricts the use of thin spaces (left of the decimal) to scientific/engineering articles. However, I don't believe that this truly reflects use in the real world out there. A few months ago, Dbfirs mentioned that the use of thin spaces for thousands separators is what's taught in British schools. It's also quite normal in Australia. Furthermore, this is the style recommended by the SI.[1] Why, then is MOSNUM suggesting that this style may only be used in scientific/engineering articles? It should be preferred in such articles but allowed in any. Jimp 14:30, 14 April 2015 (UTC)

  is one of the few code points I know by number, but IIRC it doesn't have the "no break" property of   or the also existing "no break hyphen". IOW, just using thin space instead of   might be not good enough, because you certainly don't want a line break within a number. Please correct me if "IIRC" means "not correct" here. –Be..anyone (talk) 12:24, 15 April 2015 (UTC)

Thin spaces are also the standard thousands separator in South Africa, although certain sectors such as the financial press are increasingly using the "American" comma. Roger (Dodger67) (talk) 12:27, 15 April 2015 (UTC)

Perhaps we need "U+202F narrow no-break space   NNBSP" -- see Non-breaking_space#Width_variation. EEng (talk) 13:33, 15 April 2015 (UTC)

Mark up

There are a couple of questionable suggestions regarding mark up. Currently, the text is suggesting the use of {{val/delimitnum}}. This is a subtemplate of {{val}} and as such we shouldn't be encouraging its use in the article space. It also suggests {{gapnum}} but this somewhat obscure template should probably be merged with {{val}}.

There is a hidden comment here which goes "perhaps should say something more re nbsp here since some will hand-code the markup; also, should {{val}} and {{gaps}} use nbsp? (answer may be different left of the point vs right of the point)". I wonder what more we might say about   and, no, neither {{val}} nor {{gaps}} should use   and the answer should be the same either side of the decimal point. Firstly,   is too wide, the spaces should be thin; secondly, as noted,   causes problems for screen readers it also causes problems when copying and pasting numbers into a calculation program (e.g. Excel). Jimp 14:30, 14 April 2015 (UTC)

Proposal

I'm proposing a rewrite of the section to clarify what is and what is not acceptable and where.

Wording as of 16 April 2015:

• Left of the decimal point: Five or more digits should be grouped (and exactly four digits may optionally be grouped) into triples separated by commas (never period/full stop): 12,200;   255,200;   8,274,527;   1,250 (optionally 1250).

• Exception: never group four-digit page numbers or four-digit calendar years (not sailed in 1,492, though 10,400 BC).
• In scientific/engineering articles, long strings left of the point may be grouped into triples without commas: 8274527

• Right of the decimal point: Five or more digits may be grouped into triples without commas: 99.123456.

• In mathematics-oriented articles, digits right of the point may be grouped into fives: 3.14159265358979323846....

Grouping style should be consistent throughout a given article.

Markup: Templates {{val}}, {{val/delimitnum}}, {{gaps}}, and {{gapnum}} may be useful in grouping digits. Use of hard-coded spaces, such as the regular space character, the non-breaking space (  or {{space}}), and the thin space (  or {{thinsp}}), is problematic for screen readers because they read out each group of digits as separate numbers (e.g. 30 000 is read as "thirty zero zero zero").

Proposal:

Former proposals

Initial proposal by Jimp: Digits should be grouped and separated either by commas or thin spaces (never a period/full stop). Grouping with commas Left of the decimal point, five or more digits should be grouped (and exactly four digits may optionally be grouped) into threes separated by commas (e.g.  12,200,  255,200,  8,274,527  and either  1,250  or  1250). Right of the decimal point, do not group digits. Markup: Generally this is hard-coded; however, {{formatnum:}} may be used to produce this formatting in templates. Grouping with thin spaces Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456). Digits are grouped into threes or fives. Digits should generally be grouped into threes; however, right of the decimal point, the final group of digits should not be a single digit. Instead add the final digit to the preceding group (e.g.  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...). This style is especially recommended for articles related to science, technology, engineering or mathematics. Markup: Templates {{val}} or {{gaps}} may be used to produce this formatting. The use of hard-coded spaces, such as the regular space character, the non-breaking space (&nbsp; or {{space}}), and the thin space (&thinsp; or {{thinsp}}), is problematic for screen readers because they read out each group of digits as separate numbers (e.g.  30&nbsp;000  is read as "thirty zero zero zero"). Delimiting style should be consistent throughout a given article. Either use commas or thin spaces. Either delimit exactly four digits left of the decimal point or do not. However, grouping by threes and fives may coexist. An exception is made for four-digit page numbers or four-digit calendar years. These should never be grouped (not  sailed in 1,492,  though  10,400 BC). This is revised below (by EEng & yours truly). The wording "should be" and "do not" becomes "are" and "are not" to emphasise that this is advice for a particular style. "Right of the decimal point, do not group digits." becomes "When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string)." for clarity. Also it's possible that {{formatnum:}} may have uses outside of templates. Jimp 15:46, 14 April 2015 (UTC) Initial revision by EEng: Digits should be grouped and separated either by commas or thin spaces (never a period/full stop). Grouping with commas Left of the decimal point, five or more digits should be grouped (and exactly four digits may optionally be grouped) into threes separated by commas (e.g.  12,200,  255,200,  8,274,527  and either  1,250  or  1250). Never use commas (or any other "non-whitespace" symbol) to group right of the decimal point. Markup: Generally this is hard-coded; however, {{formatnum:}} may be used to produce this formatting in templates. Grouping with thin spaces Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456). Digits are grouped into threes or fives. Digits should generally be grouped into threes; however, right of the decimal point, the final group of digits should not be a single digit. Instead add the final digit to the preceding group (e.g.  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...). This style is especially recommended for articles related to science, technology, engineering or mathematics. Markup: Templates {{val}} or {{gaps}} may be used to produce this formatting. The use of hard-coded spaces, such as the regular space character, the non-breaking space (&nbsp; or {{space}}), and the thin space (&thinsp; or {{thinsp}}), is problematic for screen readers because they read out each group of digits as separate numbers (e.g.  30&nbsp;000  is read as "thirty zero zero zero"). Delimiting style should be consistent throughout a given article. Either use commas or thin spaces. Either delimit exactly four digits left of the decimal point or do not. However, grouping by threes and fives may coexist. An exception is made for four-digit page numbers or four-digit calendar years. These should never be grouped (not  sailed in 1,492,  though  10,400 BC). EEng, no, I don't mind this modification, except that I don't really think that it is what I meant. I'm suggesting that using commas on one side and spaces on the other should not be acceptable. In English, we never write "1,234.123456". Jimp 15:01, 14 April 2015 (UTC) Further revision by EEng: Digits should be grouped and separated either by commas or thin spaces (never a period/full stop). Grouping with commas Left of the decimal point, five or more digits are grouped (and exactly four digits may optionally be grouped) into threes separated by commas (e.g.  12,200,  255,200,  8,274,527  and either  1,250  or  1250). When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string). Markup: Generally this is hard-coded; however, {{formatnum:}} may be used to produce this formatting (useful in templates). Grouping with thin spaces Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456). Digits are grouped into threes or fives. Digits should generally be grouped into threes; however, right of the decimal point, the final group of digits should not be a single digit. Instead add the final digit to the preceding group (e.g.  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...). This style is especially recommended for articles related to science, technology, engineering or mathematics. Markup: Templates {{val}} or {{gaps}} may be used to produce this formatting. the use of hard-coded spaces, such as the regular space character, the non-breaking space (&nbsp; or {{space}}), and the thin space (&thinsp; or {{thinsp}}), is problematic for screen readers because they read out each group of digits as separate numbers (e.g.  30&nbsp;000  is read as "thirty zero zero zero"). Delimiting style should be consistent throughout a given article. Either use , or {{thinsp}}, but not both. However, grouping by threes and fives may coexist. An exception is made for four-digit page numbers or four-digit calendar years. These should never be grouped (not  sailed in 1,492,  though  dynasty collapsed around 10,400 BC). We would rather be contradicting ourselves to suggest using {{thinsp}} considering that we've just suggested not to use {{thinsp}}. We might as well delete "The use of hard-coded spaces ... ( ... 'thirty zero zero zero')." and so, considering to the comments you've made below regarding this, I'm taking the liberty to do so below (I hope you don't mind). Also I'm taking the liberty to add "or  by 13727 AD, the Earth's axial precession will have made Vega the northern pole star" as an example of a year delimited with spaces (I hope you don't mind this either). Jimp 18:32, 14 April 2015 (UTC) Revision by Jimp: Digits should be grouped and separated either by commas or thin spaces (never a period/full stop). Grouping with commas Left of the decimal point, five or more digits are grouped (and exactly four digits may optionally be grouped) into threes separated by commas (e.g.  12,200,  255,200,  8,274,527  and either  1,250  or  1250). When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string). Markup: Generally this is hard-coded; however, {{formatnum:}} may be used to produce this formatting (useful in templates). Grouping with thin spaces Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456). Digits are grouped into threes or fives. Digits should generally be grouped into threes; however, right of the decimal point, the final group of digits should not be a single digit. Instead add the final digit to the preceding group (e.g.  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...). This style is especially recommended for articles related to science, technology, engineering or mathematics. Markup: Templates {{val}} or {{gaps}} may be used to produce this formatting. The use of hard-coded spaces, such as the regular space character, the non-breaking space (&nbsp; or {{space}}), and the thin space (&thinsp; or {{thinsp}}), is problematic for screen readers because they read out each group of digits as separate numbers (e.g.  30&nbsp;000  is read as "thirty zero zero zero"). Delimiting style should be consistent throughout a given article. Either use commas or thin spaces, but not both. Either delimit exactly four digits left of the decimal point or do not. However, grouping by threes and fives may coexist. An exception is made for four-digit page numbers or four-digit calendar years. These should never be grouped (not  sailed in 1,492,  though  dynasty collapsed around 10,400 BC  or  by 13727 AD, the Earth's axial precession will have made Vega the northern pole star). This is more complicated, we'd have to admit, but I'd suggest clarity is necessary and if complexity is the cost of clarity, it's a price we've got to pay. Jimp 14:30, 14 April 2015 (UTC) I think this is a good start, though no doubt there are lots of little mods to be made, and I haven't carefully compared it to the old wording. One comment though, and I will be blunt: I'm tired of hearing how we can't do this or that because "it's problematic for screen readers". It's obvious that hard space is a space. If a screen reader doesn't know that, then fix the goddam screen readers, somebody. EEng (talk) 15:47, 14 April 2015 (UTC) Revision by EEng slightly tweaked: Digits should be grouped and separated either by commas or thin spaces (never a period/full stop). Grouping with commas Left of the decimal point, five or more digits are grouped (and exactly four digits may optionally be grouped) into threes separated by commas (e.g.  12,200,  255,200,  8,274,527  and either  1,250  or  1250). When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string). Markup: Generally this is hard-coded; however, {{formatnum:}} may be used to produce this formatting (useful in templates). Grouping with thin spaces Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456). Digits are grouped into threes or fives. Digits should generally be grouped into threes; however, right of the decimal point, the final group of digits should not be a single digit. Instead add the final digit to the preceding group (e.g.  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...). This style is especially recommended for articles related to science, technology, engineering or mathematics. Markup: Templates {{val}} or {{gaps}} may be used to produce this formatting. Delimiting style should be consistent throughout a given article. Either use , or {{thinsp}}, but not both. However, grouping by threes and fives may coexist. An exception is made for four-digit page numbers or four-digit calendar years. These should never be grouped (not  sailed in 1,492,  though  dynasty collapsed around 10,400 BC  or  by 13727 AD, the Earth's axial precession will have made Vega the northern pole star). The above second (14 April 2015 3:47 pm) revision by EEng has been tweaked a little (see above). There are a couple of issues, though, that I think we aught to address. I hear ya and agree. Yes, the screen readers should be fixed ... but we can't do it. So, we've either got to accommodate them or ignore them. Either way, though, "Either use , or {{thinsp}}, but not both." is a bit unclear since this talks about mark up instead of style. Leaving aside the question of whether they always should be, thin spaces can be produced by <span style="margin-left:.25em"> ... </span> (as used by the templates {{val}} and {{gaps}}) and (at least) sometimes this is the best option (even without considering screen readers). Likewise, various templates (such as {{convert}}) use {{formatnum:}} to give formatting with commas, so we needn't be talking about using ,. So, really it's not a question of how to create the thin spaces ({{val}} vs {{gaps}} vs {{thinsp}} vs &thinsp; etc.) or commas but whether to. I'm suggesting that "Either use commas or thin spaces" gets the point regarding style across better than "Either use , or {{thinsp}}". I'm not sure that there is a case where you'd want to delimit some four-digit-left-of-the-dot numbers and not others. Yes, page numbers and years are an exception but do you not reckon it's clear enough that this is the case according to the wording ... or isn't it? Whilst we're on the topic, how about mailing/shipping addresses, phone numbers, etc.? Jimp 18:32, 14 April 2015 (UTC) Might I suggest this revision for clarity and simplicity: Further revision by sroc: Digits should be grouped and separated either by commas or thin spaces (never a period/full stop). Grouping with commas Left of the decimal point, five or more digits should be grouped into threes separated by commas (e.g.  12,200,  255,200,  8,274,527). Numbers with exactly four digits left of the decimal point may optionally be grouped (either  1,250  or  1250), provided that this is consistent within each article. ... —sroc 💬 03:57, 16 April 2015 (UTC) i.e. split the first bullet point under Grouping with commas in two. Yes, you might. I agree it is simpler and clearer this way. Jimp 05:03, 16 April 2015 (UTC)

• Digits should be grouped and separated either by commas or thin spaces (never a period/full stop).

Grouping with commas

• Left of the decimal point, five or more digits are grouped into threes separated by commas (e.g.  12,200,  255,200,  8,274,527).
• Numbers with exactly four digits left of the decimal point may optionally be grouped (either  1,250  or  1250), provided that this is consistent within each article.
• When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string).
• Markup: Generally this is hard-coded; however, {{formatnum:}} may be used to produce this formatting (useful in templates).

Grouping with thin spaces

• Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456).
• Digits are grouped into threes or fives.

• Digits should generally be grouped into threes; however, right of the decimal point, the final group of digits should not be a single digit. Instead add the final digit to the preceding group (e.g.  99.1234567).
• For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).

• This style is especially recommended for articles related to science, technology, engineering or mathematics.
• Markup: Templates {{val}} or {{gaps}} may be used to produce this formatting. The use of hard-coded spaces, such as the regular space character, the non-breaking space (  or {{space}}), and the thin space (  or {{thinsp}}), is problematic for screen readers because they read out each group of digits as separate numbers (e.g.  30 000  is read as "thirty zero zero zero").

• Delimiting style should be consistent throughout a given article.

• Either use commas or thin spaces, but not both.
• Either delimit exactly four digits left of the decimal point or do not.
• However, grouping by threes and fives may coexist.

• An exception is made for four-digit page numbers or four-digit calendar years. These should never be grouped (not  sailed in 1,492,  though  dynasty collapsed around 10,400 BC  or  by 13727 AD, the Earth's axial precession will have made Vega the northern pole star).

Discussion

ordinals, numerators, denominators and non-base-ten numbers

There is some reading between the lines to be done here. Firstly, I would take it as given that if there is no decimal point that the left-of-the-point rules apply (e.g.  "123456"  or  "98,765"). Secondly, the rules apply to ordinals as well as numerals (e.g.  "the 1010th day of the human totem pole"  or   "the 12,000th contestant"), to quantities (e.g.  "1234 kg" or  "1,250 ml") and to numerators and denominators of a fraction (e.g.  "1234+1234⁄5678"  or  "4,321+7,654⁄9,876"). Thirdly, that this applies to base-ten representations of numbers (e.g. not binary  "101110001"  or hexadecimal  "12A,F09,7E2"). Should we bother making any of this explicit? Jimp 20:03, 14 April 2015 (UTC)

Good idea. Maybe just include these as examples?

• Digits should be grouped and separated either by commas or thin spaces (never a period/full stop).

Grouping with commas

• Left of the decimal point, five or more digits should be grouped into threes separated by commas (e.g.  12,200,  255,200 km,  8,274,527th,  12,345+34,567⁄67,890).
• Numbers with exactly four digits left of the decimal point may optionally be grouped (either  1,250  or  1250), provided that this is consistent within each article.

...

—sroc 💬 05:27, 16 April 2015

... or something like

• Digits should be grouped and separated either by commas or thin spaces (never a period/full stop).

Grouping with commas

• Left of the decimal point, five or more digits are grouped into threes separated by commas (e.g.  12,200,  255,200 km,  8,274,527th,  1⁄3,600).
• Numbers with exactly four digits left of the decimal point may optionally be grouped (either  1,250  or  1250), provided that this is consistent within each article.
     ...

Grouping with thin spaces

• Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456,  520.01234 °C,  1010th,  ⁠101325/760⁠).
     ...

Jimp 07:35, 18 April 2015 (UTC)

Looks good, except that the fraction example needs to have at least five digits in the numerator and/or denominator for the rule to apply (1⁄36,000 requires a comma but 1⁄3600 doesn't). —sroc 💬 15:04, 18 April 2015 (UTC)

Can I also suggest collapsing the three- and five-digit grouping points?

• Digits should be grouped and separated either by commas or thin spaces (never a period/full stop).

Grouping with commas

• Left of the decimal point, five or more digits are grouped into threes separated by commas (e.g.  12,200,  255,200 km,  8,274,527th,  1⁄86,400).
• Numbers with exactly four digits left of the decimal point may optionally be grouped (either  1,250  or  1250), provided that this is consistent within each article.
  ...

Grouping with thin spaces

• Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456,  520.01234 °C,  1010th,  ⁠101325/760⁠).
• Digits should generally be grouped into threes—however, right of the decimal point, the final group of digits should not be a single digit; instead add the final digit to the preceding group (e.g.  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).
  ...

—sroc 💬 15:15, 18 April 2015 (UTC)

Good point regarding 1⁄3,600; yes, 1⁄86,400 is probably better. Also, it seems clear enough with the threes and fives collapsed but perhaps we could swap "should ... be" for "are". Jimp 22:55, 18 April 2015 (UTC)

Grouping with thin spaces

• Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456,  520.01234 °C,  1010th,  ⁠101325/760⁠).
• Digits are generally grouped into threes—however, right of the decimal point, the final group of digits should not be a single digit; instead add the final digit to the preceding group (e.g.  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).
     ...

Left vs right

General comments:

• I find commas to left and spaces to the right jarring; but I also find commas to the left and no spaces to the right jarring, if there are (say) 6 or more digits to the right. I'm not sure what to suggest.
• As for "consistency", something I'm usually in favor of: I don't see a need for consistency between display of "small" integers (say, less than 10⁶) and long mathematical constants (20+ digits). I'm not sure how to express the idea that display should be generally consistent, but there are reasonable exceptions. Possible example of problems, without checking whether there actual problems, would be the article on the trajectory of the Earth's axis, which might include 5-digit years (for which I would prefer commas) and precession and nutation coefficients which might be accurate to more than 10 decimal places.
• I think we should take a stand against spaces or commas in fraction numerator or denominators when using the {{frac}} template; any such article should be mathematical, so the {{frac}} template is discouraged

I'm on a smartphone, so placing these comments in the correct subsection is difficult. As a tax preparer, this is not a good time for me. But I'm on the train on my way to fill out some forms for my wife's doctor's appointment, so I have a little time to comment. — Arthur Rubin (talk) 16:17, 15 April 2015 (UTC)

Perhaps you could post your wife's X-rays and diagnosis when they're available. EEng (talk) 16:44, 15 April 2015 (UTC)

Concerning spaces in fractions, you may like Thnidu's examination of the problem at Talk:Torr#fraction format and his eventual triumph. NebY (talk) 17:02, 15 April 2015 (UTC)

Can anyone refer us to any style guides or standards, or even textbooks, that provide rules or guidance on this? NebY (talk) 17:13, 15 April 2015 (UTC)

Thousands separators are addressed in some detail by the International System of Quantities. The international standard is thin spaces to left and right of the decimal marker. Wikipedia prefers to ignore the international standard and invent its own rules. Dondervogel 2 (talk) 17:57, 15 April 2015 (UTC)

The US Government Printing Office Style Manual calls for commas to the left of the decimal and spaces to the right; see the top of page 272. Jc3s5h (talk) 18:08, 15 April 2015 (UTC)

@Dondervogel 2:Really? The International System of Quantities concerns quantities such as the base quantities length, mass, time, electric current, thermodynamic temperature, amount of substance and luminous intensity. I don't believe it's concerned with the representation of numeric values. ISO may well publish an international standard that covers typographical representation of numerical quantity values and I'd be glad to know what it is and what it says - it just won't be the ISQ. NebY (talk) 18:24, 15 April 2015 (UTC)

Page 27 of ISO 80000-1:2009 contains the following text

• To facilitate the reading of numbers with many digits, these may be separated into groups of three, counting from the decimal sign towards the left and the right. No group shall contain more than three digits. Where such separation into groups of three is used, the groups shall be separated by a small space and not by a point or a comma or by any other means.

EXAMPLE 1 1 234,567 8 rather than 1 234,5678 0,567 8 rather than 0,5678

• In the case where there is no decimal part (and thus no decimal sign), the counting shall be from the rightmost digit towards the left.

EXAMPLE 2 In the number “1 234”, the right-most digit is that underlined.

• The separation into groups of three should not be used for ordinal numbers used as reference numbers, e.g. ISO 80000-1.
• The year shall always be written without a space, e.g. 1935.
• A plus or minus sign before a number (or a quantity), used to indicate “same sign” or “change of sign”, is a monadic operator and shall not be separated from the number by a space (see Example 3). However, for operations, signs and symbols, there shall be a space on both sides of the sign or symbol, as shown in the examples given in Example 4. See also 7.1.3. For signs denoting a relation, such as =, < and >, there shall also be a space on both sides.

EXAMPLE 3 A Celsius temperature from −7 °C to +5 °C.

EXAMPLE 4 5 + 2 5 − 3 n ± 1,6 D < 2 mm > 5 mm"

Dondervogel 2 (talk) 18:56, 15 April 2015 (UTC)

• These are enlightening and may very well help us decide what our MOS should say, but please, no more talk of "the" international standard. There's no such thing. It's nonsense. EEng (talk) 19:27, 15 April 2015 (UTC)

The US Government Printing Office Style Manual doesn't have the luxury of dealing with the issue on an article-by-article basis. It seems that they're attempting to create some kind of compromise by hybridising the "traditional" (commas left and no grouping right) with the "modern" (spaces either side) and, I'd assume, they're hoping that this doesn't produce too many jarring juxtapositions of the two. At Wikipedia, on the other hand, we're free to chose one or the other as appropriate to the topic at hand. On a page where it's advantageous to delimit digits after a decimal point, the most sane thing to do would be to use spaces either side (not Frankennumbers like  "987,654,321.123456789").

I would not think that treating numbers differently according to whether they are followed by a unit of measure or not (e.g. "7,845 entrants ran the 14000-metre course from Hyde Park to Bondi Beach") would be good writing style. Moreover, the ISQ deals with SI units, so you might argue that spaces be used if and only if followed by an SI unit (e.g. "3776.24 m (12,389 ft)"). Surely, inconsistency like this is something we wouldn't want. Perhaps choice between commas and spaces might be influenced by whether there is a predominance of quantities on the page in question but we should consistently use one of the other.

I too find commas to left and spaces to the right jarring, we never use this in English (I doubt even US Government Printing Office publications would do this in spite of a literal interpretation of their style manual). If commas to the left and no spaces to the right (if there are enough digits to the right) is also jarring, then spaces both sides would be an obvious solution. Large numbers of digits after a decimal point is a pretty good indication that the topic is a bit of a technical one anyway so using spaces shouldn't generally be a problem.

With respect to grouping I would not advocate consistency between long and short (in terms of number of digits) numbers. It makes perfect sense (as I see it) to reserve grouping by fives to the longer numbers. I'm not sure whether we need put a specific number on it but if we were to, perhaps 15 digits on one side and/or the other of the decimal point might be good. However, we never group by fives using commas (not in standard English) so grouping by fives should be done with spaces. If we're using spaces to group digits in long numbers, it would seem natural to do so for short ones on the same page. Again, we shouldn't expect to run into long numbers except on technical pages so using spaces should be fine here too. I'd like to mention again, though, that it would only be sensible to be consistent within the one number: we should never group by fives on one side of the decimal point and by threes on the other.

As for long numbers in numerators and denominators, using {{sfrac}} instead of {{frac}} as on Torr (mentioned above) should generally solve any issues here.

Jimp 04:57, 16 April 2015 (UTC)

Four-digit numbers

I read in a guide many moons ago that commas in four-digit numbers were optional but should be included in a list with other numbers with commas, e.g.:

• 123; 4,567; 7,890 or 123; 4567; 7890
• 1,234; 4,567; 78,900 but not 1234; 4567; 78,900

I think this was especially jarring in mathematical sums, e.g.:

YCorrect:	NIncorrect:
1,234 4,567 + 78,900 ———————— 84,701	1234 4567 + 78,900 ———————— 84,701

Should we include guidance on this? —sroc 💬 05:37, 16 April 2015 (UTC)

The same would go for tables too.

YCorrect:	NIncorrect:
1,234	1234
4,567	4567
78,900	78,900
84,701	84,701

I'd agree with this. The question is whether then other numbers on the page should follow suit. I'd say it would be best if they did. Jimp 07:29, 16 April 2015 (UTC)

• I'll need time to catch up on the intervening discussion, but on this last bit... Please, we don't need to specify absolutely everything -- we can rely to some extent (maybe even a lot) on editors' good sense. I would really prefer we not go so far as to rigidly insist that all four-digit numbers be treated the same way throughout an article, and for tables and so on, we might just mention that alignment should be considered. I think the following is fine, for example:

1234 4567 1234 4567 1234 4567 1234 4567 1234 4567 1234 + 4567 ———————— 123,701

— Preceding unsigned comment added by EEng (talk • contribs) 16:39, 16 April 2015

Well I don't (think it's fine). Perhaps it is browser related but the columns are out of alignment on my screen. Jimp's version is clearer. Dondervogel 2 (talk) 16:48, 16 April 2015 (UTC)

(I've changed the example slightly to emphasize what I'm about to say.) If you mean that the comma in the total is directly below the thousand's place in the addends, yes, that's intentional, because maybe where there are a lot of little 4-digit addends, adding to a big 5- or 6-digit number, you might not want the clutter of commas in all the addends, but want the comma in the sum. I really think we should be leaving little choices like this to the editors of individual articles -- let them decide what looks best, and put something in MOS only when it's clearly needed because of it keeps coming up as a problem in multiple articles. EEng (talk) 17:10, 16 April 2015 (UTC)

Perhaps this kind of thing would be best dealt with elsewhere, like a section on aligning digits in tables etc. (note, though, that calculations like the aboves aren't going to be common); then let people figure it out themselves. Too many mini rules have the potential to cloud this guidance. Also, if we're going to talk about the alignment of digits, we'd have to deal with the problem of varying numbers of digits after the decimal point like in the example below.

Japanese unit			Metric	Imperial/US
romanised name	character	tsubo	square metres	square inches	square feet	square yards
shaku	勺	1⁄100	0.03306	51.24	0.3558	0.03954
gō	合	1⁄10	0.3306	512.4	3.558	0.3954
jō	畳	1⁄2	1.653	2562	17.79	1.979
tsubo	坪	1	3.306	5124	35.58	3.954
bu	歩	1	3.306	5124	35.58	3.954
se	畝	30	99.17	1.537×105	1067	118.6
tan	段, 反	300	991.7	1.537×106	1.067×104	1186
chō	町, 町歩	3000	9917	1.537×107	1.067×105	1.186×104

Jimp 17:39, 16 April 2015 (UTC)

Yes, I agree this kind of detail is best left to editors. A note providing general advice on alignment would address my concern. Dondervogel 2 (talk) 17:57, 16 April 2015 (UTC)

Good, and let's put additional considerations involving tables on hold for now, if I may suggest. EEng (talk) 18:06, 16 April 2015 (UTC)

Four-digit grouping on the right

Jimp's proposal says:

Digits should generally be grouped into threes; however, right of the decimal point, the final group of digits should not be a single digit. Instead add the final digit to the preceding group (e.g.  99.1234567).

This is new; the current guideline does not provide for four-digit groups, much less say that a single-digit group "should not" be used. As Dondervogel 2 has pointed out above, ISO 80000-1:2009 advocates three-digit groups and makes no allowance for a final four-digit group.

I have no objection to allowing a final four-digit group, but think this should probably be optional, e.g.:

Grouping with thin spaces

...

• Digits should generally be grouped into threes. Right of the decimal point, the final group of digits may include four digits to avoid having a single digit after a gap (e.g. 99.1234567 or 99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).

...

Note the use of "may" in the above wording. —sroc 💬 15:46, 18 April 2015 (UTC)

It may seem new but it's actually quite old. It dates back to 2008 when thin-space formatting was introduced and remained part of the guideline until only last year. It's pretty much been the norm on WP ever since we've been using space formatting. {{Val}} has been formatting numbers this way almost ever since its creation. {{Gapnum}} also uses this style. So, really not following the rule would be new; not only new but it would potentially lead to style clashes on pages which use {{val}} and/or {{gapnum}}. Jimp 18:46, 18 April 2015 (UTC)

Thanks. I thought this was familiar and was surprised not to find it in the current wording. In any case, should it be a "may" rather than a "should"? —sroc 💬 19:43, 18 April 2015 (UTC)

May it be a "should" rather than a "may"? Jimp 20:44, 18 April 2015 (UTC)

That that is is that that is not is not is that it it is. —sroc 💬 20:47, 18 April 2015 (UTC)

The real question is: Can can can can can can can can can can? —sroc 💬 20:50, 18 April 2015 (UTC)

To be honest, I'd have to admit that I'm a little in two minds about it. Of course, we don't want to be too strict and stifle creativity by too many rules but adding yet another formatting style by switching "may" for "should" is not without its problems. Firstly, people come to the MOS for advice on what the standard style is; having too many options leaves us unenlightened. Secondly, the more options there are the less consistency we get. Thirdly, to accommodate the various options templates become more and more complicated making their code harder to read and write, pushing up their load time and entailing that fewer of them can be used on a page before we hit the template limits. So, unless there is a good reason to make this optional, I wouldn't be in favour of doing so. That said, though, perhaps there is a good reason. We'd prefer to have digits line up vertically in a table and this won't always be possible if we insist that this rule always be followed. So, instead of a "should" or a "may" perhaps a "generally" would be best. Perhaps something like this ... Jimp 22:09, 18 April 2015 (UTC)

• Digits are generally grouped into threes. Right of the decimal point, having a single digit after a gap is generally avoided by including four digits in the final group (e.g.  99.1234567  or  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).

... or like this. Jimp 22:37, 18 April 2015 (UTC)

• Digits are generally grouped into threes. Right of the decimal point, usual practice is to avoid having a single digit after a gap; so, the final group may include four digits (e.g.  99.1234567  or  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).

Revision by EEng:

• Digits are generally grouped into threes. Right of the decimal point, usual practice is to have final group of four instead of a final lone digit (e.g.  99.1234567  or  99.1234567). In mathematics-oriented articles long strings right of the point may be grouped into fives (e.g.  3.14159265358979323846...).

You guys are moving too fast for me to keep up given other stuff I've got on my plate, but I like the apparent progress. Jimp, since there's been no comment on your last version I've made some adjustments which you should feel free to revert. Also, in the group-by-5 style, should there be a special provision for "6 at end instead of isolated digit"? And is the ... at the end of the "math" example really needed? If not, it's confusing. EEng (talk) 01:00, 19 April 2015 (UTC)

I'd make three points.

• Your wording does seem to read better than mine.
• I'm not sure why we'd want to restrict grouping by fives only to the right of the decimal point (a recently introduced idea). If grouping by fives is okay on one side, why not the other? Suppose we have a number with many digits on both sides, would we really want to group by threes on one side and fives on the other of the very same number (e.g.  123456789012345.678901234567890)?
• Allowing for an optional (or even a compulsory) group of six when (otherwise) grouping by fives, it seems to me, just makes things that much more complicated. It might be a solution for a problem which doesn't exist; how often is this going to occur? Also, unlike the analogous provision when grouping by threes, it doesn't seem to draw from actual practice in the real world.

So, how about this? Jimp 02:00, 19 April 2015 (UTC)

• Digits are generally grouped into threes. Right of the decimal point, usual practice is to have a final group of four instead of a lone digit (e.g.  99.1234567  or  99.1234567). In mathematics-oriented articles long strings may be grouped into fives (e.g.  3.14159265358979323846...).

I'm just guessing, but I suspect that if there's any grouping done on the left, it's always by threes, because the notion of 1000s, millions, billions, etc. is so universal. I wouldn't be surprised to see threes on the left and fives on the right, but again I'm just guessing. I think we need someone to dig up some actual examples in the wild. Again, this is all going too fast for me but maybe in the next few days I can catch up. Please, though, try to remember my usual advice that MOS shouldn't opine on things that editors have been able to, or are likely to, be able to decide for themselves on individual articles. (The threes-on-left-with-fives-on-right dilemma may be an example. Maybe we should say nothing about whether or not 3s can be combined with 5s, and editors faced with the question will have sources available to act as examples for them.) EEng (talk) 03:48, 19 April 2015 (UTC)

I'm inclined to agree with you. I see your point about grouping on the left's being naturally by threes in a way the grouping on the right isn't, so maybe banning  123456789012345.678901234567890 isn't the way to go after all. On the other hand, though, we might also say that it's natural to group digits consistently on both sides, so banning  123456789012345.678901234567890 doesn't seem right either. I'd be happy to have MOSNUM keep silent about whether one is preferable to the other and which that might be at least until it ever becomes an issue or until we do have a clearer picture as to what the actual practice out there is. As for the idea that "MOS shouldn't opine on things that editors have been able to, or are likely to, be able to decide for themselves on individual articles", yes, generally speaking, this pretty much goes without saying. Jimp 05:23, 19 April 2015 (UTC)

A specimen found in the wild

Look at Heegner number, which foregoes any spacing on the right, and sometimes on the left (262,537,412,640,768,743.99999999999925...;  640320³ + 744 − 0.00000000000075). I think failing to group the digits makes it particularly hard to read (i.e., count the repeated digits), but there may be special reasons to do this. Do we take any examples of this or treat this as exceptional? —sroc 💬 12:05, 19 April 2015 (UTC)

I meant someone should look at some article in math / physics / astro journals. EEng (talk) 14:41, 19 April 2015 (UTC)

I'd be guessing that the special reason to do this is sloppiness. Heegner number, like any article, is a work in progress, so I don't think we can necessarily take how things happen to be done there as the way things should be done. There's always room for improvement. Jimp 12:39, 19 April 2015 (UTC)

Here's what the article would look like if numbers were formatted. It's a whole lot more readable. However, when I was over there I noticed a hidden comment "don't put thousands separators under <math>!". I cannot, however, think of any valid reason to make an exception for numbers that happen to be produced using <math>. My guess is that whoever was insisting on this was labouring under the misapprehension that thousands separators within <math> are going to produce spaces after the comma like <math>262,537,412,640,768,743.99999999999925</math> would but <math>262{,}537{,}412{,}640{,}768{,}743.99999999999925</math> (as used on the page in spite of this insistence) gives normal comma formatting and <math>262\,537\,412\,640\,768\,743.999\,999\,999\,999\,25</math> gives thin spaces. I've raised the issue on the talk page. Jimp 13:23, 19 April 2015 (UTC)

A little digging around and I believe I've found the answer. It was just as I'd expected, <math>262,537,412,640,768,743.99999999999925</math> puts spaces after the commas which is undesirable. So, it's not that thousands separators shouldn't be used in <math> but merely that people should take the time to look up how to do this properly. Thus, the special reason seems to be that nobody bothered to read Help:Math ... which could be called sloppiness. Jimp 14:01, 19 April 2015 (UTC)

Should we mention formatting mark up when using <math>? Jimp 14:06, 19 April 2015 (UTC)

For the specific question of math/physics/etc. (especially very long numbers unlikely to arise in articles on general topics) why don't we raise the issue at project Math or whathaveyou? EEng (talk) 14:41, 19 April 2015 (UTC)

I must say, even after skimming Help:Displaying a formula (WP:MATH) and searching in vain for "comma", I couldn't find any advice on this. This may be worth raising on that talk page and/or Wikipedia talk:WikiProject Mathematics. —sroc 💬 17:22, 19 April 2015 (UTC)

Wikipedia:Manual of Style/Mathematics (MOS:MATH) also addresses formatting formulae but doesn't clearly explain what to do with commas; worth raising on that talk page, too. I suggest that's the most appropriate place to raise this issue and link from the MOS:MATH and WikiProject talk pages to that discussion. —sroc 💬 17:26, 19 April 2015 (UTC)

In direct response to the question "Should we mention formatting mark up when using <math>?" I don't think we need to overload MOS:NUM with this; it belongs at MOS:MATH and/or WP:MATH where <math> is already covered and will find a more relevant audience. —sroc 💬 17:33, 19 April 2015 (UTC)

Year in article head

Articles for Bandy World Championships have recently been moved from (e.g.) Bandy World Championship 2015 to 2015 Bandy World Championship. Is this due to some rule in the Manual of Style which I can't find? Skogsvandraren (talk) 14:13, 19 April 2015 (UTC)

Sorry, definitely not our department. (We're in charge of whether the year has a comma in it.) Why not ask User_talk:Shirt58, who made the move you linked here? EEng (talk) 00:25, 20 April 2015 (UTC)

How to write January 1, 1

There is a discussion at Talk:Julian day#Timestamp column about whether January 1, 1, should be written Jan 1, 1 in a table. User:Be..anyone would like to write it Jan 1, 0001. Jc3s5h (talk) 22:19, 24 April 2015 (UTC)

Subject to the approval of my esteemed fellow editors, I've added [2] an entry to the dos-and-don'ts table re not zero-padding years. For the record, please comment even it it's just a support. Notice that, since we've got that numbskull provision that YYYY-MM-DD can't be used before 1583, the question is moot for the one place zero-padding might actually make sense i.e. the YYYY in YYYY-DD-MM. EEng (talk) 23:33, 24 April 2015 (UTC)

We can't seem to agree if ISO 8601 applies to dates in the YYYY-MM-DD format. I think I found a few vague diffs from near the founding of Wikipedia hinting that it did, but I didn't stash them in a safe place. If we don't declare what standard applies, who is to say the way to write January 1, 1 in the all-numeric format isn't 1-01-01? Jc3s5h (talk) 23:53, 24 April 2015 (UTC)

Support but I think it would be more helpful to comment on the talk pages of Julian day, Rata Die, where this format has been introduced by User:Be..anyone. Jc3s5h (talk) 23:41, 24 April 2015 (UTC)

A few more supports here and that debate will be moot (at least the zero-pad part of it). EEng (talk) 23:48, 24 April 2015 (UTC)

Support, of course. That said, I would not write "January 1, 1", just as I would not write "2004-05" for "May 2004", as it's a confusing and ambiguous construction. – Jonesey95 (talk) 23:57, 24 April 2015 (UTC)

What would you suggest for that somewhat unusual situation? – perhaps January 1, 1 AD? EEng (talk) 02:17, 25 April 2015 (UTC)

I would suggest avoiding it. It's very much a hypothetical date, isn't it? I don't think it even makes sense to write it down. Nobody was watching the ball drop with Dick Clark or arguing about which year was the first year of the new millennium on that particular day, I suspect. I read the discussion on the linked talk page, and it looks like a morass to me. And that's from someone who watches this page.... – Jonesey95 (talk) 04:17, 25 April 2015 (UTC)

Indeed a shocking indictment! However, in a technical discussion you might want to say something like days since January 1, 1 AD. I just thought the AD would help the reader parse. EEng (talk) 10:46, 25 April 2015 (UTC)

Cambridge University Press saw fit to publish Dershowitz and Reingold's Calendrical Calculations (several editions, in fact) and that book does contain it (see p. 15 of the 3rd ed. as an example). So Jonesey95's suggestion that there is no need to write it down is dashed to smithereens. Jc3s5h (talk) 11:19, 25 April 2015 (UTC)

OK, but please, let's keep the rhetorical smithereen-smashing to the talk pages of the articles in question. EEng (talk) 11:23, 25 April 2015 (UTC)

• Support. And I believe I would, as a rule, always use AD/BC/CE/BCE on one- or two-digit years to make them easier to parse. The first barrier is making it understood that it is in fact a year, and to my mind "January 1, 1" and "1 January 1" probably fail on that. Kahastok talk 11:41, 25 April 2015 (UTC)

I think what's going on here is that the brain tends to parse a one- or two-digit number as a day-of-month, so there's a moment of brain-freeze when confronted with January 1, 1 or 1 January 1. I've made another bold edit [3], subject to the approval of my esteemed fellow editors. EEng (talk) 12:09, 25 April 2015 (UTC)

I support this change. Kahastok talk 19:55, 26 April 2015 (UTC)

Using AD/BC/CE/BCE for any year less than 100 AD wherever there is potential confusion (i.e. in most cases) seems the most sane approach. Zero padding is just something we don't do when writing dates in normal English (in though yyyy-mm-dd we would might). Jimp 08:45, 26 April 2015 (UTC)

We would write January 1, AD 1 as 0001-01-01 if we had adopted a standard telling us what to do so. If we ever allowed dates in that format before 1583 we would have to adopt a standard or make up our own telling editors what to do. Jc3s5h (talk) 15:52, 26 April 2015 (UTC)

It is not obvious to me (other than based on context) that "0001-01-01" is even a date. But I have never been happy with the YYYY-MM-DD format at all, because it takes that much longer to parse at the best of times, compared with the "26 Apr 2015" format that does not require significantly more space. Kahastok talk 19:55, 26 April 2015 (UTC)

In practice I don't think this is likely to be a problem. It's a rare occasion when you'll see dates from before 1583 in a table, for example. In most instances where it comes up, I'd say just leave it to the intelligence of the editors working on the article. Adding BC/AD/BCE/CE to disambiguate years close to 1 AD is pretty commonsense and should not be controversial. Archon 2488 (talk) 14:10, 27 April 2015 (UTC)

Violating my exhortation below... the funny thing about YYYY-MM-DD is that, if we allowed e.g. 27Apr2015 (without spaces) that would actually be as or more compact horizontally than 2015-04-27 -- compactness being the primary argument for YYYY-MM-DD (sort-ability being handled another way). Check it out:

27Apr2015

2015-04-27

Results would be slightly different for different particular values, but I double DDMMMYYYY would ever be wider than YYYY-MM-DD. EEng (talk) 15:31, 27 April 2015 (UTC)

It's harder to parse and not very aesthetically pleasing without spaces. I think that's more important than saving a tiny bit of space at the edges; space isn't at that much of a premium on our pages, surely. Archon 2488 (talk) 16:12, 27 April 2015 (UTC)

Well, space does matter in e.g. tables. I agree 25Apr2015 isn't very nice-looking, but I'm just pointing out it's as nice-looking, or nicer, than 2015-04-25, and as or more compact. I'm not advocating either. EEng (talk) 16:57, 27 April 2015 (UTC) Why the hell am I fanning the flames of this conversation?

YYYYMMDD satisfies this new criterion of compactness while remaining eminently sortable - e.g. 20150427. I'm grateful to EEng for so gently leading us to this conclusion which I am sure will satisfy everyone. NebY (talk) 16:43, 27 April 2015 (UTC)

Oh, fuck. What have I done? EEng (talk) 16:57, 27 April 2015 (UTC)

It's also language neutral. Dondervogel 2 (talk) 17:42, 27 April 2015 (UTC)

All online references for this special date in tables on two pages use 1 January 0001 or 0001-01-01 (+time where discussed.) I haven't read the book. Trivia, if I understood it correctly the Go (programming language) manual claims that it is perfectly okay to consider 0 as invalid or undefined, because nobody would ever need this date. Nobody outside of MOS talk pages. –Be..anyone (talk) 22:50, 27 April 2015 (UTC)

EEng, yes, what have you done? No, "25Apr2015" isn't nice-looking, though nicer than "2015-04-25", but as far as compactness is concerned, the normal "25 Apr 2015" or even "Apr 25, 2015" is perfectly adequate. If there really is ever a situation where we're so pressed for space, we could use a line break or even two: 25&nbsp;Apr<br />2015 or 25<br />Apr<br />2015. Dates written like this would be perfectly readable and be far better at squeezing into a narrow column though they would take up more horizontal space.

As for "20150425", well, this is simply unreadable; "2015-04-25" is unreadable enough as it is without leaving the hyphens out.

I agree with Archon 2488, I don't believe we'll ever be faced with a situation in which it would be worth sacrificing readability for the sake of saving a character or two in the width of a date.

Yes, "2015-04-25" (and "20150425") are language neutral being equally foreign to all of us. We might as well advocate spelling "neighbour" as "naber", "colour" as "culler", "litre" as "leter", etc.

Sortability is a non-issue; we have {{dts}}. Jimp 02:57, 29 April 2015 (UTC)

I can't think of any good reason to use yyyy-mm-dd at all on WP. Jimp 01:00, 27 April 2015 (UTC)

DON'T ANYBODY RESPOND TO THAT. NO. NO ONE. WE'VE ALREADY BEEN TO HELL AND BACK ON THIS ONE. EEng (talk) 01:37, 27 April 2015 (UTC)

Yes, we have gone off-topic somewhat and it would be better to save the perennial date formatting debate for another day. As Jc3s5h points out, yyyy-mm-dd is not permitted for dates before 1583, so whether or not years could have leading zeros in that format is moot. In normal English-language date formats (i.e. dmy and mdy), we don't add leading zero either. So, I'd say the only sane ways to write the date in question would be "1 January 1 AD", "1 Jan 1 AD", "January 1, 1 AD", "Jan 1, 1 AD", "1 January 1 CE", "1 Jan 1 CE", "January 1, 1 CE" or "Jan 1, 1 CE". Jimp 02:57, 29 April 2015 (UTC)

Conversation at WT:MoS about making that talk page the official site for style questions

The proposed style noticeboard has fallen through. There is now a conversation under way at WT:MoS about endorsing and centralizing its longstanding Q&A function. This would include encouraging users to ask questions about style and copyediting either at WT:MoS or a subpage and not at other talk pages. The discussion is still very preliminary and participants from other pages that would be affected are very welcome. Darkfrog24 (talk) 16:03, 5 May 2015 (UTC)

MOS:NUMERAL

The guideline currently states:

"Integers greater than nine expressible in one or two words may be expressed either in numerals or in words".

Is the spirit of limiting this to one or two words designed to force editors to use numerals for two hundred and fifty and similar numbers? RO^(talk) 21:49, 11 May 2015 (UTC)

I believe so. An exception would be if a product or something is specifically spelled out. Not to be a wise ass, but I believe the correct wording for your example is two hundred fifty, like if writing a check.—Iknow23 (talk) 03:43, 12 May 2015 (UTC)

Perhaps this is one of many differences between US-UK-AUS English, but I was taught to write "two hundred and fifty". Dondervogel 2 (talk) 06:12, 12 May 2015 (UTC)

I generally spell out numbers up to ten (or at the start of sentences), which is supported by various Australian style guides:

• Australian National University advises: "Within regular prose, numbers one to nine should be spelt out and 10 and above should be numerals."
• University of Technology Sydney advises: "spell out one to nine and use numerals for 10 and above"
• University of Western Australia advises: "Numbers from one to nine are written as words. Numbers 10 and above are written in digits except when starting a sentence"
• Radio National advises: "In body copy spell out numbers from one to ten, then use numerals."

Interestingly, CMOS has a different view: "In nontechnical contexts, Chicago advises spelling out whole numbers from zero through one hundred and certain round multiples of those numbers." —sroc 💬 08:13, 12 May 2015 (UTC)

ist Ist 1st or ist Ist I ?

Closest statement to my question is Ordinals where it talks about Regnal numbers. Previous I've have changed a few instances like "John Ist" to "John 1st". I see now the section says that "John I" should *not* be changed to "John 1". Okay. But what about "Ist" to "1st"? Should I revert my last six changes?

Separately, searching for instances of "The Ist" I found article Alfred_Schlemm#Italy which has in consecutive sections

Ist Fallschirm-Korps (multiple)

IIIrd Fallschirm-Korps

1st Fallschirm-Armee (multiple)

Which style is correct, "Ist" or "1st"? Shenme (talk) 02:40, 14 May 2015 (UTC)

I would think that MOS:IDENTITY applies. What do reliable sources call these entities?

On a somewhat related note, where are you seeing "John Ist" or "John 1st"? Those don't look right and should probably be "John I". – Jonesey95 (talk) 03:27, 14 May 2015 (UTC)

Invitation to comment on VP proposal: Establish WT:MoS as the official site for style Q&A on Wikipedia

There is now a proposal at the Village Pump that WT:MoS be established as Wikipedia's official page for style Q&A. This would involve actively guiding editors with style questions to WT:MoS and away from other pages. Participation is welcome. Darkfrog24 (talk) 18:14, 14 May 2015 (UTC)

DATETIES: Is DMY format now acceptable for the U.S.?

I ask the following question in consequence of earlier comments (under another section) where it was suggested that usage of the DMY format is increasingly common in the US. The question is the extent of this shift and whether the MDY format remains in use to such a predominant extent or whether it might now be considered that both formats are acceptable, as in the case of Canada? Cinderella157 (talk) 01:52, 11 April 2015 (UTC)

Good question. On one hand I am so immersed in scientific areas where DMY is nearly universal that I can't really assess how far MDY has been supplanted in non-scentific areas. And any poll would strongly reflect how a sample was selected. On the other hand, does it really matter? When writing shortened numeric dates, there is a big difference between 4-11-15 and 11-4-15. But when the month is spelled out (even partially) I think most people have no problem with either Apr. 11 or 11 Apr.

Off-topic excursion into nuances of "numeric" dates

Inline reply to J. Johnson: No general style guide endorses any punctuation in an all-numeric date other than a forward slash; no general style guide authorizes hyphens or periods in dates. Two-digit years have been verboten since the 1990s, if not earlier. ISO 8601 permits (but does not require) separating the elements of a yyyymmdd date with hyphens (and the parts of a time with colons). ISO 8601 is the only all-numeric date format that is not ambiguous for days 1–12. However, ISO 8601 is a standard for data representation only, not for use in publications. No style guide in the real world permits ISO 8601 dates.—Finell 02:41, 12 April 2015 (UTC) Thank you, but you have totally missed the point I was trying to illustrate. ~ J. Johnson (JJ) (talk) 02:14, 13 April 2015 (UTC)

At a somewhat broader level, I wonder whether the "strong national tie" ought to arise from the topic itself — or from the audience most likely to be reading the topic. E.g., should an article on an ancient Chinese history use ancient Chinese dates? Or those familiar to modern English speakers? For local or parochial topics of mainly local interest there is no problem, but what about (say) the first trans-Atlantic telegraph cable? ~ J. Johnson (JJ) (talk) 22:16, 11 April 2015 (UTC)

If it is, then the whole issue of DATETIES might well be mute. Cinderella157 (talk) 00:04, 12 April 2015 (UTC)

Well, if anything's patently obvious it's that the DATETIES issue is not mute. EEng (talk) 00:10, 12 April 2015 (UTC)

Just to be perfectly clear: DMY format dates are not acceptable in articles written in American English -- with a limited exception for military topics. DMY format dates are not used with any frequency in mainstream American media, nor are they recommended/endorsed by American English style guides. No, DMY format dates are not an acceptable mainstream alternative practice in American English.

P.S. The abbreviation "U.S." (with periods) is still the preferred form of abbreviation in American English, too. Dirtlawyer1 (talk) 00:41, 12 April 2015 (UTC)

However, some reputable publications are using US, and I perceive a trend toward that usage. Also, statements such as "UK and U.S. officials ..." irritate the sensitive reader.—Finell 03:49, 12 April 2015 (UTC)

@Dirtlawyer1, "acceptable mainstream practice" is established by the mainstream, not by authority, nor by lawyering. One can observe style guides and other official compilations, but they are not the source of what is "mainstream"; they are at best a reflection. At worst, they tend to be conservative and behind any curve of changes. Mainstream changes tend to just happen; they are not organized. But the mainstream in America is always absorbing the influences of the other practices around it, and is not rejecting DMY either. It's recognized as "another style", not American in origin, but acceptable all the same thank you very much. If you think otherwise, I would challenge you to find a story of objection or ire directed against this un-American activity. But really, "mainstream" is "the people", not "officialdom". Evensteven (talk) 20:25, 19 April 2015 (UTC)

Evensteven, please feel free to provide evidence for the DMY in American mainstream practice . . . if you don't trust "conservative" American style guides, please feel free to list all of the major American publications that use DMY dates which you can find. You know, "conservative" publications like The New York Times, The Washington Post, Los Angeles Times, Chicago Tribune, USA Today, Time magazine, People, Sports Illustrated, The Sporting News, Bon Appetit, The Wine Spectator, The Harvard Law Review . . . Can you name a single major American daily newspaper or weekly/monthly magazine of national circulation -- exclusive of technical journals -- that actually uses DMY dates in publication? Good luck, and be prepared to spend a lot of time searching! And for every example of an American publication that uses DMY which you manage to uncover, I can easily provide the names of 100 publications that use MDY dates with 1/100th the effort: that's what I mean by "mainstream practice." Dirtlawyer1 (talk) 22:33, 19 April 2015 (UTC)

FWIW, I would note that the guideline suggests either format is appropriate for Canada is completely out of touch with reality. DMY hasn't been in common use (or even rare use) in English Canada for decades. And honestly, I don't see evidence that it is becoming prevalent in the US either. So my position is that for general, no, DMY would not be appropriate for American (or Canadian) articles. Resolute 02:46, 12 April 2015 (UTC)

The statement that DMY is not in common use in English Canada for decades is not correct. While Alberta seemingly does use MDY more commonly, and the Canadian media use MDY, there are plenty of examples (not only rare ones) where DMY is used. Service Canada and the Canada Revenue Agency (as one example) use ISO 8601 most of the time, but use DMY for the times they do not. Particularly in the business sector for things like Records of Employment, benefits, and medical reports. XFile and a number of other Canadian tax processes require DMY importing. Citizen and Immigration Canada requests documents be submitted in the ISO 8601 or DMY. In any regard, the only consensus among Canadians is that both are and may be used. Mkdw^talk 04:00, 18 April 2015 (UTC)\

You are overstating things. Most newspapers, magazines and universities use MDY over DMY. No such consensus exists among Canadians. The last time this was discussed, I found exactly two universities using DMY and at least fifty that used MDY, in-line with American scholarly publication guidelines. Similar issue for publications. Walter Görlitz (talk) 06:40, 18 April 2015 (UTC)

I didn't overstate anything and request you retract that statement. I gave two examples of there the MDY format is readily available and in NO way said those were the only places. In fact they were concession examples that I used to show that MDY is widely used in some (never said only or all) highly visible areas. It was a carryover so please read it more carefully before you make baseless accusations. My point was that there are other places where DMY is used and not as "rare". Both date formats can be used. It states so here on the Wikipedia guideline for DATETIES, the article date format by country, but more notably the issue of date format is found in multiple places. Maybe I need to put this more plainly but there is no prohibition on date format over the other in Canada; only preference. Even at the federal and legislative level despite "adoption" of ISO 8601 the dual format system exists even at our government level. There is absolutely no where that it states Canada has one format over the other. Mkdw^talk 07:32, 18 April 2015 (UTC)

I plainly refuse to retract my statement because it's correct.

I'm not stating that it should be changed for Canada, just that most publications and universities use MDY format and it applies to more individuals than government documents. Walter Görlitz (talk) 14:40, 18 April 2015 (UTC)

Cinderella: I could only hope that the ever-going DATETIES arguments would "mute", but not likely. And possibly you meant "moot"? Even so, no such luck. Granting that either format is acceptable leaves lots of room to argue which should be used. [Removed extraneous comment added here by Walter Görlitz.]

On the same basis of "strong national ties", DMY seems as appropriate for scientific topics as military topics. ~ J. Johnson (JJ) (talk) 03:45, 13 April 2015 (UTC)

Hey, I already made the "mute" joke. Get your own humor! EEng (talk) 03:56, 13 April 2015 (UTC)

There was still some flavor left. :-) ~ J. Johnson (JJ) (talk) 22:37, 13 April 2015 (UTC)

The irony is that the error is perhaps not so erroneous, even if technically incorrect. Cinderella157 (talk) 23:30, 13 April 2015 (UTC)

My own take on most of these date arguments is that the rule/guide isn't meant to tell you the best date format to use - it is meant as a tie breaker when we have arguments. As mentioned above, the subject of the article can't exclusively decide (eg articles on China should not use the Chinese date format) and you can't tell which readers you have (an American wanting to visit a Chinese city, an Australia looking up a American company for business research, etc). Since the reader could be anybody, the actual format used is irrelevant as long as it can be deciphered: eg, 1 May 2015 or May 1, 2015 or 2015-05-01 (the last not for general prose). But historically we have seen many articles written in, say, 1 May 2015 style and an American will 'correct" the date format. A Brit or an Australian will then "correct" it back and so it goes for a few weeks until some editors leave WP in disgust. By having a tie breaker guideline we can allow the main contributor to choose a style they are comfortable with while still allow a way to choose when opposing parties can not reach a conclusion. I would be very against interpreting the guides as "this type of article MUST use this date format". Best to leave it as a tie breaker, not a straight jacket.  Stepho  talk  00:02, 14 April 2015 (UTC)

I also oppose any interpretation of the date format guidelines as mandating either DMY or MDY. But use as a tie breaker is not optimal, as it encourages arguments, where DATRET and DATETIES are then used as battering rams. I think we need to accept (as Stepho said) that date format is irrelevant as long is it understood. Particularly, that all readers will understand BOTH "11 April" or "April 11", quite aside from their relative prevalence. And that arguing which is more common in any given context is neither relevant nor useful. ~ J. Johnson (JJ) (talk) 22:55, 24 April 2015 (UTC)

People will argue about it. People will cruse about Wikipedia changing any format for which their are national favorites to their favourite. Rules for how to choose seem to help with this problem. Jc3s5h (talk) 23:35, 24 April 2015 (UTC)

To say that a given rule is to be applied whenever there is a controversy encourages creation of controversy to get the rule applied. We certainly have plenty of editors unilaterally changing date formatting on the sole basis of DATETIES/DATERET, controversy or not. And note the discussion just above, where it is argued (12:39, 10 Apr) that DATETIES is superior to DATERET, and constrains the reversion of "bold" date format edits.

I think we should formulate a new principle: that MDY and DMY are BOTH acceptable (though articles should be consistent in using one or the other), that "national" or other contextual ties are a factor editors should consider, but is not a mandate, and may not be argued except where an existing split in discussion cannot be otherwise resolved. ~ J. Johnson (JJ) (talk) 21:29, 25 April 2015 (UTC)

Not seeing a lot of support on this, JJ. I've been observing this area for a decade or so, and I think that where something works in Wikipedia, we shouldn't fix it. People can get seriously attached to trivia like this, and a slight change in wording can be the signal for some earnest editor to bot up thousands of articles to their preferred style before anyone notices.

I travel reasonably frequently, and while DMY is making some inroads into American usage, along with metrics, it isn't a real lot. MDY is probably doing better in the rest of the world than it used to be, mainly due to newspapers choosing to use US news services as feeds and not wanting to employ more people to correct formats. Actually, it's more MD format making headway - MDY doesn't necessarily follow, because when the year is included, there's a disconnect.

When the month is spelt out, either format is acceptable, in my view, and it then remains to minimise discomfort and conflict among editors, which is where WP:DATETIES comes in, and seems to be working reasonably well to reduce disruption. If we were to change that, I'd change it to conform with our usage for currencies and units of measurement. I can't see why we'd use Swiss Francs and metres in an article about Switzerland, but then use American date formats just because some American editor back in the mists of wikitime happened to use whatever they wanted. --Pete (talk) 17:01, 5 May 2015 (UTC)

If there already was a lot of support I wouldn't need to say anything, right? It is when something needs changing, or an idea is new, that support has to be built and mindsets re-oriented. I believe J. S. Mill said someting about all mass beliefs starting as an idea of a single individual. But getting there can be a bit of struggle. E.g.: shit (entropy) can roll down hill all by itself, but getting anything good to the top of a hill takes a lot of pushing.

You express a concern that "a slight change in wording can be the signal for some earnest editor to bot up thousands of articles". My overriding concern is that (except in very limited cases of obvious inconsistency or error) NO date formatting changes should be done unilaterally, and certainly not automatically, without some concurrence of the affected editors. As it is, we have quite a bit of disruption where (as we have been discussing) some editors are emboldened by DATETIES to make changes unilaterally, and then insist that their changes can't be reverted because DATETIES overrides DATERET. If the editors on some article agree (because of "strong ties", or any other reason) to a date format it does not matter what "some American editor back in the mists of wikitime happened to use". That some editors are over emboldened by DATETIES is a cause of disruption that we should fix. ~ J. Johnson (JJ) (talk) 22:09, 5 May 2015 (UTC)

While I take your philosophical points, I think a fair bit of support for your position would have to be expressed here for a consensus to be perceived and a change implemented. As it stands, WP:DATETIES overrides WP:DATERET. Lao Tzu makes the point that finding the natural order of things is easy; water runs downhill and finds its natural course. It's when something unnatural is inserted - a dam, perhaps - that the natural flow is disturbed. --Pete (talk) 23:27, 5 May 2015 (UTC)

Wikipedia is like the water behind the dam: without standards, etc., it, too, would "naturally" go downhill. Where the standards are ill-formed there tends to be turbulence, even destructive cavitation.

The interpretation of DATETIES as a mandate, and as overriding even BRD, is a serious bit of cavitation. ~ J. Johnson (JJ) (talk) 21:34, 9 May 2015 (UTC)

JJ, why do you think we have WP:DATETIES? --Pete (talk) 23:33, 9 May 2015 (UTC)

I believe the intent of having DATETIES is to break ties, to resolve matters where consensus has not been obtained. However, the all too frequent effect is (as I've said) to make ties, where DATETIES is taken (see discussion above) as superior to other principles, and even modifies BRD. On the basis of this interpretation some editors are assuming a right to unilaterally change date formatting. This creates conflict. ~ 23:53, 10 May 2015 (UTC)

I agree with:

In any case, I believe that the words "unless there are reasons for changing it based on strong national ties" mean, simply, that if "there are reasons for changing it based on strong national ties" (i.e., if DATETIES applies), then DATERET does not apply to counter it; otherwise. (This is all assuming, of course, that the editor is acting in good faith in asserting that DATETIES applies in the particular case.)

I think this is an entirely understandable and legitimate way to read it. In fact, I think it is the only way to read it, and you should not see users invoking DATETIES as "running rampant" unless there is an explicit "consensus on the article's talk page" to keep the existing date format. If it were otherwise, the exception would be in DATETIES instead—"Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that nation, unless another date format has already been established in accordance with MOS:DATERET"—but it isn't. —sroc 💬 07:20, 9 April 2015 (UTC)

I think sroc's reading is correct. Jc3s5h (talk) 20:30, 9 April 2015 (UTC)

—Iknow23 (talk) 01:47, 11 May 2015 (UTC)

You probably meant to add your comment to the previous discussion. The topic here ws whether DMY format is now acceptable for the U.S. On the pragmatic basis of whether any confusion would ensue, DMY seems quite acceptable. But as your comment reminds us, we have a strong ideological commitment that DMY is not acceptable "for the U.S.", the underlying rationale being a supposed reduction in "disruption". ~ J. Johnson (JJ) (talk) 20:18, 16 May 2015 (UTC)

Calibers and spaces between numbers and "mm"

I have started a discussion over at WikiProject Firearms on how to properly designate cartridges and munitions (40mm versus 40 mm grenade, for example). I'd definitely appreciate some input. Faceless Enemy (talk) 14:22, 17 May 2015 (UTC)

"Eight tenths"and "4/5", not "point eight"

I don't see anywhere here which says that one must type either of the first two in the subject but not "point eight" as an example. Gamingforfun365 (talk) 01:06, 18 May 2015 (UTC)

In what article has this question arisen? EEng (talk) 01:17, 18 May 2015 (UTC)

Clarification on DATERET

A problem has arisen with a conflict between DATETIES and DATERET in a number of Canadian geographic articles. An editor made a consensus decision based on a discussion here and applied it to other articles in the same region. There are two questions

1. Can consensus override DATERET on an article-by-article basis? If so, can consensus change at a later time and reverse that decision?
2. Do dates in prose carry more weight than dates in references? My contention is that the tools used for references often apply an ISO 8601 format and sometimes a DMY format automatically and so it may not be valid to assume the editor chose to apply that date, although one edit in particular makes it clear that the editor did choose that date format.

Feel free to ping me if needed. Walter Görlitz (talk) 05:44, 1 April 2015 (UTC)

DATETIES and DATERET do not conflict; DATETIES is an exception to DATERET. DATERET specifically says: "If an article has evolved using predominantly one format, the whole article should conform to it, unless there are reasons for changing it based on strong national ties to the topic or consensus on the article's talk page." However, DATETIES would not require a change to MDY format in this case, as it says: "Articles related to Canada may use either format consistently."

On point 1, local consensus can override DATERET (indeed, it is also explicitly excepted in the above quoted text) and, of course, consensus can change.

On point 2, in general, I would think that dates in body content (prose, lists, etc.) carry more weight than dates in references in determining whether DMY or MDY is the predominant format of a given article because they are more noticeable; changing the format in footnotes is less likely to be controversial than changing the format in the body. —sroc 💬 06:22, 1 April 2015 (UTC) [amended 06:26, 1 April 2015 (UTC)]

Certainly an interesting question regarding "date format chosen by the first major contributor in the early stages of an article should continue to be used". I believe the real question whether the first major contributor "choose" the date format or not -- regardless of whether it was in the reference or prose section. For prose we have a fairly good assumption that they chose the format, and for references we cannot be certain if they did or did not. Perhaps they used a tool, but equally as likely, perhaps they didn't use a tool and choose the other. References started becoming more popular around 2006-2009 for city articles and almost always the first time we see a date format is in reference form. That's because specific dates in those articles were almost always only month and year. The article Delta, British Columbia was an example where it evolved with one format and still to this day, no prose date is present in the article. If someone were to add a different date format in the prose now, I don't think it should override nearly a decade of use of the other one in the references. I think the solution is to prioritize the first bullet point in DATERET and to focus on "evolved using predominantly one format, the whole article should conform to it". The issue of first date format should only be applied if the article evolved using both without one clear dominant date format. Mkdw^talk 16:59, 1 April 2015 (UTC)

sroc's comments are somewhat inconsistent. His view that WP:DATETIES overrides WP:DATERET is a questionable view that he has been pushing above at #Military date format in biographical articles. However, he does state that local consensus can override DATERET (which is the general rule and practice). And notes the explicit statement in DATETIES that "[a]rticles related to Canada may use either format consistently." I would further point out that WP:DATEUNIFY (partiallly quoted above) does not require consistency across the different classes of dates, so what ever usage has evolved with your reference dates might not be fully applicable to dates in the text. As to the main point that was raised here: yes, consensus can change, and thus override what ever has evolved. Which is something you should work out at the article's talk page. ~ J. Johnson (JJ) (talk) 21:05, 4 April 2015 (UTC)

@J. Johnson: "His view that WP:DATETIES overrides WP:DATERET is a questionable view ..." How so? DATERET explicitly excepts cases where "there are reasons for changing it based on strong national ties" (i.e., where DATETIES applies) as well as for following "consensus on the article's talk page". I am merely reading the guideline. How is this "questionable" or "inconsistent"? —sroc 💬 05:14, 5 April 2015 (UTC)

The issue comes down to whether the exceptions to DATERET ("reasons ... based on strong national ties", or "consensus") are permissive, or mandatory. In a prior discussion about this (above, at #Military date format in biographical articles, where "military usage" is based on DATETIES) you said (11:51, 22 Mar) 'But the guideline says "[military articles] use day before month"; it doesn't say "may use" or "sometimes use" ....'

Subsequently you said (18:27, 26 Mar) "My position remains clear: ... Where a topic contains strong national ties ... that will direct whether to use DMY or MDY... thus, DATETIES overrides DATERET." [Emphasis added.]

In your rejection of "may use", and explicit use of "will direct", you are saying that if there is a "strong national tie" then use of the national style is mandatory, irregardless of usage previously established in the article. However, you overlook the "should generally use" qualification of DATETIES, or that in DATERET "strong national ties" does not override "consensus".

You should also bear in mind that the broader guidance of WP:MOS#Retaining the existing variety (MOS:RETAIN) clearly states:

When an English variety's consistent usage has been established in an article, maintain it in the absence of consensus to the contrary. With few exceptions (e.g. when a topic has strong national ties or a term/spelling carries less ambiguity), there is no valid reason for such a change.

It seems clear to me that DATERET is permissive: articles should use an established format, but may use another if there is consensus to do so. ~ J. Johnson (JJ) (talk) 20:25, 5 April 2015 (UTC).

Both DATETIES and DATERET use "should"; these are, of course, subject to consensus to overlook this guidance in specific instances. DATETIES doesn't make an exception for DATERET. DATERET makes an exception for DATETIES. Simply put, the order of precedence is clear:

1. If there is consensus to follow a particular format for a specific article, follow that consensus.
2. DATETIES: articles with strong national ties to an English-speaking country should use the common format for that country (i.e., MDY for US, DMY for US military and the rest of the world, but either MDY or DMY for Canada), except in the case of 1.
3. DATERET: don't change the date format from DMY to MDY or vice versa, except in the case of 1 or 2.

This is consistent with the text you quoted from RETAIN. —sroc 💬 06:07, 6 April 2015 (UTC)

To be clear, I never said that DATETIES and DATERET override local consensus. The issue in the earlier discussion was how to reconcile a conflict between DATETIES and DATERET, and I pointed out that there could not be any such conflict because DATETIES is an explicit exception to DATERET. Another editor argued "Provided an article is consistent in date format usage, there is no good reason to change the date format used"—I pointed out that this disregarded that DATETIES may provide a good reason to change the date format where an article uses a format inconsistent with strong national ties (ignoring consensus, which I believed to be an understood exception but irrelevant to the discussion as between DATETIES and DATERET). Please do not misrepresent my comments or position. —sroc 💬 06:18, 6 April 2015 (UTC)

You said that "DATETIES overrides DATERET" without specifying whether that applied to the specific part of DATERET about consensus; please do not fault me for your own lack of clarity.

I would agree with your levels of precedence except for one omission:

• If an article has evolved using predominantly one format, the whole article should conform to it .... [Per MOS:DATERET.]

There is no requirement that such a predominant format be consistent with strong national ties, therefore the lack of such consistency does not "provide a good reason to change the date format". (More precisely, is not itself a sufficient reason to change.) I note also that such inconsistency is not itself a reason based on strong national ties. ~ J. Johnson (JJ) (talk) 22:23, 6 April 2015 (UTC)

Actually, in the case of Canada, STRONGNAT/DATETIES is immaterial as both DMY and MDY apply. So the question is a bit deeper than what editors are commenting on here. Walter Görlitz (talk) 03:52, 7 April 2015 (UTC)

Indeed. I believe we have gone from the specific issue that was raised here to the broader applicability of DATETIES and DATERET. ~ J. Johnson (JJ) (talk) 22:26, 7 April 2015 (UTC)

@J. Johnson: "There is no requirement that such a predominant format be consistent with strong national ties ..." There is no need to re-state the need for consistency in DATETIES as this is already covered in the immediately preceding section, MOS:DATEUNIFY: "Dates in article body text should all use the same format ..." Neither DATETIES nor DATERET is exempt from this basic principle of DATEUNIFY. —sroc 💬 04:53, 7 April 2015 (UTC)

• While these date-format discussions give me a headache, I see the potential for some good here. You two seem close to agreeing on how these policies interact, and the trouble of getting to that point may act as a roadmap for improving the guidelines so others won't be similarly vexed. Can you two work together to propose something? EEng (talk) 22:49, 6 April 2015 (UTC)

You have found me out! I am hoping that we will have convergence, but the basis for our different views needs to be understood before we can resolve it. Everyone please be patient. ~ J. Johnson (JJ) (talk) 22:29, 7 April 2015 (UTC)

@sroc: I think we agree (and everyone else?) that per WP:DATEUNIFY there should be consistency of date format within each class of dates (text, publication [references], and access/archive) in each article. I think we also agree that an article's date format (possibly differing for each class of dates) may be set by consensus of the involved editors. (Here I note a possible conflict with "strong national ties", to discuss later.)

Our difference is this: does a claim of a strong national tie "provide a good reason to change the date format" (as you said) even though an article has "evolved using predominantly one [presumably different] format" (DATERET}? In other words, must established usage (absent any declared consensus) always yield to a claim of "strong national tie"? ~ J. Johnson (JJ) (talk) 22:35, 7 April 2015 (UTC)

@J. Johnson: In the absence of consensus to the contrary, yes, a valid claim of strong national ties provides a valid reason to change the predominant date format in an article. That's what DATERET says: "If an article has evolved using predominantly one format, the whole article should conform to it, unless there are reasons for changing it based on strong national ties to the topic or consensus on the article's talk page." For example, if the article on New Zealand Prime Minister John Key had consistently used the MDY date format since its inception, DATETIES would provide the justification to change it to DMY (in spite of DATERET) unless there was consensus to disregard the guidelines. That's how I read the current guidelines. Do you disagree? —sroc 💬 06:19, 8 April 2015 (UTC)

Yes, I disagree. A predominately consistent usage in an article is an implicit consensus of the several editors. It is uncivil and creates ill-will when some editor unilaterally (and sometimes idiosyncratically) makes sweeping changes while waving "DATETIES" as a big stick of justification. I can see DATETIES (or rather, reasons based on it) as a point to raise in a discussion, and as a deciding factor when editors are dead-locked on proper usage, but not as license to run rampant. As I have previously said (5 Apr), I think it is a matter of whether the DATETIES exception is permissive, or mandatory. That is, whether DATERET allows exceptions to established usage, or requires them. ~ J. Johnson (JJ) (talk) 20:54, 8 April 2015 (UTC)

@J. Johnson: Did you mean "... but [not] as license to run rampant"?

[Ooops! Yes, of course.~ J. Johnson (JJ) (talk)]

In any case, I believe that the words "unless there are reasons for changing it based on strong national ties" mean, simply, that if "there are reasons for changing it based on strong national ties" (i.e., if DATETIES applies), then DATERET does not apply to counter it; otherwise. (This is all assuming, of course, that the editor is acting in good faith in asserting that DATETIES applies in the particular case.)

I think this is an entirely understandable and legitimate way to read it. In fact, I think it is the only way to read it, and you should not see users invoking DATETIES as "running rampant" unless there is an explicit "consensus on the article's talk page" to keep the existing date format. If it were otherwise, the exception would be in DATETIES instead—"Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that nation, unless another date format has already been established in accordance with MOS:DATERET"—but it isn't. —sroc 💬 07:20, 9 April 2015 (UTC)

I think sroc's reading is correct. Jc3s5h (talk) 20:30, 9 April 2015 (UTC)

It is a possible reading, but not the only one. And we should consider what reading is most acceptable. E.g., does "strong national ties" give any drive-by editor a right to unilaterally change date formats where explicit consensus is not to be found "on the article's talk page"? Does it count if it is buried deep in the archives? Does the presence of {{mdy}} or {{dmy}} templates indicate explicit consensus? ~ J. Johnson (JJ) (talk) 21:19, 9 April 2015 (UTC)

Archives are still evidence of explicit consensus arrived at on the talk page (it doesn't stop being consensus when archived). Maintenance templates are not a substitute for explicit consensus on the talk page achieved through discussion. —sroc 💬 03:21, 10 April 2015 (UTC)

By the way, the use of terms like "drive-by editor" and "unilaterally" betray a failure to assume good faith. Users may make valuable contributions by applying Wikipedia's policies and guidelines (including the MOS) to clean-up articles, even if they are unfamiliar with the subject or do not otherwise edit particular articles. For example, I routinely fix formatting to add missing commas after MDY dates (per MOS:DATEFORMAT) and after city–state or city–country combinations (per MOS:COMMA) as I browse articles I read; this is not vandalism.

If an editor changes an established date format citing DATETIES, assume that they have a good faith reason to believe that it's the right thing to do according to the guideline. If they are mistaken that DATETIES applies (e.g., the subject is Canadian and either DMY or MDY is acceptable, or the subject is US military and DMY is preferred instead of MDY), then revert the edit and explain why. If it is contentious whether DATETIES applies (e.g., it is unclear whether the subject has strong national ties to an English-speaking country), raise the matter on the article's talk page. If there is explicit consensus to use a particular date format for the article, revert the edit and point to the earlier discussion that established consensus (there may be an opportunity to discuss whether consensus has changed). But do not simply revert the change citing DATERET if there is a valid reason to apply DATETIES just because no one has had the presence of mind to do so before. Certainly do not bully or undermine editors who may have been trying to do the right thing (or what they thought was the right thing). —sroc 💬 12:59, 10 April 2015 (UTC)

Please note that Accusing others of bad faith is itself a violation of AGF. (See also WP:Assume the assumption of good faith.) Your objection to "drive-by" and "unilaterally" suggests you see those as inherently colored terms, or that I have some cryptic meaning intended. Which are both incorrect, and an assumption of bad faith on your part. The fact is that no one (not even yourself) considers unilateral action itself to "betray a failure to assume good faith." Similarly for "drive-by". These terms are innocent.

The problem with unilateral action is when it contravenes consensus, including those cases where (as you said) "no one has had the presence of mind" (or just not seen the need?) to document it before. This does not have to result from, nor does it "betray", any nefarious intent. It could be nothing more than shear bullheadedness. More commonly the problem stems from editors thinkig it is (as you say) "the right thing to do according to the guideline", but they may also (as you explain) presume upon that, without any inquiry or discussion. For any non-MOS matter such Bold editing could be Reverted, to be followed with Discussion. But date-format discussions all too often get short-circuited into assertions that DATETIES overrides all other considerations (except explicit consensus previously obtained), including established ("evolved") usage.

You state: "Certainly do not bully or undermine editors who may have been trying to do the right thing ...." For sure! Please note that the WP:Civility nutshell says: "Do not ignore the positions and conclusions of your fellow editors", and: "Participate in a respectful and considerate way". I say these include respect for extant work, including established usages, and to not make broad changes unilaterally without the courtesy of discussing it with those who have made major contributions. ~ J. Johnson (JJ) (talk) 21:59, 10 April 2015 (UTC)

If I edit an article to add commas after MDY dates, without the matter having ever been discussed on the article's talk page but ensuring consistency with MOS:DATEFORMAT and MOS:COMMA, would you object on the basis that it is against consensus on the article's talk page? I would hope not. Why then treat edits to comply with DATETIES any differently (assuming that there is a valid basis and the matter has not been addressed for that article before)? —sroc 💬 10:48, 11 April 2015 (UTC)

Why would you presume to drop-in on an article where you have never made any major contributions and make broad changes of a frequently controversial nature "without the courtesy of discussing it with those who have made major contributions"? Even if we assume that such changes are proper, it is arrogant to do so without any consultation. It assumes as a right or a license what is really only a guideline. Do you assume that other major contributors are so ignorant of the guidelines that only you can set matters right? Why should any such edits not be subject to the R of WP:BRD?

There is a right: it's the B in BRD. I never said that controversial edits are not subject to R—in fact, I wrote: "If they are mistaken that DATETIES applies ... then revert the edit and explain why." Reverting presumes there is a valid justification to oppose the change.

In longer articles with many dates, it may be prudent to make a comment on the talk page, but this is not a strict requirement when the application of DATETIES does not appear controversial; if it really is controversial, someone will revert it. In stubs or short articles with only one or two dates, a switch in date formats when DATETIES obviously applies (say, a short biographical article on a relatively obscure Australian written by a handful of contributors) is unlikely to be controversial—would you call it arrogant to make such a change? —sroc 💬 08:14, 12 April 2015 (UTC)

The problem isn't so much where you or anyone else claims a right - which is to say, to claim a moral or legal entitlement - to change a date format, but where editors insist that their changes may not be reverted. That is arrogance, just as it is arrogant to assume that one's own sense of "obvious" (implying that explanation is not necessary) is superior to anyone else's sense of "obvious". If a "handful of contributors" has consistently used any format, then, yes, I would call it arrogant to assume any right to revert their efforts. To simply "make a comment on the talk page" suggests that discussion is not necessary, and implies there is nothing they could say that would change your intention. ~ J. Johnson (JJ) (talk) 23:17, 13 April 2015 (UTC)

Sroc seems to be taking a wikibreak. To summarize where we have gotten to, sroc seems to allow that Reversion can be applied to "controversial edits", but apparently only where it is mistaken to apply DATETIES, where there is "valid justification to oppose the change." To me this sounds like an attempt to give edits that claim DATETIES an exemption from reversion, which I find arrogant. And there the matter stands, without resolution. ~ J. Johnson (JJ) (talk) 23:33, 24 April 2015 (UTC)

J. Johnson seems to have misunderstood where I'm coming from. My understanding is that, on Wikipedia, by definition, any edit that is disputed is "controversial" (which is not to say that it is necessarily something likely to provoke a heated argument). Per this policy:

Wikipedia encourages editors to be bold, but while a potentially controversial change may be made to find out whether it is opposed, another editor may revert it. This may be the beginning of a bold, revert, discuss (BRD) cycle. An edit war only arises if the situation develops into a series of back-and-forth reverts.

For example:

• A stub article on an obscure Australian includes one date and it is in MDY format.
• An editor notices that dates for articles with strong ties to Australian topics should use DMY format (per MOS:DATETIES) and boldly adjusts the date (the first step in the Wikipedia:BOLD, revert, discuss cycle).
• Another editor notices the change and can either:
  • leave it, as it is a good sensible change, and it becomes the new consensus; or
  • revert it and discuss why the change is bad on the article's talk page.

But if there's no real reason to keep the MDY format, why should anyone revert it? MOS:DATERET is not a good reason in itself to avoid a change to comply with MOS:DATETIES, so reverting is a bad idea unless there are other good reasons which merit discussion. —sroc 💬 18:25, 3 May 2015 (UTC)

The essence of your argument is that DATETIES is superior to DATERET (that the latter "is not a good reason ..."). I say that DATETIES is actually a very weak rationale, which, in regard of reaching consensus, may be used as a tie breaker, but should not be used as a tie maker. That is, if there is no case for changing a date (either MDY or DMY) prior to applying "strong ties", then "strong ties" is an insufficient basis for such a change. What you seem to want is that "bold" edits (e.g., unilateral edits without prior discussion) should be privileged in that DATERET "is not a good reason" for reversion, that the reverting editor has the burden of proving why the "bold" edit is bad. I find such an interpretation unfortunate in that it has caused much acrimony on what should be a petty matter. ~ J. Johnson (JJ) (talk) 20:19, 4 May 2015 (UTC)

I'm merely reading the wording of DATERET which includes an express exception for DATETIES. I'm not sure what you mean by "DATETIES is actually a very weak rationale"—whether you think that DATETIES shouldn't exist or that you would ignore it at will or what.

Answer me this: in the example in my last comment—where there are strong national ties to an English-speaking country using DMY and an editor changes a solitary date from MDY to DMY format, and there has been no prior discussion of the date format relating to the article at all—would you revert it on the grounds of DATERET? If so, why? —sroc 💬 16:33, 5 May 2015 (UTC)

Why not? By the same principle where you Boldly edit why should I not be equally free to Revert? I don't even need to cite DATERET. And if we don't reach consensus on the matter it reverts to the original form, and everyone moves on — right? Well, in your earlier comment you did imply that the reverting editor has the burden of proving "why the change is bad". But I don't agree with that. Why should your edits be "more equal" than mine? ~ J. Johnson (JJ) (talk) 22:13, 5 May 2015 (UTC)

JJ, could you answer the question, please? It's fine to talk of the general, but in this case a specific example has been raised and I'm interested in your specific response. Thanks. --Pete (talk) 23:31, 5 May 2015 (UTC)

In the current context (caveat: it's not completely specified!) I would revert. Why? Why do I need any more reason than (channeling sroc's response of 12 Apr) BRD gives me that right? Note that I am not taking any position regarding what date format should be applied; what I would be reverting is not a specific format, but an undiscussed edit. Sroc keeps assuming that one format is better than the other, but I take no stand on that. My argument is that DATETIES does not (and should not) have superiority or privilege over DATERET or BRD. ~ J. Johnson (JJ) (talk) 23:41, 8 May 2015 (UTC)

WP:DATETIES does in fact override WP:DATERET: "The date format chosen by the first major contributor in the early stages of an article should continue to be used, unless there is reason to change it based on strong national ties to the topic or consensus on the article's talk page." The wording is clear. But even if it wasn't the case, for an Australian subject, Australian editors would prefer International format rather than American format, and your edit war would escalate. And this is the reason we have DATETIES; to prevent disruption. It's one of those conventions developed in actual practice over the years because it works. --Pete (talk) 00:17, 9 May 2015 (UTC)

Thank you, Pete. Furthermore, BRD is not a licence to edit-war. In the above example, where a stub article on an obscure Australian includes one date in MDY format, with no explicit consensus on date format (let's assume the talk page has not yet been created) and an editor boldly changes the date to DMY format (citing MOS:DATETIES in the edit summary), J. Johnson feels justified in reverting the edit, not because the change was wrong ("I am not taking any position regarding what date format should be applied") but because it was not discussed. Most edits do not require prior discussion and a reversion to retain a status quo is not superior to an edit based on Wikipedia policies or guidelines:

• "BRD is never a reason for reverting. ... BRD is not a valid excuse for reverting good-faith efforts to improve a page simply because you don't like the changes. Don't invoke BRD as your reason for reverting someone else's work or for edit warring: instead, provide a reason that is based on policies, guidelines, or common sense." (WP:BRD-NOT)
• "Don't revert an edit because it is unnecessary — because it does not improve the article. For a reversion to be appropriate, the reverted edit must actually make the article worse. Wikipedia does not have a bias toward the status quo (except in cases of fully developed disputes, while they are being resolved). In fact, Wikipedia has a bias toward change, as a means of maximizing quality by maximizing participation." (WP:ONLYREVERT)
• "All edits should be explained (unless the reason for them is obvious) – either by clear edit summaries indicating the reason why the change was made, or by discussion on the article talk page." (WP:EDITCONSENSUS)

Finally, WP:DATETIES is, in fact, an express exception to WP:DATERET. JJ's refusal to accept this is staggering and any attempt to revert changes made on this basis without any other reasoning would disrupt the progress of Wikipedia. If JJ does not accept this now, then I'm afraid this conversation can serve no purpose any more. Goodbye. —sroc 💬 06:03, 9 May 2015 (UTC)

"Staggering" may appeal to sroc's sense of melodrama, but I think it is more applicable to his notion that all progress of Wikipedia would be disrupted! if there was any attempt to revert any edit with an edit summary of "per WP:DATETIES". That is the end result of his argument: that by simply shouting "DATETIES" discussion is not necessary, and reversion is precluded. Some of the postulates by which he derives that are faulty, but let's just overlook that lest Wikipedia should falter. ~ J. Johnson (JJ) (talk) 23:07, 14 May 2015 (UTC)

Arbitrary break

I see there's been agreement limiting Iran's nuclear ambitions. Any chance of similar progress here? EEng (talk) 21:25, 12 April 2015 (UTC)

As the Tennessee gentleman said: "I begin to doubt.". But as was said in one of my favorite moveis: "we'll keep pumping air." ~ J. Johnson (JJ) (talk) 23:23, 13 April 2015 (UTC)

• (One month later) Just checking in... How's it going? EEng (talk) 05:07, 16 May 2015 (UTC)

@EEng: One wikibreak later and JJ is still ignoring rational arguments and misinterpreting my comments. Done. —sroc 💬 07:53, 16 May 2015 (UTC)

The charge of misinterpreting others is serious enough to warrant a response. Your comment was: "any attempt to revert changes made on this basis without any other reasoning would disrupt the progress of Wikipedia" [emphasis added]. Admittedly, you did not say all progress would be disrupted, but that is within the scope of rhetorical dramatization that you have already displayed. Aside from that, and the trivial inversion, my comment is practically a direct quote of your comment, so it is really hard to see there is room for even a sliver of misinterpretation.

Note that I do agree with you in regard of "this conversation can serve no purpose any more." As I am inclined to ignore your syllogistic failures, please feel free to stagger back into space. ~ J. Johnson (JJ) (talk) 20:11, 16 May 2015 (UTC)

Stating that I had claimed "all progress of Wikipedia would be disrupted!" (your emphasis) whilst accusing me on sensationalism is misrepresentation. I made various rational arguments based on established Wikipedia principles, but you have chosen to ignore or misinterpret them and misrepresent my statements in an attempt to validate your view. There's no point arguing with someone who does not respond to reason. —sroc 💬 03:41, 17 May 2015 (UTC)

I am trying to not respond to provocation. Which seems to be the only purpose you have in continuing this conversation. Or are you mainly trying to distract attention from your "disrupt" claim? ~ J. Johnson (JJ) (talk) 21:00, 18 May 2015 (UTC)

• I'll be asking the Security Council for peacekeeping troops tomorrow morning. EEng (talk) 06:01, 17 May 2015 (UTC) In all seriousness, I wish I felt I could help resolve this, but I don't. Sorry.

Thanks. Tell them to bring lots of foam. And kill the air. ~ J. Johnson (JJ) (talk) 21:02, 18 May 2015 (UTC)

Another arbitrary break

Look, guys (and gals, if any), I haven't been following this, but I really did hope, way back when, that some good would come out of it. But it looks like this has become another impasse. Do you think that it would be worth my time to review the discussion and see if I can help? Or would I just be wasting my time? Please don't say Yes just to flatter me, though I know you're all eager to do that. EEng (talk) 01:33, 19 May 2015 (UTC)

I, too, had hopes some good might result. But I no longer find it worth the hassle. With sroc so wrapped up in "DATETIES uber alles!" that he does not even understand my point (whether that is because I am too dumb to explain, or he is just too deaf to hear, likely makes little difference), and his pushing this alleged misrepresentation, while making various snide remarks, amounts to so much friction that any effort applied here will create more heat than light. This discussion has become a waste of time. ~ J. Johnson (JJ) (talk) 21:39, 19 May 2015 (UTC)

@J. Johnson (JJ), I get your point but there is no proposition on how to resolve the issue such as an amendment; such as - changes invoking DATETIES should only be made after comment has been sought and a consensus exists. Cinderella157 (talk) 00:48, 20 May 2015 (UTC)

@J. Johnson: I never said "DATETIES uber alles!" I said DATETIES is an exception to DATERET because that's what DATERET specifically says! And you have yet to respond to all of the Wikipedia principles cited above saying not to revert without a good reason (and which say "it wasn't discussed first" isn't good enough). It may be more useful to discuss potentially contentious cases before implementing them, but you ignore all this to justify reverting even uncontroversial changes you don't disagree with! —sroc 💬 02:54, 20 May 2015 (UTC)

You have the right of it, sroc. It's not a matter of personal interpretation of ambiguous wording. DATETIES over-rides DATERET and has done for many years. It's pointless trying to argue that any other interpretation is valid; it isn't. JJ is welcome to discuss changing the wording, but trying to argue that the wording means something it clearly does not is just being disruptive. --Pete (talk) 17:00, 20 May 2015 (UTC)

Cinderella157: it would be premature to propose any changes when some folks here do not see the problem. E.g., Pete suggests that I am "trying to argue that the wording means something it clearly does not". However, that is not correct. Note that there is the "wording" (the text), and there is the interpretation of the text. While I have some quibbles about the interpretation sroc choses, my primary concern is not either of these, but with their use. As commented in the following discussion, I think the intent of DATETIES is to break ties: to resolve matters where editors are unable to reach consensus. However, what I am concerned about is DATETIES being used to make ties – that is, for making changes where there had been no issue or conflict or lack of consensus with the date formatting, which changes no one else is allowed to change "without good reason". My argument has not been about the text itself, but with how it is used. Failure to understand this distinction undercuts any chance of this discussion moving forward. ~ J. Johnson (JJ) (talk) 22:16, 20 May 2015 (UTC)

You may have a point, though in my innocence I'm seeing it as rather a confected one. If there have been problems in interpretation of this nature, could you please show us a real-world example? Inasmuch as Wikipedia may be described as "real world", of course. --Pete (talk) 18:45, 22 May 2015 (UTC)

Could, but not particularly interested in doing so, as this discussion has lost what little flavor it had. As I recall there was a bit of edlit warring along these lines at Audie Murphy (although I don't recall that DATETIES was cited explicitly in the edit summaries)); that did lead to the discussion on this page (now at Wikipedia Talk:Manual of Style/Dates and numbers/Archive 150#Military date format in biographical articles). But not a matter I really care about anymore. ~ J. Johnson (JJ) (talk) 22:54, 22 May 2015 (UTC)

(1 x 3 x 6) m = 18 m

This has been discussed before. There is only one possible interpretation of (1 x 3 x 6) m, and that is 18 m. Dondervogel 2 (talk) 06:15, 27 May 2015 (UTC)

Where has it been discussed before? I'm not trying to make trouble, but we shouldn't be suddenly changing what's acceptable without discussion. I suspect it will turn out no one's using this format and we can remove it (I don't like it much myself) but if it is in use, we should look into why. EEng (talk) 06:21, 27 May 2015 (UTC)

Dondervogel's right, it has been discussed. The consensus was against "(1 x 3 x 6) m" and "1 x 3 x 6 m³" allowing only "1 m x 3 m x 6 m" (though "1 by 3 by 6 metres" is fine). This is less of a sudden change and more of a belated reversion to what has been accepted consensus for years. Exactly where the discussion is to be found I couldn't quite say; we'd need to dig around the archives but I believe it has been discussed one than once with the same result. Jimp 06:39, 27 May 2015 (UTC)

Hey EEng, do you remember this this? Jimp 07:25, 27 May 2015 (UTC)

(ec) I think you'll find it is in use, and for a very simple reason: pure laziness. It's really not worth the trouble of digging into the archives because the same arguments still hold today. Just remember the words of the most sensible president the US of A has ever produced (the 27th). Dondervogel 2 (talk) 07:27, 27 May 2015 (UTC)

"The welfare of the farmer is vital to that of the whole country"? ―Mandruss ☎ 07:34, 27 May 2015 (UTC)

Wise words, but not quite the ones I had in mind. Dondervogel 2 (talk) 07:59, 27 May 2015 (UTC)

Headbomb was entirely right to correct a startling error. EEng, you can call it tag-teaming if you like, but wouldn't it be better to stick to your view that we're all friends here and accept a WP:SNOW consensus with which you sympathise yourself? You can still discuss it if you wish. NebY (talk) 11:10, 27 May 2015 (UTC)

• A bunch of reversions over 30 minutes in the middle of the night (where I am) isn't any kind of consensus. Jimp, your diff only shows me rewriting this section for clarity, with no change of meaning; the fact that, at the time I rewrote, it did not have the (1 x 2 x 3) m format we're discussing here, only proves that stability and clarity -- not affection for any particular format -- is my goal with respect to this page of guidelines.

Headbomb made a change which he justified via an appeal to a certain kind of mathematical formalism. That's sensible but not entirely conclusive, since there are many competing considerations here in addition to formalism. Now, I myself had no recollection of when the (1 x 2 x 3) m format was introduced. For all I could remembered it had been here for many years, despite Jimp's diff -- I don't have a photographic memory, you see. So I reverted and asked for a discussion.

Instead of all the stuff above, why didn't one of you just find the diff in which (apparently in the last year) someone inserted this format (apparently without discussion -- how did we all miss that?). Exhibiting that diff would have ended the matter: "X inserted it here out of nowhere, without justification". I'd look now but my 5-year-old nephew is about to arrive, and he takes priority over everything. EEng (talk) 13:07, 27 May 2015 (UTC)

Wikiblame, the revision history search tool, quickly indicated that the format was inserted with this edit which does not seem to be discussed in the two archives for that period. @Kwamikagami: would you like to expand on your edit comment "common variant in scientific articles" now? NebY (talk) 13:37, 27 May 2015 (UTC)

It's a format I'd recently seen at the time. I haven't been paying attention to the lit since. From the next comment, it's perhaps a regional variant. If that's the case, it should probably be removed. — kwami (talk) 16:47, 27 May 2015 (UTC)

• For what it's worth, (1 × 3 × 6) m is not a format I have seen in use and I don't think it would be valid—certainly not for specifying length–width–height dimensions, which this section is about. Even if it is an acceptable format in some regions, it looks quite wrong from my perspective and I would suspect more people would find it jarring than would think it's fine. I don't think anyone would doubt the universal validity of 1 m × 3 m × 6 m, so I don't think we should endorse the more dubious format. (It might be acceptable in a scientific context, but not in general prose.) —sroc 💬 14:07, 27 May 2015 (UTC)

The "diff only shows me rewriting this section for clarity, with no change of meaning". That's the point. It's a new thing someone's gone and snuck in not that long ago. It's certainly not any long-standing rule with the weight of consensus. Anyway, have fun with your nephew, at least he's not going to be quibbling over the rules of writing numbers. Jimp 14:22, 27 May 2015 (UTC)

Based on that this fmt should stay out, but I didn't know that when we had our little revert war. Since there are so many people watching here it's a good working assumption that any given thing here got in with at least the tacit approval of many, and it was on that assumption that I felt we should discuss. Turns out I was wrong, but I think you'll understand my operating from that assumption.

My nephew does know a lot about numbers. One time he counted to 20 for someone. The someone said, "Can you go higher?". My nephew looked very serious and said, "Uncle EEng [note: not what he actually said] says there's always another number!" EEng (talk) 01:12, 28 May 2015 (UTC)

Note : I saw too much reverting yesterday so to forestall another edit war, I've locked the page for 24 hours to help everyone focus on closing this debate down. If EEng and others can convince me we're all done here and nobody's going to change anything, I'll unlock it. Ritchie333 ^{(talk) (cont)} 07:10, 28 May 2015 (UTC)

Ritchie, I really do like you, but please lighten up on the use of the administrative tools. In light of the discussion above that was completely unnecessary. EEng (talk) 11:04, 28 May 2015 (UTC)

I don't think this was your classic edit war by any means. I'd say the debate's been had and the issue put to rest. I'd say it would be safe enough to unlock the page. Jimp 07:52, 28 May 2015 (UTC)

This was WP:BRD working at its best, resulting in complete consensus after a short, constructive and good natured discussion. Dondervogel 2 (talk) 09:29, 28 May 2015 (UTC)

Canadian Standard Date Format

This debate gets too tedious for words, but let me state the basic facts:

1. There is a Canadian standard date format
2. It is ISO 8601

The decision to use ISO 8601 was originally made back in the 1970s when Canada converted to the metric system. At the same time as Canada abandoned the (British) Imperial system of measure, the conversion committees decided to standardize on a date format, and that format was ISO 8601. It was mandated by the Treasury Board of Canada, and was confirmed by the Canadian Standards Association: Canadian national standard CSA Z234.5:1989.

Of course there are numerous people that will deny that this ever happened, but it did. I was a systems analyst for a major oil company and worked on the metric conversion process. At the same time as metrication occurred, our computer systems started blowing up on date errors. Oil companies write a lot of 25-year leases for oil well sites, and when 1975 rolled around, the 25-year leases started expiring in the year 2000. BOOM! went the computer systems. The company decided that the only rational solution was to accept the government mandate, and use the ISO 8601 standard for all dates. It saved them millions of dollars 25 years later when the calendar date rolled around from 1999 to 2000. Other companies spent millions of dollars fixing their software in the Y2K imbroglio, my old company spent a few thousand.

There are a lot of people who will argue until they are blue in the face that this isn't true, that there is some kind of other Canadian standard, but in reality they just don't like any date format other than their favorite (which could be either British or American, or possibly French), or they just don't like governments, or they just don't like anybody's rules other than their own. They should move to the US, use the American date format (MDY), move to the UK and use the British date format (DMY), or move to France and use the French date format (DMY, but in French). The only one that really works for Canada's multilingual, multiethnic environment and doesn't blow up when you change centuries is ISO 8601. Trust me, I've tried them all.RockyMtnGuy (talk) 17:56, 27 May 2015 (UTC)

How do you think your fellow Canadians will feel about writing that Quebec City was founded 1608-07-13? Jc3s5h (talk) 18:03, 27 May 2015 (UTC)

Is that on the Gregorian calendar or the Julian calendar? Do you know which one you are citing? On the different calendars, there was up to an 11 day difference, and due to religious disagreements, England and France used different calendars. For that matter, Scotland was on a different calendar than England for about 100 years. If it is standard ISO 8601, then it would be on the Gregorian calendar by definition.RockyMtnGuy (talk) 19:11, 27 May 2015 (UTC)

I won't deny that YYYY-MM-DD may be the official date format, but MDY date format is also prominently used. I have done business with a Canadian law firm that exclusively use MDY dates in correspondence. I have also observed Canadian websites that have used either MDY (e.g., Toronto Star) or a mix of MDY and YYYY-MM-DD dates (e.g., CTV). Personally, I prefer DMY, but I haven't seen it used much in Canadian media from afar. —sroc 💬 18:08, 27 May 2015 (UTC)

Other than ISO 8601, there is no Canadian standard date format. Having worked for decades as a systems analyst and business analyst for Canadian companies, I found there was no consistency whatsoever in date formats. In the US, I did a straw poll of oilfield workers to find out if they thought the standard American date format was MDY, and found out that about 50% agreed. The other 50% weren't sure. If you quizzed British workers about DMY, you'd find the same proportion. So, the only real solution is just to tell them what to do and give them no choice. In the military, that's even more true because nobody knows what is going on but everybody is trained to follow orders. I used to recommend the ISO 8601 date format to all my clients because it was least likely to cause confusion. Anger, maybe, but not confusion.RockyMtnGuy (talk) 19:48, 27 May 2015 (UTC)

What is this in reference to? I use ISO 8601 all the time for reference formatting, but in prose, nobody will ever agree with using it over MDY or DMY. Resolute 20:19, 27 May 2015 (UTC)

Right. RockyMtnGuy seems to have overlooked that his context is information processing, and that ISO 8601 is entirely about numeric representations of dates and times, and (to quote ISO 8601) avoiding misrepresentation "when data are transferred between countries with different conventions for writing numeric dates and times.". It is in no way a style guide for prose or other mundane usses. I believe it has nothing to say about non-numeric dates, which is what all the debate above is about. It is not relevant here. ~ J. Johnson (JJ) (talk) 21:34, 27 May 2015 (UTC)

Using the ISO standard avoids language issues, not to mention the the big-endian, little-endian, middle-endian imbroglio, which is the source of the American/British disconnect. The French system is actually closer to the British one if you skip over the language issue. People who don't deal with international markets don't understand that, whatever their national biases are, they aren't universal. There are lots of other people in other countries - or as in Canada, the same country - with different biases.RockyMtnGuy (talk) 22:39, 27 May 2015 (UTC)

I do not believe ISO 8601 or any relabeled Canadian version of it is an official standard in the sense of being imposed on the general public, or even being strongly recommended for the general public, as a general purpose date format. Countries don't usually legislate about language for general use. Extraordinary claims require extraordinary proof. Show us the proof. Jc3s5h (talk) 22:45, 27 May 2015 (UTC)

P.S. I am tempted to undo sroc's reversion on the basis that "unnecessary commentary" does not constitute a "necessary" reversion. A better basis for the reversion is that the commentary was about numeric dates, which is irrelevant to that section. ~ J. Johnson (JJ) (talk) 21:57, 27 May 2015 (UTC)

• If only all the ink spilled about date formats could be rebottled and sold and the proceeds donated to the cause of world peace. We could probably clear up the Mideast and maybe the Basque thing as a bonus. Also Ebola. EEng (talk) 01:18, 28 May 2015 (UTC)

Nah, we'd just waste it on something else. —sroc 💬 13:41, 30 May 2015 (UTC)

You might as well say "There is an American standard system of units; it is the metric system."; after all, the US was one of the original seventeen signatory nations to the Metre Convention. We're not beholden to what some 1970s bureaucrat in Ottawa came up with. Sure, you may be able to find a few counter examples here and there but the formats that Canadians actually use are dmy and mdy. Jimp 01:28, 28 May 2015 (UTC)

It wasn't some bureaucrat in Ottawa that was pushing metrication, it was industry. Canada was on the BRITISH Imperial system, and NONE of the liquid units of measure are the same as the American system. The Canadian quart, gallon, and barrel are all different than the US units. We were always converting our quarts to their quarts and our gallons to their gallons and vice-versa. It drove us nuts. Converting to metric saved us a fortune. A litre is a litre even if Americans spell it liter.RockyMtnGuy (talk) 11:06, 28 May 2015 (UTC)

I handle a lot of cheques (note spelling) as Treasurer of one of the larger sections of the Alpine Club of Canada. The banks use fixed format cheques but give their customers a choice of DDMMYYYY, MMDDYYYY, or YYYYMMDD format on them. I would say that about 75% are YYYYMMDD format, about 15% are DDMMYYYY format, and about 10% are MMDDYYYY format. I prefer YYYYMMDD because I can look at the date, and if runs 20150405, I know it's April 5. If it runs 04052015, then I have to stop and ask myself, is that April 5 or May 4?RockyMtnGuy (talk) 11:06, 28 May 2015 (UTC)

Re J. Johnson's P.S. a few comments back, I don't think that the material removed by that revert belongs in the Manual of Style. It (and most of this discussion) would be more appropriately located in the Date and time notation in Canada article. Supporting source candidates might include [4] and [5]; [6] might also be of interest. Wtmitchell (talk) (earlier Boracay Bill) 02:00, 28 May 2015 (UTC)

My point in making the addition was that there is an official Canadian standard date format, it is ISO 8601, and it is in common use in the country. The Manual of Style should reflect that fact. From a practical standpoint, there are three, not two date formats in common use in Canada: MDY, DMY, and YMD, in both English and French. A lot of people (mostly non-Canadians I assume) seem to hate the YMD format, but a lot of Canadians use it. I would assume most of the YMD-haters are either American or British promoting their local MDY or DMY biases. A lot of the disconnect in formats arises from the fact that Canada is not, per se, an English-speaking country. Canada is truly a multilingual and multi-ethnic country. The majority speaks English, but the majority is not of English origin. The split of mother tongues as per the last census was 58% English, 22% French, and 20% "Other". (Canadians usually refer to them as Anglophones, Francophones, and Allophones). The largest group of "Allophones" is Chinese, and as it happens, Chinese commonly use the YYYY-MM-DD format. There are about a million Chinese speakers in Canada (the vast majority of whom also speak English), but they are not the only ones using the YYYY-MM-DD format because it is, after all, the same as the standard ISO 8601 format.RockyMtnGuy (talk) 09:37, 28 May 2015 (UTC)

This is the English-language Wikipedia, and what works in English text are non-numeric formats. Think about how you'd say a text if you were talking to someone. It would be peculiar to come out with a string of numbers - and dashes! - but in general practice we say the name of the month, rather than its number. --Pete (talk) 17:07, 28 May 2015 (UTC)

That's a really good point. EEng (talk) 17:13, 28 May 2015 (UTC)

I beg to differ. We say "the 28th of May" but we do not write that. By the same token if we see "28 May" written on a piece of paper (or on a computer screen) and we are reading the text out loud, we do not say "28 May" (at least I don't). If some Canadian's have developed a habit of writing 2015-05-28, whose to say whether they read that as "the 28th of May 2015" or as "twenty fifteen, oh five, twenty eight"? It doesn't matter either way. What matters here is only how they write it. So, in an article about some aspect of Chinese Canadian culture, what is the objection of writing the date as the Chinese Canadian would have written it? Dondervogel 2 (talk) 17:24, 28 May 2015 (UTC)

I beg beg to differ differ. I didn't mean to imply that there should be an absolute correspondence between what's written and how it would be read out, but what mental reshuffling we require should be within the realm of that to which people are accustomed. Reading aloud, for 12 August 2015 I might speak out "12th of August" or "August 12" or "August 12th" or even "12 August", and would do so with ease; if I see August 12, 2015 I would probably pick from "August 12" and "August 12th". But confronted with "2015-08-12" I'd probably stumble, "Oh, um..." while mentally thinking, "Wait, is Month 8 August, or September, I can never remember... Um, 30 days hath September... OK, wait, 2015-dash-...". It's unnatural. It might be natural someday, but here at WP we don't lead, we follow. EEng (talk) 20:01, 28 May 2015 (UTC)

Yes, I agree, but perhaps they get as confused reading US or UK format dates as we do reading ISO 8601, so I repeat my own question "in an article about ... Chinese Canadian culture, what is the objection of writing the date as the Chinese Canadian would have written it?" . Dondervogel 2 (talk) 20:30, 28 May 2015 (UTC)

I don't know much about Chinese language and culture (in Canada, China, or anywhere else) but I suspect it's only Quakers and maybe a few others who speak in terms of "First Month, Second Month" and so on (and I don't think even Quakers do that any more). To answer your question we should look (as in the next ===-level section) at publications. Know of any Chinese-Canadian newspapers? EEng (talk) 22:06, 28 May 2015 (UTC)

Not my neck of the woods I'm afraid. I'll try Google. Dondervogel 2 (talk) 22:24, 28 May 2015 (UTC)

Yeah. Well I don't think we're going to see a real lot of support for dropping strings of numbers into written prose. Data tables, maybe. --Pete (talk) 18:05, 28 May 2015 (UTC)

One objection would be that articles are generally written to facilitate the understanding and edification of readers who are not famiilar with the subject, nor of the customary usages associated with it. The implicit basis for DATETIES is that a "strong tie" (national or otherwise) anticipates where the most interest, and therefore the most readers, will come from. But in many cases the largest readership is not those who are familiar with the topic, but those who are not. So if something as mundane as date formatting really made any difference (it does not) usage ought follow the readership, not the topic. ~ J. Johnson (JJ) (talk) 22:25, 29 May 2015 (UTC)

You're putting an awful lot of yourself into a topic you insist isn't important, JJ. The fact is that DATETIES overrides DATERET, has done so effectively for many years, and I'm not seeing any strong agreement to change this. The loudest voice is yours. I'm seeing this discussion as more heat than light and perhaps we can all work on something else for a bit. --Pete (talk) 22:47, 29 May 2015 (UTC)

What I am insisting isn't important (except as others make it to be) is the whole DMY vs. MDY debate. I am also saying that DATETIES is not as effective at quelling debate as you seem to think it is (witness the many discussions as to when a strong military tie eclipses a strong national tie), and no more effective than any other arbitrary rule. But we wander. My comment immediately above was in response to Dondervogel's question as to whether, "in an article about ... Chinese Canadian culture", a date should be written as a Chinese Canadian would have written it. ~ J. Johnson (JJ) (talk) 22:23, 30 May 2015 (UTC)

@RockyMtnGuy: "From a practical standpoint, there are three, not two date formats in common use in Canada: MDY, DMY, and YMD, in both English and French. A lot of people (mostly non-Canadians I assume) seem to hate the YMD format, but a lot of Canadians use it." This Wikipedia seeks to accommodate English language speakers from all over the world. Outside of Canada, the rest of the English-speaking world uses either DMY or MDY date formats—different people in different regions have their preferences, but we've accepted that everyone can deal with both formats even if it's not their preferred—yet hardly anyone would accept the YMD date format in written prose, so we have agreed not to use it here. Even if the YMD date format is acceptable in prose in Canada (which is unclear), it's not anywhere else, so we're better off sticking to the other formats that are universally accepted (or, at least, tolerated).

This isn't a Canadian Wikipedia; articles on Canadian topics are still written for an international audience, so the YMD date format is not appropriate here for the same reason that we wouldn't allow the article on Jean Chrétien to be written in French—even though it's a common language in Canada, and especially his native Quebec, it wouldn't suit our international audience on the English language Wikipedia. —sroc 💬 14:14, 30 May 2015 (UTC)

Yup. ~ J. Johnson (JJ) (talk) 22:27, 30 May 2015 (UTC)

• "I would assume most of the YMD-haters are either American or British promoting their local MDY or DMY biases." Oh, brother. You forgot to mention the conspiracy against French. EEng (talk) 12:22, 28 May 2015 (UTC)
  • The irony of that bit of whining is that it implies most Canadians would be biased towards his position. Yet, RockyMtnGuy is certainly the very first such Canadian whom I have ever seen make this argument. Resolute 22:42, 28 May 2015 (UTC)
    • In addition to Canadian, American and British companies, I've worked or consulted for Paris-based and Montreal-based companies. I did't want to get into this, but the French French and the Quebec French have disputes going between them that make the American/British gap between MDY and YMD seem picayune, and neither side will give an inch (or a centimetre). I went into a local French bakery last Christmas and asked for a tourtiere (a classic French Canadian meat pie they cook for Christmas). The clerk looked at me and said, "That is NOT the way we pronounce it in French". And then the customer behind me said, "Well, that's the way we pronounce it in Quebec!" And then a huge argument started about how to pronounce, "tourtiere". I said, "Look, I don't speak French well enough to even understand this argument, so could you give me my meat pie and let me go home?" I was on a barge tour in Holland last month, and the tour company put the French French and Quebec French on separate barges. The French French only had the tour guide and us English Canadians to talk to, but maybe they prefer it that way.RockyMtnGuy (talk) 11:40, 30 May 2015 (UTC)

We get it: you're super-cosmopolitan and have experienced lots of French snobbery up close. Your point being... what? Can we end this ill-begotten thread now? EEng (talk) 12:47, 2 June 2015 (UTC)

Hey, EEng, I appreciate a Roquefort bleu, a fresh croissant and a nice bottle of Bordeaux as much as the next Anglo wine snob, so let's not digress. That said, if their online newspapers are any indication, les Quebecois are not using ISO 8601 formatted date in prose, either. Nor is the Canadian government in documents on its website. This appears to be exactly what I expected: ISO 8601 is the "official" computer-readable date format for electronic files and hard-copy documents that need to be computer readable. Nothing more. Dirtlawyer1 (talk) 21:36, 2 June 2015 (UTC)

Roquefort bleu ... croissant ... Bordeaux -- that's the trouble with French. It's like they think vowels grow on trees. EEng (talk) 22:06, 2 June 2015 (UTC)

Mais, oui, monsieur. But they do damn fine food products. Beats shepherd's pie and bangers and mash every time, although I must confess a certain weakness for English beer served at 14° C. Dirtlawyer1 (talk) 23:33, 2 June 2015 (UTC)

Canadian date formats, convenience break, no. 1

So, let's see what date formats the mainstream Canadian media are using in prose:

• Calgary Herald: "June 1, 2015", "May 24, 2015" and "June 30".

• CBC: "May 17, 2015" and "May 28".

• The Chronicle-Herald (Halifax): "Aug 4. 1914 - Nov 11. 1918".

• Edmonton Journal: "December 16, 2014" and "June 1, 2015".

• The Hamilton Spectator: "May 30, 2015" and "May 31".

• Journal de Quebec: "27 mai 2015" and "15 août".

• la Presse (Montreal): "28 Mai 2015", "30 Octobre 2005" and "9 Mars 2006".

• Mclean's: "May 15, 2014" and "April 23".

• Montreal Gazette: "May 28, 2015" and "June 8".

• National Post: "June 1, 2015", "June 1" and "May 8".

• Ottawa Citizen: "June 1, 2015" and "June 11".

• Ottawa Sun: "March 18, 2015" and "May 31, 2015".

• Regina Leader-Post: "May 28, 2015" and "May 13, 1987"

• The Star-Phoenix (Saskatoon): "June 1, 2015" and May 28, 2015".

• Toronto Star: "May 28, 2015" and "July 27".

• Toronto Sun: "May 19, 2015" and "June 11".

• Vancouver Sun: "May 27, 2015" and "June 16".

• Winnipeg Free Press: "Nov. 15"

Not an English-language publication:

• Singtao Toronto "2015 5 28", with intermingled Chinese characters (in Chinese)

• Canada China News "2015 5 15", with intermingled Chinese characters (in Chinese); "May 25, 2015"

Not a Canadian publication:

• China Daily "May 29, 2015"; "[2015-05-28 19:57]", "[2015-05-28 19:52]", "[2015-05-28 16:30]" ...

That should get us started. Other discussion participants should feel free to add to the list above, with linked examples from major Canadian media of their own. I'm not finding any examples of ISO 8601 YYYY-MM-DD formatted dates in article prose of Canadian news media.

@RockyMtnGuy: It is axiomatic on Wikipedia that we follow the published sources. So, how about it? Where is your list of mainstream Canadian publications that are use ISO 8601 YYYY-MM-DD formatted dates in prose? Dirtlawyer1 (talk) 18:28, 28 May 2015 (UTC)

@RockyMtnGuy:: What does ISO 8601 say about the use of non-numeric dates, such as when the month is spelled out? Or (harkening back to your previous comment) where is the "big-endian, little-endian, middle-endian imbroglio" when someone says or writes cinco de mayo? Or any of the dates presented above? ~ J. Johnson (JJ) (talk) 19:53, 28 May 2015 (UTC)

ISO does not define non-numeric date formats since it is an international body and there are no non-language-specific non-numeric formats. Some companies I worked for, being multinational and multilingual, simply banned non-numeric formats. Others went with 2015 May 29 as their standard non-numeric date format since it is unambiguous and easily converted to numeric. The other companies really didn't have any standard, and everybody just did what they felt like. The various regulatory authorities usually mandated 2015-05-29 on the government forms since that is supposed to be the standard.RockyMtnGuy (talk) 11:40, 30 May 2015 (UTC)

It may not have been some bureaucrat in Ottawa who was pushing metrication but YYYY-MM-DD hasn't got anything to do with metrication.

Dates on cheques (yes, I can spell normally too) and dates on pages intended for reading are two different things. I used to have an RBC account and, yes, the cheques were in YYYY-MM-DD, but there were instructions on the cheque making it clear that this was how to fill in the boxes. In an everyday piece of writing there are no such thing. Okay, RockyMtnGuy, you can look at the date and if runs 20150405, you know it's 5 April. What if your cheque runs "20102012", is that 20 December 2010 or 20 October 2012? Anyway, there is no trouble if all-numeric dates are avoided.

Yes, Canada is multilingual but it's hardly unreasonable to consider Anglophones exclusively on the English Wikipedia.

YYYY-MM-DD is just not user friendly (unless you're a computer) to the typical English speaker. By "typical English speaker" I intend to include Canadians. No, I haven't done a survey and I haven't lived all my life in Canada (some of it though) and I just don't buy the argument that YYYY-MM-DD is considered the normal or standard way of writing dates. We're not writing cheques or filling out government forms here, we're writing an encyclopædia. Jimp 10:52, 29 May 2015 (UTC)

It's an ON-LINE encyclopedia. Lets try not to pretend we're illuminating parchment scrolls or that the users are computer-illiterate.RockyMtnGuy (talk) 11:40, 30 May 2015 (UTC)

Let's not assume the readers are computer literate. Wikipedia may be on-line but it's one of the most accessed sites on the web. We should expect reader who have limited experience with computers. Why write exclusively for the computer-literate anyway? We should be writing to be understood. YYYY-MM-DD is an impediment to understanding.. YYYY-MM-DD should be banned from Wikipedia. Jimp 13:46, 3 June 2015 (UTC)

Love your 20102012 example! EEng (talk) 18:49, 29 May 2015 (UTC)

Binary terns

There was no explicit statement of base, so perhaps it's in ternary. :-) ~ J. Johnson (JJ) (talk) 21:29, 29 May 2015 (UTC)

Nice try, but the ISO format is YYYY-MM-DD and the months only run from 01 to 12, so there's no such thing as 20102012. You could have 20101220, but that's unambiguous unless you're living in the 13th century. The banks also preprint the century, 20yy-mm-dd so it's doubly unambiguous. The trouble with cheque blanks that say xx-xx-20xx is that people sometimes fill them out wrong, transposing the month and day because they didn't read the fine print or didn't wear their reading glasses (stories from the treasury trenches).RockyMtnGuy (talk) 11:40, 30 May 2015 (UTC)

Yes, nice try, RMG. Do you have any examples of ISO 8601 dates in the prose of mainstream Canadian publications? Or would you like some more examples of the dominance of the MDY date format in English language Canadian publications? For the record, the French language publications are using DMY formatted dates. The only example so far of a Canadian publication using ISO 8601 in prose is written in Chinese. Dirtlawyer1 (talk) 06:37, 2 June 2015 (UTC)

Oh, and just for giggles, the Canadian government, which adopted ISO 8601 as its official date format, does not use YYYY-MM-DD dates in prose on its English language website. Here's an example [7], and there are plenty more from whence it came. It appears that the Canadian government uses ISO 8601 primarily in documents and files that need to be computer readable. Which is really not a big surprise. Are you ready to end this discussion? If anything, this little exercise demonstrates just how predominant the use of MDY dates in Canada really is. Perhaps we should be considering whether MOS should prefer MDY dates in Canadian English articles? Dirtlawyer1 (talk) 06:47, 2 June 2015 (UTC)

@RockyMtnGuy:: It also appears that there is no such thing as "January, February, .. December" (or their abbreviations) in ISO 8601. If you have information otherwise, or any information that 8601 has any applicability to non-numeric dates, please show us. Lacking that, ISO 8601 is entirely irrelevant to the DMY/MDY debate.~ J. Johnson (JJ) (talk) 22:32, 30 May 2015 (UTC)

Permanent break (I hope)

Can we end this now? The newspaper data seems dispositive on the lack of uptake of YYYY-MM-DD in general use. EEng (talk) 13:02, 30 May 2015 (UTC)

This is the first time anyone has complained for many years about the guideline that Canada-related articles can use either dmy or mdy in the main text. Tony (talk) 14:27, 30 May 2015 (UTC)

It had to happen eventually. We ring all the changes sooner or later here at Dates and Numbers. EEng (talk) 14:54, 30 May 2015 (UTC) You don't still think I insulted you the other day, do you?

Me? Where? Tony (talk) 14:55, 30 May 2015 (UTC)

How quickly they forget. EEng (talk) 15:36, 30 May 2015 (UTC)

Definition of mid-year range and more (example mid-1990s)

When someone says "mid-90s" am I correct in that it means the years 1994, 1995, and 1996, that with temperatures it means 94, 95, and 96, and in one year it means May, June and July?

Also, when someone for example says "mid-June" what days would they be referring to? --Jesant13 (talk) 04:12, 29 May 2015 (UTC)

I don't think there's a definite agreement on the precise meaning. I'd be inclined to include 93 for symmetry, though: early/low → {90, 91, 92}, mid → {93, 94, 95, 96}, late/high → {97, 98, 97}. Likewise: May, June, July and August (dividing the year into equal thirds). Similarly, mid-June would be the 11th to the 20th. But in reality, these are kind of vague concepts (often deliberately so I'd say). Jimp 11:07, 29 May 2015 (UTC)

I didn't know there were multiple definitions. I wonder if one definition should be standardized on Wikipedia. Jesant13 (talk) 16:17, 29 May 2015 (UTC)

Absolutely not! This is the epitome of a solution in search of a problem. If you can show that lack of MOS guidance on this has caused time to be wasted on the Talk pages of multiple articles, then come back with diffs. Otherwise this is one of the silliest ideas I've heard here -- pardon me but it must be said I don't think this is a good idea. (And Jimp the Chimp ;P is right -- the term is deliberately vague.) EEng (talk) 18:48, 29 May 2015 (UTC)

Concur with EEng. Terms such as "early", "mid-" and "late" are intentionally vague and it's not for us to define them. —sroc 💬 03:14, 30 May 2015 (UTC)

Jesant, I've modified my earlier comment, which I made when I was in a bad mood. EEng (talk) 12:58, 30 May 2015 (UTC)

An unlikely tale

I've started a general discussion on the Manual of Style talk page under the above heading. The issue, for example, is that the manual says that dates in British (and therefore American) history between 5 October 1582 and 2 September 1752 should not be converted to Gregorian. An editor is claiming that if consensus can be achieved to convert them they can be - just like that. I don't think that can possibly be right and should be grateful for comments on the matter. 156.61.250.250 (talk) 12:41, 23 May 2015 (UTC)

With MOS as with all guidelines, exceptions apply where consensus decides there's good reason for them. Discussion leading to such a consensus should explicitly engage the intent of the guideline and why an exception is appropriate. In the case you describe, assuming there's a reason -- e.g. detailed tie-in with events on the Continent -- to give the date in Gregorian, seems like that should probably be in addition to Julian (perhaps Julian in main text, Gregorian in parens). But those are just my thoughts -- this should be worked out on the article Talk among editors interested in the particular article. EEng (talk) 18:57, 23 May 2015 (UTC)

Query about gradient conversions

Units experts, I wonder whether you might have your say at DYK talk, where in my characteristically blunt way (I don't have much patience with the DYK process after all these years of slop) I've drawn attention to issues. Tony (talk) 15:25, 31 May 2015 (UTC)

I predict an uphill battle here. EEng (talk) 15:35, 31 May 2015 (UTC) Also, road gradients are formally dimensionless, so we units experts won't have anything to say about it. ;P

I appreciate the humour, but I'm trying to be serious. SI has nothing to say on the expression of gradients, then? Tony (talk) 15:37, 31 May 2015 (UTC)

Serious people don't keep their sanity here very long -- witness the ignoble fates of participants in the various date-format debates on this very page. I don't know for sure, and I've been unable to find anything on point in 90 seconds of looking, but I suspect SI thinks of e.g. a road gradient as just another ratio such as those I mentioned over at Talk:DYK -- m/km or ft/mi or whatever. EEng (talk) 15:52, 31 May 2015 (UTC) (I can think of a few people here who will likely have something more useful to say on this, so just stand by for a bit.)

@Tony I'd like to help if I can, but I'm not sure what not the problem is. Can you formulate the question more precisely? Dondervogel 2 (talk) 03:44, 1 June 2015 (UTC)

See Wikipedia_talk:Did_you_know#Slop_job_again. EEng (talk) 03:57, 1 June 2015 (UTC)

I've read that twice now and I'm still unsure of the question. While stating gradients in metres per mile is bizarre, it is not incorrect. MOSNUM supports other bizarre conventions, so why not this one? If you are asking me how I would write a gradient (in the sense of a steepness of a slope), the answer would probably be "1:10" for a one in ten slope, with a conversion to a percentage ("10 %"). If I wanted to adhere to SI rules I would write it as 0.1 m/m or 0.1 km/km, again with a conversion to a percentage ("10 %"). Does this help? Dondervogel 2 (talk) 10:06, 1 June 2015 (UTC)

• Tony, did this resolve your concern? EEng (talk) 17:14, 9 June 2015 (UTC)

Focusing on a problematic sentence

As OP of the thread above, I don't want to be pushing this away from what should be addressed on MoS talk pages. Since my unchallenged change to MOSNUM, I only want to bring attentions to a specific remaining sentence that makes it difficult to interpret the MoS, specifically as to whether BIPM should be used as guide on non-SI units, which may lead to issues such as above. This is the first sentence in WP:MoS § Units of measurement:

• The main unit in which a quantity is expressed should generally be an SI unit or non-SI unit officially accepted for use with the SI.

It is unclear to a reader of the MoS how much guidance is being given by "should generally be [... a] non-SI unit officially accepted for use with the SI", and in particular whether what the BIPM says should be followed. As it stands, I read this as asserting that it should (including that 'au' should be used), but I suspect that this is contrary to what EEng and others might feel it should be read. Can we change this sentence to fix this apparent disparity? Some possible ways of dealing with this may be to delete the "or ..." part, or to soften the "should" as it applies to this part, or to revise our interpretation to be that the official position of the BIPM determines the style guide on WP. Which is it to be? The only reason that I am unhappy with EEng's proposal to adopt no change to the wording is that (seems to me, anyway) there are clearly differences of opinion on the interpretation of this sentence. —Quondum 21:12, 16 June 2015 (UTC)

I interpret the sentence to mean that it is just fine to use a non-SI unit which is officially accepted for use with the SI as the main unit of measure for a quantity in a Wikipedia article. Whether the unit is accepted or not is determined by the BIPM, but it does not follow that the BIPM is in charge of the name, symbol, or definition of the unit. So an astronomy article could use the astronomical unit as the main unit of measure for a quantity, but use the symbol AU. Jc3s5h (talk) 21:29, 16 June 2015 (UTC)

Good point. "unit" ≠ "symbol". Perhaps this could be made clearer. —Quondum 21:46, 16 June 2015 (UTC)

A "unit" can be written by "unit name" or by "unit symbol". -DePiep (talk) 22:13, 16 June 2015 (UTC)

• No, they are three different things and it is helpful to distinguish between them: A unit is a thing or a concept. A unit name is the name we use to describe the thing or concept, and a unit symbol is an unambiguous representation of the concept.
• That last point is very important so I have highlighted it. The names are subject to the ambiguities and idiosyncrasies of language, but the symbols are entirely under the BIPM's control. It is the reason why the BIPM chooses a single unambiguous symbol for all SI units, and the reason it strives to find unambiguous symbols for all units permitted for use alongside the SI. (I'm not convinced that second goal is always reached). Finally, it is the reason why MOSNUM should make stronger statements than it does about preferred unit symbols.
• Dondervogel 2 (talk) 05:53, 17 June 2015 (UTC)

This is fundamentally about communicating meaning, which is language. Language isn't defined by standards bodies, and multiple words or symbols with similar or identical meanings happen all the time. The fact is that AU is much more common than au and thus likely clearer to many readers; it is certainly more clear to the majority of the editors who have discussed this (to the limited extent to which that samples readers). And a number of editors have pointed out a number of other common uses of "au", while I haven't seen any other common uses of "AU", so I don't get the ambiguity argument. The fact that both symbols are used is fine by me; if there really is a consensus to make a MOS-wide decision (which is separate from the Template:Convert options, as I think everyone but DePiep agrees), I prefer AU because it is the de facto standard (even though au is the "de jure" standard, to the limited extent that the IAU resolution is law). —Alex (Ashill | talk | contribs) 07:07, 17 June 2015 (UTC)

I agree with

• "Language isn't defined by standards bodies" [precisely my point]
• "AU is ... more common than au"

I disagree with

• "AU is ... likely clearer to many readers"
• "[AU] is ... more clear to the majority of the editors"

All that one conveys with familiarity is the impression of clarity, not clarity itself. My point about ambiguity is that au is defined (by the IAU and BIPM) and (for as long as MOSNUM remains silent on the issue) AU is not. Hence my continuing preference for au for as long as this matter is unresolved. Dondervogel 2 (talk) 07:29, 17 June 2015 (UTC)

Clarity does not stem from official sanction, but from the user/reader being familiar with the unit and having (mostly) seen one symbol for it, in this case "AU". --JorisvS (talk) 09:33, 17 June 2015 (UTC)

I agree with the sentiment of this post of JorisvS, though I would have phrased it differently. Seeing one unique symbol for a unit is indeed the key, with the caveat that that symbol be clearly defined. The way to achieve both consistent use and clarity of definition is via MOSNUM. That's what MOSNUM is for. Dondervogel 2 (talk) 09:46, 17 June 2015 (UTC)

Agreed, I have finally made up my mind that it is indeed better to describe this situation explicitly in the MoS. --JorisvS (talk) 10:02, 17 June 2015 (UTC)

I largely agree, though I think that it's best to define whatever symbol is used at first use (as Nature and Science both do, though a wikilink probably suffices in many contexts on Wikipedia) since neither au nor AU are nearly as familiar as m, km, or mile. Furthermore, if we define the symbol at first use, the need to be consistent across Wikipedia is much less (though the need to be consistent within an article remains). The definition in the MOS is obviously of little direct help for readers. —Alex (Ashill | talk | contribs) 13:49, 17 June 2015 (UTC)

You've got a point. And, yes, I can think of many articles where spelling it out would be over the top. I think that noting the situation with "AU" vs. "au" in the MoS and stating WP's preference and why is still helpful (obviously not really to readers, but to editors), but it makes sense to also advise to add a wikilink to the article and, for the more visible articles, to spell it out. --JorisvS (talk) 14:15, 17 June 2015 (UTC)

I was going to suggest that this be added to the MOS, but it's already there for all units, not just non-SI ones: "In prose, unit names should be given in full if used only a few times, but symbols may be used when a unit (especially one with a long name) is used repeatedly, after spelling out the first use (e.g. Up to 15 kilograms of filler is used for a batch of 250 kg)." But as evidence of how over-prescriptive the MOS is, it took me a while to find this while looking for it. —Alex (Ashill | talk | contribs) 14:36, 17 June 2015 (UTC)

Okay. I managed to find it pretty quickly, though, thanks to the structure of the page. Given its structure, it would be a straightforward matter of adding a row to the table under "Specific units", including the comment that I described above. This would not really increase clutter on the page, nor make other things harder to find. --JorisvS (talk) 14:53, 17 June 2015 (UTC)

• While MOS is supposed to control in case of conflict with MOSNUM (just as with conflict between MOS and any of its subsidiary pages), in fact MOSNUM has been drifting away from MOS, in various details, for some time. No one seems to care for the moment, though if push comes to shove the ueber-MOSsers who hang out at Talk:MOS will probably scold we MOSNUM little people for letting that happen. I fear this thread will force a showdown to resolve the stress between the two pages, much as an earthquake relieves pent-up stress in the earth's crust (or whatever it is an earthquake does). EEng (talk) 21:57, 16 June 2015 (UTC)

re Quondum: I don't see the point. Instead of asking clarification for the "should genrerally be", you propose to water it down to your possible misunderstanding/unclearity? Or else, can you re-describe the problem you see? For me there is none, so far. -DePiep (talk) 22:04, 16 June 2015 (UTC)

Oh and I challenge (reverted) your MOSNUM edit. Jee, editing a MOS page to fit your own discussion? -DePiep (talk) 22:06, 16 June 2015 (UTC)

I am asking here for an interpretation of the MOS, as it stands. I pointed out the areas of uncertainty as I see them: the edit you just reverted, plus that mentioned here. DePiep, please interpret for all of us what you think it means? For example, what does it say about use of units mentioned by BIPM for use with SI? I would appreciate interpretations by others, too. And please do not back out of this with claims of forum shopping. You have engaged on this page about an issue relating to wording of the MoS. —Quondum 23:37, 16 June 2015 (UTC)

I have restored Quondum's version. "Chapter 4... give[s] additional guidance on non-SI units" misrepresents the source, which says that non-SI units are not recommended. Therefore, the previous version is just wrong. "Chapter 4... give[s] additional information on non-SI units" is a more accurate representation of the source. I disagree strongly with the characterization of the edit; it was to better reflect the source, not fit any editor's particular view. —Alex (Ashill | talk | contribs) 07:01, 17 June 2015 (UTC)

Reverted before arriving here, see my es [8]. I think "guidance" may be even a little stronger, but alas. -DePiep (talk) 09:13, 17 June 2015 (UTC)

I disagree with Dondervogel 2's statement above "The names are subject to the ambiguities and idiosyncrasies of language, but the symbols are entirely under the BIPM's control." Actually, symbols used for the sale of goods and services in commerce are under the control of government weights and measures officials, who ultimately have the power to use force to enforce their laws. Other unit names and symbols are controlled by the consensus of language speakers. Even in a more metaphorical sense, it is highly questionable whether BIPM has control over symbols that are not part of SI or the metric system, even if the BIPM does list them as acceptable for use with SI. Jc3s5h (talk) 11:02, 17 June 2015 (UTC)

Quite. If the BIPM had control, then their 2006 statement that the symbol is "ua" would have transformed usage by agencies (NASA, ESA, etc), publications (Astronomy & Astrophysics, Astronomy Now, etc) and professional bodies (IAU, AAS, etc), and would not have been reversed by BIPM themselves. NebY (talk) 11:28, 17 June 2015 (UTC)

I stand by my position on this. When the BIPM switched from ua to au, it was their decision to do so. That is what I understand by "control". I did not mean to imply they control the symbols used by others, as they clearly do not control MOSNUM, to give a relevant example. They do not control MOSNUM, but we do, collectively, and if we choose to we can use that control to do some good. Dondervogel 2 (talk) 11:39, 17 June 2015 (UTC)

Use of Val template for formatting MoS

I was asked to explain the rationale for removing the use of {{val}} for formatting examples in the MoS.

• Examples often serve to disambiguate the meaning; when in apparent conflict with the wording, someone might even update the wording to match the example. It literally becomes difficult to determine what the intent was when the template changes its formatting, so it is like walking on shifting sands.
• Template:Val has been undergoing substantial changes in the last few weeks; it has frequently broken in this time, causing display errors in the examples of the MoS. This is how I noticed it in the first place. This template is still in state of flux (i.e. it is unstable, and is always subject to the vagaries of editors of its subtemplates. I consequently regard it as unsuitable for style examples.
• At the time the {{val}} template is inserted by an editor, certain default behaviour it has at the time might be relied upon in an example, but the defaults can change (e.g. under what circumstances a four-digit number will have a gap inserted). This may have been the case for the example that EEng removed rather than trying to resolve the intent.

EEng, I think that you equally can be called upon to explain why a MoS page should be subject to insertion of text or subtle changes by an editor who is unaware that what they do can affect the MoS, often without being noticed. My argument is that problems arose as a result of its use, and I was preventing a recurrence. —Quondum 17:42, 20 June 2015 (UTC)

I removed the example of 1010th because it seemed to imply that ordinals should be formatted a certain way, which I don't think is true, so I thought leaving this to editor discretion, applying the other rules elsewhere, would be best.

I understand the argument that changes to val could modify the very examples which, circularly, explain how val works, but that applies to a lot of stuff in MOS. Unfortunately we have to rely, to a large extent, on people who tinker with templates knowing what they're doing and being careful; fortunately, that turns out to be what happens most of the time. The examples have been presented the way they are for quite some time, so I'd feel better if others who understand that technical details weigh in before making such a sweeping change. EEng (talk) 18:34, 20 June 2015 (UTC)

And I'd feel better if you were not so trigger-happy with reverting carefully considered changes. I made no change to the display of the MoS, or if I did, it was inadvertent. The one where I was unsure, you've removed (and I agree with that removal). It is still up to you to show that you had a reason to revert, and the only good reason would either be a refutation of my reason, or that I had introduced a change that needed discussion. You have not addressed my issue: template val is currently under maintenance (which rebuts your claim that it has been in use); you have also misaddressed the circularity issue: we are giving examples of acceptable formatting, not explaining how val works. We are only mentioning incidentally that val can be used for such formatting. As a part-time val maintainer, I have been faced with the problem that can no longer be sure of exactly what was intended in the MoS, because val is used for formatting the examples that I look to to see what val should be doing.

Please explain what you mean by a "sweeping change". I would describe a change that makes no visible change as minor, not sweeping. —Quondum 21:42, 20 June 2015 (UTC)

Calm down. In a high-visibility document like MOS, conservatism rules and consensus is more important than elsewhere. If you're really certain your edit makes no change to what the user see here in MOS (but I had no way of knowing you're some kind of expert on that) then that's great. But I'm puzzled: doesn't val have its own test cases? Are you really making changes to val such that you're not sure whether its output has changed? EEng (talk) 23:29, 20 June 2015 (UTC)

Val is a relatively unused template (less than 1300 articles, 300 pages in template space, 100 in WP space). It does not seem to have thorough test methodology, and a few editors are valiantly tackling a major revamp, with a conversion to Lua on the cards. As you have discerned, I'm not cut out for the interaction in this space, so I'm removing the WP: space from my watchlist. I think we'll both be more comfortable that way. —Quondum 01:29, 21 June 2015 (UTC)

Um, I hadn't discerned anything. Your help is welcome. If you say you're sure your edit didn't make any unintended changes, then together with the many eagle eyes usually on the case here, that's certainly good enough for me. EEng (talk) 01:50, 21 June 2015 (UTC)

Use of ndash and nbsp

It's my understanding that, for some time now, dates of birth and death in the opening sentence of an article take the form "12 February 1809 – 19 April 1882", the ndash being provided under the edit box, rather than "12 February 1809 – 19 April 1882" There is no need that I can see to have markup for the n-dash, and virtually never any need for a non-breaking space when the dates come immediately the subject's name at the very start of the article. Yet this MOS still states that wiki or html markup should be used. The guideline is being followed, though not always fully: see here and here. Should the MOS not be updated in line with changes over the last ten years? Scolaire (talk) 17:54, 19 June 2015 (UTC)

Some people don't know how to make dashes. When I point out that en-dash is the first of the links under the edit box (which are properly called the charinsert gadget), they've either not understood its significance, or simply never noticed that it's there. --Redrose64 (talk) 19:52, 19 June 2015 (UTC)

I don't understand what the concern is exactly, but depending on font and so on it can be very difficult to distinguish hyphen from endash in the edit window; thus using some symbolic form of endash, rather than literal, makes it easier to be sure that the character present is the right one. {{snd}} ("spaced endash"), which gives an nbsp + endash + regular space, is compact and convenient. It's true that nbsp is probably not needed in the usual opening words of a bio, but bothering to special-case that makes no sense at all. EEng (talk) 22:06, 19 June 2015 (UTC)

"They've...simply never noticed that it's there": that's precisely why it should say in the MOS that it's there, and that it's there to be used. If some people don't understand, too bad; it's not a reason for not saying it. At the moment the MOS seems to prohibit the n-dash character and say we must use markup. Likewise, there's no harm is saying the {snd} is available, but the MOS shouldn't appear to be mandating it when most people are happier just using space-dash-space. I think it's stretching it to say that the dates in a bio is a "special case" when it applies to every single biography, and the example in the MOS that I quoted above specifically refers to a biography: "Charles Robert Darwin (12 February 1809 – 19 April 1882) was an English naturalist ..." Again, the MOS seems to be saying, "this is how it will appear but you mustn't type it that way." Scolaire (talk) 22:37, 19 June 2015 (UTC)

{{snd}} is simple and easy, and it's easy to tell that a hyphen hasn't snuck in. I really don't get your complaint. If you want to suggest a change to the guidelines, go ahead. EEng (talk) 00:04, 20 June 2015 (UTC)

Essentially, what I'm saying is that a manual of style should be something that is followed in reality, rather than what some editors think would be ideal practice. I regularly see copy-edits to articles on my watchlists where text or hyphens are replaced with "–", but this edit, that I linked to previously, is the first time in literally years that I have seen a "&ndash" added, and I was amazed to see the edit summary of "per WP:MOSNUM". Following the initial posts here I looked at eleven current, recent and forthcoming Featured Articles. Eight of those – HMS Nairana (1917), Blue's Clues, Robin Friday, Stanley Savige, L'Arianna, Augustinian theodicy, Drowning Girl and Battle of Labuan – use the simple dash; two, Ian Craig and Carl Nielsen, use {spaced ndash}; and one, AMX-30E, uses &ndash. In addition, Robin Friday, Stanley Savige and Drowning Girl have an &nbsp before the dash but not after, or between day and month or month and year. In other words, the Manual of Style is at odds not only with regular practice but also with Featured Article criteria. I can't see the benefit of that to anybody. Scolaire (talk) 10:43, 21 June 2015 (UTC)

I don't know where this puts me in the debate, but there are bots which remove non-breaking spaces, claiming compliance with WP:MOS. I'm not sure exactly where that appears, but it is problematic for two subpages of WP:MOS to contradict each other. I think we should encourage use of templates such as {{snd}} where appropriate. — Arthur Rubin (talk) 01:29, 22 June 2015 (UTC)

You may be thinking of the mindless scripts and bots which remove e.g. nbsp from references, claiming that they "contaminate the COinS metadata" -- see Template:Citation#COinS. This is nonsense of course, since obviously it would be easy to simply map nbsp to regular space, remove italicization and bolding, etc. before outputting the metadata, but nonetheless we have gnomes running around removing careful formatting from references in the belief they're improving something. I've even run into people changing {{ndash}} to &ndash; because (they say) "templates contaminate COinS", when obviously this makes no difference at all. EEng (talk) 02:55, 22 June 2015 (UTC)

Proposed edit

• A pure year–year range is written (as is any range) using an en dash, not a hyphen or slash. The en dash is the first of the "Insert" links under the edit box, or it can be coded as – or {{ndash}}. The dash is usually unspaced (that is, with no space on either side), and the range's "end" year is usually abbreviated to two digits:

  •   1881–86;  1881–92 (not 1881–6;  1881 – 86)

Markup: 1881{{ndash}}86 or 1881–86

...

• If at least one of the items being linked is in a "mixed" format (containing two or more of day, month, year), carries a modifier such as c., or otherwise contains a space, then there should be a space before and after the en dash. The spaced en dash template ({{snd}}) can be used:

• between specific dates in different months: They travelled June 3 – August 18, 1952;  They travelled 3 June – 18 August 1952
• between dates in different years:

Charles Robert Darwin (12 February 1809 – 19 April 1882) was an English naturalist ...

Markup: 12 February 1809{{snd}}19 April 1882 or 12 February 1809 – 19 April 1882

Abraham Lincoln (February 12, 1809 – April 15, 1865) was the 16th President of ...

• between months in different years: The exception was in force August 1892 – January 1903;  The Ghent Incursion (March 1822 – January 1, 1823) was ended by the New Year's Treaty

Markup: March 1822{{snd}}January 1, 1823 or March 1822 – January 1, 1823

Scolaire (talk) 10:43, 21 June 2015 (UTC)

• Oppose You're suggesting that the first space in a spaced ndash should be a regular space instead of nbsp. If this is going on in FAs then -- surprise! -- FAs aren't perfect. I looked at some of the articles you linked and I can't tell what you're talking about. You seem to be mixing up the question of literal-versus-symbolic with nbsp-versus-space with I-don't-know-what. This continues to be a solution in search of a problem AFAICS. EEng (talk) 12:39, 21 June 2015 (UTC)
  • Nobody has bothered to explain to me why the first space (specifically) in a spaced ndash should be non-breaking rather than a regular space, or where this rule is written down or where and when it was agreed. It's a very small part of my proposal and can easily be amended if the rationale for doing so is spelled out. You can't tell what I'm talking about? It couldn't be simpler: 70% of those Featured articles (and probably a far greater percentage of articles in general) don't use wiki or html markup for date ranges, so what is the point in mandating its use in the MOS? I'm not mixing up anything with anything with anything. And FAs aren't perfect. Does that mean the MOS is perfect? Are the editors who brought them to FA standard and the people who promoted them wilfully disobeying some God-given law? Or if there was some community consensus on it can you link me to it? AFAICS it is this part of the MOS that is a solution in search of a problem. I am also getting a strong sense of ownership here. Scolaire (talk) 13:10, 21 June 2015 (UTC)

The nbsp prevents the ndash from coming at the start of a new line, which looks bad. As with anything else in MOS, if you want to see the discussion about it you'll have to search the Talk archives. This provision way predates me so ownership has nothing to do with it. (I also don't think God had anything to do with it, but if you find something in the archives along those lines we should notify the media.)

As mentioned before, literal ndashes are hard to distinguish from hyphens in the edit window (in at least some editing environments) so symbolics like & ndash; and {ndash}/{snd} are preferable. This isn't any kind of rule but MOS might as well encourage good practices like that. We certainly shouldn't be saying stuff like "It's the first character in the list when you select Foo from the dropdown of the ...", which can change.

Neither MOS nor FAs are perfect, obviously. I doubt anyone working on FAs is willfully ignoring MOS, but MOS is big and complex so a lot of minor stuff gets overlooked. We can but try. EEng (talk) 13:57, 21 June 2015 (UTC)

I have searched the archives using every combination of search terms I can think of, but I can't find any discussion where it is agreed, or even proposed, to use markup rather than either literal n-dashes or literal spaces. While I understand what you're saying about a non-breaking space before an n-dash – and thank you for explaining it to me – it's not actually written anywhere in the MOS. That, and the absence of any evidence of discussion or consensus, makes me wonder how authoritative your statements on that or on the n-dash are, which in turn makes me wonder just how much of the MOS is built on sand. Having said that, I know that an ordinary Joe suggesting that a MOS might be made more relevant to the actual writing of articles has no chance against a Guardian of the Sacred Text, so I won't bother you further; I'll leave you to your cozy discussions of arcane matters. Goodbye and happy editing. Scolaire (talk) 10:09, 22 June 2015 (UTC)

I made no claim to authoritativeness, but merely explained what I know. Many things in MOS were added boldly long ago, and have never been challenged. If you want to argue that the improvement in appearance from using nbsp isn't worth it, then go ahead. (Your next step should be to search the edit history to find who added this provision, and when, and to see how other editors reacted at the time.) Otherwise, someone has to deal with these arcane matters, and if you're not up to it, please don't impugn those who are. EEng (talk) 12:26, 22 June 2015 (UTC)

I have argued that the improvement in appearance from using nbsp isn't worth it. It doesn't require any search of the archives for me to do so. If nobody can remember any previous discussion then any previous discussion is irrelevant. It's merely a matter of discussing current proposals on their merits. You haven't done this: you have rather pompously dismissed the whole thing on the basis one or two small details. And I did not impugn anybody for discussing arcane matters. My problem is that people will not take time out from discussing them to deal honestly with a silly rule that affects literally millions of articles. But as I say, I know I am a lone voice so I am not going to push it further. Feel free to give me another slap-down; I won't respond next time. Scolaire (talk) 07:10, 23 June 2015 (UTC)

• I have argued that the improvement in appearance from using nbsp isn't worth it. I can't see how, since until my post a moment ago you apparently didn't even understand what the nbsp was for.
• It doesn't require any search of the archives for me to do so. Yeah, it really does. To ignore prior discussion is to reinvent the wheel.
• If nobody can remember any previous discussion then any previous discussion is irrelevant. Nonsense. If living memory were the outer limits of what's valuable then we wouldn't bother with libraries‍—‌or encyclopedias, come to think of it. It's why discussions are archived.
• You have rather pompously dismissed the whole thing on the basis one or two small details. I don't know about pompous, but I opposed the proposal because the two substantive things I could see it did‍—‌endorse the use of literal ndashes, and remove the specification that ndash be preceded by nbsp‍—‌were bad ideas, IMO for reasons I stated. If there's more to your proposal I didn't see it, undoubtedly because you just posted a long chunk of proposed replacement text without telling us what in it represented a change.
• I did not impugn anybody for discussing arcane matters. Yeah, you did: "I'll leave you to your cozy discussions of arcane matters."
• I know I am a lone voice. Perhaps you should think about why that is. EEng (talk) 07:33, 23 June 2015 (UTC)

"1930s and 40s"

The MOS wording for decades is currently "always use four digits". I've started adding the century to two-digit decades. One of my edits has been reverted, so I'm stopping to ask for advice. Should the MOS wording be relaxed a little? Consider expressions such as "1930s and 40s" [no apostrophe], "1930s and '40s" [apostrophe], or where, as in Black genocide, the "'50s" is further away from the preceding "19" but still clear in context. (Pinging Binksternet) -- John of Reading (talk) 18:28, 23 June 2015 (UTC)

As you're asking for purely personal opinion rather than interpretation of guidelines, I'll give my personal opinion. I think "1930s and 40s" is fine for conversation and informal writing but lacks encyclopedic tone. I would avoid it for the same reason that we avoid contractions. If someone could cite a few examples of such usage in a major printed encyclopedia, I could be swayed. ―Mandruss ☎ 18:38, 23 June 2015 (UTC)

Binksternet, I was going to comment, but Mandruss has already perfectly encapsulated my thinking on point. Dirtlawyer1 (talk) 18:49, 23 June 2015 (UTC)

When talking about decades, natural speech trims the century as much as possible in context, with that context often remaining unspoken. Written English requires the context established, but after that is accomplished, I think our writing can follow natural speaking style. I'm in favor of allowing two-digit decades once context is established with four digits, especially if two or more decades are in the same sentence, as in the above-linked example. Otherwise our writing is stilted, dissimilar to speech. Binksternet (talk) 18:54, 23 June 2015 (UTC)

The same argument could be applied to contractions, but we don't do so (do not do so). Encyclopedic tone sometimes sounds stilted, and that's just how it is (that is just how it is). ―Mandruss ☎ 19:10, 23 June 2015 (UTC)

• I'm absolutely with Binksternet. In general two-digit decades sound too informal, but there are times when insisting on repeating 19xx over and over is excessive. Every MOS page carries a boxed qualification, "Use common sense in applying it; it will have occasional exceptions", and the example linked in the OP is an excellent example of a place where such editor discretion is appropriately applied. There's almost nothing on which absolutely rigid prohibition is appropriate (and that includes, BTW, contractions). And no, we should not be writing anything that all recognize as stilted if there's some way to fix that by bending the rules. Good flow is paramount.

"Encyclopedic" vacuously means "Wikipedia should employ style appropriate to Wikipedia", which of course helps not at all. I wouldn't be surprised if no other encyclopedia ever says "beginning in the 1940s, though the 50s, and ending about the mid-1960s", but I wouldn't be surprised if NYT did say such a thing, and I think it's appropriate for WP to mix a little bit of the slightly more accessible style of NYT in with our otherwise Britannica-ish aspirations. EEng (talk) 20:37, 23 June 2015 (UTC)

Yes. Though I would add that "style appropriate to Wikipedia" is usually based on individual editors' personal sense of "appropriate". ~ J. Johnson (JJ) (talk) 21:34, 23 June 2015 (UTC)

That's what I mean: encyclopedic is just a fancy way of saying "in my opinion, for reasons I can't verbalize". EEng (talk) 21:36, 23 June 2015 (UTC)

Fine. Then let's throw out the advice against contractions, using precisely the same reasoning. I can't verbalize why we shouldn't use contractions, nor can anyone else, and contractions make the language flow more naturally, like conversational speech. Can you reasonably support "1930s and 40s" while opposing contractions? I don't see how. They are both elisions that our language has invented for the purpose of brevity, with no material difference. Finally, do I really need to clarify that I'm not suggesting or supporting a 100% prohibition, given that there is no 100% prohibition on virtually anything in Wikipedia content? Of course there are well-reasoned exception cases, but the example in the OP's diff is not one of them. ―Mandruss ☎ 00:02, 24 June 2015 (UTC)

No, let's not throw out any of the guidelines; rather, let's remind ourselves that they are guidelines, not barrier walls. What to do about OP's example we should leave to the editors of that article. On a minor point like this the universe will not collapse onto itself if an exception is made locally that centralized discussion, with full consideration of all points and consideration, might decide the other way. EEng (talk) 01:37, 24 June 2015 (UTC)

Let's also remind ourselves of some other things. The question raised in this thread was whether we should relax the current guideline, and I suggested no, nothing more. I gather you agree, awesome. Only at Wikipedia can two people in agreement argue with each other. There is no local consensus that gives Binksternet's preference any more weight than mine, and "editors of that article" is not a useful concept here. Absent local discussion of this specific question, we are all editors of that article, simply having our article talk discussion outside of article talk. I don't need to be familiar with the topic of black genocide to have an equally valid opinion about whether the form "1930s and 40s" should be used there; that question has nothing to do with black genocide. ―Mandruss ☎ 02:05, 24 June 2015 (UTC)

The OP did ask whether the guideline should be relaxed, but if you look closely you answered a slightly different question i.e. whether two digits would ever be acceptable (either under a changed guideline or as an exception to an unchanged general guideline).

I disagree with you -- there are plenty of places where people who agree with each other can argue. (Discuss.)

By "editors of that article" I mean people who spend some substantial time on it and who are doing more than dropping in to blindly apply some minor guideline. BTW, the phrase in the OP is quite different from the one you keep quoting -- it's "Because of this racist reaction, sterilization of African Americans increased from 23% of the total in the 1930s and '40s to 59% at the end of the '50s, and rose further to 64% in the mid-1960s." (There are other problems with it, of course, which need not concern us here.) EEng (talk) 02:30, 24 June 2015 (UTC) Still friends?

I think I've stated my case adequately — and it would be even more pointless to go all meta about the meaning of guidelines, Wikipedia, and Life itself — so I'll leave it there. My mind has not been changed on this question; I'll leave that article alone, but, if I happen across other such usage, I'll boldly fix it per existing guideline. (And who knows, someday I might happen across that article; I do roam a lot.) Of course still friends, we go way back! ―Mandruss ☎ 02:54, 24 June 2015 (UTC)

Hey, have you visited the museums lately? EEng (talk) 02:40, 25 June 2015 (UTC)

Dateranges using AD

Could it be that section WP:DATERANGE needs to be corrected?

Currently

• starting year before 1000 AD: 355–372 (not 355–72);  95–113;  95–113 AD;  982–1066;  2590–2550 BCE;  1011–922 BC

Should be

• starting year before AD 1000: 355–372 (not 355–72);  95–113;  AD 95–113;  982–1066;  2590–2550 BCE;  1011–922 BC

As per lead of Anno Domini, AD is leading the year number, not trailering it. So the part of the statement written in boldface is obviously wrong (1000 AD→AD 1000). I presume that this rule also applies to date ranges, so AD 95–113 would be better than 95–113 AD, but since I cannot be sure, I post it here on the talk page rather than to edit the section myself. Cheers, Rfassbind -talk 01:09, 8 July 2015 (UTC)

See WP:ERA: AD may appear before or after a year. Some style guides insist that AD come "before", others "after", but (in an unusual display of flexibility) WP allows either. EEng (talk) 02:23, 8 July 2015 (UTC)

Thank you for your quick reply. Too bad I didn't notice WP:ERA. As for the article, Anno Domini, the given example and the corresponding note saying "Just as '500 in the year' is not good English syntax, neither is 500 AD; whereas 'AD 500' preserves syntactic order when translated (Chicago Manual of Style 2010, pp. 476–7; Goldstein 2007, p. 6)." let me jump to the conclusion that indeed the example in WP:DATERANGE wasn't correct. Sorry, for my confusion. At least I learned that AD and BC are always written in upper case, unspaced, without periods, and separated from the year number by a space in WP... -- Thx again, Rfassbind -talk 03:12, 8 July 2015 (UTC)

My pleasure; it's a refreshing change of pace for a MOSNUM thread to not immediately result in swords being unsheathed and battle lines drawn. The stuff about "preserving syntactic order" is the kind of hyperfussy nonsense taught by Mrs. Snodgrass in the 7th grade -- ridiculous, because no one's going to translate AD any more than they're going to translate pm in a time of day. EEng (talk) 03:40, 8 July 2015 (UTC)

A "date range" template?

Is there a date range template similar to this on WikiPedia? I couldn't find one. Basically, I'd like a combined "start date" and "end date" template with range written in text. For example 9–10 July 2015 and 12 November–13 December 2015. TheBigJagielka (talk) 14:13, 9 July 2015 (UTC)

How will a template help when you can just type the text yourself? EEng (talk) 16:46, 9 July 2015 (UTC)

Proposal: Stop recommending the Unicode minus symbol

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was a consensus to continue using the Unicode minus symbol for negative and minus. Even the nominator changed to this view, resulting in 0 editors in favor of the proposal (other than, in theory, the original author of the essay). There's also a consensus to userspace the essay. [Non-admin close by nominator, rescinding proposal.]  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:58, 27 July 2015 (UTC)

---

This is a procedural nomination, on behalf of User:Wikid's essay, Wikipedia:Avoid unicode minus and use numeric keypad minus. The full text of the essay can serve as the proposal, to exclusively recommend the hyphen-minus (keyboard minus) not the special Unicode minus glyph. Don't fixate on every quibble in this, just the main proposal:

In the Wikipedia Manual of Style, the paragraph "Minus signs" failed to mention the 40-year standard of the minus-key on a numeric keypad, which is what the Wikipedia MediaWiki system uses for negative numbers. The paragraph should have been written to prefer the keypad minus-sign, but to also allow using "&minus;" in some cases:

Minus signs // "Do not use an en dash for negative signs and subtraction operators: the preferred sign is the minus-key on the numeric keypad of a computer keyboard (same as the hyphen), which has been a keyboard standard for over 40 years, and it is also the result generated by Wikipedia, as in subtracting 9 - 10: {{#expr: 9 - 10}} (to yield "-1"). The unicode character for the minus sign (&minus; as "−") could be used for some display purposes. However, the hyphen is preferred when searching a page for negative numbers (matches keypad "-"), or when calculating negative results in a template, or when sorting numbers."

The use of "&minus;" (during 2007-2009) [still true, and today also effects parsing of strings as numbers by WP:Lua modules. – SMcCandlish] has led to templates generating unusable negative-numbers which will not match a numeric-keypad search, and will NOT sort numerically in sortable tables specified using class="wikitable sortable". However, the WP:MOS standard could be changed in later years, to prefer &minus when the world's keyboards change most numeric keypads, but I don't think that should be stated in the MOS, because of the decades of waiting.

Meanwhile, the template {{msym}} can be used to alter the font and display a keypad-minus (or hyphen) in a font that appears like a unicode minus, such as Courier font. Compare the example of "-3" with {{msym}}3 versus &minus;3:  "-3" with "−3" versus "−3". When searching a page for a hyphen-minus or negative number, then any unicode-minus on the page will fail to match, while any msym-style minus will match.

The template it referred to would need to be create or recreated, or the recommendation to use it deleted.

If the proposal is not carried, the WP:ORPHANed essay should be MfD'd to be userspaced or deleted.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:55, 22 July 2015 (UTC)

Support

• Support the core proposal, not the nitpicky specifics. Changed to Oppose, effectively rescinding the proposal. I'm a huge fan of using the proper Unicode glyphs for things, when it is practical. However, the search and automated parseability problems here seem non-trivial (I've encountered the problem myself in dealing with regular expressions in Lua modules.) This change would be consistent with our deprecation of curly quotes for the same and similar reasons. [Aside: I don't entertain any "not enough editors do it anyway" argument; not "enough" editors follow any style rules of any kind, but MOS remains important, and its principle purpose is establishing best practices. It's secondary one is guiding WP:WikiGnomes in cleanup efforts, and this is proper: Editors creating new content should not need to futz over style minutiae when bots and style tweakers who prefer to do that work sometimes can clean up after them. So, please avoid that lame argument.]

  A problem with one nit-picky specific, is that the widen-the-character idea is a poor one, because the resulting rendered character will be hard to distinguish from a dash.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:56, 22 July 2015 (UTC)

  PS: I have no "dog in the fight" and do not care in any emotional way what version of "–" vs. "−" we use. I'm just supporting the essay's underlying rationale on logical usability grounds. The "we should use the Unicode character because it exists" rationale isn't compelling in the face of the problems that it can cause. But they're not frequent problems or very widespread ones, so maybe the cost is worth it. I'll be fine with either result, but am not quite neutral.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:42, 26 July 2015 (UTC)

Oppose

• Oppose, if I'm understanding this correctly. A key isn't a symbol, so can you please tell us what symbol it is you think we should be using? On every computer I've used at home or work, the symbol generated by the minus key on the numeric keypad is an ordinary hyphen, as it has been since before there was a Unicode, and before anyone had proportional typefaces on their computers, so neither minus signs nor en dashes even existed on them. If that's what you feel we should use, well, typographically, it's too short. And it won't help searches anyway.

Search engines normally don't distinguish punctuation like hyphens, from word breaks. An initial hyphen is sometimes a special case, meaning "find pages that don't have the term to which the hyphen has been affixed". For example, "-hello" means "return only pages that don't have the word 'hello' on them". Indeed, I just ran a Wikipedia search on -30, returning 3.8 million articles. Of the ones I looked at, none had either "30" or "-30" on them.

As the redlink shows, there is no template {{msym}}. I don't understand how rendering anything in Courier or other monospaced font would make it look longer than a hyphen anyway. —Largo Plazo (talk) 11:52, 22 July 2015 (UTC)

"Symbol" isn't the right word either. It's about glyphs. This was already explained in the original text (which I repeat is not mine), but to re-explain it: The glyph we arguably should be recommending is the one that 99.999^-% of the world uses for "minus": -, a.k.a hyphen, a.k.a. hyphen-minus, a.k.a. the glyph produced by the - keys on virtually every keyboard in the world (both in the main keyboard and, when present, the numeric keypad on the side). It's also the one that virtually all software and programming languages use for minus (i.e. for negative and for subtraction). The one to not use the − Unicode character for minus, which you can find in the "Insert" editing tools below the WP edit window (it's between ± and ×.

Code does distinguish. But so do search engines. Here's a simple demonstration that they don't do what you think they do: [9][10]. Most of them drop (or use for specific things, like exclusion) the - hyphen. But most of them do not drop Unicode characters outside the basic ASCII range, but treat them as literals. It would be insanely tedious to code a search engine to drop every "symbol" its coders arbitrarily decided wasn't alphanumeric "enough". In-page search also distinguishes these characters, in every browser I have.

If you're not inclined to support, I request that you switch to neutral until you've had time to investigate the matter in more detail. (And the proposal itself; I already addressed the fact that {{msym}} is missing. :-) 'I don't understand' is not a rationale for "oppose". To explain that point you flagged, the monospace font will usually do this because all glyphs in such a font are the width of the font's widest character, while in a proportional font, hyphen-minus is never that wide.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:48, 22 July 2015 (UTC)

Actually it is about symbols rather than glyphs. U+0016 represents the character/symbol "lowercase a". The glyph for this character varies by font; in particular the right downstroke may or may not extend above the closed loop. In a fixed space font, the glyph for a hyphen (U+002D) is usually the same as the glyph for a minus sign (U+2212), but they are different characters. Peter coxhead (talk) 14:49, 22 July 2015 (UTC)

Your links to search results pages showing what Google returns for searches on a hyphen in isolation, or a Unicode minus in isolation, are irrelevant, since you are talking about searchs for negative numbers, and I already explained to you what happens when you try to search for a negative number where the symbol you use to indicate the negativity is a hyphen. By the way, glyphs includes symbols, letters, numerals, etc. The kind of glyph that a hyhen is, is a symbol. —Largo Plazo (talk) 15:01, 22 July 2015 (UTC)

Code conventions don't bear any relevance to this discussion because we don't write Wikipedia articles to look like this and because here we also properly write a × b instead of a * b, as well as 2¹⁰ instead of the typical code expression 2^10 (or 2**10 as in Fortran, if I recall correctly).

"I don't understand" is a euphemism for "Maybe there's an outside possibility that I'm missing something but I doubt it". I will express my conclusion based on my view of the situation and as I see fit. —Largo Plazo (talk) 16:31, 22 July 2015 (UTC)

This "glyphs vs. symbols" stuff is a distraction; all three of us commenting on these words and their distinctions apparently come from backgrounds where these words have different meanings. It's clear we all do understand that we are talking about the difference between "-" and "−".

Code vs. prose: I addressed this in a comment below, but short version is: we have in the prose in many articles, and there are templates and other code that work on strings as numeric data and put it back out as strings, so it does matter. This idea that "never the twain shall meet" is an illusion.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:42, 26 July 2015 (UTC)

Oppose. If you want to have a minus sign, then you need to use the minus sign. The only allowable exception is in code, because code is designed around a hyphen-minus for the minus sign. This is already mentioned. No change to the current wording is required or desired. Headbomb {talk / contribs / physics / books} 13:49, 22 July 2015 (UTC)

And that essay needs to be userfied. Headbomb {talk / contribs / physics / books} 13:55, 22 July 2015 (UTC)

Or just deleted; I'd leave that up to MfD.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:57, 22 July 2015 (UTC)

Oppose I write and check computer code and also moderate public examination questions in Computer Science. In code, of course the hyphen is used (ultimately because computer languages go back to typewriter fonts, which didn't have a minus sign). In examination papers, when a proportional font is used, whether for code or for mathematical formulae, the glyph for a hyphen is too short and looks wrong for a minus sign. In my experience, those writing and editing examination papers generally seem to substitute an en-dash (U+2013), I guess because for most people it's easier to input. The use of en-dash for this purpose causes the same problems as the correct minus character in terms of searching and sorting, but has the additional disadvantage of being the wrong character. In Wikipedia we should promote correct typography, and encourage search and sorting technology to catch up. Peter coxhead (talk) 14:49, 22 July 2015 (UTC)

Huh? How is that relevant? WP:NOT a public examination, and why would we want to emulate abuse of en-dashes? That's not "correct typography". "In Wikipedia we should promote some ideal, and encourage the real world to catch up" is precisely the same argument the activists are using on transgender issues, pushing for WP to falsify history and 'lead the way' in language reform. This is the dead opposite of WP's role. We reflect (within reason and technical limits) general mainstream usage. In this case, there are some technical issues that seem to be real (see below). Question: Does Microsoft Word auto-convert hyphen to a minus when it precedes a numeral? Just looking to see if there's anything indicating any shift, in computer-mediated communication, not dead-trees printing, toward use of the Unicode symbol. I agree mainstream print has long distinguished (though to a greater or less extent depending on the nature of the publication). We also prefer higher-quality sources over newspapers when it comes to technical material, so I can see why we'd favor the minus from that viewpoint. Unlike, say, capitalizing species common names, there is no principle of least astonishment factor at work; the average reader neither notices nor cares about any difference between these characters. I want to support it, because I agree with the "we should use proper typography" idea.

Oppose There's a lot of stuff which is irrelevant, dated and/or plain wrong here.

• This notion that the minus sign doesn't work in sortable tables may or may not have been accurate at the time of this essay's being written but it isn't true now. Even if it were the case, however, there would be ways around it (e.g. {{nts}}).
• The fact that in the early days of typewriters people had to get by without such characters as "−", "×", "÷", "±", "≈", "≠", "≤", "≥", etc. is of no relevance. Why continue to limit ourselves to what was possible a century ago ... tradition?
• The text in question is text intended for humans to read not for computers. That such functions as {{#expr:}} and {{#time:}} require the hyphen as a minus sign is of no relevance. It's a question of output not input. If a template or module has to cope with minus signs as input (for some reason), Lua is capable of dealing with it.
• There are two types of search to consider.
  • Firstly, as mentioned above, in the search box, a hyphen will turn up pages without whatever text comes after it but a minus sign is simply ignored. Obviously, it's of no use to recommend either one over the other here.
  • Secondly, there is the [CTRL][F] search done on a page. Again as mentioned above, the two are distinguished in this case. However, far from this counting in favour of the proposal, it gives us a strong reason to reject it. We may only want to find the hyphens and not the minuses or vice versa. Say, for example, we're looking for ymd dates on a page, we could look for "-0" and "-1" but we don't want "−0" or "−1".
• Owing to its length and position, the hyphen is more difficult to recognise as a minus sign than a true minus sign. This is especially true where it's in sub- or superscript.
• The proposal would mean a whole lot of work in getting rid of the minus signs we have in place and replacing them with the inferior hyphen. This is likely to end up in edit wars as it is clearly a bad idea. Eventually, though, we'd realise the mistake and go back to the more sane approach. However, we'd run the risk of ending up with en dashes for minus signs (as we once had). In other words, it would be a lot of work with no actual benefits ... unless you count the in the negative.
• The idea that something like {{msym}} would ever end up being used throughout WP is just unrealistic but for consistency this would be necessary. As I recall, there were a half dozen or so transclusions in use before it was deleted, just another fleeting whim of its creator.

Just userfy this essay. Jimp 03:20, 24 July 2015 (UTC)

Not so "irrelevant" except the first one:

• Sortable tables: Glad that's been fixed.
• It's not about typewriters, it's about modern keyboards.
• These categories overlap. Only last week I made a module that strips string input down to embedded numeric data, performs an operation on it, then returns the result of the operation as a string again. It's extra work I'm not willing to do to also add routines to convert back and forth between – and −. I barely ever edit mathematical or string manipulation templates, but here I have a counter-example to what you said, and it's only days old. Sure makes we wonder if someone who does a whole lot of Lua module coding has dozens and dozens of counter-examples.
• There are not two types of searches to consider, but at least three, if you want to lump "all external search engines" into one category. Not all of them are as blunt an instrument as Google. Plenty let you search for specific strings one way or another. WP's results in them are totally different for the otherwise-identical string if you put in a Unicode minus vs. a hyphen.
• "more difficult to recognise as a minus sign than a true minus sign"? More difficult for whom? Only a vanishingly small percentage of computer users even know a separate Unicode minus symbol exists, and of them, only a tiny fraction use it. I'd bet money that less that 0.0000001% of computer users have ever intentionally put a Unicode minus instead of a hyphen. There's no evidence that people have any difficulty recognizing "-2". I would almost also bet that some, especially younger people used to computer-mediated communication, have difficulty parsing (at first) "2x−6b" or "−2", because it looks like an en dash; for them a minus is "–", and this "−" character is what's unfamiliar, while the opposite would be true for an older person, or just a more studious, one who spent a lot of time reading math printed by publishers that use the Unicode symbol.
• Virtually all proposals to change any style on WP mean a whole lot of work. This is a variant of the WP:HARDWORK argument at WP:AADD.
• Yeah, the {{msym}} thing doesn't seem practical.

I'm half devil's advocate on this, but only half. I expected there to be a dozen reasons why this proposal was crap, but so far most of the rationales against it aren't very strong. The case against the Unicode minus is quite similar to the one against curly quotes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:42, 26 July 2015 (UTC)

• Modern keyboards are descended from the old typewriter but whereas in the old days we had to make do with "-" for minus signs, "x" or "*" for multiplication signs, etc. we don't have to do so any longer. We can easily put a non-keyboard symbol in.
• If it's too much work for you to make your module/template output a true minus sign, let someone else fix it.
• If the third type of search distinguishes between hyphens and minus signs, as you indicate, this is a reason to use the minus sign.
• The hyphen is shorter and lower. This is why it seems to me more difficult to recognise.
• True, we shouldn't base style proposals on how much work will be needed to be done. The main point I was trying to get at was that we may end up with a mess with hyphens, en dashes and minus signs all being used.
• There is a significant difference between minus signs vs hyphens and straight vs curly quotes. Straight and curly quotes are different versions of the same symbol whereas hyphens and minus signs are different symbols.

The rationales against the proposal may be crap but I don't see the rationales for it as any better. Jimp 02:02, 27 July 2015 (UTC)

I think I'm sold on most of that.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:58, 27 July 2015 (UTC)

• Changing to Oppose: While I think there are rationales that run both ways, those in favor of the Unicode minus have swayed me. I was mostly neutral anyway, and this detailed discussion archives enough arguments that we can call this a solid consensus against further motions in this regard, unless something new comes to light that might cause consensus to change.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:58, 27 July 2015 (UTC)

Neutral

• Neutral. I have not investigate how search engines handle this, but the Firefox for Windows search within a page feature definitely distinguishes hyphen-minus from minus. This is a feature I use a great deal both in Wikipedia and elsewhere. Jc3s5h (talk) 14:51, 22 July 2015 (UTC)
  • Yeah, it'll be that way for all of them; it's the same issue as curly quotes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:42, 26 July 2015 (UTC)

Comments

• Has anyone mentioned line break rules for text layout? My understanding is that hyphen-minus (U+002D) is ordinarily interpreted as binding to its left, but minus (U+2212) binds to its right. If a line break needs to be placed in the neighborhood of a minus sign, it can have a really ugly result if a minus sign is coded as a hyphen-minus, because the sign can end up on a different line than the number it prefixes. —BarrelProof (talk) 02:11, 27 July 2015 (UTC)
  • Math expressions should be put in {{nowrap}} anyway. They'll be hard to parse if they break before or after "+" or "=" or whatever.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:42, 27 July 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Symbol for astronomical units (again)

The discussion was closed by IJBall below. The result was implemented by Ashill as noted in another subsection below. Cunard (talk) 06:06, 30 July 2015 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

There is some active debate about what symbol should be permitted in the MoS and/or supported by {{convert}} to represent the astronomical unit in WP. I feel that this debate should be on this talk page, and those watching this page may be interested in weighing in (and bringing the debate here). See Template talk:Convert#au, Template talk:Val/units#What should MoS say on unit "au", Talk:Non-SI units mentioned in the SI#The symbol used in the article for astronomical unit is incorrect, Talk:Astronomical unit#AU vs au vs ua. Since so much debate is sparked by this, it strikes me as a prime candidate for explicit mention in WP:MOSNUM. —Quondum 23:47, 13 June 2015 (UTC)

MOSNUM shouldn't get involved unless and until there's evidence that editor time is being wasted litigating the issue on multiple articles. And {{convert}} shouldn't add a new unit to its repertoire until there's general consensus of how to represent that unit. In other words: FIRST discussion on individual article talk pages, SECOND (if necessary) discussion at MOSNUM to harmonize things, and then LAST convert takes that consensus on. (Until then it's OK for convert not to handle a given unit -- conversions can be handled manually in articles for a while.) As far as I can see from your diffs, we're still at (or even before) step FIRST -- where are the discussions among actual editors of actual articles, disputing this issue? EEng (talk) 04:46, 14 June 2015 (UTC)

I agree with Quondum that there is a problem, but I don't know how to fix it. Internationally accepted symbols for the astronomical unit include au (IAU) and ua (ISO). Until recently, the BIPM recommended symbol was ua (following ISO), but switched to au after a recent decision by the IAU to standardise on that symbol.

In my opinion Wikipedia needs to either make a choice between the two standard symbols (ua and au), or permit both of them, but it doesn't. I have made several attempts to adopt one or other symbol (it doesn't matter which) on various articles but these attempts have failed because (as far as I can tell) the {convert} template accepts only AU, a symbol not accepted by any standards organization that I know of. The result is standardization on a non-standard symbol (AU) by the back door of {convert}. It would be much better if a decision were made centrally and for the conversion template to implement that central decision.

Dondervogel 2 (talk) 08:17, 14 June 2015 (UTC)

"AU" is much more common than "au" and clearer to many people. --JorisvS (talk) 09:23, 14 June 2015 (UTC)

Just because something is common does not make it better (otherwise no doctor would have bothered to invent a vaccine for the common flu), so we can safely ignore that argument. Clarity is certainly desirable so let's focus on that. Do you have any evidence to support the assertion that AU is clearer than au? Dondervogel 2 (talk) 10:06, 14 June 2015 (UTC)

Just to be clear, if we can agree here that AU is the most appropriate symbol to use (whatever the reason), I would be pleased to go along with that choice. What is not acceptable is confusion caused by reluctance to harmonise. Dondervogel 2 (talk) 10:13, 14 June 2015 (UTC)

Your comparison with the flu is wrong. This is writing, a form of language, not some illness. What is appropriate language is determined by commonality. As a case in point, Wikipedia uses a subject's common name for an article's title, even when this deviates from some officially preferred name. I'm all for standardization, if that goes to the most common and clearest option, which is "AU" here, no matter that it deviates from an official acceptance by some organization. --JorisvS (talk) 10:28, 14 June 2015 (UTC)

Well, it's not just "some organization" we're talking about here. The bodies supporting au as the symbol are the International Astronomical Union and the BIPM (responsible for the SI). I do agree that what matters to WP is consensus on this page though. Can we agree to standardise here on AU? Dondervogel 2 (talk) 10:34, 14 June 2015 (UTC)

Only two options exist, blindly follow IAU (BIPM/ISO are irrelevant here) and use the official symbol of au. Or follow sources and do what everyone does, and use AU (which has the added benefit of not being ambiguous with atto-atomic mass unit, although no one would ever use that). Personally, I'd standardize on AU. Headbomb {talk / contribs / physics / books} 11:03, 14 June 2015 (UTC)

I think this comment is confusing a mostly-ignored IAU standard and an almost-completely-ignored BIPM standard with "international acceptance". This is a case where common usage is different from the standards. That's fine. —Alex (Ashill | talk | contribs) 12:50, 14 June 2015 (UTC)

I think Alex's statement is a critical concept to understand. This is not like metric adoption, which is nearly universal. Very few entities actually use the "standards" in practice. — Huntster (t @ c) 13:05, 14 June 2015 (UTC)

There has indeed been much discussion of this, but the editor time is spent almost entirely in talk space. That makes this seem to me like a solution in search of a problem. FWIW, my preference is to go with the overwhelmingly-most common symbol, AU, which also has the benefit of being unique (as far as I know) and thus more clear than "au" or certainly "ua". (I had never even been aware that another symbol was in use until this was brought up a while ago on Wikipedia, and I see "AU" all the time.) —Alex (Ashill | talk | contribs) 12:36, 14 June 2015 (UTC)

I pinged Talk:Astronomical unit about this discussion and was brought here by a ping at WT:Astronomy. —Alex (Ashill | talk | contribs) 12:45, 14 June 2015 (UTC)

A Guide to Effective Publising in Astronomy coordinated by Claude Bertout, Chris Biemesderfer, Agnès Henri (EDP Sciences, 2012, outcome of a workshop for journal authors and referees, held originally at the XXVIII General Assembly of the IAU in Beijing, in August 2012.) says the core astronomy journals are

• the journals of the American Astronomical Society, including the Astronomical Journal (AJ) and the Astrophysical Journal (ApJ) and the Astronomy Education Review (AER). Other core journals are Astronomy and Astrophysics, The Monthly Notices of the Royal Astronomical Society, and the publications of the Astronomical Society of the Pacific.

The "Manuscript Preparation: AJ & ApJ Author Instructions" says "Use standard abbreviations for SI (e.g., m, km, mm) and natural units (e.g., AU, pc, cm)." But it also says "The AAS style conforms to Merriam-Webster's Collegiate Dictionary (11th ed.) and The Chicago Manual of Style (15th ed.)." The current edition of Chicago is the 16th, suggesting the instructions may not have been updated recently.

The "Astronomy & Astrophysics - Author’s guide" (April 2015) addresses units on page 27 but does not specifically mention the astronomical unit. A forthcoming paper for which free access is currently available, "Search for satellites near comet 67P/Churyumov-Gerasimenko using Rosetta/OSIRIS images" (I. Bertini et al, A & A manuscript no. 25979_ap_final_printer) says "The images were taken when the comet was at 3.69 AU from the Sun." (emphasis added).

The "Instructions to Authors" of the Monthly Notices of the Royal Astronomical Society says "The units of length/distance are Å, nm, µm, mm, cm, m, km, au, light-year, pc" (emphasis added).

"Information for Authors" of the Publications of the Astronomical Society of the Pacific does not contain style recommendations at this level of detail.

Perhaps other editors with convenient access to these journals can report what symbol is used in recent issues. Jc3s5h (talk) 13:24, 14 June 2015 (UTC)

The most recent issue of the last I can access through JSTOR is that of May 2014, in which one article uses AU for astronomical units—while another uses au for “arbitrary units“ (to label one axis in a set of plots).—Odysseus1479 07:51, 15 June 2015 (UTC)

• PASP: AU in doi:10.1086/681765 (May 2015 issue)
• ApJ and AJ: explicit policy is to use AU, as quoted above.
• MNRAS: explicit policy is to use au, as quoted above.
• A&A: AU in doi:10.1051/0004-6361/201525680 (May 2015)
• And for higher profile academic journals, Science: AU in doi:10.1126/science.1251527 (July 2014, in the title as well as text; defined at first use in the abstract)
• Nature: small caps AU in doi:10.1038/nature14276 (2015) and doi:10.1038/nature04205 (2005, in the title as well as text). At first use, the 2015 example says "corresponding to 50–70 astronomical units (1 AU is the distance from the Earth to the Sun)"
• I also searched Sky & Telescope, but couldn't find any relevant usage of the term. I'm much less adept at searching Sky & Telescope articles than I am journals, though. —Alex (Ashill | talk | contribs) 12:42, 17 June 2015 (UTC)

Examples from individual papers (first 7 hits for "astronomical unit" using Google Scholar)

1. Krasinsky et al 2004 uses AU.
2. Millan-Gabet et al 2004 uses AU.
3. Standish 2004 uses au.
4. Pitjeva & Standish 2009 uses AU.
5. Iorio 2008 uses AU.
6. Cameron & Pine 1973 is behind paywall.
7. Muhlernan, D. O., Holdridge, D. B., & Block, N. (1962). The astronomical unit determined by radar reflections from Venus. The Astronomical Journal, 67, 191. uses a.u.

But the IAU declaration of the symbol, together with the change from a measured to a defined unit, was in 2012, so older papers don't help us discern whether the astronomical community has decided to follow the IAU or not. Jc3s5h (talk) 13:58, 14 June 2015 (UTC)

Would it make any difference if they did follow the 2012 decision? I have the impression that the majority preference is to follow AU "because it's out there". I'm not saying I consider this a good reason, but it's better to agree to follow AU than to have no agreement. Dondervogel 2 (talk) 14:06, 14 June 2015 (UTC)

Studying papers published only in the last two years doesn't show much change. Most use AU. A few use au. I looked for a split between different branches of astronomy, but couldn't see anything obvious. Possibly there is a tendency for physicists to use au and astrophysicists to use AU. As an (old) astrophysicist I would never dream of using au and have to think twice what it means when I stumble across it. Lithopsian (talk) 14:22, 14 June 2015 (UTC)

I agree with Lithopsian. au can mean thousands of things and it will probably take a while for a reader to understand it means "Astronomical unit", but Astronomical unit immediately pops up into the reader's mind when he sees "AU". Besides, the majority of people are used to "AU", so why change that? We're not trying to get the reader confused here. aaaaaaaaaaaaaaaaaaaaaa (talk) 17:14, 14 June 2015 (UTC)

Examples from individual papers since 2014 (first 3 hits for "astronomical unit" using Google Scholar)

1. GALTIER AND MEYRAND 2014 uses no symbol or abbreviation
2. Kobulnicky et al 2014 uses no symbol or abbreviation in the abstract
3. Chiu 2014 uses AU

Pardon me

Pardon me, but can someone show me where there's been trouble about this in actual articles? Someone above said, "There has indeed been much discussion of this, but the editor time is spent almost entirely in talk space" -- could we have pointers to those discussions (by editors down in the trenches actually working on articles -- not just arguments about how convert should work). Otherwise, why does MOSNUM need to say anything about this? EEng (talk) 14:43, 14 June 2015 (UTC)

Mostly the extensive discussion at Talk:Astronomical unit, which grew out of an earlier discussion (linked there). By "editor time is spent almost entirely in talk space", I meant that the editor time is spent by editors who want to change the MOS, not editors who are actively involved in editing articles that use the symbol AU (there are, appropriately, very few that use au or ua). —Alex (Ashill | talk | contribs) 15:33, 14 June 2015 (UTC)

Thanks for the clarification. EEng (talk) 18:51, 14 June 2015 (UTC)

Previous discussion

I note that this discussion rather closely mirrors the one at Talk:Astronomical unit#AU vs au vs ua. Has anything changed since then? Why are we having this discussion again? There was one clear consensus from that discussion: there is not a desire to even decide on this question on a project-wide basis. Instead, the preference of most editors was to decide this on an article-by-article basis (a la WP:ENGVAR), since there haven't actually been many problems doing it that way (and the conclusion has almost always been AU anyway). —Alex (Ashill | talk | contribs) 15:36, 14 June 2015 (UTC)

If this is being brought up again because the convert template enforces AU (instead of the no-project-wide-consensus approach), could "au" be added to convert, so it supports both AU and au? —Alex (Ashill | talk | contribs) 15:48, 14 June 2015 (UTC)

I strongly object to the status quo. It should be clear to an editor which units are acceptable, e.g. that au or AU can be decided on a per-article basis. At the moment, this is not clear, and triggers a fresh, drawn-out and unproductive discussion on many such occasions. As Alex says, if au is acceptable, {{convert}} should support it rather than discriminating against it behind-the-scenes, as EEng seems to think it should.

The MOSNUM guidance is currently (quoted from WP:MOSNUM#Specific units):

• The SI Brochure should be consulted for guidance on use of other SI units. "Chapter 4" tables 6, 7, 8, and 9 give additional guidance on non-SI units.

The linked brochure clearly lists au as the unit symbol. I consider this as sufficient to motivate a change of style in any given article, unless MOSNUM makes a specific note about this unit. —Quondum 16:03, 14 June 2015 (UTC)

@Ashill The reason we are having this discussion again is that the previous discussion, by deciding against harmonization, has led to the situation to which Quondum refers, whereby what is used on WP is determined by {convert}. Changing {convert} to accept other units unit symbols would not change that unless a decision was first reached regarding which symbols are (and are not) acceptable. Dondervogel 2 (talk) 16:38, 14 June 2015 (UTC)

@Dondervogel 2: Well, I'm virtually certain you've got your history wrong: Wikipedia, like everywhere else in the English-speaking world, used predominantly AU. Then the convert template was written and reflected that (probably without much thought, since "AU" is the normal practice used in most cases -- I see no evidence at all that there was any conscious attempt to use convert to enforce AU over au). And then after that the IAU specified "au". Now some are arguing that au is either acceptable or should be primary. But either way, this objection can (as far as I can tell) be easily addressed by modifying convert to accept either AU or au, so this is not a reason to make a Wikipedia-wide decision about this. (There may be other arguments, but editors didn't find them persuasive before and I don't see what has changed.)

@Quondum: The guideline to follow the SI brochure is useful because in most cases common practice reflects the brochure (or, perhaps more accurately, the brochure reflects common practice). That's not true in this case, so I think we should follow common practice (or at the very least allow editors to decide to follow common practice on an article-by-article basis). —Alex (Ashill | talk | contribs) 17:10, 14 June 2015 (UTC)

My problem is that what you say is not evident from MOSNUM, and it should be: to the editor coming in fresh, the use of AU seems to be going against the MoS. I am perfectly happy with an article-by-article choice, or pretty much any choice, even one to allow any symbol. But in my mind inclusiveness implies two things: (a) qualify the reference in MOSNUM to the SI brochure to say that both au and AU may be used (or something along those lines, such as even just "AU is commonly used"), and (b) support au in {{convert}}. What I'm objecting to in the status quo is the confused message from MOSNUM. —Quondum 17:22, 14 June 2015 (UTC)

And mine is that I speak from personal experience. When I encounter articles with non-standard or inconsistent unit symbols by instinct is to make them consistent, first internally and then with each other. When I find one using {convert}, the only choices available to me are a) use the non-standard symbol and b) remove the conversion. I don't believe decisions should be driven by the shortcomings of the conversion template. Dondervogel 2 (talk) 17:31, 14 June 2015 (UTC)

OK, so easy enough; have the convert template support "au" in addition to "AU". —Alex (Ashill | talk | contribs) 17:43, 14 June 2015 (UTC)

That seems reasonable. Two quick additional points: the MOSNUM guidance does not say that the SI brochure should be consulted for guidance on the use of non-SI units, and a quick site-specific date-limited search of the NASA, ESA and BPS sites suggests that the use of AU is still prevalent in at least the public-facing material of some space exploration organisations. NebY (talk) 18:32, 14 June 2015 (UTC)

For convert to be agnostic seems to me the best outcome, under the circumstances. EEng (talk) 18:52, 14 June 2015 (UTC)

In the absence of consensus, how would the custodians of {convert} decide which unit symbols it would accept? Dondervogel 2 (talk) 19:09, 14 June 2015 (UTC)

I think convert should probably accept pretty much anything editors want it to accept, in general, except where MOS clearly says Usage X is inappropriate. The talk page of a template isn't the place to make decisions on which units are OK or not OK, how to present them, etc. A template is a tool, not a cudgel.

Having said that, there's no necessity that convert handle absolutely everything, or everything right now. If a unit is somehow subject to dispute, or its usage is, then it's OK to leave that unit out in the cold, convert-wise, until clarity is found on how to handle it. In the meantime editors can do manual conversions within articles. I'd rather have that than some rushed decision on the convert talk page. EEng (talk) 19:18, 14 June 2015 (UTC)

(edit conflict)Dondervogel 2, There seems to be a growing consensus in this discussion that MOSNUM should not specify au or AU. (There's a difference of opinion as to whether MOSNUM currently prefers AU; Quondum says it does but I think that's a misreading.) Are you opposed to that consensus? NebY (talk) 19:28, 14 June 2015 (UTC)

With at least 4 editors arguing for standardization (Quondum, JorisV, Headbomb, and Dondervogel 2), I see no such consensus. Dondervogel 2 (talk) 19:52, 14 June 2015 (UTC)

None of the others you mention have said so clearly. Quondum said explicitly that s/he doesn't care if this is specified at the MOS level. —Alex (Ashill | talk | contribs) 22:16, 14 June 2015 (UTC)

This feels more than a little absurd to me. The only controversy I've seen stems from one party demanding that "au" be used on Wikipedia to the exclusion of "AU" because industry standards demand it, despite industry practice overwhelmingly using "AU". The Convert template can of course use both "AU" and "au" as inputs, and there's no reason to not do so. — Huntster (t @ c) 21:04, 14 June 2015 (UTC)

So it seems to me that an acceptable solution would be that convert support both AU and au, and that MOSNUM should be worded carefully to avoid implying any guidance on non-SI units from the SI brochure? (BTW, what I read in the MOS was a reference to an article, which has changed since, and I should not have read any weight into that anyway. So, I'm not arguing for any specific unit, only for some clarity.)—Quondum 21:46, 14 June 2015 (UTC)

Agree with the view that we should allow both AU and au. If sometime down the road academic standards and practice agree on one of them, we can then reconsider the issue. --SteveMcCluskey (talk) 22:00, 14 June 2015 (UTC)

I particularly agree that the convert tool is not the place to make a decision like this. Irrespective of whether a consensus is reached that au or AU is preferred Wikipedia-wide, the template should let editors do what they want to within reason (and au and AU are both within reason). —Alex (Ashill | talk | contribs) 22:10, 14 June 2015 (UTC)

I totally agree, and I particularly like EEng's above "A template is a tool, not a cudgel."—I have been less eloquently arguing that at Template talk:Convert for a while. Someone has just added au to convert, so editors can now choose for themselves:

• {{convert|12.3|au|abbr=on}} → 12.3 au (1.84×10⁹ km; 1.14×10⁹ mi)
• {{convert|12.3|AU|abbr=on}} → 12.3 AU (1.84×10⁹ km; 1.14×10⁹ mi)

Johnuniq (talk) 00:59, 15 June 2015 (UTC)

What about abbreviations?

There seems to be a consensus for permitting both AU and au as unit symbols for astronomical unit. That is real progress. Also common are the abbreviations A.U. and (perhaps less so) a.u. Can we also agree these abbreviations are not permitted in lieu of a unit symbol? Dondervogel 2 (talk) 07:35, 15 June 2015 (UTC)

When I see 'au', I think Australia. My preference is to use AU for Astronomical Unit; that's usually how I see it used. Praemonitus (talk) 22:11, 16 June 2015 (UTC)

What exactly is the consensus then?

We should just standardize on "AU" as it is the only one that is frequently and commonly used in the field, by the professionals, and also used by popular science books and amateur astronomy publications. "standards" that are never used are not real standards, since they are not used. BIPM isn't even the relevant or competent authority in this area. If the convening authority is not related, then it's like those schemes to sell plots of land on the Sun and the Moon. Sure you get a nice piece of paper saying you have title, but it's only worth as much as the paper it's printed on.

WP:SOAP Wikipedia itself does not prescribe how the field should operate, it merely follows actual usage in the field. -- 70.51.202.183 (talk) 08:45, 15 June 2015 (UTC)

Hmmm, it seems I spoke too soon. Would someone like to summarise what they think the consensus is? Dondervogel 2 (talk) 09:01, 15 June 2015 (UTC)

The IP seems to be on the right track. Consensus has been and still seems to be that "AU" is the preferred output on Wikipedia. That "au" was added as an alternative input for Convert doesn't change anything, it simply adds flexibility. Progress. — Huntster (t @ c) 13:39, 15 June 2015 (UTC)

How about this: if one editor tries to change the style of an article from au to AU or vice versa, and another editor objects, the meta-rules imply that the change should not happen. What seems clear is that the MoS does not say that only AU or only au may will be used across all scientific articles. Does anyone object to that summary? It is all we need, for practical purposes. —Quondum 13:56, 15 June 2015 (UTC)

My impression is also that there is basically a consensus here for standardizing on using "AU". --JorisvS (talk) 13:59, 15 June 2015 (UTC)

In my opinion it is better to choose between AU and au, and do not feel strongly which of the two it should be. I would therefore support uniform adoption of AU across Wikipedia. Any objections to doing so? Dondervogel 2 (talk) 14:06, 15 June 2015 (UTC)

I don't think it's necessary for MOSNUM to rule between AU and au. Yes, AU appears to predominate at present but the IAU - in the IP's words a "relevant or competent authority in this area" - has chosen "au" and we can expect it to appear in RSs. I agree that MOSNUM could usefully say that "A.U." and "a.u." should not be used (we avoid phrases like "not permitted" here"). NebY (talk) 14:42, 15 June 2015 (UTC)

Which brings us back to my post of 07:35 this morning, which I rephrase now as

There seems to no consensus for making a choice between AU and au as unit symbols for astronomical unit, implying that both are permitted. That is real progress. Also common are the abbreviations A.U. and (perhaps less so) a.u. Can we also agree these abbreviations should not be used in lieu of a unit symbol?

Dondervogel 2 (talk) 14:52, 15 June 2015 (UTC)

@Dondervogel 2: I don't think anyone will object if you change "au" to "AU" in articles, even if "AU" is not formally chosen here. I have done it on occasion and no one has ever objected. --JorisvS (talk) 16:01, 15 June 2015 (UTC)

@JorisvS: Given there is no consensus to make the change you describe, I don't understand why anyone would want to replace an international standard symbol with a non-standard one. My preference is to use international standard symbols until there is consensus to depart from them. Dondervogel 2 (talk) 16:28, 15 June 2015 (UTC)

Well, I see basically a consensus that "AU" is much more common (inside and outside Wikipedia) and clearer and hence preferable, but that there is some disagreement whether this should be made explicit in the MoS. My point was that if you prefer to have "AU" everywhere over a mixture of "AU" and "au", then changing the few cases of "au" lying around to "AU" is unlikely to find opposition regardless of the MoS. --JorisvS (talk) 16:42, 15 June 2015 (UTC)

I just don't agree that widespread use makes something better by default. Years ago there was a debate about whether to use Mbps or Mbit/s as a symbol for megabits per second. Those in favour of "Mbps" argued that it was far more common, which it was. Those in favour of "Mbit/s" argued that international standards should be followed. I argued then to follow the appropriate international standard and so again. For this reason I prefer au over AU and see no justification for converting in the direction you suggest. My position would change if there were consensus here to use AU, but I don not see that consensus. Dondervogel 2 (talk) 10:33, 16 June 2015 (UTC)

Widespread use is what MOS and other relevant WP:POLICY uses (e.g. WP:COMMONNAME), unless some greater concern overrides it. If you disagree with the widespread use, demonstrate why a less common one overwhelmingly better for WP's mission, audience, technical needs, etc., don't just say WP shouldn't operate the WP does. It will continue to operate the way it does.  :-)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:22, 22 July 2015 (UTC)

Pardon me again

In response to my previous query along these lines (#Pardon me) I was told that the closest thing to dispute on this issue was at Talk:Astronomical unit. That's it? Here's my usual, tiresome refrain:

A. It is an axiom of mine that something belongs in MOS only if (as a necessary, but not sufficient test) either:

• 1. There is a manifest a priori need for project-wide consistency (e.g. "professional look" issues such as consistent typography, layout, etc. -- things which, if inconsistent, would be noticeably annoying, or confusing, to many readers reader); OR
• 2. Editor time has, and continues to be, spent litigating the same issue over and over on numerous articles, either

• (a) with generally the same result (so we might as well just memorialize that result, and save all the future arguing), or
• (b) with different results in different cases, but with reason to believe the differences are arbitrary, and not worth all the arguing -- a final decision on one arbitrary choice, though an intrusion on the general principle that decisions on each article should be made on the Talk page of that article, is worth making in light of the large amount of editor time saved.

B. There's a further reason that disputes on multiple articles should be a gating requirement for adding anything to MOS: without actual situations to discuss, the debate devolves into the "Well, suppose an article says this..."–type of hypothesizing -- no examples of which, quite possibly, will ever occur in the real life of real editing. An analogy: the US Supreme Court (like the highest courts of many nations) refuses to rule on an issue until multiple lower courts have ruled on that issue and been unable to agree. This not only reduces the highest court's workload, but helps ensure that the issue has been "thoroughly ventilated", from many points of view and in the context of a variety of fact situations, by the time the highest court takes it up. I think the same thinking should apply to any consideration of adding a provision to MOS.

That's only my humble opinion of course. But humor me... where's the evidence that either (1) or (2) is satisfied? If not, why should MOS say anything at all about this? All I see here is a lot of people arguing in the abstract, divorced from actual article work. EEng (talk) 15:02, 15 June 2015 (UTC)

Yup, I agree. Although it did come in 2004 on that same talk page. Though I think it has been discussed to death, it hasn't come up all that frequently. Neither 1 nor 2 is satisfied; in fact, I think there's a pretty clear consensus with only one vocal objector that there is no need to harmonize AU or au project-wide. But if we do decide to harmonize, I think the consensus (clear, though perhaps slightly less so) is for AU over au. —Alex (Ashill | talk | contribs) 15:11, 15 June 2015 (UTC)

I guess we see things slightly differently. My purpose is only to document consensus. At present I see no consensus so there is nothing to document. Dondervogel 2 (talk) 16:43, 15 June 2015 (UTC)

@Dondervogel 2: Where do you see disagreement with using "AU" all over? --JorisvS (talk) 09:22, 16 June 2015 (UTC)

@JorisvS: Well, to start with I disagree with doing this myself unless there is consensus for it that would override the wider principle of following international standards. When I suggested (earlier in this same thread) that such a consensus might exist, it received objections from several editors. Do you think it is worth trying again. Perhaps it just needs to be phrased differently? Dondervogel 2 (talk) 10:39, 16 June 2015 (UTC)

@Dondervogel 2: Who expressed that and where? All I find is either agreement with standardizing on "AU", disagreement over whether the MoS needs to address this even if it is decided to standardize, and a somewhat vague position of Quondum, who appears to object mainly to how the MoS currently handles the situation, but not really to using "AU" if that is decided. --JorisvS (talk) 11:37, 16 June 2015 (UTC)

That isn't my interpretation, but rather than reading between the lines, let's just try it one more time to see what happens. I would support standardizing on AU if there is consensus for that. Are there any objections to adopting AU as the preferred symbol for astronomical unit on Wikipedia? Dondervogel 2 (talk) 12:31, 16 June 2015 (UTC)

Yes, objections. See (earlier thread) Template_talk:Convert#au look four 'Authority', IAU and BIPM. Apart from forumshopping (3 talkpages by now), I am with EEng that this MOS has no case to answer. -DePiep (talk) 13:40, 16 June 2015 (UTC)

As long at some clarity on the position is added, I'd be fine with any statement in the MoS on this. Even something as vague as "No specific symbol is preferred by the MoS for the astronomical unit." This would shortcut a lot of future wrangling. —Quondum 13:56, 16 June 2015 (UTC)

@DePiep: but article titles can differ from an officially sanctioned term if the unofficial term is more common. Why not do the same here? (Separately from whether the MoS should address this at all.) --JorisvS (talk) 15:37, 16 June 2015 (UTC)

Won't do content here, this is being forumshopped in three pages by now. -DePiep (talk) 15:39, 16 June 2015 (UTC)

@DePiep: Then your objection is hollow. This is the only place where I've discussed it because this is where I saw it. --JorisvS (talk) 17:14, 16 June 2015 (UTC)

Whatever, I won't get pulled in. I happened to talk somewhere else, how can you call that a "discussion"? Replying here would be oxygen for WP:FORUMSHOPPING. I'm not blaming you for this, but engaging is not the way to finish this talkmess. This talk is the last one of three AFAIK opened, so I can claim nullification of any outcome. -DePiep (talk) 17:40, 16 June 2015 (UTC)

Did you or did you not state your objections elsewhere? If yes, then I'd call that (part of) a "discussion". I asked you a question and I'd appreciate a response. If you won't do that here, elsewhere is fine to me (e.g. my talk page), but refusing to respond categorically to an editor who has not been involved in any of the discussions you refer to simply because that would be fuel for the "forumshopping" is no way to work cooperatively. --JorisvS (talk) 18:02, 16 June 2015 (UTC)

See? If I wrote something elsewhere, you claim you responded here and call that a discussion? Not. -DePiep (talk) 18:07, 16 June 2015 (UTC)

? I was talking about a discussion between you and others elsewhere, not between you and me. I was not involved in any of the other discussions, so I'm not familiar with your objections. That's why I asked and why I'd like a response, even if it is elsewhere. And if you have actually voiced your objections already to others, you can also simply refer to where you said it. --JorisvS (talk) 19:33, 16 June 2015 (UTC)

Proposal proposing not proposing

Proposal: There being no evidence at this time that a MOS provision is needed, that this discussion be ended with nothing added or changed to MOS.

• Support as proposer. EEng (talk) 19:18, 15 June 2015 (UTC)
• I dispute the premise that there is no evidence a MOS provision is needed. Who invented those rules for determining so called "evidence"? If there were no clear preference between AU, au, A.U. and a.u. then I would agree with EEng's proposal, but there is a clear preference, namely for AU. For me that is reason enough to document that preference. I abstain because I do not feel strongly enough either way to oppose. Dondervogel 2 (talk) 19:35, 15 June 2015 (UTC)

The rules are mine own, but they reflect a principle that I and others have been pushing for some time, to wit If there's no need for MOS to have a rule, there's a need for MOS to not have a rule. The reasons are given above. Absent such a need we shouldn't be achieving consensus here even if we can. EEng (talk) 22:20, 15 June 2015 (UTC)

Like I said, we see things differently. I find it confusing as a reader (not as an editor) to be confronted with multiple different symbols and abbreviations for exactly the same quantity. It would make my life much easier as a reader (not as an editor) if such inconsistencies were removed. This is the reason the SI chooses a unique symbol "m" for the metre, and does nor permit individual authors to use "met", "mtr" or "m." even if they do so consistently throughout an article. The MOSNUM is our SI. It is our tool for helping the reader. Dondervogel 2 (talk) 22:59, 15 June 2015 (UTC)

Yeah, but SI doesn't insist on either meter or metre, demonstrating that other considerations sometimes override the general principle that uniformity is usually better. Your argument is basically "A1" in my formulation above, but absent further evidence I don't buy that, any more than I buy that all date formats, or AD/BC vs. CE/BCE, need to be uniform project-wide. EEng (talk) 23:33, 15 June 2015 (UTC)

@EEng The spelling is completely irrelevant here, and the (uncharacteristic) weakness of your argument (what evidence might possibly be needed to demonstrate that having four different symbols for the same quantity is confusing?) irritates me. I now do feel strongly enough about this to oppose and change my position accordingly. Dondervogel 2 (talk) 08:53, 16 June 2015 (UTC)

• Comment I don't see a problem with documenting what we've found and what we've agreed on. MOS is a guide, not a court that only gives rulings on substantial disputes, and it's quite possible - even desirable - that editors will seek guidance here during the ordinary processes of article creation and editing. I would suggest something along the lines that a literature search in 2015 found that "au" was now recommended (stipulated?) by the IAU and the BIPM, but that AU still predominated; either is acceptable and supported by Convert but consistency within an article is preferred. "A.U.", "a.u." and "ua" should not be used. NebY (talk) 23:48, 15 June 2015 (UTC)

The problem is that "we" aren't those actually editing articles using the unit (if they're here are they aren't identifying themselves -- anyway we'd want a much wider group to participate). For all we know such a group might decide that one form or another is best. EEng (talk) 23:54, 15 June 2015 (UTC)

• Oppose – having just gone through an exercise that has cost me many hours of arguing, based on what I did read in the MoS and on what I sought in the MoS and failed to find, I would be sorely put out if next time this issue arises I will find myself, and many other editors, spending time rehashing this yet again. EEng, I put it to you that there is plenty of evidence that some greater guidance is needed from the MoS on this, and thus that you are misapplying your principles. I am in agreement with the perspectives of both Dondervogel and NebY, except in that I categorically reject the conclusion as proposed. —Quondum 03:17, 16 June 2015 (UTC)

Where were you hashing it out, other than here? EEng (talk) 03:47, 16 June 2015 (UTC)

I brought it here after it had gone some way elsewhere; it is not as though I didn't link to it. Please don't be obtuse. —Quondum 06:07, 16 June 2015 (UTC)

Some people think my reasoning is acute. Sorry -- I forgot you were the OP. Look, I'm seeing one article (the article astronomical unit itself) at which there was such discussion. The rest was at places like convert and val. So as far as I can see actual editors of actual articles (and there must be zillions of them on comets and asteroids and whatnot) aren't asking for guidance on this. EEng (talk) 14:16, 16 June 2015 (UTC)

I apologize for my tone. I don't think we're far apart; I'm going to make a new observation below that focuses exclusively on the MoS wording, in particular a nuance that might need rewording. —Quondum 19:12, 16 June 2015 (UTC)

'Somewhere else' being Template_talk:Convert#au starting at 21:34, 12 June 2015. -DePiep (talk) 11:17, 16 June 2015 (UTC)

*Support. There is no need to specify one way or the other in the MOS, and the MOS suffers from instruction creep (to say the least). Adding an outcome of every discussion the MOS makes it less manageable and harder to read and thus less useful. But if we do add something to the MOS, the formulation by EEng NebY is a good starting point. (I wouldn't proscribe "A.U.", "a.u.", or ua, though. We don't need to list options that aren't recommended.) —Alex (Ashill | talk | contribs) 06:23, 16 June 2015 (UTC)

Wikipedia talk:MOSNUM

(not to scale)

I'm taking you off my Christmas card list. EEng (talk) 13:09, 17 June 2015 (UTC)

:D I wish editors would apply the "common sense" admonishment at the top of every guideline, which your idea implicitly replies on. Alas, this discussion has convinced me that it ain't so. —Alex (Ashill | talk | contribs) 13:11, 17 June 2015 (UTC)

I wonder if you meant the approach I suggested? I wouldn't have a problem with dropping the mention of "A.U.", "a.u." and "ua" and it might even be possible to take account of Quondum's categorical rejection - if I understand it correctly - with something along these lines: A literature search in 2015 found that "AU" predominated although "au" was now recommended (stipulated?) by the IAU and the BIPM. Both are supported by Template:Convert but consistency within an article is preferred. NebY (talk) 12:28, 17 June 2015 (UTC)

You're correct; I misread the signature line. I would definitely say "recommended" not "stipulated", since "recommend" is the word the IAU uses and they obviously have no authority to stipulate, since almost no one follows their recommendation anyway! —Alex (Ashill | talk | contribs) 12:52, 17 June 2015 (UTC)

• Oppose Given the disruptive insistence by some editors, mostly DePiep, that their view prevail and be enforced by the convert template if the MOS doesn't make some mention of AU or au, I now am leaning away from the view that we can leave the MOS alone. I now think we probably should say something. My preference is for NebY's formulation; I could also readily get behind just specifying AU per the vast majority of English-language sources. —Alex (Ashill | talk | contribs) 12:58, 17 June 2015 (UTC)

disruptive insistence by some editors, mostly DePiep -- Take a F-riday day off. I did not start this forumshopping. btw, I still claim any outcome is invalid for that reason. -DePiep (talk) 22:54, 22 June 2015 (UTC)

• Support. I am astonished that I am supposed to redo the older discussion all again here. WP:FORUMSHOPPING? -DePiep (talk) 11:10, 16 June 2015 (UTC)

As was pointed out on Template talk:Convert, that is not the appropriate place to discuss something like this. And if you want older discussions, see Talk:Astronomical unit, where there was one discussion in 2004 and one in January 2015 (and the last few hours of December 2014); nothing had changed since that discussion, but it was restarted at Template talk:Convert anyway.

On the substance, DePiep, is it your view that this proposal would mean Wikipedia-wide adoption of au over AU? —Alex (Ashill | talk | contribs) 14:02, 16 June 2015 (UTC)

That's not the way to kill forumshopping. I don't do content -- this thread cannot decide, I claim fs. -DePiep (talk) 14:09, 16 June 2015 (UTC)

DePiep, today you argued on Template talk:Convert#au concerning "AU" "Please show me where MOS allows this deviation (contradiction) of BIPM/SI".[11] It seems as if your support for this proposal is not so much in order that MOSNUM should not take a stance, as EEng intended, but so that you can interpret it as by its silence definitively favouring one symbol (au) and barring the other (AU). NebY (talk) 19:34, 16 June 2015 (UTC)

Stop trying to pull me in a discussion. I stated that this topic is bein forumshopped, and three-page (or more?) discussion threads are impossible to perform. For this, I will claim any outcome here invalid. This thread might as well be closed & killed. -DePiep (talk) 22:10, 16 June 2015 (UTC)-DePiep (talk) 22:10, 16 June 2015 (UTC)

DePiep, you sought to use Convert to remove AU from articles ("AU to be be removed from the {{Convert}} data set, offending articles will be listed automatically for edit (up for change 'AU' into 'au')".[12] The use of "AU" is an appropriate matter for discussion here - Convert works within the scope of MOSNUM - and you yourself pleaded MOS as your WP authority for such a change. NebY (talk) 09:17, 17 June 2015 (UTC)

Stop confronting and blaming me for what I wrote elsewhere. That is my point: this discussion is multi-page, so invalid. I am not discussing with you here. DePiep (talk) 22:49, 22 June 2015 (UTC)

• Oppose. The MoS should clarify that, despite official sanction of "au", "AU" is far more common and clearer and hence preferred on Wikipedia. Not mentioning it may suggest differently. --JorisvS (talk) 10:00, 17 June 2015 (UTC)
• Comment: As someone that edits asteroid articles, I think it is useful to remain true to what the source uses to prevent confusion for any readers that check the source. Most sources will use AU. -- Kheider (talk) 13:55, 21 June 2015 (UTC)

  Strongly oppose a mess of inconsistent symbols or abbreviations, each copied from the source that supports a particular statement. Jc3s5h (talk) 19:41, 21 June 2015 (UTC)

  Strongly support Jc3s5h strongly opposing source based units. Dondervogel 2 (talk) 20:20, 21 June 2015 (UTC)

• This thread seems to have lost its way. There's no proposal for source-based units or any of those other awful things. The proposal is simply to close the discussion without making any change to MOS (which is currently silent on au/AU/a.u./A.U./whatever, as it is on almost all units). EEng (talk) 20:58, 21 June 2015 (UTC)

  If we not to follow sources, the only sensible option - in the absence of clear advice from MOSNUM - is to follow international standards. Dondervogel 2 (talk) 08:33, 22 June 2015 (UTC)

• Strongly support: (this proposal to close the discussion without making any changes to the MOS). It's been hashed over once recently, not to the satisfaction of some who wish some form of standardization which was not agreed to, so there's no reason to go through it again. The Convert template is not the issue here, and is not required by MOS, and hence does not enforce a de fact standard in the absence of consensus either. Evensteven (talk) 05:28, 22 June 2015 (UTC)
• Oppose doing nothing: Perennial demands don't go away unless a "rule" is put into place (they sometimes still don't go away even then, but usually do).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:18, 22 July 2015 (UTC)

Proposal to add "AU" to the MoS

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There appears to be near universal consensus for the idea that the use of "A.U." (i.e. as a "unit abbreviation", as opposed to a "unit symbol") is incorrect in these circumstances, and its use should be discouraged under the MOS. On the issue of the use of "AU" versus "au", there appears to be narrower, though still clear, consensus that "AU" is most commonly used as the unit symbol for Astronomical unit in the literature, and thus should be adopted as the unit symbol in the MOS. Therefore, there seems to be a consensus to add "AU" to the table, as proposed (with the "Comment" portion still subject to further debate and refinement). Note that "AU" vs. "au" in the table issue can always be revisited at a later date if the IAU preferred "au" version becomes the more widely adopted unit symbol in the literature. --IJBall (contribs • talk) 16:21, 23 July 2015 (UTC)

---

Proposal: add "AU" to the table under the header "Specific units" as follows:

Guidelines on specific units

Group	Name	Symbol	Comment
Length Speed	astronomical unit	AU	"AU" is the most commonly used unit symbol for the astronomical unit, both in popular and professional astronomical articles and is hence also used on Wikipedia, even though "au" is officially sanctioned by the IAU

• Support as proposer. Feel free to tweak the comment. --JorisvS (talk) 10:29, 22 June 2015 (UTC)
• Qualified Unqualified support. It is important to choose between au and AU. If au is chosen one only needs to point to the IAU (or BIPM) definition. If AU is chosen as proposed here (and I understand the reasons for doing so) I think it is important to include a comment, similar to the one proposed, to the effect that the international standard symbol is au. I say "similar" because I need to think about the precise wording. I will come back with a specific suggestion if there is support in principle for this proposal Dondervogel 2 (talk) 10:38, 22 June 2015 (UTC)

  Here is my suggested wording for the comment

  Most sources use “AU”, although “au”, “A.U.” and “a.u.” are also seen. Even though international standardisation bodies such as the IAU and BIPM specify “au” as the symbol for astronomical unit, the preferred symbol on Wikipedia is AU because it is familiar, and therefore most recognisable to readers of astronomy articles.

  Dondervogel 2 (talk) 13:53, 22 June 2015 (UTC)

• support as it is the most widely used form and we should stop the pointless changing of these abbreviations back and forwards, and put a bullet into the argument above that seems to be getting nowhere. Graeme Bartlett (talk) 11:49, 22 June 2015 (UTC)
• Support. AU is the most widely used, and we need some finality to all this. I approve of the mention that "au" is officially sanctioned. — Huntster (t @ c) 13:25, 22 June 2015 (UTC)
• Support per others and the extensive previous discussion on at least four article and WP talk pages. —Alex (Ashill | talk | contribs) 13:52, 22 June 2015 (UTC)
• Oppose. Even when leading bodies in astronomy make a decision, it takes a long time to filter down through the style guides of the leading journals and the practices of working astronomers. It is too soon to tell if the astronomical community will switch from "AU" to "au" after the pronouncements from the IAU. Also, this proposal is incomplete in that it only addresses the abbreviation without addressing the definition, which was also changed by the IAU. I suggest we wait five years. Jc3s5h (talk) 14:02, 22 June 2015 (UTC)

• Not sure if the suggestion to wait five years was a joke. However, the IAU-recommended symbol from 1976–2012 was A (ref), which no one used. So the astronomical community never followed the recommended symbol, and I see no movement towards accepting "au", three years after the recommendation came into place. —Alex (Ashill | talk | contribs) 23:48, 23 June 2015 (UTC)

• Support per JorisvS wording. As I have learned at WP:NASTRO, sometimes it is better for Wikipedia guides to get to the point and not spend too much time explaining themselves. -- Kheider (talk) 14:05, 22 June 2015 (UTC)
• Provisional oppose (assuming there's no answer to the first two bullets below). I am still waiting for diffs showing that actual editors, on actual articles, are having disputes over this, so that guidance in MOS is needed.

• Graeme Bartlett refers to "the pointless changing of these abbreviations back and forwards" -- a few diffs, please?
• Ashill says there have been "extensive previous discussion on at least four articles" -- sorry if I missed something, but what four articles?
• Huntster says "we need some finality to all this" -- well, we do need finality to this discussion of whether to put something in MOS, and that's easily done by putting nothing unless there's an answer to my requests in the first two bullets.

EEng (talk) 17:46, 22 June 2015 (UTC)

• Diffs (from today alone, and only one per article: see the article history for additional edits): Gliese 876, Lambda Scorpi, Alpha Comae Berenices. But I agree that this has, fortunately, been more discussion in talk space than edit warring on articles.
• Previous discussion: Talk:Astronomical unit (dating back more than a decade), Talk:Voyager 1 (later moved to Talk:Astronomical unit, here, and Template Talk:convert. I think there are others, but don't know where off the top of my head.
• The main thing that convinced me that the MOS needs to say something was that an editor has made clear that if the MOS doesn't say something explicitly, the convert template will be used to enforce that editor's preferred format (au). —Alex (Ashill | talk | contribs) 18:19, 22 June 2015 (UTC)

Thanks. I notice, Ashill, that in an earlier discussion at Talk:Astronomical_unit, you said, "This seems like a solution in search of a problem. What problem does this proposal address? I agree that the British vs American spelling is a useful analogy. As long as each article is internally consistent, I see no need to enforce a project-wide standard." What changed your mind? If it's the convert thing, you'll see elsewhere on this page that (thank goodness) it was agreed convert must not be used to coerce stylistic choices, and both au and AU would be supported. EEng (talk) 18:59, 22 June 2015 (UTC)

For the reasons I gave here. I don't see the agreement you refer to from the problematic editors, which is why I have, unfortunately, come to the view that this discussion will come up again and again if the MOS doesn't simply say something. (I'd be fine if what it says is "either AU or au is fine" or "any symbol the editors of a given article damn well please is fine", but my reading of the discussion is that specifying AU has the most support. The one thing I would oppose is specifying a single symbol other than the most-widely-used one, which is AU.) —Alex (Ashill | talk | contribs) 19:29, 22 June 2015 (UTC)

• The symbol au is not the preferred symbol of just one isolated editor. It is the international standard symbol for the astronomical unit, and I for one agree with the editor referred to by Ashill that you need a damn good reason to use something different. The only authority that can trump the RS to which he refers is MOSNUM itself. The opposition to this simple change has gone for far too long. Dondervogel 2 (talk) 18:27, 22 June 2015 (UTC)

But Dondervogel2, you seem to be supporting the change to MOS (which specifies AU), while at the same time implying au! Huh? And if you were really going around changing this in articles, even as this discussion was going on, then shame on you. EEng (talk) 18:59, 22 June 2015 (UTC)

Dondervogel 2 has, I think, made it quite clear that (s)he would prefer au but most strongly prefers harmonization across Wikipedia, even if the standardization is on AU. I appreciate the flexibility. —Alex (Ashill | talk | contribs) 19:29, 22 June 2015 (UTC)

@EEng: The editing I was doing was to purge "A.U." wherever I found it. I changed this to "au" because, as Ashill correctly asserts, this is my preferred symbol, and then others followed my trails and replaced "au" with "AU". If there is consensus for "AU" I am willing to support that in the interests of harmony. Dondervogel 2 (talk) 20:15, 22 June 2015 (UTC)

Dondervogel 2, "[The symbol 'au'] is the international standard symbol for the astronomical unit" is untrue. A true statement would be "The symbol 'au' is an international symbol for the astronomical unit. The IAU is just an association of astronomers, and people are free to accept or ignore their pronouncements. BIPM only has authority over SI; any other pronouncements are just mild suggestions. The usage in the major astronomy journals is at least as authoritative as the pronouncements of these two organizations. Jc3s5h (talk) 19:16, 22 June 2015 (UTC)

The way I see it BIPM accepted IAU's authority (for want of a better word) on the matter by adopting its recommendations. Scientific articles do not normally go to the trouble of defining units, relying instead on the authority of bodies like BIPM or ISO. In this instance, BIPM has chosen to follow the IAU, resulting in a conflict with ISO. I hope we can resolve this by all agreeing on AU. Otherwise you will have me arguing for "ua" :P Dondervogel 2 (talk) 20:26, 22 June 2015 (UTC)

I can't say I've personally submitted articles to academic journals (although I've worked in the same office as people who did). But I would expect authors of scientific journal articles to follow the style manual of the publisher. I would expect the authors to write the article with the publisher's style manual next to their keyboard, and do their best to use the symbols, citation style, and every other requirement in the manual, so as to get their article published as quickly as possible. I know my former employer had cash awards for publishing; the sooner you publish, the sooner the money shows up in your paycheck. Jc3s5h (talk) 21:55, 22 June 2015 (UTC)

• OK, I give up. But look... drop the "comment". The table is full of choices (like bit/s instead of bps) that are more or less arbitrary, without explanation. MOS is bloated enough as it is. If you decide AU is what should be used, then just say so. Comments should only be used where something really needs explaining to avoid confusion e.g. calorie/kilocalorie/etc. EEng (talk) 22:03, 22 June 2015 (UTC)
• Oppose. The "Used by most RS's commonly"-rule can provide this. Dangerous for a sub-MOS to intrude SI this way. -DePiep (talk) 22:45, 22 June 2015 (UTC)

Oh and before I forget (you sure did): this thread is forumshopping, and thus invalid. BIPM is the authority. -DePiep (talk) 22:57, 22 June 2015 (UTC)

• Support "AU" is most commonly used amongst Research, Pedagogical texts, Popular science and Amateur astronomy RS's -- 70.51.203.69 (talk) 04:07, 23 June 2015 (UTC)
• Comment. The proposal says "even though "au" is officially sanctioned by the IAU". First this reads a bit childish, I'd expect a better formulated background (for a MoS page). Anyway, the IAU decision is also approved by BIPM and so in SI. -DePiep (talk) 22:23, 23 June 2015 (UTC)

Oh dear. Does the proposal really say "AU is a speed"? -DePiep (talk) 22:25, 23 June 2015 (UTC)

No. The proposal shows a new line to be added to the existing table, in the "Length / Speed" section. EEng (talk) 22:45, 23 June 2015 (UTC)

I stand corrected on my secondary note. Now will the MOS include BIPM in this? -DePiep (talk) 23:44, 23 June 2015 (UTC)

I agree that the wording could be slightly better (as JorisvS noted in the proposal). "Recommended" would be better than "sanctioned". Proposed alternate wording (which has some similarities to that proposed by Dondervogel 2:

"AU" is the most commonly used unit symbol for the astronomical unit, both in popular and professional astronomical articles, and is hence also used on Wikipedia, The [[BIPM]] and [[IAU]] officially recommend "au".<ref>{{cite web | title=RESOLUTION B2 on the re-definition of the astronomical unit of length | url=https://www.iau.org/administration/resolutions/general_assemblies/ | date=2012 | work=International Astronomical Union}}</ref><ref>{{cite web | title=SI Brochure | section=4.1, Table 6 | url=http://www.bipm.org/en/publications/si-brochure/chapter4.html | edition=8 | date=2006, updated in 2014 | accessdate=2015-06-23}}</ref>

(If we're going to appeal to authority, the authority we're appealing to should be explicitly cited, I think.) I also note that the IAU recommendation is used in English and French; "au" may well be commonly-used in French even though it's not in English, which may explain the different choice. My preference is that English Wikipedia follow common English usage, which (as we have well established) is AU. Though I also take EEng's point that we could just drop the comment altogether. Because I'm pretty sure the horse is dead by now, I wouldn't object to any of these four options (the original comment, Dondervogel's comment, my comment, or no comment at all). —Alex (Ashill | talk | contribs) 00:05, 24 June 2015 (UTC)

• Support Death to au and dots per majority practice in professional settings. When, and if, the world switches to au, so can we. But for now, we do what most do, and standardize on AU. Headbomb {talk / contribs / physics / books} 18:02, 6 July 2015 (UTC)
• Comment In response to a point below (#Where are we on this now?) but moved here to keep substantive discussion together: including the defined value of one AU is excessive and counterproductive. I doubt there are any contexts on Wikipedia in which the difference between the old value (149597870700±3 m) and the new definition (149597870700 m, exactly) matter. If there is any article in which that level of precision matters, it should be stated explicitly anyway, since readers aren't expected to refer to the MOS to know which value is being used. —Alex (Ashill | talk | contribs) 15:20, 7 July 2015 (UTC)
  • @Ashill I would expect there to be articles for which the difference matters. I have seen publications that talk about the rate of change of the astronomical unit, measured in units of km per year (or similar). Clearly with the new definition the answer is identically zero, so in this context it does matter. I do agree with you that this kind of detail is for article space, and not mosnum. Dondervogel 2 (talk) 15:48, 7 July 2015 (UTC)
• Support so that this kind of edit won't be necessary anymore. Rfassbind -talk 01:23, 8 July 2015 (UTC)
• I'm fine with "no consensus for change to the MOS": I am not convinced that the encyclopedia benefits from a rule prohibiting a usage which is mandated by important bodies such as IAU and BIPM. And in response to the inevitable objections that standards bodies don't decide everything: no, but they are at least a part of what determines usage. To ignore them is at least as serious a violation of NPOV as to follow them slavishly. Archon 2488 (talk) 22:26, 7 July 2015 (UTC)

@Archon 2488: Hardly 'mandated', more like 'recommended'. And as noted above, they used to recommend "A", which never caught on. The common usage has been "AU" for a long time. Wikipedia also follows common usage with article titles, even if there is a different officially sanctioned one. Why should be we not do the same here? --JorisvS (talk) 09:15, 8 July 2015 (UTC)

I try to resist the seduction to redo the discussions. I thought this section is about concluding the proposal. -DePiep (talk) 09:23, 8 July 2015 (UTC)

• Support because the "AU" usage is predominant in the field, most consistently used in reliable sources, while "au" and "A.U." appear to be uncommon. "AU" is also more easily recognizable as a unit symbol to more readers, "A.U." looks like an abbreviation of something (e.g. human initials), while "au" looks like a typo, and also coincides with both the ISO two-letter and IETF symbols for Australia. This is a essentially a repeat of WP:BIRDCON, and that massive RfC ended with precisely that rationale in the close, in regard to another 'standard" being advanced by one organization's adherents in a field that was not actually adopting their proposal in the real world, either.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:48, 20 July 2015 (UTC) Updated.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:24, 22 July 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Where are we on this now?

Can someone suggest how to get this discussion closed? As mentioned earlier I've dropped my opposition to the proposal (I still question how much good it does, but I don't feel strongly) but I don't think it's appropriate for me to evaluate consensus. I would like to stress, again, that I think there's no need for the comment. EEng (talk) 20:54, 26 June 2015 (UTC)

I support EEng's (implied) proposal for closure by adding the symbol 'AU', without a comment. Dondervogel 2 (talk) 21:17, 26 June 2015 (UTC)

The discussion of the proposal was started on 22 June. I suggest that we wait at least 7 days (ie until 29 June) before posting a request for closure. I think that leaving a discussion open for at least a week is normal and old practice. I'll suggest wording separately. —Alex (Ashill | talk | contribs) 00:06, 27 June 2015 (UTC)

Gosh, I thought it had been much longer. I guess a day away from the AU debate feels like a month in the country. EEng (talk) 00:19, 27 June 2015 (UTC)

Huh, it felt longer for me, too. I don't oppose not adding any comment at all when 'AU' is added, though I do think that if a comment about the reasoning behind it is useful to make editors understand why this particular choice has been made and to prevent people from posting objections simply because 'the IAU and BIPM have decided "au"'. --JorisvS (talk) 20:27, 27 June 2015 (UTC)

I propose posting a request for closure with the following text: "Would an uninvolved editor please assess the consesnsus at WT:MOSNUM#Proposal to add "AU" to the MoS. Please address three related questions: 1) Is there consensus to add a comment about the symbol(s) for astronomical unit to the manual of style? 2) If yes, is there a consensus which symbol(s), if any, should be specified? 3) If yes, is there a consensus for the explanatory text to be added?" —Alex (Ashill | talk | contribs) 18:40, 29 June 2015 (UTC)

This discussion has been stale for some time now. Above, there are seven support votes, one provisional oppose whose provisions were addressed, one oppose whose argument was debunked, and one oppose who didn't give any actual argument, but who considers this forum shopping, even though this is the talk page of the Wikipedia: page affected. Is this consensus? --JorisvS (talk) 08:44, 6 July 2015 (UTC)

I'm trying to work out who's arguments have been "debunked". Do you mean those of Jc3s5h. I do have some sympathy for his point of view, and would not object to au and AU both being permitted, in order to address that concern. It might be worth exploring whether that option might carry more support than the present proposal of AU only. I would support either one because what I seek is clarity. Dondervogel 2 (talk) 10:24, 6 July 2015 (UTC)

Is there anyone who disagrees with JorisvS's reading of the consensus? If no, then I'd say we're done and can implement the proposal (perhaps with some tweaks as suggested in the discussion). If yes, I suggest the formal request for closure route I proposed above. Pinging the two editors who opposed and haven't retracted: DePiep, Jc3s5h. I generally prefer not to assess consensus of a discussion I'm involved in unless it's unanimous, and I prefer not to interpret for others whether their concerns have been addressed (whether or not I agree). —Alex (Ashill | talk | contribs) 15:34, 6 July 2015 (UTC)

I oppose a statement that limits the symbol to AU; au should also be accepted since it is the current recommendation of the IAU, BIPM, and the "Instructions to Authors" of the Monthly Notices of the Royal Astronomical Society. I would prefer to see a mention that it has been changed from an experimental derived quantity to a defined quantity, with a link to the current definition. Jc3s5h (talk) 16:26, 6 July 2015 (UTC)

Are you suggesting that the use of au should be limited to the new IAU definition (a constant), while AU should refer to the old definition (a variable)? If so, would such a ruling be within the scope of mosnum? Dondervogel 2 (talk) 17:27, 6 July 2015 (UTC)

@Jc3s5h: That wasn't the question that was asked. The question was do you disagree with JorisvS's characterization of the consensus from the discussion? (Put another way: It's clear that you disagree with the substance of the result, but do you disagree that there is a consensus?) —Alex (Ashill | talk | contribs) 17:37, 6 July 2015 (UTC)

@Dondervogel 2: There is no mention in any of the documents I've read that au should be associated solely with the new definition. Of course, when editors are discussing some source or software that used/uses the old definition, the editor would be free to use it too, so long as there was some mention that an older definition was being used. Jc3s5h (talk) 19:05, 6 July 2015 (UTC)

Let me begin by saying I will count everyone's recent (beginning June 2015) response, including those who didn't come back to repeat their views over and over again when the question was re-asked over and over again. I count in favor Jorvus, Dondervogel 2, Graeme Bartlett, Headbomb, 70.51.202.69, and Kheider (6 editors). I count against DePiep, Jc3s5h, Quondum, Ashill, Steve McCluskey, Johnuiq, Neby, and Evensteven (8 editors). If the discussion were closed now, I think it should be closed as no consensus for change to MOSNUM. Jc3s5h (talk) 18:57, 6 July 2015 (UTC)

Not sure how you count me as an oppose, since I said Support in the discussion here. But sounds to me like we should as for closure from an uninvolved editor. I'll do so in 24 hours if there's no objection. —Alex (Ashill | talk | contribs) 19:21, 6 July 2015 (UTC)

I'd request that this section be kept to the meta discussion of where we are and whether there's consensus, keeping substantive discussion like whether we should include the specific quantity in the existing section. —Alex (Ashill | talk | contribs) 17:44, 6 July 2015 (UTC)

re Ashill 15:34. (As for !vote counting: I oppose per my 22:45 !vote; the rest is comments & arguments. I'm not sure the weighing & judging of the discussion by JorisvS at 08:44 I understand).

Have reread this plus the previous (proposal) thread. I'm fine with no consensus (no change). Both 'au' and 'AU' have a correct, though conflicting, base to be used in WP (one being by two authorities, the other one used by RS's). Following non-consensus (and so no changes to this MOS), any page editor will have to keep in mind: internal stylistic unity (i.e. use one spelling only throughout), any new article or first usage of au/AU has prevalence, editors will follow source habit, and explicit source quoted spellings (like in book title) should be followed. Nothing new. I guess not changing the MOS will keep AU in use a long time, and still leaves the option open that science community (by paper styles) evaluates to the new form. Forbidding 'au' would block this evolution. (What to do if one journal decides to change style next year? Two?). EEng's line makes most sense over this all.

All this is to say that no consensus will leave a viable solution, absorbing recent changes on long-time WP-rules in time. And, of course, it reflects the situation in that scientific domain. -DePiep (talk) 09:01, 7 July 2015 (UTC)

I have not judged anything, merely summarized the vote above and asked a question. As for including 'AU' in the MoS blocking such change: any decision to include it can simply be revisited if such a change were to occur. --JorisvS (talk) 09:05, 7 July 2015 (UTC)

As a summary, I don't recognise it. All in all, the !voting reads like an no-consensus with arguments presented (not just !votes). I think no consensus (to change the MOS) should be the conclusion. That's common WP practice, and no fatal consequences have been brought forward (i.e., no change does not disrupt anything). -DePiep (talk) 08:34, 8 July 2015 (UTC)

No change means we have to put with the nonsense symbols "A.U.", "a.u." and the like. Dondervogel 2 (talk) 09:01, 8 July 2015 (UTC)

Where was this added to the original issue? How are these unit symbols at all (are you confusing symbol and abbreviation?). Why would anyone be allowed to add nonsense symbols to an article?, per yesterday's MOS, or per any tomorrow's MOS? Cutting short: there are two options under discussion. Both have RS's. -DePiep (talk) 09:20, 8 July 2015 (UTC)

I see them as abbreviations myself, but they are used on many WP articles in lieu of symbols, and that is what I really meant. It's often done (not only on WP - also in peer-reviewed journal publications), and I strongly prefer a deprecation of this practice. And no, this is not new. Just me repeating the main reason why I support the proposal. Dondervogel 2 (talk) 10:06, 8 July 2015 (UTC)

The dotted versions are not part of the proposal. Full stop. As unit, they are not valid. How does current MOSNUM prevent you from changing those articles? -DePiep (talk) 11:23, 8 July 2015 (UTC)

It doesn't, and the dotted versions are part of the proposal because saying "AU only" implicitly excludes "A.U." and similar. But the dotted versions are used (on WP and beyond) and are very hard to track down (on WP) because the search engine ignores the dots. It would make all our lives easier if the dotted versions were discouraged from the outset. Dondervogel 2 (talk) 11:44, 8 July 2015 (UTC)

Dotted spelling is off topic (that is, all topics in this thread). I leave this thread. -DePiep (talk) 12:38, 8 July 2015 (UTC)

@Dondervogel2:I'll reply to Dondervogel2 in a new thread. Jc3s5h (talk) 12:11, 8 July 2015 (UTC)

Since the discussion has once again stagnated, I have put a request for closure up at WP:AN/RFC. —Alex (Ashill | talk | contribs) 22:04, 20 July 2015 (UTC)

Should "A.U." et al. be addressed on a wider level?

This is all WP:MOS#Units of measurement has to say about symbols vs. abbreviations:

• Standard unit symbols do not require a full stop (period). However, non-standard abbreviations should always be given a full stop.

MOSNUM does not directly address the issue, but does contain one table entry that indicates it's hard to draw a bright clear line between symbols and abbreviations, and when to use dots and when not to. The statement in the table is "The abbreviations sq and cu may be used for US customary and imperial units but not for SI units." The good example is 15 sq mi and the bad example is 15 sq km

If you want to address the issue of dots in A.U. you need a new proposal. If I were going to do it, I'd go over to MOS and revise the statement I quoted above to improve the situation for all units, not just the astronomical unit. The statement I quoted fails to say what to do if there is a standard abbreviation for a unit. If peer-reviewed science journals use an abbreviation, that makes it a standard abbreviation. Period. (Pun intended). Jc3s5h (talk) 12:11, 8 July 2015 (UTC)

There is a bright clear line. By BIPM, and so in the wider SI, there is no "unit abbreviation", let alone a "standard" one. There only exists "unit name" and "unit symbol". (note that MOSNUM confuses "abbreviation" and "symbol" in the quote). -DePiep (talk) 12:45, 8 July 2015 (UTC)

@DePiep: Please fix that error; shouldn't be controversial.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:19, 20 July 2015 (UTC)

You mean propose a change to MOSNUM? Later, maybe. btw, if it's correct what I say anyone else could pick this up. -DePiep (talk) 20:06, 20 July 2015 (UTC)

No, I meant WP:Be bold and WP:JUSTFIXIT. But it doesn't say "unit abbreviation" in MOSNUM anyway, so there's nothing to fix.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:13, 22 July 2015 (UTC)

It's pretty clear that SI units only have names and symbols, but Wikipedia uses units outside SI, and historical evolution that lead to various ways of writing full and short versions of those units mostly went on when short versions were generally regarded as abbreviations. And yet, technical publications that continue to use non-SI units tend to combine them with other units as if the short forms were symbols. So I don't see a bright clear line for non-SI units. Jc3s5h (talk) 21:15, 20 July 2015 (UTC)

The distinction between "abbreviation" and "symbol" is so subtle that it is only meaningful if one spends way too much time focusing on the MOS; I doubt it means anything to most editors, let alone readers. So the choice of whether to use "AU", "au", and "A.U." to mean "astronomical unit" is all one discussion. Note that not a single editor in this discussion has supported the use of "A.U." anyway; there are just some existing articles (and reliable sources, albeit mostly older ones) that use "A.U.". The point is that explicitly recommending "AU", "au", or "AU or au" in MOSNUM proscribes "A.U." simply, efficiently, and unambiguously. Yes, it's already said elsewhere in MOSNUM that any abbreviation involving periods/full stops should not be used as a shortened version of a unit, which is why we don't need to say "not A.U." in the comments, but I think that this remains a valid talk-only argument for including "AU", "au", or "AU or au" in the unit table. —Alex (Ashill | talk | contribs) 12:58, 8 July 2015 (UTC)

I am 100% behind Ashill on this. To argue that use (or not) of "A.U." is somehow a separate issue is absurd. I can support any one of "AU", "au", or "AU or au", for precisely the reasons he states. I honestly don't give a toss which, but some pronouncement is needed IMO. Dondervogel 2 (talk) 13:44, 8 July 2015 (UTC)

Ashill: 'not a single editor supported A.U.'. Dv2: 'that A.U. is a separate issue is absurd.' Etcetera ad infinitum. -DePiep (talk) 14:15, 8 July 2015 (UTC)

Ashill writes "Yes, it's already said elsewhere in MOSNUM that any abbreviation involving periods/full stops should not be used as a shortened version of a unit...." No, I don't think MOSNUM says anything like that (but maybe I missed it). MOS just says that if you do use a standard symbol, you shouldn't use dots. MOS doesn't say that an editor who has decided to write a unit in a shortened form should prefer a standard symbol over an abbreviation if there is a standard symbol available.

DePiep's comment is all about SI. It certainly doesn't apply to units not accepted by BIPM for use with SI. It's highly questionable whether it applies to units accepted for use with SI by BIPM, since BIPM merely recognizes the usefulness of the units; it doesn't control them. Jc3s5h (talk) 13:50, 8 July 2015 (UTC)

OK, fair enough. So I think that makes the case for including "AU", "au", or "AU or au" explicitly in MOSNUM (which is just another line in a table, not a huge deal) a bit stronger. —Alex (Ashill | talk | contribs) 13:58, 8 July 2015 (UTC)

re 'abbr or symbol "is so subtle that it is only meaningful if one spends way too much time focusing on the MOS"' - too little time for you. Your response does not reply to the post it responds to.

re 'It certainly doesn't apply to ...' - bs. What a useless threads. Bye. -14:15, 8 July 2015 (UTC)

FWIW I am happy with "close with no consensus for change"; I could accept merely listing the different symbols in the table of units for the sake of completeness, which should not be controversial, but I don't yet see strong consensus for a prescription about usage. Archon 2488 (talk) 14:11, 8 July 2015 (UTC)

Chew on this you all. So there is a Proposal with !votes, it is "concluded", that forks into "dots allowed?", and no we arehere at this period:. -DePiep (talk) 23:29, 8 July 2015 (UTC)

• As the sources don't agree, MOS should prefer AU, since it's obviously more recognizable as a unit symbol instead of some typo. WP is written for everyday readers, not just astrophysicists IAU and BIPM members with some WP:SSF axe to grind about lower-casing that their industry doesn't even consistently support. This closely mirrors WP:BIRDCON (in which one segment of editors on a biological topic were very strong supporters of a particular alleged standard (also regarding letter case) used by some-but-not-all RS, and they were overruled by the community because the usage wasn't a consistent standard used by RS, and it conflicted with everyday readers' expectations. We shouldn't use lower-case unit symbols unless the usage in RS is consistent (as it is for, e.g. km and other metric units).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:45, 20 July 2015 (UTC) Same goes for "A.U." Because WP insists on permitting that formatting for "U.S." (and damned near nothing else on WP, not even human initials), despite the fact that even the US government barely uses it any more and most American citizens don't either, it's liable to be interpreted as a country name abbreviation, or just confusing in general. "AU" = principle of least astonishment for the general public, meanwhile people who actually work with that unit recognize it in all three forms.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:51, 20 July 2015 (UTC)

A minor point: it's not "astrophysicists" who have a SSF axe to grind about lower-casing; quite the contrary. The norm in astrophysics usage (both professional and for lay audiences) is AU, which is the main argument (as far as I'm concerned, at least) for using AU. It's a group of editors who insist that the IAU and BIPM recommendations are gospel despite not being followed by most writers, including astrophysicists, who are arguing for au. —Alex (Ashill | talk | contribs)

Noted! This means that this case really, really directly parallels WP:BIRDCON (another case of standards-activism by adherents to a particular organizational camp advancing a preferred pseudo-standard that is not actually the standard in their field at all. I'm going to take this to WP:ANRFC on that basis.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:00, 22 July 2015 (UTC)
Never mind; someone beat me to it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:13, 22 July 2015 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Added to table

Per the closure of the discussion above, I have added astronomical unit to the table. The closure indicates that further discussion is possible on the comment text; I've chosen the last proposed version of the comment text (which I suggested) because I thought that it incorporated the points raised in the discussion, but I by no means view that as a fully determined consensus. —Alex (Ashill | talk | contribs) 01:28, 27 July 2015 (UTC)