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

Archive 70

←

Archive 73

Archive 74

Archive 75

Archive 76

Archive 77

→

Archive 80

New opening

To me, the current lead is lame. Like the wobbly second para of MOS central, which was removed last week, this lead seems to apologise for the existence of the manual. And it should take the opportunity to refer explicitly to its area of specialisation.

Just as an overriding statement has been inserted into the lead at MOS central that the guidelines don't apply to direct quotations, it would be neater to say that in the lead here, too, and thus to remove the references to this from the body of the text.

EXISTING

This Manual of Style, like all style guides, attempts to encourage consistency and ease of reading. The guidelines here are just that: guidelines are not inflexible rules; one way is often as good as another, but if everyone does it the same way, Wikipedia will be easier to read, write and edit.

New contributors are reminded that clear, informative and unbiased writing is always more important than presentation and formatting. (See Wikipedia:Editing policy.)

PROPOSED

Almost every Wikipedia article contains dates or numbers. This Manual of Style aims to achieve consistency in the usage and formatting of these key aspects of presenting human knowledge. In this respect, consistency within and between articles will make Wikipedia more authoritative and easier to read, write and edit. An overriding principle is that the style and formatting of chronological and numerical items should be applied consistently throughout an article unless there is a good reason to do otherwise, except in direct quotations, where the original text is generally preserved.

Your thoughts? Tony 12:46, 20 July 2007 (UTC)

• The proposed is better. That this MOS page is not a set of rigid rules is pointed to well enough by its being labelled "guidelines" in the "style-guideline" template, atop it. The current language emphasising that its contents are merely guidelines fairly well encourages editors to pay them no mind. What ought be encouraged is that they be followed.
  -- Lonewolf BC 17:07, 20 July 2007 (UTC)

• Human knowledge...as opposed to dog or monkey knowledge. How 'bout just knowledge. Other than my jokingly sarcastic minor observation, I think it is a great improvement and agree with Lonewolf BC's assessment. —MJCdetroit 18:21, 20 July 2007 (UTC)

Here's your proposal, copy-edited:

This part of the Manual of Style aims to achieve consistency in the use and format of dates and numbers in Wikipedia articles. Consist standards will make articles easier to read, write and edit. Consistency should be maintained, unless there is a good reason to do otherwise; or in direct quotations, where the original text should be preserved.

Andy Mabbett | Talk to Andy Mabbett 20:02, 20 July 2007 (UTC)

Hmm: perhaps:

This part of the Manual of Style aims to achieve consistency in the use and format of dates and numbers in Wikipedia articles. Consistent standards will make articles easier to read, write and edit. Consistency should be maintained unless there is a good reason to do otherwise. In direct quotations the original text should be preserved.

Direct quotations are a "good reason to do otherwise", not an alternative, surely? Could perhaps link last 2 sentences with ":"? PamD 22:50, 20 July 2007 (UTC)

Oh, these are all improvements on my offering. But further tweaking is required. May I chuck this into the ring, then?

This part of the Manual of Style aims to achieve consistency in the use and formatting of dates and numbers in Wikipedia articles. Consistent standards make articles easier to read, write and edit. Where this manual provides options, consistency should be maintained within an article, unless there is a good reason to do otherwise. In direct quotations, the original text should be preserved.

"Formatting" to match "use"— here, these are processes, not results, I think. I removed the future "will", coz it's stronger to suggest to all that the manual is influential now. "Within articles" is an essential point that is taken from both MOS central and the existing text and spirit of MOSNUM (i.e., don't use a mixture of 12- and 24-hour clock unless there's a good reason to do so.) But I see your concern about "consistency", which was used in two senses without clarity. Better now? Tony 01:49, 21 July 2007 (UTC)

• Implemented. Tony 12:57, 22 July 2007 (UTC)

This part of the MoS allows so many alternative styles that it’s derision to claim it truthfully was about consistency. (I liked it if it was.) Christoph Päper

I'm always open to opinions that there are too many options, but a wiki style guide needs to be a little more inclusive than one for, say, a publishing house, where people are employed to produce a more uniform product. Here, it's international, democratic and voluntary; I think the MOS does well at treading a line between too much and too little choice.

But more to the point, I think you may be missing the point about the statement on consistency within articles: it's there because of the options. Choose an option for an article and use it consistently throughout. Tony 14:24, 25 July 2007 (UTC)

Omitting commas in Wiki-formatted dates

I'd like to propose a guideline to be added to the MOS regarding formatting dates that are Wiki-linked.

Be it proposed: Editors should omit commas in Wiki-linked dates.

Example:

Markup in text	Rendered result†
[[April 11]] [[1998]]	April 11 1998
[[11 April]] [[1998]]	11 April 1998

† Depending, of course, on reader's preference settings. This is the default.

Rationale: 'Tis better to let the wiki-software handle the insertion (or not) of commas, since this is its intended purpose. The date will be rendered correctly, depending on the viewer's preference settings. This

• Makes the task of the editor a tiny bit easier (no uncertainty over whether or where to insert commas)
• Reduces the size of articles somewhat
• Is consistent with the function of wiki-date-formatting

