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

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

Archive 125

←

Archive 130

Use nowrap template around all dates?

I have researched this subject enough to have found a discussion in Archive 130 "NBSP and hyphens in citations". The upshot seems to be that nowrap should no longer be used for dates in citations. What about dates in running text? I think that using nowrap around "2 May" (or NBSP inside it) makes editing harder on the eyes (for experienced editors) and/or confusing (for new editors). I'm all for NBSP between numbers and abbreviations or symbols such as "23 km", as this guideline clearly indicates. The guideline does not, however, call for NBSP or nowrap for all dates and all numbers, such as "250 militiamen", and I used to think that was clear enough, but at least one experienced editor read it and drew the opposite conclusion. We should probably clarify whether dates should generally be nowrap-ped or un-nowrap-ped. Chris the speller (talk) 18:46, 27 November 2010 (UTC)

I don't understand the last sentence. Apart from whether the guideline should be changed, MOS:NUM#Non-breaking spaces presently specifies nbsp (or presumably Nowrap) for "27 November or November 27" and "November 2010". As for "250 militiamen", I don't Nowrap that, but "other places where breaking across lines might be disruptive to the reader" means whatever you want it to mean. Art LaPella (talk) 19:25, 27 November 2010 (UTC)

I try to always nowrap or non-break a numeric value and its unit symbol (1.21 GW lightning bolt → 1.21 GW lightning bolt) as well as most anything where two members of a pair complete a noun or a compound adjective; particularly where one side of the pair has no more than three characters-worth of equivalent width in order to avoid creating unnecessarily large (or unnecessarily larger) voids at the end of a line. Thus, I will also do 6:30 p.m.. This idea applies also to the nonbreaking hyphen; ergo, I also write…

The alloy known as Pt{{nbhyph}}10Ir → The alloy known as Pt‑10Ir

He lifted 10{{nbhyph}}kilogram object→ He lifted 10‑kilogram object

Until the age of twenty{{nbhyph}}one→ Until the age of twenty‑one

I would nowrap (or NBSP) “2 May” or (May 2). I would not no-wrap “250 militiamen” and certainly not “2500 militiamen” (neither is particularly confusing to the eye and the latter one is too large of an end-of-line hole). Accordingly, I have no problem with what MOSNUM says in that regard. The idea of no-wrapping numeric measures that employ a unit symbol is that beginning a line with something that isn’t a word like GW or pm is just too awkward for the eye and interrupts the train of thought. It avoids end-of-line awkwardness like this:

He sweated a great deal as he lifted a 10-
kilogram lightning rod tipped with a Pt-
10Ir ball. He wasn’t allowed to participate
in safety-related work until he was twenty-
one years old. Finally, one night at 6:30
p.m., the lightning rod was hit. The flash
of lightning was captured so all of its 1.21
GW of power could be routed to the flux
capacitor.

And then he found a 4×4 Toyota pickup in his garage, got the chick, the asshole on Wikipedia waxed his Toyota all day, and all was well with the world. Amen. Greg L (talk) 22:17, 27 November 2010 (UTC)

Art, I see why you didn't understand the last sentence of my original question above. I had looked at the section "MOS:NUM#Non-breaking spaces" and somehow missed the line about "between the date number and month name". After much research, I see that the bullet item was added at 09:02, 9 September 2010 by Mclay1. This was following an example that had been added at 17:57, 11 June 2010 by JackofOz. Both changes were made without discussion. I feel that this represents a sea change in date formatting that is comparable in scope to the wholesale delinking of dates that used to provide individually customized formatting of almost all dates. The fact remains that nearly all dates in WP currently lack NBSP or nowrap. Is this causing a problem for our readers? (I doubt it.) Are we building bots to convert them all? (I hope not.) Why does the section "MOS:NUM#Dates" have no mention of NBSP? (Editors are likely to code dates as shown in those examples and omit the NBSP.) Chris the speller (talk) 01:45, 28 November 2010 (UTC)

I didn't add that rule; I just tidied up the wording. It was there before I started editing MOS:NUM. McLerristarr | Mclay1 06:15, 28 November 2010 (UTC)

If date nowrapping is bad because "nearly all dates in WP currently lack NBSP or nowrap", then nbsp and nowrap should be junked altogether for the same reason, along with several other guidelines. Why does MOS:NUM#Dates not mention nbsp? For the same reason as the rest of the contradictions. Are we builiding bots to convert them all? Well, it's in my AWB edits. I prefer editing to politics, so if date nowrapping isn't a consensus then please change the guideline. Consistently this time. Art LaPella (talk) 06:21, 28 November 2010 (UTC)

What, are there browsers so brain-damaged as to allow line wrapping after a hyphen unless an obscure special character is used? I can think of no situation when it wouldn't be undesirable for that to happen other than to indicate syllabification, which would anyway use the "soft hyphen" character. A. di M. (talk) 12:07, 28 November 2010 (UTC)

