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 | Archive 131 | Archive 132 | Archive 133 | Archive 134 | Archive 135 |
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)
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‑10IrHe lifted 10{{nbhyph}}kilogram object
→ He lifted 10‑kilogram objectUntil the age of twenty{{nbhyph}}one
→ Until the age of twenty‑oneHe 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.
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)
) 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)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)
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)
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:
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)
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)
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)
George Washington (1732–1799) was the dominant military and political leader of the new United States of America from 1775–1797…
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)
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)
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)
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.
←(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)
So how about replacing this:
With this (or something like it):
And this would also have to be put in WP:MOSBIO. Herostratus ( talk) 14:44, 21 October 2010 (UTC)
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, ...
If we have the birthdate isn't it because it is published already? Munijym ( talk) 07:27, 27 October 2010 (UTC)
Michael Jackson was a...?
. —
CIS (
talk |
stalk)
15:17, 5 November 2010 (UTC)(N.B.: comments after this point were made after the "Standing as of December 1 2010" section, below, was written)
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:
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)
Our current guideline says:
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)
–
", 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)
–
", 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)
–
? 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)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)
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)
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)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)
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)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.
For the election coordinators, Tony (talk) 02:46, 4 December 2010 (UTC)
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:
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:
Does anyone anticipate any problems which might arise from use of symbol MMbbl? - Wikid77 ( talk) 00:14, 1 December 2010 (UTC)
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. | ” |
…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)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)
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:
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)I ran a database search and found only 11 articles using 'MMBBL' (upper or lower case). Of those
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)
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)
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)
We have the following text scattered throughout all the other woolly guidance:
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. |
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 |
|
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 |
Regards Lightmouse ( talk) 09:50, 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)
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)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:
Regards Lightmouse ( talk) 17:59, 27 November 2010 (UTC)
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)
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 | cm3 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 cm3"... "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. |
"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 |
"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)
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)
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)
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.
Aliens on planets 50 Mlyrs away wouldn’t write so abstrusely. ;-)
Greg L ( talk) 02:59, 4 December 2010 (UTC)• 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.
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.
• 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.
• 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)
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)
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)
• 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.
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)I suspect we are developing a clear consensus that just because chemists see We added ca. 200 ml H2O 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)<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)<span title="or thereabouts">c.</span>
(= c.) seems to work better. --
Michael Bednarek (
talk)
03:16, 7 December 2010 (UTC)
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)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:
Regards Lightmouse ( talk) 12:19, 5 December 2010 (UTC)
lb)
or in dates to prevent occurrences of On July20, 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)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.
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
.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   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   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  , 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)
{{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)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:
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)
We have the following text scattered throughout all the other woolly guidance:
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. |
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 |
|
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 |
Regards Lightmouse ( talk) 09:50, 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)
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)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:
Regards Lightmouse ( talk) 17:59, 27 November 2010 (UTC)
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)
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 | cm3 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 cm3"... "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. |
"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 |
"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)
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)
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 | Archive 131 | Archive 132 | Archive 133 | Archive 134 | Archive 135 |
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)
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‑10IrHe lifted 10{{nbhyph}}kilogram object
→ He lifted 10‑kilogram objectUntil the age of twenty{{nbhyph}}one
→ Until the age of twenty‑oneHe 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.
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)
) 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)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)
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)
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:
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)
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)
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)
George Washington (1732–1799) was the dominant military and political leader of the new United States of America from 1775–1797…
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)
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)
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)
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.
←(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)
So how about replacing this:
With this (or something like it):
And this would also have to be put in WP:MOSBIO. Herostratus ( talk) 14:44, 21 October 2010 (UTC)
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, ...
If we have the birthdate isn't it because it is published already? Munijym ( talk) 07:27, 27 October 2010 (UTC)
Michael Jackson was a...?
. —
CIS (
talk |
stalk)
15:17, 5 November 2010 (UTC)(N.B.: comments after this point were made after the "Standing as of December 1 2010" section, below, was written)
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:
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)
Our current guideline says:
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)
–
", 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)
–
", 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)
–
? 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)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)
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)
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)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)
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)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.
For the election coordinators, Tony (talk) 02:46, 4 December 2010 (UTC)
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:
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:
Does anyone anticipate any problems which might arise from use of symbol MMbbl? - Wikid77 ( talk) 00:14, 1 December 2010 (UTC)
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. | ” |
…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)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)
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:
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)I ran a database search and found only 11 articles using 'MMBBL' (upper or lower case). Of those
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)
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)
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)
We have the following text scattered throughout all the other woolly guidance:
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. |
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 |
|
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 |
Regards Lightmouse ( talk) 09:50, 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)
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)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:
Regards Lightmouse ( talk) 17:59, 27 November 2010 (UTC)
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)
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 | cm3 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 cm3"... "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. |
"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 |
"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)
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)
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)
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.
Aliens on planets 50 Mlyrs away wouldn’t write so abstrusely. ;-)
Greg L ( talk) 02:59, 4 December 2010 (UTC)• 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.
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.
• 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.
• 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)
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)
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)
• 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.
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)I suspect we are developing a clear consensus that just because chemists see We added ca. 200 ml H2O 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)<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)<span title="or thereabouts">c.</span>
(= c.) seems to work better. --
Michael Bednarek (
talk)
03:16, 7 December 2010 (UTC)
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)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:
Regards Lightmouse ( talk) 12:19, 5 December 2010 (UTC)
lb)
or in dates to prevent occurrences of On July20, 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)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.
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
.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   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   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  , 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)
{{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)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:
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)
We have the following text scattered throughout all the other woolly guidance:
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. |
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 |
|
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 |
Regards Lightmouse ( talk) 09:50, 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)
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)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:
Regards Lightmouse ( talk) 17:59, 27 November 2010 (UTC)
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)
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 | cm3 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 cm3"... "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. |
"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 |
"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)
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)