I don't see any downsides to this. So whaddya think? +ILike2BeAnonymous 20:50, 20 July 2007 (UTC)

I see no reason to forbid people from insterting the comma. It has no effect on what is displayed, saves a meaningless amount of storage space, and frankly seems like instruction creep. The software will handle this anyway, making it a non-issue. You're going to have a tough time convincing American editors to input their dates in a format that they know is grammatically incorrect. Not much point in making rules that don't improve anything and will be ignored. — Aluvus t/c 01:42, 21 July 2007 (UTC)

Objections noted. I certainly didn't see this in terms of "forbidding" the use of unnecessary commas. How about at least a mention in the MOS that one can write Wiki-linked dates in this fashion; I don't think this is stated there, at least not very clearly. +ILike2BeAnonymous 02:45, 21 July 2007 (UTC)

A very similar proposal was made here a few months ago, and abandoned after a huge amount of discussion. I doubt that some sea change has occurred since then. The proposal will ruffle the feathers of a lot of American editors. To balance this, what should we do to annoy British editors? ;-) My opinion is that readers who do not set any national preferences for date formatting should not have to see incorrectly formatted dates, just properly formatted Commonwealth or American formats. WP has enough problems with sloppiness without encouraging editors to depart from the guidelines. Chris the speller 03:37, 21 July 2007 (UTC)

Yes, but (at the risk of inflating this discussion even more) that shouldn't be an issue, since I'm talking about properly-Wiki-formatted dates, like [[April 11]] [[1998]], which will always render a properly formatted result. The only issue is whether or not to put commas in the markup. The commas will appear (or not) correctly based on preferences set. I'm not advocating creating dates that could display incorrectly, like "April 11 1998".

By the way, could you provide a link to that earlier discussion? I don't feel like digging through the archives. Thanks. +ILike2BeAnonymous 04:07, 21 July 2007 (UTC)

The earlier discussion wasn't hard to find; Archive D4, Commas in dates. It's in the second box from the top right corner of this page. And you're not as insane as I started to assume; yes, Wikipedia adds the comma to American-style linked dates that lack the comma. But, as the earlier discussion points out, that can't be guaranteed for mirrors and forks. And the comma does not get inserted for the nav popup (at least it didn't, as I remember), and I found that fairly annoying. Chris the speller 19:18, 21 July 2007 (UTC)

This is /very/ bad idea. Here's something I told another user: It's a common misconception that commas should not be included within American dates, indeed they are automatically added in the rendered version. However, the MoS states clearly that an American topic should use American dates (there are commas in American dates), it would make it grammatically incorrect not to use commas (think of it like this: if the software fixed typos on the rendered version, would it be acceptable to have them?) Please remember that Wikipedia is forked, a lot of these mirrors don't use the same setup as Wikipedia (consequentially they may contain bad grammar if commas are removed). Matthew 20:38, 23 July 2007 (UTC)

But wait just a minute: if what you say is true—that "forked" Wikipedia content may render incorrectly if editors do things like omitting commas in Wiki-linked dates—wouldn't that be true as well for text containing any of the thousands of templates and other paraphernalia used here, which would also have to be correctly rendered by the mirrored site? Do mirroring sites simply discard things like Wiki-templates (which would surely cause rendering errors)? I'm asking because I don't know; it seems as if one (potential) problem is true, the other is as well. +ILike2BeAnonymous 05:43, 25 July 2007 (UTC)

I've seen forked articles that should have templates there... but there's nothing there. So yes, I expect they probably maybe just discard them. The same is said for images as well. Matthew 18:00, 25 July 2007 (UTC)

Then that's pretty much what I thought happened. So basically, all bets are off when it comes to material that gets web-scraped from here, so why should we be concerned with the penny-ante possibility of a comma being dropped from a date? There are much larger issues here, and in my view (and that of others), such web scrapers pretty much get what they deserve. +ILike2BeAnonymous 18:29, 25 July 2007 (UTC)

I was going to make the frequent argument that proper date formatting for dates like [[April 11]] [[1998]] wouldn't work for anonymous users and for registered users with "No preference" for dates selected, but I just noticed that it magically is working for both now. I guess our developers have fixed this since the last time I checked it. ~ Jeff Q (talk) 23:57, 25 July 2007 (UTC)

ILike2B started out by saying he/she didn't see any downsides, and now that some have been pointed out, says there are bigger problems with mirrors and forks, so this downside is negligible; I hope it's not going to come to "Damn the torpedoes". I have already indicated that the nav popup does not format dates or insert the comma, so unless the comma is included when the date is entered, American-format dates look wrong through the nav popup, causing a waste of time and resources to investigate them. There is really no value added to WP by forbidding the commas, it will definitely annoy American editors who know the correct formatting, and if commas were proscribed, one or more goofballs would pick this up and run with it, ripping commas out of every article that has American-format dates. To me it seems wasteful to have humans taking out the commas just so the computer can put them back in. Chris the speller 03:00, 26 July 2007 (UTC)

I haven't followed this debate closely. Are there any implications for the proposed new "Autoformatting and linking" subsection? Tony 03:16, 26 July 2007 (UTC)

Yes, if the proposal to eliminate commas were to be accepted, you would need to deep-six the first comma in this line:

• • [[February 17]], [[1958]] will be rendered as either “February 17, 1958” or “17 February 1958”.

While we're at it, you should add an example of how British-formatted dates would be handled:

• • [[17 February]] [[1958]] will be rendered as either “February 17, 1958” or “17 February 1958”.

Chris the speller 03:35, 26 July 2007 (UTC)

This is a storm in a teacup. Personally, I prefer to eliminate commas in wikidates, because the software automatically formats them correctly. However, I would be opposed to making this compulsory, simply because it's not something that is worth enforcing. American editors are going to use a comma, because to them that is the way things are, and very few of them are going to bother hunting down the MOS or the various discussions. As to forks, let the forks look after themselves. --Pete 03:27, 26 July 2007 (UTC)

Let me repeat that I never contemplated making this scheme mandatory, just a suggested way of formatting dates. I agree with you on forks and web-scrapers. +ILike2BeAnonymous 05:29, 26 July 2007 (UTC)

Don't know the term "deep six" (=expunge?). So, I'm getting that there's no substantive change in policy or technical specs, and that I need to insert the other way of formatting dates in the example; will do. (Thanks, Chris. How could I neglect this? I'm not American.) Tony 05:46, 26 July 2007 (UTC)