IIRC, both The TeXbook and The Chicago Manual of Style call for hard spaces in such places. (The solution to the harder-on-the-eyes problem would be having a simpler way than   to code the hard space, but don't let me go into that once again.) A. di M. (talk) 12:04, 28 November 2010 (UTC)

Well, in theory one could use a Unicode nonbreaking space character; on Mac OS, at least, that's easy to type: Option-Space. The problem is that it will look just like a regular space onscreen. While that will reduce the visual clutter, it will also make it rather difficult to tell that a nonbreaking space has been used. With regards to dates, perhaps the most reasonable compromise would be templates that apply the space formatting automatically. It would probably be difficult to get people to use them, though. // ⌘macwhiz (talk) 14:25, 28 November 2010 (UTC)

I’m on a Mac, ⌘macwhiz, and used such a technique—just out of habit—early on. But the result is code that is invisible to those using Barbarian-OS when in edit mode and, thus, they are not given little clues to “Dude, copy this sort of thing.” Greg L (talk) 19:57, 28 November 2010 (UTC)

There are some browsers which automatically replace all non-breaking spaces with ordinary spaces when submitting a form, so any literal non-breaking space character used in the source will magically turn into a normal space as soon as someone using such a browser edits and saves the section. A. di M. (talk) 15:01, 28 November 2010 (UTC)

The MOS now says "Use a non-breaking space ... between the date number and month name". This is unequivocal. Will I now get complaints from other editors if I change "November 28" to "28 November" without adding NBSP or nowrap in an article that otherwise has all dates in day-month format? If I add or change some dates in an article that has 33 dates with NBSP interspersed with 33 dates with nowrap, should I change to all one or the other, or leave the disorderly conglomeration? On first adding dates to an article, should I start with NBSP or nowrap? I have no confidence that there was consensus to start nowrap-ping all dates, and even if there was and still is, these and other questions should be worked out before we plunge in headfirst. Chris the speller (talk) 16:55, 28 November 2010 (UTC)

The current MOSNUM wording says a non-breaking space should be added between the date number and month name (e.g. 28 November or November 28) and that for expressions of time, A hard space (see above) is advisable between the numerals and the a.m./p.m. This wording has been there for a long time and your objections amount to a tempest in a teapot. Nowraping skills (via the {nowrap} template or the  ) are advanced skills that aren’t expected of all editors. The current wording regarding time doesn’t *require* volunteer wikipedians to know or remember advanced wikimarkup and HTML before contributing to Wikipedia when all they want to add is the time something occurred because the current wording says it is “advisable.”
The section of MOSNUM addressing dates was requiring that editors flat “use” a non-breaking space. That’s overly prescriptive language as it implies the expectation that contributors possess advanced wikimarkup and HTML skills before one can contribute. So I just now changed the wording to be consistent with how MOSNUM handles time: It is advisable to use a non-breaking space.
But you already know about such advanced skills. So let’s talk about your situation. As to your question: Will I now get complaints from other editors if I change "November 28" to "28 November" without adding NBSP or nowrap in an article that otherwise has all dates in day-month format? No one can know what editors might complain about and it can’t be helped be helped if they do. If you don’t want to nowrap expressions of time or dates, then don’t. It especially doesn’t matter if such expression occur within the first twelve words from the beginning of a sentence since they would seldom wrap for our readership. But since having the 6:30 p.m. or November 22 break apart with half of the expressions wrapping to the beginning of the line below looks poor, MOSNUM allows others (and those with bots) to come back later and add the nbsp or {nowrap} to these expressions; actually, MOSNUM advises that they should do so. So don’t profess to be all bewitched, bothered and bewildered when they improve them and don’t revert them.
As for how some articles might have dates hardspaced with the {nowrap} template and others using non-breaking spaces (as if existence of different techniques that accomplish the same end is an intractable, oh-so-confusing dilemma), it doesn’t matter and such quibbling is more ‘tempest in a teapot’ borne out of a healthy dose of [[I DON'T LIKE IT]]. Personally, I use a non-breaking space if there is only one space to deal with to keep an expression from wrapping. If the expression requires two or more (not often), I use the {nowrap} template.
Finally, as for your I have no confidence that there was consensus to start nowrap-ping all dates, and even if there was and still is, these and other questions should be worked out before we plunge in headfirst: Yeah… I knew that was where you were heading with all your posts, above. Yes, there is indeed a consensus to do so; you don’t agree. I’m fine with that. Do whatever you please when you add new dates and times since no one will take you to ANI for not no-wraping them—not unless you start stripping out nonbreaking markup out of dates just to be difficult.
Greg L (talk) 19:18, 28 November 2010 (UTC)

OK, if date nowrapping is a consensus after all (and I didn't say it is), then can we fix MOS:NUM#Dates to match? Art LaPella (talk) 20:06, 28 November 2010 (UTC)

I should certainly think so. I trust it is your intention to mirror the tone here on MOSNUM(?): It is advisable to use a non-breaking space… We welcome contributions from editors with wide-ranging skills. Editors proficient in writing English but not in wikimarkup or HTML should be able to contribute without flat-out *violating* a guideline; ergo, the “is advisable” allows more experienced old-timers to come through later and improve details such as fine typography. Greg L (talk) 20:19, 28 November 2010 (UTC)

I didn't intend to make such an edit myself unless there is a more clear-cut consensus. And the edit I had in mind was to simply add nbsp to dates in that section (and throughout the page), that is, set an example rather than talk about it. Art LaPella (talk) 20:27, 28 November 2010 (UTC)

Greg, your tone verges on hostility. No personal attacks are needed to resolve this issue. I had a valid concern that having an occasional "28" on a separate line from "November" would not really confuse or even jar very many readers, while the antidote could make an article more difficult to read in edit mode, could put off or confuse newer editors, and could undermine existing editing tools for cleaning up dates (I have developed and used a number of tools to clean up a mish-mash of date formats in articles). And no, the wording has not been there for a long time; go back six months, and the MOS said nothing about non-breaking spaces between month and day. When the month and day example was first inserted into the middle of the list of examples, I imagine that many experienced editors (myself included) failed to notice it for quite a while. For many, many years the MOS did not encourage the use of NBSP in ordinary dates. Your second-guessing of my motives is not only unfriendly, but wrong. It's not that I don't like the idea; I have been on both sides of format issues (such as linking all dates and then delinking them), switching my support when a valid consensus appeared, but the instruction to "Use a non-breaking space ... between the date number and month name" came by degrees, without any discussion, and no consensus that I can see. Thank you for softening the wording to "is advisable". Art, thanks for your ideas to bring the date examples more in line with the section on non-breaking spaces. Chris the speller (talk) 20:33, 28 November 2010 (UTC)

Now you are just wikilawyering. Please don’t try to hide behind the apron strings of baseless claims of “personal attacks”. I made a case for how your arguments are hollow and the basis for your reasoning doesn’t withstand critical scrutiny. No one here said you and your religion stinks, that you fail to regularly apply deodorant in the morning, and that you should be waxing my way-cool 4×4 Toyota all day long. This is not primary school and the people here are not required to admire you thoughts and edits and claims as much as you do. And, just pardon me all over the place, but I still think many of your above observations—like If I add or change some dates in an article that has 33 dates with NBSP interspersed with 33 dates with nowrap, should I change to all one or the other, or leave the disorderly conglomeration?—are much ado about nothing. Ergo, your conclusion in your above post (these and other questions should be worked out before we plunge in headfirst) is one that appears to be built upon a facade of great grief. Greg L (talk) 21:06, 28 November 2010 (UTC)

I haven't mentioned your tone because you're having a relatively good day, but Chris might not know that. Art LaPella (talk) 21:13, 28 November 2010 (UTC)

Thanks. I admire your style and sense of humor. ;-) Greg L (talk) 21:21, 28 November 2010 (UTC)

Chris is starting to remember. He's going to make a 90-degree turn and go fix some articles. Chris the speller (talk) 22:51, 28 November 2010 (UTC)

Well, with good sportsmanship like that, I feel like a poopy-head now. :-) Greg L (talk) 23:02, 28 November 2010 (UTC)

long dates and the use of the comma

Hi

I have just found an editor changing (9,000 - 3,000 BCE) to (9,000 - 3000 BCE) using AWB

I am a little concerned that I cannot find anything in the MOSNUM to cover this. The article has sections which use date ranges such as X,XXX,XXX - X,XXX,XXX and XXX,XXX - XXX,XXX and X,XXX to X,XXX.

It seems to me that it is normal to use the commas in all those date ranges ?

Chaosdruid (talk) 11:40, 28 November 2010 (UTC)

"Numbers are not delimited when they are part of mailing and shipping addresses, page numbers, or years with four or fewer digits". Anyway, it should be 9000–3000 BCE, with no comma in either date, an unspaced en dash rather than a spaced hyphen, and a non-breaking space before the BCE. A. di M. (talk) 11:59, 28 November 2010 (UTC)

I am aware of the ndash but do not apply the rule on talk pages

Thx for the info on the comma though as I must have missed it when reading MOSNUM on this silly smartphone

can you point out where exactly that quote is from? Chaosdruid (talk) 12:15, 28 November 2010 (UTC)

WP:MOSNUM#Delimiting (grouping of digits). A. di M. (talk) 12:35, 28 November 2010 (UTC)

If anyone knows where X,XXX appears in the MOS as a way to denote years, it would be helpful to point those out so those instances can be correced. (not talking about xx,xxx and above which are quite ok). Hmains (talk) 19:43, 28 November 2010 (UTC)

It does not appear in the MOS, as far as I know. XXXX is the right way, as you can see by following the link provided above by A. di M. Chris the speller (talk) 20:38, 28 November 2010 (UTC)

So what IS the deal with birth/death locations in the opening?

An editor has replaced "John Smith (January 0, 0000, Somecity, Somecountry - January 0, 0000, Somecity, Somecountry)" with "John Smith (January 0, 0000 - January 0, 0000)" and moved the birth and death locations to the body of the article, with an edit summary of "WP:MOSDATE". (There is no infobox in this case.)

So which of these is correct:

This is indeed per WP:MOSDATE (in which case the changes should or indeed must stay), or
It is just his personal preference (in which case the edit can be reverted, and the editor advised to not incorrectly cite MOSDATE to justify his personal preference)?

Apparently, MOS:DOB used to say "Locations of birth and death are given subsequently rather than being entangled with the dates." However, it doesn't say this anymore.

On the other hand, at MOS:DOB it says "At the start of an article on an individual, his or her dates of birth and death are provided..." and the main example given is "Charles Darwin (12 February 1809 – 19 April 1882) was a British..." (no locations given). It doesn't state ""At the start of an article on an individual, only his or her dates of birth and death are provided...", but it would be possible to infer this from the the example. (But if it is policy, why is it not stated but rather left for us to infer?)

So what it is? I'm not asking what it should be or what one personally prefers, but whether another editor can properly change with an unassailable cite of MOSDATE.

((There are some discussions of the matter at these places: Wikipedia talk:Manual of Style (dates and numbers)/Archive 85#Use of place of birth/death and Wikipedia talk:Manual of Style (dates and numbers)/Archive 124#Birthplace in opening and Wikipedia talk:Manual of Style (dates and numbers)/Archive 127#Dates and places of birth) Herostratus (talk) 04:46, 11 October 2010 (UTC)

IMO it should be handled case by case. IIRC, someone argued that the town of birth is not always so relevant to someone's life as to deserve a mention in the first sentence (and I agree), but then it is even rarer for the month and day of birth to be relevant enough and yet I don't remember anyone suggesting that normally only the year should be provided. (Personally, in over 60% of the cases I'd say (19xx, Town, Country – 20xx, Othertown, Othercountry) or (born 19xx in Town, Country).)A. di M. (talk) 13:21, 11 October 2010 (UTC)

I think the consensus was "it all depends", so maybe there should be something that indicates to an editor that just because a place of birth & death is or is not shown in one biographical article doesn't require following the same practice in the piece that he or she is writing or editing. However, I don't know how many editors would consult the Manual of Style, or know where to look. —— Shakescene (talk) 13:30, 11 October 2010 (UTC)

Given no rule to the contrary, my personal preference is put only the dates in the parenthetical comment; it's far easier to read. To pacify those that want easy access to the place of birth and death, why not add an appropriate person infobox that includes the appropriate information? Those things are appropriate to an infobox; adding them as parenthetical comments in the first line of the lead seems to be tantamount to a list of trivia to me, and we don't like those... // ⌘macwhiz (talk) 20:50, 12 October 2010 (UTC)

It probably does all depend on context, but usually it is ungainly and cluttered to squash full dates and locations within parentheses right at the opening. Tony (talk) 00:55, 13 October 2010 (UTC)

Yes, it's something that struck me reading professional biographies, that start with the birth place and date of the subjects grand-parents, or the exact time of birth - these things occupationally summon an image, or might be considered making a researched fact widely available, but in general they are irrelevant to the story and would be better relegated to a footnote, and if you read several biographies in a row, come across as as amateurish as the geographical texts that begin "XXXX is a city of contrasts" - and there are many. Rich Farmbrough, 10:40, 13 October 2010 (UTC).

I would be inclined to say: neither. The style isn't in MOSDATE, so it can be discussed. The editor should just be told "that's not in MOSDATE any more" not "advised to not incorrectly cite MOSDATE to justify his personal preference" - this might appear rather short on good faith. Rich Farmbrough, 10:33, 13 October 2010 (UTC).

Oh goodness no, I wouldn't put it like to the other editor. I was just being succinct, here. Herostratus (talk) 17:01, 14 October 2010 (UTC)

I still say just put the years in the lead, since the people that want birth and death details in the lead have not come up with any good reasons to have an exception to the Wikipedia:Manual of Style (lead section) guidelines. My compromise is to put the full dates and places in the infobox and the body of the article first, then use only years in the lead section. The lead needs to be a summary of the body and infobox, not the other way-round. At least that is WIkiedia convention. Older encyclopediae made a point of emphasizing exact dates and places perhaps, but they also took pains to use proper forms of address, like "the honourable", "the right reverend" "esquire" etc. which generally we do not require. The years give a quick summary and context, all that a lead section is supposed to do. And sylistically long parenthetical lists with dashes make readability worse. W Nowicki (talk) 16:25, 15 October 2010 (UTC)

I fully agree. Compare the following:

George Washington (February 22, 1732 – December 14, 1799) was the dominant military and political leader of the new United States of America from 1775–1797, ...

George Washington (1732–1799) was the dominant military and political leader of the new United States of America from 1775–1797, leading the American victory ...

George Washington (born February 22, 1732 in Pope's Creek Estate, Westmoreland County, Virginia; died December 14, 1799 in Westmoreland County, Virginia) ...

The first is what we have in the article George Washington right now (Wikipedia's standard convention for biographies), as seen from Google. The other two are approximations to the Google snippets we would get with the two major alternatives. I think the second line is superior and the third is the worst of the lot. We don't need to prove that we are a serious encyclopedia by using an old-fashioned but impractical convention. We are already encyclopedia #1. It is our job to innovate. Our articles have lead sections (many if not most encyclopedias don't), and that makes certain changes necessary. This is one of them. Hans Adler 16:59, 15 October 2010 (UTC)

I don't fully agree; dates should not be removed from the lede unless they are both in the infobox and in the body. If that's done, although I still think the dates should be in the lede, I wouldn't object to their removal.

However, I don't think the place should be in the lede unless important; if, for example, the person was executed, then the place of execution probably should be in the lede.

In either case, this article WP:MOSDATE is not the appropriate guideline to cover places. — Arthur Rubin (talk) 17:13, 15 October 2010 (UTC)

I agree with Arthur. Readers routinely skip sidebars and infoboxes. So any key information that is mentioned in a photo caption or sidebar (like an infobox) may (should?) be duplicated in the main body text if so desired; that includes linking the first occurrence of a word. 19:50, 17 October 2010 (UTC)

"Readers routinely skip sidebars and infoboxes."^{[citation needed]}. --Walter Görlitz (talk) 20:58, 17 October 2010 (UTC)

Technical writing 101. That’s all you’ll get. Sidebars, as our own article describes them, …often include small bits of information such as quotes, polls, lists, pictures, site tools, etc.. By definition, they aren’t intended to be part of linear body text. You may read to them first; others read them last (or not at all). Greg L (talk) 22:01, 17 October 2010 (UTC)

I agree. (But I don't think that the day and month of birth and death constitute "key information" in most cases.) A. di M. (talk) 22:23, 17 October 2010 (UTC)

Huh?? This thread started out as one of birth and death locations. Now, the trouble with infoboxes is they often don’t have the information I seek. I would have expected that the infoboxes for cars like Porche 911 would list “Top speed” but it doesn’t. If the article is a biography, including birth and death dates in the first sentence of the lede are standard practices for all encyclopedias. Why would we depart from this convention? Because that information is in the infobox? Is that what this is about now? If so, I very much disagree.

For instance, our ‘George Washington’ article says this:

George Washington (February 22, 1732 – December 14, 1799) was the dominant military and political leader of the new United States of America from 1775–1797…

Are you suggesting that we abandon this practice? Greg L (talk) 23:31, 17 October 2010 (UTC)

I certainly would. "February 22" and "December 14" are of minor importance;

George Washington (1732–1799) was the dominant military and political leader of the new United States of America from 1775–1797…

is much better. His dates (and places) of birth and death would of course come later in the article. -- Hoary (talk) 23:50, 17 October 2010 (UTC)

That seems very sensible. Citing just the years is entirely consistent with the summary register of a lead, and avoids the ugly clutter of the full number/spacing tragedy. Surely the dates appear later in the detailed sections. Tony (talk) 00:52, 18 October 2010 (UTC)

To clarify, I do agree with above that any details in the infobox or caption must be in the body of the text too. The place I do not think they are required is in the lead section if they are already in both box and body. And to answer the question as to why we are different than many (not all, I bet one could find one that does not) printed encyclopediae that put all sorts of details in parentheses: Yes, it is because we have infoboxes! That seems exactly what infoboxes are for. No need to a bot or massive sweep, just allow the cleaner style in the lead since it is a minor issue IMO. For example, do it when adding infoboxes to a previsouly infoboxless article. W Nowicki (talk) 02:42, 18 October 2010 (UTC)

Oh. I didn’t read what you wrote carefully enough, A. di M. I agree that providing just the birth/death years in biographies {George Washington (1732–1799)} in the lede of the body text seems perfectly fine. (Hmmm… I like it alot.} Greg L (talk) 03:18, 18 October 2010 (UTC)

Yes I don't have a problem with that either. Can we either 1) put this into the manual of style or 2) at least write this up as a short essay and make it a subpage of this page, so that people don't have to reargue this six months from now? Herostratus (talk) 06:34, 18 October 2010 (UTC)

In the particular cases of George Washington and Abraham Lincoln, the exact days of their birth are significant to many people because, before the institution of the portmanteau Presidents Day, February 12 (Lincoln's Birthday) and February 22 (Washington's Birthday) were separately and specifically celebrated national holidays in the U.S. So it wouldn't surprise me if a casual reader would go to Abraham Lincoln just to check the date quickly after running across a literary or historical reference to Lincoln's Birthday. Washington presents the additional difficulty that on the day he was born, the calendar didn't say 22 February 1732, but 11 February 1731. (See a similar difficult at Alexander Kerensky.) —— Shakescene (talk) 12:35, 18 October 2010 (UTC)

Straw poll

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.

There was no consensus to apply recommendation for how to present birth and death dates in the lead. No change to existing guidelines. SilkTork 17:42, 2 December 2010

Could we have a show of hands for a recommendation (rather than compulsion) at MOSNUM that where birth and death dates appear elsewhere in an article, just the years be provided at the opening of the lead? (This would not apply to an infobox.) Compulsion would mean rendering many articles non-compliant, but a recommendation would make it ok for an editor to change without gaining consensus at the talk page first. The exception to this recommendation would be where the actual dates of birth or death are significant per se.

Links to this straw poll have been posted at WT:MOS and and have posted a notice at the Village Pump and Centralized discussion. Tony (talk) 03:37, 20 October 2010 (UTC)

Examples

One of the things you want readers—especially students—to absorb about historical figures is where their lifespan fits into the scheme of things. I have enough trouble remembering the lifetimes of the major figures just in years. Which of the following "big picture" expressions of lifespan is more likely to be held in readers' minds, just where they're embarking on the topic at the outset of the lead summary? I've chosen two composer articles, but the principle goes for all bios.

Aaron Copland, a significant 20th-century composer: here and as it was. In the first, I've moved his full date of birth down to the opening of "Early life", where it fits nicely and complements the full date of his death, which was already in "Later life", just where you'd expect it.
JS Bach—the mess at the top has been an irritant for many years, worsened by the need to refer to the calendar change in Thuringia at the start of the 18th century. The proposed option is here; the previous version is here. The old-style calendar reference is now shifted from the very opening of the article to the start of the "Childhood (1685–1703)" section, without using the distracting small font size that I suppose was an attempt to minimise the clutter at the opening. Again, the date of death was already stated in the "Death (1750)" section. Tony (talk) 02:32, 20 October 2010 (UTC)
¶ Most of the leading clutter in J.S. Bach comes from the phonetic transcription that of course most readers can't understand even if it is neutral between their different accents. I know that's a different argument of equally-long standing, and I realize that how to pronounce "Bach" is a common and natural question for ordinary readers. On the other hand, another question of many ordinary, common readers is "when is Bach's birthday?" and others might well be "where exactly was he born?" (was he, for example, an Austrian?) and "where did he die?" (in England, like Handel? in a big German city? in the countryside?) —— Shakescene (talk) 06:59, 20 October 2010 (UTC)

Your opinions

Support Tony (talk) 08:00, 18 October 2010 (UTC)
Support for the reasons I have given above. Hans Adler 08:19, 18 October 2010 (UTC)
Support Dates of birth and death never have great relevance unless they are an observance (ie perhaps only in George Washington's case). Less clutter by minor information for the lede must be welcome. --Ohconfucius ^¡digame! 08:33, 18 October 2010 (UTC)
Support Messy opening to an article and can be provided in infobox and later in main article. Adabow (talk · contribs) 08:43, 18 October 2010 (UTC)
Support with very rare exceptions (e.g. the death date of Saint Patrick). A. di M. (talk) 09:21, 18 October 2010 (UTC)
Support, with the same caveats that Ohconfucius and A.di M. mention, that sometime, especially when it's a well-known date that has been memorialized, it may indeed be relevant. But that's case-by-case and should be decided on the article's talk page. Must be careful in the wording that no one uses it as a cudgel against any use of full dates, as well.oknazevad (talk) 10:58, 18 October 2010 (UTC)
Support, with Ohconfucius's and A. di M.'s caveats. I don't think that George Washington's birth and death dates are important enough to include in the opening of the lede, but St. Patrick's death date certainly is. Ozob (talk) 11:19, 18 October 2010 (UTC)
Support As the proposal is worded: where birth and death dates appear elsewhere in an article, just the years be provided at the opening. It is a simple recommendation that results in a clean-reading article. Greg L (talk) 13:05, 18 October 2010 (UTC)
Support. Birth and death day-month is very seldom important. If this is put back into the MOS, I would support something like "...except in particular exceptional cases, where there is a reason for including the month and day, and a cogent reason is given on the talk page" or something. (I am the person who started this thread, but I was not objecting to having birth/death year be the only info included, only to the lack of clarity.) Birth and death location is another matter, and more arguable in my opinion - a person's country of birth (not so much the city, usually) can be pretty important. But, overall, I am OK with an MOS that proscribes including the birth/death location either, in the interest of not cluttering up the lead sentence with parenthesized detail. After all, the info can go right into the second sentence or so, with better detail to boot. For instance "John Q. Somebody (born Somedate, Riga, Latvia...)" tells one story, while "Was born in Riga of ethnic German parents" or whatever tells another, and the first example is actually somewhat misleading. Herostratus (talk) 16:22, 18 October 2010 (UTC)
Support. Keep it simple. Lightmouse (talk) 18:05, 18 October 2010 (UTC)
Support. The lead is meant to be the summary and not contain every fact. Including the exact date and location details, adds undo emphasis to these items and moves the actual text on the individual further into the text. Vegaswikian (talk) 18:28, 18 October 2010 (UTC)
Oppose. WP is an encyclopaedia—not an advertising brochure that has to look tidy to sell the product. The day and month currently sit neatly in the lede in thousands of articles which means that readers have learnt that there is a consistent place to obtain that information (and the information is bracketed and easy to skip while scanning). I don't believe WP is improved by having inconsistencies between articles (e.g. if a reader wants to determine if someone was born early or late in a year, they would have to go looking through many paragraphs for what would be essentially a random placement—if there at all). Other respected publications have no problem including the day and month information (Grove does it). I would only support the removal of the day and month information if that information were to be contained in the infobox (as a consistent approach for readers), and not at a random point in the article. The proposal will also make it impossible for script to detect the precise dates of birth and death—something that at least has a chance if placed in the first brackets in the first sentence of an article). I feel that this proposal will lead to increased tension and debate on many, many pages. HWV258. 19:25, 18 October 2010 (UTC)

Funny, "(1912–2002)" rather than "(January 15, 1912 – August 31, 2002)" doesn't look like an advertising brochure to me. It has to look tidy for ease of reading and good organisation (lead vs. the more detailed sections), not because it's trying "to sell a product". Tony (talk) 02:06, 19 October 2010 (UTC)

Support, because it will make the articles more readable, especially for biographies where one also needs to specify one or more alternative forms of the subject's name in a different language or writing system—which is also done parenthetically. However, I agree with HWV258 that we should also stress the suggestion to use an infobox as well, and that the infobox should be as precise as possible and use the appropriate templates to generate metadata. Failing that, we should point users toward instructions on how to encode the full birth/death dates as metadata manually. Yes, I know that many people would ignore such a suggestion, but if the extra link gets even a few people to do the right thing, it's still a worthwhile win. (For that matter, could we create a template that would take the birth/death dates in as precise a form as available, generate the desired parenthetical output, and still generate the needed metadata?) // ⌘macwhiz (talk) 20:09, 18 October 2010 (UTC)
Strongly oppose. Discussion/proposal belongs at MOS:BIO. Relates directly to the first section there, i.e. what information is included not how it is formatted. _wjemather^bigissue 20:30, 18 October 2010 (UTC)
- Thanks. I just put a note there to bring the posse around. --Ohconfucius ^¡digame! 02:45, 19 October 2010 (UTC)
  - Since this seems like it going to stay here all I can say is that sometimes the bad ideas are just right there in front of you. It is long established practice to include birth and death dates as accurately as known in the opening paragraph and there is no reason to change other than a desire to provoke mass edit wars (we've seen those before and don't need them again). In any case it would do our readers great disservice to bury key information in the article body. As has already been stated, the infobox is not a substitute and these details should be as accessible as possible. _wjemather ^bigissue 21:32, 20 October 2010 (UTC)
Oppose I believe that dates are very important information that should be included at the start of an article, and I sure as heck don't want people mechanically deleting them like was done with birth/death places. I also agree with Mclay below: Ideally, the lead could be a stand-alone summary, which includes the dates. Reywas92^Talk 03:39, 19 October 2010 (UTC)
Weak Oppose Should be on a case-by-case basis. Sometimes the exact dates have particular historical significance; many times they do not particularly crowd the lead. --Cybercobra (talk) 04:17, 19 October 2010 (UTC)
The proposal is not do ban them, only to discourage them when there's no good reason to put them in the first sentence. A. di M. (talk) 14:55, 19 October 2010 (UTC)
Strong oppose. Full birth and death dates should always appear in the lead, as they do in any good encyclopaedia. They should not, in my opinion, appear elsewhere in the article, as this is completely unnecessary. Infoboxes should be a supplement (if used at all - I personally dislike the things, as I feel they are ugly and unbalance the article) - they should never, ever contain information that is not contained elsewhere and should never be the primary source of any piece of information in the article. -- Necrothesp (talk) 08:19, 19 October 2010 (UTC)
- You mean that Johannes Kepler#Early years should start with "Johannes Kepler was born in 1571 at the ..." and the penultimate sentence of Johannes Kepler#Rudolphine Tables and his last years should be "He died in 1630 and was buried there; ..."? What's the point of that? Surely someone reading about the details of someone's birth of death is more likely, rather than less, to want to know the day and month, so the dates in the body of the article should be retained whether they're also in the lead or not. A. di M. (talk) 15:04, 19 October 2010 (UTC)
  - No, I mean that it should start "Johannes Kepler was born in the Free Imperial City of Weil der Stadt..." The dates are already in the lead and don't need repeating ad infinitem, which is a trend that has, in my experience, begun fairly recently on Wikipedia. People are generally intelligent enough not to need spoon-feeding. -- Necrothesp (talk) 15:13, 19 October 2010 (UTC)
    - Well, lead sections are supposed to be a summary of the rest of the article, so they should not contain detail not given later. So, giving the year for every event in Johannes Kepler#Rudolphine Tables and his last years except the death on the ground that the death date was already given umpteen screenfuls before would look quite weird to me. A. di M. (talk) 18:03, 19 October 2010 (UTC)
Oppose. My comment above was to suggest it should be allowable not to have the dates of birth and death in the parenthetical section of the first sentence, even they appear both in the body and and infobox; I still think they should occur in the parenthetical section, or should be linked in the body (contrary to current guidelines.) — Arthur Rubin (talk) 08:57, 19 October 2010 (UTC)
Oppose – the first paragraph is meant to be a summary of the article. An reader should be able to read the summary and know all the basic information. Birth and death dates are essential information about a person and do no harm sitting in brackets after the persons name. McLerristarr / Mclay1 15:48, 19 October 2010 (UTC)

We all agree that the lead should be a summary of the article, every single one of us. The question is whether the lead should be a brief and readable SUMMARY that gets users on target or an all-inclusive summary that includes mention of every significant tidbit. Give me clean, fast, short, concise leads over meandering messes that say too much every time. See the lead for Communist Party USA for an example of a technically by-the-book, practically atrocity of a lead... Giving the years alone enables readers to know whether they are looking at the right John Smith at a glance and his general era. If they want to know what day and where he died, that's the place for the main article. The sole rationale that advocates of the current Officially Specified Cluttered Format seem to tout (see below) is "that's what other encyclopedias do." Show me just one paper encyclopedia with a short summary lead, followed by a table of contents, followed by a main article and I might agree with ya... Carrite (talk) 15:30, 21 October 2010 (UTC)

Support. With caveat as stated above, the details should go in the infobox and body, and only then removed from the lead. Years are certainly a summary, so do not understand the previous comment at all. The proposal is not to eliminate the dates totally from the lead, just cut down specific dates to two mentions instead of three. And yes, belongs in the bio style guide. W Nowicki (talk) 15:51, 19 October 2010 (UTC)
Support. One of the main functions of a lead is to summarise the article without unnecessary detail. In most cases the day/month is detail and the year a sufficient summary, so the default recommendation should be to discourage them. Where the day/month are significant, then of course that is an justifiable exception. Although it's out of scope here, I'd venture in an analogous way that the exact location is usually detail, while the nationality is summary, so the same would apply. For what it's worth, I certainly do not think it is appropriate to have information in the lead that is not contained in the body of the article. --RexxS (talk) 17:17, 19 October 2010 (UTC)
- If location is detail that should not be included in the body paragraph, are you suggesting that, for example, the lead paragraph of John Lennon should not mention his birth in Liverpool? McLerristarr / Mclay1 17:22, 19 October 2010 (UTC)
Comment – Just to clarify something here: does first paragraph mean just the first line or the entire first section before the contents? McLerristarr / Mclay1 17:24, 19 October 2010 (UTC)
- The first paragraph is all the text before the first blank line, though IMO the problem is cramming too much stuff in the parentheses. A. di M. (talk) 18:03, 19 October 2010 (UTC)
Support: the first sentence should give the most important information about a person, and that is what that person did and in what period he lived, not on what days the person happened to be born and die. Of course, there may be individual cases where it is appropriate to give the dates. Ucucha 01:36, 20 October 2010 (UTC)
Oppose Dates of birth and death are at the top of the ubiquitous information about a person; they are bookmarks of the human condition; they are vitals like name, gender and profession, and so they loom large when we tell the story of a life. We ask that ideally leads be able to function as stand-alone documents that summarize the important aspects of a person's life, and we do so not just as an empty exercise in summarization, or style, but because people often read just the lead as a mini-article and stop there. I cannot imagine a good biography that does not provide these vitals, so if we truly mean that the lead should pass scrutiny as stand-alone, then this information must be included there.--Fuhghettaboutit (talk) 03:58, 20 October 2010 (UTC)
- Few of the biographies shorter than several tens of pages that I recall reading – let alone four-paragraph ones – give days and months for the birth and death dates. A. di M. (talk) 16:16, 20 October 2010 (UTC)
  - We must do our reading in alternate universes.--Fuhghettaboutit (talk) 17:41, 20 October 2010 (UTC)
Comment – I often find birth and death dates are not referenced to citations; where they are cited adjacent to the first sentence to the lead, they often lead to clutter within the already busy parentheses in the lead section. Unless it's from an obit, it's extremely likely ever to have a single cite for both birth and death dates. So I think it's better to have all that detail in the body –. --Ohconfucius ^¡digame! 04:00, 20 October 2010 (UTC)
Comment. There's nothing wrong with presenting significant detail like place of birth in the lead, but if a great deal of readers (not editors) say it reduces usability, let them have their way. There are two caveats that I'd like to see in the final decision - taking care of another round of "lamest MOS wars":

Editors who remove dates and places from the lead should check if they are clearly mentioned elsewhere in the text (not infobox) and, when necessary, carefully re-insert such info where appropriate.
Deletion of dates and places from the lead is not an excuse for the addition of an infobox. Infobox wars... been there. East of Borschov 06:37, 20 October 2010 (UTC)

Oppose: Keep dates of birth and death in the lead parenthesis, to the month and day. Locations, however, should appear later in the article. /ninly_(talk) 07:23, 20 October 2010 (UTC)
- Yes, agree with that 100%. Places of birth and death should be in the article, not the lead. -- Necrothesp (talk) 08:31, 20 October 2010 (UTC)
Oppose. This is basic information. If you want to remove superfluous info from the lead, it would be better to remove the full name of people from the lead and only introduce that in the body. I don't want the first thing in the article on Stephen Hawking to be that his middle name is William, nor do I believe that the fact that he is a fellow of the Royal Society for the encouragement of Arts, Manufactures & Commerce needs to be introduced so soon. Considering that we normally have such minor infotmation prominently in the lead, I don't think excluding the exact date of birth and date should be our priorities. Fram (talk) 08:47, 20 October 2010 (UTC)
- I really don't think a person's full name is superfluous. Neither, in Britain, are their postnominal letters. -- Necrothesp (talk) 08:49, 20 October 2010 (UTC)
  - That's basically the problem. You believe that where someone is born shouldn't be in the lead, but that someone has the middle name X on his birth certificate should be, even though in many cases the first had a profound influence on his life and career, and the latter may be a totally irrelevant bit of trivia. Everyone has his preferences, opinions, things that pique the interest or that are totally irrelevant to you. I don't see why the exact date of birth and death should be singled out. I could see the need for a total rethinking of what to put in the lead, or what to put in the first sentence of a lead, focusing solely on what was essential to the person (which would certainly be the commonly known name and the claim to notability (usually their job), and may include their years of birth and death, their nationality or other regional affiliation, and a few other things. It would usually not include little-known middle names, postnomials unrelated to their main notability, dates of birth and death, ancestry (X was a Y of Polish-Italian-German descent? X was a Y will suffice for the lead)). Such a discussion and rewrite of the MOs for the lead, I could perhaps support. But as it stands, I don't see the reason for removing this from the lead when so much other clutter is allowed (and even encouraged) in it. Fram (talk) 08:58, 20 October 2010 (UTC)
- Do I understand you correctly? Do you oppose removing birth and death day and month where irrelevant (while keeping the years in), because you think irrelevant details about the name should also be removed? That seems rather odd to me. Hans Adler 13:05, 20 October 2010 (UTC)
  - If we agree that some less relevant info can or should be included in the lead (first sentence) anyway, then I believe that the exact dates of birth and death are a prime candidate for such inclusion, as they are a natural extension of the years (which everyone, I believe, agrees should be included). I can accept the position that no less relevant info should be included in the first sentence, and a discussion on that may be worthwhile. But I can also see the arguments to include some more trivial or less relevant info in the first sentence, and in that case, I think that these dates should be kept. What I can't support is the exclusion of the dates coupled with the inclusion of other material. I hope that clarifies my position on this. Fram (talk) 08:36, 21 October 2010 (UTC)
    - Thanks. That makes perfect sense. I saw this proposal, which initially looked like a case of snow, primarily as a way to get started about removing the lead clutter. I'm a bit worried that your nuanced argument won't be taken into consideration when people later argue that because of the strong opposition to removing the dates WP:LEAD can clearly not be enforced for such content. Hans Adler 09:03, 21 October 2010 (UTC)
Supportissimo. For the great majority of notable people, the details of the birth or death aren't important to their notability. This is just clutter. The demand for consistency makes it worse, in view of all the people whose dates arguably need to be spelled out in both the Julian and the Gregorian calendar (and indeed in years with old versus present-day year-division). There's talk above of how any good encyclopedia consistently does this or that; I don't have any large biographical encyclopedia conveniently to hand, but to me it would be one whose articles provided such details as dates of birth and death but whose leads were crafted by and for thinking humans, rather than by robotic application of a handful of rules that prioritized consistency across articles on people as diverse as physicists, murderers, novelists, film directors, explorers, and pop crooners. -- Hoary (talk) 09:47, 20 October 2010 (UTC)
Oppose per Fram. People are used to this and expect it as both readers and editors; and in isolation it is not an improvement. I would support, as Fram suggested above, a wider rethink on what information should be excluded from leads unless it is shown to be significant - and as part of that, it might be OK to say that in many cases the exact dates are a distraction rather than helpful. Rd232 ^talk 11:07, 20 October 2010 (UTC)
- But I'm a person, a reader, and an editor; and I am not used to it and indeed am irritated by it. Incidentally, I too would be happy to boot obscure matters of naming out of the lead. -- Hoary (talk) 11:39, 20 October 2010 (UTC)
Oppose I don't see a major change in flow, but I do see a lack of instant information. If I want to see a birthday, I look at the top and don't want to scroll down looking. Is this change OK sometimes? Yes, so do it on a case-by-case basis. But not always, please. How is this not important info, anyway? Can we exclude titles (OBE, etc.) too, as superfluous? What constitutes unimportant detail? I think presenting, in most cases, the specific dates at the beginning is helpful and relevant. /ƒETCH COMMS / 12:57, 20 October 2010 (UTC)
- How is this not important info, anyway? Because it's remarkably difficult to come up with examples for which the date of birth is significant. ("Oh, Mozart/Gesualdo/Ockeghem/Beethoven/Schoenberg/Bach/Zemlinsky was born in April/June/November?" Good grief, then no wonder he is/isn't performed much these days!") -- Hoary (talk) 13:25, 20 October 2010 (UTC)
  - Exactly. For illustration, let's take a few anonymous famous composers and experiment with various formats:
  A (born in Salzburg; died in Vienna) was an Austrian composer.
  
  B (born 17 December; died 26 March) was a German composer.
  
  C (born 31 March (O.S. 21 March) 1685 in Eisenach; died 28 July 1750 in Leipzig) was a composer.
  
  D (1685–1759) was a German-British composer.
  
  I know which format I prefer, and why. Hans Adler 14:45, 20 October 2010 (UTC)
  This is slightly disingenuous to say the least, since the normal format on Wikipedia at the moment is not any of these, but: E (31 March 1685 – 28 July 1750) was a German composer. This is the format I and others continue to support. -- Necrothesp (talk) 15:59, 20 October 2010 (UTC)
  Me too. I, for one, consider that "E" conveys the most relevant information and is much faster for me to get that info from. I am truly interested in his birth date, not just the year. Being born in January vs. December is a pretty big difference time-wise. In addition, what do other encyclopedias do? Hey, look at Brittanica: we're not them, but I think the standard for encyclopedias is like what EB does, "(b. Jan. 27, 1756, Salzburg, Archbishopric of Salzburg [Austria]—d. Dec. 5, 1791, Vienna)". /ƒETCH COMMS / 19:42, 20 October 2010 (UTC)
  Apart from answering trivia questions in a pub quiz, I can't see any use for the exact date, nor the relevance of day and month to the subject's life and work. I could understand that John Lennon being born in Liverpool in 1940 would be relevant, but why "9 October"? --RexxS (talk) 22:33, 20 October 2010 (UTC)
  
  I think it's an important biographical fact. We should, by your reasoning, exclude orders of chivalry (because no one says that in daily speech), cities of birth (because everyone knows that the country is what matters), pronunciations (because very few people can understand IPA), middle names, and full birth names for people like Lady Gaga. Does having the date of birth in the lede hurt the lede that bad? Why make information that is relevant to the subject's life (because that's when it started!) be harder to find? This is an encyclopedia; it is for reference. If I want to look up Barack Obama's birthday for an essay or article I am writing, I will look to Wikipedia, as will most other readers, including a large number of professional journalists and such. That page takes a long time to load for me. I don't want to wait an extra 30 seconds to see the rest of the article when I can just wait 10 to see the first part of the lede, and know the birth date. In almost every case, I see no harm in leaving the full date of birth in the first sentence. It's not really unnecessary detail; we're giving basic facts but not going into minutes or seconds and whatnot. /ƒETCH COMMS / 01:55, 21 October 2010 (UTC)
Oppose. For one it is more convenient to our readers to have it readily available. Secondly, it is important in contributing to the summing up of the article which is the lede's purpose and nearly all of the 800, 000 plus biographical articles have the birth and dates dates (not just years) in the lede. To change this policy like this would require what I perceive to be 800, 000 unnecessary changes. --Kumioko (talk) 15:08, 20 October 2010 (UTC)

Yes, but it would be more convenient for readers to have everything at the opening; that is just not practical. What goes there has to be rationed, and at the moment we are forced to put birthdays in at the very opening—no flexibility at all. "To change this policy like this would require what I perceive to be 800, 000 unnecessary changes." Well, no: at the top it clearly says that the new advice would be a recommendation, not a compulsion, specifically not to render 800,000 articles in breach. Tony (talk) 16:41, 20 October 2010 (UTC)

What? It's convenient to have basic info that one expects to see (AKA the birth date) and a summary of the subject. I expect to see the full birth date, so it is convenient if it is there. If it's not, I am inconvenienced. Or is it actually easier for me to have to wait for the page to load more and then search lower? Also, if this is a recommendation, how is it determined when this should occur? The main contributor's discretion? Will we need different consensus on every single page? I like them all the current way, and so do many others; should there be a massive edit war over a ... recommendation? /ƒETCH COMMS / 01:55, 21 October 2010 (UTC)

Support - The lead is supposed to be a simple, concise summary of the expanded content in the article below. Yet the Official Style Guide specifies for expanded dates in the lead (which are often times not repeated in the article below, human nature being what it is...). This is nutty. Fortunately, the number of people who follow Official Style instead of unofficial Logical Style is a small minority. Carrite (talk) 15:31, 20 October 2010 (UTC)

←(e.c.) Response to Hans Adler: Agreed, most readers, if asked, would instantly go for the clean, simple one. What is it about birthdays that makes people want to put them right at the start? May as well give the day of the week they were born, or whether they were right- or left-handed, first-/last-born, brown/blue-eyed, right at the opening, then. Aside from my poor attempt at humour, birthdays are a more significant problem than those trivialities when it comes to the impact on the reader of historical lifespan—almost always a critical concern. Because days and months are expressed in numerals adjacent to the years, they really do damage the easy accessibility of information that enables a reader to conceptualise their place in history—that is, the years. Ask any schoolteacher, any professor, any journalist, what really matters. Birth and death dates are details that are much more suitable in the body of the text, where whole sections are typically devoted to "Early life" and "Later life". And the infobox, where there is one, will still announce the full dates, usually. Days and months should be trumpeted in the first second of reading an article only where they have modern anniversary implications (St. Patrick's Day, for example). The clutter has been a serious shortcoming of WP's bio articles, and it is high time we gave editors the option of allocating macro- and micro-details to the summary and the sections, respectively. Tony (talk) 15:09, 20 October 2010 (UTC)

You are not entitled to speak for "most readers," only for yourself. Edison (talk) 15:56, 20 October 2010 (UTC)

Agreed, and please, can we stop this tiresome banging on about things being in infoboxes and therefore not needing to be in the lead. Infoboxes are not uncontroversial and many of us don't like their recent proliferation in the first place. In addition, who on earth has the right to decide what is an acceptable "modern anniversary" and what is not? St Patrick's Day means nothing to me. Indeed, it probably means nothing to most people outside Ireland and North America. -- Necrothesp (talk) 16:01, 20 October 2010 (UTC)

I agree that the insistence on infoboxes here is annoying. For articles without infobox it should be enough if the dates appear in the text in the obvious locations. Hans Adler 16:07, 20 October 2010 (UTC)

I guess the reason some editors insist on this is related to the reason why so many articles begin with the silly "X refers to" pattern and have an etymology section that only deals with the title, even though articles are supposed to be about (often several related) concepts rather than words. People use dictionaries more often than encyclopedias, and even many encyclopedias are organised by words rather than topics. So this is what editors are used to. Hans Adler 16:07, 20 October 2010 (UTC)

Strong oppose I expect to see the date of birth and death, and not just the year, at the beginning of a biography, consistent with paper encyclopedias and biographical dictionaries. If you don't care what Copland's birthday was, then skip over it. Many articles do not have an infobox near the beginning. If there is such as easily accessible infobox, then just years would suffice. (Addendum:) Britannica gives the date and place of birth and death in parentheses at the beginning of a biography, and I take that as a good model for Wikipedia. Worldbook, more of a "schoolkid encyclopedia," just puts the years of birth and death at the beginning. The place and date of birth are buried down around the third paragraph. The year of death may be down many paragraphs later, and they typically do not explicitly give the place of death. Edison (talk) 15:56, 20 October 2010 (UTC)
Strong oppose An encyclopedia should have the full information regarding birth and death. Day and year are naturals but even month brings meaningful info. To mention an upcoming one. Harry Houdini's death on October 31, 1926 summons up its own connotations. Use of the year "1926" by itself does not. MarnetteD | Talk 17:07, 20 October 2010 (UTC)
Oppose: This is a real-world standard for biographies, there's no strong reason to step away from it MBelgrano (talk) 18:42, 20 October 2010 (UTC)
Support. I don't see any real advantage to putting the full date in the lead sentence. Keeping it simple makes the intro more readable, IMO. Kaldari (talk) 20:23, 20 October 2010 (UTC)
Oppose per Necrothesp and Wjemather, full dates but no places in the parentheses, i.e. restore the line "Locations of birth and death are given subsequently rather than being entangled with the dates." Tewapack (talk) 22:36, 20 October 2010 (UTC)
Oppose in that this argument over very few cases like Bach would result in losing birthdates and deathdates in very many cases to wherever in the article the latest haphazard editor put them (including the infobox). Even the O.S. cases like Bach and Washington are already easily standardized. There is a much worse problem with the hyperinclusive multiscript spellings of various articles that often present a reader with browser-breakers before he can even parse the first sentence, and thus a date-related proposal is a bit time-wasting. IMHO I saw a very reasonable suggestion that if there are several alternate spellings, that can be explained in the first section. In that case it makes sense, especially if alternate spellings are bolded as per guidance, but if birth and death are moved (deathdate has NO other easy-to-find location in any article except the sometime infobox) there is no quick way to determine even if WP knows about the deathdate. JJB 00:02, 21 October 2010 (UTC)
Support if the birth date is easy to find elsewhere, e.g. in the infobox or at the start of an "Early life" section. SlimVirgin ^{talk|contribs} 00:12, 21 October 2010 (UTC)
Strong Oppose. Wikipedia needs guidelines to ensure consistency. This "straw poll" introduces subjective criteria for a "whatever goes" mentality. The introduction presents the clause: "The exception to this recommendation would be where the actual dates of birth or death are significant per se." This is highly subjective, potentially leading to much discord between editors. What is useful, important, or significant to one editor may not equate to the next. We need to maintain consistency, rather than set a precedent for revising policy, guidelines, and Manual of Style at the whim of any straw poll. Cindamuse (talk) 06:47, 21 October 2010 (UTC)
Can't we all just get along? "Wikipedia needs guidelines to ensure consistency" is one opinion; "A foolish consistency is the hobgoblin of little minds" is another. We don't seem to have a consensus, and so I don't think we can mandate exactly what the material in the parenthesis following the person's name is. Let a hundred flowers bloom. As it stands, as far as I can tell, there is no prescription; that is the de facto policy. However, I think it's very important to make this clear. Lack of consistency is not a problem; lack of clarity is a problem and leads to long discussions such as this one (and this one, and this one and this one, and more in future if we don't pin this down now).

So how about replacing this:

At the start of an article on an individual, his or her dates of birth and death are provided. For example: "Charles Darwin (12 February 1809 – 19 April 1882) was a British ..." En dashes are preceded by a non-breaking space, except between year-pairs when no spaces are used.

With this (or something like it):

Biographical articles should begin with the name of the person (bolded), an opening parenthesis, and a closing parenthesis. The parentheses must enclose the birth and death year, and may (at the author's discretion) enclose the birth and/or death day and month and birth and/or death location. For example: "Charles Darwin (1809 – 1882) was a British ..." or "Charles Darwin (12 February 1809 – 19 April 1882) was a British ... or Charles Darwin (12 February 1809, Shrewsbury, Shropshire, England – 19 April 1882, Downe, Kent, England) was a British ...". En dashes are preceded by a non-breaking space, except between year-pairs when no spaces are used. For living persons and persons where all the information is not known, see the examples below.

And this would also have to be put in WP:MOSBIO. Herostratus (talk) 14:44, 21 October 2010 (UTC)

Comment. A lack of clarity leads to lack of consistency. There is most certainly a problem with a lack of consistency. If it were not so, there would be no need for this discussion. And yes, I agree, this discussion is taking place devoid of WP:MOSBIO, as well as WP:PEER. As such, it really holds little water outside of satisfying curious minds pertaining to style preferences. And please, I have seen nothing signifying "not getting along", outside of your "foolish, little minds" comment. Let's not go there. Maintain respect, while assuming good faith. Thanks. Cindamuse (talk) 15:51, 21 October 2010 (UTC)

Well, I was just quoting Emerson. Take it up with him. Herostratus (talk) 03:27, 22 October 2010 (UTC)

WP:CRAP. One does not justify the other. Cindamuse (talk) 05:50, 22 October 2010 (UTC)

Comment – If the birth and death dates were removed from the lead, then you would have to go to the introduction for the birth date and search through the rest for the death date. That seems very inconvenient seeing as how birth and death dates are such basic information. I bet a lot of readers look at a biographical article just to find out the person's birth and death dates. We've got to remember that most people who read Wikipedia articles are just looking for some quick information. They do not want to trail through a large amount of text; if they have to do that, they'll look elsewhere on other websites. McLerristarr / Mclay1 15:23, 21 October 2010 (UTC)
- People just looking for some quick information can find it in the infobox. That's what they are for. A. di M. (talk) 15:35, 21 October 2010 (UTC)
- The lede paragraph of Millard Fillmore, for instance, is so full of trivia that it doesn't mention slavery or the Compromise of 1850. Those subjects explain Fillmore's importance much better than the exact date, not just the year, of his birth and death. Everything can't come first. Art LaPella (talk) 16:01, 21 October 2010 (UTC)
  - Agree with A. di M. and Art LaPella. Mclay1, when you say, "I bet a lot of readers look at a biographical article just to find out the person's birth and death dates", do you have any evidence for your punt? It's been pointed out a number of times above that the dates are inconsequential in defining the "big picture" summary that defines the role of the lead, and unhelpful to readers and students in extracting the critical lifespan in historical terms. Tony (talk) 16:06, 21 October 2010 (UTC)
    - Dates of birth and death are an integral part of any biography. I find it quite ludicrous that anyone would suggest otherwise. _wjemather ^bigissue 19:28, 21 October 2010 (UTC)
Support (assuming it applies to living people too). The proposed recommendation would be a positive development. Mentioning just the year does suit the lead's "big picture" role. The actual dates can be found immediately in the infobox if required. PL290 (talk) 18:23, 21 October 2010 (UTC)
Support where birth/death dates appear in infobox, at least. Enhances readability, doesn't bog the reader down (especially where there's pronunciation and other junk making the first sentence unwieldy). If the birth/death dates are in the infobox, it's not as though readers will be disserviced by not having them in the first few words of the article. Calliopejen1 (talk) 19:13, 21 October 2010 (UTC)
Comment. To make it clear for those who seem to have glossed over it, an infobox is a supplementary feature that summarises an article. All information contained in an infobox should also be found in the main text of the article. More importantly, some readers are unable to access infoboxes, so as far as this discussion goes please assume that they do not exist. _wjemather^bigissue 19:23, 21 October 2010 (UTC)
- Nothing glossed over: exactly the same is true of the lead. All information contained in the lead should also be found in the main text. PL290 (talk) 19:35, 21 October 2010 (UTC)
  - If it is not being glossed over, why do infoboxes keep being mentioned time and time again? They are absolutely irrelevant to this discussion, and apparently that needs to be made clear. And yes, everything in the lead should be expanded upon later. _wjemather^bigissue 23:03, 21 October 2010 (UTC)
    - If there's an accessibility issue with infoboxes (btw I wasn't aware there was till you mentioned it; could you provide a link to the policy/guideline?), then I agree that makes infoboxes a slight red herring, but still not a glossing-over, for the reason just given: what's in the lead and the infobox should always be present in the main article text. PL290 (talk) 11:27, 22 October 2010 (UTC)
      - Help:Infobox. _wjemather ^bigissue 16:14, 22 October 2010 (UTC)
Support for those articles where date information is available in an infobox and/or later section. In some very short biographies, without infoboxes, the initial paragraph is actually the most appropriate place. (The theory that "everything in the lede should be expanded upon later is fine for featured articles, but realistically many articles are not going to respect this.) TheGrappler (talk) 00:46, 22 October 2010 (UTC)
- To address this point I suggest the recommendation, if implemented, should include advice along the lines, "Ensure the details are present in the main text before removing them from the lead." PL290 (talk) 11:27, 22 October 2010 (UTC)
Support for those articles where date information is available in an infobox and later section. For all the reasons given above, but not to mess with those in WP:BIO. Walter Görlitz (talk) 01:25, 22 October 2010 (UTC)

Oppose because

a person's dates of birth and death are literally vital and thus belong into the lead;
making readers hunt through the narration for these dates is a disservice;
the parenthetical presentation of these dates makes it at once easy to skip and easy to parse, depending on the readers' interest;
many biographies don't have infoboxes, they are not universally accepted; in such articles, there is a chance for programmatic parsing for these dates if they are are presented as they are now;
very short biographies would aquire an awkward phrasing if the dates were to be repeated in full in the articles' short body;
I don't know of any Wikipedia in another language which uses this style; its introduction would make editing for multilingual editors more difficult.

Michael Bednarek (talk) 03:47, 22 October 2010 (UTC)

If it's in the article and infobox it can be found.
The infobox is not narration.
But not search engines.
A good reason to add them and make them standard instead of a long date.
not if an infobox is added.
probably for this very reason. Once we start, they too will see how rational it is.

Walter Görlitz (talk) 05:18, 22 October 2010 (UTC)

Lots of facts might be constructed as "vital"—they can't all be shoved in right at the opening, which is by definite a rationing of information (please see WP:LEAD). We don't normally insert locations of birth and death within the parentheses, because editors have drawn the clutter-line against that. Many editors have felt for some time that birthdays are not sufficiently significant to warrant compulsory inclusion in the first second or two of the reading.
Hunting for them: per Görlitz above; where there is no infobox (bless the fact), you don't have to hunt far, since the opening section is almost always the bio, starting with birth.
"Easy to skip"? Well, no, the whole point is that the clutter of numerals makes the important bits, the years that define the lifespan, harder to extract; but they are of the essence in a summary. Readers read quickly ... we editors work on the text slowly.
Where there is no infobox, it's up to the editors on the talk page, isn't it? As far as "programmatic" parsing, something in my non-programmer's brain tells me the location of the full dates makes utterly no difference, and please, putting the needs of programmers above the readers' needs is just not on.
"Awkward phrasing in short bios"—no one is arguing for compulsory separation of the dates from the years at the top (although what we have at the moment is compulsory inclusion, which many of us object to). The full dates should be expressed according to local conditions. Editors need to have the flexibility to do this, not compulsion to do it one way.
"editing for multilingual editors more difficult"—err ... why? Tony (talk) 06:24, 22 October 2010 (UTC)

It's difficult enough to keep track of which quote signs to use (typographical, chevrons, straight), in which order interwiki links appear, which titles are italicised, etc; the use of full dates in the first sentence seems to be so far universal among all language versions of Wikipedia. Departing from this practice here would make it more difficult, not only for editors working in different language versions of Wikipedia, but also for readers following the interwiki links. I can see a flood of edits by well-meaning editors wanting to correct a perceived lack of detail. -- Michael Bednarek (talk) 07:59, 22 October 2010 (UTC)

Oppose for all the reasons listed by Michael Bednarek above. The argument that deleting the equivalent of four words in parenthethetical information makes the article "easier to read" is spurious. Likewise that it makes the article "look more attractive", unless the goal here is to write a magazine rather than an encyclopedia. Full birth and death dates (and places, for that matter) immediately following the subject's name are standard in all major encyclopedias and biographical dictionaries. There is clearly no consensus here for such a major and detrimental change here and I sincerely hope that it will not be made on the basis of straw poll in a discussion in an obscure corner of Wikipedia. Why was this discussion not notified to the many projects which deal with large numbers of biographical articles? I am informing the three projects I work with of this discussion (Opera, Classical Music, and Composers). Voceditenore (talk) 05:39, 22 October 2010 (UTC)

Nonsense. You don't understand the argument if you are under the belief it's to make the article easier to read. The reason is to make the summary easier to read in a Google search. --Walter Görlitz (talk) 06:00, 22 October 2010 (UTC)

It's not nonsense at all. Several of the Support !votes have suggested that it makes the article itself easier to read and/or somehow "cleaner". If the main thrust of the argument is that it makes the Google seach summary easier to read, it's an even more spurious argument. First of all, talk about letting the tail wag the dog. But more importantly, if people are only going to read the Google summary, it's often because they specifically want to know the exact dates of birth and death. Here's what "Rossini" comes up as in the Google search:

Gioachino Rossini - Wikipedia, the free encyclopedia

Gioachino Antonio Rossini (February 29, 1792 – November 13, 1868) was an Italian composer who wrote 39 operas as well as sacred music, chamber music, songs, ...

How is that summary "difficult to read"? How would the reader be "helped" by not being able to access the exact dates via a Google search summary? Voceditenore (talk) 06:40, 22 October 2010 (UTC)

Oppose per Michael Bednarek and Voceditenore.4meter4 (talk) 06:07, 22 October 2010 (UTC)

Voceditnore, "The argument that deleting the equivalent of four words in parenthetetical information makes the article "easier to read" is spurious." Have you looked at the examples I provided at the top? If you don't think the cluster of numerals makes it harder to absorb the years alone, perhaps I'm wrong and I need new glasses. Tony (talk) 06:24, 22 October 2010 (UTC)

Nope, I don't think the old version of the Copland lede it made it harder to "absorb" the years of his lifespan at all. The mess in Bach is an extreme example, and as has been pointed out above, most of that mess comes from the lengthy IPA transcription which is useless to most readers and the unnecessary addition of the alternate Old Style date. The current "improved" version [1] has thrown out the baby and left a considerable amount of bathwater. Voceditenore (talk) 06:56, 22 October 2010 (UTC)

Oppose - Standard biographical dictionaries have the full birth and death dates in the first sentence. Many Wikipedia articles cover the birth in an "Early years" section at the beginning of the article and the "Death" at the end of the article. Readers would have to search for both dates. Info boxes should not be required for biographies. -- SWTPC6800 (talk) 06:26, 22 October 2010 (UTC)
I've just checked the Oxford Dictionary of National Biography and they just give the years, as did the s:Dictionary of National Biography -- PBS (talk) 20:30, 22 October 2010 (UTC)
Oppose per HWV258 and Fram. --Arxiloxos (talk) 07:01, 22 October 2010 (UTC)
Absolutely oppose. This is standard, essential, encyclopaedic information, whether or not individual editors are bored by it or it turns them off. --Smerus (talk) 07:19, 22 October 2010 (UTC)
Oppose for all the reasons listed by Michael Bednarek above. In addition I would like to see there the places of death and birth, to have all Persondata together, rather than collect them from various sections of an article. --Gerda Arendt (talk) 08:07, 22 October 2010 (UTC)
Strong oppose - Listing only the years implies that we don't know the specific dates, which makes Wikipedia look less reputable. It can be hard to find the information in long articles and many, like the two examples given, don't have infoboxes. Adoption of this proposal will surely lead to mandatory infoboxes, which are opposed by many. There are better ways to cleanup the lead than this proposal. —UncleDouggie (talk) 08:27, 22 October 2010 (UTC)
Oppose. This is not a terrible idea, but if there is no infobox (and I, like many editors, am not fond of them) then this would make birth and death dates too hard to find, and would unnecessarily surprise our readers. Mike Christie (talk) 12:15, 22 October 2010 (UTC)
Oppose. For all the aove reasons, principally the fact that so many articles contain the day-month-year of birth and death. Viva-Verdi (talk) 17:44, 22 October 2010 (UTC)
Oppose per reasons above. In this case, less is less. We should be copying the example of encyclopaedias and biographical dictionaries. --Folantin (talk) 18:07, 22 October 2010 (UTC)
Comment Well this has divided the community! I can see this is going to be another saga like date linking. I've always put this one down to a matter of judgement. Indeed I have recently been a squabble over this issue in the article Walter Hungerford, 1st Baron Hungerford of Heytesbury although it was to do with sourcing rather than placement. As I had failed to notice the day of thee month of death in the text, it could be used as justification for including it in the first line. I think that this has a lot to do with ones perception of what an biography entry is for. As Churchill said of Chamberlain "He views foreign policy from the wrong end of a municipal drain" (The Chamberlain family made their political reputation in local politics in Birmingham). If a persons interest in a biography entry is primarily for genealogy, then the "Family" section is the major interest and having the full date in the first line and the article is most useful. If on the other hand one is more interested in notability of the person for what they did, then usually, unless the date of death is notable fact for historical reasons (eg see the Harry Patch article), the specific date is just clutter. To give another examples: The full date of death is useful in the Hitler biography because it was time critical in history (he is one of the few people were we have a specific article down to the minute that he died), his date of birth less so, but given one why not the other for aesthetic reasons? Likewise the deaths of Franklin D. Roosevelt and JFK are historically significant, but the specific DOB and DOD are not historically significant for Winston Churchill. There are a number of British reliable sources, such as Collins's Peerage of England; Genealogical, Biographical, and Historical (1812), that emphasise breeding and who married whom (very important for the society and clientele for whom Collins's was writing), rather than historical significance, so using such sources articles like this old version of the article Sir John St John, 1st Baronet can be constructed, which emphasise family, in comparison to this version that has the biography information placed first. I think the first thing that needs to be discussed is given the entry in WP:NOTDIRECTORY, how much weight should be given in Wikiepdia to readers who's interest is primarily genealogy? -- PBS (talk) 20:30, 22 October 2010 (UTC)
Suggestion What about adding an infobox to every person article? This would help have the date/place birth/death info altogether, wouldn't it? -- Magioladitis (talk) 03:23, 24 October 2010 (UTC)

Not really. Even if you (it could not be done automatically) included the birth and death dates, they also need to be in the body of the article. — Arthur Rubin (talk) 04:17, 24 October 2010 (UTC)

Absolutely not. As has already been pointed out several times by several people, infoboxes are controversial and should not be added as a matter of course for the sake of it. I fail to see why editors would support the inclusion of ugly, article-unbalancing infoboxes, while opposing the appearance of two words and two numbers in the lead. Incredible! However, as this proposal clearly has nothing even vaguely approaching unanimous support, I suggest we knock it on the head now and agree to retain the advice to include full dates in the lead. -- Necrothesp (talk) 08:37, 25 October 2010 (UTC)

Comment I actually have no strong opinions either way, but would prefer conformity. Either we use dates in all leads, or in none of them. Dates are important to many readers, hence I'd sit on the fence with their essentialness in the lead. Casliber (talk · contribs) 11:21, 24 October 2010 (UTC)
Support. A very sensible idea, logical proposal. Agree with Casliber (talk · contribs), that it is good to have uniformity. However, there should be exceptions, where the date itself of birth or death, is noteworthy. -- Cirt (talk) 15:41, 24 October 2010 (UTC)
Support Seems to be a sensible idea to me; keep the lede as a summary, and leave the fine detail (and a citation, of course ;-) in the body of the article. Of course there may be outliers where an alternative approach is better perhaps due to some quirk of the subject or their lifespan; but editors may use common sense on that. As a general recommendation rather than an iron rule, I'm happy with it. bobrayner (talk) 13:20, 25 October 2010 (UTC)
Oppose The dates of an individual's birth & death -- where known -- are traditionally placed at the beginning of an encyclopedia article. This is where our users expect to find them, & these facts are amongst the most commonly sought facts in biographical articles. Putting them in the body of the article forces the reader to spend an unnecessary amount of time hunting for them, thus achieving a debatable improvement in aesthetics while making articles harder to use. -- llywrch (talk) 16:36, 25 October 2010 (UTC)
Comment A traditional encyclopedia doesn't have a sidebar summarizing the biographical informtion. That is the equivalent of our infobox. Since you suggest that we be more like a "traditional encyclopedia" I suppose you want to get rid of the infobox as well? It is, afterall, redundant and not at all like a "traditional encyclopedia". --Walter Görlitz (talk) 19:48, 25 October 2010 (UTC)
What an excellent idea. Now, getting rid of all infoboxes is something I would support! -- Necrothesp (talk) 12:04, 26 October 2010 (UTC)

The contents of infoboxes are not standardized, AFAIK. And as at least one other commenter has pointed out, there is no guarrantee or requirement that infoboxes be part of an article. -- llywrch (talk) 17:04, 27 October 2010 (UTC)

Also, traditional encyclopedias often also have the places of birth and death in that same place. A. di M. (talk) 22:06, 25 October 2010 (UTC)
Oppose for the same reasons as Llywrch. Angus McLellan (Talk) 17:38, 25 October 2010 (UTC)
Comment My quick count as of now is Support = 25, Oppose = 30. -- SWTPC6800 (talk) 17:52, 25 October 2010 (UTC)

Reply. I counted it three times at Support=25, Oppose = 32.4meter4 (talk) 20:58, 25 October 2010 (UTC)

Comment Several people in this survey have said that other reference books traditional include day of birth and day of death. But have not produced any evidence that this is true. As I pointed out above the ODNB does not do it, nor does the earlier DNB. I have just looked at EB1911 on Wikisource and the first obvious biography I could find was s:1911 Encyclopædia Britannica/Adams, Herbert Baxter it does not include day or month of birth or death nor does the next article s:1911 Encyclopædia Britannica/Adams, John, but Herbert Baxter Adams in the modern Britannica indicates that they use "(b. April 16, 1850, Shutesbury, Mass., U.S.—d. July 30, 1901, Amherst, Mass.)". I also checked the Catholic Encyclopedia and the first biograhpy they have is s:Catholic Encyclopedia (1913)/Pedro Abarca which does include day of death, as does the next entry where this information is likely to be know s:Catholic Encyclopedia (1913)/Jean Baptiste Abbeloos, but the format of their articles is somewhat different from ours. This quick survey neither confirms or reject the argument whether most do or do not, and I am not sure how anyone can argue unequivocally that including "day of birth" and "day of death" is standard unless they have information from a wider survey to support the statement. If so pleas share it with us. -- PBS (talk) 09:55, 26 October 2010 (UTC)

Comment. So the narrow majority who opposed are quite happy to force all editors, no matter what the circumstances and the local consensus, to put all of the numerals right at the top, in the opening sentence and in the infobox where there is one, and often as not further down in the appropriate sections. Tony (talk) 10:11, 26 October 2010 (UTC)
Since the majority rule does not apply here, "narrow majority" means "no consensus" and hence (depending on your interpretation) either "status quo" or "no rule, decide on a case-by-case basis". If it means "status quo", right now WP:MOSNUM has: "When only the years are known, or days and months would be irrelevant detail: Socrates (470–399 BC) was..." (italics added). A. di M. (talk) 11:09, 26 October 2010 (UTC)
The part "or days and months would be irrelevant detail" was only recently introduced; I'm not sure on what basis. -- Michael Bednarek (talk) 05:07, 27 October 2010 (UTC)
It was discussed here and its implementation here. But that discussion was much smaller in size than this one. A. di M. (talk) 13:37, 27 October 2010 (UTC)

Tony1 I don't see how you draw the conclusion you do from those who oppose you proposition. AFAICT the opposition is to your suggestion of adding a recommendation not to add full DOB/DOD, (although no doubt many of the current opposer would support a proposition to always have full dates at the start of the article). -- PBS (talk) 23:55, 26 October 2010 (UTC)

As one of the opposers, I would not be "quite happy" with that. Including the full dates in the lede would, in my opinion, obviate the need to include them later in the article. This is not an uncommon style in published encyclopedias (I know it was used in OUP's African American National Biography, for example), giving more room and easier parsing of geographic information.

A side note: the assertion of dates' irrelevance (or importance) in this whole discussion seems to come primarily from the whim of each particular editor, rather than any empirical or otherwise established standard. /ninly_(talk) 15:31, 27 October 2010 (UTC)

(Response to PBS) Including the date to the year of birth/death is a practice I believed is the norm, enough to admit I was surprised that my copy of the New Columbia Encyclopedia didn't follow that practice. However, the NCE does not provide dates of birth/death anywhere in its biographical articles; I assume that is because the NCE's primary goal is to be a "one-volume" encyclopedia, & the editors believed that was something they could exclude. However Wikipedia is not paper, & we need somewhere to put this information that is easy-to-find. If having it in the first sentence -- for whatever reason -- is not acceptible, is there another location in an article where the reader would reasonably expect to find it? I am open to all reasonable, if not better, alternatives. -- llywrch (talk) 17:04, 27 October 2010 (UTC)

Comment A number of editors have suggested that, if we choose to change all articles to the (year-year) format, we could take exceptions to it if the full date is important to that person's life. However, surely the point of this RfC is to create a uniform for all biographical articles—if we can take exceptions to the rule then all biographical articles will not be consistent, and this will leave the average user confused? Wackywace ^{converse | contribs} 18:47, 26 October 2010 (UTC)
Oppose Firstly, I do not believe that having a full date of birth and a full date of death adds clutter to the lede of an article. Having (1956-2004) is far less encyclopedic than having a full date of birth. Many ordinary Wikipedia users come here to look for the full date of birth and/or full date of death of a person, and they are one of the most important things about a person. Therefore, they should be in a prominent position in the article. Wackywace ^{converse | contribs} 18:47, 26 October 2010 (UTC)
How do you know that "Many ordinary Wikipedia users come here to look for the full date of birth and/or full date of death of a person"? or that "they are one of the most important things about a person"? -- PBS (talk) 23:55, 26 October 2010 (UTC)
Exactly what Philip says: how do you know, Wackywace? Do you have evidence supporting this claim? "I do not believe that having a full date of birth and a full date of death adds clutter to the lede of an article"—have you looked at the two examples I provided at the top? To you, and to Philip ... could I point out that this is "a recommendation (rather than compulsion)". It is now being construed as rendering hundreds of thousands of articles in breach of the MoS; that was explicitly not the intention. Tony (talk) 13:47, 27 October 2010 (UTC)
Realistically, there is no way to know what looks good and what does not—it is a matter of personal opinion—and mine is that having a full DoB/DoD at the top of an article does not add unnecessary clutter. Philip, it is obvious that a DoB/DoD are two very important things about a person—if they were not, why would they feature in Template:Infobox person? Wackywace ^{converse | contribs} 19:37, 27 October 2010 (UTC)
Presumably because everyone has a date of birth and death, and most such dates are known, so it fits well into a table. More important facts about a person, such as if he discovered America, go in the text, rather than leave an empty spot in an infobox for everyone who hasn't discovered America. Art LaPella (talk) 20:07, 27 October 2010 (UTC)
"| known_for =" Wackywace ^{converse | contribs} 07:26, 28 October 2010 (UTC)
Oops, you're right. But even so, most of us can remember much more about Columbus than what would fit in the infobox, without remembering his date of birth or death, and what we remember is the part that matters. As for dates, remembering October 12, 1492, is enough to understand the historical context. Art LaPella (talk) 21:17, 28 October 2010 (UTC)

Support - pubicizing birth dates of living persons promotes identify theft. Racepacket (talk) 19:43, 26 October 2010 (UTC)

If the only concern is for biographies of living people, this is already covered by the BLP policy: Presumption in favor of privacy. There's no need to re-write the current MoS to recommend that all biographical arrticles omit exact dates.

If we have the birthdate isn't it because it is published already?Munijym (talk) 07:27, 27 October 2010 (UTC)

Oppose - (1900-1990) is a short-hand for publications where space is limited or the person has died so long ago we don't have the data or it is meaningless to the reader. I expect an encyclopedia should have any known dates upfront and standardized not lurking awaiting discovery. Isn't that why the first sentence includes what country they are from and what profession they are? Munijym (talk) 07:27, 27 October 2010 (UTC)
Alternative: This looks to me like no consensus for either recommendation. The dates of birth and death are an interruption in the first sentence; there is always a case, as Tony says, for shortening that bump. There is also always a case for adding more information; even where the year of birth is unknown, as with Alexander Hamilton, there's a case for saying why. We should acknowledge both cases, and recommend that both be considered; the relative strength of the two cases will vary from article to article. Septentrionalis PMAnderson 16:33, 27 October 2010 (UTC)

In Hamilton's case, as a reader I would expect there to be a brief statement to the effect the date of his birth is unknown/disputed -- if the reason is notable -- & a full discussion in the body of the article. In the case where we only know the date of an early event in the person's life (i.e., date of baptism), identifying that in the lead sentence (or the dates of holding a title) with the appropriate gloss is all that is needed. -- llywrch (talk) 17:04, 27 October 2010 (UTC)

(edit conflict): I agree with Septentrionalis's last comment (which is why I haven't yet put in a "support" or "oppose"). The same applies, I think, to places of birth (which is where this discussion first started, although this RfC is about dates). Sometimes the place of birth or death is significant enough (Napoleon, Hitler, Lincoln & Jefferson Davis both born in Kentucky) or wondered about often enough (e.g. Barack Obama, Albert Einstein, Henry Kissinger) to put somewhere in the first lead paragraph or sentence; often it can wait until further in the article (plus Infobox if one exists). There are conveniences to having a general rule, since a reader knows better what to expect, but the situations are so different that one can't really replace discussion between an article's editors. —— Shakescene (talk) 17:16, 27 October 2010 (UTC)

Oppose. The guiding thought is what is most helpful to readers. If the reader knows the approximate date, or is only interested in learning the lifespan of the subject, then they will read through precise date, discarding the extra information and just picking up the years. However, if the reader is in search of the precise date, they will be sent through the article text to search for the detail, with no particular clue as to where it will be found in a long article. So I think this change will on balance be unhelpful to readers. Sam Blacketer (talk) 10:37, 28 October 2010 (UTC)
Oppose. Dates are very important to give context to someones's life. The only exception I can think of is where the dates are too vague and uncertain to be useful.Dejvid (talk) 11:13, 28 October 2010 (UTC)
Oppose. Firstly Mosnum is supposed to be a recommendation only. Secondly the value of the detail in the parenthesis depends on the person and the era, and of course the reader. In many climes, time of year indicates (or did indicate) a lot about the environment of a birth or death, weather, scarcity of food, prevalence of disease, for example, as well as creating a more vibrant picture. Locality is likewise important - there is more to London than "London" Cadogan Square, or Whitechapel are as different in past centuries as London and New York today, possibly more so. Rich Farmbrough, 04:17, 31 October 2010 (UTC).

Excuse me, it is only a recommendation. Why are you misreading the proposal and putting about a falsehood that is likely to turn people off it? Second, no one is suggesting that the full information not be provided in prominent places in an article; just not all at the top. Tony (talk) 04:22, 31 October 2010 (UTC)

Oppose; well-established convention in reference works. I'm all for keeping lead sections simple, but exact dates are essential information. Llywrch says it well. Antandrus (talk) 04:33, 31 October 2010 (UTC)
Real-Wikiworld example: Purely by chance, I just had occasion to edit one of the few articles I've actually created from scratch, John G. Woolley, notable chiefly as the Prohibition Party's candidate in the 1900 U.S. presidential election. Although my natural tendency parallels the current instructions in the Manual of Style (include full dates of birth and death when known), which I'd forgotten, I started this short two-paragraph biography with "John G. Woolley (1850–1922), ...", beginning the short second paragraph with his full date and place of birth, and ending it with the full date and place of his death. The article's current depth and the subject's importance don't really merit an information box. So would that be sufficient for someone looking for fast vital statistics? It didn't seem important enough to include the full dates at the beginning of the lead of this particular article, but on the other hand, it wouldn't do great harm. So I'm no dogmatist on the question (in other cases, such as Abraham Lincoln (Kentucky, February 12, 1809 – Washington, D.C., April 15, 1865) or some of the other examples I cited above, I'd strongly favour including full dates and/or places of birth & death). But I tend to think that the Manual should be permissive without strong recommendations either way; instead it should point out the considerations that editors should balance. —— Shakescene (talk) 04:44, 31 October 2010 (UTC)

Support; I actually like the suggestion to just put year of birth and death after the full name, and moving the specifics and places into the article proper and the infobox. Sometimes it does bother me that the information is not repeated later, but the other convention is to repeat it verbatim which seems equally pointless. This suggestion allows a summary (i.e. timeline) to fit into the lead, but the full detail (and related vagaries such as calendar changes) to come later. The only times it would feel odd is in a stub, where the duplication will be ridiculous. In those cases (often single paragraph articles), I would argue to leave the dates/places after the name, as much of the current practice is. As soon as a 'contents' box is generated, and the article is long enough to support it, the info should be moved to the personal life/early years/death section as appropriate.—User:MDCollins (talk) 09:58, 2 November 2010 (UTC)

Oppose. First, like it or not, something inserted as a "recommendation" in this manner will end up used as justification for removal of dates, then another editor will disagree and say "it was only a recommendation, please leave my text alone", and the other editor will say "well what's your justification eh? And BTW WP:OWN" and it will degenerate from there. The argument put at the start of this poll involving "mak[ing] it ok for an editor to change without gaining consensus at the talk page first" should be a red flag as to the dangers. Second (and on the other hand) it isn't the case that all biographical sources put a full set of dates at the start: I don't think one can argue for either option based on 'prevailing practice'. Why not have the worst of both worlds: here's the opening phrase from the Australian Dictionary of Biography's entry on James Cook: "COOK, JAMES (1728-1779), navigator, was born on 27 October 1728 at Marton-in-Cleveland, Yorkshire, England..." Both versions of the date in the lead! I think not ;-) Third, I can be pursuaded to support if someone can demonstrate to me that it will make the MOS shorter and simpler - but I'm not seeing that as a likely outcome :-) hamiltonstone (talk) 02:11, 3 November 2010 (UTC)
Oppose. The person's full birth and death dates, where available, is the kind of information readers would expect to find in a prominent place in any encyclopedia entry. If we didn't already have a standard of putting those dates in the lead sentence, we might not adopt it now if we were starting from scratch. But by now, Wikipedia readers may well expect to find that information there, so we should continue to recommend that such dates (if available) should be shown there for new biographical articles as well. --Metropolitan90 (talk) 04:25, 3 November 2010 (UTC)
Strong spport - the article openning should give a general idea of the person, not all the details. While the time when a person lived is relevant the precise date is usually not. עוד מישהו Od Mishehu 11:13, 3 November 2010 (UTC)
Strong oppose; The lead sentence of an article about a person should always give the most publicly desired, relevant, and core information about them. A person's DOB and DOD along with their nationality, gender and reason for notability are all crucially important to the lead IMO. Besides, if the DOB isn't in the lead where will it be? The "Early life" section? No can do — what about in stub articles that have no body? The infobox? Hell no, that's not prominent enough. We list a person's notability and nationality in the Infobox as well, does that mean we should remove that from the lead too? What would be left?... Michael Jackson was a...?. — CIS ^(talk | stalk) 15:17, 5 November 2010 (UTC)
Weak Oppose I recall myself scanning biography pages to find when a person died. Let's add infoboxes to all bio pages and then we can discuss it again. -- Magioladitis (talk) 02:33, 10 November 2010 (UTC)
Infoboxes make me vomit, I'm afraid. Let's not do that. Tony (talk) 03:30, 10 November 2010 (UTC)
Support: It's good to minimise how much detail is contained in the intro. Birth and death years and nationality are important but the specific dates and and cities are clutter. Details should follow later whether they be in a seperate section or, in the case of a very short article, in a seperate paragraph. JIMp_talk·cont 03:48, 10 November 2010 (UTC)
Support with exceptions. The primary purpose of the lead paragraph is to establish context and provide a very broad overview of the topic. Birth year and death year almost always help to establish context by establishing the era the person lived in; birth place and death place may also help with this, but these are usually omitted in favour of adjectives as in "an Austrian composer" (I think either one or the other is fine). Birthdays/deathdays rarely help to establish context or to summarize the topic, unless the birthday is one of the most notable facts about the person - for example, if a major holiday was created to celebrate their birthday. I would limit their inclusion to such cases, and even then I would consider noting it in a separate sentence of the lead paragraph. I also agree that infoboxes should continue to contain detailed information. Dcoetzee 00:40, 11 November 2010 (UTC)
Oppose It is a convention on Wikipediat that doesn't need to change. Elmmapleoakpine (talk) 02:07, 11 November 2010 (UTC)
Oppose per Fram, Michael Bednarek et al. --Klein zach 01:42, 12 November 2010 (UTC)
Oppose As far as known, full DOB/DOD information should be at the top. The lead consists of many things repeated further down the article, so why not in this case. And who decides when a specific date is important "of itself"? This proposal only confuses things that used to be clear so far. Buchraeumer (talk) 23:53, 12 November 2010 (UTC)
Oppose Theres no reason to change it. If only the years are shown, it looks like we dont have the exact date.--Metallurgist (talk) 04:24, 15 November 2010 (UTC)
Support - keep unnecessary detail from lead and conform to many other publications. Racepacket (talk) 21:49, 19 November 2010 (UTC)
Support recommendation, especially since if there's an infobox it usually includes the full dates already, so the reader would not even be forced to scroll down to find the information. The lead sentence can become unnecessarily cluttered in many articles with alternate names, pronunciations etc. Better to move non-essential information elsewhere if possible. Year of birth/death has much more importance in understanding the subject than the actual dates. Jafeluv (talk) 01:31, 24 November 2010 (UTC)
Oppose, having the full date is entirely fine. Not broken. Wizardman _{Operation Big Bear} 18:49, 27 November 2010 (UTC)
Comment - The full date and place of birth should, if available, appear somewhere in the article. If they appear in both the lede and later on in the article, then the lede should contain just the years of birth and of death (for example Barack Obama), but in short articles, especially where there is no full lede (for example John Traicos) the full date and place of birth and death should be in the opening line. Martinvl (talk) 19:06, 27 November 2010 (UTC)
Oppose Only the full date allows readers to calculate age (current or at the time of death) quickly. I would argue age is the most relevant datum for living people. Surprised no one has mentioned this.--Carwil (talk) 02:58, 29 November 2010 (UTC)
Oppose - as per many above. -- Jack of Oz ... speak! ... 18:33, 29 November 2010 (UTC)
Oppose. Not broken, needs no fix. I also don't think birthdates are really as extraneous of details as some here seem to suggest. Heimstern Läufer (talk) 09:59, 30 November 2010 (UTC)

(N.B.: comments after this point were made after the "Standing as of December 1 2010" section, below, was written)

Standing as of December 1, 2010

Well, this thread has been open for over thirty days, which is the recommended life for an RfC. And discussion has slowed to a trickle. And eventually the thread will become dormant and disappear into the archives. And so, while not intending to cut off discussion or step on anyone's toes, I think it would be worthwhile to take a reading of where we stand at this point.

It has been a lively discussion and all are to be thanked for contributing and congratulated for making many cogent points.

When trying to summarize the many subtle points made into simple numbers, I am reminded of the joke: A man says to the waiter "I would like the filet mignon, just a tad over medium rare, and my date will have the same, but just a bit less than well-done and with the bernaise source on the side." The waiter turns toward the kitchen and shouts "Burn two!"

Nevertheless, we have to reduce data into a form we can get a handle on, so here goes.

According to my count, we have had 83 contributors so far. Two did not take a definite side, so by my count we have:

Support: 31 Oppose: 50

This is 62% Oppose from a pretty large sample.

Of the Support comments, three were "Support for long bios, but not for short bios". Five Support comments were in the nature of "Support, except when the date is an observance or is otherwise noteworthy". One Oppose commentor also preferred a case-by-case approach.

There was some mention of infoboxes, but apparently infoboxes are controversial and it looks like any recommendation which suggests using them or assumes their existence would not be acceptable to several commentors.

Turning to strength of argument. There does not seem to be a universal standard generally used by similar publications, so appeals to that may be dismissed, I guess. I think - and this is a considerable simplification - is that the main arguments are:

Support because:
- It avoids data clutter which detracts from the getting the key facts from the lead as efficiently as possible.
- The years give the gist of when the person thrived, which is the main thing you want to know right off about the person.
Oppose because:
- It's basic factual info about the person that some readers will want to know right off.
- And as we can't assume an infobox (often absent, and controversial anyway) the birth and death dates will be widely seperated (and the death date in particular will require looking deep into the article).

Both are strong and cogent points. I can only speak for myself, but it seems that neither argument leaps off the page and dances on the grave of the other. I would describe the arguments as reasonably close to being of equal strength. A point about being able to easily calculate age (current or at death) was brought up, but late.

So given the 62% Oppose numbers I think it fair to say that the proposal (that a recommendation be made to usually use just years in the opening parens) has not succeeded.

So. Does this mean that the opposite proposition - that a recommendation be made to use dates in the opening parens - has consensus? Not necessarily. You don't want to say that a stand against a proposition is anything other than what it is, unless the person has made it abundantly clear. So to establish that, one would have to sort out people who support that from people who support no recommendation. I haven't gone through each "Oppose" comment to separate those who can probably be considered to clearly support the opposite proposition (use dates) from those can't. But throwing out even ten "Oppose" comments as not being clearly in support of the opposite proposition would bring the percentage clearly supporting the opposite proposition down to 56%, which is maybe not a sufficient supermajority to be considered a consensus, in my personl opinion. (If someone wants to go through all the comments and do this, though, that'd be great. Maybe it's much less than ten.)

So where does that leave us?

One answer could be "Well, there's no consensus from a large sample, so we should adopt the system used for English spelling/American spelling: the person creating the article gets to decide the format, and editors should not change it absent some good reason with discussion first." It'd be unusual for a work like the Wikipedia to have no manual of style on this, but that's the situation now anyway, and we're unusual in a lot of ways, and the number of actual reader deaths caused by not having a specific rule on this would probably be low enough to be acceptable.

However.

There's no consensus for adopting the English spelling/American spelling solution, and only a few commentors seemed to specifically support this. And I would think that an attempt to get consensus on this would maybe fail - you would have many "Support" commentors, but several streams feeding into the "Oppose" river: "Oppose, don't care which it is but we should have one definite style" and "Oppose, it should definitely be years only" and "Oppose, it should be definitely be year and date", and "Oppose, OK to have be either depending on the case (long article/short article, infobox/no infobox, date observed/not observed), but shouldn't be decided by random factor of who first wrote the article" - and at any rate can't be assumed. So to adopt the English spelling/American spelling solution would require a different discussion, I think.

So where does that leave us?

Nowhere. We don't have a recommendation, but we don't have a decision to not have a recommdation. So it remains the Wild West - as it stands, editors are free to change the format of an article we come across to suit their preference, I guess, including mass conversions using scripts. This is not a good situation. I don't have a solution, except maybe to open another discussion.

All this is my personal opinion, and if there is a consensus or solution that I'm not seeing, slap me with a trout and tell me what it is. Herostratus (talk) 19:46, 1 December 2010 (UTC)

The proposal by Tony1 was "for a recommendation (rather than compulsion) at MOSNUM that where birth and death dates appear elsewhere in an article, just the years be provided at the opening of the lead". That proposal failed to gain consensual approval, so the status quo at MOS:DOB remains. I can't see how an inverse, or opposite, of that proposal can be construed, nor can I see the need to do so. -- Michael Bednarek (talk) 03:52, 2 December 2010 (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.

Dates - dashes, spaces and things

Our current guideline says:

At the start of an article on an individual, his or her dates of birth and death are provided. For example: "Charles Darwin (12 February 1809*** – ***19 April 1882) was a British ..." En dashes are preceded and followed by spaces, where the preceding space should preferably be a non-breaking space, ...

Is there any reason why the 12 characters between the two *** marks above can't be replaced with simpler and neater {{spaced ndash}}? I use this all the time, and it works for me. -- Jack of Oz ... speak! ... 18:56, 29 November 2010 (UTC)

No idea. The template's documentation says: "Also, this template should not routinely be used in regular article text and certainly not where an em-dash would be more appropriate. As a rule, this template should not be used between clauses of a sentence." But it just expands to " – ", so I can't see what's wrong with using it that way and I'll continue to do that until someone explains me why I shouldn't. A. di M. (talk) 19:30, 29 November 2010 (UTC)

Does "what's wrong with using it that way" refer to "this template should not routinely be used in regular article text [or] ... between clauses of a sentence"? If so, this discussion is relevant. Art LaPella (talk) 22:34, 29 November 2010 (UTC)

That frightful en dash template should be banned. To start with, it renders the spaces badly at best, and wrongly at worst. Second, it is nine keystrokes rather than three. Geekery gone mad. Tony (talk) 10:05, 30 November 2010 (UTC)

It expands to " – ", so the spaces will be rendered exactly as if the template weren't used – like this. Also, " – " is 14 keystrokes. (If you have a keyboard with the en dash character, it's eight keystrokes, but if you have a keyboard with the hard space you'd better not use it because it'll turn into a normal space as soon as someone edits and saves the section with Firefox or another browser with that quirk. In my ideal world you could type "_-- " which is four keystrokes, but don't let me go into that again.) A. di M. (talk) 12:40, 30 November 2010 (UTC)

MoS just recommends a hard space in such situations: it is not mandated. Does this mean that my Mac hard space (com-space) won't survive? I'm not sure about this. Tony (talk) 15:31, 30 November 2010 (UTC)

Well, but when the hard space is used, how is {{ndash}} worse than  – ? Your hard space will only survive until someone using Firefox (and possibly other browsers) saves the page, for example I'm copying and pasting hard spaces into the following: test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test . A. di M. (talk) 15:42, 30 November 2010 (UTC)

Isn't this a bit of a tempest in a teapot? If someone is browsing Wikipedia with a browser width so narrow that they're remotely likely to have an automatic line break after the fifth or sixth word in a sentence, an odd wrap before the en dash will probably be the least of their typographical worries. I don't think a hard space before the en dash in this case is strictly necessary for anything but pedantry. If it does seem necessary on a page, I'd check to see if perhaps the infobox or photo is unduly wide before adding the en dash... There's no reason to not do it, but there's absolutely no reason to go about mandating it or "fixing" it. // ⌘macwhiz (talk) 15:59, 30 November 2010 (UTC)

I note that the date elements in our own signatures have never included hard-spaces. I've not heard a single complaint. Tony (talk) 16:04, 30 November 2010 (UTC)

See if any of the 23s split from the Decembers when you narrow and widen the window: 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980 Tony (talk) 16:35, 30 November 2010 (UTC)

Before I edited the section, they didn't... A. di M. (talk) 16:46, 30 November 2010 (UTC)

...well, they still don't. Maybe the bug is with the copy-and-paste, so lemme try copying and pasting that: 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980, 23 December 1980. A. di M. (talk) 16:48, 30 November 2010 (UTC)

Now the very first December wraps. So the problem is that on pasting text into Firefox (and/or copying it from Firefox) the hard spaces are converted to ordinary ones. Dunno... A. di M. (talk) 16:50, 30 November 2010 (UTC)

spaces with degrees?

I can see that there is some kvetching about this in the previous pages, but am just curious about the MOS taking a firm stance that we should have a space between the number and the degree sign for temps? We would not do that if Kelvins, right? So why not the number flush against the degree symbol? Plus, even by WP's own description of degree symbol typography that seems more accepted, no? http://en.wikipedia.org/wiki/Degree_symbol#Typography Are we using WP to try to drive a different standard of English? (At least the "capitalize animals even though they are common nouns" people seem to have died down. ;) But seriously, educate me. I'm no maven. What gives? TCO (talk) 06:54, 2 December 2010 (UTC)

We indeed do space Kelvin units. "270 K" (with a non-breaking space) is the correct form. Non-breaking spaces should always be used before unit symbols, including degrees Celsius and degrees Fahrenheit. That's just the way the Wikipedia consensus decided to standardise measurements. McLerristarr | Mclay1 07:34, 2 December 2010 (UTC)

I'll march to the drummer, don't fear. Just asking. (And you are right on kelvins.)

Um...but what if you refer to a number of degrees and just use the symbol (without the letter)? Wouldn't you normally just butt the symbol up against the number in that case, same as you would with a percent symbol?

"The engine temperature rose 10° in the hot sun."

-or-

"The engine temperature rose 10 ° in the hot sun."

(Last one looks funny, no?)

TCO (talk) 08:07, 2 December 2010 (UTC)

I agree, spacing the degree symbol looks very wierd. I have never seen it done that way in any other publication. Roger (talk) 08:18, 2 December 2010 (UTC)

MOS:NUM#Unit symbols:

Values and unit symbols are separated by a non-breaking space. The {{{1}}} template or the character can be used for this purpose. For example, use 10 m or 29 kg, not 10m or 29kg.
- Exceptions: Non-alphabetic symbols for degrees, minutes and seconds for angles and coordinates and the percent sign are unspaced (for example, 5° 24′ 21.12″ N for coordinates, 90° for an angle, 47% for a percentage, but 18 °C for a temperature). See also Manual of Style—Geographical Coordinates.

I suppose if you were to write degrees without the C or F then it would follow the same conventions as for angles and coordinates. However, it's probably not recommended to ignore the C or F because of ambiguity and because it's technically incorrect. McLerristarr | Mclay1 10:15, 2 December 2010 (UTC)

Normally I'd only use 20 °C or 68 °F; in a direct quotation of a source using "degrees" for temperatures without specifying which ones, I'd use the format the source used if it's written and spell out "degrees" if it's spoken. (In both cases I'd add square brackets specifying which degrees are meant and the conversion to the other degrees.) A. di M. (talk) 16:51, 2 December 2010 (UTC)

Though one can not require that novice editors posses advanced wikimarkup and HTML-coding skills as a condition of contributing to Wikipedia, advanced editors should always use a non-breaking space (or no-wrap) between a numeric value and a unit symbol. Ending a line with a 10 and beginning the next line down with a °C is awkward looking and distracts. It is ambiguous to not specify the temperature scale being used—failing to do so also entails the shortcoming of the expression looking similar to a measure of angle; ergo, when using unit symbols in the measure of temperature or intervals of temperature, a good way to code is as follows: 60 °C and 140 °F and 333 K to obtain 60 °C and 140 °F and 333 K.
BTW, it is A right angle is at 90° from the first line segment, not A right angle is at 90 ° from…. This is in perfect accordance with the BIPM’s manual of style for the SI, which requires a space before all unit symbols with the exception of the symbols for degrees, minutes, and seconds of unit angle.
As for intervals of temperature; that is, for ∆T (differentials), I personally think it wisest to write out the unit of measure in a form that is exceedingly unambiguous and can’t be misinterpreted as a specific temperature on a scale. Thus, I write The Siemens industrial thermal switch marked “100 °C” attached to the espresso maker’s boiler has a hysteresis of 15 degrees Celsius and will therefore nominally allow the water to reach as low as 85 °C.
To my knowledge, MOSNUM is correct (at least it was when I last looked) in its advise with regard to temperatures and angles and the proper formatting of their unit symbols; editors should abide by its advise.
Greg L (talk) 19:21, 2 December 2010 (UTC)
- Or more exactly "100 °C", if we are enforcing straight quotes according to the "Quotation characters" paragraph of WP:PUNC. Art LaPella (talk) 20:54, 2 December 2010 (UTC)
  - Indeed. You are quite correct. We eschew typographers’ quotes in order to make Wikipedia more accessible to editors sitting in front of computers running Barbarian-OS. User:⌘macwhiz knows what I’m talking about. ;-)
    There's a discussion about allowing curly quotes right now at WT:MOS#Quotation marks: typewriter vs. typographical. A. di M. (talk) 12:42, 4 December 2010 (UTC)

I'll follow the guide and learn the nonbreaking space and all that. Don't really have a strong opinion, was just curious. On the other hand capitalizing bird names would only be done under duress. TCO (talk) 23:02, 2 December 2010 (UTC)

Thanks. I wish every editor had your “go with the flow” attitude. Note however, that you don’t have to learn and use non-breaking spaces. We’ve recently changed one of the guidelines to be consistent with the principle that it It is advisable to use them. The point is that if you don’t bother to learn the advanced skill (or simply forget), all that is needed is to allow others—without reverting them—to come in later and clean that sort of thing up so that page-flow variables will still result in fine typography. We even have people who operate bots for this sort of thing. To the extent that you want your work to be even more polished, that’s great. Greg L (talk) 23:15, 2 December 2010 (UTC)
P.S. As to capitalizing the names of bird species, I’m not an expert on such matters so I am reticent to comment on the matter as it pertains to factual issues on birds. I do note that MOSNUM has a strong emphasis on the fundamental principal that Wikipedia should follow the practices widely observed by reliable sources in any given field. I don’t know what the simple facts are regarding birds and these sort of things are best left up to those wikipedians who specialize in a given field. However, I find it quite interesting that a very reliable source (perhaps the most reliable source) on all-maters bird—the Audubon Society, here,—capitalize the names of bird species. Their usage has it “Allen's Hummingbird” and “Rufous Hummingbird”. I’ll leave it at that; these things are best hashed out on the talk pages of our bird-related articles. I learn something every day. Greg L (talk) 23:26, 2 December 2010 (UTC)
P.P.S It appears that the principle of capitalizing applies not only to species of birds, but also to breeds of dogs. I see that the AKC, here, capitalize breeds; it is the “Airedale Terrier”. As a medical researcher, it might have been better if I had known this before. That’s what’s good about Wikipedia… Anyway, none of this has anything to do with MOSNUM; such things belong on MOS and elsewhere.
Greg L (talk) 23:32, 2 December 2010 (UTC)

Reminder: last chance to vote in the Arbitration Committee Elections

This weekend is the final chance to vote in the December 2010 elections to elect new members to the Arbitration Committee. Voting began last Friday and will close just before midnight UTC, end of Sunday 5 December (earlier for North America: just before 4 pm west coast, 7 pm east coast). Eligible voters (check your eligibility) are encouraged to vote well before the closing time due to the risk of server lag.

Arbitrators occupy high-profile positions and perform essential and demanding roles in handling some of the most difficult and sensitive issues on the project. The following pages may be of assistance to voters: candidate statements, questions for the candidates, discussion of the candidates and personal voter guides.

Proceed here to cast your vote

For the election coordinators, Tony (talk) 02:46, 4 December 2010 (UTC)

FYI: Oil industry millions as MM

This is a general notice that we are changing Template:Convert to show "MMbbl" for "million barrels" of oil, which seems to be a standard notation for the oil and gas industry. The one-M form, "Mbbl" is for "thousand barrels" of oil. For example:

{Convert|9|MMoilbbl|abbr=off} → 9 million barrels (1.4 million cubic metres)
{Convert|9|MMoilbbl|abbr=on} → 9 MMbbl (1.4×10^⁶ m³)

I searched in Google and confirmed solid use of "MMbbl" (or "mmbbl") for million barrels of oil, in webpages for Exxon Mobil and PEMEX (Petroleos Mexicanos) since at least 2000, see PEMEX abbreviations & 2001 book:

"Abbreviations" webpage at Pemex.com: Pemex-Abbrev-PDF.
The Western Gulf of Mexico Basin: tectonics, sedimentary basins (2001), Google Books link: Western-Gulf-p272.

Does anyone anticipate any problems which might arise from use of symbol MMbbl? -Wikid77 (talk) 00:14, 1 December 2010 (UTC)

If that ugly-ass looking thing is really widely used in the oil industry, then that is what should be used. However, I strongly recommend that editors abide by one of the most-overlooked but most powerful guidelines in existence (IMHO) on WP:MOSNUM (located at Wikipedia:Manual of Style (dates and numbers)#Conventions): Where space is limited, such as in tables, infoboxes, and parenthetical notes, and in mathematical formulas, unit symbols are preferable. In prose it is usually better to spell out unit names, but symbols may also be used when a unit (especially one with a very long name) is used many times in an article. (emphasis was mine).
Thus, if there is a table of various countries’ oil production over time or whatever, go ahead and use the unit symbol. I’d also advise that such a table have a small text footer bullet point (or something in the column heading) explaining what the unit symbol means. For body text, it would be much better to just spell out “13 million barrels of oil per hour are wasted by guys driving big-ass trucks to make up for the fact that they have small ‘junk’.”
As I wrote on these pages once before, editors often think they are being very—as Sarah Palin might say—*scientificy* when they use unit symbols in prose. Or perhaps they think they are impressing their wikipedian peers because… *certainly only some editor who really knows his stuff could be so fluent with ‘insider talk’.* But being a wikipedian is not about impressing upon others that we ‘must be from the BIG CITY.’ Quickly descending into use of obscure unit symbols in prose without good reason just makes articles less accessible to a general-interest readership. Take, for instance, this actual first sentence from this version of ‘SN 1979C’:

“

SN 1979C was a supernova about 50 Mlys away in Messier 100, a spiral galaxy in the constellation Coma Berenices.

”

Huh? “Mlys”??? Is that millions of barrels of molasses? Even Sky & Telescope wouldn’t do that. It’s generally better to write these ones out as long as there is room and the unit of measure isn’t being repeated ad nauseam. (talk) 02:58, 1 December 2010 (UTC)

And once again I'll point out that to my knowledge, nobody advocates using that guideline in the case of kilograms, which is the example in the guideline. Or at least the guideline isn't put into practice that way. People would be more likely to know and use the guideline if it said what we really meant. Art LaPella (talk) 04:50, 1 December 2010 (UTC)

The guidelines says what it means. You apparently disagree with the example it uses; ergo: 1) You’re quibbling about a detail of the guideline, 2) the example used in the guideline (kilograms) doesn’t invalidate the principle it conveys (generally write out units of measure), and 3) the metric system isn’t used in the U.S. and since kilograms aren’t generally used in the daily life of an American, the use of the symbol “kg” makes the measure even less likely to be understood. So the example used (write out “kilogram”) is especially good advise. There certainly are exceptions, such as an article on U.S. highways and the speeds on them. There would certainly be nothing wrong with writing “mph” instead of belaboring over and over with “miles per hour” after the measure has been properly introduced. But to use a unit symbol from the metric system (kg) in an “Oh… didn’-cha know?”-fashion in en.Wikipedia (where, as I recall, ~~25%~~ 46% of our readership is American), is poor technical writing practice. And finally…
…As to this specific thread (the use of the unit symbol “MMbbl” or “Mlys” for that matter), write them out, as the guideline says. That’s always good advise and is part of Technical Writing 101 for any encyclopedia directed to a general-interest readership. In the mean time…
Art LaPella will apparently insist on writing “The fool was crushed under 700 kg of cow manure after sliding his car sideways into the back of the farm truck” rather than “…crushed under 700 kilograms of cow manure…” because he finds the latter to be so much clearer for an English-speaking readership that includes Americans. That’s *extra special*. No one here can stop you, Art. Do what you want; I’m not going to argue the point with you.
Greg L (talk) 06:09, 1 December 2010 (UTC)
46% actually... A. di M. (talk) 12:39, 1 December 2010 (UTC)

OK, I withdraw "to my knowledge, nobody advocates using that guideline in the case of kilograms"; there is at least one exception, namely GregL. It's still true that almost no actual articles aren't written that way, and the exceptions are mostly articles about units rather than just using the unit to measure something. Google search Art LaPella (talk) 01:45, 2 December 2010 (UTC)

If "kg" is too hard, "MMbbl" forget it. The guideline says to avoid "MM" for "million" because it's obscure industry-specific jargon. In a table, you won't need symbols anyway, just write the unit out at the top of the column. PS "Mlys" is wrong anyway, don't pluralise units, it's "Mly". JIMp_talk·cont 11:29, 1 December 2010 (UTC)

Well, I half agree with you, Jimp. Yes, spell out the units of measure in regular prose unless the unit of measure is repeated a tedious number of times or other good reason (like tera-electron•volt).
But the sum of MOSNUM’s guidelines could not be clearer that for those disciplines where a majority of reliable sources use a given unit of measure (such as barrels), then Wikipedia should go with the flow. That principle doesn’t change for the accompanying unit symbol for “millions of barrels” in sections of articles where space is at a premium, such as in tables. We suddenly don’t invent a house style and look towards the SI for guidance as to what would be an SI-like unit symbol that the world ought to follow our lead and adopt.
In my first response, above, I wrote two things:

If that ugly-ass looking thing [referring to “MMbbl” now] is really widely used in the oil industry, then that is what should be used. And…
It’s generally better to write these ones out as long as there is room and the unit of measure isn’t being repeated ad nauseam.

My advise is, I think, founded upon good technical writing practices and (fortunately), MOSNUM is now in a state that mirrors that. Are you and I going to disagree about any of this?

The only other caveat I added is one that is already observed on Wikipedia (making Greg L happy again) on, for instance, automotive-related articles. Certain units of measure, like “55 mph” are expressed as unit symbols in daily life for our readership to such an extent the unit symbol becomes a spelled-out unit of measure unto itself. So for an article on the U.S. highway system, using “mph” would be appropriate in an article that is closely associated with the U.S. after it has been properly introduced in spelled-out form and the unit symbol properly introduced via a parenthetical for the benefit of our metric-thinking readership.

The point in technical writing is to craft prose in a manner where the writing style doesn’t call attention to itself. This causes the fewest (!) brain-interrupts as thought is conveyed.

Further, whereas some wikipedians tend to write across widely disparate disciplines and desire project-wide consistency, pursuing this desire to the point where editors flout widely held practices with the very units of measures, unit symbols, and terminology used within disciplines does our readers no favor whatsoever. We certainly do no one a favor by casually referring to “computers with 256 MiB of RAM” when the reader won’t find such terminology in a book or magazine on computer technology after they close their browser window and walk away from their computer.

In short, as editors, it is our duty to fully and clearly understand a particular discipline and be knowledgeable about its terminology and language, and to convey it in plain-speak so obscure techno-speak well known to the pros is made as accessible as possible for a general-interest readership. Doing so best supports the core purpose of any encyclopedia, which is to educate its readership on a given topic and properly prepare them for their continuing studies elsewhere on that subject.

Greg L (talk) 15:34, 1 December 2010 (UTC)

Usage of MMBBL on Wikipedia

I ran a database search and found only 11 articles using 'MMBBL' (upper or lower case). Of those

three articles were definitions (Barrel (unit), Volume units used in petroleum engineering, List of energy abbreviations).
Two articles explicitly stated what the symbol meant.
Two articles linked the symbol.
Three articles needed improvement with respect to units of measure. They might be acceptable for passing from one oil nerd to another but need further work to be suitable for Wikipedia readers.

This symbol is in a class of domain-specialist symbols that is obscure to outsiders. In some cases, the symbol was being used when the full form could have been used. If that isn't possible, articles should provide an explanation or a link (as some articles do). We could list some of the known symbols in this class ('MMBBL', 'MBBL', 'TCF', 'CID') in a table. Lightmouse (talk) 14:09, 4 December 2010 (UTC)

M for thousand (and MM, MMM for million, billion) is not oil industry specific. It's done in the chemical industry, used for finance, etc. Not just oil quantities, but often financial stuff. It IS very old school and confusing and even though I spent several years using it, I still vote to NOT do it here. The M means thousand, not million always tripped me up. TCO (talk) 15:34, 4 December 2010 (UTC)

I just found the following text in mosnum: "If a unit symbol which can be unfamiliar to a general audience is used in an article, it should be shown parenthetically after the first use of the full unit name...". That seems to apply to 'MMBBL' if it must be used at all. Lightmouse (talk) 18:02, 4 December 2010 (UTC)

See the two {xt} green-text points in the thread, above. Another editor seem to have demonstrated that if the unit symbol is used at all, it is best “MMbbl”. I don’t know if that particular form is most common or not. But, to drive home the point again, use of unit symbols in regular body text—particularly specialty units—should be greatly discouraged. Greg L (talk) 21:37, 6 December 2010 (UTC)

Units in 1910 London to Manchester air race

Editors have tried to provide unit conversions in 1910 London to Manchester air race. These keep being removed by the most frequent editor of the article. Edit summaries for removal include "if people can't figure it out themselves then tough". Some editors raised the issue on his talk page which says "If you're coming here to lecture, patronise, troll or otherwise fuck me about, then you definitely won't get the response you expect.". See the discussion.

Would anyone else like to try to improve the article? Lightmouse (talk) 11:49, 5 December 2010 (UTC)

Seems like the currently-empty discussion page for the article (rather than of an editor) might be the best place to raise this. At least over time, more editors are likely to see it, and—now that the benefits of an individual approach seem to be exhausted—it might be less personalized than the tit-for-tats on the edit history and user page. At first blush, I can see arguments on both sides, but this Featured Article should really come to its own consensus. Does the Aviation WikiGroup have a policy about units of distance? Since the race was a century ago, some of this year's commemorative stories might use km as a primary unit and be easier to correlate with a few more conversions after the first one.—— Shakescene (talk) 20:11, 6 December 2010 (UTC)

Lightmouse, User:Parrot of Doom’s edit was clearly improper and s/he has no leg to stand on. Roughly 45% of en.Wikipedia’s readership is American. Most of the rest thinks in metric terms. To make the articles as clear as possible for our readership, we provide conversions. Also, Parrot of Doom’s edit summary was patent nonsense. Providing conversions for our metric-thinking readership isn’t “pandering”; it’s making the article more accessible for a large segment of our readership. MOSNUM could not be any clearer on this principle. Greg L (talk) 21:31, 6 December 2010 (UTC)

America's Franken-sizes: The U.S. handling of metric units is a divided mindset: gasoline and motor oil is in gallons and quarts, but soda is bundled in 2 or 3-liter bottles, yet has 16-ounce and 20-ounce servings. Many scientists use metric units (based on thousands: 1 km = 1,000 m) almost entirely, but computer experts rarely need metric units, while thinking in kilobytes (1,024 bytes) and megabytes (1024x1024 bytes), and cups or quarts of milk and orange juice. Meanwhile, miserly packaging is shrinking the American portions: 18-oz peanut butter shrank to 17.3 ounces per jar, while half-gallon ice cream shrank to 1.75 liters, and such. America has become a culture of "Franken-sizes" twisting and warping the metric and other units. Hence, chemistry articles rarely need non-metric units, but beverages need liters and ounces, while automobiles need U.S. gallons, quarts and liters. The units depend on the subject, not the nation. -Wikid77 (talk) 07:56, 7 December 2010 (UTC)

Proposal to move details on specific units into a table

We have the following text scattered throughout all the other woolly guidance:

Use nmi (or NM) to abbreviate nautical mile
Use kn to abbreviate knot
Use nautical mile or statute mile rather than mile...
The symbol for litre is written as an upper case L when not preceded by a prefix.
Avoid using the old-fashioned name "degree centigrade"
The symbol for the bit is bit

Guidance like that could be summarised in a table. Most debates on talk pages are about specific units and it would be more helpful to have all of this in one place. Lightmouse (talk) 22:07, 26 November 2010 (UTC)

Proposed table layout:

Name	Symbol	Comment
degree centigrade	°C	A synonym for degree Celsius. May be used in quotations and historical contexts. Otherwise should be replaced by degree Celsius.
fermi	fm	A synonym for femtometre. May be used in <...circumstances...>.
knot	kn
litre (liter in American English)	Use upper case L when not preceded by a prefix. This is to eliminate confusion between a solitary lower case l and the digit 1.
metre (meter in American English)	m
micron	μm	The micron is a synonym for micrometre. May be used in <...circumstances...>.
nautical mile	nmi (or NM). The symbol nm means nanometre.	Use nautical mile rather than mile in nautical and aeronautical contexts to avoid confusion with statute mile

Regards Lightmouse (talk) 09:50, 27 November 2010 (UTC)

The point is to do what the sources do, not to use the SI except in a finite number of circumstances. Thousandths of inch should be used for gauges of guitar strings, not millimetres. Inches should be used for displays, not centimetres; and so on. A long list of cases in which to use non-SI units would 1) be very likely to be incomplete and 2) leave the readers unable to see the forest for the trees. (If someone doesn't know which is the proper unit for guitar string gauges and doesn't know how to find that out, they shouldn't look it up on a long list on WP:MOSNUM: they shouldn't be writing an article about guitar strings in the first place.) A. di M. (talk) 11:54, 27 November 2010 (UTC)

I agree that it shouldn't list all units. However, mosnum contains scattered guidance on specific units. A table would make the existing guidance on those particular units and make it easier to access. Or have I misunderstood you and your suggestion is to delete the existing guidance on 'centigrade', 'litre', 'metre', 'nautical mile', 'knot' etc? Confused. Lightmouse (talk) 14:02, 27 November 2010 (UTC)

I don’t see why, A. di M., Lightmouse should not be able to consolidate information on units. I think we all agree that MOSNUM has slowly evolved into quite a tangle and needs to be rearranged. As Lightmouse wrote, things are scattered all over the place. However, I agree 100 % ;-) with you, A. di M., that a table referencing the rule of SI should not look towards the BIPM’s recommendations any further than has already been done on MOSNUM; that is, a table should take existing guidelines and faithfully reflect what they say. And more to your point, the underlying principle that the table should not undermine is, as you say, what do the sources say. Accordingly, where MOSNUM is silent, the table should remain silent.

Another detail (perhaps this point has already been raised but I don’t see it) is that many of the current guidelines on each of these points has example text to make meaning clear. Either room should be made in the table to encompass all the information and examples, or room should be made immediately below the table to provide notes with the full verbiage. Alternatively, links could be provided below the table directing readers to the full verbiage in their existing locations. Given that this is a hot-button issue, I would propose that the table and accompanying notes or links be run by all here for review before being posted.

Greg L (talk) 16:44, 27 November 2010 (UTC)

P.S. I would propose too, that we limit discussion of the table to one simple point: whether it reflects current intent and meaning and conveys that information in a better manner. Most-everyone around here agrees that better organization is good. What we should certainly reject are any attempts here to exploit discussion of the table to consolidate existing information for the purposes of advancing a new agenda. The current guidelines are the product of vigorous debate—often over protracted periods of time—and the result are compromises that met the consensus view and were thought to best serve the interests of our readership. Precious little of of what is currently in MOSNUM (or none of it) was by accident. The result is a proper balance between those who just want it MY way and The SI Nazis®™© and those who say “just follow current literature.” If we get bogged down with agenda-pushing to get changes and/or new items from peoples’ wish-lists introduced, we will never make progress on simple reorganizations like Lightmouse is proposing. It’s time to put our foot down on that stuff. Greg L (talk) 17:08, 27 November 2010 (UTC)

I don't see why only non-SI usage should be consolidated. The table may be helpful, but all specific MOSNUM recommendations, even where they align with SI or BIPM recommendations, should be listed. This should probably include binary prefixes kibibit and kibibyte, etc. (By the way, do we want to comment on μ as an obsoleted, but potentially used, symbol for micron?) — Arthur Rubin (talk) 17:00, 27 November 2010 (UTC)

With regard to the micron symbol, Arthur, see my PS, above. If the issue is already addressed on MOSNUM, there is no reason we can’t include it. If MOSNUM is silent, then *later* would be a better time to introduce new topics; otherwise, we will never be able to make progress in reorganizing what is currently on MOSNUM into a more coherent structure. Greg L (talk) 17:11, 27 November 2010 (UTC)

I'll comment on that later, if I remember. I agree that the discussion of the micron symbol shouldn't be in this section, but the status of our position on the IEC recommendations probably should be in the table.

I lean toward requesting that Lightmouse not edit the guideline, himself, as he had (note tense) misinterpreted it to read "BIPM ~~only~~ except ...." rather than "use what reliable sources use, which is usually SI/BIPM". Many of his suggestions do constitute an improvement, but WP:BRD is not a good guideline for editing guidelines. — Arthur Rubin (talk) 17:23, 27 November 2010 (UTC)

With regard to your first paragraph, that’s good. With regard to your second paragraph, see the last sentence of my second paragraph of my 16:44 post, above. But, in short: yes, I agree. We will avoid Turkish butt-stabbings, ANI finger-pokes in the eye, and ArbCom inquisitions and the attendant tongue amputations if we all have an opportunity to see and discuss what he is proposing here on WT:MOSNUM before it gets posted to WP:MOSNUM. If we all avoid trying to introduce changes to meaning as he does the heavy lifting, things should go smoothly enough. Greg L (talk) 17:47, 27 November 2010 (UTC)

I can't remember when I last edited mosnum and I'm not intending doing any more editing of mosnum for a while. I proposed the table here because I see it as a major change in format. Good points are being made:

The table shown here is only meant to illustrate the principle of consolidating existing guidance on specific units. This will make it simpler for anyone wanting to check the guidance on a specific unit (a common reason for coming to mosnum). As a consequence, the general guidance section will become shorter and more distinct.
The table should include SI where mosnum varies from the standard. With the recent revisions, we no longer need to say that mega is 'M' not 'm' and watt is 'W' not 'w'. Thus we can get rid of a lot of metric guidance in mosnum.
The table should include non-SI e.g. bit and byte. The more extensive stuff about binary prefixes may be too long to put in there.
The table should be silent where the existing guidance is silent (thus 'fermi' should not have been put in the example). First we need to decide on the table itself. If consensus is that the existing guidance is inadequate e.g. for fermi, kph, μ, then the table is the place where the outcome of a debate is recorded.
The table should be expanded as far as we want and include anything relevant to a specific unit. But in some cases it might be best to have a summary with extensive discussion elsewhere in mosnum. Some of mosnum uses units to illustrate a point and that seems to me to be quite different.
I think it would be good to have a competely different section for all the various thoughts on how to address units that aren't in mosnum or what to do if a debate breaks out somewhere.

Regards Lightmouse (talk) 17:59, 27 November 2010 (UTC)

Most of what you write above is very good, Lightmouse. But I am confused. You wrote, in bullet point #2 as follows: The table should include SI where mosnum varies from the standard. Does that mean that if MOSNUM eschews the BIPM and does not follow the rule of the SI in some regards, the table should include what the SI says? Wouldn’t that be confusing? Greg L (talk) 18:05, 27 November 2010 (UTC) (I’m taking a break for part of the day. Back later.)

Quite the opposite. If MOSNUM eschews the BIPM and does not follow the rule of the SI in some regards, the table should include what the MOSNUM says. The table is simply a new container for existing mosnum guidance. I hope that's clear. Bullet point #2 was addressing Arthur Rubin's comment "I don't see why only non-SI usage should be consolidated". So I said "The table should include SI..." - I meant the table should include existing guidance about "SI units" as shown in the above example. Lightmouse (talk) 18:55, 27 November 2010 (UTC)

I'm not sure that that (M not m) shouldn't remain in the guideline, but it shouldn't be in the table. I appreciate the clarification. Good idea. — Arthur Rubin (talk) 19:06, 27 November 2010 (UTC)

Following the points made above, here's an update. Proposed table layout:

Name	Symbol	Comment	Existing mosnum text (this column will not appear in mosnum)
bit	bit	Other symbols for bit (such as b or B) should be replaced with bit. This is to reduce confusion with byte. Similarly, it is kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc.	"The symbol for the bit is bit, not b."... "By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc."
byte	B or byte	Other symbols for byte (such as b or o (French: octet)) should be replaced with B or byte. This is to reduce confusion with bit. Similarly, it is kB/s (not kBps or KBps) and MB/s (not Mbps or MBps).	"The byte may be represented by either one of the symbols B and byte, but not b or o (French: octet)."... "kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps)."
cubic centimetre	cm³ or cc	The non-SI symbol cc may be used to refer to engine volume e.g. Honda motorcycles engines. The form cc must be linked to cubic centimetre on first use in each article.	"it is cc in an article on Honda motorcycles engines and not cm³"... "Such non-standard units or unit names are always linked on first use."
degree centigrade	°C	A synonym for degree Celsius. May be used in quotations and historical contexts. Otherwise should be replaced by degree Celsius.	"Avoid using the old-fashioned name "degree centigrade" for the degree Celsius, except in quotations and historical contexts."
knot	kn	The symbol 'kt' is reserved for kilotonne. The symbol 'kN' is reserved for kilonewton.	"Use kn to abbreviate knot: kt could be confused with kilotonne; kN could be confused with kilonewton."
litre (liter in American English)	Use upper case L when not preceded by a prefix.	The solitary lower case l is avoided to reduce confusion with the digit 1.	"The symbol for litre is written as an upper case L when not preceded by a prefix. This is to eliminate confusion between a solitary lower case l and the digit 1."..."American spellings of unit names (e.g. meter or liter) should be used on pages written in American English."
long ton	long ton	This unit must always be spelled out in full.	"Use long ton or short ton and not just ton; these units have no symbol or abbreviation and are always spelled out."
metre (meter in American English)	m		"American spellings of unit names (e.g. meter or liter) should be used on pages written in American English."
micron	μm	A synonym for micrometre. A link to micrometre is required on first use in each article. The symbol μ may be used in quotations and historical contexts, otherwise it should be replaced by μm.	"the term "micron" (rather than micrometre) is also still in widespread use in certain disciplines. Such non-standard units or unit names are always linked on first use."
mile per hour	mph		"Exceptions include mph for the mile per hour..."
nautical mile	nmi (or NM).	The symbol nm is reserved for nanometre. Use nautical mile rather than mile in nautical and aeronautical contexts to avoid confusion with statute mile	"Use nmi (or NM) to abbreviate nautical mile rather than nm (nanometre)."
Pound per square inch	psi		"Exceptions include ... psi for pounds per square inch..."
short ton	short ton	This unit must always be spelled out in full.	"Use long ton or short ton and not just ton; these units have no symbol or abbreviation and are always spelled out."
tonne (metric ton in American English)	t	Other symbols (such as mt or MT) should be replaced with t.	"American spellings of unit names (e.g. meter or liter) should be used on pages written in American English." ... "The tonne, 1000 kilograms, is officially known as the metric ton in the US. Whichever name is used, the symbol is t."

There are some more specific units mentioned such as ounces, gallons but I've stopped working on the proposed table for now. Regards Lightmouse (talk) 17:31, 4 December 2010 (UTC)

Such a table, since it is meant to summarise MOSNUM guidance, would need to include units like KB in the decimal and binary sense. It should also make it clear the XiB style is generally not to be used.Fnag aton 11:20, 8 December 2010 (UTC)
- Drive-by comment (I'll be back soon): this looks like a great idea. Tony (talk) 12:45, 8 December 2010 (UTC)

use of c. with other numbers than years

I find some use in articles of c. (for circa) for other numbers than years (use for years is disussed in this MOS). Examples: "c. 150 meters" or "c. 200 sites", indicating "about 150 meters" or "about 200 sites". I have been changing the "c." to "about", but what do you all think? I see nothing in this MOS about this. Hmains (talk) 22:21, 3 December 2010 (UTC)

IMHO: Very good. c. is not well recognized by a general-interest readership and is unnecessarily cryptic. The whole point of being a wikipedian is to communicate as clearly as possible; not impress our wikipedian peers with how we must be from the big city and are comfortable with geek-speak. The same thing can be found in chemistry papers directed to scientists, where the slightly longer form ca. is often used to denote that the magnitude of a physical measurement is approximate. “Circa”, hower, in my opinion, is very closely associated with approximate dates. Accordingly, this expression: Thomas Harriot, circa 1585, first pondered the mathematics of the cannonball arrangement seems appropriate to me since—even if the reader is unfamiliar with the term—it pretty much explains itself because of context. I think, were it me, I would most certainly replace any instances of c. used in the measure of physical quantities with about or approximately or a similar spelled-out word. For approximate dates, I would expand c. to circa rather than substituting it with an alternative word, such as about. Greg L (talk) 23:18, 3 December 2010 (UTC)

I don't think of the expression as dates only. But would be a bit more tolerant of it there. TCO (talk) 23:59, 3 December 2010 (UTC)

The existing guideline for years is "c. is preferred over circa, ca, ca., approximately, or approx.", so "I would expand c. to circa" would be better phrased as a proposed guideline change. Art LaPella (talk) 00:58, 4 December 2010 (UTC)

Where on earth did they get the idea that c. is more widely understood than ca.? That's what I want to know. Wareh (talk) 01:59, 5 December 2010 (UTC)

I don't write the rules (except for copyediting); I just automate them. Art LaPella (talk) 04:01, 5 December 2010 (UTC)

Oh. I didn’t realize that. Indeed; I propose a guideline change. The details of the wording may vary, but the principle would be this:

To denote that the year an event occurred is approximate, write out circa 1900 instead of c. and ca. and similar abbreviations in order to communicate clearly to a general-interest readership. Wikipedia is not a gigantic scientific paper for submission to an archeology journal.

And I note that the guideline to which you linked speaks only to using c. for years. It appears volunteer wikipedians thought the advise to be so way-cool and *scientificy*, they would use it to denote that any measure is approximate. So Wikipedia apparently has There are c. 1200 EPA Superfund sites, instead of There are approximately 1200 EPA Superfund sites. What?? Like, writing clearly hurts?

Aliens on planets 50 Mlyrs away wouldn’t write so abstrusely. ;-)

Greg L (talk) 02:59, 4 December 2010 (UTC)

If the guideline is changed to specify that circa can be used for measurements other than dates, I don't think it should be allowed for non-measurement numbers (e.g. "Circa 1500 oranges grew on the tree."). A number following circa without a unit of measurement afterwards could be confused for a year (e.g. my previous example could be confused for "Circa 1500, oranges grew on the tree."). McLerristarr | Mclay1 09:43, 4 December 2010 (UTC)

Yeah, this whole “circa”-thing for dates is a giant mess unless limited to years. Nothing in MOSNUM should be interpreted to encourage use of “circa” and any of its abbreviations for use in measures of anything besides years. And when one does want to use the word, spell it out; the abbreviation c. is best reserved for scientific papers. I propose the following:

• Use of circa: When denoting that the year an event occurred is approximate, editors may chose to replace the phrase in approximately and its near-equivalents with the Latin word circa. When doing so, spell out the word (do not use abbreviations c. or ca.). The expression is generally used either as a parenthetical or as a clause set off with commas. In place of Thomas Harriot in about 1585 first pondered the mathematics of close‑packed spheres, the following alternatives are suitable: Thomas Harriot, circa 1585, first pondered the mathematics of close‑packed spheres or Thomas Harriot (circa 1585) first pondered the mathematics of close‑packed spheres. Do not use circa or its abbreviations to denote that measures other than years are approximate.

I believe the above should be uncontroversial and will add it shortly. If this assessment and WP:BOLDness was misplaced, please revert. Greg L (talk) 19:43, 4 December 2010 (UTC)

Couldn't you swap "c." with "circa" in the existing text (removing "abbreviation" of course)? (BTW, I guess that anybody who's unfamiliar with "c." would be very likely to be unfamiliar with "circa" as well.) A. di M. (talk) 19:50, 4 December 2010 (UTC)

The earlier text did not explicitly explain that the expression should generally be inside a parenthetical or at least as a clause. See Answers.com on this issue. We have such inexperienced editors coming to Wikipedia so we best give them the full deal on how to handle the word. And given User:Hmains’ observations (what started this thread), an short explicit statement to not use it for any other measures seems appropriate. Greg L (talk) 19:55, 4 December 2010 (UTC)

I agree that circa or any of its abbreviations should NOT be used for non-years and I think that alternative words, such as 'about', approximately' or whatever should be mentioned so that editors are given an alternative. There are not so many instances of this that a change will be difficult to implement. Hmains (talk) 20:55, 4 December 2010 (UTC)
I think that 'c. ' should be used for years, not 'circa '. First, 'c.' has been in place for some time in MOS and WP has thousands/tens of thousands or more instances of this. And 'c.' should be used whether or not the year is in parenthesis (there are just as many instances in WP of using or not using parentheis for years). Circa is too long when used in tables or strings of years. Would you enjoy reading "c. 2300 BC/c. 2200 BC - c. 800 BC/c. 750 BC" or "circa 2300 BC/circa 2200 BC - circa 800 BC/circa 750 BC". And 'c.' should be used whether or not the year is in parenthesis (there are just as many instances in WP of using or not using parentheis for years). I have no way to know, but 'c.' might be a common-enough English construction that can be safely used in WP. If not, the first instance of its use in an article can be wikified as [[circa|c.]] as one does when terms are introduced in an article. Hmains (talk) 20:55, 4 December 2010 (UTC)
- The original advise to use an abbreviation was a mistake. The form that is most accessible to a general-interest readership is the fully spelled-out form. We have many operators of bots who could fix the many instances of “c.” And while doing so, they can ensure that the expression is properly separated as a clause—or better yet—parenthetical. Tables, where space is limited, are typically treated differently from body text in many regards, including the fact that sentence fragments are OK; that’s a separate matter. Greg L (talk) 22:10, 4 December 2010 (UTC)

And legislating against the use of abbreviations completely would also be a mistake. I have serious doubts about the use of bots in this instance. _wjemather ^bigissue 22:41, 4 December 2010 (UTC)

The current version is in a list called "Years" and doesn't mention other units; the point about approximations of other quantities (mysteriously located at the end of the section called "Avoiding ambiguities") doesn't mention circa at all. Maybe a sentence about not using circa could be added to the latter, but in the former it would be off-topic: given the context is already clear that that point applies to years but not masses of black holes or lengths of human penises. (I'd bet that the editors writing the articles Hmains found hadn't read MOSNUM in the first place, not that they misunderstood it.) A. di M. (talk) 12:16, 5 December 2010 (UTC)

Straw poll on "circa"

The previous guideline on the use of "circa" (third bullet point in Years, here), did not specify that the term should be a clause or a parenthetical, did not prohibit using it in expressions like c. 150 meters, and told editors to use the more obscure abbreviation. Please indicate your support or opposition for the new wording, shown below, and the reasoning for your position:

• Use of circa: When denoting that the year an event occurred is approximate, editors may chose to replace the phrase in approximately and its near-equivalents with the Latin word circa. When doing so, spell out the word (do not use abbreviations c. or ca.). The expression is generally used either as a parenthetical or as a clause set off with commas. In place of Thomas Harriot in about 1585 first pondered the mathematics of close‑packed spheres, the following alternatives are suitable: Thomas Harriot, circa 1585, first pondered the mathematics of close‑packed spheres or the even-better Thomas Harriot (circa 1585) first pondered the mathematics of close‑packed spheres. Do not use circa or its abbreviations to denote that measures other than years are approximate.

Support Write it out instead of the more abstruse c. and ca. and similar abbreviations in order to communicate clearly to a general-interest readership. Wikipedia is not a gigantic scientific paper for submission to an archeology journal. Also, Wikipedia gets its share of novice editors so more explicit examples of usage help. For things like chained expressions (multiple dates in a row of approximate BD/AC dates) or in tables and other places where space is limited, exceptions might well be added to the above wording. But for general body-text prose, the above appears most readable and clear. Greg L (talk) 22:22, 4 December 2010 (UTC)

Oppose on the basis that while things should generally be spelled out in running prose, abbreviations are sometimes preferable, especially where space may be limited (e.g tables), so it makes absolutely no sense to say "do not use abbreviations". In addition, I don't see any reason to change for the sake of being consistent with Answers.com which is far from a reliable or definitive guide for anything. _wjemather^bigissue 22:38, 4 December 2010 (UTC)
- Well, we’re converging a great deal then. Quoting you: on the basis that while things should generally be spelled out in running prose… From that, I would deduce that you aren’t so excited about the old wording that flat says “write "c." (everywhere, including regular body text). So why don’t you propose some revised wording that advises that for 'general prose', the above is best; and then advance some exceptions. Maybe you can pull off some extra-clever, catch-all wording to handle exceptions. Post it below as a the next === level straw poll. Greg L (talk) 22:47, 4 December 2010 (UTC)
  - Your deduction would be correct, I just wouldn't say abbreviations should never be used. Not sure about the best way of wording it (it's quite late here now, so probably won't come up with anything tonight). I have to say also that I don't like straw polls when we can just discuss and come to consensus without them, and I think that is eminently doable here. _wjemather ^bigissue 22:58, 4 December 2010 (UTC)

Hmm… let me try this one then to see if we can achieve a closer-yet convergence:

• Use of circa: When denoting that the year an event occurred is approximate in regular body text, editors may choose to replace the phrase in approximately and its near-equivalents with the Latin word circa. When doing so in body text, it is generally best to spell out the word and not use abbreviations c. or ca.. The expression is generally used either as a parenthetical or as a clause fully set off with commas. Thus, in place of Thomas Harriot in about 1585 first pondered the mathematics of close‑packed spheres, the following alternatives are suitable: Thomas Harriot, circa 1585, first pondered the mathematics of close‑packed spheres or the even-better Thomas Harriot (circa 1585) first pondered the mathematics of close‑packed spheres.
In tables and other places where space is limited, consider using the abbreviation ca. When denoting a range of dates from antiquity in regular body text, consider taking advantage of available room and write …from around 2300 BC to around 2200 BC or …between approximately 2300 and 2200 BC as an alternative to more cryptic expressions like (ca. 2300 BC/ca. 2200 BC).
Do not use circa or its abbreviations to denote that measures other than years are approximate.

I changed "chose" to "choose". Art LaPella (talk) 23:21, 4 December 2010 (UTC)

Thanks. I’m working on that chose/choose distinction. I’m also working on spelling “exercise” (Ha! Got it right that time). Greg L (talk) 23:26, 4 December 2010 (UTC)

My preference is for c. rather than ca. as an abbreviation but see no reason to recommend one over the other. Likewise with commas/parentheticals – each is acceptable and we don't need to prefer one. I also dislike the phrase "regular body text" and don't think it is actually needed. I'm sure "best" (of two options) is gramatically incorrect as well (should be "better"). How about this: _wjemather ^bigissue 00:36, 5 December 2010 (UTC)

• Use of circa: When denoting that the year an event occurred is approximate editors may choose to replace the phrase in approximately and its near-equivalents with the Latin word circa. When doing so it is generally better to spell out the word rather than using abbreviations such as c. or ca.. The expression is generally used either as a parenthetical or as a clause fully set off with commas. Thus, in place of Thomas Harriot in about 1585 first pondered the mathematics of close‑packed spheres, the following alternatives are suitable: Thomas Harriot, circa 1585, first pondered the mathematics of close‑packed spheres or Thomas Harriot (circa 1585) first pondered the mathematics of close‑packed spheres.
In tables and other places where space is limited consider using the abbreviation c. or ca. When denoting a range of dates from antiquity in regular body text, consider taking advantage of available room and write …from around 2300 BC to around 2200 BC or …between approximately 2300 and 2200 BC as an alternative to more cryptic expressions like (ca. 2300 BC/ca. 2200 BC).
Do not use circa or its abbreviations to denote that measures other than years are approximate.

Comment1 I would strongly discourage constructions like Thomas Harriot (circa 1585) first pondered the mathematics of close‑packed spheres. To me, that looks as though 1585 was the approximate year of Harriot's birth, by analogy with the common construction Thomas Harriot (1560–1621).... Adrian J. Hunter^{(talk•contribs)} 04:47, 5 December 2010 (UTC)

Comment2 Let's not write "Do not use circa or its abbreviations...", which gets readers used to seeing "circa" written in italics, which no-one here is advocating. We should instead write "Do not use "circa" or its abbreviations...", or else use {{xt}}. Adrian J. Hunter^{(talk•contribs)} 04:47, 5 December 2010 (UTC)

Like all Latin words, circa is generally italicised in English. The guidelines used to suggest italicising the abbreviation too. McLerristarr | Mclay1 11:11, 5 December 2010 (UTC)

So it is, my mistake. I was just looking at the examples in green above, most of which are not italicised (but should be?). Adrian J. Hunter^{(talk•contribs)} 14:11, 5 December 2010 (UTC)

Yes, probably should be italicised. _wjemather ^bigissue 15:50, 5 December 2010 (UTC)

comment3 I still see no good reason why the current MOS regarding years should be changed: use 'c.'. No exceptions, no quibbling, no having to think and ponder when and where--'c'.' is to be used everywhere with years. 'c.' is in common use in the literate English world, which surely the target audience for WP. And 'ca.' is rarely used compared to 'c.' in WP. One of the purpose of a MOS is to provide stability over time so that faithful editors can follow it and not expect to have things changed underneath or behind them all the time. All the proposed wordings are simply ignoring this line of thought; hardly a consensus at all. And the proposed wording just makes this area of WP far too complicated to attact anyone to be interested in or to follow. Hmains (talk) 05:55, 5 December 2010 (UTC)

Oppose – I much prefer using "c." rather than the spelt-out "circa". We don't spell out "e.g.", "i.e.", "fl." or "etc.". McLerristarr | Mclay1 11:09, 5 December 2010 (UTC)

Oppose I think the current wording is just fine. Stongly oppose the form Thomas Harriot, circa 1585, first … or Thomas Harriot (circa 1585) first … because, as Adrian J. Hunter observed above, it can be understood as a DoB. -- Michael Bednarek (talk) 12:41, 5 December 2010 (UTC)

- Then you are strongly opposing the way things are properly done. If you made yourself more familiar with proper practices, you’d understand that what you advocate is a off-standard house style. Greg L (talk) 19:31, 5 December 2010 (UTC)
  - I support the thrust, but also see the ambiguity in the example, and would propose that as to what 1585 applies to can be resolved by relocating the juxtaposition. --Ohconfucius ^¡digame! 02:48, 6 December 2010 (UTC)

Oppose, but revising guideline to specify the more widely used and understood ca. in place of c. Wareh (talk) 15:23, 5 December 2010 (UTC)

Since when was "ca." more widely used? I see "c." far more often. McLerristarr | Mclay1 15:31, 5 December 2010 (UTC)

Quite, I very rarely see ca. used anywhere. _wjemather ^bigissue 15:48, 5 December 2010 (UTC)

Straw poll on circa #2

• Use of circa: When denoting that the year an event occurred is approximate editors may choose to replace the phrase in approximately and its near-equivalents with the Latin word circa. When doing so it is generally better to spell out the word rather than using abbreviations such as c. or ca.. The expression is generally used either as a parenthetical or as a clause fully set off with commas. Thus, in place of Thomas Harriot in about 1585 first pondered the mathematics of close‑packed spheres, the following alternatives are suitable: Thomas Harriot, circa 1585, first pondered the mathematics of close‑packed spheres or Thomas Harriot (circa 1585) first pondered the mathematics of close‑packed spheres.
In tables and other places where space is limited consider using the abbreviation c. When denoting a range of dates from antiquity in regular body text, consider taking advantage of available room and write …from around 2300 BC to around 2200 BC or …between approximately 2300 and 2200 BC as an alternative to more cryptic expressions like (c. 2300 BC/c. 2200 BC).
Do not use circa or its abbreviations to denote that measures other than years are approximate.

Support Cryptic abbreviations of already cryptic latin words should be avoided in prose. Moreover, the most-proper use of "circa" is to have as a clause separated by commas or as a parenthetical. Greg L (talk) 19:24, 5 December 2010 (UTC)
- I would have thought "Circa 1585, Thomas Harriot first pondered the mathematics of close‑packed spheres" or "Thomas Harriot first pondered the mathematics of close‑packed spheres circa 1585" also acceptable and a probably more common structures. Also, as above, should "circa" not be italicised? _wjemather^bigissue 19:42, 5 December 2010 (UTC)
  - I used to sell Word Book encyclopedias back in the late 70’s. So I still have my two-volume Wold Book dictionary from 1976. And I have my 1787-page unabridged Webster’s New Encyclopedic Dictionary, published 1993. Of course, both these are so old that the prefix “giga-” is pronounced jiga (before legions of Joe Sixpack went to Wal-Mart to buy computers and common usage changed). So it can’t be ruled out that new-age ways of corrupting things via the internet hasn’t encroached into the proper usage of Latin words to communicate meaning.
    Neither encyclopedia says that the word “circa” should be italicized. Webster’s shows it italicized in its example, but then, all usage examples in it show the word in question in italicized typestyle.
    Webster’s doesn’t mention abbreviating it, but World Book dictionary reads as follows: Abbr: ca. That bit makes boat loads of sense to me since c. is that little bit more abstract; at least the added a in ca. helps to queue readers’ mind to the full word and its meaning: “circa”. But I’ve compromised to the more cryptic single-letter abbreviation for those here who have long had it their way and want to continue that practice.
    The whole point of all this adjustment is to encourage writing things out in plain-speak and to try to get away from using the most abstract and cryptic techniques known to man—as if that is somehow the way one communicates unambiguously to a general-interest readership that includes plenty of high school-age students. There has been an insidious tendency on Wikipedia for editors, in a subconscious effort to impress their peers that they have mastery of arcane insider-speak on issues, to engage in such practices as employing unit symbols in measures in regular body text. As User:Hmains noted in beginning this thread, this phenomenon of “write like you’re an impressive pro who can write *scientificy* and shouldn’t be reverted” has lead to unnecessarily abstruse writing practices and insider-speak as if that a good thing for a general-interest readership. Thus, we have editors writing c. 150 meters away instead of the infinitely clearer approximately 150 meters away. This revision to the guideline addresses that point quite succinctly (and in plain-speak, too).
    Greg L (talk) 21:01, 5 December 2010 (UTC)
    - After some more thought about the whole issue, instead of deciding how to use "circa", shouldn't we be recommending that people just use plain and simple English? That is "about" or "around" (but not "approximately"), rather than suggesting that latin is okay. The only use of circa that should be acceptable is abbreviated (as c. because that is by far the most common in the real world as far as I can tell) in certain circumstances, such as where space is at a premium. With that in mind, the existing wording only needs a minor tweak since it currently seems to recommend using "c." in all instances. _wjemather^bigissue 21:40, 5 December 2010 (UTC)
      - I’m all for recommending that editors eschew Latin and French and all manner of crap that unnecessarily makes the written word unnecessarily abstruse if there is a plain-speak way using *English words* (*sound of audience gasp*) to communicate the message more clearly. Communicating as plainly as possible would be more formally sanctified as de rigueur. ;-) I’m not yet sold that c. is more common and clear than circa if one is not looking towards speciality sources specializing in archeology. If the venue is a general interest publication, I should think that the spelled-out word would be clearer. If you have evidence to the contrary as regards general-interest articles, please provide the evidence. I can show you that ca. is used all over the place in chemistry circles to denote that a physical measure is approximate (a good friend of mine is a near-retired Ph.D. chemist). Thus, one will find precisely what User:Hmains wrote of, with instances galore in chemistry papers of added ca. 200 ml. As to eschewing “approximately”, I see nothing wrong with that whatsoever since that is pretty much exactly what it means; see all these Web definitions. Greg L (talk) 21:59, 5 December 2010 (UTC)
        Yes, that does seem to ring some bells but aren't they almost always talking about measures other than years? It may be that ca. is more common in the U.S., so you will be more familiar with it but I certainly don't see much of it. A couple of style guide examples from the U.K.: The Times (although that is "c" on it's own) and the University of Oxford (also uses italics). Incidentally, the BBC likes "simple words" such as "about" instead of "approximately" to make it as easy as possible for readers. They echo your sentiments on the use of "foreign phrases" – "...unless you are deliberately setting out to persuade your audience that you are a journalist of some pretension and virtuosity, it is advisable not to use them." _wjemather ^bigissue 22:34, 5 December 2010 (UTC)
        Could it just be that chemists use "ca." and historians use "c."? A. di M. (talk) 23:17, 5 December 2010 (UTC)
        
        I wouldn’t be surprised if it isn’t just that simple, A. di M.
        I suspect we are developing a clear consensus that just because chemists see We added ca. 200 ml H₂O to prevent an exotherm in Polychem Level-V Andromeda-Strain Journal (25), p 268 and like to mirror such practices in their laboratory notebooks (Greg L in his early 40s: “Dr. Bayyuk, what does ‘ca.’ mean here?”), is no reason for for MOSNUM to recommend that editors follow such practices in the body text of an encyclopedia directed to a general-interest readership.
        Once we agree upon the basic principal of limiting “circa” and its triply-obscure abbreviations to the maximum practical extent and recommend that editors simply write “about,” “roughly”, “in about,” and “approximately,” then we can discuss the details of a few notable exceptions, such as tables and other areas where space is at a premium.
        No matter what we end up with, I strongly suggest we include an explicit proscription on the utterly dreadful hybrid practice drawn from chemistry- and archeology-related journals where c. is used to denote that the magnitude of a physical quantities are approximate, such as The Acme-brand safe landed c. 150 meters from Road Runner. The term “circa”—if it is used at all—should be limited to only years.
        Greg L (talk) 00:06, 6 December 2010 (UTC)
I am happy for "c." or "ca." to be used only for years, and not italicised. Tony (talk) 02:09, 6 December 2010 (UTC)
Oppose – Anyone who does not know what "c." means will not know what "circa" means either. As long as we link the first usage, a reader can look up what it means if necessary. Support not using circa for measurements other than dates. McLerristarr | Mclay1 02:47, 6 December 2010 (UTC)
- A pernicious Wikurban myth that needs be rooted out is that unnecessary obscurities can be easily resolved by just linking. Most readers, apparently, are just like me in other contexts (where I'm unblest with Wikipedia:popups), they only click a link, wait for it to load, replace the text before them with a different page, and then (we hope) return by a like process to where they'd begun with the greatest of reluctance. Most readers aren't editors, most editors aren't registered, and I think that most registered editors haven't installed WP:Tools/Navigation popups. It's easier just to stay mystified—like wanting to read a French book, hear an Italian opera, see a Shakespeare play, sing a traditional Christmas Carol, recite a nursery rhyme, or attend a Book of Common Prayer wedding without consulting a dictionary for every unfamiliar word. But if a familiar one is ready to hand, why don't we (writing in the same language and era as our readers) use it? —— Shakescene (talk) 14:10, 6 December 2010 (UTC)
Agree about the futility of linking. Readers just don't divert for that purpose. Tony (talk) 14:50, 6 December 2010 (UTC)
Well, if a reader doesn't know what a word means and can't be bothered to find out just by clicking, why should we care? It's not our problem. McLerristarr | Mclay1 15:24, 6 December 2010 (UTC)
That is exactly the attitude that we don't need on Wikipedia. Wikipedia is written for the users, not for the editors, so it is our problem. That doesn't mean we need always make endless detours, heroic sacrifices or Herculean efforts on their behalf, although many editors do spend much time and trouble trying to increase accessibility, overcome national differences in usage and construct clearer tables. But using "about" instead of "circa" requires no such effort. —— Shakescene (talk) 19:51, 6 December 2010 (UTC)
So you think we should never use any words that readers may not understand? It is unlikely that an adult native English-speaker would not know what "circa" means. If they do not understand "hard" words, they have the Simple English Wikipedia. My point was, it's not our problem if someone is too lazy to look up a word in the dictionary. Although, they wouldn't have to do that if we linked the word to our own article... McLerristarr | Mclay1 03:23, 8 December 2010 (UTC)

What about <abbr title="circa">c.</abbr> (c.)? (The abbr tag has been in HTML ever since I can remember, i.e. at least since the late 1990s, so I'd expect any kind of user agent to have a convenient way to allow the user to retrieve the expansion.) A. di M. (talk) 16:07, 6 December 2010 (UTC)

That tag apparently causes problems with screenreaders; see Talk:Spiccato#Abbr element in sound file description. <span title="or thereabouts">c.</span> (= c.) seems to work better. -- Michael Bednarek (talk) 03:16, 7 December 2010 (UTC)

That appears to be a particularly, er..., ‘unorthodox’ usage of abbr, not about abbr in general. IIUC with "abbreviation announcement on" c. would just be read as "circa". A. di M. (talk) 04:30, 7 December 2010 (UTC)

Support use of 'circa, 'ca.' or 'c.' These should only be used to indicate approximate years. In such a circumstance of not applying it to e.g. distances, I believe the need to link to circa, as a dicdef, would be obviated. --Ohconfucius ^¡digame! 02:54, 6 December 2010 (UTC)
Support. Per Oh.--Epeefleche (talk) 03:19, 6 December 2010 (UTC)
oppose The only idea for which there is consensus is that circa and its abbreviations should not be used for non-years. It follows therefore that the only change that can be made at this time to this MOS is to add the sentence: "Do not use circa or its abbreviations to indicate that measures other than years are approximate." The only question is where to place this sentence. Hmains (talk) 03:54, 6 December 2010 (UTC)
- Well, the first two sub-bullets of the last bullet of "Avoiding ambiguities" (???) says "When part of a full sentence, write approximately in full", though I don't think it's intended to discourage any other choice as there's nothing wrong with "about". Maybe it could be changed to "write about or approximately in full ... Do not use circa except for years." A. di M. (talk) 11:18, 6 December 2010 (UTC)
Oppose as worded because it's too wordy and per McLerristarr, though maybe we could add "in parentheses, tables and the like" after "or about" in the currently existing text. A. di M. (talk) 11:18, 6 December 2010 (UTC)
Support per Greg L. SteveB67 (talk) 15:52, 6 December 2010 (UTC)
Oppose the use of the abbreviation c. I'm not a native English speaker (Danish), but consider myself fluent, have a master in engineering with a mostly English curriculum, and have spend a large part of my life reading in English. Yet I don't recall ever seeing c. used! It must be restricted to some specific fields like perhaps history or genealogi? Both circa and ca. seems completely commonplace to me, but then again they are in Danish, so I could well be mixing that up. However c. can not by any strecth be commonplace, and saying that if you don't know c., you won't know circa is just wrong. Normally a person with limited vocabulary will know the word, before (s)he knows the abbreviation. Take ROFL for an easy instance (yes, there are exceptions, usually words where the abbreviation is rarely read out loud in its full form, like IRA or PC. c. is not one of them, it will always be read out as circa). I'm not saying the use of c. is catastrophic - if you know circa, propably you'd often be able to guess the meaning of c. from context, but ca. would be far easier in that regard, and thus preferable. (NB: I was surprised to see that circa is not considered English. What is a reliable source for finding that i.e. circa should be italicised, whereas approximately should not - both being of Latin origin?)
It also seems questionable to recommend setting circa off with commas or parentheses. Sentences like "He was born circa 1600" seems to be a correct and common use, and is btw. the (only!) example used by both Merriam-Webster and Cambridge online (OK, so they must have stolen that example from each other, but it can't be all wrong?)
Tøpholm (talk) 23:06, 7 December 2010 (UTC)
- If you oppose the use of the abbreviation you would then support the proposal, would you not? I would have to disagree that "ca." is easier to understand. "ca." could easily be mistaken for an initialism or an abbreviation of a word starting with "ca". Also, in modern English, usage is moving away from using a full stop after an abbreviation ending in the last letter of the word, therefore "ca" should have no full stop but that would probably be mistaken for a typo of something. As for the comment about Latin, "approximately" is derived from Latin, as are many English words, but "circa" is a Latin word. In English, foreign words are usually italicised. It is slightly odd to italicise words like "circa" which have been completely absorbed into our language but that's just what's done for some reason. McLerristarr | Mclay1 03:19, 8 December 2010 (UTC)

Support In this case abbreviations do not help clarify what is actually being written.Fnag aton 11:15, 8 December 2010 (UTC)

Where nbsp adds no value and might even be harmful

I think the obsession with nbsp has gone too far. Adding nbsp is a nerdy programmers delight - it's easy to do. The current guidance doesn't put any constraints so we have people adding them everywhere. I think it's time the guidance was updated to indicate cases where nbsp adds no value.

On a large browser, lines don't wrap for the first 30 words. On a small browser (e.g. handheld device) the nbsp is actually a bad thing. As an example of zero added value use, look at an aircraft specifications table.

I'd like to add a caveat to the guidance such as:

nbsp serves no purpose where a large browser window won't wrap and could make reading more difficult on small browser windows. A rule of thumb is to avoid the use of nbsp for the first 30 words from the left of a line.

Regards Lightmouse (talk) 12:19, 5 December 2010 (UTC)

OK with "no value", but how it it harmful? Even on a very narrow browser, in such a line as "Empty weight: 11,150 kg (24,560 lb)" I'd pretty much prefer the break to be after "kg" (or after "weight:") than before it (or, much worse, before "lb)". Can you take a snapshot of something which looks worse with hard spaces than with soft spaces? (One disadvantage I do see with hard spaces is that they make the source code of the page harder to read, but if a slicker way to input hard spaces was implemented there'd be no such problem. See WT:MOS#Nbsp before en dash.) A. di M. (talk) 12:36, 5 December 2010 (UTC)

After other objections of this kind, with great difficulty I programmed my AWB to avoid nbsp in the first 30 characters (not words), but remember that windows can be any size if they aren't maximized to the whole screen. Art LaPella (talk) 19:09, 5 December 2010 (UTC)

Perhaps you could suggest that as a new feature for AWB? McLerristarr | Mclay1 03:20, 6 December 2010 (UTC)

You mean include nbsp as described at MOS:NUM#Non-breaking spaces among WP:AutoWikiBrowser/General fixes, but only after the first 30 characters? I can't imagine what that could mean, that wouldn't create way too many false positives. Art LaPella (talk) 03:52, 6 December 2010 (UTC)

Yes, that is what I mean. If AWB adds non-breaking spaces before units of measurement (like it already does) and before an endash, I don't see what false positives are possible. Even if there are a few false positives, it's not like a stray non-breaking space is a major concern. At least a false positive would make it easier to find the original mistake that caused the false positive. McLerristarr | Mclay1 15:29, 6 December 2010 (UTC)

I just confirmed that after turning general fixes on. AWB does indeed already add nbsp before units of measurement. I couldn't confirm in my sandbox that it adds nbsp before an endash. But I was unable to fool AWB into adding an nbsp to "At the age of 25 L L Bean published a catalog. He counted computers, 14 in the country at the time." (emphasis added) Since you know as much about this subject as I do, I nominate you to propose the feature. Art LaPella (talk) 21:58, 6 December 2010 (UTC)

I agree with A.di M. here. The advise serves good purpose when used between a numeric value and a unit symbol, to prevent (24,560
lb)
or in dates to prevent occurrences of On July
20, man (anatomically, at least, and unapologetic) set foot on the moon.
If there is some sort of over-use in über-long strings that is actually crippling browsers, then something is way-wrong. Greg L (talk) 00:21, 6 December 2010 (UTC)
Ugh, just as well current guidance isn't carried out by editors to its logical conclusion. I wouldn't like to encourage the proliferation of the nbsp inside date strings. It would render my job of harmonising date formats a veritable nightmare. --Ohconfucius ^¡digame! 03:00, 6 December 2010 (UTC)

I do indeed use AWB to add nbsp or Nowrap to dates, and if that isn't a consensus then please change the guideline. Art LaPella (talk) 03:52, 6 December 2010 (UTC)

Before we deal with this issue, we need to band together and put a viable proposal to Bugzilla (again) for a short-cut keystroke or small set of keystrokes for hard-spaces. Few people are prepared to type in that ugly duckling (how many keystrokes is it, six, and they're such a difficult sequence for the fingers, too). It is the main reason I don't use it much. Tony (talk) 14:54, 6 December 2010 (UTC)

Indeed. See WT:MOS#Nbsp before en dash. Maybe not all hope is lost. :-) A. di M. (talk) 16:12, 6 December 2010 (UTC)

Third, that.--Epeefleche (talk) 17:07, 6 December 2010 (UTC)

No one is required to use advanced techniques to prevent no-wrapping of “November 23" or “71 kg”. They are merely encouraged to do so if they have the necessary skills. There isn’t anything wrong with that.
In addition to the coded non-breaking space, we also have the {{nowrap}} template for editors who have difficulty remembering the &[f**king magic]; syntax of special characters. Given that templates are used all over Wikipedia for a variety of reasons, I can’t imagine why we would want to discourage editors from no-wrapping such things. No next should read like this:

Gamma ray distribution is such that there is a logarithmic decline, with 18
TeV energies being exceedingly rare.

As for something that is even easier to type than   or {{nowrap}}, any alternative needs to be “exemplary”; which is to say, it shouldn’t be a hidden attribute that fails to serve as an example to novices. It is only too easy for Mac owners to type a non-breaking space; it is opion-[spacebar]. But such beasts in the code window look identical to a regular space. All of use learn new techniques by looking at the code others have used. Remember when we did a lot of that as novices? I used to type the Mac-keyboard non-breaking space that all the time when I first landed on Wikipedia. But the trouble is that when novices edit an article in which I might directly type a non-breaking space, they can’t learn by sight and follow by example when the code for 18 TeV and 18 TeV look identical (that latter example is a non-breaking space that I just typed too-easily from my Mac keyboard). So I take the extra one second to type  .

I can’t help but think back to the days of the Holy Wars Of Date Delinking and attendant date auto-formating—bearing in mind that the “autoformating” only benefited 0.001% of Wikipedia’s readership (registered editors who had set their user-prefs). Compared to that nonsense, no-wrapping “18 TeV” and “November 23” is a typographical nicety that benefits all our readership.

Perhaps we can ask the developer gods (even though some of them are particularly arrogant asses who think they can be rude to the mere earthlings who inhabit this venue), to add a non-breaking space and/or the {{nowrap}} template to the Wiki markup pallet. In my standard browser-window width of 1280 pixels, the third row down is only 55% full (just a thought) Greg L (talk) 21:16, 6 December 2010 (UTC)

Plan for smart typesetting: This discussion presumes that Wikipedia will never have simple, smart typesetting. People, please remember that the MediaWiki (1.6) software is in its infancy, as the reason why people are hard-coding &nbsp to compensate for bad typesetting. But, it's not just MediaWiki, it's all of today's clueless computers: HTML markup can handle "<center>" but not understand "<left>" or "<right>" (which it centers between). How utterly clueless is that?!? Of course, we don't want to wrap "1 cm" or "10 m" but also, it would be trivial to not wrap "6 cats" or "1 pi" or "a dog" UNLESS the window was extremely narrow, then the smart typesetting would allow wrapping after a tiny word or numeral (in narrow windows). In a sense, it is the fault of these archaic browsers which choose to wrap "a cat" but not hyphenate a very long word "unintelligent" at the end of the line. Autohyphenation would be trivial for browsers to perform when redisplaying text into narrowed windows, just as auto-nonwrapping is trivial when a tiny word precedes a longer word. Perhaps when computer software went crazy over graphics images, then they became text-stupid, unable to auto-hyphenate long words, and unable to search for dog+cat in the same sentence. It would be trivial for any computer to search the current webpage to find matching sentences (as in "hunt dog+cat"), but today's primitive computers are pathetically backward: searching for only a static text-phrase, not multiple words (as in Google). Each screen window, not the editor, should be choosing whether "6 cm" or "a wiz" should be wrapping or not. Submit a request for the MediaWiki software to wise up, think big, and smart-wrap text to avoid millions of &nbsp being hard-coded as if this were the Dark Ages of Computer Typesetting (oh wait, it is!). Meanwhile, Template:Convert is being changed to not wrap "6 cm" but wrap "66,000 cm" when "66,000" would fit at the end of a short line (with "cm" on the next line). Similarly, smart typesetting would not wrap "a cat" to end a paragraph as a line with one word, "cat". At this point, we want the computer to decide when to insert &nbsp, rather than have editors hard-coding them everywhere, so plan these concepts with smart typesetting in mind. -Wikid77 (talk) 07:26, 7 December 2010 (UTC)

You're preaching to the choir. Art LaPella (talk) 08:18, 7 December 2010 (UTC)

"[T]he MediaWiki (1.6) software is in its infancy"... What? It's over eight years old. A. di M. (talk) 12:05, 7 December 2010 (UTC)

That's a valid point. Perhaps, the term to use should be "juvenile delinquent" - there's a difference between "slow maturation" and software determined have "Peter Pan syndrome" in its functionality. Despite the speed of today's computers (Wikipedia can reformat 320,000 articles within 5 hours), the MediaWiki formatting limits are pitiful: only 40 levels of if-then-else logic are allowed, and we should allow at least 60, if not 200 levels of nested templates and if-else clauses, to enable super-smart templates. It appears that MediaWiki has spent the years providing rudimentary typesetting for 50 obscure languages ("pre-Columbian mumble-speak"), while ignoring the need for the next level of English or German-language typesetting. I suppose we should focus on more typesetting templates: we have {Convert} to typeset conversions, and {val} to typeset numbers, plus others in Category:Formatting templates. So, let's see if we can provide the &nbsp capability by using some short templates, instead. Meanwhile, stop worrying about trivial phrases: no need to avoid "the year" 2010, when there's even a song title, "In the Year 2525". Continuing to ban real-world text is like the people who thought "FEMA trailer" was non-notable, until we revealed there is even jewelry designed to look like them: FEMA-trailer earrings. Focus on bigger issues, and let's organize the templates to help with the major typesetting problems. -Wikid77 (talk) 17:58, 7 December 2010 (UTC)

My point was indeed that if MediaWiki hasn't changed that much in the last 8 years, it's quite unlikely to change that much in the foreseeable future either. (As for templates, yhere's a {{nbsp}}, but it's two keystrokes more than the HTML entity so it solves nothing and the purpose of it eludes me.) A. di M. (talk) 18:14, 7 December 2010 (UTC)

I have created a redirect as template {{j}} to "join" (nowrap) text, as described below. I agree that progress has been slow, but remember Wikipedia did eventually replace the MediaWiki "expand-all preprocessor" in January 2008 with a recursive-descent parser which excludes false branches in template logic. Now a #switch with 300 branches will run 300 times faster when the first branch matches. If someone had said, "Wikipedia templates will be running 100x times faster in 2008", who would have believed it possible? Meanwhile, we can focus on the typesetting templates such as {j}, described below. -Wikid77 (talk) 15:46, 8 December 2010 (UTC)

Redirect j gives quick nowrap of counts/wikilinks

The new redirect {j}, to invoke {{nowrap}}, provides the shortest name "j" (meaning "join") for widespread use to join non-breaking text, wikilinks, money or unit symbols, counts, or numeric formats (for WP:MOSNUM). The template {j} is intended to be used many times, instead of cluttering with numerous " ". For clarity, an optional space can be placed after the name "j" as either: {{j |xx zz}} or {{j|xx zz}}. Some examples:

Earth's distance from the Sun is {{j|"1 [[AU]]"}} officially.
Earth's distance from the Sun is "1 AU" officially.
With new medicines, the disease caused only {{j|9 deaths}}.
With new medicines, the disease caused only 9 deaths.
He joked, "Problems at the UN made him {{j|UN-comfortable.}}"
He joked, "Problems at the UN made him UN-comfortable."
The safari saw {{j|1 [[black rhino]]}}, {{j|7 [[reticulated giraffe]]s}}, but {{j|10,000 [[gnu]]s}} and [[common zebra]]s.
The safari saw 1 black rhino, 7 reticulated giraffes, but 10,000 gnus and common zebras.
The stated force was {{j |"7 ft·lb-per-hour"}}, meaning {{convert|7|ftlb|lk=in}}.
The stated force was "7 ft·lb-per-hour", meaning 7 foot-pounds (9.5 J).

Concerns over name-length (of the template) were in comparison to the length of " " as 5 characters long. However, even a non-breaking space sometimes does not stop wrapping of text with a wikilink, so this template handles that situation of joining text as well. -Wikid77 (talk) 15:46, 8 December 2010 (UTC)

Thanks,Wikid77. Greg L (talk) 16:39, 12 December 2010 (UTC)

Proposal to move details on specific units into a table

We have the following text scattered throughout all the other woolly guidance:

Use nmi (or NM) to abbreviate nautical mile
Use kn to abbreviate knot
Use nautical mile or statute mile rather than mile...
The symbol for litre is written as an upper case L when not preceded by a prefix.
Avoid using the old-fashioned name "degree centigrade"
The symbol for the bit is bit

Guidance like that could be summarised in a table. Most debates on talk pages are about specific units and it would be more helpful to have all of this in one place. Lightmouse (talk) 22:07, 26 November 2010 (UTC)

Proposed table layout:

Name	Symbol	Comment
degree centigrade	°C	A synonym for degree Celsius. May be used in quotations and historical contexts. Otherwise should be replaced by degree Celsius.
fermi	fm	A synonym for femtometre. May be used in <...circumstances...>.
knot	kn
litre (liter in American English)	Use upper case L when not preceded by a prefix. This is to eliminate confusion between a solitary lower case l and the digit 1.
metre (meter in American English)	m
micron	μm	The micron is a synonym for micrometre. May be used in <...circumstances...>.
nautical mile	nmi (or NM). The symbol nm means nanometre.	Use nautical mile rather than mile in nautical and aeronautical contexts to avoid confusion with statute mile

Regards Lightmouse (talk) 09:50, 27 November 2010 (UTC)

The point is to do what the sources do, not to use the SI except in a finite number of circumstances. Thousandths of inch should be used for gauges of guitar strings, not millimetres. Inches should be used for displays, not centimetres; and so on. A long list of cases in which to use non-SI units would 1) be very likely to be incomplete and 2) leave the readers unable to see the forest for the trees. (If someone doesn't know which is the proper unit for guitar string gauges and doesn't know how to find that out, they shouldn't look it up on a long list on WP:MOSNUM: they shouldn't be writing an article about guitar strings in the first place.) A. di M. (talk) 11:54, 27 November 2010 (UTC)

I agree that it shouldn't list all units. However, mosnum contains scattered guidance on specific units. A table would make the existing guidance on those particular units and make it easier to access. Or have I misunderstood you and your suggestion is to delete the existing guidance on 'centigrade', 'litre', 'metre', 'nautical mile', 'knot' etc? Confused. Lightmouse (talk) 14:02, 27 November 2010 (UTC)

I don’t see why, A. di M., Lightmouse should not be able to consolidate information on units. I think we all agree that MOSNUM has slowly evolved into quite a tangle and needs to be rearranged. As Lightmouse wrote, things are scattered all over the place. However, I agree 100 % ;-) with you, A. di M., that a table referencing the rule of SI should not look towards the BIPM’s recommendations any further than has already been done on MOSNUM; that is, a table should take existing guidelines and faithfully reflect what they say. And more to your point, the underlying principle that the table should not undermine is, as you say, what do the sources say. Accordingly, where MOSNUM is silent, the table should remain silent.

Another detail (perhaps this point has already been raised but I don’t see it) is that many of the current guidelines on each of these points has example text to make meaning clear. Either room should be made in the table to encompass all the information and examples, or room should be made immediately below the table to provide notes with the full verbiage. Alternatively, links could be provided below the table directing readers to the full verbiage in their existing locations. Given that this is a hot-button issue, I would propose that the table and accompanying notes or links be run by all here for review before being posted.

Greg L (talk) 16:44, 27 November 2010 (UTC)

P.S. I would propose too, that we limit discussion of the table to one simple point: whether it reflects current intent and meaning and conveys that information in a better manner. Most-everyone around here agrees that better organization is good. What we should certainly reject are any attempts here to exploit discussion of the table to consolidate existing information for the purposes of advancing a new agenda. The current guidelines are the product of vigorous debate—often over protracted periods of time—and the result are compromises that met the consensus view and were thought to best serve the interests of our readership. Precious little of of what is currently in MOSNUM (or none of it) was by accident. The result is a proper balance between those who just want it MY way and The SI Nazis®™© and those who say “just follow current literature.” If we get bogged down with agenda-pushing to get changes and/or new items from peoples’ wish-lists introduced, we will never make progress on simple reorganizations like Lightmouse is proposing. It’s time to put our foot down on that stuff. Greg L (talk) 17:08, 27 November 2010 (UTC)

I don't see why only non-SI usage should be consolidated. The table may be helpful, but all specific MOSNUM recommendations, even where they align with SI or BIPM recommendations, should be listed. This should probably include binary prefixes kibibit and kibibyte, etc. (By the way, do we want to comment on μ as an obsoleted, but potentially used, symbol for micron?) — Arthur Rubin (talk) 17:00, 27 November 2010 (UTC)

With regard to the micron symbol, Arthur, see my PS, above. If the issue is already addressed on MOSNUM, there is no reason we can’t include it. If MOSNUM is silent, then *later* would be a better time to introduce new topics; otherwise, we will never be able to make progress in reorganizing what is currently on MOSNUM into a more coherent structure. Greg L (talk) 17:11, 27 November 2010 (UTC)

I'll comment on that later, if I remember. I agree that the discussion of the micron symbol shouldn't be in this section, but the status of our position on the IEC recommendations probably should be in the table.

I lean toward requesting that Lightmouse not edit the guideline, himself, as he had (note tense) misinterpreted it to read "BIPM ~~only~~ except ...." rather than "use what reliable sources use, which is usually SI/BIPM". Many of his suggestions do constitute an improvement, but WP:BRD is not a good guideline for editing guidelines. — Arthur Rubin (talk) 17:23, 27 November 2010 (UTC)

With regard to your first paragraph, that’s good. With regard to your second paragraph, see the last sentence of my second paragraph of my 16:44 post, above. But, in short: yes, I agree. We will avoid Turkish butt-stabbings, ANI finger-pokes in the eye, and ArbCom inquisitions and the attendant tongue amputations if we all have an opportunity to see and discuss what he is proposing here on WT:MOSNUM before it gets posted to WP:MOSNUM. If we all avoid trying to introduce changes to meaning as he does the heavy lifting, things should go smoothly enough. Greg L (talk) 17:47, 27 November 2010 (UTC)

I can't remember when I last edited mosnum and I'm not intending doing any more editing of mosnum for a while. I proposed the table here because I see it as a major change in format. Good points are being made:

The table shown here is only meant to illustrate the principle of consolidating existing guidance on specific units. This will make it simpler for anyone wanting to check the guidance on a specific unit (a common reason for coming to mosnum). As a consequence, the general guidance section will become shorter and more distinct.
The table should include SI where mosnum varies from the standard. With the recent revisions, we no longer need to say that mega is 'M' not 'm' and watt is 'W' not 'w'. Thus we can get rid of a lot of metric guidance in mosnum.
The table should include non-SI e.g. bit and byte. The more extensive stuff about binary prefixes may be too long to put in there.
The table should be silent where the existing guidance is silent (thus 'fermi' should not have been put in the example). First we need to decide on the table itself. If consensus is that the existing guidance is inadequate e.g. for fermi, kph, μ, then the table is the place where the outcome of a debate is recorded.
The table should be expanded as far as we want and include anything relevant to a specific unit. But in some cases it might be best to have a summary with extensive discussion elsewhere in mosnum. Some of mosnum uses units to illustrate a point and that seems to me to be quite different.
I think it would be good to have a competely different section for all the various thoughts on how to address units that aren't in mosnum or what to do if a debate breaks out somewhere.

Regards Lightmouse (talk) 17:59, 27 November 2010 (UTC)

Most of what you write above is very good, Lightmouse. But I am confused. You wrote, in bullet point #2 as follows: The table should include SI where mosnum varies from the standard. Does that mean that if MOSNUM eschews the BIPM and does not follow the rule of the SI in some regards, the table should include what the SI says? Wouldn’t that be confusing? Greg L (talk) 18:05, 27 November 2010 (UTC) (I’m taking a break for part of the day. Back later.)

Quite the opposite. If MOSNUM eschews the BIPM and does not follow the rule of the SI in some regards, the table should include what the MOSNUM says. The table is simply a new container for existing mosnum guidance. I hope that's clear. Bullet point #2 was addressing Arthur Rubin's comment "I don't see why only non-SI usage should be consolidated". So I said "The table should include SI..." - I meant the table should include existing guidance about "SI units" as shown in the above example. Lightmouse (talk) 18:55, 27 November 2010 (UTC)

I'm not sure that that (M not m) shouldn't remain in the guideline, but it shouldn't be in the table. I appreciate the clarification. Good idea. — Arthur Rubin (talk) 19:06, 27 November 2010 (UTC)

Following the points made above, here's an update. Proposed table layout:

Name	Symbol	Comment	Existing mosnum text (this column will not appear in mosnum)
bit	bit	Other symbols for bit (such as b or B) should be replaced with bit. This is to reduce confusion with byte. Similarly, it is kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc.	"The symbol for the bit is bit, not b."... "By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc."
byte	B or byte	Other symbols for byte (such as b or o (French: octet)) should be replaced with B or byte. This is to reduce confusion with bit. Similarly, it is kB/s (not kBps or KBps) and MB/s (not Mbps or MBps).	"The byte may be represented by either one of the symbols B and byte, but not b or o (French: octet)."... "kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps)."
cubic centimetre	cm³ or cc	The non-SI symbol cc may be used to refer to engine volume e.g. Honda motorcycles engines. The form cc must be linked to cubic centimetre on first use in each article.	"it is cc in an article on Honda motorcycles engines and not cm³"... "Such non-standard units or unit names are always linked on first use."
degree centigrade	°C	A synonym for degree Celsius. May be used in quotations and historical contexts. Otherwise should be replaced by degree Celsius.	"Avoid using the old-fashioned name "degree centigrade" for the degree Celsius, except in quotations and historical contexts."
knot	kn	The symbol 'kt' is reserved for kilotonne. The symbol 'kN' is reserved for kilonewton.	"Use kn to abbreviate knot: kt could be confused with kilotonne; kN could be confused with kilonewton."
litre (liter in American English)	Use upper case L when not preceded by a prefix.	The solitary lower case l is avoided to reduce confusion with the digit 1.	"The symbol for litre is written as an upper case L when not preceded by a prefix. This is to eliminate confusion between a solitary lower case l and the digit 1."..."American spellings of unit names (e.g. meter or liter) should be used on pages written in American English."
long ton	long ton	This unit must always be spelled out in full.	"Use long ton or short ton and not just ton; these units have no symbol or abbreviation and are always spelled out."
metre (meter in American English)	m		"American spellings of unit names (e.g. meter or liter) should be used on pages written in American English."
micron	μm	A synonym for micrometre. A link to micrometre is required on first use in each article. The symbol μ may be used in quotations and historical contexts, otherwise it should be replaced by μm.	"the term "micron" (rather than micrometre) is also still in widespread use in certain disciplines. Such non-standard units or unit names are always linked on first use."
mile per hour	mph		"Exceptions include mph for the mile per hour..."
nautical mile	nmi (or NM).	The symbol nm is reserved for nanometre. Use nautical mile rather than mile in nautical and aeronautical contexts to avoid confusion with statute mile	"Use nmi (or NM) to abbreviate nautical mile rather than nm (nanometre)."
Pound per square inch	psi		"Exceptions include ... psi for pounds per square inch..."
short ton	short ton	This unit must always be spelled out in full.	"Use long ton or short ton and not just ton; these units have no symbol or abbreviation and are always spelled out."
tonne (metric ton in American English)	t	Other symbols (such as mt or MT) should be replaced with t.	"American spellings of unit names (e.g. meter or liter) should be used on pages written in American English." ... "The tonne, 1000 kilograms, is officially known as the metric ton in the US. Whichever name is used, the symbol is t."

There are some more specific units mentioned such as ounces, gallons but I've stopped working on the proposed table for now. Regards Lightmouse (talk) 17:31, 4 December 2010 (UTC)

Such a table, since it is meant to summarise MOSNUM guidance, would need to include units like KB in the decimal and binary sense. It should also make it clear the XiB style is generally not to be used.Fnag aton 11:20, 8 December 2010 (UTC)
- Drive-by comment (I'll be back soon): this looks like a great idea. Tony (talk) 12:45, 8 December 2010 (UTC)

In response to the above discussion, I've added the table. Now that some of the guidance is now in the table, duplicate text scattered throughout the page can be eliminated to reduce the length and complexity of the page. I did some but didn't complete the task. Regards Lightmouse (talk) 16:05, 18 December 2010 (UTC)