I don't know it either, had assumed it was some baseball equivalent of "hitting for six" when a cricket ball is hit over the boundary and scores six. But it isn't! Wiktionary doesn't know "deep six" but WP does: dab page at Deep six tells us it's

"an American slang term that means, when used as a verb, to "ignore", "get rid of","toss out", or "throw overboard". "Deep-six" is a reference to the approximate depth of six fathoms needed for a burial grave at sea."

The six fathoms is interesting - Shakespeare had "Full fathom five thy father lies..."! Sorry if this is a bit of a digression. PamD 08:33, 26 July 2007 (UTC)

Since we're digressing, I wanted to ask "Pete" if he really meant a "storm in a teacup". I've never heard this expression, but I have heard "tempest in a teacup" plenty o'times. Is this an updated, 21st-century variant? +ILike2BeAnonymous 23:24, 26 July 2007 (UTC)

If linking of all dates was mandatory the above comma/no comma problems would be rendered pointless by the autoformat, with the added addition that registered users who had bothered to set their date preferences would see dates displayed in their chosen format, all registered users benefit regardless of their chosen national date format. - X201 18:52, 31 July 2007 (UTC)

Pluralizing of Units of Measurements

I'm not comfortable with the current restriction never to pluralize imperial units. While I understand metric units are not pluralized in their abbreviated forms, certain imperial units are nearly always abbreviated. Particularly 10 lbs. and 100 yds. (although yards are less commonly used than pounds, the primary measurement of mass in the imperial system). In mainstream American writing, I never see 200 lb. but rather 200 lbs. Some examples are: [1] [2] [3] [4] [5] This is not advocacy to adopt a US-centric style, but since the United States, Liberia, and Myanmar are the only countries still using the imperials system, any article in English Wikipedia that does include pounds should abbreviate it as lbs. Talmage 00:01, 21 July 2007 (UTC)

Not sure I see the logic in the last sentence. Any Americans care to respond? I have no idea. Tony 01:57, 21 July 2007 (UTC)

I see it both ways, but more often with an ‘s’ for plurals; without ‘s’ is seen more frequently in technical sources. I think that what drives dropping the ‘s’ in Wikipedia, though, is more parallelism with SI metric usage whenever conversions are displayed. E.g., “a weight of 10 lb (4.5 kg)” looks a little bit less odd than “a weight of 10 lbs (4.5 kg)” and helps less experienced editors avoid mistakes like “a weight of 10 lbs (4.5 kgs)”. On the whole, though, I have no great objection to the proposal to permit it as an option – as always, with consistent usage throughout an article. Askari Mark (Talk) 02:08, 21 July 2007 (UTC)

Most appearances of lbs occur in non-scientific non-technical writings, since even in the United States, the vast majority of scientific documentation uses the metric system. I just think the following sentence looks extremely awkward: I weigh 195 lb. Also what I meant by the US-centric statement was that anytime pounds are used, it likely reflects American usage anyways since no other English speaking country uses the imperial system. Talmage 05:23, 21 July 2007 (UTC)

Talmage, English Canada and the UK still very much use the imperial system. Also, the sample sentence that you gave technically goes against the MOSNUM because lb. should be spelled out in full unless in parenthesis. I weigh 195 pounds (88.4 kg). However, as far as adding an s to certain imperial abbreviations, I could support that. —MJCdetroit 06:35, 22 July 2007 (UTC)

Normal spoken UK usage would actually be I weigh 13 stone 13 (if my mental arithmetic is right)! Weights in pounds alone are seen as US usage. PamD 09:03, 22 July 2007 (UTC)

Yes the common British English usage is to use stone as in the example above. Stone is singular and plural. Fnagaton 11:38, 22 July 2007 (UTC)

What on earth is "Talmage"? Tony 12:56, 22 July 2007 (UTC)

A more accurate question would be "Where is Talmage?" :) Fnagaton 09:40, 23 July 2007 (UTC)

Silly me; now I see that MJC was being wry.Tony 10:07, 23 July 2007 (UTC)

In the UK, most goods supplied by shops are primarily marked with Metric measurements (there are just a couple of notable exceptions; e.g. "pint of beer"). This has been the law for quite a few years. It is also permitted to mark the goods with equivalent Imperial measurements, but only if that is done in a smaller typeface. In this way, UK WP articles should use metric measurements first, with imperial measures optionally stated in parentheses. Metric measures have been taught in all UK schools since 1971. Anyone aged under 41 in 2007 will have been taught Metric from their very first year at school. Anyone born before 1955 will not have seen any metric tuition while at school. 81.178.213.159 2007-Jul-23 11:35 UTC (+ later edit)

I think you meant to say "primarily marked with Metric measurements"! [YES] That's what the law requires. Different from road signs which are in miles. (New babies announced to proud familes seem mixed - kgs for parents' generation, lbs for grandparents?) PamD 12:34, 23 July 2007 (UTC)

Unlike many guidelines, this one is comprehensive, simple to understand, and simple to apply. Plural symbols for some units, in some circumstances would be complicated. It would effectively end the guideline. I would rather delete the guideline.

I presume we are only discussing within-parentheses and within-tables. One method of thinking about a problem is to invert it. Instead of asking the question where is lbs acceptable, invert it and ask where is lb unacceptable.
Lightmouse 12:08, 23 July 2007 (UTC)

Good thinking. I suspect that we're going to come to the conclusion that the status quo should remain (no pluralising). Plurals look fine as exemplified above, but yes, in WP articles these abbreviations appear only within parentheses and in tables, where singular for all is fine, I think. Tony 13:05, 25 July 2007 (UTC)

Storm at MOS central

It's been over a clause I added to the very last section "Submanuals" (after posting the proposal at talk to no response, mind you):

Where a discrepancy arises between the text of this manual and that of a submanual, the former prevails.

The arguments for this clause are set out in detail on talk. I'm alerting my colleagues here because I think there may be support among them for better coordination between all 33 MOSs; my "discrepancy" clause is intended to encourage cross-checking and centralised discussion at MOS central when significant changes are proposed for daughter articles. It sees daughter articles as setting out greater detail rather than being separate empires.

Your thoughts? Tony 02:54, 21 July 2007 (UTC)

• I strongly support, in theory. The only caveat or catch to my mind is that changing the core MoS is harder than changing one of its sub-guidelines, so it could potentially be difficult to keep "MoS Central" perfectly in-synch at all times with the more exploratory documents. PS: Until what to do with WP:DATED is determined, please make sure that it is listed as one of the 33; we wouldn't want to lose it again!  :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 16:32, 26 July 2007 (UTC)

Proposal for the addition of a summary of this submanual at MOS central

The time has finally come to unveil a draft summary of the poorly named "dates and numbers" guidelines (dates are far too narrowly defined to encompass this topic). MOS central already has summaries of the important submanuals, with links to them at the subsection level. Therefore, it's inconsistent not to include this highly significant part of style at the central location. The role of the submanual, like that of others, will be to set out the topic in greater detail, tended by specialists. I'm also keen that there be more coordination between the submanuals and MOS central.

My aim is to produce a summary that:

1. excludes detail that is less frequently at issue, unstable, or contentious (in that sense alone, it is a summary of this submanual)
2. is better organised than the current submanual here
3. is properly copy-edited
4. includes changes arising from issues that have recently been resolved on this page, and
5. includes changes in policy that occurred to me in the process (highlighted in <font-color=darkgreen>green). I hope I've captured all of them; you'll still need to refer to the existing submanual as you read through it.

I seek your advice and feedback on this draft over the next, say, two weeks, so that it can be refined before taking it to the talk page at MOS central. I suggest that consideration be given for using the text of the summary to improve the submanual (the which case the examples should be different).

I seek your consensus on:

• (a) the proposal to include a summary of dates and numbers in MOS central in the first place
• (b) the green-highlighted policy changes
• (c) the copy-edited text—there are surely still glitches, and your attentive eyes will be appreciated
• (d) using the text to improve this submanual.

Miscellaneous points:

• I've deliberately excluded most of the first section here. Much of it is included in the new "Chronological items" section. I think that the stuff about linking (which is contentious) should be sequestered into a specifically named subsection at the end of the "Chronological items section" in this submanual. It's a visually and conceptually messy way of starting the submanual as it is, but this, I hope, can be a separate issue to the one at hand.
• MOS central's section "Scientific style" would be subsumed by this, largely. I think this summary should be located where that existing section is.

To assist you in providing advice and feedback, I've set out the headings and subheadings of the proposal for you to add your comments on (b)–(d), with space at the top for general comments, particularly WRT (a). I expect that people will scrutinise and comment on portions at a time; please note that you can sign with four tildes at a number of locations below in the same edit. If you have no issues with a subsection, an "OK" or simply nothing might be enough.

Tony 05:30, 22 July 2007 (UTC)

These improvements have already made] on the basis of feedback from users. My only concern is MJCdetroit's addition of the UK to the existing list of countries (the US, Liberia and Myanmar) for which imperial units should be the main ones, with metric units in parentheses, rather than vice versa. On consulting Metrication in the United Kingdom, yes, it does appear to be a mixed bag in the UK. However, I'd still prefer the metrics to be the main units for UK-related articles. The alternative is to explicitly state that either way is acceptable for UK-related articles. MJC's edit forces imperial units to be the main ones, with which I disagree.

I can see that my line would lead to too much flak, so does anyone object if we explicitly allow both systems for UK-related articles? Tony 08:00, 23 July 2007 (UTC)

Both units seems wisest: I think the majority of people in the UK still think in miles first, and that's what's used on road signs, although an increasing number of younger people think metric. PamD 08:39, 23 July 2007 (UTC)

Done. ("For articles relating to the UK, the main units are either metric or imperial; the choice should be consistent within an article.") Tony 13:18, 23 July 2007 (UTC)

My thinking in adding the UK was exactly as PamD put it above, that most people in the UK prefer imperial measurements over metric and that the government is still not fully metric. I wouldn't want to force anyone to do anything that they're not comfortable with. Therefore, I am OK with giving guidelines to have both and letting the editors of the articles decide which is preferred. We may want to add and the British Commonwealth after UK, as I know Canada is a "mixed bag" in this area; especially if the source is non-governmental in nature (Example: ref#3 at this article). —MJCdetroit 17:19, 23 July 2007 (UTC)

(edit conflict)Re the UK, miles are something of a special case. For smaller distances, centimetres have largely taken over (eg measurements of paintings etc) in the sort of sources we should be using and emulating. Yards/metres are just in a muddle. Johnbod 17:49, 23 July 2007 (UTC)

I think countries and individuals who insist on holding onto the old system are being tedious, I'm afraid. I made it optional for the UK only under pressure; Canada, Australia, NZ and South Africa have had metrics for many decades: there's no issue there. Tony 04:03, 24 July 2007 (UTC)

Under "Conversions", I don't think the line, [except] ...in highly scientific contexts where the likely readership can be assumed to be familiar with metric units should be included. That would be giving someone a license to start removing things like the length of insects in inches or Fahrenheit from the flash point of chemicals like Toluene. We should just leave this how it was—indicating that SI units should be the main units unless there is...

Done. Tony 04:11, 24 July 2007 (UTC)

Also, instead of directing editors to use one template ({{convert}}), direct them to the category Category:Conversion templates and allow them to choose. This way it does not appear that the MOSNUM is endorsing one template over another. I like {{convert}} for some things but I personally find some other templates in that category easier/faster to use in some cases. —MJCdetroit 17:44, 23 July 2007 (UTC)

Done. Tony 04:05, 24 July 2007 (UTC) Except, can you tell me whether all of the templates there include a non-breaking space? I've assumed they don't in the latest edit: "*Category:Conversion templates can be used to convert and format many common units, including {{convert}}, which includes non-breaking spaces." Need to adjust according to your new advice. Tony 04:09, 24 July 2007 (UTC)

I will go through the Category and let you know about the spaces. —MJCdetroit 14:25, 24 July 2007 (UTC)

---

• General comments on structure, strategic intentions
• I'm going with both inclusion in MOS central and the use of the draft to improve this submanual. Tony 05:58, 22 July 2007 (UTC)

  Any room in the summary for the binary prefixes section? Fnagaton 09:43, 23 July 2007 (UTC)

  Since this concerns a highly specialised area—computing—the link at the top of the (summarised) "Numbers" section to MOSNUM's detailed information on this topic might be sufficient. Same for Geographical coordinates. Is there a strong argument for squeezing it into MOS central? Tony 10:39, 23 July 2007 (UTC)

---

2 Chronological items

• New 2.1: Precise language

• 2.1 Times

Should a mention be made of hundred hours? As in "The attack was scheduled to start at 0700 hours"? --Philip Baird Shearer 13:28, 25 July 2007 (UTC)

This would be an extension of existing options. Is there a good reason? Would it be restricted to military contexts? Tony 14:40, 25 July 2007 (UTC)

• 2.2 Dates

--- or put a comma or the word of between month and year. This seems to assume American style "October 25, 1976" not European style "25 October, 1976" --Philip Baird Shearer 13:28, 25 July 2007 (UTC)

Will fix tomorrow. Tony 14:40, 25 July 2007 (UTC) On re-examination, I wonder whether there's anything wrong with this? US style assumes a comma between the day and the year (both digital groups), and WP, right IMV, proscribes the redundant comma that might arise in the use of the European style between spelled-out month and digital year. Fine, yes?

Tony 01:48, 26 July 2007 (UTC)

---

Why is there no acceptance of dates like 25th October? --Philip Baird Shearer 13:28, 25 July 2007 (UTC)

This is an existing requirement that, I think, reflects a solid trend in English-speaking countries towards dispensing with ordinal suffixes in dates. Are you proposing that it be re-introduced? Tony 14:40, 25 July 2007 (UTC)

---

Years - not mentioned explicitly, but needed here (there's "Eras" in the next section). We need to add that both "BCE/CE and BC/AD are acceptable." but call for consistency, and to explain where to put "AD". PamD 08:39, 23 July 2007 (UTC)

I can find nothing about years alone in the first five subsections of "Dates" in the current MOSNUM that is worth putting in the MOS summary (tell me if there is something). I found a bit about yearless dates that I've now inserted into "Dates". These first five subsections are almost entirely about linking chrological items, a contentious issue. I suggest that it be moved down to the end of "Chronological items" in the revised MOSNUM; there's already a link to such a section at the top of the section in the proposed summary. On your last point, "BCE/CE" and "BC/AD" are already piped links to those explanations, under "eras". Tony

Piped link it may be, but it leads to:

"Traditionally English copies Latin usage by placing the abbreviation before the year number for AD, but after the year number for BC; for example: 64 BC, but AD 2007. However, the placing of the AD after the year number (as in 2007 AD) is now also common..."

which doesn't help much! I agree that "Years" doesn't appear in the MOSNUM, so can't be expected in the "Summary" - a defect which ought to be sorted out, but perhaps not as part of the current process. PamD 13:32, 23 July 2007 (UTC)

So what points do your think need to be made about years? Can't think of any, apart from year ranges, which is there already. I presume that you're suggesting it be pointed out that CE/AD is back to the year 1, and BCE/BC before that? It should be under "eras", I guess. Tony 15:44, 23 July 2007 (UTC)

I think it's all there under "Eras" but would be better further up, under "Years". The lead sentence is "This section describes how to write years, decades and centuries", but it doesn't go into BC/AD and BCE/CE: there are links to articles on these, but we need to say (a) either system may be used, (b) be consistent, (c) remember AD goes in front, the others all after. Perhaps "BP" and "MYA" should remain under "Eras": they seem to be rather different. PamD 16:18, 23 July 2007 (UTC)

I've removed the "Eras" subsection and put it all under years. Please comment now on "Years". Tony 09:25, 24 July 2007 (UTC)

"Years" looks fine now, thanks. Much clearer without the "Eras". One last small thought: might it be helpful to include an explanation of what CE/BCE mean, as it's a bit puzzling without if you don't know? PamD 17:33, 24 July 2007 (UTC)

I find that difficult. Did you have a brief explanation in mind? It's like explaining year as the period of time stretching from 1 Jan to 31 Dec. Tony 01:50, 26 July 2007 (UTC)

Sorry, perhaps "expansion" would have been clearer than "explanation". Something like

(Some writers use CE and BCE, ("Common Era" and "Before Common Era"), to avoid the overtly Christian associations of AD and BC ("Anno Domini" or "year of the lord" and "Before Christ".)).

Except that that version has ugly nested brackets! But that's the info I suggest adding - could perhaps omit the explanation of AD/BC as more people are familiar. I suspect some people may think CE stands for Christian Era. (I've just checked the article to which BCE redirects, and corrected what I'd written above from "Current" to "Common", so I had it wrong too!) PamD 08:17, 26 July 2007 (UTC)

(delurking) As a matter of chronological nicety, it might be quite helpful to explicitly define the year as stretching between those two dates. At various points before 1600 (& perhaps later, I'm quoting from memory at the moment), the year was defined as beginning on Christmas, 25 March, or 11 September depending on custom & usage. If someone is using a date from a calendar that does not map precisely onto a 1 Jan.- 31 Dec. year (for example, from a date given as "Anno Hajiri", but with no month or day), it would be convenient for them to provide the date in the original form either before or after the AD/CE version. -- llywrch 05:13, 26 July 2007 (UTC)

Llywrch, please lurk no longer. Should we then have to define "day" as stretching from midnight to midnight? I certainly think that these definitions are too detailed for MOS central; and unless there's solid support from others here, I suspect that they're too detailed and unnecessary for a back-pasting of the new sections into MONSUM. Who doesn't know now what the boundaries of a year are? I've insert boundary definitions for centuries and milliennia only because they're counterintuitive and often misunderstood. (That could come out of the MOS central text and be retained here if people want.) Tony 06:20, 26 July 2007 (UTC)

No, I merely pointed this out because confusion is possible. (Then I let myself be distracted from my point due to a specific case. Darn...) It would be helpful, though if the MOS included a simple statement to the effect that "unless otherwise stated, units of time begin & end at the points most commonly accepted in the English-speaking world." Perhaps this might discourage some arguments. As for centuries & millenia, I find some of these cases so confusing that I'd prefer to avoid writing statements like "the beginning of the 3rd century BC" entirely! -- llywrch 19:58, 26 July 2007 (UTC)

The draft doesn't say "the beginning of ..": it just gives examples of centuries and millennia (strictly speaking, decades, too, go from 1 to 0 (1981–90). But trying to get people to refer to 1990 as part of the 80s, well, I don't think that way. So I left it out. The only issue is whether the stuff about the year 0 and centuries and millennia should be omitted from the MOS-central summary text, while retained here. MOSNUM, after all, should be the place for extended details that people can link to from MOS-central. Tony 01:11, 27 July 2007 (UTC)

For an overview of some of the complexities of calendar changes etc you might like to look at [6] from a site aimed at genealogists. Mind-boggling. Not for MOSNUM, though I'm sure historians will be aware of the usages for their own periods, just mentioned as of passing interest! PamD 08:26, 26 July 2007 (UTC)

Also Old Style and New Style dates, and on the talkpage Talk:Old Style and New Style dates#Two different interpretations --Philip Baird Shearer 08:16, 1 August 2007 (UTC)

• 2.3 Longer periods
  • Year ranges: "A closing BCE year " should for consistency be "A closing BCE/BC" year PamD 08:39, 23 July 2007 (UTC)

Done. Tony

---

Supposing one is talking about the first RAF 1,000 bomber raid of WWII that occurred on night of 30/31 May 1942. How should such dates be represented given that 30 May will be inverted if linked and the option is set in the user options? --Philip Baird Shearer 13:28, 25 July 2007 (UTC)

You've raised a reasonable usage of the slash that I'd include if it wasn't for the stupid autoformatting function, which won't accept the slash, just as it won't accept a date range with en dash (or, for the matter, the hyphen). I hate that inflexible autoformatting; it needs an overhaul, but they won't do it. Tony 01:58, 26 July 2007 (UTC)

Convenience link back to the draft summary

3 Numbers

• 3.1 Spelling out numbers
• 3.1.1 General rule

• 3.1.2 Exceptions

• 3.1.3 Hyphenation

• 3.2 Large numbers
  • Perhaps a need to mention crores and lakhs in articles relating to the Indian subcontinent, since they are used in daily life and news reports? Need to point out the old 10¹² usage of billion in older (say pre-1950s) British usage? -- Arwel (talk) 13:45, 22 July 2007 (UTC)

Has this come up before? These units are not mentioned in the existing version. Are they in the India-related MOS submanual? Is there point in using them if only Indians can understand them? It might be covered in a link to it, but there would have to be support for this. Want to raise it as an issue below in a stand-alone section? Tony 14:17, 22 July 2007 (UTC)

• • "Avoid overly precise values " doesn't make sense without examples - are these planned for later inclusion? PamD 08:39, 23 July 2007 (UTC)

Oops, forgot. Examples completed now. Tony 13:18, 23 July 2007 (UTC)

Billion should be expanded to mention Long and short scales, and that Wikipedia uses the short scale Billion of 10⁹ unless it is explicitly mentioned that in a specific context that it means 10¹². This is important to highlight for foreign language editors who's native system is long scale as they often work with figures from a foreign language translation an they may not be aware that in English it is usual to use the short scale. BTW UK was long scale before 1974. --Philip Baird Shearer 13:51, 25 July 2007 (UTC)

I'll make this straightforward change. Tony 14:34, 25 July 2007 (UTC)

Not so fast; why complicate matters? At the moment, the draft says "Billion is understood as 10⁹. After the first occurrence in an article, billion may be abbreviated to unspaced bn ($35bn)." What kind of context would require the long scale? It would be nicer to keep this simple, don't you think? Otherwise, it has to be something like this, which is kind of complicated: "Billion is understood as 10⁹, that is, on the short scale (unless it is explicitly mentioned that in a specific context that the long scale is being used, where billion means 10¹²). After the first occurrence in an article, billion may be abbreviated to unspaced bn ($35bn)."Tony 04:35, 26 July 2007 (UTC)

---

Adding Long and short scales to the "See also Magnitude prefixes and Order of magnitude." would be useful. Any reason for not using the {{see also}}? --Philip Baird Shearer 05:57, 30 July 2007 (UTC)

Long and short scales added. Didn't know about the see-also template, but ... no, can't see much use for it. Tony 10:21, 30 July 2007 (UTC)

I think a better link than Commas is Commas. --Philip Baird Shearer 05:57, 30 July 2007 (UTC)

Indeed—done. Tony 10:21, 30 July 2007 (UTC)

• 3.3 Decimal points
  • OK -- Arwel (talk) 13:45, 22 July 2007 (UTC)

I think the wording is silly. a "decimal point" is far clearer than "period". What is needed for those editors from Decimal separator#Comma countries that in English a decimal point is used between the between the integral and the fractional parts of a decimal, and that a comma is used symbol as the thousands separator. And probably a mention that when a number in numerical is taken from a non English language source that care is taken with the translation of the decimal seperator and the thousands separator. --Philip Baird Shearer 13:51, 25 July 2007 (UTC)

Let's agree on something: I won't call you "silly" if you don't call me "silly". Tony 14:04, 25 July 2007 (UTC)

I agree not to call you silly, because I never call any editor silly. I did not call you silly, I said "I think the wording is silly" --Philip Baird Shearer 14:23, 25 July 2007 (UTC)

Call my wording silly, you call me silly. Your input here is valuable. Please be positive. Tony 14:32, 25 July 2007 (UTC)

How is this? "A decimal point is used between the integral and the fractional parts of a decimal; a comma is never used in this role (6.57, not 6,57)." Commas as thousands separators are comvered under "Large numbers". Tony 04:14, 26 July 2007 (UTC)

But a comma IS widely used in that role in many places all over the world. However, it isn't common in many English-language (English as the main language) countries. Why doesn't WP just adopt whatever has been thrashed out in International standards? They have already done the donkey work of avoiding ambiguities and addressing conformity. 81.178.115.45 2007-07-25 20:00 UTC

I'm with Tony1 on this. The way around 81...'s objection is simply to change Tony's suggested language to "a comma is never used in the English Wikipedia" (an in point of fact, many of the non-English ones do use this weird comma-as-decimal thing.) — SMcCandlish [talk] [cont] ‹(-¿-)› 00:26, 27 July 2007 (UTC)

I've changed the draft wording thus. Tony 01:04, 27 July 2007 (UTC)

• 3.4 Percentages
  • Perhaps a recommendation to use percentages rather than pro mille (⁰/₀₀) figures, since they are uncommon in English usage (I've only seen them in translated documents). -- Arwel (talk) 13:45, 22 July 2007 (UTC)

Unsure that the introduction of this point is appropriate in a summary. Does it need to be in the more detailed MOSNUM? Tony 13:18, 23 July 2007 (UTC)

Convenience link back to the draft summary

4 Units of measurement

• 4.1 Which system to use
  • OK -- Arwel (talk) 13:45, 22 July 2007 (UTC)
  • I added UK to the list. —MJCdetroit 04:00, 23 July 2007 (UTC)

Made it optional for UK-related articles—see notes above. Is that OK? Tony 13:18, 23 July 2007 (UTC)

The UK needs removing from the first bullet point --Philip Baird Shearer 14:18, 25 July 2007 (UTC)

Thanks; done. Tony 14:36, 25 July 2007 (UTC)

• 4.2 Unit symbols and abbreviations
  • Seems OK, apart from the mis-spelling of "Fahrenheit", which I took the liberty of fixing. -- Arwel (talk) 13:45, 22 July 2007 (UTC)
  • Added or imperial gallon,... —MJCdetroit 04:00, 23 July 2007 (UTC)
  • Anyone know whether you say "degrees farenheit" with small "f"? Both Celsius and Kelvin articles seem to make a consistent distinction between, say, "Kelvin scale" and Celsius scale, and 20 degrees kelvin, and Celsius units and 20 degrees celsius; the Farenheit article contains no examples of the latter, and a search of the Internet reveals both upper- and lower-case f in that role. I'm confused. Tony 13:56, 23 July 2007 (UTC)
  • Whoa! At least Kelvin, Celcius, and Fahrenheit should always start with a capital letter (not sure about Centigrade though), as they are all names of people. Additionally, since Kelvin is an Absolute scale, you would say "two hundred Kelvin", and NOT "two hundred degrees Kelvin". 81.178.213.159 2007-Jul-23 15:41 UTC

The no-degree symbol point is already in the text. It needs to be said that you don't include the word degrees, as well, which I'll add. I think I'll leave notes at those articles about the upper/lower case inconsistencies, then. Tony 15:48, 23 July 2007 (UTC)

Correct usage is upper case for degrees Celcius, Fahrenheit and Rankine, and lower case for kelvin and degrees centigrade. Thus a change of temperature of 1 degree Celsius is

1 deg Celcius = 1 deg centigrade = 1.8 deg Rankine = 1 kelvin = 1.8 deg Fahrenheit.

Thunderbird2 20:20, 7 September 2007 (UTC)

• 4.3 Conversions
  • Mention the {{convert}} template here?

Done. Tony

5 Currencies

• 5.1 Which one to use

• 5.2 Formatting

7 Geographical coordinates

Partial dates seems to have become misplaced under this section heading.

It's a section I found bemusing on first encounter, and still feel is unclear. "Dates which do not reflect users' preferences ...": I thought it was telling me that a user following that link would end up at a page other than where s/he wanted to go. It's all very negative. Could usefully all be scrapped, replaced by the couple of sentences explaining how User Preferences affect day/month dates, which I've just seen elsewhere ... ah yes, it's your "Autoformatting and linking" proposal, which seems sensible, thanks. PamD 16:40, 25 July 2007 (UTC)

So are you suggesting it should just be removed? Is there nothing to say about the topic? I must say that I was perplexed as to what to do with it: my brain melts when I try to read it, and it's clearly been pushed and pulled about by parties who disagree on it. What to do? Tony 01:02, 26 July 2007 (UTC)

Convenience link back to the draft summary