Jump to content

Wikipedia talk:Manual of Style/Dates and numbers

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:Manual of Style

This is an old revision of this page, as edited by Headbomb (talk | contribs) at 12:20, 3 May 2008 (→‎Minor Request). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

edit
Archive
Years and dates archives

Concern: commas and dates

MOS:DATE#Dates (or any other section I'm aware of) does not clarify that commas have to be inserted for full dates which are wiki-linked. Example; a comma automatically appears in February 14 2008 (see the linked [[February 14]] [[2008]] here, note that it does not for February 14 2008 and February 14 2008). In other words, if the date is linked, the comma is visible to viewers even though it is not edited into the context. So, can someone see the logic in this revert? To me, this is like placing the |right| to an image which already has a mark-up like |frame| or |thumb| which sets the image to the right by default. My proposal — the guideline should say that a comma does not need to be inserted for a correctly linked date. Is this understandable? Lord Sesshomaru (talk • edits) 02:52, 5 March 2008 (UTC)[reply]

See also Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_94#Commas_in_linked_dates. Some people still don't realize a comma is added in [[February 14]] [[2008]] (February 14 2008), and removed in [[14 February]], [[2008]] (14 February, 2008), even for IP editing. The revert was based on a misunderstanding. Gimmetrow 03:03, 5 March 2008 (UTC)[reply]
So you agree that these things should be mentioned in the guideline? Lord Sesshomaru (talk • edits) 03:08, 5 March 2008 (UTC)[reply]
I can agree with saying a comma does not need to be inserted with the [[February 14]] [[2008]] format, but I'm less clear on recommending it. No comma seems to confuse editors. With [[14 February]], [[2008]], I think the comma should be removed and not restored, since MediaWiki removes it anyway for viewing, but editing solely for this would be a trivial edit. Gimmetrow 03:30, 5 March 2008 (UTC)[reply]
The guideline doesn't say that is HAS to be added, but it also doesn't say it HAS to be removed. If the comma is optional, the guideline probably should note that, but I don't think that should be a justification to remove them. Does having the comma there cause any actual problems? If not, when doing February 14, 2008, why remove the comma? It seems like a personal editing preference, and not one that needs to be "corrected" unless there is an actual reason to do so. Collectonian (talk) 03:35, 5 March 2008 (UTC)[reply]
This argument is a bit pointless. When a complete date is wikilinked, it will always display correctly—for the American style the comma will be inserted where it is not present. The opposite applies for British style, where the comma is deleted if present. This applies also for unregistered users. But mention should be made of this somewhere to prevent unnecessary editing. I had a discussion about this before (here) and still have the test in my sandbox (if anyone's interested be sure to switch of dates preferences beforehand). TINYMARK 04:07, 5 March 2008 (UTC)[reply]
It's just like the image sample I cited: why add |right| if |thumbnail|, |frame|, etc., already does the job? It's past redundant. Therefore, the guideline should make note of this. Do we have an agreement? Can this be indicated in the guideline now? Lord Sesshomaru (talk • edits) 04:17, 5 March 2008 (UTC)[reply]
I'd link to see an alternative way of formatting dates than using double brackets ([[ ]]). The problem I see lies in there not being consensus on how dates should appear (American vs international), leading to a system where user preferences can be set to recognise and format all dates marked in a certain way. Fine, up to a point. However, in using the article linking mechanism, dates are being linked left right and centre, when there is no real reason to - many dates in articles have no great historical significance, and do not even warrant a mention in the linked date article. Nevertheless, there appear to be editors who spend most of their time manually making these links. This labour-intensive and overlinking to dates and years articles (just check their backlinks and you will see what I mean - there are well in excess of 20,000 articles linked to January 1 alone), and the paranoïa apparently associated with it drives me nuts. Ohconfucius (talk) 05:15, 5 March 2008 (UTC)[reply]
You're absolutely right. There should as well be a section on which layout is preferred. That'll be hard to decide, albeit there really isn't a standard preference, it'll have to be one or the other. Lord Sesshomaru (talk • edits) 05:34, 5 March 2008 (UTC)[reply]
What we should not be doing is what you did in your original post, Sesshomaru. Don't link February to the article on the month, link 14 (meant to be the day of the month) to article on the year AD 14 and 2008 to article on the year AD 2008. That's already covered in the MoS, isn't it?
Our standard "look and feel" is the results we get from dates properly formatted for user preferences. There is no preference from among those options, if that's what you are talking about. It is best to enter it the way it appears, but the missing or extra comma we are talking about there won't make much difference in the results, and in not in itself reason to edit an article.
Yes, the software will fix some of the problems even for users who are not logged in. I used to think, after the software started acting that way, that it no longer mattered if a linked-for-preferences date was linked as "[[January 15]], [[1961]" or "[[January 15]], [[1961]", but if I recall correctly, somebody pointed out some case in which it does make a difference. But maybe I just imagined that, I cannot tell you what it would be. Gene Nygaard (talk) 15:18, 5 March 2008 (UTC)[reply]
Not quite sure if you're upset or bothered by anything Gene. I was making a simple point about the comma in those samples. In any case, shall I update this page per discussion or are there any opposing? Seems to be legit. However, I'll refrain from mentioning how dates should appear, American vs international-wise, since that would require a separate section. Agreed by all parties? Lord Sesshomaru (talk • edits) 16:55, 5 March 2008 (UTC)[reply]
If I understand your point, and going by what you were edit-warring about, we most certainly should not be saying not to use commas on the edit page, in places where they would normally appear in what readers see on the article page. Why in the world are you even asking for that? Gene Nygaard (talk) 17:51, 5 March 2008 (UTC)[reply]
Edit warring? What in the world are you talking about? Lord Sesshomaru (talk • edits) 18:04, 5 March 2008 (UTC)[reply]
Okay, I take that back; not edit-warring. It was just a first impression, when you were complaining about someone's reversion of your edit removing commas from the Month DD, Year format. I don't think you have any cause for complaint; we should not be running around removing the commas. That's the point I'm trying to get across. Gene Nygaard (talk) 18:31, 5 March 2008 (UTC)[reply]
Compromise: how about having the guideline say something like, "commas for the [[February 14]] [[2008]] format do not need to be inserted since they are visible even without them in the edit."? Implying not to use commas no matter the circumstance is a tiny bit irrational, I guess. This makes sense? Lord Sesshomaru (talk • edits) 18:52, 5 March 2008 (UTC)[reply]
Okay. I'll do the compromised edit to the guideline tommorrow. Any additional comments? Lord Sesshomaru (talk • edits) 06:04, 8 March 2008 (UTC)[reply]

(deindent) Make sure to note that just because they are not needed is no reason to run around removing them from existing articles. Collectonian (talk) 21:13, 10 March 2008 (UTC)[reply]

I think I know why you're saying this. You don't want the commas removed in pages that you heavily edited, like List of Star Ocean EX episodes? Can I ask why? If someone has enough spare time on their hands, I don't see why they should not run around and get the job done. It's optional. Thoughts? Lord Sesshomaru (talk • edits) 21:28, 10 March 2008 (UTC)[reply]
I'd have thought the reason is obvious. Do you want to see your watchlist explode ?? ;-) TINYMARK 21:34, 10 March 2008 (UTC)[reply]
You're right, I don't. I see no point to it. I find it rather annoying, as it isn't needed or useful at all. If people have time on their hands, I'd rather them do something that actually improves the articles rather than just do such an extremely meaningless edit. It would be one thing if removing the commas actually fixes anything, but it doesn't. Even tag and go is more useful than stripping out the commas. Its about as pointless an edit as one can get. And, as TinyMark notes, it is another watchlist addition that gets to be doubly annoying when someone comes along, is editing, noticing there are none, and feels they need to fix it. I also find the code looks very ugly without the commas and I think it would be very confusing to anyone who doesn't understand that the commas are not needed (a good chunk of editors, I'd suspect). Maybe I'm an anal web developer, but I seriously abhor ugly code :P Collectonian (talk) 21:51, 10 March 2008 (UTC)[reply]
I don't really think the layman will assume that a comma is missing (that's what the preview button is for). But I see both of your points. What about the dates in pages that already have no commas? Are you two suggesting that the commas should be inserted because the layman will think they are missing and will "explode" one's watchlst? Lord Sesshomaru (talk • edits) 22:10, 10 March 2008 (UTC)[reply]
If any article is already without commas, then no need to insert either. So my basic position is, if they are there, leave them there, if they aren't, leave them out, though if a newbie editor comes alongs and adds them because they think they are missing, no need to yell either (though feel free to undo and explain). Its kind of like referencing, I guess. If a valid referencing style is already in heavy use (such as Harvard referencing), don't run through and completely redo to your preferred referencing style (maybe using templates). In the case of citation styles, Wikipedia:Citing sources includes language regarding that:
"Any style or system is acceptable on Wikipedia so long as articles are internally consistent. You should follow the style already established in an article, if it has one; where there is disagreement, the style or system used by the first editor to use one should be respected."
Perhaps something similar would work here? Collectonian (talk) 22:26, 10 March 2008 (UTC)[reply]

I guess that could work, but what about Death Note? Some dates there have a comma, others do not. And if someone comes along and removes the commas while doing other good faith edits, like I did here, one should not revert blindly or undo only the removal of the commas, as that seems to be a case of Wikipedia:Ownership. So can we integrate what I just said into the guideline as well? Lord Sesshomaru (talk • edits) 22:37, 10 March 2008 (UTC)[reply]

For Death Note, if we use the citation guideline, then whichever was used first should be kept and the rest changed to match. As for the Star Ocean issue, well, as has already been noted, removing wasn't necessary. The list was created with them (first editor to use), and that shouldn't have been changed. Your other good faith edit (only one other thing) was put back. Collectonian (talk) 01:09, 11 March 2008 (UTC)[reply]
So how should it be written in the guideline? I know what to include, but don't know how to phrase it. Any thoughts or suggestions? Lord Sesshomaru (talk • edits) 01:18, 11 March 2008 (UTC)[reply]
I think a slight modification of the quote from cite, retooled to dates, would be fine. So something like: "Commas are not required to be used in full format American dates. Their inclusion or exclusion is a stylistic and editorial preference. Either style is acceptable so long as articles are internally consistent. You should follow the method already established in an article, so that if the article has dates with commas, then the commas should be left alone and new dates added to the article should have commas. If the dates in the article do not have commas, then they should not be added to existing dates and new dates should not have them. Where there is disagreement or the article currently has a mix of commas and no commas, then the earliest format used should be respected and the article changed to be consistent with that format." Collectonian (talk) 20:02, 11 March 2008 (UTC)[reply]
Sounds great! I noted that the Death Note page first used commas, then some were removed. I shall correct this problem soon. Okay, go ahead and update the guideline, would you? Lord Sesshomaru (talk • edits) 20:08, 11 March 2008 (UTC)[reply]
The page is currently edit protected, so before I put in an editprotected request, does anyone else want to comment on this? Collectonian (talk) 04:04, 12 March 2008 (UTC)[reply]
Go for it. Seems we have concluded. Lord Sesshomaru (talk • edits) 20:09, 12 March 2008 (UTC)[reply]
Added. I wasn't completely sure where to put it, so I put it in the section on full date formatting. If someone feels it should be positioned differently, feel free to shift around.Collectonian (talk) 17:57, 13 March 2008 (UTC)[reply]

Section break

This has not been thought through. It is not necessary or even useful to have a different standard for articles that pertain to American topics. If I am editing a section of an article on a clearly British topic to correct a misspelled word, and then also see a mess like "happened on the 14<sup>th</sup> of Sept [[1777]]", I can simply change it to "happened on [[14 September]] [[1777]]". If I see this in a section of an article on a clearly American topic, I would, according to these new instructions. need to:

  • get out of edit mode on that section.
  • view or edit the entire article, examining it to see if there are any dates in either of 2 formats, [[July 4]], [[1776]] or [[July 4]] [[1776]].
  • if there are none, pick one format and use it for the mess I found.
  • if all other dates are in one of those 2 formats, use that format to fix the messy date.
  • if there are several dates in each format, spend half the afternoon digging through the revision history trying to find the revision that first introduced one of these 2 formats, and use that format to fix the other dates that were added since, and the messy date.

If this strikes anyone as an unrealistic burden to throw on the back of editors who are trying to clean up articles on American topics, I agree and sympathize with you completely. Before the manga edit skirmish began, we had 2 formats: [[July 4]], [[1776]] or [[4 July]] [[1776]], for west of the Atlantic and east of it. I feel that adding a 3rd format and encouraging its use (just because it is known that the software will fix it for general display) detracts from Wikipedia. I will remove that recommendation from the guideline. An agreement between two editors doesn't constitute much of a consensus. Chris the speller (talk) 18:19, 19 March 2008 (UTC)[reply]

No one is saying anything about adding a 3rd format. The article already says you can use [[July 4]], [[1776]] or [[July 4]] [[1776]]. The paragraph just clarifies that people shouldn't go around removing all the commas in an article because the comma isn't needed, nor should they be added in, rather as with sources, stick with the method already in use in the article. Collectonian (talk) 18:35, 19 March 2008 (UTC)[reply]
Your statement is completely incorrect. Nowhere does the guideline say that [[July 4]] [[1776]] is an acceptable format. Please remove that paragraph or allow me to remove it again. Chris the speller (talk) 20:40, 19 March 2008 (UTC)[reply]
It is shown in the table lower in the page. Personally, I agree, but as other editors have used this guideline to say commas are not required and have removed them (and not just the case noted here), something should be added to clarify. The paragraph is an attempt to do so. Do you have another suggestion for a better way to deal with it? Collectonian (talk) 20:46, 19 March 2008 (UTC)[reply]
I think you will see that I am on your side if you read the discussion "Commas in linked dates" in Archive 94 of this talk page. Back then I was afraid that including "[[May 15]] [[2005]]" in the table would lead to some editors to think that it was an acceptable format, but there was an insistence on leaving it in to provide a complete list of formats that the autoformatting software could or could not handle. You have shown that my fears were justified. The omission of the comma has come up several times, but a consensus to allow dropping it has never been achieved. My last comment in that discussion clearly shows that I opposed editing just to remove a comma from the British-style dates, so I wholeheartedly oppose removing them from American-style dates. The removal of commas from the manga article was not only a waste of time for that editor and a waste of Wikipedia resources, but turned into a further burden on those taking part in discussions here. I kept getting beat up about that table and the green check marks and red X's. If you want to support adding a couple of red X's to that table instead of the 2 wimpy asterisks, maybe we can get this cleared up. Chris the speller (talk) 21:55, 19 March 2008 (UTC)[reply]
That might be a good idea, and I could see it being cleaner than the paragraph addition. I'd support making it clearer for sure. Collectonian (talk) 22:22, 19 March 2008 (UTC)[reply]
What do you think of the green checks and red X's that were in the table here? Never mind that the legend below it is inaccurate in this version. Would something like this work to show what formats are acceptable? Chris the speller (talk) 01:20, 20 March 2008 (UTC)[reply]
I think that would work. It makes it clearer what formats are acceptable and much easier to quick read. Collectonian (talk) 01:23, 20 March 2008 (UTC)[reply]

How about adding green check marks on the left of the table, just for the two formats that are accepted by the MOS? Red X's are already used on the right to indicate what will display as a dead link. Chris the speller (talk) 15:30, 26 March 2008 (UTC)[reply]

Section break 2

Totally different perspective (on original issue raised in this thread): The comma absolutely must be used in the [[February 29]], [[2007]] format (and never in the other). The geeky reason is that the entire web has been evolving for over a decade now toward the complete separation of content and presentation markup, and this violates that principle. The more practical and immediate WP reason is that, as most of you know, Tony1 and others have been working hard to raise awareness of the absolute suckitude of the current date formatting system, with the eventual badly-desired result of removing the [[...]] markup that causes the dates to be wikilinked for no reader-useful reason, to be replaced by something as yet undetermined. It is very likely in my opinion that the developers will eventually fix this with an "intelligent" solution that auto-parses correctly formatted dates on-the-fly, in precisely the same way that it auto-parses correctly formatted cases of ISBN followed by an ISBN number, rather than introduce some wacky new markup that no one understands ($#$February 27 2008$#$ or whatever). I'd bet real-world money on it. If I'm right, potentially millions of dates will not be auto-formatted because MOSNUM will have told editors they can be lazy and omit the commas, resulting in malformed dates when the square-brackets are removed for implementation of the new date coding system. For this reason, I correct cases of [[February 29]] [[2007]] on sight. PS: The idea of "oh, well, the smart autoparser can just recognize that format too" does not fly, because WP is open content, meaning that it can be reused in any way that people want, including selectively downloading the wiki, not HTML source and stripping out what they don't like and reworking it; we have no guarantee at all that the MediaWiki parser will be used in any particular case of legitimate re-use of WP content. We cannot permit invalid content just because we're lazy and we assume (in some cases falsely) that tricky aspects of the MediaWiki code transmogrification process will compensate for our errors. By way of analogy, it would be trivial for the MW developers to install code that corrected on-the-fly all instances of "hte" and "corect" so that they were spelled correctly by the time the code was rendered in the browser window, without actually correcting these errors in the source code. No way, José. We have bots (and humans) correcting the source for a reason. This is why you will probably notice plenty of people going around and correcting cases of <br> to <br />. It simply doesn't matter that MW is smart enough to send the latter to the browser on-the-fly without correcting the source. The source has to be clean. A very probable (maybe already common!) use case for repurposing WP content is to get the WP database, load it into a customized instance of MW, remove all unwanted templates, subst all the rest of them with a bot, and replace all wikimarkup with its XHTML equivalents, then export the resulting lovely, validating XHTML code to a completely different kind of server. Not correcting <br> and not fixing [[February 29]] [[2007]] in the wiki code itself is going to really screw up that kind of WP content re-use. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:07, 5 April 2008 (UTC)[reply]

I agree with SMcCandlish that dates formatted like February 29, 2008 should have a comma, because to drop the comma is incorrect, and dates should appear correct to those who do not set any date format preference. I do not agree that dates which totally lack markup will ever be formatted automatically. One obstacle is dates within direct quotations; these should not be reformatted. Another obstacle is cases where the number following the month and day is not a year, but some other quantity. To make up an example, "The number of prisoners taken on February 28 was 2000, and on February 29, 2500." --Gerry Ashton (talk) 01:31, 5 April 2008 (UTC)[reply]
Trivial. Unusual cases like that would be handled in exactly the same way as us not wanting to autowikilink in a quotation that read "...I thought it was ISBN 978-1-59874-011-0 but it wasn't...". Just do this: "...I thought it was <nowiki>ISBN 978-1-59874-011-0</nowiki> but it wasn't...", which renders as "...I thought it was ISBN 978-1-59874-011-0 but it wasn't...", as it should. We do this stuff all the time, like when you need to italicize something that begins with an apostrophe, etc., etc., etc. — SMcCandlish [talk] [cont] ‹(-¿-)› 05:50, 5 April 2008 (UTC)[reply]

SMcCandlish is right on the mark: we should not count on questionable MW software to correct our sloppiness. I have added green check marks to the table to show what is approved by this manual. Chris the speller (talk) 18:05, 7 April 2008 (UTC)[reply]

My clarification of the table has been reverted twice, on aesthetic grounds. Apparently, not offending one editor's tastes is more important than having a guideline that avoids confusing many editors. I am walking away from this one. In fact, I will now unwatch this discussion page, which has had the benefit of a few very thoughtful and eloquent editors, but has also seen them nearly drowned out by hordes of people intent only on pushing their own personal tastes. This has taken far too much of my time, and I will be happier improving Wikipedia articles than trying to wade through all the bickering. Those who stay and continue trying to make this guideline useful have my best wishes. Chris the speller (talk) 04:12, 9 April 2008 (UTC)[reply]
  • Chris the speller: I’m sorry to see you go. I haven’t been involved in this discussion thread. I only became interested because of the post at the very bottom of this page (∆ here) talking of “awful kindergarten graphics”. That of course, made me curious. Which page? This discussion page? I had to search to find out that the “kindergarten graphics” being referred to was check marks: …which you used in a table. They didn’t seem bad to me and you certainly didn’t deserve the smack down you received.

    I encourage you, Chris, to come on back and get back into the saddle soon after the sting wears off. I really think MOSNUM needs an infusion of new blood. I’m not suggesting that there is anything wrong with the current “regulars”—not at all; we need old-timers to help keep us on track and explain history to us so we aren’t doomed to repeat past mistakes. On the other hand, I think it was wrong for a new arrival to get so soundly stomped on over such a trivial issue as the relative aesthetics of a checkmark. One of the editors posted this for their edit comment when he/she deleted your check marks: “removing yet more ugly check marks; approved by who?” Someone please correct me if I’m wrong here, but anyone can make minor edits on MOSNUM. Yes, like anything else on Wikipedia, those changes can always be reverted when another editor disagrees. But I don’t think Chris needed “approval” from one of the regulars around here to add them.

    May I suggest we try to be a bit more accommodating to outsiders here? I think Chris the speller is feeling a bit like the first female firefighter to try to join the NY City Fire Department: more than a bit unwelcome. Only, what is at stake here isn’t as important as the physical ability of a firefighter to “carry a 200-lb mayor out of a burning building”. Talk:MOSNUM is a market for the exchange of thought. I hate to sound like a University poster-boy for politically correct slogans, but some extra diversity of opinion can be very helpful on MOSNUM and we need to help newcomers to feel welcome. If there was more “history” to this spat than is apparent and this issue was just a “straw that broke the camel’s back” so to speak, I apologize for interceding without having researched this better. But at this point, I’m just not seeing a good justification for what lead up to Chris calling it quits on MOSNUM. Greg L (my talk) 05:04, 9 April 2008 (UTC)[reply]

We already had this discussion in early February after I pointed out the table showed the wrong rendered formats for the comma cases. Chris the speller then placed red checkmarks with the comma cases, which I removed since they do render to one of the standard date formats, and we came to an agreement to have the double-asterisk ** note. Or so I thought. Sorry for being a bit abrupt, but I was surprised when the same edit appeared a couple days ago claiming some forms were now "approved".

I think it's a bad idea to list "approved forms" for wikitext. If it doesn't concern appearance, it shouldn't concern the Manual of Style, which is a guide for the style and formatting of articles as they are read. The MoS discusses wikitext occasionally to note alternatives producing the same rendered page, such as either one or two spaces after a period. As far as I know, we don't have MoS pages telling people to only use one space, or to write <br />, or to format cite templates with one field per line, or to use cite templates rather than hand-written references. Or do we now? Gimmetrow 07:26, 9 April 2008 (UTC)[reply]

  • No, you didn’t come across as abrupt at all Gimmetrow; thanks for taking the time to fully explain this. As I feared, this was a “tip of the iceberg” issue. It seemed a lot more trivial than that due to SandyGeorgia’s post, which read “I just tried to remove some awful kindergarten graphics from this page, but edit conflicted with Gimmetrow, who beat me to it. Please, this isn't a picture book, and we don't need these illustrative gimmicks.”. As you can imagine, given that post, and your recent edit summary statement, the conflict seemed much more superficial—and unwaranted—than it really was. Greg L (my talk) 16:07, 9 April 2008 (UTC)[reply]
I really wish I hadn't dewatched listed this now. Can't this be made clearer in the guideline, some how. The issue of comma stripping is again coming up, now on Ballad of a Shinigami in which an editor decided he needed to "clean up" the article by stripping out all of the commas from the dates. It isn't superficial and it is increasingly becoming a problem as editors claim they are unnecessary due to auto-formatting while others point to the MOS and say they should be included, but the MOS is so ambiguous they argue it isn't said explicitly and just keep doing it. Collectonian (talk) 01:44, 11 April 2008 (UTC)[reply]
Looking at Ballad of a Shinigami, I want to know why American format dates are used for a non-American subject. International format would appear far more appropriate. --Pete (talk) 02:19, 11 April 2008 (UTC)[reply]
Per the MOS, Japan uses both, so its up to the editor. "Articles on topics with strong ties to a particular English-speaking nation should generally use the more common date format for that nation; articles related to Canada may use either format consistently. Articles related to other countries that commonly use one of the two acceptable guidelines above should use that format." The consensus in the project (and this MOS) is to use whichever format was first used, either American or International. In almost all cases, American is first used for articles on anime and manga, so that is what almost all use. Collectonian (talk) 02:22, 11 April 2008 (UTC)[reply]
Not to mention that the primary material (light novels) and anime are released internationally, the novels in North America, the anime via online (though only available to Australia/New Zealand I believe).--十八 02:26, 11 April 2008 (UTC)[reply]
It's silly to edit just to change the wikitext when it has no effect on display. It might have been best if the MediaWiki software had never started adding/removing commas and spaces automatically. Gimmetrow 18:38, 12 April 2008 (UTC)[reply]

Next try

It's been a while so perhaps things have settled, and I've asked Chris the speller back. I think our goals are not incompatible. I mainly want these edits (switching commas around in wikilinked dates) to stop, and I think the solution is to redesign the table more substantially.

We should just list the basic forms which produce autolinking. When discussing the redlink forms there is no need to show how they look under different format prefs since they don't change. Finally, observe that some variations in commas and spacing in the wikitext produce the same rendered forms, and there is no need to add or remove commas. I would even go so far as to say if there is any dispute about the wikitext, it should match the displayed form. I'm seeimg some editors even removing *spaces*: [[1 January]][[2001]] and [[January 1]][[2001]] render as 1 January2001 and January 12001. This needs to stop. Gimmetrow 04:26, 18 April 2008 (UTC)[reply]

Can you make the suggested changes to the table and put it in a subpage, maybe one of yours, so we can take a look? Chris the speller (talk) 04:53, 18 April 2008 (UTC)[reply]

Adding below. The table currently live on the page is mistaken in how [[15 May]] is rendered under different preferences. Gimmetrow 05:26, 18 April 2008 (UTC)[reply]

The table looks fine. The note that it will "display [[May 15]] [[2005]] as May 15, 2005 even for users not logged in" seems one-sided, as it does not point out that it will also "display [[15 May]], [[2005]] as 15 May 2005 even for users not logged in." The extra comma on one side of the Atlantic is equal and opposite to the missing comma across the pond. And saying that the "comma is optional in this case" gives too much encouragement to editors who would like to depart from the formats that have been approved. As pointed out above by SMcCandlish, "we have no guarantee at all that the MediaWiki parser will be used in any particular case of legitimate re-use of WP content". Chris the speller (talk) 15:58, 18 April 2008 (UTC)[reply]
That's because it's just one example. If you don't like it, suggest a different way to phrase it. Gimmetrow 23:00, 18 April 2008 (UTC)[reply]
OK, see my proposed wording below. Chris the speller (talk) 00:56, 29 April 2008 (UTC)[reply]
Chris, you seemed to argue that the comma was needed because there's no guarantee that any re-use will use the MediaWiki parser; are you saying you now don't like Stanton's argument at #Section break 2? - Dan Dank55 (talk)(mistakes) 03:05, 29 April 2008 (UTC)[reply]
(moved Dank55 comment from draft section to consolidate the discussion) - I don't see any comment by Stanton in that section. Chris the speller (talk) 14:46, 29 April 2008 (UTC)[reply]
Sorry; Stanton is SMcCandlish. P.S. Glad to see you back, I always enjoyed your comments. - Dan Dank55 (talk)(mistakes) 21:36, 29 April 2008 (UTC)[reply]

Draft

What you type What logged-in registered users see (settings on first row) What others will see*
-- January 15, 2001 15 January 2001 2001 January 15 2001-01-15 No preference --
[[May 15]] May 15 15 May May 15 May 15 May 15 May 15
[[15 May]] May 15 15 May 15 May 15 May 15 May 15 May
[[May 15]], [[2005]] May 15, 2005 15 May 2005 2005 May 15 2005-05-15 May 15, 2005 May 15, 2005
[[15 May]] [[2005]] May 15, 2005 15 May 2005 2005 May 15 2005-05-15 15 May 2005 15 May 2005
[[2005-05-15]] May 15, 2005 15 May 2005 2005 May 15 2005-05-15 2005-05-15 2005-05-15
* Non-registered users and registered users not logged in
  • The year should be wikilinked separate from the date except for dates in ISO 8601 format. Other full date formats will not autoformat when wikilinked, and are likely to produce a redlink: [[2005 May 15]] produces 2005 May 15.
  • MediaWiki allows some variation in spacing and comma. For example, [[May 15]] [[2005]] will display as May 15, 2005 even for users not logged in. Although the comma is supplied by the MediaWiki software in this case, it need not and should not be removed from the wikitext. Wikitext which differs from the displayed form can be confusing to editors. It is also improper to edit an article solely to insert a comma in such a case. Likewise, do not edit solely to remove a comma from [[15 May]], [[2005]].

{{delimitnum}} template

Note that if this section becomes structurally complex, with many different sub-discussions and threads, I will, where necessary to avoid confusion, take the liberty of rearranging things here after-the-fact (after people have responded). However, I will do so in ways that makes it clear who was responding to what. I think this will be necessary to keep this topic organized and understandable.

I thought everyone would be interested to know that another of our regular editors, Zocky visited Kilogram and saw all my cumbersome code (like 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>(30)&nbsp;×&nbsp;10<sup>23</sup>&nbsp;kg), which was all just for generating numbers like


So he created a template, {{delimitnum}}, and now all editors need to code is {{delimitnum|6.02246479|30|23|kg}} to accomplish the exact same thing. This is the issue many of us discussed here at Archive #94 of Talk:MOSNUM. In a nutshell though, this template parses as follows:

{{ template name | significand–delimiting | uncertainty | base–ten exponent | unit symbol}}

The advantage of this template is twofold: values with long strings of digits to the right of the decimal marker will 1) now be delimited with thin gaps (so they are much easier to parse), and 2) the spaces aren’t characters so the values can be copied and pasted into programs like Excel, where they will be treated as true numbers.

The Natural logarithm article (first paragraph) and Kilogram (throughout, with 2 kB of savings) have both been updated with this template.

What Zocky did is quite an accomplishment because other template authors said a function this complex couldn’t properly be done with a template and really required a parser function (magic word). Indeed, the effort was not at all trivial; Zocky invested a great deal of effort to get the template bug free. In fact, I created a special proof-checking sandbox here on my talk page to assist him in his effort.

As far as I know, it should be extraordinarily simple to convert articles that use Zocky’s template to one that uses the parser function once it becomes available; perhaps just a global search & replace to exchange a pipe (|) for a colon (:).

My main purpose here is to alert you all to this parallel effort (a template vs. a parser function) and to let you know it is now available for use. Perhaps now would be a good time to begin discussing a formal MOSNUM policy regarding the use of the template. I propose the following:

Per current MOSNUM policy, numeric values must have the integer portions of their significand (the digits to the left of the decimal marker) delimited with commas and the decimal marker must be a full stop (.), e.g. 1,234.567. Further now, the use of the {{delimitnum}} template/parser function (magic word) is “encouraged” and is the “preferred” method for delimiting numeric strings with five or more digits in the fractional portion of the significand (the digits to the right of the decimal marker). The use of {{delimitnum}} delimits values like 6.022461342 so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as Excel-pasteable numeric values.

In furtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or non-breaking spaces (e.g. coding 0.187&nbsp;985&nbsp;755 or 0.187 985 755 to produce 0.187 985 755) because such text strings can break at line-end word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of {{delimitnum}}. “Irreversibly” means that it is impermissible to convert a value that is delimited with {{delimitnum}} to a simple, non-delimited numeric string.

Further, numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 106) that were neither created with the {{e}} template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the {{nowrap}} template, or 3) use of {{delimitnum}}—exclusively so if the value has 5+ fractional-side digits.


The effect of this proposed policy, if adopted, is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which 1) uses non-Excel-pasteable non-breaking spaces, and 2) also improperly leaves single dangling digits (like this example: 0.187 985 755 2), would formally be considered as “incorrect” and should be irreversibly upgraded.

Greg L (my talk) 22:42, 14 March 2008 (UTC)[reply]

I tried this out in the sandbox and the first attempt failed:
  • {{delimitnum|1234567.7654321| |12}}
  • with template functioning: Template:Delimitnum
  • renders to me in IE7 like 1,234,567.765 4321 096 × 1012 (with spurious 096 inserted)
−Woodstone (talk) 22:47, 14 March 2008 (UTC)[reply]
There's a limit to significant digits and precision in WPs math magic words. The example in the documentation works with 13 digits, but too many digits will break the template:
Woodstone's example has 14 digits. A different issue:
Gimmetrow 23:00, 14 March 2008 (UTC)[reply]
  • Indeed. The template sometimes has problems beyond twelve digits—particularly if lots of them are in the integer portion of the signficand, which will be a rare occurance indeed. Still, it is a potential problem and certainly is a legitimate issue to discuss. This was a known inadequacy of the template-based method that was foreseen. Note however, that maybe 95% of the time, values will be a single digit in the integer portion and most of the digits will be in the fractinoal side. It could be that this might be enough of a problem that it can’t be considered as “ready for prime time.” However the Kilogram is likely very representative of the kind of article that will be using this and has encountered no difficulties. Greg L (my talk) 23:21, 14 March 2008 (UTC)[reply]
There is still a problem with a single digit in the integer portion: {{delimitnum|1.01}} = Template:Delimitnum, {{delimitnum|1.001}}: Template:Delimitnum. This can be fixed, though, as it's not a fundamental limitation (like 13-14 digits). Gimmetrow 23:38, 14 March 2008 (UTC)[reply]
  • I can see that the template may be too buggy. I noticed that while in preview mode while making my edits, all my examples were working fine but no longer worked after I saved the page. I believe what was occurring is that previous wonked-out examples (for instance, Woodstone’s examples weren’t parsed as he intended), and your 14-digit values left the template on the fritz. I can’t defend this behavior. As you can see from Kilogram, it worked great there. I don’t know whether to pull this proposal. Please see this sandbox, which really exersized the template (I think). Greg L (my talk) 23:27, 14 March 2008 (UTC)[reply]
  • Clearly, given that there are still some problems with some values, I’m withdrawing my proposal that the template be formally made available for general use. Zocky and I both worked hard to proof-check the template and thought it had been thorougly wrung out. I can now see it wasn’t. I’ll continue to use it in Kilogram as it works damn nicely there. However, I am rather expert in its use and pay particularly close attention to the numbers when I use the template. It clearly can't be put into the hands of general users until it can reliabily work with ≤12 digits. I know Zocky has put so much work in this too.
Show below is what it does do rather well now (at least in "Show preview" mode. I’ll see how they look when I click “Save page” here…

NOTE: THE BELOW MAROON EXAMPLES USE A MONOSPACED <code> FONT. THERE ARE NO SPACES INSERTED BETWEEN BLANK VERTICAL SEPARATORS (|) OR “PIPES” (adviso added later by Greg L (my talk) 21:22, 15 March 2008 (UTC))[reply]

{{delimitnum|12345.6789012}} → Template:Delimitnum
{{delimitnum|12345.6789012||12|}} → Template:Delimitnum
{{delimitnum|12345.6789012||12|Hz}} → Template:Delimitnum
{{delimitnum|6.02214179|30|23|kg}} → Template:Delimitnum
{{delimitnum|1579800.298728}} → Template:Delimitnum
{{delimitnum|1.356392733||50|Hz}} → Template:Delimitnum
{{delimitnum|0.45359237|||kg}} → Template:Delimitnum
{{delimitnum|6.022461}} → Template:Delimitnum
{{delimitnum|6.0224613}} → Template:Delimitnum
{{delimitnum|6.02246134}} → Template:Delimitnum
{{delimitnum|6.022461342345}} → Template:Delimitnum
{{delimitnum|1579800.298728|||}} → Template:Delimitnum
{{frac|{{delimitnum|1.602176487||–19|}}}} → 1⁄Template:Delimitnum

Greg L (my talk) 23:51, 14 March 2008 (UTC)[reply]

Zocky, Here’s additional examples, most of which doesn’t work:

{{delimitnum|1.01}} → Template:Delimitnum (I note that no one would use this template to delimit a number that doesn’t need delimiting)
{{delimitnum|1.00001}} → Template:Delimitnum
{{delimitnum|1.10001}} → Template:Delimitnum
{{delimitnum|1.11001}} → Template:Delimitnum
{{delimitnum|1.11201}} → Template:Delimitnum
{{delimitnum|1.11231}} → Template:Delimitnum
{{delimitnum|1.11232}} → Template:Delimitnum (this one doesn’t end with a 1 and works)
{{delimitnum|0.29872801}} → Template:Delimitnum
{{delimitnum|0.29872821}} → Template:Delimitnum (this one doesn’t end with an 01 and does work)

Greg L (my talk) 00:03, 15 March 2008 (UTC)[reply]

OK, I thought just showing the problem with 1.01 would be enough illustration, but apparently not given the above examples. The problem can manifest itself in various ways with any group of three starting with a 0. It doesn't just happen with numbers ending in '1', and it's not just a symptom of numbers too short to delimit. Gimmetrow 01:41, 15 March 2008 (UTC)[reply]
{{delimitnum|1.0001}}: Template:Delimitnum
{{delimitnum|1.00001}}: Template:Delimitnum
{{delimitnum|1.00101}}: Template:Delimitnum
{{delimitnum|1.00102}}: Template:Delimitnum
{{delimitnum|1.000001}}: Template:Delimitnum
{{delimitnum|1.000002}}: Template:Delimitnum
  • I understood that Gimmetrow. I appreciate that you’re in this with us trying to figure out its current limitations. Thanks. In my last example above, I made a it a point to show that a number that finally didn’t end with 01 would work. Clearly, it has a problem with anything ending in an 01. But the bugs don’t end there. I just added a over 200 new progressions to my test sandbox in a special section titled Progressions of features and digits. Please check it out. You can see where it’s having problems and maybe that will guide you in other directions. As you will see there, I tried all 100 progressions that end with two-digit groupings from 00–99. I also added 100 progressions with three-digit groupings from 000–099. It shows that numbers ending with two-digit groupings like 25 or three-digit groupings like 026 can be a problem. The patterns are unobvious. Maybe someone who really understands templates can discern a pattern. Greg L (my talk) 02:47, 15 March 2008 (UTC)[reply]
  • One problem (the spurious 09x) is roundoff error in the math used to separate the digits. The other problems appear to be: two digit groups with "0" (07) are evaluated as 7 rather than 70 (so treated as a single digit), and a first group of 000 loses the decimal point. Gimmetrow 02:59, 15 March 2008 (UTC)[reply]
  • Thanks Gimmetrow. Hopefully all this will assist Zocky. That is, if he isn’t sick to death of this exceedingly complex template. Are you out there Zocky?

    *crickets chirping*

    Let me know if I can be of further assistance. Greg L (my talk) 04:17, 15 March 2008 (UTC)[reply]

I'm not very proficient with template magic, but may I suggest to do it character based instead of math based? That would avoid problems with number of digits and 01 being seen as 1, or groups of 000 being overlooked. It would place restrictions on the input, such as forbidden commas or spaces, but that would not be a problem in my view. −Woodstone (talk) 13:35, 15 March 2008 (UTC)[reply]
Unfortunately, we can't make it character-based with a template, because we don't have the appropriate parser functions. I made a general template for this kind of spacing, {{spaced}}, which can be used to space anything:
. That's a good workaround for numbers that need more precision than parser functions can handle, but it's awkward, especially for the powers of ten.
As for the bugs, the missing . is easy to fix, so I'll go and do that now. I'll also look into the other reported bug and get back to you. Zocky | picture popups 14:42, 15 March 2008 (UTC)[reply]
I've fixed two more bugs - the missing leading 0 in 1.01, and the 099 additions that were caused by rounding errors in the parser functions. Any more problems? Zocky | picture popups 15:47, 15 March 2008 (UTC)[reply]
Starting to look good. My 14 digit example above works as well now. To even improve more on size of numbers, would it be an alternative to split the integer and mantissa part into separate arguments? So the template would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. −Woodstone (talk) 17:22, 15 March 2008 (UTC)[reply]
(unindented)
  • All: I created an all new section of Delimitnum sandbox with all 3960 possible variations of two, three, and four-digit groupings. I was really tempted to just declare that this is good to go but knew we would have been making the judgment based largely on what we see in the sandbox. I knew better than that and added all possible combinations I can think of which might cause rounding errors. I’m glad I did too because two-digit groups following 5 thru 9 still suffer from rounding errors (with trailing “9”s). Three and four-digit groups are all good though! To see what I’m talking about, go to the two-digit groupings section (click the underlined “two” link, above), and search on the value 0.12501. Greg L (my talk) 20:10, 15 March 2008 (UTC)[reply]

  • That was fast. All those have apparently been fixed. Please now search here for all occurrences of these (in both maroon input values and the black output values):

    0.125019
    0.125069
    0.125101
    0.125241
    and
    0.125569
    0.125597
    0.125601–0.125603
    0.125629–0.125631
    0.125735–0.125741

    Greg L (my talk) 21:52, 15 March 2008 (UTC)[reply]

Section start

Template:Delimitnum

Section end

the above result comes out of {{delimitnum|100000.000001}}
showing to me as 1.0E+5.000001

I had to insert a subsection here because this behaviour is very erratic. I have seen it only happening at the beginning of a section at the beginning of a line with nothing following. Probably not important, but you never know what is lurking behind. −Woodstone (talk) 21:56, 15 March 2008 (UTC)[reply]

  • It seems to randomly display as 100,000.000 half the time and as 1.0E+5.000 the other half for me (on Safari). Greg L (my talk) 05:25, 16 March 2008 (UTC)[reply]
  • I created an Excel spreadsheet to help me identify breaks in the progression. Here is a more concise list:

    0.125013
    0.125021
    0.125041
    0.125048
    0.125069
    0.125075
    0.125097
    0.125101–0.125104
    0.125124
    0.125131
    0.125153
    0.125186
    0.125208
    0.125214
    0.125236
    0.125241
    0.125263–0.125271
    0.125291
    0.125298
    0.125319
    0.125325
    0.125346
    0.125353
    0.125375–0.125381
    0.125402–0.125408
    0.125431–0.125436
    0.125457
    0.125485
    0.125492
    0.125513
    0.125520
    0.125541–0.125547
    0.125568
    0.125575
    0.125596–0.125603
    0.125624–0.125631

    The list goes on but if this all gets fixed, I suspect everything after this will too. Greg L (my talk) 22:56, 15 March 2008 (UTC)[reply]

Greg, this looks very promising. Pleasing to see that the MOS requirements for the spacing of the × are observed by the template (although the + sign seems to be squashed, but is of course relatively uncommon). Tony (talk) 02:08, 16 March 2008 (UTC)[reply]

Thanks Tony. I’m not trying to be difficult, but what plus sign? Greg L (my talk) 03:01, 16 March 2008 (UTC)[reply]

My overall impression here is that the fundamental way of working in the template is too vulnerable. If so many special cases need to be distinguished and remedied, we can never be sure the output will be dependable. You never reacted to my suggestion above to split the integer and fractional part in the input to the template. So it would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. With an example of use {{formatnum|1000|.0001}} (note the dot). This would allow easier manipulation of the fractional part and double the maximum number of digits. Also, as remarked by above by Tony, a leading explicit "+" sign should be maintained. −Woodstone (talk) 09:14, 17 March 2008 (UTC)[reply]

  • Woodstone, I tend to agree with you; it doesn’t look very promising that anyone—even Zocky—can overcome the fundamental limitations of templates. Perhaps in the future, templates will have access to character-based parser functions. Unless Zocky pulls a rabbit out of the hat on this one, it seems the template-based version of {{delimitnum}} won’t be something that can be put into the hands of the general editing community. However, it will only be a short time before one of our behind-the-scenes developers delivers a parser function-based magic word by the same name. As it will use character-based (not math-based) delimiting, it is a much simpler process. I heard yesterday from the developer that the magic word is done but he isn’t happy with the look of the code. “Programmers,” you see; they like tight code.

    In response to your above statement: “Also, as remarked by above by [sic] Tony, a leading explicit "+" sign should be maintained”, I assume you mean a default + sign should precede positive base-ten exponents (e.g. ×10+9). I’m sure there are different ways to format scientific notation. However, the way it has been implemented here is a very common and exceedingly professional way to do it; both the NIST and BIPM, for instance, format scientific notation the exact same way (see NIST:Fundamental Physical Constants and SI Brochure, Section 3.1). As you can see, both default to omitting the utterly unnecessary + sign in front of positive base-ten exponents. This reality is acknowledged in Wikipedia’s own Scientific notation and SI Prefixes articles as well as the {{SI multiples}} and {{e}} templates. Coding {{e|9}}} and {{subst:e|9}} omits the preceding + sign and returns ×109. I note however, that the {{e}} template doesn’t properly add spaces on each side of the × sign (see the above-linked NIST site, as well as SI Brochure: 5.3.5 for examples of proper formating in this regard). This oversight was addressed with {{delimitnum}}, which takes care of delimiting both the integer and fractional sides of the significand, and handles uncertainty, and base-ten exponents, and the unit symbol. One-stop shopping for expressing numeric equivalencies.

    Don’t despair though, if a user really has a “thing” for the unnecessary + sign and doesn’t care if he or she is flouting the BIPM and NIST, they can always code {{delimitnum|1.567892||+9|kg}} to obtain Template:Delimitnum, just as can currently be done with the existing {{e}} template. You can put anything in these templates, including Template:Delimitnum. In my opinion though, the practice of using the plus sign in front of positive exponents should be generally discouraged by official MOSNUM policy unless it is being used in Wikipedia articles on advanced mathematical concepts where the distinction must be emphasized for some reason.

    Note that every single aspect of this template was debated for a long time by many users—including Tony—here at Archive #94 of Talk:MOSNUM and everyone was quite pleased with the proposal. It seems to me that that was the time for appearance issues like adding a + in front of positive exponents to be raised so all the others could weigh in on the subject. Does it strike either you or Tony that now is the time to try to change things after all that discussion has transpired (and after a near-unanimous consensus has already been achieved)? There were one or two things I might have changed after-the-fact on this template myself but I was disinclined to even head down that path since I am entrusted with shepherding the group’s consensus decision through to completion in good faith. Greg L (my talk) 17:10, 17 March 2008 (UTC)[reply]
Actually I was referring to an explicit "+" for the whole number. Entering {{delimitnum|+123}} results in "123" without "+" sign. But I now realise the problem can be circumvented by entering +{{delimitnum|123}}. This trick should be added to the description of the template (whenever it comes to releasing it). −Woodstone (talk) 10:49, 18 March 2008 (UTC)[reply]

Sandbox moved

All: I moved the proof-checking sandbox to User:Greg L/Delimitnum sandbox. Greg L (my talk) 23:06, 17 March 2008 (UTC)[reply]

Deadly failure

I think I found a deadly failure of this concept for the template (using arithetic for formatting). Look at:

  • {{delimitnum|1.1200|25}}
  • which should lead to 1.1200(25),
  • but with current methods would come out like 1.12(25) (my hard coding)
  • or from the current template as Template:Delimitnum (for me now mysteriously looking like 1.012(25))

The problem is that in such cases the trailing zeroes are significant. Leaving them out changes the meaning of the accuracy indicator.
−Woodstone (talk) 09:27, 19 March 2008 (UTC)[reply]

  • Thanks Woodstone. I’ll copy this to the top of the sandbox to ensure it is noticed. Greg L (my talk) 18:29, 20 March 2008 (UTC)[reply]
  • I posted it over on the sandbox. I doubt that a math-based template can do anything about this one. The upcoming character-based magic word should be able to properly digest it. But just to make sure this issue is dealt with, I notified the developer of the magic word than trailing zeros in the significand shouldn’t be truncated if the uncertainty pipe has a value in it. Greg L (my talk) 18:53, 20 March 2008 (UTC)[reply]
In my opinion, numbers should never be truncated. Just use whatever digits the editor supplies. −Woodstone (talk) 09:18, 24 March 2008 (UTC)[reply]
  • It's not impossible to overcome this type of thing with templates (look at {{rnd}} for example) but if there's a magic word in the works, might we not just be happy to hold our breath? Jɪmp 03:49, 24 March 2008 (UTC)[reply]
In template "rnd" this can be achieved because the number of digits is an explicit parameter. Requiring that in this case would make the template less usable.−Woodstone (talk) 09:18, 24 March 2008 (UTC)[reply]

Consensus?

Um, since when was there any consensus at all that this weird and user-confusing spacing of long numbers was going to be sanctioned by MOS in the first place? I realize I've been off doing other things for a while but the last time I checked in on that debate, there was a strong majority against it, as a geeky practice that no one but mathematicians is likely to understand, with most users experiencing strings like that as a bunch of separate numbers. Just because some people have spent inordinate amounts of time developing elegant templates to do something doesn't mean that doing them makes any sense on WP. If I really did miss an overwheming consensus shift, then we at least need to make the spaces way smaller, like half that size.

PS: Lest I be thought to be nothing but a nay-sayer today, I will add that I like the fact that the spacing effect (which I hate in this case, because no one writes numbers that way but people in lab coats) is done entirely in CSS and does not touch the content in any way. I think a solution like this would probably be much better than &nbsp;-spacing in a lot of other cases, and would also obviate all the angsting over at WP:MOS proper about the inability to use &thinsp; because some browsers don't support it – you could simply have one template that took a space character and made it smaller for cases where a space really does belong there in the content but looks too big on-screen, and another to use the above pure-CSS spacing trick to make things visually easier to read without actually inserting any spaces. But I'm rambling... — SMcCandlish [talk] [cont] ‹(-¿-)› 01:26, 5 April 2008 (UTC)[reply]

{{val}}

Just to add to the conversation, I created {{val}} (or {{ScientificValue}} as it was originally known). It has some of the features that {{delimitnum}} has, but lacks the spacing. It does have a few added features, which I think make it better. I am looking at copying the spacing code from {{delimitnum}} into val (or just transcluding it). I hope that we can merge the two into one template that covers all requirements for values. Since {{val}} is still "in production", we can make breaking changes there without having to modify large amounts of pages. Once {{val}} is done, maybe we can deprecate one or the other name and get a bot to modify all current use of both {tl|val}} and {{delimitnum}} and manually coded values to use the new template?
-- SkyLined (talk) 16:53, 9 April 2008 (UTC)[reply]

I'm no bot expert but with a combined total of about a dozen articles ...
Template:Delimitnum (edit | talk | history | links | watch | logs)
Template:ScientificValue (edit | talk | history | links | watch | logs)
... it may be easier to convert them over manually. JЇѦρ 17:02, 9 April 2008 (UTC)[reply]

Perfect, though I'd like to look at converting manually entered values to use of this new template, which would include a much larger number of instances (and would be substancially harder to do correctly)
-- SkyLined (talk) 17:06, 9 April 2008 (UTC)[reply]

Comma's

There's been some debate about the use of comma's to delimit large numbers at Template talk:ScientificValue#New_.7B.7Bval.7D.7D_convention. There are some (unconfirmed) claims that SI specifically advocates against it. I believe some of you have been through this discussion before, but I haven't got time to find everything that was said in various places and read all of it. Is there one place where we document the rationale behind the decisions that lead to the current MOS? Could somebody help me summarize all discussions, so we have something to point to when the argument pops up again?-- SkyLined (talk) 10:28, 23 April 2008 (UTC)[reply]

The claims were confirmed BTW. You can check NIST - Grouping Digits. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 05:39, 27 April 2008 (UTC)

Micron, micrometre

Conversation copied from WP:MoS, and closed there. It is sloppy for me to bring this over here without reading the archives, but I'm pressed for time. There's nothing on micron on MOSNUM, or (other than the following) in recent MoS discussions.

  • Temperatures doesn't explain why one uses °C and °F for Celsius and Fahrenheit, but just K (not °K) for Kelvin; it's because, unlike the other two, the Kelvin scale is absolute and thus not measured in degrees.
  • This section ought to include the rule that, to avoid ambiguity, millionths of a metre (μg) are known as microns, not as "micrometres" or, worse, "micrometers", because a micrometer is a measuring instrument.
  • Squared and cubic metric-symbols: what is the Wikipedia standard for the inverses of such units? For instance, in stationery shops I've seen good-quality paper as having a weight of "80g/m2" or of 80gm-2, both meaning "80 grams per square metre". Does Wikipedia have any preference for one or the other? —Preceding unsigned comment added by 217.171.129.75 (talk) 17:29, 9 April 2008 (UTC)[reply]
My comments:
  • Temperatures I've never seen an authoritative statement about why "degree" was dropped from Kelvin. The change was made by the General Conference on Weights and Measures. If you want to claim this is why, please supply an authoritative citation.

I'm going to take your word for that, Gerry, rather than pulling up a PDF with at least 155 pages, but this is a complete surprise to me. American Heritage does say "no longer in use". Micrometre and Merriam-Webster say that micron is fine. Scientists and engineers still use the word frequently. I'm fairly sure that a MoS rule that says to avoid micron will be widely and forcefully ignored by scientists and engineers, at least in 2008. I agree that micrometre/er is completely fine. - Dan Dank55 (talk) 20:36, 9 April 2008 (UTC)[reply]

This [i.e. WT:MoS] is the wrong venue for this discussion. The section in question is simply a summary of what is at Wikipedia:Manual of Style (dates and numbers), so any issues with its advice should be raised at WT:MOSNUM (other than MOS corrections to the accurate summarization of what is actually said at MOSNUM). — SMcCandlish [talk] [cont] ‹(-¿-)› 06:47, 10 April 2008 (UTC)[reply]

Actually, Dan's summary of the Micrometre article isn't quite accurate, it says "Some people (especially in astronomy and the semiconductor industry) use the old name micron and/or the solitary symbol µ (both of which were official[citation needed] between 1879 and 1967) to denote a micrometre." My electronics engineering experience was that μ in writing was common up to the early eighties, but after that μm was generally used. (The computers back then often didn't support Greek letters, and sometimes didn't even support lower-case, so "u" was often substituted for "μ".) The word micron was often spoken long after the written form had become "μm". --Gerry Ashton (talk) 16:49, 10 April 2008 (UTC)[reply]

I agree with Gerry Ashton. There is no need for the word "micron" to appear in any WP articles except those relevant to the history of the term. The modern term is micrometre (symbol μm). Thunderbird2 (talk) 17:02, 10 April 2008 (UTC)[reply]
Gerry, I was perhaps a bit sloppy, I didn't read any farther in the article than the second sentence, which is "It is also commonly known as a micron." Thunderbird2, I'm being a little hypocritical with regard to my usual "no original research" position, but my "original research" is that I read the word "micron" often, still, in 2008. I wouldn't object to prescriptive language; it's certainly true that "micron" has not been in SI for a while, although it continues to be used in other contexts. I'm just saying that I don't think we're going to get wide compliance. This isn't a killer, it's just something to think about. - Dan Dank55 (talk) 15:53, 12 April 2008 (UTC)[reply]

The primary source for SI units is the official SI website. Terms like 'micron', 'Centigrade', and 'degrees Kelvin' were once part of SI, but they are not anymore. The continued use of legacy terms is widespread in all sorts of domains and it should not surprise anyone that this happens in SI too.

This debate started because somebody wanted to know what the current SI units are. The answers are at the official SI website. Lightmouse (talk) 17:40, 10 April 2008 (UTC)[reply]

  • We don't need to cling to outdated terminology. A foot is a body part but if I mention a 100-foot tram, who's going to think it looks like a centipede?
  • Yes, that there's no need for degrees when it comes to kelvin is due to the scale's being absolute but there is still the degree Rankine. The MoS is no place for such details though.
  • I don't believe that any standard exists for inverting units. It seems that the slash is most common, I'd say just be consistant throughout an article.
JЇѦρ 18:13, 10 April 2008 (UTC)[reply]

Temperature: Gerry, re the dropping of degree with Kelvin, see this refLeadSongDog (talk) 21:41, 10 April 2008 (UTC)[reply]

Micron is used for dot pitch on LCD displays. DavidPaulHamilton (talk) 22:45, 10 April 2008 (UTC)[reply]

Perhaps, but very rarely anymore. Compare the hits for LCD "dot pitch" 2008 micron vs. LCD "dot pitch" 2008 mm vs LCD "dot pitch" 2008 and you'll see that less than one percent used micron, and in fact most of those were references to Micron (the company).LeadSongDog (talk) 00:04, 11 April 2008 (UTC)[reply]

The rules and conventions for writing inverted SI units is given at the official SI website 'Rules and style conventions for expressing values of quantities'. You may also find useful ISO and IEC standards and SI is generally compliant with those. The original query was about paper described as either "80 g/m2" or 80 gm-2. As far as I am aware, both forms are equally valid in official terms and are equally valid in Wikipedia terms. Toss a coin. Lightmouse (talk) 08:28, 11 April 2008 (UTC)[reply]

The relevant MOSNUM text reads:

  • When units are combined by division, use a slash to separate the symbols (e.g., for metre per second, use the symbol ‘m/s’, not ‘mps’) or use negative exponents (m·s−1). There should be no more than one slash per compound unit symbol, e.g. ‘kg/(m·s)’, not ‘kg/m/s’ or ‘kg/m·s’).

Therefore g/m2 and g·m−2 are both permitted, but g m−2 and gm−2 are not.Thunderbird2 (talk) 14:02, 11 April 2008 (UTC)[reply]

My two cents
Original poster says "the Kelvin scale is absolute and thus not measured in degrees." That is false on both counts:
  • It was "degrees Kelvin" and °K until 1967. It was also "degrees absolute" (°A) in some of the earlier texts.
  • The Rankine scale is an absolute scale, and its units remain degrees Rankine with the symbol °R.
Re the micron: The biggest remaining problem on Wikipedia isn't computer monitors, but rather those editors who insist on using it for wool, and who have even created a separate article at Micron (wool).
Thunderbird2 is mostly right, when he says: "Therefore g/m2 and g·m−2 are both permitted, but g m−2 and gm−2 are not." The latter negative exponent notation requires either a space (g m−2) or a centered dot (g·m−2),[BIPM SI brochure §5.1; NIST SP811 §6.1.5 (citing ISO 31) says centered dot recommended but space acceptable, and MOSNUM is silent on this point] not run-together as gm−2 (which may well be what the original poster has seen some manufacturers use; that doesn't mean it is acceptable here). The "gm" combination is especially objectionable because that was an acceptable symbol for grams, before the 1948 standardization of symbols by the CGPM—and it is still far too often used for grams; I've fixed it in many Wikipedia articles, yet there are likely still several using it here. The ² character can be used for the "g/m²" variant, but that doesn't work with the negative exponents in the other format.
However, even though the still-senseless MOSNUM rules call for non-breaking spaces in many situations where they are not needed, they still fail completely to address this one where if a space is used, it should be a nonbreaking space. It is a hell of a lot more important to keep the unit symbols from breaking up, than it is to keep from having a line break between the number and the symbol (the latter is something not in the rules of any measurement standards organization). Gene Nygaard (talk) 15:26, 12 April 2008 (UTC)[reply]

Thanks Gene, I enjoyed the micron (wool) article. I guess it's just a matter of time before we find micron (paper thickness), micron (wavelength) and micron (font size) ;-) Returning to your point about the space as a separator, MOSNUM is not completely silent:

  • When units are combined by multiplication, use a middle dot to separate the symbols (e.g., for newton metre, use ‘N·m’, not ‘N m’, ‘Nm’, ‘N-m’ or ‘N•m’).

I interpret that as ruling out g m−2. Do you read it differently? Thunderbird2 (talk) 15:43, 12 April 2008 (UTC)[reply]

Well, I probably overlooked it. However, the "combined by muliplication" part is a little confusion, when we are talking here should come under the "combined by division" rules which I looked at on the project page. Sure, it is multiplication by an inverse; that's basically what division is. But yes, I think it should be interpreted as applying, but it would be even stronger if you could show that that was an informed decision involved in the choice between a space and a middot. Gene Nygaard (talk) 14:16, 15 April 2008 (UTC)[reply]
My recollection is that it was a deliberate (and hopefully informed) decision to use a mid-dot rather than a space. I remember the discussion because my browser didn't display the mid-dot correctly. I will trawl through the archives to see what I can find ... Thunderbird2 (talk) 14:55, 15 April 2008 (UTC)[reply]
Regarding "trawl through the archives" ... keep on trawling, please, and see my suggestion on indexing all style guidelines talk archives at WT:MoS#Proposal to index. I would love it if someone else indexes the WT:MOSNUM archives, because there are so many words and I wasn't here for most of it. Regarding the &middot; ... the official SI link says to use them, and it would be great if the current bugzilla debate doesn't have to consider hard spaces between units because the "official" position is to use a mid-dot; that would help get us over the hump at bugzilla. There's also a relevant user-interface principle here, the Principle of least astonishment. In fact, that one belongs over at the bugzilla thread, where I'm headed now. On the other hand, typesetters' characters of all kinds become less common every year in persuasive online writing, since so many people are doing their own copyediting these days. (But on the other other hand, how could Wikipedia possibly do without multiplication dots in technical articles?) All things considered, I wouldn't mind a consensus to use the mid-dot, and if somehow we can do that quickly, it will help us make progress at bugzilla. - Dan (talk) 15:27, 15 April 2008 (UTC)[reply]
This (and subsequent related discussion) is what I was looking for. Thunderbird2 (talk) 15:54, 15 April 2008 (UTC)[reply]
Thanks kindly, I read the archived discussion. There are 12 million Google hits for "kWh"/"kwh", and almost all of the first 3 pages of hits are in this sense, so it would be very silly for WP:MOSNUM to say "You can't write 'kWh' ". Google hits or something like that would be the way to distinguish for me whether it's a good idea to string units together without a mid-dot. I'm hoping for a result from the bugzilla discussion that "uncommon" one- and two-letter words don't wind up at the beginning of a line, and this might mean that we don't have to worry about a no-break space in some cases. Obviously, this is an area that requires careful description before prescription. - Dan (talk) 16:11, 15 April 2008 (UTC)[reply]
It would not be at all silly for us to require kW·h. That is in use outside Wikipedia. But we, like anyone else, have a right to choose our own house style. It is part of the "look and feel" of Wikipedia. There is no reason whatsoever for us to be even tackling the elusive task of determining "most common used" because it isn't relevant. If we follow consistent, systematic rules, that is quite enough. Google results are often useless or deceptive in such cases anyway. Consider the fact that while a search for "kWh" gets 12,200,000 hits, a search for "kWh" but not "kW·h" gets only 610,000 hits. And, like you said, many of those hits on the simplest search are for "kwh" rather than "kWh"; you forgot to mention the "KWH" hits, and you didn't even try to search for "KWHR" which gets hundreds fo thousands of hits. Of course, searching for kW·h will also find people who write it kw/h even though this unit involves a multiplication, and not a division, but "kW·h" and not "kWh" gets 6,620,000 hits, more than 10 times as much as the other way around. Gene Nygaard (talk) 13:05, 16 April 2008 (UTC)[reply]
After I said that, I looked around at abbreviations, and saw that we have 3 different sets of guidelines on abbreviations, with little apparent hope of reaching consensus on many issues. I'm thinking that abbreviations is a subject I'm not ready to tackle. - Dan (talk) 13:17, 16 April 2008 (UTC)[reply]
That's part of the reason why consistent, systematic rules are especially important for a collaborative project such as Wikipedia. Don't be saying that people writing about rugby players can add an s to their ins and kgs and lbs, but nobody else can (we don't do so here—our rule applies across the board—but because of a couple of persistent editors, we certainly do need more help in cleaning them up—just Google lbs rugby site:en.wikipedia.org[1] to see how bad it is). Gene Nygaard (talk) 13:24, 16 April 2008 (UTC)[reply]

Omegatron's proposal on a kind of no-break space at bugzilla

User:Omegatron has given the bugzilla (MediaWiki) developers a proposal to automatically avoid wrapping lines between numbers and certain abbreviations, such as cm or m. The link is https://bugzilla.wikimedia.org/show_bug.cgi?id=13619. He's not proposing that they insert a no-break space character, simply that the html rendering not wrap the line in those places. Does anyone have anything to add or subtract from the list of scientific symbols at User:Bobblewik/monobook.js/unitformatter.js? - Dan Dank55 (talk) 03:24, 12 April 2008 (UTC)[reply]

Centralized discussion: Wikipedia_talk:Manual_of_Style#No-break_spaces_discussion_continues_at_bugzilla — Omegatron (talk) 17:08, 12 April 2008 (UTC)[reply]

I agree the discussion should be in one place at a time ... nothing was going on there when I posted this :) Let's keep it there for now, but input would be appreciated, we don't get to take our concerns to bugzilla every day, and this one is important (to me). - Dan Dank55 (talk) 19:53, 12 April 2008 (UTC)[reply]

I reviewed the link provided by Dan which supposedly is a list of scientific symbols, and it struck me as gibberish. --Gerry Ashton (talk) 13:32, 14 April 2008 (UTC)[reply]
So many responses come to mind, but just one seems relevant. In wandering around Wikipedia, I've noticed that some discussions are more useful than others. A useful rule of thumb is to talk about things on the right page, and never on two different pages at once, otherwise things get a lot harder than they need to be. Note that, now that Stanton is back, he has moved several discussions that were in WP:MoS over here; good for him. We should be more careful to do that. In this particular case, the discussion has relevance to a bunch of different issues at the same time, so, as I pointed out above, we're arguing this one over in WP:MoS, where you will find that I gave additional links to official lists of SI symbols. The discussion needs more eyeballs, and there's some urgency, because there's an open request at bugzilla. - Dan Dank55 (talk) 14:13, 14 April 2008 (UTC)[reply]
Like Gerry Ashton, I was curious enough to click on the monobook.js link. Also like him, I did not understand the programming language used in the script, but something caught my eye nevertheless. Just after the comment "// decibel" is the command
  • txt.value = txt.value.replace(/(\d)\s?(dB)\b/g, '$1 $2');
Now I am curious about what this does. Can someone explain? Thunderbird2 (talk) 17:23, 23 April 2008 (UTC)[reply]
The reason I am curious is that the decibel is no ordinary unit. It is a (logarithmic) unit of ratio, and often meaningless unless accompanied by more information about both numerator and denominator of that ratio. It seems unlikely to me that such subtle (but important) considerations are taken into account by a single command. Hence the request for clarification. Thunderbird2 (talk) 17:31, 23 April 2008 (UTC)[reply]
It simply replaces any sequence of the form { <digit> <zero or one space character> "dB" <word boundary> } with { <same digit> < what I assume is actually a non-breaking space no, it's just a space> "dB" }. I don't think any special considerations are applicable here, though I'll note that this statement will not do the same for, e.g. dBA dBV and so on. --Random832 (contribs) 19:51, 2 May 2008 (UTC)[reply]

This line 

   txt.value = txt.value.replace(/º/g, '°');

is indiscriminate. It will replace instances even where the Ordinal indicator character is actually intended. 

   txt.value = txt.value.replace(/centigrade/gi, 'Celsius');

replaces all instances of the word "centigrade" in any context. "The Celsius temperature scale was previously known as the centigrade scale." would become "The Celsius temperature scale was previously known as the Celsius scale."

I'm also concerned in general about the indiscriminate behavior of this script, as applies to quotations, URLs, etc.. --Random832 (contribs) 19:58, 2 May 2008 (UTC)[reply]

Follow current literature

This section if for discussing MOSNUM:Follow current literature   Greg L (talk) 02:46, 16 April 2008 (UTC)[reply]

First draft

Difficulty level versus target readership
You may comment on how this guideline might be modified and/or expanded at Talk:Difficulty level versus target readership
  • For any given subject and level of difficulty, editors should use the units of measure and methods of disambiguation commonly used in current literature on that subject.

    In short: don’t write above the heads of the readership. The goal in all technical writing is to clearly communicate to the intended audience with minimal confusion. A Wikipedia article about the mathematics of black hole evaporation necessarily requires the use of more advanced terminology and units of measure—Planck units—than does a more mainstream, general-interest article on black holes, which should use the SI or astronomical units of measure (kilograms or solar mass) that are more familiar and appropriate for that readership. A Wikipedia article on, for instance, x86 assembly language that is directed primarily to professional software developers might require advanced units of measure and unit symbols that would be unfamiliar and unsuitable for use in general-interest articles about computers, such as Macintosh. In all cases—and within the confines of Which system to use, above—editors should use terminology and symbols commonly employed in current literature for that subject and level of difficulty. When in doubt, use the units of measure, prefixes, unit symbols, and methods of disambiguation used by the majority of reliable periodicals directed to that readership.

Were this to be accepted as policy, it would open the door to all kinds of symbols and abbreviations. Each WikiProject will be using different stuff. There'll be no consistancy across the encyclopædia. Things are bad enough as they are with the "cc"s, "BCM"s, "TCF"s, "mmBTU/hr"s, "cfs"es,[2] "ltr"s, etc. The readership we ought to target is a general readership. The symbols and abbreviations we use should be the standard symbols of SI units and non-SI units accepted for use with SI plus a consistant standardised set of imperial/US customary abbreviations. In short we should strive to maintain consistancy across the encyclopædia valuing this more highly that consistency with sources. Certainly we should quote measurements in the units as found the sources but we need not use the same names, symbols or abbreviations. If our source uses "kph", we should not hesitate to change it to the standard "km/h". JЇѦρ 06:33, 16 April 2008 (UTC)[reply]

  • This doesn’t change anything related to the preferred use of the SI; it address only the issue that its section title (“Difficulty level v.s. target readership”) suggests: don’t talk over the head of the readership. It’s pretty much stating what is common-sense, proper technical writing practices but needs to be spelled out. The wording specifically says “within the confines of Which system to use, above”. And to help insure the message is clear, it specifically gives the example of the Planck units, which are special, scientific units of measure currently used in Hawking_radiation#Black_hole_evaporation—and for good reason: those are the proper units to use when one is discussing such an advanced concept to such a readership. The point of the policy is that editors should not use Planck units in a general-purpose article about black holes (like Black hole) and should instead use the more familiar SI units of measure (kilograms) or astronomy terms (solar masses). Given your above post, I went back and added language to drive this point home. Greg L (talk) 07:33, 16 April 2008 (UTC)[reply]
Much of what you're saying there I'd agree with. There are a few things which I'm opposed to. For example, "editors should use terminology and symbols commonly employed in the literature for that subject and level of difficulty." The symbol "cc" is commonly employed in automotive literature, should "cc" be used in car articles in violation of Wikipedia:Manual of Style (dates and numbers)#Unit symbols which states "Squared and cubic metric symbols are always expressed with a superscript exponent ..."? Note also some of the weird and wonderful symbols used in the American natural gas and Canadian hog industries as discussed above. And if some sheep farmers still cling to the micron, do we have to? We can be true to the sources without using their terms and symbols. JЇѦρ 08:15, 16 April 2008 (UTC)[reply]
  • I think this is a common sense goal. In an article on assemble language programming, it is reasonable to express memory addresses in hexadecimal notation. It would also make sense to use the CPU vendor's assembly language syntax. This level of geek speak is not appropriate for a general audience computer article.

    Wikipedia has style guidelines that mimic the guidelines found in the real publishing world. A serious medical journal is going to use terminology that assumes the reader has an advanced degree in medicine. That terminology would be of no use to a typical layperson.

    We need to recognize the fact that articles at different levels may require different styles. If there are multiple units used in the real world, Wikidedia can select a preferred unit. In a few cases, one preference would be for general articles and one would be for technical articles. -- SWTPC6800 (talk) 14:23, 16 April 2008 (UTC)[reply]

  • Jimp, you brought up some good examples of units that might get caught in the dragnet. I would say that *if* there really was a Wikipedia article directed to professional sheep farmers, such as an in-depth article about a particular sheep disease, then Wikipedia should use the units used in current literature intended for that audience. The same thing goes for natural gas exploration. Remember though, the question to ask is: is this one of those rather rare Wikipedia articles directed primarily to an expert audience? Or is it for a general-interest audience? How would Newsweek communicate the issue in its science section? This policy is only supposed to need common-sense, no-hidden-strings interpretations so editors don’t use the wrong units. In all cases, Wikipedia articles must use the units of measure that would cause the least confusion among the readership to which that article is directed.

    You bring up an interesting point about the use of “cc” (cubic centimeters) as it applies to engine displacement and this speaks to the issue the policy is suppose to address. If there is a Wikipedia article on a certain Ferrari car—take the example of Ferrari 250 GTO—which seems to me would be directed to enthusiasts of a car made in the early 60s, and if current literature (in the English-speaking world, since this is en.Wikipedia) on that subject still uses the symbol cc for engine displacement, then I would argue that Wikipedia indeed should go with the flow. Why would we want a novice, who plans on attending a gathering of Ferrari aficionados, first read up on the subject here on Wikipedia, and then not understand why other others are talking about “see-sees”? The acceptance of “cc” would apply only to auto-related contexts and would absolutely not supplant the use of milliliter (ml) in other disciplines. If there is a good reason to not let “cc” as it applies to auto engines get swept up in this policy (I can’t think of a good one at the moment), then a specific exception can be made for that in twenty words or less.

    The point of having the policy statement is to ensure that the important principal is understood before editors discuss particular exceptions to the rule on Talk:MOSNUM. Greg L (talk) 17:12, 16 April 2008 (UTC)[reply]

Without getting into the general debate, I'd like to point out that "v.s." is not an abbreviation for "versus". Use either "v.", "vs.", or the unabbreviated "versus" if this is kept. Caerwine Caer’s whines 03:25, 17 April 2008 (UTC)[reply]

  • I seem to have been having problems lately with that one. Thanks. I changed it to (“versus”) from “v.”, which—though technically correct for an abbreviation—seemed less well known. Greg L (talk) 05:23, 17 April 2008 (UTC)[reply]
The whole thing seems to hinge a great deal on judging readership. How do we know who's going to read the article? Are there many articles aimed at the experts? Should there even be any? Do the experts look to Wikipedia for information on their own subject?
Certainly we have articles pitched at differerent levels but should we not strive to make all articles as comprehensible possible to as wide an audience as possible?
Perhaps an exception can be made for "cc", and an article on sub-atomic physics would naturally use "eV" but we should be able to read Bonga Field without being hit with "bopd", "MMscf", "mmbll", "bcf" and "mmBoe".
By all means we should use the units as used by the source but we need not use the same names/symbols/abbreviations. There is no conceivable reason we should abbreviate a cubic kilometre as "BCM". Though it may be found in some source material, we should avoid the use of "M" for thousand. The natural gas industry expert might be used to talking "TCF"s but I'm sure he'd be able to handle "×1012 cu ft".
In an above section a number of us expressed their disapproval of the use of "lb" for pounds-force. It is used this way in certain literature, though. It automotive industry may quote torque with "lb·ft", we should feel free to change it for the same of consistency if need be.
JЇѦρ 06:41, 17 April 2008 (UTC)[reply]

I removed the section because, as I understand it, dramatic changes to policy should be discussed here first. This seemed to me to come out of nowhere until I looked at the extensive arguments over binary prefixes where it is part of the dispute. Regardless of the motivation for adding that section, it seems to me to be unnecessary unless we want to debate binary prefix issues. I would rather not have a debate in two places. Lightmouse (talk) 10:15, 17 April 2008 (UTC)[reply]

And I undid your change because it was discussed, and because the change is sensible. Fnagaton 10:26, 17 April 2008 (UTC)[reply]
The change was made on 16 April at 02:59 and the discussion was started later the same day at 06:33. Please do not fight the binary prefix war here. Lightmouse (talk) 13:40, 17 April 2008 (UTC)[reply]
That is not true, this subject was talked about in this archived section. Fnagaton 16:09, 17 April 2008 (UTC)[reply]
It would do our editors a favor to mention, either in this section or somewhere else, that material is removed routinely from Wikipedia due to the objection that it is too technical or too specialized, and that using unfamiliar language or units could be a factor in whether other editors perceive the material as violating WP:NOT#TEXTBOOK (with or without justification). It would also be helpful to mention that, provided the rejected material is well-written, properly sourced and notable in its field, you can always move it to Wikibooks and link it directly there, so that it becomes effectively an extension of the Wikipedia page, which is better than a vague reference that "additional material can be found in Wikibooks". Carl and others discussed this at WT:WikiProject_Mathematics/Proofs#Where oh where has my little proof gone?. - Dan (talk) 13:58, 17 April 2008 (UTC)[reply]
  • All, this is more than just the “binary prefix war” issue. As Jimp pointed out, this is very properly touches upon other issues such as engine displacements in cc. This policy is a simple common-sense one and editors who have their favorite “issues” with units of measure have got to stop acting like this somehow “opens the door” to other uses. As one of the most vociferous proponents of using the binary prefixes wrote (B7 archive, 18:21, 13 April 2008 (UTC) post): “That is a nice rule of thumb but it's common-sense. Therefore, there's no need to add it to any guideline.” Common sense rules don’t require a consensus of approval to be written here on MOSNUM; the principals of technical writing apply even to Wikipedia. Opposition to things like “cc” for engine displacements (and all the other pet issues being bandied about here) should be argued as separate issues but we can’t allow them to be individually used as a justifications for suppressing the basic fundamentals of common sense. Everyone has their pet unit of measure; if they can’t mount a successful argument as to why their pet unit should be exempt from a fundamental principal of technical writing, then their pet unit should probably fall and Wikipedia should use the unit used in current literature.

    If some editors here really want to have a poll and discussion over this, we can. But it will be with the policy right there in MOSNUM so lots of editors can know of the issue and weigh in here—rather than the standard handful of editors, each with his own agenda, oh-so anxious to quote their favorite Wikipedia rule to justify burying this thing as deep as possible. The whole point of having the policy statement is to ensure this important, basic principal is understood before editors choose the units of measure to use in their articles. A lot of current discord might have been averted had this been in place years ago. Greg L (talk) 18:59, 17 April 2008 (UTC)[reply]

  • I disagree with the reverts made by Thunderbird2 and Lightmouse of this common sense addition to MOSNUM. Fnagaton 08:34, 18 April 2008 (UTC)[reply]
I agree with the removal of the proposal from the page. There is no consensus on this at present. Proposals should be discussed first. A brief discussion on seperate page cannot be said to count as consensus especially when that page was created to deal with an issue of much narrower scope and the existance of which had not as the time been clearly advertised. I would like to see the potential consequences of such change fleshed out first. Label it common sense if you like, it would nonetheless be a huge change in policy. JЇѦρ 09:06, 18 April 2008 (UTC)[reply]
  • More importantly, while good advice in general, it does not belong here; it's not about style in the narrow sense. Write an essay, which can be upgraded to a guideline if enough people agree with it. Please, everybody, do remember that this obscure page is also only a guideline: it is not policy, and should not be. Septentrionalis PMAnderson 14:54, 18 April 2008 (UTC)[reply]
  • Oh common Pmanderson, is that the best you can do? The policy is directed exclusively to choosing units of measure appropriate to the subject and difficulty level. If that doesn’t belong in MOSNUM right there as a subsection of “Units of measurement”, I don’t know what does. What kind of argument was that(?): “it belongs *somewhere* but not on MOSNUM…”. Sorry, but that one’s just not working for me here.

    But I do agree with you wholeheartedly that MOSNUM is a guideline and—unlike some things such as “no personal attacks”—is not Wikipedia law. The purpose of this guideline is to put into MOSNUM, what should have been there years ago. We would have avoided having one Wikipedia page using one set of units, and another on the same general topic using another (and endless battles between the two camps).

    This policy touches upon two important issues: 1) Use the units in current literature, and 2) with the confines of that, don’t use units of measure that are primarily only for industry pros if the article is really better suited to a general-interest readership.

    If we have an article on Oil production, it’s simple; use “barrels”; our job on Wikipedia is to communicate, not promote adoption of the SI. If we have general-interest articles on computer technology, use the units used by the manufacturers of computer equipment (in their advertisements, brochures, product packaging, owners manuals), and in all general-circulation computer magazines: kilobytes (KB), megabytes (MB), etc. rather than use the IEC proposal: kibibytes (KiB), mebibytes (MiB), etc., which have only been mildly adopted for professional software developers.

    Too many novice editors on Wikipedia have been so smitten with the power of authorship Wikipedia affords them, and the gigantic audience it enjoys, that they’ve hijacked Wikipedia as a forum to promote change (WP:SOAP WP:NEO, and WP:V) whereever they perceive that using certain way-different unit of measure is a good idea. That is not the purpose of any encyclopedia. Our job is to communicate to a given readership with minimal confusion so they can learn about a subject and are primed as well as possible to learn more about the subject in their readings elsewhere. It does the reader no good to at all (and just makes Wikipedia look foolish), if Wikipedia talks of oil production in “millions of m³”, an engine displacement of “2600 ml” and a “computer with 512 MiB of RAM.” The clue for editors is this: what is the rest of the publishing world—including Encyclopedia Britannica and World Book—doing in order to communicate to the audience on a particular subject? If we find that Wikipedia is all on its own, we need to ask ourselves “are we doing so for a valid and compelling reason?” If not, maybe we need to stop thinking of ourselves as encyclopedia hot shots and follow what the paid professionals are doing elsewhere throughout the English-speaking planet. Greg L (talk) 17:10, 18 April 2008 (UTC)[reply]

I agree perfectly with Our job is to communicate to a given readership with minimal confusion so they can learn about a subject and are primed as well as possible to learn more about the subject in their readings elsewhere. I also agree with the example of barrels. Can we say just those two things, and a linking sentence about units?
The generalizations about the heads of the audience drag in a mass of controversy, much of it not consensus, or relevant here. I deplored them. Septentrionalis PMAnderson 17:43, 18 April 2008 (UTC)[reply]
  • Our objective should be to begin to have consistent, sensible policy regarding how editors can select the appropriate unit of measure for all articles on Wikipedia and have consistent practices across all articles on the same general subject. I will not back down from stating the truth, no matter how uncomfortable it may be. The simple fact is that some of Wikipedia’s practices of using “future-talk” units of measure that haven’t found any traction whatsoever in the real world make Wikipedia the subject of ridicule among knowledgeable readers of certain subjects. Why has this been permitted to go on for so long? Because we don’t have the courage to post a simple “Well… Duhhh” statement that comes straight out of Technical Writing 101? Instead of battling each editor with their pet, weird unit of measure that no one else uses for discussing that topic, we’ll start with the basics and work down. We’ve got to have enough courage to do that. I have no interest in defending whether this policy should or should not be on MOSNUM by allowing myself to be dragged into every case-by-case argument on every damned weird unit of measure. No one on the planet has the time and energy for that crap. No, the issue has to be this: For any given topic and level of difficulty, is it a wise Wikipedia guideline that asks that editors use the units of measure that have already been adopted by the rest of the English-speaking, generally metric-using publishing world? We must lay down the fundamental starting point and let the combatants with their respective units go to work with what best meets the spirit of that fundamental objective. Greg L (talk) 20:06, 18 April 2008 (UTC)[reply]
  • P.S. Pmanderson, I kinda like that wording. Wouldn’t you agree that the proposed policy point is pretty similar to this (?): “Editors should use the units of measure that have already been adopted by the rest of the English-speaking, generally metric-using publishing world for that topic and target readership level.” Greg L (talk) 20:16, 18 April 2008 (UTC)[reply]
    • Editors should use the units of measure that have already been adopted by publishers in English for that topic and target readership level. and we've got a deal. Generally metric-speaking will be abused to compel the use of kiloliters of petroleum. Septentrionalis PMAnderson 20:33, 18 April 2008 (UTC)[reply]
  • Well, I think you and I can write collaboratively together. I haven’t eaten yet (it’s 1:46 PM local time) and am tired juggling "real world" and Wikipedia this morning. I’ll get back to this later. I am concerned about how your proposed wording would be perceived by the SI community. I, for one, am an ardent proponent of SI. Hell, I had a celsius Honeywell household thermostat brought down by car from Canada for use in my previous house. I’ve since lightened up a tad. It seems that we might be missing an important nuance here. Wikipedia rightfully has a policy of using SI first to describe generalities. The issue becomes problematic where a discipline 1) uses metric in a non-standard way (2600 cc engine), or 2) has multiple, scientific units of measure to use and its an issue of appropriateness for the level of difficulty (kibibytes vs. kilobytes or Planck units vs. solar masses), or 3) where the discipline simply does not use SI whatsoever (barrels of oil). How do we make it clear that just because Car & Driver speaks of a “2600 cc engine”, we don’t also have to write of a “3200-lb car”? Do you think the explanatory text, where it says “In all cases—and within the confines of Which system to use, above—editors should use…” sufficiently addresses this issue? Greg L (talk) 21:02, 18 April 2008 (UTC)[reply]
  • Pmanderson, as a starting point (we will come up with a pithy, single-sentence policy statement later), would you agree that the following explanatory text correctly expands on the principal we’re trying to get across? Greg L (talk) 22:29, 18 April 2008 (UTC)[reply]

Second draft

Generally speaking, Wikipedia has a strong preference for SI over other systems of measurement such as U.S. Customary and Imperial. It should be “the auto weighs 1450 kg (3200 lb),” not the reverse. There are, however, many instances where a given industry has such an entrenched and universal practice of using non-SI units of measure, or SI units in non-standard ways, that for a reader to be conversant and knowledgeable in the discipline necessarily requires that Wikipedia mirror those practices. Thus, it is a “2600 cc auto engine” and never “a 2600 ml auto engine.” It is “Saudi Arabia exported 9.0 million barrels of crude,” never “1.43 m³ of crude.” In other cases, there are different systems to choose from that each meet the spirit of the SI, but are not appropriate for a certain level of readership (difficulty level). Thus, Planck units would be suitable generally only in advanced articles on, for instance, an article on black hole evaporation but a Wikipedia article directed to a general-interest readership should describe a black hole’s mass in terms of solar mass. In still other cases, the issue pertains to ubiquity. The 1999 IEC proposal on binary prefixes which introduced new prefixes for the byte and bit, producing kibibyte (KiB), kibibit (Kib), mebibyte (MiB), etc., have seen precious little real-world adoption. They are consequently unfamiliar to the typical Wikipedia reader and will likely not be encountered elsewhere after leaving Wikipedia. Accordingly, the standard binary prefixes, such as kilobyte (KB), megabyte (MB), should be used for most purposes and their meaning disambiguated using conventional techniques.

In all cases—and within the spirit of Which system to use, above—editors should use terminology and symbols commonly employed in current literature for that subject and level of difficulty. When in doubt, use the units of measure, prefixes, unit symbols, and methods of disambiguation used by the majority of reliable periodicals directed to that readership.


Support. Good job. - Dan Dank55 (talk) 22:56, 18 April 2008 (UTC)[reply]

P.S. I could be wrong, but the point I mentioned above (NOT#TEXTBOOK) seems related. The most likely objection to your proposal is going to run something like: "If you're saying that some Wikipedia articles ought to measure things in Planck units, I've got an answer for you: NOT#TEXTBOOK." To deflect this, we should make it clear that the only things that are essential when starting an article are notability (in its field), good sources, and the desire to say something, and say it well; if someone has all that, we should not discourage them from working on their article, and if it's later decided that some of it is too "textbook", then just put it in Wikibooks and link it directly. - Dan Dank55 (talk) 23:09, 18 April 2008 (UTC)[reply]
P.P.S. It needs to talk about "how far, how fast" on the metric thing. I believe I was agreeing with Sept below when I said "I could only support a "gradual push" towards metric for anything that isn't solidly tied to the U.S." - Dan Dank55 (talk) 23:13, 18 April 2008 (UTC)[reply]

Support Fnagaton 22:59, 18 April 2008 (UTC)[reply]

Invalid Suggestive. Assertive. Bloated. --217.87.60.234 (talk)

  • While I disagree with the “invalid” label, I agree with all three of the adjectives you chose. Unfortunately, I see nothing that can be done about “bloated.” Without the detail of “here’s exactly what we’re talking about,” we’d be leaving this contentious guideline open to misinterpretation, open to driving a semi-truck through an unintentional loophole, or beating around the bush until that the point becomes ambiguous enough that someone with their pet unit of measure no longer sees this as a threat. I don’t believe in wasting time here. Ergo, your blanket statement that it is “invalid.” I’d really prefer that you had said “oppose”; if literally invalid, why? Greg L (talk) 04:38, 19 April 2008 (UTC)[reply]
  • P.S. Well, let me ask this: Setting aside the issue of how it directly speaks to the issue of the IEC prefixes, do you agree with the first part—the two-sentence guideline itself (the version below) and the principal it embodies? Greg L (talk) 05:43, 19 April 2008 (UTC)[reply]
I already told you before that I agree with a guideline like "editors should use the units of measure and methods of disambiguation commonly used in current literature on that subject" because it represents common-sense. I also told you that the discussion about binary prefixes is an exception to this rule of thumb. The definition of units like lbs. or kg is not context-dependent. You can directly convert the values from one unit to another. Furthermore, the mega in megaton does not conflict with SI definition regardless of the definition of ton. IEC 60027-2 isn't rocket-science as your example of "black hole evaporation" seems to imply. It was already concluded that it's no more difficult to understand "1 MB = 1,000,000 bytes" than understanding "1 MiB = 1,024×1,024 bytes" and that the average reader most-likely does not know the exact definition of MB in any specific context anyway. Therefore clarification is required in either case. You're trying to cram unrelated issues into a single "guideline". That's why I consider this proposal as invalid. --217.87.60.234 (talk) 12:39, 19 April 2008 (UTC)[reply]
  • Please see the Third draft below. The parenthetical “(details subject to Binary prefixes, below)” is about as good as I can do at the moment. Do you expect more or can you support it? Greg L (talk) 05:04, 20 April 2008 (UTC)[reply]
  • Amend. We disagree on emphasis; the customary and imperial systems are often quite natural. Even more important, this page should not decide whether WP strongly supports something; we should observe whether there is widespread consensus elsewhere, and I don't think there is, for principal use of metric units for articles on all subjects, in all dialects. The following draft is tentative; for more, see my remarks in the following sections. Nevertheless, I would rephrase only the first three sentences, down to non-standard ways; I heartily concur with the rest. Septentrionalis PMAnderson 23:25, 18 April 2008 (UTC)[reply]

Third draft

{Quick link to version on MOSNUM}

Follow current literature

In a nutshell: Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:
Preference for modern units
Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.
Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or metric rather than SI—Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline. Editors should write…
  • “a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm3 Honda motorcycle engine”;
  • “Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude” (unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices);
  • “a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10−6 s–2”, in the science of gravimetry.
Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems, but sometimes not. Note that even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no “best” way. For instance, writing “a 450 cc (450 cm3) motorcycle engine” is inappropriate even though it is in conformance with the SI. “The Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inchs (5,766 cc)” is appropriate for a historical, American-made engine. “The Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 CID)” is appropriate for a modern, American-label engine that is classified in liters. But writing “the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches” would be inappropriate in an article primarily about a European-made sports car.
There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities. The “uno” was proposed to address the numbering system-dependent ambiguity inherent in expressions like “parts per billion”. Notwithstanding that many of the parts-per notations are non-compliant with the SI, the uno has found little, if any, real-world adoption. Editors should therefore not use the uno to express dimensionless quantities. Similarly, because existing prefixed forms of the byte are ambiguous (“KB”, for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as “kibibyte (KiB)”, “kibibit (Kibit)”, and “mebibyte (MiB)”. However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, like “kilobyte (KB)” and “megabyte (MB)”, for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to “Binary prefixes”, below).
Level of difficulty (do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.
Support. I consider the above green-division proposed policy to be a live document that is subject to continual, collaborative revision by proponents of the basic objective it is addressing. In its current form, I support it. I will occasionally update my ~~~~ auto-signature to confirm that I support the latest revision. Greg L (talk) 06:07, 20 April 2008 (UTC) Other reasons would include[reply]
  • simple American or British idiom (as pints);
  • If the data is given in lb only, there is often a case for presenting it as lb (kg), because it's the lb which are verifiable. (Also if the weight is precisely a ton, we should say so, and convert to 900 or 907 kg.)
  • Others may occur to me.
I have not time to copyedit the rest. Septentrionalis PMAnderson 23:25, 18 April 2008 (UTC)[reply]
  • Pmanderson, I’m perfectly happy with your re-write. May I suggest that since we agree on this much, I see no point in trying to condense all of that into a magical, single-sentence statement. Instead, why don’t we flip it upside down and put the two-sentence summary first and make it the suggested guidline. What do you think? What did you have in mind for the guideline statement? Greg L (talk) 03:58, 19 April 2008 (UTC)[reply]
  • P.S. I took the liberty of flipping it upside down. If you had a great idea for a nutshell, single-sentence guideline statement, go ahead and flip it around and add what you’re thinking about. Greg L (talk) 04:23, 19 April 2008 (UTC)[reply]
  • Dank55, I checked out WP:NOT#Textbook and could not see your point. Reading your suggestion above in its broadest context (what it takes for notability) seems, at first blush to me, to be touching upon more than we need to bite off with this. Please feel free to modify the above green-division per notability as it applies to knowing whether or not the proper units of measure have been chosen. Or are you satisifed with it the way it is currently written (for choosing units of measure)? May I suggest that your edit be in the form of underlined text if it can take the form of a simple addition? Greg L (talk) 04:16, 19 April 2008 (UTC)[reply]
Thinking about recent battles at WT:V makes me realize that we should leave my point out. Changes at guidelines and policy pages seem to be accepted better if we do one thing at a time, then wait to see how it's handled "in the trenches" and deal with unexpected consequences, before trying any additional steps.
I say that I approve of the language, and I do, but as a clear statement of what our position is. Many people will say that explanatory text doesn't belong in guidelines, and many people will say that there is either policy somewhere in here, or guidelines that don't belong on WP:MOSNUM. So, I'm not sure what we've got or how it will be received, but I like it. - Dan Dank55 (talk) 04:13, 19 April 2008 (UTC)[reply]
P.S. Made a few edits (-precious, reword in terms of "difficult material", comma before 'but'). I'm going to ask around about what experience people have had with getting their material rejected because of NOT#TEXTBOOK, so that I'll be ready to handle objections that may arise. - Dan Dank55 (talk) 04:40, 19 April 2008 (UTC)[reply]
  • Dank55, thanks for your help. I normally pride myself on being able to craft tight, pithy, one or two-sentence statements that are unambiguous and which cover an issue in its entirety. In this case, I’m at a total loss to find such powerful wording (and therefore have to resort to the explanatory examples). It must be inherent in the nebulous nature of the subject of “units of measure.” Greg L (talk) 04:51, 19 April 2008 (UTC)[reply]
  • Fnagaton, I think I understand your objectives clearly enough. May I assume that you are quite happy with the above green-division proposed guideline? Greg L (talk) 04:18, 19 April 2008 (UTC)[reply]
  • You are correct to assume that. :) Fnagaton 09:20, 19 April 2008 (UTC)[reply]
Support. A goal statement like this one has been needed on the Manual of Style (dates and numbers) page for some time. Some contributors here feel the mission of Wikipedia is to teach the world the "correct" usage of "approved" units. If this destroys the readability of the articles and leaves the readers baffled, too bad; as long as the units are correct. -- SWTPC6800 (talk) 16:45, 19 April 2008 (UTC)[reply]
The current revision is vastly improved and I support it. -- SWTPC6800 (talk) 17:37, 26 April 2008 (UTC)[reply]
Comment I’ve been watching the evolution of this proposal. It has improved with each new draft. It’s not quite there yet, but it’s approaching something I can support. The two problems that I still see are both a consequence of the closing paragraph:
  1. The phrases “use the units … and methods of disambiguation used by the majority of reliable periodicals directed to [readership of a given subject and level of difficulty]” and “… kilobyte (KB), megabyte (MB), should be … disambiguated using conventional techniques” can be interpreted as advice not to disambiguate in cases where the convention of most periodicals is not to do so. I don’t see how that can be a good thing.
  2. There are many cases where the unit MB changes meaning half-way through an article, often half-way through a paragraph, and sometimes half-way through a sentence. There are two ways of disambiguating such an awkward construction: one is to restructure the article, an onerous task; the other is to use unambiguous units, which is discouraged by the final paragraph.
The simplest way to deal with both problems is to delete the offending paragraph. Thunderbird2 (talk) 19:23, 19 April 2008 (UTC)[reply]
  • Thunderbird2, if restructuring the article helps the average reader to understand the subject I'm willing to help. Fnagaton 08:37, 20 April 2008 (UTC)[reply]
  • There are many examples, but Mac Pro is an interesting one - I counted 5 changes of meaning. It already includes some disambiguation of both varieties (IEC prefixes as well as "conventional" footnotes). I find the IEC prefixes helpful (I may have added them myself) and would find the article difficult to follow without them (even with the footnotes) because of the multiple changes of meaning. Thunderbird2 (talk) 08:56, 20 April 2008 (UTC)[reply]
  • I’m somewhat inclined to jetison the IEC prefix issue here just to get this important guideline in. However, that would lessen the support of some other key players here so I’ll keep at it for a while. I’m trying to find language that clearly and rationally applies across the board. It seems to come down to a general agreement that the IEC prefixes are not commonly used in current literature (and therefore not generally recognized). Proponents of the IEC prefixes argue that the problems with the conventional units are so compelling that Wikipedia’s bucking the trend is warranted. I’ve added “where necessary” to the above regarding disambiguation. Does that help? Greg L (talk) 20:21, 19 April 2008 (UTC)[reply]
    • If you prefer to keep it, then a way of making it less controversial is to balance it with an explanation of why IEC found it necessary to come up with these prefixes in the first place, emphasising the fundamental need to disambiguate MB etc. That might be enough. Thunderbird2 (talk) 20:31, 19 April 2008 (UTC)[reply]
  • I will give a crack at it. The challenge will be to do so in a tight, compact way so it doesn’t start looking like a battleground over IEC prefixes with “Oh… and these issues too” tacked on around the edges. Greg L (talk) 20:48, 19 April 2008 (UTC)[reply]
  • Is that what you had in mind? Greg L (talk) 21:03, 19 April 2008 (UTC)[reply]
Comment I agree with the general principle here. However I've got just a few reservations with some of the details. The wording above might be taken as implying that conversions to metric will generally not be given. Is this the intent? I would oppose this. If our goal is to communicate, conversions are essential (not only to metric but imperial/US where appropriate). Crude oil will typically be given in barrels (though some sources may give tonnes). If the source quotes barrels, we should but that does not mean a cubic-metre (and/or tonne where possible) conversion should not be given. Another concern is consistancy across different topics. If "lb" means one thing on one page and another thing on another, the encyclopædia will be a very confusing place to be. I'd also like to see something about avoidance of unfamiliar abbreviations/terms where there exists a more familiar alternative. The abbreviation "cc" may be non-standard but at least it's well recognised. "123 MMCF" will not be so comprehensible and would be better written out in full as "123 million cubic feet" or abbreviated as "1.23×108 cu ft". Let us not neglect the casual reader who might just have got engrossed in a "random article". JЇѦρ 19:45, 19 April 2008 (UTC)[reply]
  • It was not my intention to rule out conversions. I’ll fix that. Like I’ve stated before, no earthling I know of has the energy and time to defend this most basic of proposals by arguing it based on the merits of each and every unit of measure that might come up. Clearly, “Lb” means different things; primarily, it’s both a force and a mass. The guideline is already filled with enough bloat to clearly convey the gist of the point. I think it is clear enough as to its basic intent (after I go back up and tweak it for conversions as you propose) without having to go into even more detail as to what might be an appropriate conversions or not; do you? For instance, this eia Web site lists many oil production conversions, among them, to tonnes. However it has no conversions to cubic meters. It seems to me that the policy would be clear as to what are appropriate conversions without having to spell it all out; would you agree? Greg L (talk) 20:21, 19 April 2008 (UTC)[reply]
Support. I agree with Greg's latest revision. Thunderbird2 (talk) 05:42, 20 April 2008 (UTC)[reply]
  • Is the text in the green box intended for insertion into MOSNUM? If so, it's a pity it's so long. And shall I copy-edit it? TONY (talk) 08:57, 20 April 2008 (UTC)[reply]
  • Tony: yes, it is intended for insertion. This guideline started as sort of a single-cell organism and evolved in complexity in order to adapt to the many challenges presented to it. As I told Dank55, I normally pride myself on being able to craft tight, pithy, one or two-sentence statements that are unambiguous and which cover an issue in its entirety. In this instance, I was at a total loss to find such powerful wording and therefore had to resort to explanatory examples. If you follow the discussion threads above, you will see that each bit of the proposal was added to address a specific concern or ambiguity in intent; Jimp, for instance, was concerned about conversions; Thunderbird2 wanted homage paid to the potential virtues of the IEC’s proposal. I think the difficulty I experienced is inherent in the nebulous nature of the subject of “units of measure” and the shear enormity of the different ways and combinations units can be employed in articles.

    As for its size: indeed, it is bigger than some other topics on MOSNUM. But, while it isn’t small, the amount of bickering that’s transpired over the years over so many units of measure is truly enormous. Had this style guide policy been in place from the beginning, it would have avoided debate (now memorialized in nearly a hundred archives) worth—literally—a thousand times its size. I would further submit that while bigger than many things on MOSNUM, it is smaller than just the Longer periods-portion of Chronological items and is about as large as Binary prefixes—a subject this addresses within it. And in the end, it has gained the support of editors with surprisingly diverse opinions on units of measure—some with rather stridently held positions heading into this. Greg L (talk) 15:52, 20 April 2008 (UTC)[reply]

Comment I don't want to get us bogged down with specifics but I'd like to see the implication that cubic metres are inappropriate for crude oil removed.

Canadians typically report crude oil production in cubic metres, whereas production in the U.S. is reported in barrels.

JЇѦρ 16:30, 20 April 2008 (UTC)[reply]

There is still "not '1.43 m3 of crude.'" Now if your source gives cubic metres, it would be appropriate to give this first with a conversion to barrels. JЇѦρ 17:11, 20 April 2008 (UTC)[reply]
  • Well, that’s a good point. Why don’t I copy that point into the proposal and get a two-fer for the effort? I’ll give it a try above. Greg L (talk) 17:23, 20 April 2008 (UTC)[reply]
  • P.S. I think that was a good point you made and addressing it greatly improved the proposal because it emphasized the point about “current literature” by dragging in the topic of quoting sources. Thus, if it’s an article about Canadian oil production, then that’s the “current literature.” Or if you are quoting a Canadian source in an article about Saudi Arabian production, it’s also cubic meters. Do you approve as now revised? Greg L (talk) 17:35, 20 April 2008 (UTC)[reply]

Oppose details While I agree with the principles of this section, I see no proof that engine displacements are generally expressed in cc. I think I saw somewhere in the earlier discussion that fanciers of older cars often used the cc to measure engine displacements for old European cars, but such a specialized group has no standing to have their eccentric terminology adopted in an encyclopedia, particularly when interest in their particular car models is overlaped by people interested in mechanical engineering or transportation in general, and those other people would be better served by litres, millilitres, or cm3.

I also oppose all use of the ton or tonne due to ambiguity; it should be metric ton, megagram, or Mg. --Gerry Ashton (talk) 16:40, 20 April 2008 (UTC)[reply]

  • *(sigh)* The important point (and the point the policy makes) is that no one says “2000 ml engine”. It’s either “2000cc engine” (improper formatting) or it’s “2000 cc engine”. It is also perfectly OK to say “an engine displacement of 2 liters.” Just because the proposal gives an example of what is appropriate, that doesn’t mean it’s the only appropriate one. And just because the proposal gives an example of what is inappropriate, that doesn’t mean it’s the only inappropriate one. As for “tonne”, it is defined quite clearly and what I have is perfectly and internally consistent with Wikipedia’s own Tonne and Kilogram articles. To make any damn progress here at all, we’ve got to begin with the assumption that Google and Wikipedia have their basic units of measurement down right. Greg L (talk) 17:08, 20 April 2008 (UTC)[reply]
  • Surely you don't mean that? (We certainly can't rely on Google!) As for Wikipedia, it's often a good starting point, but don't assume that everyone puts the same care and attention as you have done in kilogram. I rather agree with Gerry about the tonne. Regardless of the article tonne itself, I suspect that the word "tonne" is used with many different meanings on WP. Isn't it possible to choose a less ambiguous unit for your example. Thunderbird2 (talk) 17:44, 20 April 2008 (UTC)[reply]
  • Well… yes, as a matter of fact, I did mean that. Given that Google had a ready conversion for tonne and Wikipedia’s own article on tonne is clear, I thought I was a steady ground here. “Megagram” ain’t gonna fly here; though “official” it has not seen widespread adoption. Would “metric ton” be acceptable to you both? Greg L (talk) 17:58, 20 April 2008 (UTC)[reply]
The tonne should not be used in Wikipedia because
  • it is not accepted by the United States. U.S. law authorizes the Secretary of Commerce to interpret the metric system for the U.S., and the Secretary has done so: "With regard to the metric ton, this is the name to be used in the United States for the unit with symbol t and defined according to 1 t = 103 kg. (The name ‘‘metric ton’’ is also used in some other English speaking countries, but the name ‘‘tonne’’ is used in many countries.)"[3] Although many Wikipedia readers are not from the U.S., there are enough U.S. readers that we shouldn't use units that are unlawful in the U.S.
  • Readers unfamiliar with the subtleties of the various ton(ne)s might not know which version is intended by "tonne" but most of them will recognize "metric ton".
  • All that would be nice information to have in Tonne, but then, that’s probably another holy war, right? ;-) OK, will make “metric ton.” Greg L (talk) 18:05, 20 April 2008 (UTC)[reply]

Greg, was this edit what you intended? The conversion from microgals didn't seem quite right, but you seem to have inadvertently re-introduced the error. Or am I misinterpreting it? Thunderbird2 (talk) 17:37, 20 April 2008 (UTC)[reply]

The fact that "cc" appears in Google searches about cars proves nothing. With the possible exception of historical articles, Wikipedia should use modern correct usage; "cc" is wrong in modern works. The carmakers seem to agree; I have not seen anything modern from a carmaker that expresses SI displacement in anything other than litres.
  • OK, I will change it to motorcycle engines. I really, really hope we can agree that current literature on motorcycles by far and wide use cc for engine displacement? That doesn’t mean it’s kosher with the BIPM for use with the SI, or is a good thing, or is a bad thing. Just that you don’t do a reader a service by writing of a 450 cm3 engine. If we’re going to embrace the basic principal of “follow the practices in current literature,” then this is the way it’s done. Right? Greg L (talk) 18:23, 20 April 2008 (UTC)[reply]
  • Figuring out current usage is a task normally undertaken by dictionaries. I don't know what the current literature uses for motorcycle engines. If some current literature uses "cc", I suspect it would be literature aimed at motorcycle buyers. I would be quite suprised if mechanical engineers who design them used anything other than L, mL, or cm3 in their formal literature. --Gerry Ashton (talk) 23:13, 21 April 2008 (UTC)[reply]
  • Is the SI-equivalent now proper? Greg L (talk) 17:58, 20 April 2008 (UTC)[reply]
    • Yup, it's OK now, though my personal choice would have been 3.1 ks–2  ;-)

It's tonne and never metric ton in Australian English. This is what the BIPM calls it. We could certainly ban the term from articles written in US English but I'd oppose banning tonne altogether. Ambiguity can be dispelled with a link. JЇѦρ 23:20, 20 April 2008 (UTC) ... This, of course, is a moot point with respect to this example since the guideline is to "use unit symbols or abbreviations for conversions in parentheses;" therefore it should be "9.0 million barrels (1.2 t)". Note also that "1.43 million m³" is inapropriate, just as you would not write "three m³", this should be "1.43 million cubic metres" (or "... meters"), "1,430,000 m3" or "1.43×106 m3". On another point, watch your punctuation, you've got some things inside inverted commas which belong outside. JЇѦρ 23:38, 20 April 2008 (UTC)[reply]

  • Jimp, last thing first. I use U.S.-style, typographers commas; which is to say, unless it is directly quoted material or requires that something be re-typed verbatim into a computer, I keep the comma inside the quotation marks. I also use Harvard commas. I’m not going to make a federal case out of it though. If you want to sign on as a supporter, you are free to edit it like any of the other supporters. Still, I’ll go back and see if I have violated the style I just stated here; it must be consistent. As for tonne, I agree with you; I thought its meaning was clear as glass and I always have a healthy skepticism for arguments that rely upon “you can’t always believe Wikipedia.” However, a point was made that tonne is ambiguous in the U.S. (and two editors had a problem with it), so it seems that “metric ton,” which [there, I used a U.S.-style typographers comma again] is also clear as glass will also work for this example. The term “metric ton” is being used to make larger point and does not pretend to prescribe that “metric ton” is preferable to “tonne.” I’m sure editors will do what they want with tonne and metric ton. As for “1.43 million m3”, [directly quoting your text], you are correct. I’ll fix those. Greg L (talk) 00:39, 21 April 2008 (UTC)[reply]
    • Generally only the main units (i.e. not the conversions) are the ones spelt out. Thus you'd have "9.0 million barrels (1.2×106 t)” or “9.0 million barrels (1.43×106 m3)”... (of course, you could write "9.0 million barrels (1.2 Mt)”, "9.0 million barrels (1.2 Gg)” or “9.0 million barrels (1.43 dam3)”but you'd leave many readers rather puzzled). I have no objection to the change from tonne to metric ton in the above, it is only an example. I'm just voicing an objection to the statement that "The tonne should not be used in Wikipedia". As I mention, I think it should be abbreviated anyway so it'd be a moot point. Logical quotation is used on Wikipedia per WP:PUNC. Also, with respect, anyone is free to edit the page whether they support, oppose, half-support or don't care about what's written. Me, I'm growing to like it. JЇѦρ 02:37, 21 April 2008 (UTC)[reply]
  • Strongly oppose. I'm still wading through all the lime-green boxes. But unless I'm mistaken, there are serious problems here
    1. "Current literature" is rarely so monolithic as is assumed in this entire discussion. I need to look up a specific example in this regards, in an old discussion where somebody was trying to use MOSNUM rules to keep SI units out of an article, and that editor later had to admit that his own profesisonal organization recommended those very SI units.
    2. "House rules" and a consistent "look and feel" for Wikipedia have a legitimate place here.
    3. "Current literature" is often wrong. We'll end up using "ft./lbs." or something of that ilk, if we go by what the car magazines use. We don't need to be putting in a slash when there is no division involved, we don't need to add dots to our unit symbols nor modify them in the plural, just because somebody else does. Gene Nygaard (talk) 00:22, 25 April 2008 (UTC)[reply]

Footnotes digression

Comment. Something isn't working. I have attempted to apply Greg's new guideline on a number of different articles, but the success rate is patchy. One example is Mac Pro, where I cannot make head or tail of the various footnotes. The article is a mess. I will continue to try, but I fear this problem will not go away. Thunderbird2 (talk) 06:23, 21 April 2008 (UTC)[reply]

  • I would think you’d rather not let Fnagaton loose on the thing. ;-) I took a quick peek at the article and it didn’t appear that there was anything especially onorous about the article that hasn’t already been succesfully tackled thousands of times in the print edition of Mac World and (MacDailyNews and Macintouch and AppleInsider and World of Apple and Low End Mac and osxfaq and Macnn and eweek and Infoworld and Macs Only! news). If there are problems that can’t be easily fixed (too many chefs in the kitchen for too long and no harmony at all within the article), then it’s proably in need of some repair. While I’ve never owned a Mac Pro, I’m a long-term Mac user (a MacPlus happens to be the first Mac I owned) and I’ve been on Mac OS since System 4.1 / Finder 5.5. As you know, the best place to start is with Apple’s Mac Pro technical specs to look for guidance on how to communicate to that audience. On that page, they have a footnote (#3) that says “1TB = approximately 1 trillion bytes; actual formatted capacity less.” I’m sure your difficulties are a bit more complex than this though; I can help if you like. Greg L (talk) 21:50, 21 April 2008 (UTC)[reply]
    • You're welcome to try, but I don't expect it to be easy. I don't see how the footnotes can work without restructuring the whole article. Thunderbird2 (talk) 22:04, 21 April 2008 (UTC)[reply]
  • Please provide a nutshell description of just a single issue that was bedeviling you. I think Fnagaton is on a brief Wikibreak. I’ll coordinate with him and see who most feels up to cleaning up the article. Greg L (talk) 22:09, 21 April 2008 (UTC)[reply]
    • Take a look at the disambiguation footnotes. I think there are 6 in all. They are necessary because the article doesn't stick with one use for longer than about 2.3 milliseconds at a time, but in the end I fear they just serve to confuse - kinda defeats the object. Thunderbird2 (talk) 22:18, 21 April 2008 (UTC)[reply]
  • And now there are three. I see no reason they shouldn’t stick now. Greg L (talk) 00:40, 22 April 2008 (UTC)[reply]

Third draft massaged

I've rationalised and copy-edited it, including the fixing of a few MOS issues. No substantive change in meaning is intended; I've removed the explicit rationale in a few places, since it's too long (still) and the rationale is overwhelmingly obvious. I don't like the title; just how does this new text relate to the rest of the units section? It appears to cover more than just "following current literature". Why not "Principles in the choice of units"? The previous third draft appears directly underneath for ease of comparison. TONY (talk) 03:45, 21 April 2008 (UTC)[reply]

New massaged version:

NOTE: THE CURRENT VERSION IS here at “Third draft”


[Follow current literature]

In a nutshell: Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, and methods of disambiguation found in the greatest number of reliable periodicals directed to a similar readership to that to which an article is addressed. There are three important elements in the choice of units of measure for an article.

Preference for modern units
Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write "the auto weighs 1450 kg (3200 lb)", not the reverse.
Discipline-specific preference
Where a discipline consistently uses its own units—either conventional or metric rather than SI—and knowledge of the discipline requires the reader to be conversant in them, Wikipedia mirrors this practice. Thus, for example, use:
  • "a 450 cc motorcycle engine" and never "a 450 ml" or "450 cm3" auto engine;
  • "Saudi Arabia exported 9.0 million barrels of crude”, not “Saudi Arabia exported 1.43 million cubic meters of crude”;
  • "a gravity gradient of 3.1 µGal/cm", not "a gravity gradient of 3.1 × 10–6 s–2", in the science of gravimetry (unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices).
Parenthetical conversions to modern units should be given where appropriate and should generally also follow the practices in current literature on that subject, unless there is good reason to do otherwise. Both "Saudi Arabia exported 9.0 million barrels (1.2 million metric tons) of crude oil" and "Saudi Arabia exported 9.0 million barrels (1.43 million cubic meters)" are appropriate; writing "a motorcycle engine of 450 cc (450 cm3)" is not.
Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB). The IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. Use the standard binary prefixes, such as "kilobyte (KB) and "megabyte (MB)", for general-interest articles, and clarify their meaning using conventional techniques where necessary (subject to "Binary prefixes", below).
Level of difficulty (do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from, but some are appropriate only for articles for an expert readership. Thus, Planck units are generally suitable only in advanced articles for expert readers—for example, on the mathematics describing black hole evaporation—whereas an article directed to general-interest reader should describe the mass of a black hole in terms of solar mass.


Support I rather like this Tony. It’s late and I don’t have the energy at the moment, but I’d like to “borrow” the organization you used for the Discipline-specific preference section as well as some other elements. I’d still like to retain my original second paragraph (I think it is an important point that is worth reinforcing). Impressive work! Greg L (talk) 04:23, 21 April 2008 (UTC)[reply]

Previous third draft for comparison:
Follow current literature

In all cases—and within the spirit of Which system to use, above—editors should use terminology and symbols commonly employed in current literature for that subject and level of difficulty. When in doubt, use the units of measure, prefixes, unit symbols, and methods of disambiguation used by the majority of reliable periodicals directed to a given readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. For any given article, there are three important elements of choosing units of measure that best supports this mission:
Preference for modern units:
Wikipedia generally prefers modern systems of measurement such as the SI over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, we write “the auto weighs 1450 kg (3200 lb),” not the reverse.
Follow current literature:
There are, however, exceptions to the rule of using modern systems of measurement, including where certain disciplines so consistently use their own units—either conventional or metric but not SI—that for a reader to be conversant and knowledgeable in a given discipline necessitates that Wikipedia mirror its practices. Thus, it is “a 450 cc motorcycle engine” and never “a 450 ml” or “450 cm3” auto engine. Unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices, it is “Saudi Arabia exported 9.0 million barrels of crude,” not “Saudi Arabia exported 1.43 million cubic meters of crude.” In the science of gravimetry, it is “a gravity gradient of 3.1 µGal/cm,” not “a gravity gradient of 3.1 × 10–6 s–2.” Parenthetical conversions to modern units should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Both “Saudi Arabia exported 9.0 million barrels (1.2 million metric tons) of crude oil” and “Saudi Arabia exported 9.0 million barrels (1.43 million cubic meters)” are appropriate; writing “a motorcycle engine of 450 cc (450 cm3)” is not. Because existing prefixed forms of the byte are ambiguous (“KB”, for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released their IEC 60027-2 amendment introducing new prefixes for the byte and bit, producing kibibyte (KiB), kibibit (Kibit), mebibyte (MiB), etc. Unfortunately, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with “follow current literature,” editors should use the standard binary prefixes, such as kilobyte (KB), megabyte (MB), for general-interest articles and should disambiguate their meaning using conventional techniques where necessary (details subject to Binary prefixes, below).
Level of difficulty (don’t write over the heads of the readership):
For some topics, there are multiple modern systems of measurement to choose from but some would be appropriate only for articles directed to an expert readership. Thus, Planck units would generally be suitable only in advanced articles, for instance, one on the mathematics describing black hole evaporation, whereas a Wikipedia article directed to a general-interest readership would describe a black hole’s mass in terms of solar mass.
I deleted "general-interest reader should eschew"; revert me if that's not an improvement. - Dan Dank55 (talk)(mistakes) 15:19, 21 April 2008 (UTC)[reply]
  • Dank55: Thanks. That seems good too. Greg L (talk) 18:51, 21 April 2008 (UTC)[reply]
    • Megatonne edit: When I see the unit Mt I expect to be reading an article about nuclear warheads, not oil production. What you had before was better. (If you want to be unambiguous, use the teragram). Thunderbird2 (talk) 20:24, 21 April 2008 (UTC)[reply]
  • Well… I was trying to address a concern Jimp had (02:37, 21 April 2008 (UTC) post) but that seemed to have lead to yet another issue, didn’t it? Whereas “Mt” can be read as “megaton”, it is can also be read as “millions of tons”. The test shouldn’t be whether a particular editor has a jones about it, but whether the unit of measure and the unit symbols are used in real-world literature on Canadian oil production and is directed to a general-interest readership. I just now looked and it wasn’t hard to find the usage. Please see Canadian Supply Perspectives (550 KB PDF here). It uses “Mt”. Still, to address your concern and to not suggest that scientific notation is frowned upon, I added another conversion: scientific notation with the ton to the version used on this Talk page. However, while writing this, I realized that I haven't found this form in real-world usage so I haven’t added it to the MOSNUM version. If you can find frequent scientific notation-style (directed to a general-interest readership) in real-world usage like this: “(1.23×106 t)”, let me know. I didn’t plan on becoming a damned expert on Canadian oil production when I pulled “barrels of oil” out of my ass, but perhaps I should have. ;-)Greg L (talk) 21:00, 21 April 2008 (UTC)[reply]
  • P.S. Naw, I don’t want to try to maintain the slight difference. We should find out what is most common in real-world usage before stating that something is an example of an appropriate conversion or not. Greg L (talk) 21:04, 21 April 2008 (UTC)[reply]
  • P.P.S. After researching the subject of Canadian oil production and looking at actual reports, and thinking about communicating to a general-interest readership (which the oil-production reports also do), I’ve revised the proposal to reflect real-world, common-sense practices. This doesn’t mean that these are the only ways, just that they seem to be the most common at the moment. I’m certainly open to being shown evidence that there are other, quite-common methods. Greg L (talk) 21:27, 21 April 2008 (UTC)[reply]
Never under any circumstances apply a prefix to any metric mass unit except the gram. --Gerry Ashton (talk) 23:16, 21 April 2008 (UTC)[reply]
  • Good work. I didn't know the Canadians had their own measure of gravity. -- SWTPC6800 (talk) 00:00, 22 April 2008 (UTC)[reply]
  • Gerry, I would argue that one never ever concatenates prefixes. Thus, you don’t ever have megakilogram, that is why prefixes are used only with the gram. However, the SI prefixes can be tacked onto nearly anything else. The tonne, not having a prefix as part of its name is why you have all the prefixed forms of it. Again, I’m not saying that this has all the truth and wisdom of the ages embodied in it (I don’t want to get into a war over how yet another Wikipedia article has things all wrong). Anyway, I started really reading the Google hits and realized that Mt was being used not to describe the oil production, but was being used to describe the emissions caused by oil use. Indeed, the environmental movement is big on megatonnes and Mt. From what I can see, the Canadian oil industry uses cube meters and 42-gallon-equivalent barrels. So I streamlined the proposal to just mention the conversion to cubic meters. Greg L (talk) 01:34, 22 April 2008 (UTC)[reply]
  • All: I found what I think is a far better example for conversion: the Ford 351 Cleveland engine (quick, “show me” link). It handily and simultaneously address a number of issues (without explicitly saying so) and is a good example to use IMO. Greg L (talk) 02:01, 22 April 2008 (UTC)[reply]
  • I agree with the general direction of this discussion but I think that it should have been discussed more before posting it to the guide. I have a few disagreements with it.
As someone who works in the automotive industry and is from Detroit must disagree with the passages about engines. The examples given are better but technically not perfect. They are not perfect examples because technically speaking engine displacements are almost always measured in cubic inches (CID) and/or cubic centimeters (cc) and not liters. Displacement is a measurement, just like power (hp, kW) or torque (ft·lbf, N·m) and should be converted if it is given; even if it is for a European sports car. It would similar to saying that because Harley's Twin cam engines are American made their displacement measurements of 88 CID and 96 CID should not be converted to cc. This would be silly, although the Harley crowd would like it, it would be inappropriate— information should always flow both ways without restrictions or personal preferences interfering. Many people in automotive/motorcycle circles talk engine sizes in terms of cubic inches. The engines in most cars that roll off the assembly line today are named after their rounded displacement converted to liters, but not the actual true displacement itself. For example, Dodge has a 5.7 L HEMI V-8 that they publish as displacing 345.0 cubic inches or 5,654 cubic centimeters. 5.7 L HEMI is the name, not the true displacement. What would be inappropriate is to try to give a conversion every time the name 5.7 L HEMI is given (i.e. 5.7 L (345 CID) HEMI). Here's the specs from Ford on engine options for the 2008 F-150 listing displacements as 281 CID or 330 CID; and chevy's published displacements (you'll need to click on the 'engine' tab).
I would rewrite the section as "The Ford 351 Cleveland engine has a displacement of 351 cubic inches (5,752 cc)" is the proper conversion that adds clarity; writing "a motorcycle engine of 450 cc (450 cm3)" is not. “The 5.5 L Ferrari Dino V12 engine has a displacement of 5474 cc (334 CID)” is proper; writing “the 5.5 L Ferrari Dino V12 engine has a displacement of 334 cubic inches (5474 cc)” would not be appropriate in an article primarily about European-made sports cars.
Modern units?? That's like saying Islam is a modern religion when compared to Judaism and Christianity. Why not just say SI units? And I wouldn't use the auto example. I'd say: Wikipedia generally prefers SI units, over other metric units, U.S. customary units or the units from imperial system, unless common practice or common sense dictates otherwise. Unless there is a good reason to do otherwise, write “the statue weighs 1,450 kg (3,200 lb)”, not the reverse. Likewise, unless there is good reason not to, write “the provincial park is 155,646 hectares (384,610 acres), not the reverse and don't substitute square meters for hectares. I know the last part seems odd but I've seen people swap out hectares for square meters before and claim square meters are the SI unit. Another similar example I can think of is in any hurricane article, like Katrina, where pressure is recorded and reported in millibars by sources (even in the U.S., where inHg is the norm for other weather events) and then wiki editors write the pressures as 902 mbar (hPa; 26.65 inHg). The SI unit of hPa seems somewhat redundant to me considering 902 mbar = 902 hPa.
These are some changes I'd like to see to the "draft" which is "posted live". Thanks —MJCdetroit (yak) 04:11, 23 April 2008 (UTC)[reply]
  • The examples of displacements are just that: examples. Their scope and breadth of their applicability is obvious. The Harley Engine example you gave is a perfect example of Wikipedia observing the practice generally used in that industry. That’s what the policy is all about. I think you are reading the wording more broadly than what they are saying. Each is an example for that article and topic. Still, I will, however, go back and add “Honda” in front of “motorcycle” so it doesn’t carry the connotation you are concerned about.

    As for “modern units”, no, it is not like saying “Islam is a modern religion and Judaism and Christianity are not”. That isn’t remotely a valid simile and unnecessarily drags in terribly emotional issues with out any good reason whatsoever. That tactic is a metric ton of weapons-grade bullonium. People have strong, and sometimes irrational, feelings about politics (and sex, and religion, etc), and all you accomplish by gratuitously inserting those into the conversation is to lose the people who are offended, without enlightening the others, IMO. You undermine the rest of your arguments and I start tuning you out when you have to resort to such B.S. There are other modern systems of measurement that physicists and astronomers routinely used in science besides the SI. Are particle physicists supposed to start expressing the mass of sub-atomic particles in grams because MJCdetroit says Atomic mass unit aren’t allowed now? They’re not “modern” enough for you? Stephen Hawking can’t use Planck units in his calculations any more? That’s why I don’t “just say SI units.”

    As for my posting the proposal “live”, I’m simply keeping the version on MOSNUM current so editors who visit MOSNUM (but have little occasion to check out the goings-on here on Talk:MOSNUM) can know of the proposal, which is clearly marked and delineated in green as a proposal, along with an invitation for comment.

    As for how you would write “351 cubic inches (5,752 cc)”, you know, I had another editor earlier here on this page (16:40, 20 April 2008 (UTC) posting) write about how car engines are never rated in ccs. Go take it up with him. And me, for I wholeheartedly agree with him now after having made the same argument you made (yes, I understand you have “detroit” in red white and blue in your registered user name). I checked out a few articles here on Wikipedia and did a little research myself and indeed, U.S. auto manufacturers most often communicate to the public using liters of displacement nowadays when they aren’t using cubic inches. It varies with the manufacturer and the engine.

    There is also an issue of properly interpreting “logic” here. The proposal clearly only gives examples of what is an appropriate conversion in one case, and what is an inappropriate conversion in another. Nowhere does the proposal say that writing “351 cubic inches (5,766 cc)” is not acceptable. I ducked that one because it was already controversial with another editor. But I am sure there are many articles and contexts where disambiguating an American engine to cc would be perfectly appropriate—principally, where the extra precision is helpful. This policy is already bloated enough without having to be all-inclusive to satisfy every single editor who objects because their pet unit of measure wasn’t also used as an example.

    I do note this interesting tidbit about disambiguating to cc. For someone who apparently prides himself on being a car buff, you apparently took the value “351” and multiplied it by the conversion factor to obtain your “5,752 cc”. I rarely copy other people’s calculations—even other engineers—and almost always start fresh. Without even thinking about it, I started with the bore and stroke (4.000 × 3.500) to end up with my figure of 5,766 cc (351.9 cubic inches). I just now noticed our two values differ. Isn’t that interesting? I suppose either one of us could be wrong, but maybe this difference between our results speaks to the issue of why we might not want to encourage editors to start giving parenthetical conversions to high precision; especially when the auto companies simply call them “5.8 L” engines. Not every volunteer editor here on Wikipedia is an industry professional like you are.

    Finally… you wrote as follows:

They are not perfect examples because technically speaking engine displacements are almost always measured in cubic inches (CID) and/or cubic centimeters (cc) and not liters.

Who cares how they are “technically” measured?!? It only matters how displacments are typically communicated by the auto industry to the general public. Did you not get that point when you read the proposal? What I’ve stated in the proposed policy regarding displacement is quite consistent with each Wikipedia article it references, such as Ford_Cleveland_engine#351_M. I start getting really skeptical of editors’ arguments here when the very foundation of their position starts out with the apparent premise that “Well, yet another Wikipedia article is all wrong and you are right.” Sorry, that argument just isn’t working for me right now. Greg L (talk) 05:47, 23 April 2008 (UTC)[reply]
Greg, can you rephrase "That tactic is a metric ton of weapons-grade bullonium" into something more like what I said at WT:Replies_to_common_objections#No article? Not one? Also: communism: "People have strong, and sometimes irrational, feelings about politics (and sex, and religion, etc), and all you accomplish by gratuitously inserting those into the conversation is to lose the people who are offended, without enlightening the others, IMO." - Dan Dank55 (talk)(mistakes) 13:45, 23 April 2008 (UTC)[reply]
  • As a matter of fact, I can. I got up this morning to tone it down and you had proposed wording sitting here as a suggestion for me to adopt. Thanks. Greg L (talk) 14:37, 23 April 2008 (UTC)[reply]
I do apologize if my comparison to religion was misconstrued and made anyone angry. That was not my intention and I thought to myself (after the fact) that I should not have typed the first thing that came to mind especially since it involved religion. I should have found a different comparison before hitting save and turning the computer off. It would have saved me from typing this apology now. Again, I truly do apologize and I didn't mean for it to be a tactic to stir anyone's emotions, as we know, we could use a little less of those around here anyway.
I interpreted modern to mean SI and not taking into account the Planck units and other units used by physicists and astronomers (but are those systems modern or just currently used?). I don't think that there is any other way to say that but maybe there can be a link to what is meant by modern systems.
As for displacement, yes I did just convert 351 CID to cc to get the 5752 cc, but your example stated that the displacement was 351 CID, not 351.9 CID. One of my points was that displacement is a specific measurement given by manufacturers and is rarely given in liters. This is different than what a manufacturer calls or names an engine. I gave three links above demonstrating how the auto industry typically communicates this information to the general public. Each case showed a specific value in cc or CID for displacement (here's a couple more: Honda and Holden. So, whoever him was that told you auto engine displacements are never given in cc is 100% wrong (as I demonstrated in 5 links). I think what I am trying to convey is that if you are going to give an example in the style guide under "Discipline-specific preference", shouldn't that example be stated as correctly as possible? Perhaps there are better examples out there with specifications that can be referenced and still convey your point. —MJCdetroit (yak) 19:51, 23 April 2008 (UTC)[reply]
Thanks, Greg. MJC, I really don't think you need to apologize for that, because politics, sex and religion are so prevalent on Wikipedia that it almost feels like a deliberate decision by policymakers to keep things "spicy"; you can't be blamed for going with the flow. I just don't think it's helpful, myself. On another note, I'm very interested in current issues on this page but I'm going to have to take a week off, I am seriously behind in some of my wikistuff. - Dan Dank55 (talk)(mistakes) 20:13, 23 April 2008 (UTC)[reply]
  • I very much appreciate your thoughtful response MJCdetroit. Given the bore & stroke of the 351 Cleveland, you’d think they’d call it a 352 Cleveland and an encyclopedia would best say something like “…and has an actual displacement of 351.9 cubic inches (5,766 cc).” However, that is yet another holy war best left to people better versed in the subject. I also agree now with you regarding parenthetically disambiguating American-label engine displacements in ccs. I would say that calling it a “5.7 liter” engine is best thought of as a marketing label; what do you call the engine. It is “the 5.7 liter, Dodge engine.” As for precisely denoting its actual displacement, it is perfectly appropriate to state “5,654 cc (345.0 in³)”. And why is this good encyclopedia practices? Because as MJCdetroit proved it via this link to a Dodge data sheet that — at least for describing that particular Dodge engine — this is how current literature on the subject precisely describes that engine’s displacement.

    I’m sorry I didn’t pick up on that important point earlier. I suppose, like I alluded to above, a bad tone can blind people to your remaining points. Notwithstanding the “bloat” factor, I will add ccs as an appropriate parenthetical disambiguation for precisely describing the displacement of an American-label auto engine. {Quick link to “Third draft”}

    Greg L (talk) 21:27, 23 April 2008 (UTC)[reply]

About cc: I do not recognize the public relations departments at automakers, nor the auto magazines that depend on them for advertising revenue, as legitimate arbiters of correct usage. If cc is used in sources like Time Magazine, The Wall Street Journal, The Times of London, or Scientific American, fine, but auto makers aren't good enough. About applying prefixes to tonne: http://www.bipm.org/en/CIPM/db/1967/2/ says don't do it. I intend to edit the offending Wikipedia tonne article immediately. --Gerry Ashton (talk) 23:43, 23 April 2008 (UTC)[reply]
  • I think you are way in error on whether prefixed forms of the tonne are acceptable. The BIPM in their CIPM, 1967: Recommendation 2 didn’t say the SI prefixes can’t be used with tonne. In fact, they didn’t say anything about the tonne. Recommendation 2 was clearly addressing the issue that you attach SI prefixes to the gram and not the kilogram. Further, SI brochure, Table 6 (Section 4.1) (“Non-SI units accepted for use with the SI, and units based on fundamental constants”) specifically includes the tonne—along with the liter—among the non-SI units that are acceptable for use with the SI. That means with the SI prefixes too. As you no doubt know (or should know), prefixed forms of the liter (one of the other non-SI units that are acceptable for use with the SI) are perfectly well accepted throughout the world (see Litre#SI prefixes applied to the litre. Are you going to go and delete the SI table from the Liter article too? In fact, the BIPM, in their French language Réglementation Métrologique (1970) (103 KB download, here) specifically acknowledges that the prefixed forms of tonne are “becoming recognized.” And that was back in 1970! You need to settle down and familiarize yourself with the world of the SI before performing such radical changes.

    As for cc being used to accurately describe the displacement of auto engines, that is a common practice in the general-interest auto magazines. It doesn’t matter what The Wall Street Journal uses; that’s just silly. It’s the practices of the car companies and general-interest auto magazines that one looks to for guidance here. Greg L (talk) 03:18, 24 April 2008 (UTC)[reply]

P.S. Never mind on the above. I see you just reverted your own edits to Tonne. Greg L (talk) 03:47, 24 April 2008 (UTC)[reply]
When I first read the Recommendation 2, I interpreted it to mean that the only mass unit to which prefixes may be attached was the gram. Upon re-reading, I realize that the only SI mass unit to which prefixes may be attached is the gram; since the tonne is metric but not SI, that Recommendation 2 does not really apply after all. Still, I've never seen prefixes used with tonne.
As for which sources to consider in deciding if cc applies to automobiles, my feeling is that literate people need to know at least the more commonly used SI units. Once they have taken the trouble to do that, they should not be burdened by the need to learn obsolete units or abbreviations when reading general interest publications, including most Wikipedia articles. What units the general interest reader should be expected to understand is better gauged by general interst publications, such as The Times or Time Magazine than special interest publications like Road and Track or Car and Driver.
As for me not being familiar with SI, that's a load of crap. --Gerry Ashton (talk) 03:43, 24 April 2008 (UTC)[reply]
  • Gerry, when you wrote “my feeling is that literate people need to know at least the more commonly used SI units. Once they have taken the trouble to do that, they should not be burdened by the need to learn obsolete units or abbreviations when reading general interest publications, including most Wikipedia articles”, that seems to be a common sentiment among many Wikipedia editors; you’re not alone. Still, that sentiment can’t be used as an excuse for Wikipedia to effectively promote the use of the SI by writing “the Honda CB450SC had a 447 mL engine.” We subvert our mission of clearly communicating to the reader and preparing them for their studies elsewhere when we depart from standard communication practices in any given discipline in a misguided effort to achieve project-wide compliance with the SI. Some industries just aren’t there yet. Greg L (talk) 04:03, 24 April 2008 (UTC)[reply]
  • P.S. I didn’t say “[you are not] familiar with SI”, I said “[y]ou need to settle down and familiarize yourself with the world of the SI before performing such radical changes.” Greg L (talk) 04:08, 24 April 2008 (UTC)[reply]
Car and Driver magazine has a paid monthly circulation of 1.3 million and Motor Trend has a monthly circulation of 1.1 million.[4] These are general interest publications that I find in my doctors office and are for sale at my local supermarket. The Society of Automotive Engineers Automotive Engineering International is a special interest journal. -- SWTPC6800 (talk) 04:15, 24 April 2008 (UTC)[reply]
  • Thank you Swtpc6800. My stomach is getting acidic about now. Gerry, I put in ccs for auto engines because —MJCdetroit (yak) insisted it was the right thing to do. I resisted and got an acid stomach with him before I realized he is right. Then I immediately get flack from you and watch you haul off and delete “megatonnes” from all existence (since corrected). If you still have a “thing” about auto engines in ccs, I suggest you take it up with him (and maybe also Swtpc6800). I at first tried to use examples of disambiguating with oil production but ran up against more theories of what is the appropriate way to do it than you can shake a stick at. I thought doing auto and motorcycle engines would be far, far “cleaner”. However, I am now seeing that no matter what discipline I choose, there will always be someone I can’t make happy. I’m going with the consensus here on ccs and auto engines. If someone has facts to back up what they are saying that materially affects the proposal, let me know. Until then, I am entirely disinclined at this point to further debate the basic principal of the proposal by letting myself get bogged down on every petty little opinion someone has on this or that pet unit of measurement. These are examples used in a style guide for editors; they aren’t laws. Greg L (talk) 04:34, 24 April 2008 (UTC)[reply]
It seems we can all have our way. I found a New York Times scooter-related article that uses "cc", and also a micro-car-related article. I have nothing against colloquial abbreviations like cc; I just want to be sure they are accessible to general readers who are not necessarily car buffs. If it's good enough for the New York Times editors, it's good enough for me. --Gerry Ashton (talk) 04:39, 24 April 2008 (UTC)][reply]
The New York times also uses CO2 for carbon dioxide. Newspaper style isn't always appropriate for an encyclopedia. Furthermore, your acceptance of the New York Times, and your rejection of Car and Driver and Road and Track, are merely a precursor of the constant, interminable haggling about what the "most common usage in current literature" is, something we don't need. Throw the whole idea out; keep it to simple, logical rules, a consistent Wikipedia style and not an ungainly hodgepodge of different systems. Gene Nygaard (talk) 03:47, 25 April 2008 (UTC)[reply]
  • Gene, much of the “interminable haggling” on Wikipedia has been due to contributing editors who have been too anxious to exploit the power and influence of Wikipedia and use it as a soap box to promote the use of the SI after observing that (for some mysterious reason) the rest of the world isn’t doing so for a given industry. If editors just use common sense and good faith and follow the clear spirit of the policy, Wikipedia will be communicating with the readership of all our articles with minimal confusion. Even though it seems like a good idea to have project-wide consistency, we do no one a favor when we write as follows:
  1. “A 450 ml” Honda motorcycle engine”
  2. (In an article on world-wide production of crude): “Saudi Arabia exported 1.43 million cubic meters of crude”
  3. “A gravity gradient at the Earth’s surface of 3.1×10−6 s–2”
  4. (In an article on American muscle cars): “The first Mustang initially had a V8 displacing 4,728 ml but eventually, models equipped with a 5,766 ml engine became available.”
  5. “In Corvallis, Oregon, 5.62 % of residents have Ph.D.s.” (note the space between the value and the % symbol; that’s SI-compliant)
All five of the above examples are perfectly compliant with the SI. With practices like this, we would be helping to create a pure and utopian world where Wikipedia has project-wide, consistent compliance with the SI. And we would be doing our readers no service whatsoever when we diverge from the way the rest of the publishing world communicates to each of those audiences (“Hello, I was wondering if you had any fifty-centimeter-cubed motor scooters for sale?”) It’s simple: in order to communicate in technical writing to any given audience with minimal confusion, all encyclopedia’s follow current communications practices in any given art, we do not try to lead by example in hopes the rest of the world will follow. Greg L (talk) 04:39, 25 April 2008 (UTC)[reply]
Thanks at least for letting your true colors show through, and admitting that this is an anti-SI proposal, which many people would be surprised to find out after reading it once.
The "rest of the publishing world" never speaks with one voice, and we'd just asking for incessant arguments about both what that publishing world is (with some arguing that we should accept New York Times and reject Car and Driver, for example), before we even get to the point of what that publishing world says.
We'd also have incessant arguments about the scope of the discipline to which a particular rule applies. Everybody here seems to be assuming that this would be a simple proposition; I assure you that it would not be. One of the most important features of the SI is its interdisciplinary nature, something at least as important as its international nature in the grand scheme of things. Educated people in any field understand SI; we should not be throwing out that usage which everybody understands in favor of archaic, unknown, peculiar terminology known only to a few people in some very specialized field. That terminology can, of course, be mentioned—what we should not be doing is using the existence of that terminology as an excuse to exclude from Wikipedia the conversions to units which the general public including people in other specialized fields who might have there own jargon in other areas does understand.
You are also throwing out red herrings, with your "compliant with the SI" arguments. In the first place, nobody uses milliliters for engine displacement, and there's no reason why anybody should, and in particular no reason why Wikipedia should. Liters, yes, and convenionally to no more than one place after the decimal point. But we do not need this proposal to keep "4,728 ml" engine displacements out of Wikipedia. The issue isn't whether or not milliliters are part of SI nor whether or not they are the same thing as cubic centimeters.
Likewise, neither the notion that "%" is a unit symbol nor that it should be spaced are an official part of SI. But most important, our rule on not spacing the percentage sign is a Wikipedia-wide rule, not a rule based on some elusive and not-worth-chasing goal of
Address the part below, too, about using newspapers which don't use subscripts and superscripts as a guideline as to whether or not Wikipedia should use them.
What is the meaning of "that subject"? Just another place in which an obstructive editor can engage in incessant arguments and edit-warring.
What is a "level of difficulty"? Just another place to argue and tie up hundreds of talk pages with quibbling. Gene Nygaard (talk) 12:15, 25 April 2008 (UTC) originally signed 69.57.88.126 (talk) 12:11, 25 April 2008 (UTC)[reply]
"Thanks at least for letting your true colors show through" - If you cannot make reasonable arguments then don't try to make it personal. Fnagaton 09:56, 26 April 2008 (UTC)[reply]
Of course, like most newspapers, the New York Times doesn't use subscripts or superscripts for anything. Given that state of affairs, I'd just as soon see "cc" as "cm3" (but, please, none of those "ccs" several people have been using in this discussion). But in any case, it isn't particularly relevant to a decision of what we should be using on Wikipedia. Gene Nygaard (talk) 04:02, 25 April 2008 (UTC)[reply]
  • Very well. Even if they aren’t a “scooter buff” going into a Wikipedia article on scooters, they will be prepared to be one after leaving Wikipedia. Unlike the New York Times, where “cc” has no obvious definition, we editors can link to it here on Wikipedia. Now our readers can go to a scooter store and really understand what the salesperson is saying. Greg L (talk) 04:46, 24 April 2008 (UTC)[reply]
Sorry if I cause you more acid, but the way engine displacement is stated (L vs cc/CID) is not a variation in style between European, Japanese or North American models; they're almost always all given in either cc or CID no matter where the car is made (VW). Displacement (or sometimes called engine capacity) is a measurement; just like the length of the car or the pressure in the tires and like length and pressure should be converted from one system to the other.
To further my explanation, I'll use the example of the Ferrari V12 engine, which currently states "a displacement of 5.5 L (5,474 cc)". This is incorrect and even the FerraiWorld (English version) states that the type 65° V12 for the 599 GTB Fiorano has a total displacement of 366.08 CID [cc were not given] (check out the 'technical specs' for the 599 GTB Fiorano on that website). Also, the Ferrai North America states that the displacement for this engine is "5,999 cm3 (366.08 cu in)" (link to pdf here). Sorry, but even the manufacturer states displacement in CID and/or cc and not L. By the way, the most common way to abbreviate cubic centimeters and cubic inches in the auto industry is 'cc' and 'CID' (as shown in some of the links above). This is different than what SI and our guide has said to do in the past (cm3 and cu in), hence one of the reasons for this section.
I would rewrite that portion to the following:
“The Ford 351 Cleveland engine had a displacement of 351.9 cubic inches (5,766 cc)” is also appropriate for a historical, American-made engine. “The Dodge 5.7 L Hemi has a displacement of 345 cubic inches (5,654 cc)” is appropriate for a modern, American-label engine that is classified in liters. So too is “the 465 kW (624 hp) Ferrari type 65° V12 engine has a displacement of 5,999 cc (366.08 CID)[1]”. But writing “the 624 hp (465 kW) Ferrari type 65° V12 engine has a displacement of 366.08 cubic inches (5,999 cc)” would be inappropriate in an article primarily about a European-made sports car. In each case, editors should look towards current literature on that subject as disambiguations will frequently acknowledge historical as well as current practices.
I threw in an extra part about kW and hp because that Ferrari article seems to place hp first. Which for an Italian car shouldn't kW be first, right? Regards, —MJCdetroit (yak) 19:39, 24 April 2008 (UTC)[reply]
  • When I visited each Wikipedia article, I looked at what I saw and evaluated whether or not it met my “grin test.” I’m in my 50s and have been a car buff myself since 17. I’ve had editors here say they’ve never seen ccs before and wanted them deleted. I earlier had used an example of a disambiguation with oil to megatonnes (a unit used extensively by the environmental movement) and had an editor, who had never seen “megatonnes” before, delete all the prefixed versions of tonne from Wikipedia’s own Tonne article. Your arguments don’t seem to be in this class and (mostly) have a valid basis for concern. With regard to this statement you just made:

…but the way engine displacement is stated (L vs cc/CID) is not a variation in style between European, Japanese or North American models; they're almost always all given in either cc or CID no matter where the car is made…

…it seems you are suggesting that the proposal advocates disambiguating displacements in liters. Nowhere does it (clearly) do that; I was trying to reflect the obvious reality that modern engines are today often “classified” or “referred” to in liters such as the “5.7 L Hemi” or the “2.6 L Capri V6” (I owned one of those), or “the 5.8 L-class Ford engine.” You and I both know that this is true. I agree with you 110% that when one clarifies the true displacement of an engine, one does so only in cubic inches and ccs. So I just now looked above and realize that my text is not clear on that point and will revise to make it 100% crystal clear. As for Ferrari, again, I looked at the Ferrari Dino V12 article and it initially struck me as likely having been written by Ferrari buffs and it met my grin-test as being in conformance with the majority of periodicals directed to that readership. Your cited Ferrari Web site that gives cubic inches above doesn’t surprise me in the least. So I now realize that I have no valid basis whatsoever for making such a blanket statement as my last sentence above. I will delete it.

Other editors have weighed in here and proposed their own wording via their own green-div sandbox. I’ve provided you one below. Greg L (talk) 20:22, 24 April 2008 (UTC)[reply]

Follow current literature

In a nutshell: Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:
Preference for modern units
Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.
[your text here]
There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities. The “uno” was proposed to address the numbering system-dependent ambiguity inherent in expressions like “parts per billion”. Notwithstanding that many of the parts-per notations are non-compliant with the SI, the uno has found little, if any, real-world real-world adoption. Editors should therefore not use the uno to express dimensionless quantities. Similarly, because existing prefixed forms of the byte are ambiguous (“KB”, for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as “kibibyte (KiB)”, “kibibit (Kibit)”, and “mebibyte (MiB)”. However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the standard binary prefixes, such as “kilobyte (KB)” and “megabyte (MB)”, for general-interest articles and clarify their meaning where necessary using conventional techniques (subject to “Binary prefixes”, below).
Level of difficulty (do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.
I haven't read over all of the discussion since I last got my feet wet here (there's a lot of it), but I have noticed an issue with the current proposal (as it stands on the main page). "editors should use the standard binary prefixes" (referring to kB, MB, etc – emphasis mine); the word "standard" is problematic, there are a number of standards, and at least one says something contrary. Thus, it might be better to say "editors should use the more common binary prefixes. SamBC(talk) 20:27, 24 April 2008 (UTC)[reply]
It's good to see this section growing well. Fnagaton 23:06, 24 April 2008 (UTC)[reply]
This is little more than a blunt trojan horse. It's comparing apples with oranges. The binary prefix issue has exactly nothing to with any other mentioned examples. Writing "should use kB" solves exactly nothing because the dispute is about the meaning of kB. kB (Kilobyte) is part of the standard i.e., IEC 60027-2. So what is the point of this sentence anyway? Likewise, sticking to the "more common" way does not solve anything either because IEC 60027-2 isn't used for fun or because it's so good but because the old convention as used in many sources causes inconsistent and ambiguous articles. You're trying to make a rule of thumb an absolute law. --217.87.83.146 (talk) 23:45, 24 April 2008 (UTC)[reply]
With the exception of the discipline specific abbreviation of CID for cubic inches displaced, which I took the liberty of tweekin', you got close enough. Keep up the good work Greg L because discipline specific stuff has come up here a lot lately (see Pressures above). Good luck with the binary prefix stuff—you'll need a mountain of tums. —MJCdetroit (yak) 01:07, 25 April 2008 (UTC)[reply]
  • Thanks MJCdetroit. To 217.87…: The uno wasn’t created for fun either. And it addressed an “ambiguity” that resulted in thousand or million-fold errors due to the different meanings that "billion” and “trillion” have in different languages—not a five or seven percent difference. And still, editors shouldn’t use the uno because it’s not in wide use and is not generally recognized by the average reader. So too with the terms like “mebibyte”; they are also not widely recognized by the typical Wikipedia reader. This is a fact that not even a single proponent of the IEC prefixes disputed. And “teaching” it to them doesn’t do much good because the average reader won’t ever encounter the terms after leaving Wikipedia. And yet, you are still here, sniping away on this issue, citing “ambiguous articles.” Your argument simply boils down this: that this “ambiguity” problem is so severe, it justifies our continued use of terminology that hasn’t found traction in the real world. That argument simply can’t withstand scrutiny because the vast majority of other general-interest computer magazines and professional print encyclopedias like Encyclopedia Britannica and World Book and the computer manufacturers have all managed to communicate to the reader and work around the ambiguity issues using familiar terms. There are at least nine archives dedicated exclusively to endless arguments over this utter failure of a practice. You’re making a mountain out of a mole hill to justify continuing to embrace it. Argument rejected. Greg L (talk) 02:06, 25 April 2008 (UTC)[reply]
  • Greg, you can "reject" anything you want as far as changes in your position are concerned, but I hope you do not think you are in a position to declare "argument rejected" as if you are the arbiter of consensus here. The same applies to criticisms of your method (that is, putting your proposed revisions up on the main page rather than on the talk page). I think this constitutes abuse of the process, and your attempts to tell me and others who share this opinion to "cease with arguments" on this point should be met with sustained horselaughs. Jeh (talk) 01:07, 29 April 2008 (UTC)[reply]
  • The claim that "...have all managed to communicate to the reader and work around the ambiguity issues using familiar terms" is demonstrably false: see the Seagate lawsuit, among other things. Heck, even YOU were mistaken about what "GB" meant on your flash memory cards! How you can continue to claim that persistent use of an ambiguous term is effective communication is beyond me. I don't expect you to agree with me on that point, but I don't expect you to declare that consensus has been achieved on it either. Since consensus has not been achieved, you are on not just thin but broken ice in attempting to push "no IEC prefixes" in here as an extremely and obviously |pointy example, rather than continuing with the discussion on that specific topic. Jeh (talk) 01:07, 29 April 2008 (UTC)[reply]
  • It's worth noting at this point that user 217.88... has been range blocked for a week for repeated vandalism. Fnagaton 02:10, 25 April 2008 (UTC)[reply]
All: I trimmed the ‘conversions’ section way down. I think it gets the same basic point across by using fewer examples. I hope you all approve. (quick link to “Third draft” above)
Greg L (talk) 07:41, 25 April 2008 (UTC)[reply]
  • Cubic metres red herring. Let's cut to the quick here. The real interest has nothing to do with barrels. Rather, it is primarily aimed not at crude oil production but at natural gas production, with the aim of preventing Wikipedia editors from using the standard unit symbol "km3" which everyone could understand, and require the use of a language-specific symbol understood by only a select few, "BCuM" or "BCM" or "bcm" or whatever. Gene Nygaard (talk) 12:24, 25 April 2008 (UTC)[reply]
  • The mGal conspiracy. Look also at the history of gal (unit) and the edits User:Greg L has made there and its talk page, and how wrong he is in pushing the goal of eliminating accelerations in the standard "m/s²" and "mm/s²" in favor of an obsolete centimeter-gram-second unit as "mGal", not only to encourage use of this virtually unknown unit but to prevent other editors from adding SI conversions of it, the SI units which are indeed widely used for this purpose, as he has repeatedly fought for on the kilogram article, which he thinks he owns. 12:38, 25 April 2008 (UTC) <--Posted by Gene Nygaard
You trimmed her a little and she looks good! ;) —MJCdetroit (yak) 13:32, 25 April 2008 (UTC)[reply]
  • MJCdetroit: I’m glad you approve. To Gene Nygaard: Eloquently said. You got me with your “Let’s cut to the quick here” statement. You’ve exposed me and my real intentions. Darn!

    Facetiousness aside; to your first part, your claim that my aim is “preventing Wikipedia editors from using the standard unit symbol "km3" which everyone could understand”, and how it’s really aimed at natural gas production, all I can say is Wow! I’ve never even visited a Wikipedia article on natural gas production. Did you really mean to write cubic kilometers or is that a typo?

    As to your second claim that I am “pushing the goal of eliminating accelerations in the standard "m/s²" and "mm/s²"”, the policy is clear as to its intent and the wording can’t possibly be any clearer: the pros in the field of gravimetry use the gal as their unit of acceleration and a µgal/cm is the standard unit of gravity gradient. Therefore, when one writes of how scientists working on the watt balance (to develop a new standard for the kilogram) have a precision gravimeter in their lab (as Rlchard Stlener does in his lab at the NIST) for measuring gravity at the parts-per-billion level, they—like others in the field of gravimetry—use gals. That’s why proper Wikipedia policy is to use the units in current literature on that subject: so readers are well prepared for their future studies elsewhere on that subject. This new policy just expands on MOSNUM:Which system to use, which states “[editors should] use the units employed in the current scientific literature on that topic.”

    Now… with regard to what my “real interest” is, and my “pushing a goal of eliminating” this or that, and “red herrings” and “the mGal conspiracy”, what is it with you and conspiracies??? Ever since you first objected to using the µgal instead of using SI units and escalated it into a huge battle on every point you could think of objecting to (and got blocked for a week because of it), you haven’t been able to let it go. That whole episode was doubly unfortunate and unnecessary given that the BIPM has officially recognized the gal as being suitable for use with the SI since 1978. I really do hope you behave yourself here Gene, administrators were considering blocking you for life. And now you’re here spouting the same story and using the same verbiage of “conspiracies” and writing about how a straightforward, common-sense policy that ‘editors should use the units in current literature’ is really a nefarious prelude to begin deprecating the use of the SI from Wikipedia. Uhmm… no. And by the way, a “conspiracy” requires two or more editors. Who are these others that are conspiring with me? Your writings are actually a bit scary to me.

    I have this suggestion for you: go and very carefully read the proposal and pretend that there is no hidden conspiracy (just for a moment). Assume for a moment that all those who’ve been behind it (it has had the input from a lot of editors now) have worked on it in good faith. If it is nothing more than what it flat says it is and if the proponents have no other motives than what it says, then does it seem like a sensible policy to you? Remember, for this experiment, you have to assume the hypothetical I just outlined. Greg L (talk) 18:28, 25 April 2008 (UTC)[reply]

Of course I meant cubic kilometers. Do you really mean that we should require "BCuM" instead, and not allow it to be expressed in cubic kilometers? Gene Nygaard (talk) 06:25, 27 April 2008 (UTC)[reply]

Continuing discussion on Third draft

All: There has been some confusion as to what version of the proposal is being discussed. Here’s some handy links:

A good ol’ Honeywell celsius thermostat

I hope to assuage some editors here, who are ardent supporters of the SI, that I too am arguably a pretty strident supporter of the SI. Early in my engineering career when I was a father of young children, I was such an radical advocate of the SI, I wanted a celsius thermostat for my house. I called the Honeywell factory because I wanted to have the same round-style one (lathe & plaster walls you see) as I currently had. I was told they were only for sale in Canada and there was simply no way to fool around “exporting” one to the U.S. So, months later, when a friend traveled on business to Canada, I had him buy one and bring it down. “Fahrenheit sucks” was my mantra. How many people do you know who would go that far? I haven’t met any. I’ve since lightened up a tad. I did (and still do) all my engineering in metric. I convert to inches at the last minute only when prints need to go to sheet metal shops for instance. Staying metric during design is the only way to go. Fuel cells on the market today can trace the dimensions and design theory underlying their construction to metric decisions I made over a decade ago.

On Wikipedia, I can now see that there are proponents of the SI that are even more radical than I am. It never occurred to me that things like µGal, which is absolutely, without any question, the unit used in gravimetry (example here) could be a point of contention with some editors. But it is. And that’s why this policy has been advanced and worked on so intently by so many contributing editors. It is intended to start with this logical and coherent policy statement: For Wikipedia to communicate with minimal confusion to each target audience, we must teach the reader what they need to know about a given subject and prepare them as well as possible so they are primed to learn even more in their studies elsewhere. To accomplish this end, all encyclopedias—even Wikipedia with its hyperlinks—generally use the units most commonly employed in that discipline unless there is good reason to do otherwise. It makes absolutely no sense to use units of measurement here in an article about a very specific subject and have someone run off using incorrect verbiage out in the field: (“Excuse me, do you have any motor scooters for sale that have a fifty-milliliter engine?”). A lot of contentious arguments all over Wikipedia centered over truly silly practices with units of measure that violate the most basic principals of technical writing could have been avoided had this policy statement been here long ago. This new guideline expands on, and clarifies, a long-standing MOSNUM guideline: MOSNUM:Which system to use, which states “[editors should] use the units employed in the current scientific literature on that topic.”

The proposal has had input from SWTPC6800, Fnagaton, Septentrionalis PMAnderson, Dank55, Gerry Ashton, Tony, MJCdetroit, T-bird, Jimp, Caerwine, and me. In many cases, objections from these editors resulted in complete abandonment of certain examples and the adoption of entirely different ones. If you think tandem writing can be dynamic and fun, try making ten editors happy. The current proposal bears little resemblance to where it first started. And this has been entirely due to the input from you all. Given that there are such ardent supporters of all-things-SI and given that this proposal isn’t bashful about directly mentioning the IEC prefixes, it should come as no surprise that this proposal hasn’t won over 100% of the editors here.

If any editors have suggestions on how to make this proposal better, speak up. To those editors who feel Follow current literature is bad policy, speak up. To those who feel Follow current literature is good policy but the IEC prefixes shouldn’t be caught up in its drag net, speak up. I had been hoping that posting this at the end of that paragraph: “(subject to “Binary prefixes”, below)”, which is intended to address current articles and avoid edit wars with its detailed policies, would be enough to meet your desire to avoid edit wars. Maybe not.

The only reason this proposal has had the diversity of input is has seen so far is because it is posted right there on MOSNUM and is very visibly flagged as a being a proposal with an invitation for comment. Editors who oppose this policy need to cease with arguments about how Wikipedia policies or procedures are somehow being violated by inviting comments from others this way. Part of Wikipedia’s problem is that some policies on MOSNUM had been pushed through by a small minority of editors who had been extraordinarily active on Talk:MOSNUM and exploited the advantages that affords them in order to get their way on one policy or another. MOSNUM has too much been a club of the elite and privileged. By inviting as many other editors to this process as possible (those who wouldn’t normally think to click on MOSNUM’s “discussion” tab), we benefit from a wide diversity of opinion on the matter. As I stated above, the latest version is the product of a lot of input from many editors and is quite different now than when it was first posted on MOSNUM. Many errors have been corrected and concerns addressed. We need even more input from other editors and that can’t be easily accomplished when opposing editors desire to remove it from MOSNUM and move it (first) to here on Talk:MOSNUM, and (later) to a remote backwater talk sub-page, where it languishes and rots.

Discussion continues below. Greg L (talk) 22:22, 25 April 2008 (UTC)[reply]

Show of hands?

How do we move forward? Should there be a show of hands of some sort? Greg L (talk) 04:38, 27 April 2008 (UTC)[reply]

No. I'm not agreeing to anything until the process is conducted in a legitimate way: on the talk page, not strewn as half-baked proposals in the actual styleguide. It's a violation of due process. TONY (talk) 02:46, 27 April 2008 (UTC)[reply]

  • I see. Over a dozen editors have participated in crafting this but you certainly have freedom of choice in the matter. While I don’t agree that it is “half-baked”, I do agree with your choice of words that it is a “proposal.” And it is clearly marked as such in order to solicit as much comment as possible instead of limiting dicsussion to the standard crowd that frequents Talk:MOSNUM. Obviously there is a wide variety of opinion, because two editors here think voting is unnecessary and the proposal is ready to ‘go to press’ as is. Note the following (quoted from #Time to slow down, below):
…and this one:
As for me, here’s my opinion:

It’s ready for press: It’s just common sense and its wording and examples have been revised and tweaked in an effort to strike a compromise with a dozen editors. LIke Francis Schonken said, I see no problem making this part of the guideline now. Greg L (talk) 04:52, 27 April 2008 (UTC)[reply]

I support the action of User:Francis Schonken to make it a proper part of the guideline. It is ready to be used. Fnagaton 09:00, 27 April 2008 (UTC)[reply]

No, it is not. And it was already improperly used without consensus, which was part of Tony1's point. Gene Nygaard (talk) 14:59, 27 April 2008 (UTC)[reply]
Repeatedly posting the contrary when the preponderance of evidence is against you is not a valid argument. Fnagaton 16:00, 27 April 2008 (UTC)[reply]

Not ready. "Follow current literature" is a good general rule, but where current practice results in misunderstandings there is nothing wrong with allowing exceptions. "It's just common sense" is not an argument, it's a statement of opinion, and do I really need to go through all of the cases where "common sense" leads to the wrong answer? Finally, using an example (binary prefixes) that is still the subject of a separate discussion (while being nicely hidden away on a talk subpage, where those not interested won't see it) seems to me to be an obvious attempt to try to get "no IEC prefixes" into the policy while sidestepping that discussion. Regardless of what anybody thinks about the general rule, there is no consensus about binary prefixes. Jeh (talk) 21:45, 27 April 2008 (UTC)[reply]

Oppose Surely the burden to show consensus is on those who wish to have the status quo changed. A number of concerns have been raised against this proposal. Some of those have been addressed. There remain a number of fundamental concerns with the proposal which have not been addressed. The claim that there exists a "preponderance of evidence" that consensus has been reached simply lacks substance. Look at the recent page history:

it is not clear that consensus has been demonstrated;

Thunderbird

repeated failure to point to where the consensus is. I guess because it doesn't exist.

Tony

There is no consensus. JЇѦρ 02:59, 28 April 2008 (UTC)[reply]

Circa and century

I noticed that the abbreviation for circa is given as "ca." or "c." The latter is wrong, as it is the standard abbreviation for century (e.g. "4th c.") If c is used to mean "circa" then it should not be followed by a dot (e.g. c10,000 men). This is confirmed by the supreme authority on the English language, the Oxford English Dictionary. It seems to me that, as a public work of reference, Wiki must follow standard abbreviations and not invent its own. EraNavigator (talk) 21:11, 16 April 2008 (UTC)[reply]

The 1911 Britannica apparently used c. as an abbreviation for circa, and still does. Oxford DNB seems to use it too. Maybe it's not entirely wrong. Gimmetrow 00:14, 17 April 2008 (UTC)[reply]
Can we agree that ca. is a better abbreviation for circa than c., on the grounds that it is less ambiguous? Thunderbird2 (talk) 05:59, 17 April 2008 (UTC)[reply]
It's not less ambiguous. Before a number "c." is either circa or chapter, which will always be determinable by context while after a number there are many things "c." could stand for such as cent, carat, cup, though it too is usually determinable by context. If we don't allow "c." for circa then it shouldn't be allowed for century either as "cent." is a standard ans far a less ambiguous abbreviation for century. Caerwine Caer’s whines 17:40, 17 April 2008 (UTC)[reply]
Regarding today's edit recommending "ca.", it's not clear what position it's taking on the phrase "around 2000". I would be very uncomfortable at WP:GAN changing "around 2000" to "ca. 2000" in most articles. I agree that "ca. 1802" is perfectly okay in any history article, and preferred in many of them. For some people who show up to have their articles reviewed, that's the first time they run into a long list of "you can't do this, you must do that, WP:MoS says so", and it's going to cause unhelpful friction to tell them they can't use the phrase "around 2000". - Dan (talk) 18:50, 17 April 2008 (UTC)[reply]
[5] I'm not so sure we should prefer "ca." to "c." when the Britannica and Oxford DNB links above do not even list ca. as an abbreviation! Gimmetrow 04:06, 18 April 2008 (UTC)[reply]
American Heritage says "c. or ca" (no period/full stop on the second). Random FAs and GAs from WP:HISTORY turned up one "c.", no "ca." - Dan Dank55 (talk) 04:56, 18 April 2008 (UTC)[reply]
It seems I was too hasty then, so I have reverted the change I made. I have seen both myself, but I still prefer ca. over c. On the other hand I agree with Dan that "around 2000" should also be acceptable. What about a preference for either ca. or about over (say) c. or approx.? Thunderbird2 (talk) 06:14, 18 April 2008 (UTC)[reply]
No thanks; see below. Septentrionalis PMAnderson 15:02, 18 April 2008 (UTC)[reply]
  • In my experience, the standard abbreviation for century is C. I would not recognize it lower case. Even if I am exceptional, this would not make c. for circa wrong; it would not even make it ambiguous unless it were so placed that it could mean either in context. There are only 26 letters; many abbreviations will have multiple senses. Septentrionalis PMAnderson 15:00, 18 April 2008 (UTC)[reply]

The 1700s

There are two problems with: "Because expressions like the 1700s are ambiguous (referring to a century or a decade), they are best avoided." The first is that if you can find someone who uses, say, the "late 1700s" to mean 1708, I'll eat my hat. There is no ambiguity. The second is that this guideline is widely and thoroughly ignored, even in articles that have gone through WP:FAC and WP:Peer review, such as the one I'm reviewing now, Black Moshannon State Park. Indeed, if the 18th century ran from 1701 to 1800, then how else would one describe the period from 1700 to 1799? - Dan (talk) 21:26, 17 April 2008 (UTC)[reply]

Relevantly or not, I discovered not long ago that WP articles such as 1700s are currently about decades (i.e. 1700-1709) rather than centuries as I would have expected. I had a protracted discussion about it with the Years folks (Wikipedia Talk:WikiProject Years#Requested moves), but couldn't convince anyone that it needed changing.--Kotniski (talk) 09:59, 18 April 2008 (UTC)[reply]
Ugh, what nonsense, I hadn't seen that. I'll put it on my to-do list to move the pages, and if they get moved back, take it to AfD. They won't find a dictionary, manual or guide of any kind that supports that meaning of "1700s". Is there any objection to deleting the sentence above? ("Because expressions like the 1700s are ambiguous (referring to a century or a decade), they are best avoided.") - Dan Dank55 (talk) 17:35, 18 April 2008 (UTC)[reply]
Please read the discussion first. These are navigation aids, and it may well be most convenient to have them in the same format as 1710s. Septentrionalis PMAnderson 17:45, 18 April 2008 (UTC)[reply]
Please go ahead, PMA. TONY (talk) 02:24, 21 April 2008 (UTC)[reply]
These pages were thought out and discussed years ago when they were first created and more than once since then. Attempts to change them now are unlikely to achieve consensus. They are good reasons they are the way they are. Rmhermen (talk) 17:56, 18 April 2008 (UTC)[reply]
The "years ago" argument doesn't impress me at all. 1700s for a decade is bizarre. It should be addressed. TONY (talk) 14:19, 21 April 2008 (UTC)[reply]

←Sept, I trust your judgment, so fill me in; it will save everyone's time. There are three cases here; which are we dealing with?

  • Some folks didn't know that "1700s" never means 1700 to 1709, or at least that meaning wouldn't make any reasonable threshold for inclusion in Wikipedia. As always, I could be wrong, and I'll be willing to consider that if anyone can produce a single dictionary, manual, guidebook, or weekly church bulletin that supports a definition of "1700–1709".
  • Some folks knew very well, but they figured it was easier to type "1700s", and it fits nicely into certain tables. This doesn't seem that likely to me, because then they'd be apologetic, or at the very least give a helpful explanation of what they're doing, rather than saying "This article is about the decade 1700CE-1709CE. For the century CE, see 18th century", as if this were perfectly normal usage. Also, we wouldn't have that outrageous sentence that I want to delete above.
  • Once again, someone put on a tinfoil hat and declared him/herself King/Queen of the English Language. - Dan Dank55 (talk) 18:18, 18 April 2008 (UTC)[reply]
    I don't know; I wasn't there. But I suggest a fourth possibility:
    • Some people (and I am one) find use of the 1700s for the decade natural or at least permissible in the immediate context of the 1710s. They constructed these tables. Septentrionalis PMAnderson 18:25, 18 April 2008 (UTC)[reply]
The principle here IMO is that English is hard, and we have no right to make it harder than it is by making up words just for Wikipedia, or making up new meanings of words (and 1700s is functioning as a word here, one with a universal meaning), unless we really are talking about something that is special to Wikipedia. Decades are not special to Wikipedia. I would find it unfortunate, but acceptable, to keep the page names if people have gotten used to them [may need to change my mind on that ... how would we deal with people linking to 1700s expecting 1700-1799, as below?], as long as the first sentence on the page is honest: "Wikipedians have found it quicker to type "1700s" and easier to fit that into tables than "1700–1709". However, be aware that in formal English and in Wikipedia mainspace articles, no one uses "1700s" in this sense, so do not write a link as [[1700s]], always write [[1700s|the first decade of the 1700s]] or [[1700s|1700–1709]]." - Dan Dank55 (talk) 18:46, 18 April 2008 (UTC)[reply]
We disagree, then, on what is possible English. If I come across a reliable statement on the matter, I'll let you know. Unfortunately 1700s is unlikely to be listed in dictionaries. Septentrionalis PMAnderson 18:52, 18 April 2008 (UTC)[reply]
Google is fine. The first 100 hits on 1700s haven't produced any non-Wikipedia links to decades; I doubt that any of the first 10000 hits would. But wait, it gets worse. People are used to seeing wiki-linked dates around here, because of that damn decision to use links for date preference formatting. I bet if we look at "what links here" for 1700s, we will see a pile of people who reasonably thought they were wikilinking to 1700-1799, unless someone has been very diligent (sad that they had to waste the time) at correcting the links. I'm tied up with a pile of wikistuff at the moment, but I'll come back to this fight when I can. "No jargon" is one of the 6 "well-written" criteria at WP:GAN, and this is a clear case, IMO. - Dan Dank55 (talk) 19:17, 18 April 2008 (UTC)[reply]
We do. The kmajority are List of decades and year articles, linking correctly through the temlate. Most of the rest are overlinks anyway, and have a dab header to get people to the century. Septentrionalis PMAnderson 19:35, 18 April 2008 (UTC)[reply]

←I hit "500" and got for the last few links:

  1. Castledawson (links)
  2. Caladium (links)
  3. Wilisoni Malani (links)
  4. Reiner Protsch (links)
  5. Daniel's Cove, Newfoundland and Labrador (links)
  6. 1698 in music (links)
  7. 1697 in music (links)
  8. Eliphalet Chapin (links)

1698 and 1697 use templates that define "1700s" as 1700 to 1709. The other 6 articles all put brackets around 1700s assuming that meant 1700-1799. This was a random selection; if there's really any doubt what the result would be if I kept going, then I'll keep going. I'd say we have a problem. I'll come back to this when I have time. - Dan Dank55 (talk) 21:31, 18 April 2008 (UTC)[reply]

I guess I should add, I was just noticing yesterday that people had previously been giving VanTucky a hard time in his RfA for "civility issues" and I thought "oh crap, he's the nicest guy I've met here, I'm in deep, deep trouble". So I guess I should say: my "tinfoil hats" comment was probably less than civil. "Jargon" just affects me the way that vandalism affects other people; it feels like someone making unnecessary work and spreading disinformation. I totally approve of the fact that "no jargon" is one of the few WP:GAN style rules that is picked out for special enforcement; it's evil in effect, even if the intention wasn't. - Dan Dank55 (talk) 21:47, 18 April 2008 (UTC)[reply]
Ah, I took the first 50, which have a dozen or less false positives: June 27 isn't; the link to 1700s is masked by ca. 1706. Septentrionalis PMAnderson 23:04, 18 April 2008 (UTC)[reply]
Tony just said above (but it might get lost in the soup) "Please go ahead, PMA". I was thinking this discussion was dying out here, I was about to go talk on WT:DAB about creating a disambiguation page for 1700s. Are we agreed that most of the people who link to 1700s without knowing Wikipedia's ad-hoc definition are going to mean 1700–1799, and that readers will get disinformation (that 1700–1709 is meant) if they follow the link? Why wouldn't we want 1700s to be DAB page to explain what's up? - Dan Dank55 (talk)(mistakes) 02:40, 21 April 2008 (UTC)[reply]
"1700s" meaning a decade is just eccentric. We should dispense with it to avoid confusion. TONY (talk) 03:53, 21 April 2008 (UTC)[reply]
Even if we want to get rid of it (and I do!), wouldn't it be easier to get consensus for a DAB page than for deleting or re-interpreting 1700s, and wouldn't it be helpful, for a while, to have a page that explains the two usages in case people have questions about what's up? - Dan Dank55 (talk)(mistakes) 15:38, 21 April 2008 (UTC)[reply]
We don't need a dab page; we need a dab header. There are only two senses (although in fact our 18th century seems to have crept to 1700-1799); no need to make everybody click twice. Septentrionalis PMAnderson 23:44, 21 April 2008 (UTC)[reply]
My previous proposal (which was rejected by everyone, although judging from the above discussion it would probably get consensus here) was to move pages like 1700s to 1700-1709, and make 1700s a redirect to 18th century (despite the one-year offset). Anyone actually looking for the decade would be able to go there straight from the navigation table which appears on all the century pages (once the link had been changed in the template). So those seeking the century click only once; those after the decade (probably a small minority) click twice. No need for a disambiguation page for a term which in the real world is barely ambiguous at all.--Kotniski (talk) 16:29, 22 April 2008 (UTC)[reply]
Can you point me to any previous discussions, Kotniski (or anyone), other than the link you gave above? - Dan Dank55 (talk)(mistakes) 03:47, 23 April 2008 (UTC)[reply]
The link I gave above, and the discussion closely preceding it, are the only ones I know of. --Kotniski (talk) 07:54, 23 April 2008 (UTC)[reply]
What are we going to do about this then - shall we go ahead with the changes? We'd better reach consensus with the Years project people first, though, since they were mostly against the change when I proposed it there.--Kotniski (talk) 07:55, 25 April 2008 (UTC)[reply]
You ought to make a WP:RM request, notifying all the pages, and setting up discussion on one of them. This is controversial — it has been controverted here, but it may prove to be consensus all the same. Let's see what happens. Septentrionalis PMAnderson 19:21, 27 April 2008 (UTC)[reply]
I'd prefer to keep working on style guidelines at the moment, but I'll join in if a discussion starts, please let me know. WP:RM has a backlog; it might be better simply to discuss the problems with the Years people. I'm pretty sure I can get to this within a week. - Dan Dank55 (talk)(mistakes) 20:30, 27 April 2008 (UTC)[reply]

Queries

Hey folks: Greg L drew my attention to MOSNUM, a page I've been playing truant from for some time. I see that it has there have been a lot of changes this month, and I'm charged with producing a summary of substantive changes at the end of each month.

  1. Towards the end of April, it would be good to know whether the changes are stable in terms of the monthly summary.
  2. At what point does MOS need to be updated to relect these changes? At the moment, a good housecleaning is in order.
  3. I see that Crissov's edit on 6 April has made quite a major shift in terms of the default main units for non-country-related articles; specifically, that the metric system should generally be used (converted, of course, unless there's consensus not to in scientific articles). This is a change that I thoroughly agree with, and I hope that it will remain. TONY (talk) 09:07, 18 April 2008 (UTC)[reply]
    • I hope this reading was not Crissov's intent; it violates WP:ENGVAR: many articles in American English should not use metric unless about a scientific subject (where it would be idiomatic). For an obvious example, pound cake should use pound, not 450 grams. I trust an injunction not to violate idiom will be uncontroversial. Septentrionalis PMAnderson 15:05, 18 April 2008 (UTC)[reply]


My reading is that before the change:

  • US-related articles—main units US (converted to metrics)
  • UK-related articles—main units either system (converted)
  • Scientific topics—main units metric (unconverted if consensus)
  • All other articles—main units either system (converted)

Now, Anderson's recent modification is in italic below, and Crissov's change is bolded; both are fine by me.

  • US-related articles, and where idiom requires it—US units (converted to metrics)
  • UK-related articles: main units either system (converted)
  • Scientific topics—main units metric (unconverted if consensus)
  • All other articles—main units generally metric (converted)

TONY (talk) 15:53, 18 April 2008 (UTC)[reply]

  • If I were doing this from scratch, I would suggest whichever is natural on a given subject in a given national variety, and add examples. In American scientific articles (with field-dependent exceptions), this would be metric.
  • In numismatics, for example, precise values are important, and figures in the same field of study have been reported in grams (normally to one decimal point) and in grains. This may be a reason for inconsistency in detailed articles; but generally may cover this. Septentrionalis PMAnderson 17:01, 18 April 2008 (UTC)[reply]
I'm American, but I'm very comfortable with saying "prefer metric". Every country except the U.S. uses SI units for almost everything (with a few exceptions, as Sept points out), and there are lots of people in the U.S. who prefer metric to U.S. units, because there's so much movement across borders, and almost no one who's comfortable with both systems actually prefers the U.S. units. Also, SI is used consistently in science and tech and in many consumer products. I'm just guessing here, but I'd say somewhere between 100 million and 200M people in the U.S., a country of 300M, feel uncomfortable with metric units. That's in a world of 6.7 billion.
I think the important point here is that this is not a style issue; this is a "free flow of information" issue. The English Wikipedia has 2.3 million pages, but all of the Wikipedias have 10 million pages. Everyone knows that, if a conversion number is given in parentheses, you can't count on the accuracy of the second number as much as the accuracy of the first number; there will be a rounding error, at the least, and you won't be able to extract any fine-grained information from the number of significant digits used. So if the U.S. unit is given first, that makes it less likely that accurate information will travel between other Wikipedias and the English Wikipedia, or travel from or to anyone outside the U.S. - Dan Dank55 (talk) 17:07, 18 April 2008 (UTC)[reply]
One problem with prefer metric is that it can lead to our taking a source which uses customary units, doing our own conversion to metric, and then adding a conversion back to customary units. Septentrionalis PMAnderson 17:12, 18 April 2008 (UTC)[reply]
I agree, but the bigger problem with not saying "prefer metric" or "generally metric" (and being very specific about what the exceptions are) is that this conversion will happen in one direction or the other every time a new editor wanders in, which is so much worse. Better to give reasons that are easy to memorize and agree to about which is better in any given article, when possible. - Dan Dank55 (talk) 17:46, 18 April 2008 (UTC)[reply]
It would be simpler to say "when precision matters, use the units given by the source and add a conversion." (Precision doesn't always matter. If we convert "the fleet was about 400 miles west of Brest" [in 1794] into "The fleet was about 750 km west of Brest" we have not actually lost any precision; the guess wasn't that precise to begin with. Even there, leaving the original avoids the possibility of mistaken conversion; these are nautical miles.) Septentrionalis PMAnderson 18:12, 18 April 2008 (UTC)[reply]

I don't accept any connection between the variety of English used in an article, and the system of units listed first. Even though a particular variety of English is used in an article, the readership is worldwide, so the units should be metric unless the subject of the article is tied to the U.S. or U.K. If, for example, the subject of an article is beer, which has no ties to any particular country, and isn't necessarily a scientific article, the first unit of measure should be metric, no matter which variety of English it is written in. --Gerry Ashton (talk) 17:55, 18 April 2008 (UTC)[reply]

  • Wikipedia is still not a school of linguistic reform. Pints should be used where it is idiomatic; doing otherwise is a violation of our duty to communicate.(So should barrels of petroleum, in any variety of English, and for the same reasons.) Septentrionalis PMAnderson 18:12, 18 April 2008 (UTC)[reply]
  • I might feel more kindly towards this post if it did not imply that pound cake should be edited to say 450 grams; perhaps a distinction may be in order. Septentrionalis PMAnderson 18:39, 18 April 2008 (UTC)[reply]
Btw Sept, I do support what you just said. We shouldn't start randomly trashing the accuracy or validity of the sources when U.S. units are used, that's a given. I could only support a "gradual push" towards metric for anything that isn't solidly tied to the U.S. - Dan Dank55 (talk) 22:17, 18 April 2008 (UTC)[reply]
  • So, what should the wording be? I am happy with the current Crissov version; "in general" and "where idiom prefers it" seem to neatly cover PMA's points about the use of such expressions as "the four-minute mile" and "poundcake", doesn't it? TONY (talk) 03:12, 19 April 2008 (UTC) BTW, I'm confused/ignorant about the difference between US and imperial units, and metric and SI. We do need to make these distinctions, do we? TONY (talk) 03:14, 19 April 2008 (UTC)[reply]
The difference between metric and SI is that anything related to the system started during the French Revolution is metric. However, in part due to relationships between different quantities that were not understood that far back, and the tendency of any trade or profession to create it's own units and take no interest in incompatible units for the same purpose created by other trades/professions, the metric system started to head in the same balkanized mess as earlier units. SI selected a set of coherent units from the various metric units, which are intended to be the one and only set of units to be used in every trade, every profession, every country, and every language. Everyone who uses non-SI metric units has a medieval guild habit of thought.
As for the difference between U.S. and U.K. customary units, I'm only familiar wiht the U.S. ones. If confronted with U.K. units, I'll look at the SI conversion; U.K. units are on the way out and are not worth learning. --Gerry Ashton (talk) 03:33, 19 April 2008 (UTC)[reply]
I think that Tony may have gotten the "before" part slightly wrong. The last bullet of his "before"—All other articles—main units either system (converted) was never in the guide. It has always been something like: For other country-related articles, the main units are metric; for example, 37 kilometres (23 mi) and when in doubt use metric first. We're already having metric units as the preferred/main unit on the majority of articles because of the way that we set up the MOSNUM. So there really isn't a need for a gradual push—we're already doing it.
Crissov's edit just changed the order of what was being stated. Except for taking out an "imperial/" and a heading, he didn't really change what was being stated. I would have reverted all of it if the content had changed without discussion, but the message stayed the same. Speaking of a lot of changes this month, which I believe was the reason for Tony's post, should we consider fully protecting the MOSNUM to force discussions before changes are made? Tony's right. Many changes are hard to keep track for some of us and this should be a slow-to-change document.
Lastly, Dank55, here's some food for thought that may break your theory above: I am an American scientist and I use both the metric system (at work) and the U.S. customary system (at work and real life). I am "comfortable" using the metric measurements but I "actually prefer" the customary system for work and play.—MJCdetroit (yak) 03:44, 19 April 2008 (UTC)[reply]
Thanks for the correction MJC. I'm always trying to use shorter sentences, but sometimes it doesn't get the idea across. There are plenty of Americans, including myself, who feel "more comfortable" with U.S. units. When I pull up the daily weather, I would rather see degrees Fahrenheit. What I meant is that people who have a long-standing attachment to both systems tend to choose metric, because it's in wider use and it's easier. - Dan Dank55 (talk) 17:33, 19 April 2008 (UTC)[reply]
  • International system of units is rather clearer, and much less tendentious, than Gerry Ashton; we should simply link to it. Similarly, United States customary units and Imperial units describe the respective systems rather well. We don't need to write a guide; we have an encyclopedia to hand. Septentrionalis PMAnderson 03:51, 19 April 2008 (UTC)[reply]
    • Thanks to Gerry for his lucid explanation, and to PMA for directing me to those articles. The fact that UK units are "on the way out" suggests that we should not have bent to the screeching of British old-timers who insisted on the option for either (first it was more constrained for fuddy-duddy-speak, but I see that the circumstances in which it may be used have been broadened in the guideline, sadly). And thanks to MJCD for pointing out that there has been no radical change at all. Please bear in mind that I have to write a summary of changes that have occurred to MOSNUM over April, and I'm not looking forward to it. TONY (talk) 04:03, 19 April 2008 (UTC)[reply]
As to Tony’s question, I have to agree that there’s no real substantive change aside from the “all others” point, as noted by MJCdetroit. If I were writing it, though, I’d say that a better approach would be (my substantive changes italicized):
  • US-related articles—US units (converted to metric)
  • UK-related articles—main units either system (converted)
  • Scientific and technical topics—main units metric (unconverted if consensus) except where an original source or custom employs another (which should be converted to metric)
  • All other articles—main units generally metric (converted) except where idiom, custom or original source necessitates other usage (converted to metric).
This seems to me to fairly address the relevant issues. With regard to the “all others”, if we’re recommending “generally metric”, conversion would seem to be superfluous except where non-metric is employed. The added reference to “custom” in the area of scientific and technical topics captures an issue with which I have to cope regularly in the aerospace field in the U.S. In the past week alone I was asked to replace or provide conversions for kg and km to lb and ft or nm in a presentation I am drafting. Interestingly (and sadly IMHO), this request was made to satisfy young engineers as well as the graybeards – and that despite the considerable transition to metric that has been made in the field over the past couple of decades. In any case, requiring a universal change to metric in technical articles would require a massive amount of work on aircraft- and aerospace-related articles that would, ironically, result in the introduction of extensive “false-precision” in the main units of measure. (In working with numbers from Jane’s, which employs metrics preferentially and offers conversions to other systems, I am constantly amazed at the amount of seemingly precise metric values are nothing more than the illusory result of conversions of round numbers values from sources using non-metric systems. Askari Mark (Talk) 19:42, 19 April 2008 (UTC)[reply]
Seems good to me. TONY (talk) 08:49, 20 April 2008 (UTC)[reply]
We should normally convert to US conventional units (at least once even in the most technical of articles), for the sake of intelligibility; there is really is a large pool of readers whose eyes will glaze over at metric values, and another pool who will have to mentally convert.
I find Askari Mark's comments on Jane's to be depressing, but unsurprising; we should not follow suit. Illusions of precision are bad things. I would therefore add to his proposal, which seems quite sound otherwise:
  • If a quantity is exactly a round number of conventional units, express as such and include a conversion to metric. The wing is 100 ft (30.48 m) long.
Or possibly 30 meters; a design specification had better be correct to a centimeter, however. Septentrionalis PMAnderson 13:10, 21 April 2008 (UTC)[reply]
Sorry, but I don't agree with the technical part. If Jane's (or some other source) states that the wingspan of the MiG-27 is 13.8 metres, then reference that figure and use {{convert}} to convert it. {{convert|13.8|m|ftin|abbr=on}} --> 13.8 m (45 ft 3 in). Seems simple enough. However, if you can't trust your source perhaps you should look for a new source. Keep in mind that the guide does state that the "level of precision" of the converted value is dependant on the source value.—MJCdetroit (yak) 13:52, 21 April 2008 (UTC)[reply]
If the source says "30.48 m (100 ft)", it is perfectly trustworthy; merely unwise. The actual measurement they got was one hundred feet; we should treat it as we would any other sourced assertion of exactly 100 ft. Writing {{convert|30.48|m|ftin|abbr=on}} or 30.48 m (100 ft 0 in) is a misreading; we are not bots, we are editors, and we should not pretend to be as stupid as bots. Septentrionalis PMAnderson 15:17, 21 April 2008 (UTC)[reply]
MJCdetroit, Jane’s All the World’s Aircraft is considered the “bible” for information on civil and military aircraft; it’s as trusty a source as there is – of course, JAWA is certainly not “inerrant” in all respects. Its preferential use of metrics even when the original source did not, however, raises the problem of converting an already converted number. For instance, 45 ft 3 in converts to 13.8 m (rounded), which then converts back to 45 ft 3-5/16 in – over a quarter inch off. For that matter, it’s not always easy to tell when one is dealing with an already converted number in the first place. It turned out that three of the aircraft I had to provide conversions for in my presentation for work were non-UK European aircraft whose original source had been in English units of measure; I would have assumed otherwise. Accordingly, I agree with PMA that conversions of round numbers should be handled with care (although 30 m would seem a better significant-figure conversion of a round 100 ft), although I’m not sure his proposed bullet statement wouldn’t be better placed in the subsection on Conversions. Askari Mark (Talk) 04:01, 22 April 2008 (UTC)[reply]

Currencies query

(originally asked at MOS) Do the three-letter ISO currency codes go before or after the value? That is, do we write CZK 55,555 or 55,555 CZK? Shouldn't this be stated in the MOS?--Kotniski (talk) 09:53, 18 April 2008 (UTC)[reply]

It strikes me that this question just begs for generalizing a template like template:USD or template:GBP. If dated, user skins should someday be able to roughly render currencies into a user's preferred currency too using FOREX histories.LeadSongDog (talk) 18:10, 18 April 2008 (UTC)[reply]
Kotniski, common usage is that the codes precede the value. Askari Mark (Talk) 18:38, 19 April 2008 (UTC)[reply]
Right, I'll do that for now. Does the ISO have anything to say on the matter? Is there a basis for stipulating something in the MOS?--Kotniski (talk) 16:17, 22 April 2008 (UTC)[reply]
This is what the EU wants everyone to use when it comes to the euro. As seen in the table, EUR precedes the value in English but comes after it in all other official EU languages. Of course, we wouldn't have to obey this if common usage were contrary though. There's also a short and ancient discussion at Talk:ISO 4217#Before or after?. -- Jao (talk) 17:55, 22 April 2008 (UTC)[reply]
That's depressing. Brussels seems to have chosen new multiplier codes for currency use ("m EUR" for million euro, "bn EUR" for billion euro). I suppose "M" and "G" weren't creative enough for them.LeadSongDog (talk) 15:57, 1 May 2008 (UTC)[reply]

Capitalisation and pluralisation of the Erlang unit

I've just encountered the Erlang unit for the first time. The article talks of "1 Erlang" and "2 Erlangs", both of which look odd to me. (I would have intuitively written "1 erlang" and "2 erlang"). What do others think? Thunderbird2 (talk) 16:31, 20 April 2008 (UTC)[reply]

I found this definition at Rowlett's site:

  • erlang (E) a measure of telecommunications traffic density. The erlang is a dimensionless "unit" representing a traffic density of one call-second per second (or one call-hour per hour, etc.). The erlang is sometimes divided into 36 unit calls or 30 EBHC. Also called the traffic unit (TU), the erlang honors A. K. Erlang (1878-1929), a Danish mathematician who studied the mathematics of telephone networks.

That definition suggests that the unit is an erlang (1 E), with plural two erlangs (2 E). Comments? Thunderbird2 (talk) 16:36, 20 April 2008 (UTC)[reply]

SI units named after people are uncapitalised, this could explain your intuition. The unit in question, however, is not SI so whether it is to be capitalised is a matter seperate to the capitalisation of SI units. ... but now you mention Rowlett's site ... JЇѦρ 16:39, 20 April 2008 (UTC)[reply]
Those are rules of the English language, not rules of the International System of units; note that in the German language, for example, the SI units named after people are capitalized: Henry, Watt, whatever. So are the units not named after people, such as the Meter and Gram: all nouns are capitalized in German. They should be applied to all units named after people; it doesn't matter if they are SI units or not. It is also the quirkiness of the English rules in which a part of a unit which is an adjective derived from a personal name is capitalized, as in "degrees Celsius" and "degrees Rankine". Gene Nygaard (talk) 23:53, 24 April 2008 (UTC)[reply]
And note especially that, along with the change from an adjective to a noun, the old "degrees Kelvin" with an uppercase K became "kelvins" with a lowercase k. Gene Nygaard (talk) 23:57, 24 April 2008 (UTC)[reply]

Frequent changes to MOSNUM

Why is MOSNUM being changed so frequently? Lightmouse (talk) 17:54, 20 April 2008 (UTC)[reply]

Possible answers:
  • People are incorrectly applying WP:BRD rather than the rule at the top of every policy and guidelines page: "Before editing this page, please make sure that your revision reflects consensus."
  • There are a lot of people doing the right thing, namely, changing MOSNUM if they perceive that there's a strong consensus of "best" editors on WP doing something different (not gonna define "best" ... nuh uh ... but I'm talking about hundreds of editors, not a cabal).
  • There are a lot of people making changes for one of many wrong reasons; I really wouldn't know. One wrong reason that people don't always realize is a wrong reason is: changing MOSNUM because some new guideline (outside Wikipedia) came into being just this month. There's no rule that Wikipedia style rules have to constantly change; recent changes in usage outside Wikipedia could always change back, so it pays to be a little conservative rather than forcing article writers and reviewers to learn new rules every month.

- Dan Dank55 (talk)(mistakes) 18:19, 20 April 2008 (UTC)[reply]

Survey foot versus international foot

Should we include any guidance on the difference between these two? Granted, one needs to be doing conversions to 6 or more decimal places before encountering any noticeable differences in the metric conversions, but I can see the rare occasion where it would be significant. Caerwine Caer’s whines 19:26, 20 April 2008 (UTC)[reply]

Conversion of units defines 6 different varieties of foot. Is there a reason for singling out the survey foot? Thunderbird2 (talk) 19:43, 20 April 2008 (UTC)[reply]
I believe the U.S. survey foot is the only foot, beside the international foot, still in use. That said, I think foot means international foot unless stated otherwise, and no guidance is necessary. --Gerry Ashton (talk) 19:55, 20 April 2008 (UTC)[reply]
I see. Thanks for the explanation. Caerwine: is there a particular article you have in mind? Thunderbird2 (talk) 20:02, 20 April 2008 (UTC)[reply]
United States would be one such article as the square mile used for the area of the U.S. is the square survey mile. With 7 significant figures, that does make a difference in the last two digits. 3,794,066 square survey miles versus 3,794,081 square international miles. There are also a few other articles of large areas such as Asia, where the distinction matters, though in that article it looks like someone sloppily applied a Google conversion of the metric value to square international miles as I got the same value as that article now has, including an errant extra significant digit in the converted value. In survey square miles the value would be 16,915,293, not 16,915,360.3 Caerwine Caer’s whines 05:15, 21 April 2008 (UTC)[reply]
I'd agree that unless otherwise stated the foot can be assumed to be the international foot. Therefore if you see a conversion to miles, square miles, etc. you should expect that this will be the international version. Given that this is the case, why would we convert to US survey acres, square miles, etc.? It will be a concern where the original measurement was in survey miles/acres/etc.—care must be taken in converting to metric. However, in conversions from metric, I'd say we can safely ignore the fact that an alternative foot exists and convert to the international units—this will apply to (just about) every article on places outside the US (like Asia). JЇѦρ 06:43, 21 April 2008 (UTC)[reply]
While I agree an explicit conversion may be over the top, I think it's important to disambiguate in cases like this to the relevant definition (eg 3,794,081 sq mi), or similar. Thunderbird2 (talk) 07:20, 21 April 2008 (UTC)[reply]
That's probably a good idea; although I expect that the effect of mandating it would be that some good soul will "correct" to [[international mile|mi]] whichever unit has actually been used. A general caution about measurements with more than five significant figures would be helpful; liter has the same problem, since two different values can be found in the literature. Septentrionalis PMAnderson 13:18, 21 April 2008 (UTC)[reply]
I've just realised that specifying international mile doesn't help, because it just takes you to mile, so the reader is none the wiser. There needs to be something more than that. Thunderbird2 (talk) 16:47, 21 April 2008 (UTC)[reply]
I don't understand the problem with litre though. What's that about? Thunderbird2 (talk) 16:49, 21 April 2008 (UTC)[reply]
I'm assuming that PM was referring to the difference between the 1901–1964 definition of a litre as "the space occupied by 1 kg of pure water at the temperature of its maximum density under a pressure of 1 atm," which is approximately 0.001000028 m3, and the present (and pre-1901) definition of a litre as exactly 0.001 m3. Of course, if we use pre-1964 sources for extremely accurate measurements (I don't think we do this very often!), this might be an issue. -- Jao (talk) 18:03, 21 April 2008 (UTC)[reply]
Actually, not that uncommon; for one thing, our article oversimplifies: it took a decade or two for the ml and the cc to be accepted again as identical in principle. Septentrionalis PMAnderson 23:47, 21 April 2008 (UTC)[reply]

Returning to the international mile, I said before that a conversion is over the top, but I've changed my mind now. When such high precision is required, a conversion to an unambiguous unit (in this case the square kilometre) is the best solution. Thunderbird2 (talk) 20:06, 21 April 2008 (UTC)[reply]

If we have a statement in sq miles, we should quote it in square miles; doing otherwise may sweep other disagreements (what are the precise boundaries of Asia? does this include the surface of Lake Baikal?) under the rug. We should convert; and we should spedify whether we mean survey or int. miles if that is determinable. Septentrionalis PMAnderson 23:42, 21 April 2008 (UTC)[reply]

Numbers as figures or words

Is there really a dispute here? I didn't see anything on the talk page that signifies one and wonder if the tag was left in this section by mistake? Karanacs (talk) 21:07, 22 April 2008 (UTC)[reply]

I actually have something to say about it. The section header currently states: numbers of more than one digit are generally rendered as figures, and alternatively as words if they are expressed in one or two words. I remember some time ago that I was either told by another user, or I found it myself, that two digit numbers should be expressed as words in prose. Should two digit numbers not generally be written as words in prose?--十八 00:02, 23 April 2008 (UTC)[reply]
The dispute was largely between two editors who aren't around at the moment; pushing various rules of thumb ranging from spell out all numbers from zero to nine to spell out all numbers from zero to one hundred, and on the other side, use figures if spelling out would take three words or more. All these have numerous exceptions (we specify some of them), but the two editors got into a revert war over the One True Way here.
There isn't a magic rule; it depends on innumerable considerations of euphony and clarity, and varies from subject to subject (if you are discussing a large number of X, use figures: 16 aircraft carriers, but sixteen sheep). Septentrionalis PMAnderson 01:31, 23 April 2008 (UTC)[reply]
Would it be too bold to suggest that spelling out of numbers is a practice that over time should either be abandoned or (better) automated? Here's why: By avoiding numeric representation we hugely complicate every article translation task, introducing a great many unnecessary errors of fact simply for stylistic considerations. While we like to use a practice that follows existing style guides, we've chosen to follow ones which for the most part are unilingual English, not at all like the polyglot wiki environment. Ideally, I'd like to see a system of templates something like this:
{{ord|99|t}} to render "ninty-ninth", {{ord|3|T|fr}} for "Troisieme", {{ord|4|n}} for "4th", {{card|88|t}} for "eighty-eight", and so forth. Default behaviour would be to render in the specific language of the wiki, while a parameter allows other choices. Reactions? LeadSongDog (talk) 16:13, 25 April 2008 (UTC)[reply]
  • Yes. Far too bold. We exist for the convenience of our readers, not the convenience of translation bots. Septentrionalis PMAnderson 20:12, 25 April 2008 (UTC)[reply]
I have done a little work on {{numtext}}. It did cardinals before I got to it. Now it does ordinals, e.g. {{numtext|12|ord=on}} gives "twelfth". I don't see a great deal of point in making the template multilingual (though it's possible) since a template on one wiki doesn't work on another until its duplicated there. JЇѦρ 19:44, 25 April 2008 (UTC)[reply]
I'm puzzled how getting the facts correct would constitute an inconvenience for our readers. Possibly for editors, but with care, I think it could even be made fairly simple for us, as with the date rendering preferences in skins. wp:Multilingual coordination is a tricky business at the best of times. It's not helped by referring to volunteer translators as bots - please don't. I'll admit the template approach seems clunky, but it's a starting point for discussion. As Jimp's illustration with template: numtext shows, the approach is not exactly a novel idea. LeadSongDog (talk) 21:29, 25 April 2008 (UTC)[reply]
If you're talking about human translators, without bot assistance, then there is no reason at all to change our practices; humans translators must always recognise that idioms in different languages are different. Even for bots, your reason is insufficient: English idiom varies between words and numbers for many reasons, some of which we list here. Our purpose is to write for our readership, not to make a convenient pidgin for translators; we are optimized for general readers, not for specialists. Septentrionalis PMAnderson 21:48, 25 April 2008 (UTC)[reply]
  • What is "getting the facts correct" supposed to mean? There are no facts here; merely the turbulent streams of English practice, which will vary from day to day and person to person. Septentrionalis PMAnderson 21:51, 25 April 2008 (UTC)[reply]
Perhaps I was insufficiently explicit. I'm not referring to a change in what the end reader sees, but in the wikitext source that we edit. If a human translator is converting an article, say, from "soixante douze" to "seventy two", I submit they are far more likely to err in the process than if they simply copy/paste {{ord|t|72}} unchanged, so that the English wiki reader sees "seventy two" as expected. Multiply the number of times per day that a number is translated and it becomes a significant source of errors. The "facts" I referred to are simply the numbers, which are the same in all languages, as opposed to the varying rendered representations of the numbers. When we introduce errors in a translation, these errors are liable to remain undetected. There just aren't so many translators available, especially for the dozens of more obscure languages, that independent detail checks get carefully done on every translated word. LeadSongDog (talk) 06:16, 26 April 2008 (UTC)[reply]
That seems deeply insufficient. Translators who are too careless to translate "soixante douze" to "seventy two" will make dozens of other errors in the space of an article; this is why mechanized translation fails. We should not go out of our way to protect them from this one at the cost of making the article harder to read for our English-speaking readership, which is our purpose. Indeed, this will make all articles read like bad translations from the Foolandish, as the price of escaping actual error in the few which are indeed bad translations (and will still read like it). We doubtless need better translators, and more ruthless purges of badly translated text; but this is not an acceptable solution. Septentrionalis PMAnderson 15:50, 26 April 2008 (UTC)[reply]
I'm not suggesting ANY change to the text that our readers see. Just how we code it. LeadSongDog (talk) 16:20, 26 April 2008 (UTC)[reply]
Huh? spelling out of numbers is a practice that over time should either be abandoned or (better) automated. Since English usage cannot be automated (we have not even finished an informal and subjective checklist), this is a proposal to radically change present usage to never spell out. Please rephrase to what you meant to say. Septentrionalis PMAnderson 20:09, 27 April 2008 (UTC)[reply]
OK, I'll try again: I do not believe that editors should need to manually spell out numbers in one, let alone dozens of languages when editing. We have better use for their time and efforts. We should provide in software a functionality equivalent to what spreadsheets and databases have long provided, so that a date or number is recorded numerically in the source text and an editor's formatting choice causes the software to render it in the way the editor desires for presentation to the reader. This has the auxilliary benefits of facilitating translation, range-checking, style change rollouts, user preference skinning, etc. It is squarely in keeping with WP:BTW as it helps to regularize the content, yet it puts no new constraints on the styles presented to the reader, except that the chosen style must be capable of description. Play with number formats in an Excel cell for a while and you'll understand that there are very few (if any) formats we'd want to present to a reader that can't be auto-rendered. Consider the power of being able to search for and identify every article that refers to a specific date or range of dates in a single query. We don't have that now because we don't regularize the data underlying the presentation, thereby rendering translation and searches intractable. How many years now have we been unable to correctly code date ranges so the don't get messed up in one skin or another? We can and should aim to do this better. LeadSongDog (talk) 07:18, 28 April 2008 (UTC)[reply]
The key question here is: does anyone else support this? If not, it has no chance of being consensus, since at least I strongly oppose it. I will also explain my reasons for doing so once more for the record.
  • I strongly oppose the attitude that we should do anything which places costs on our millions of readers to save translators the trouble of manually typing a number, as opposed to cutting and pasting it. English conventions often exist for good reasons, and are always the expected convention. Our readers have better uses for their time and effort than to try to figure out some new-fangled convention imposed for our convenience.
  • Anybody who searches for an article by date range is a fool: there are too many other ways to express the same information (In the next ten years, During the Napoleonic era, from 1837 to 1901....).
  • The only proble with coding date ranges is the autoformatting system. That was an unwise concession to those who were squeamish about ever seeing a date in the manner to which they are not accustomed; we should treat it as we treat AD/BC or other differences in idiom. "We are large, we contain multitudes." It should be abolished. Septentrionalis PMAnderson 14:17, 28 April 2008 (UTC)[reply]
So how would you expect a reader to know 1/5/2008 from 5/1/2008 then? Contextually? LeadSongDog (talk) 14:36, 28 April 2008 (UTC)[reply]
Both should be avoided, like other forms of needless ambiguity (except possibly for an article which uses one system consistently for many dates, and has several days over 12). Months have names. Septentrionalis PMAnderson 17:58, 29 April 2008 (UTC)[reply]
If we follow that line of reasoning, today would be "The first day of May in the fifty-fourth year of the reign of Her Majesty Queen Elizabeth the Second" (to use the short form). We might discover that users find that a bit unwieldy. The article we are discussing is about "MOS:dates and numbers", not "MOS:names of dates and of numbers".LeadSongDog (talk) 16:18, 1 May 2008 (UTC)[reply]

Using a policy page as a scratchpad to develop a proposal

I have raised a MOS policy about policy changes question at the village pump. Feel free to read it and comment. Lightmouse (talk) 11:26, 23 April 2008 (UTC)[reply]

Thanks, I have responded there. On a completely different subject (probably not important enough for its own topic): does anyone object to having Miszabot do archives after 10 days after the last new comment in a section instead of 15? This talk page is running a little long. We've just dropped down to 10 days on WT:MoS. - Dan Dank55 (talk)(mistakes) 15:07, 23 April 2008 (UTC)[reply]
Quick update: I don't see any startling disagreement among Lightmouse, Kim Bruning and myself at WP:VPP. Kim believes that, contrary to what I said above, WP:BRD does apply, but on the other hand, "Before you hit submit on any edit (especially a BRD edit), you had better be sure of consensus. There's actually 4 questions you need to ask yourself before hitting submit. Here's a current discussion about that: Wikipedia_talk:Ignore_all_rules#Ignoring_the_rules_v._Ignoring_a_rule. More so than with other edits, it's important to have those 4 answers ready, because you're likely to have to answer those questions several times to several different people. :-)". Let's argue it in one place at a time, please, at the village pump. - Dan Dank55 (talk)(mistakes) 18:35, 23 April 2008 (UTC)[reply]

Proposal: Deprecate links to [As of xxxx] and delete Wikipedia:As of

In February, there was a discussion about links to [[As of xxxx]]. This issue still needs resolving. Guidance at wp:overlink already has a bullet list titled
In general, do not create links to.

I propose adding the following bullet text:

  • The phrase 'As of' followed by a date e.g. [[As of 2008]]. Such links simply redirect to the date article.

Furthermore, I propose that we delete Wikipedia:As of. I welcome comment from anyone that has read the previous discussion.
Lightmouse (talk) 15:26, 24 April 2008 (UTC)[reply]

Certainly not without any mention of this discussion at Wikipedia talk:As of. You also claim a couple of prior discussions, but I see no mention of them on that talk page, and therefore they must be somewhat tainted discussions. The people who might be using this should be made aware of the discussion, rather than the people watching MoS pages trying to dictate in a vacuum. Should be mentioned at Category talk:Redirects from "As of" (now empty, red as I create this link, you can use it to start the talk page) also. Gene Nygaard (talk) 23:36, 24 April 2008 (UTC)[reply]

And such discussions as have occurred have included the argument that this is an easy-to-maintain way to make dated assertions. WP:Overlink does impose a cost-benefit text; go see if those benefits (such as they are) are still felt worth it. Septentrionalis PMAnderson 03:35, 25 April 2008 (UTC)[reply]

An assertion does not require a link. This statement was made in 2008. See? Lightmouse (talk) 11:12, 25 April 2008 (UTC)[reply]

I tend to agree with Lightmouse that the usefulness of [[As of xxxx]] links has not been demonstrated. I would emphasize that, to the reader, [[As of xxxx]] simply tempts them to click on a link that will take them to a page that 1) typically takes a long time to load, and 2) has almost no relevance to the article they're reading. I don't monitor [[As of xxxx]] linking to direct my editing efforts. If someone does, now is the time to speak up! In addition, I also agree that continued use of 'As of xxxx' text is important for qualifying statements that date. Whether the {{update after}} template is a useful way to deal with statements that date is something of a separate issue. The point here is whether [[As of xxxx]] links add more benefit than the cost imposed on readers. I believe they do not. Noca2plus (talk) 17:25, 25 April 2008 (UTC)[reply]

I agree with Lightmouse. There will generally be no point in these links ... just more useless links. On the rare occasion where there may be a point, the year (or month & year) can be linked to directly instead of through the As of set of redirects. JЇѦρ 19:34, 25 April 2008 (UTC)[reply]

I disagree with Lightmouse. This is not the place to hold this discussion. The benefit of the template to the encyclopedia is the ease of maintenance provided by having the link, which is traceable. If there is consensus to do this at TfD, with a link to the template, more power to all of you; but it would be simpler to save the template and rewrite it (to, say, include a span id, or a link masked with a space) to address any reservations. Septentrionalis PMAnderson 19:59, 25 April 2008 (UTC)[reply]

Discussion now at Wikipedia:Miscellany_for_deletion#Wikipedia:As_of
Please make your statement there. Lightmouse (talk) 08:28, 26 April 2008 (UTC)[reply]

Time to slow down

Discussion moved from Follow current literature

Can we slow down a little? The reversal of the usual ‘gain consensus, then implement’ order has been reversed here. This fact, combined with the frequency of changes made pointed out by Lightmouse has resulted in a process and a form of words with which I no longer feel comfortable.

I propose that:

  • we wind the clock back to the latest version of Follow current literature that had consensus and start the discussion again from there;
  • we review the guideline in the light of its effect on WP articles;
  • any new discussion takes place in a new thread so that the discussion on this one subject does not take over the whole Talk page;
  • any new changes made from the point of consensus are made after discussion and not before.

Thunderbird2 (talk) 06:28, 25 April 2008 (UTC)[reply]

  • Nothing is going too fast; not in the slightest. That is an entirely separate issue though, from whether or not this proposal has morphed in a direction you no longer support. The proposal is clearly delineated in green and is clearly labled as a proposal, along with an invitation for input. It is available on MOSNUM so the widest possible spectrum of editors can be aware of its existence—including those who would not think of visiting here on Talk:MOSNUM. Any editor can create a new discussion thread (you seem to have already done so) and discuss anything they want. Greg L (talk) 06:51, 25 April 2008 (UTC)[reply]
  • I can do that if it helps, but you are missing the point. It is not my opinion that is relevant here, but consensus. The question you should be asking yourself is this: which is the latest version to gain consensus? Thunderbird2 (talk) 13:19, 25 April 2008 (UTC)[reply]
  • I see that the proposal is much simpler now than it was. That makes it easier for me to pinpoint what I don't like about the present version, which is perhaps more useful than going through the edit history. My concern right now is about the uno. I can think of no conceivable modern use of this unit, so mentioning it serves no useful purpose that I can see. Thunderbird2 (talk) 18:07, 25 April 2008 (UTC)[reply]
  • I have to take that back because I think I was looking at the wrong version. The version on the Talk page is more or less OK (apart from the problem with the uno), but the one on the main page is still problematic for me. Which is the correct one? Thunderbird2 (talk) 18:26, 25 April 2008 (UTC)[reply]
  • The one here at Talk:MOSNUM#Third draft (currently 16.3) is always maintained as identical to the green-div proposal on MOSNUM (MOSNUM:Follow current literature). I don’t see why you should have difficulty with the uno/IEC paragraph; it ends with “(subject to “Binary prefixes”, below).” That’s intended to direct editors to there for the details of handling existing articles and what not. Greg L (talk) 19:20, 25 April 2008 (UTC)[reply]
Sorry, Greg, I do believe you've got the best intentions and are doing what you see as common sense. Things are, however, going faster than I'm comfortable with. Nothing wrong with being bold and all but when your edit to a page, especially a policy page, is shown not to reflect consensus, it may be time to back down. Although there may have been improvements made, I'm not sure that any version has had consensus. A number of editors have raised concerns not only with the details of the proposal but concerns that cut to its very foundation. Not only have the concerns been raised on this talk page but the proposal (then not noted as such) was removed twice. It is certainly not standard practice to have the details of a proposal spelt out in full on a policy page. It's not something I'd like to see more of. Having notes on policy pages alerting readers that important discussions are taking place may be useful but having the details elaborated in this way could be confusing and even misleading. My preference would be to have the proposal removed until there is a version that we all are happy with if ever there is one. JЇѦρ 19:14, 25 April 2008 (UTC)[reply]
  • The proposal has had input from SWTPC6800, Fnagaton, Septentrionalis PMAnderson, Dank55, Gerry Ashton, Tony, MJCdetroit, and me (and a great deal of input from and accomodation for, you two guys). The only reason it has had such a diversity of input is because it is there on MOSNUM and is very visibly flagged as a proposal with an invitation for comment. Editors who oppose this policy need to cease with arguments about how Wikipedia policies or procedures are somehow being violated by inviting comments from others this way. Part of Wikipedia’s problem is that policies on MOSNUM have been pushed through by a small minority of editors who have been extraordinarily active on Talk:MOSNUM and exploited the advantages that affords them to get their way on one policy or another. MOSNUM has too much been a club of the elite and privileged. By inviting as many other editors to this process as possible, we are benefiting from a wide diversity of opinion on the matter. It is the currently the product of a lot of input and is quite different now than when it was first posted on MOSNUM. Many errors have been corrected and concerns addressed. There is certainly no doubt about this: the proper remedy if you oppose the policy is to post your objection and not take it upon yourself to delete what you don’t like. We need even more input from other editors and that can’t be easily accomplished when opposing editors remove it from MOSNUM and move it (first) to here on Talk:MOSNUM, and (later) to a remote backwater talk sub-page, where it languishes and rots. I will no longer respond down here. If you have a concern about the proposal, be up-front about the issue and say what’s on your mind up where the action is. Greg L (talk) 19:53, 25 April 2008 (UTC)[reply]
  • I agree with the current version of the proposed guideline addition.
    Are there still substantive comments regarding this guidance?
    I see no problem to make this part of the guideline now. --Francis Schonken (talk) 18:09, 26 April 2008 (UTC)[reply]

The text seems to have settled down a little, which makes it easier to comment again. I have read the whole thing through and find I have two comments.

The first is about the sentence "The Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 CID)" is appropriate for a modern, American-label engine that is classified in liters. As a general principle I think that any conversion should include an SI unit at one end or the other, in line with the general principle of the lead. However, while I might prefer to see mL (or cm³), I can see the logic in cc, so in the end that is not a show stopper. The real problem is the use of CID for cubic inch, when it is so much clearer to use cu in or in³. The sentence would be OK if CID were replaced with one of these two options, but I wonder whether it can’t just be deleted. Is it necessary at all?

The second comment is potentially a more serious one, because I started wondering whether the appearance of obscure abbreviations like CID might be an inevitable consequence of “follow current literature”. What is the mechanism to prevent the unit kg/cm² to be used as a unit of pressure, just because “that’s what they use in my favourite ‘Steam Weekly’ magazine”? I don’t have an answer to this question, but I am interested in the views of others. Thunderbird2 (talk) 21:01, 26 April 2008 (UTC)[reply]

  • IMO, common sense adherence of the entire policy. It says two things: 1) SI takes precedence unless there is good reason to do otherwise. And 2) if a majority of reliable periodicals that are directed to that issue (steam power), then a good case could be made that kg/cm² is best if the Wikipedia article is primarily on that subject. Your postulate (“just because “that’s what they use in my favourite ‘Steam Weekly’ magazine””) doesn’t satisfy the criteria as it is only one magazine. What is the practice observed by the majority of steam-power magazines? I don’t know the answer to that question as I’m not writing steam-related articles on Wikipedia. Clearly though, steam-power aficionados will know what the standard industry practices are. Greg L (talk) 22:12, 26 April 2008 (UTC)[reply]
    • Greg, that's precisely the point. Imagine for the sake of argument that all steam power magazines do use kg/cm2. The "common sense" of the steam buffs would tell them to use that unit, but that would result in articles that only they could understand. There needs to be a mechanism to prevent that. An explicit conversion to SI might be the solution. Thunderbird2 (talk) 16:27, 27 April 2008 (UTC)[reply]
  • I think the current version of the proposed guideline is ready to be used.DavidPaulHamilton (talk) 23:49, 26 April 2008 (UTC)[reply]

Greg, I'm not sure that it's helpful telling editors what they need to do. If people have concerns about how you're going about something, it might be benificial for all involved to take a different approach. You write

There is certainly no doubt about this: the proper remedy if you oppose the policy is to post your objection and not take it upon yourself to delete what you don’t like.

So, one editor may take it apon himself to add some policy but another editor may not take it apon himself to remove one? Surely adding a policy is not so different to deleting one. If there is something that has the weight of consensus, an editor is right to add it. If there is something that lacks it, an editor is right to delete it. Any change to a policy page is valid if it is a reflexion of consensus.

I'm not sure where you want to get with comments about MOSNUM's being a "club of the elite and privileged" where policies are pushed through by extraordinarily active editors. Any interested party has always been welcome and their voice has been heard. Whenever someone tries to push through a radically new policy, the voices tend to come.

Yes, you have listened to the concerns and suggestions of other including myself. I do appreciate that. The proposal has made improvement. I still have strong concerns though. The comment that Thunderbird2 made above about "cc" and "CID" stems from one of these concerns. Now, I too would rather see "cm³" (or "ml") as currently specified by MOSNUM. However, this is throughly ignored by those editors at work on automotive articles. I've made edits to these articles using the standard SI symbol which were quickly changed to use "cc".

Perhaps we can live with "cc" since it's familiar enough to a general readership. "CID", on the other hand, is not. The general reader will have to look it up before he knows what "CID" means—a distraction he'd better of be without. Note that the link to Cubic inch displacement#Engine displacement appears about half-way down a rather long CID disambiguation page. You've got high hopes if you expect "CID" to be always linked directly and even where it is you're (over)linking to what is, in the end, a rather mundane unit of measure. "CID" also violates a general principle against attaching information to units of measure which Gene has mentioned a couple of times.

Of course, "CID" is only one abbreviation thus why all the fuss? Thunderbird2 "started wondering whether the appearance of obscure abbreviations like CID might be an inevitable consequence of 'follow current literature'." It is the inevitable consequence of this proposal. This has been my main concern all along. "What is the mechanism to prevent the unit kg/cm² to be used as a unit of pressure ...?" This policy is the mechanism to encourage it ... given that the current literature uses this abbreviation. How do we know what is used in the literature? "[S]team-power aficionados will know" ... and will end up being the only ones who can read or write steam-power articles.

Let's stop making assumptions about who we're writing for and keep in mind that this is the encyclopædia that anyone can edit and should be the encyclopædia that anyone can read. Let's have the focus put back onto internal consistancy even though this may in certain circumstances conflict with the abbrviatoins and terminology of the literature.

JЇѦρ 02:16, 28 April 2008 (UTC)[reply]

Greg thought that the previous discussion showed a consensus of movement in a general direction, and he felt that consensus should be obvious to all, and if he was right about that, then deleting the result of all that hard work was indeed a policy violation. Only ... it happens all the time. So, the process takes more work, more patience, and a little faith that all will be well. I'm pretty sure we'll get there, wherever there is.
Jimp, I agree with what you just said. What would you like to change, if anything, in the current text on the (protected) page? - Dan Dank55 (talk)(mistakes) 02:39, 28 April 2008 (UTC)[reply]
There is so much I'd like to change, it could take up a whole new section. JЇѦρ 03:07, 28 April 2008 (UTC)[reply]

Numbers as words or numerals when converting

I have been trying to find a definite ruling on this but failing. The MOS says use words for low numbers and provide metric/imperial conversions. The convert template forces numerics and the all words version does not look right to me. The word with a numeric conversion looks good but goes against the use words rule.

  • 5 miles (8 km)
  • five miles (eight kilometres)
  • five miles (8 km)

Any suggestions? MortimerCat (talk) 07:07, 25 April 2008 (UTC)[reply]

I agree. TONY (talk) 15:02, 25 April 2008 (UTC)[reply]
Discussion of having {{convert}} handle numbers as words have taken place. The feature is not yet available but it is intended that it will be. I too prefer the third one, which would be how the template would do things when the feature is added. The second is against the guideline which states that parenthetical conversion should be given using unit symbols/abbreviations (where possible). The first is how {{convert}} does things now but not against the rules as I read them for I'd always taken it that this applied to plain numbers rather than measurements. JЇѦρ 18:11, 25 April 2008 (UTC)[reply]
If you're keeping track, Jimp, please let us know when {{convert}} handles words. Even though "5" could be a MoS breach there, the template is so handy that I haven't had the heart to tell anyone at the GA level not to use it. - Dan Dank55 (talk)(mistakes) 17:34, 27 April 2008 (UTC)[reply]
I am keeping track. I'll let you know ... I'll try not forget. I'd always taken it that "5 mile" was acceptable. JЇѦρ 23:52, 27 April 2008 (UTC)[reply]

Vote to keep, delete or amend Wikipedia:As_of

Please vote to keep, delete or amend 'Wikipedia:As_of' as you think best. Please go to Wikipedia:Miscellany_for_deletion#Wikipedia:As_of
Lightmouse (talk) 16:13, 26 April 2008 (UTC)[reply]

Big money

Is there a stylistic preference between saying "$58 million" or "58 million dollars"? —Josiah Rowe (talk • contribs) 17:43, 26 April 2008 (UTC)[reply]

I suppose the second one is not wrong, but why would you normally bother? The dollar sign is so recognisable and makes for easier reading. TONY (talk) 08:03, 27 April 2008 (UTC)[reply]
That was my feeling as well — someone changed the former to the latter, and I wanted to make sure that there wasn't some reason for spelling out "dollars" that I was missing. —Josiah Rowe (talk • contribs) 05:43, 28 April 2008 (UTC)[reply]

this huge green box in the middle of MOSNUM

It's been there for some time. It's not a legitimate entry, since it is a proposal. Simple as that. It should be removed until consensus is gathered and confirmed.

Are we starting a new practice in which anyone can come along and insert large green boxes of proposals in the actual styleguide? That would lead to chaos.

Please REMOVE it now and continue the discussion—and post the green box—on the TALK PAGE, where it should have remained the whole time. TONY (talk) 02:44, 27 April 2008 (UTC)[reply]

  • It started as a green-divi box here on Talk:MOSNUM and remained that way until interest flagged and progress ground to a halt. The number of editors weighing in was limited only to those who frequent Talk:MOSNUM; which is to say, far too few editors. The only reason this proposal has had the diversity of input is has seen so far (over a dozen editors) is because it is posted right there on MOSNUM and is very visibly flagged as a being a proposal with an invitation for comment. Part of Wikipedia’s problem is that some policies on MOSNUM had been pushed through by a small minority of editors who had been extraordinarily active on Talk:MOSNUM. Talk:MOSNUM has too much been a club of the elite and privileged who might feel like they represent the views of many editors but they haven’t been elected to their positions. By inviting as many other editors to this process as possible (those who wouldn’t normally think to click on MOSNUM’s “discussion” tab), we benefit from a wide diversity of opinion on this proposal. The latest version is the product of a lot of input from many editors and is quite different now than when it first began here on Talk:MOSNUM. Many errors have been corrected and concerns addressed. We need even more input from other editors and that can’t be accomplished if it was to be removed from MOSNUM and moved (first) to here on Talk:MOSNUM, and (later) moved to a remote backwater talk sub-page, where it languishes and rots. Greg L (talk) 05:07, 27 April 2008 (UTC)[reply]
Like Tony said, the "proposal" in the green box does not belong on the project page. I'll remove it. Gene Nygaard (talk) 06:41, 27 April 2008 (UTC)[reply]

There's enough consensus on the update itself (see above), so it can go in without the green box as far as I'm concerned. I'll act accordingly. --Francis Schonken (talk) 06:56, 27 April 2008 (UTC)[reply]

Agree Francis, there is enough consensus. Fnagaton 11:48, 27 April 2008 (UTC)[reply]
Proposals just don't belong as pre-emptive actions on the page they might apply to after consensus is generated. Simple as that. Apart from the other issues, there's the practicality of not introducing instability—that's what talk pages are for. TONY (talk) 08:01, 27 April 2008 (UTC)[reply]
This, in my view, has been a very bad precident. Proposals spelt out in full have no place on policy pages—no matter how good you might believe your intent to be. Sure, by taking this approach you've got a number of editors involved: the green box took the limelight. The approach focused attention on the proposal, did it do so at the expense of other discussions which had been progressing in a more conventional fashion? The proposal has been removed, as a number of editors including me had called for. I hope we don't see this kind of approach taken again. JЇѦρ 23:44, 27 April 2008 (UTC)[reply]

Spurious "American"/"non-American" (or "British") divide

This page several times posits a divide between "American" and non-American" (or British) usage. I would make three related points about that:

  1. the divide is totally spurious and tends to rest on an assumption that British or "Commonwealth" forms are normal for "non-Americans", which is not correct. There are actually a lot of different forms of English grouped under Commonwealth English and Canadians, for instance, often use "American" forms, rather thjan anything that might be called "Commonwealth English" (or (non-American English).
  2. Styles like (e.g.) "Month-day" are not "American"; that is the format used, for instance, in Australian newspapers and magazines.
  3. British English and American English, in fact, have commonalities that are not shared by other forms, such as an aversion to the metric system and the use of "-ize", whereas -ise is almost universal in other countries (e.g. Australia)

Grant | Talk 03:25, 27 April 2008 (UTC)[reply]

1. I agree; Canadians and their queen must be puzzled by the term "Commonwealth English". It's a straighjacket term that should be avoided. 2. Only some Australian publications use the month day comma year format, and why they do so is beyond me; elsewhere in that country, the neater, more streamlined format is used, as in the UK. 3. "-ise" has become much more common in the UK, despite the refusal of the OED to swap its first and second spellings. The zed is fast becoming a hallmark of North American spelling. TONY (talk) 08:08, 27 April 2008 (UTC)[reply]

  1. No comment
  2. Month-day-year is such a daft order that I fail to see how it ever took root. It appears that it has done so nevertheless. I have the impression that it is rare outside the USA.
  3. "-ise" has always been the norm in the UK. Well, "always" is a long time ... at least since the 1970s, but I suspect much longer than that.

Thunderbird2 (talk) 08:59, 27 April 2008 (UTC)[reply]

"Month day, year" is simply an abbreviation of "April the 27th, 2008", which is not in any way "American". I have worked as a journalist in both Australia and the UK and I can assure you that "M D, Y" is almost universal in the print media in Australia. It is also frequently used in the UK, such as the datelines at the top of news stories (e.g. a story from today's Observer). Grant | Talk 13:14, 27 April 2008 (UTC)[reply]

I think one big problem is rather the assumption that there is a monolithic Youess and a monolithic Youkay way of doing things, and that once these are written down in a coherent sort of way then Youessians and Youkayans (if nobody else) will be happy.

It clearly ain't so. Let's look at the Youkay. For one thing, while -ise (where at all possible) is indeed the preferred spelling of many Britionaries and Brits, -ize is preferred by the OED and many other Brits.

I find "month-day-year" absurd but the Guardian seems to use it consistently.

Brits in general don't seem to like the metric system for distances, speeds, quantities of beer, and certain other purposes, and I rather guess that the Daily Mail demographic doesn't like it at all; but other Brit groups seem to get on well with it.

And those are just a few of the Brit-internal inconsistencies. There are more. And I'd be surprised if there weren't analogous inconsistencies in the US and A. -- Hoary (talk) 14:17, 27 April 2008 (UTC)[reply]

It is certainly inaccurate to say there are only a US or UK way of doing things. Also, in the US certain things like pop are inconsistent. Cans of pop are measured in ounces, where as bottles sized one liter+ are measured in liters. So maybe a topic specific styles should be used. The basic goal should be to clearly communicate the facts. Rds865 (talk) 17:04, 1 May 2008 (UTC)[reply]

Was there consensus for the huge green box?

What is consensus?

I certainly would have liked notice that it was to be implemented. I see things I don't like, such as:

  • "Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:"—What on earth is that first sentence doing there? There's quite enough ministering to the masses below: "... Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline".
  • There are continual MOS breaches in the curly quotes, which I've changed TWICE already, which pisses me. I think for this reason alone, the text needs to be removed until it complies. I intend to do so later today.
  • "Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise." "Also" is redundant, and a comma is probably better before "unless".

Now these are examples of why text should not be shoved into important and influential pages without due process, and certainly not without notice and a deadline so people can fix it up. TONY (talk) 08:44, 27 April 2008 (UTC)[reply]

It is clear ("which pisses me") and from your "get a life" comment from earlier you are angry about something. I suggest you take a break and do something else instead of making edits when you are angry. Fnagaton 09:05, 27 April 2008 (UTC)[reply]
I suggest you take an ice-bath. TONY (talk) 09:27, 27 April 2008 (UTC)[reply]
I do when I go to the volcanic spa, they're very good for the circulation. Fnagaton 10:11, 27 April 2008 (UTC)[reply]
  • You as individual might disagree but you cannot hold up the process of consensus with your own personal opinion. Don't insert disputed tags into the guideline that you do not have support for. Fnagaton 12:50, 27 April 2008 (UTC)[reply]
No, there is absolutely no consensus. There isn't even consensus on whether or not we should have a "show of hands", let alone on the proposal itself. Gene Nygaard (talk) 15:06, 27 April 2008 (UTC)[reply]
The same reply to Tony applies to you: You as individual might disagree but you cannot hold up the process of consensus with your own personal opinion. So yes there is consensus, just claiming there isn't despite the preponderance of evidence against your personal opinion does not mean you can add the disputed tag. I'm going to give you one chance to post substantive objections. If you do not then you have no valid reason to add the disputed tag and your edit will be reverted. The same goes for Tony. As Francis Schonken points out there is "enough consensus on the update itself ". Fnagaton 15:33, 27 April 2008 (UTC)[reply]
Um ... where is it? Point to it, please. TONY (talk) 16:44, 27 April 2008 (UTC)[reply]
"Um ... where is it? Point to it, please." - Is not a substantive objection because it is just repeating the contrary without supplying any evidence and despite the preponderance of evidence on this page that is against your position. For the avoidance of doubt the consensus is demonstrated by the whole of the text on this page relating to this topic. Fnagaton 16:52, 27 April 2008 (UTC)[reply]
  • [edit conflict] It really is the height of arrogance to issue directives such as "I'll give you one chance". What a nerve; NEWSFLASH naggy—I'm not your servant. Now this situation is not going to repair itself any time soon. Something's going to have to crack, and it won't be me or the others who are gobsmacked at the jackboot methods being employed here. TONY (talk) 16:40, 27 April 2008 (UTC)[reply]
  • "It really is the height of arrogance..." etc - Is not a substantive objection because it is it doesn't supplying any evidence and is that is despite the preponderance of evidence on this page that is against your position. Since Tony has not supplied a substantive objection he demonstrates that he has no valid argument for placing the disputed tag on the page. Fnagaton 16:52, 27 April 2008 (UTC)[reply]
Tony, are you saying that in the current discussion, the weight of both sides (considering both "votes" and "strength of the arguments", subjectively) is roughly equal, or are you saying that there's a larger consensus on style guidelines pages not to make "half-done" changes? In the discussion that Lightmouse took to WP:VPP, WP:VPP#Using a policy page as a scratchpad to develop a proposal, Kim said (without challenge) that all the relevant policy discussions have concluded that the process "breaks" when you tell people, "Don't edit before you discuss". I'm not taking a position; I'm just saying I don't think people will let us do that. It seems to me your monthly summaries are quite the elegant solution. I don't know many reviewers (FA, GA, whatever) who participate in style guidelines discussions; I doubt that day-to-day instability on this page will make one bit of difference to them, but tidying things up (if possible) before the next monthly summaries come out would be great. - Dan Dank55 (talk)(mistakes) 16:37, 27 April 2008 (UTC)[reply]
Especially the many reviewers who do not read or consult this page, and make objections which are contrary to long-established and quite stable recommendations here. Septentrionalis PMAnderson 19:51, 27 April 2008 (UTC)[reply]
      • On the contrary, it is the height of arrogance when you claim to have "votes" on this, when in fact you went out and asked if we should have a vote on it, and haven't even gotten to the point of consensus on that question yet. Gene Nygaard (talk) 17:18, 27 April 2008 (UTC)[reply]
  • "On the contrary, it is the ..." etc - Is not a substantive objection because: 1) It is not a fact "you [I] went out and asked if we should have a vote on it". Since your claim is factually inaccurate then your conclusion is incorrect. 2) "and haven't even gotten to the point of consensus on that question yet." is inaccurate because the independent editor, Francis, came along and summarised "There's enough consensus on the update itself (see above)...". Since neither of your claims are a substantive objection and since nothing Tony has posted is a substantive objection then that means both of you have no valid reason to add a disputed tag to the guideline. Fnagaton 17:31, 27 April 2008 (UTC)[reply]
Tony, I agree that guidelines need to go light on "ministering" as you say, but I like the sentence you hated, because not understanding that (or understanding and disagreeing) is exactly what creates the problem that this new guidance addresses. I wouldn't mind if you want to try tweaking the tone of it. - Dan Dank55 (talk)(mistakes) 17:27, 27 April 2008 (UTC)[reply]
Thunderbird2, regarding your change comment. I "gave Tony his chance" (and Gene also had a chance) and instead (see above) Tony chose to be uncivil and Gene misrepresented the situation. As such I have reverted their changes to add the disputed tag. Fnagaton 17:36, 27 April 2008 (UTC)[reply]
STILL waiting to be told where the consensus is ...'. Without consensus, the inserted text must be removed. TONY (talk) 17:47, 27 April 2008 (UTC)[reply]
I told you where the consensus is in an earlier edit, do not misrepresent the situation. Do not remove large sections of the guideline without getting consensus for those changes. Do not act against the consensus demonstrated on this talk page. Fnagaton 17:55, 27 April 2008 (UTC)[reply]
I must be blink: I don't see where you've done anything of the sort. I want to know WHERE THE CONSENSUS IS LOCATED. TONY (talk) 18:19, 27 April 2008 (UTC)[reply]
I already told you, it is shown on this talk page, in the sections above. Like Dank55 says below "The fact that this discussion went on for so long, with so much editing and so much input, does suggest to me there's a consensus". The fact is a different outside editor comes along, reads what has been going on and says "There's enough consensus on the update itself" disproves what you have been saying about "no consensus". By the way, consensus does not mean you have to agree with the changes, especially when you use your talk page to make personal attacks and then blank the page. Fnagaton 18:32, 27 April 2008 (UTC)[reply]
Before responding I would like to thank Greg for his efforts in taking us this far. He has put a tremendous amount of energy into ‘Follow current literature’, and it has not always been an easy process, either for him or the rest of us involved. Has he attempted to address our concerns? Emphatically, yes. Has he incorporated a wide range of views from many different editors into the text. Yes. Has he gained consensus? I honestly don’t know. If you look at the discussion in detail, you will see that Tony is the latest of several editors to have expressed concerns about the process that got us here. In my view, that fact alone is enough to justify the ‘disputed’ banner until we sort this out. Thunderbird2 (talk) 18:47, 27 April 2008 (UTC)[reply]
  • To those who like to impose their views on others and act as censors by deleting a guideline they don’t agree with: Please stop pretending that your problem lies with the manner in which the this guideline was adopted or that a consensus hadn’t been reached. Francis Schonken stepped in after seeing Gene Nygaard improperly delete the guideline. Francis had earlier posted a comment on my talk page (Re. MOSNUM) that reads as follows:

A rough consensus seems to have formed.

Discussion seems to be style improvements of the wording now primarily (and "too long"/"too short" kind of comments) - nothing substantive to the core of the matter of this being a useful idea to be added to mosnum.

Yes the procedure was somewhat unusual. Nothing inappropriate or whatever though, congratulations!

Right there in Francis’s stated reason is the common-sense evidence the rest of us already know. How did Francis determine a “rough consensus” had been reached? Simply by looking at the totality of the contributions that had gone on (12.1–12.6, above). Just like Francis said, the contributing editors who were weighing in on helping to craft the new policy had long been focusing just on the details used as examples; there was clearly a “rough consensus” as to the basic, common-sense principal it conveyed. Most of these contributing editors who helped craft the guideline simply wanted to help on what they saw was just too much common sense as they believed it would make Wikipedia a better place; they have little stomach for all the conflict that accompanies guidelines that tread on the toes of the vocal minority. Greg L (talk) 18:50, 27 April 2008 (UTC)[reply]
Okay, I understand from this that you were talking about what Gene did, Greg. Thunderbird and Tony seem to me to be saying that, if we've reached consensus, they can't tell exactly where it's landed. I think the recommendation for a vote on particular points that we might disagree on is a good one. - Dan Dank55 (talk)(mistakes) 19:03, 27 April 2008 (UTC)[reply]
I see Thunderbird just added a "disputed" tag; please don't edit-war over this, guys, it's a non-issue, just like page protection is a non-issue, as long as there's vigorous discussion that gets resolved in a few days. All the more reason to identify the points of contention and vote (or !vote :) - Dan Dank55 (talk)(mistakes) 19:13, 27 April 2008 (UTC)[reply]
  • Dank55, Francis Schonken seems to be a wise and highly experienced editor who had been uninvolved here until the last minute. He has Wikipedia’s interests at heart. HIs conclusion that a “rough consensus” had been reached was based simply upon the application of a common-sense analysis of the totality of the edits and discussion that had occurred. Nothing more is needed. To the rest of us, the fundamental point of the new guideline isn’t at all controversial and is just the application of common sense in how one communicates to its readership; the only tough part was in agreeing upon the details of the examples used. Unfortunately (or fortunately) the rest of us haven’t the stomach for all the bickering that the vocal minority are so anxious to engage in. Greg L (talk) 20:22, 27 April 2008 (UTC)[reply]
I read the "rough consensus" the same way. The straw poll works for me, if people interpret it as "do you want to move forward roughly along these lines?", but we want to follow that by any polls needed to iron out precise wording, then finish with a "can everyone live with this?" poll. - Dan Dank55 (talk)(mistakes) 20:39, 27 April 2008 (UTC)[reply]
  • No, I'm looking for the consensus that this Fnagaton person keeps loudly asserting exists. "in the section above" doesn't help me to locate it (I suspect it simply doesn't exist". At this stage, I'm looking not for rough consensus, but a posting of the exact proposed text HERE, not on the project page, and a call for consensus ON THAT TEXT. Rough will not do. I do not agree with the text that was shoved in the project page yesterday. TONY (talk) 02:03, 28 April 2008 (UTC)[reply]
We're not in any hurry, because an admin just stuck a week-long protection on the page because of the edit warring, with the proposed text in place. It looks like the straw poll will pass easily, maybe we can move on to the next step tomorrow morning. Tony, you made a very reasonable IMO comment about the "ministering" tone; can you figure out a way to change the tone of that first sentence so that it's acceptable? - Dan Dank55 (talk)(mistakes) 02:10, 28 April 2008 (UTC)[reply]

The result from the Village Pump Policy discussion

Tony and Gene, I think it will help a bit if you go read the discussion at WP:VPP#Using a policy page as a scratchpad to develop a proposal. Lightmouse brought this discussion there, and I could be wrong, but it seems to me that the questions you're asking were answered there. In particular, Kim said: "It is your own responsibility to check and ensure that the pages are in fact in line with community consensus (and also to correct them when they are not). [Summary:] Of course it's ok to discuss first, BUT DO NOT FORCE YOUR PREFERENCE ON OTHERS , it breaks the wiki-process! Allow people to use normal wiki-editing or BRD if they prefer." Kim went on to say "Wow, I don't recall using all-caps very often before... :-P But this is a point worth hammering down, before people start taking the wiki out of wikipedia. Don't break the wiki-process please!" What I take from this discussion is:

  • It's not okay to claim that there's no consensus because it hasn't been presented in some fashion, such as a vote. It's up to each person to read all the comments and exercise judgment about how many people feel what way and why. The fact that this discussion went on for so long, with so much editing and so much input, does suggest to me there's a consensus, but I'll be happy to discuss this if others disagree. It's always possible to claim that the consensus will change any minute when new people arrive; but I'll have to hear that argument to believe it.
  • It's not okay to say, "Your methods are not acceptable, so the consensus you arrived at doesn't count." On the question of what consensus now is, it doesn't matter how we got here, and "punishment" for "violations" is not an option. If someone did something wrong, take them to WP:AN/I.
  • Even more than usual, I could be wrong on this one. If I am, I suggest we invite in the people from WP:CONSENSUS and WP:VPP who discuss issues like these on a regular basis. - Dan Dank55 (talk)(mistakes) 18:01, 27 April 2008 (UTC)[reply]
  • "does suggest to me there's a consensus" - Yes, exactly so. Fnagaton 18:34, 27 April 2008 (UTC)[reply]
    I think we do; a straw poll should demonstrate it. The last time we had a straw poll on these pages, an editor took his solitary dissent as evidence of non-consensus. I trust this will not recur. Septentrionalis PMAnderson 20:14, 27 April 2008 (UTC)[reply]

Straw poll

OK, let's have a straw poll. Who supports the sentiments in the green box the below quotation in principle, setting aside disputes about minor matters: precise wording or the choice of examples? (by PMAnderson 20:14, 27 April 2008 (UTC) )[reply]

From MOSNUM: #Follow current literature:

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere.

(Strike, underlining, and quotation added after 18:46, 28 April 2008 (UTC) post) Greg L (talk) 19:54, 28 April 2008 (UTC)[reply]


Your deletion of the guideline seemed astonishingly arrogant for someone who never bothered to participate (under that user account) in any of the process that lead to it. If you are in fact Sareene (I don’t know if this is the case), you are blocked for life and are not welcome here. If you are genuinely new to all of this, you need to learn how things work around here. Under no circumstances do you just wade in and delete something that had been worked on for so long by so many. Greg L (talk) 20:39, 27 April 2008 (UTC)[reply]
  • Support. Stuff like that happens all the time, Greg; it violates the infobox at the top of every guidelines page, but if I had a dime for every time it happened, I'd donate them all to Wikipedia and they wouldn't need to do any more fundraising. If you believe CharlesFinnegan is a sock of a banned user, mention it at WP:AN; don't mention it during a poll to discredit the opposition, that's foul play. As I said above, my "support" vote means "the process is headed in the right direction, let's get on with votes over specifics." - Dan Dank55 (talk)(mistakes) 20:45, 27 April 2008 (UTC)[reply]
  • Support DavidPaulHamilton (talk) 20:59, 27 April 2008 (UTC)[reply]
  • Support Yes CharlesFinnegan is a sock of a banned user and the oppose vote can be struck. Fnagaton 22:19, 27 April 2008 (UTC)[reply]
  • Support SWTPC6800 (talk) 22:56, 27 April 2008 (UTC)[reply]
  • Abstain The motion is rather vague. JЇѦρ 23:23, 27 April 2008 (UTC)[reply]
  • Strong oppose: (1) Substantive objections to the text: I started to point out my objections here yesterday, just at the top of the green box. I have more objections. "In-principle" agreement means would mean only that the ACTUAL WORDING could be put to us here (not on the project page) to gather consensus). Now is the time to put the actual wording to us for consensus. (2) Breach of a central WP process: I will never agree to a "Proposal" that has been arrogantly spattered onto our project page before/duration the discussion process here, let alone consensus gathering on the talk page. (3) Can't the ISP address of this sock be checked? And why are there other redlinks participating now? Who are they? TONY (talk) 02:20, 28 April 2008 (UTC)[reply]
If I remember right, there was a "vote" in WP:VPP about a month ago to allow non-traceable TOR accounts to log in, it "passed" 1-0. My guess is people are going to start reconsidering. Strike that, it was a discussion about the WP:IP_block_exemption. Not a lot we can do, Tony. As to the language: I propose that we give the straw poll another 12 hours and see what we've got. If it's clear that we're going forward, then please look at the text we've got now and make suggestions, Tony. I like the sentence you didn't like, but not in its current form; you're right, it "ministers". What would be better? - Dan Dank55 (talk)(mistakes) 03:08, 28 April 2008 (UTC)[reply]
  • Support Editors who will “never agree” to this guideline because of one reason or another can choose to sit it out on the sidelines if that suits them. That’s all I have to say regarding the “process” by which it was adopted. As for the basic principle underlying the guideline, it is common-sense stuff from Technical Writing 101 and is a natural extension of MOSNUM#Which system to use, which states “In scientific articles, [editors should] use the units employed in the current scientific literature on that topic.” It should have been here long ago. As for the details of the examples, I leaned over backwards as far as I could to strike a compromise with every single editor who was interested in weighing in on the subject, which wasn’t easy because at one time or another, one editor was asking for the polar opposite of what another editor wanted. To all those with the can-do spirit, we can—and will—continue to collaboratively work on this from hereon. I don’t think the supporters here need much of my help now; it looks like they’ve got things well in hand now. Bravo to you all. Greg L (talk) 02:48, 28 April 2008 (UTC)[reply]
Oh hello, it's not a football stadium. Your "rah rah" attitude makes me want to puke. Can't you see that as soon as the page is unfrozen, I and others will quite justifiably start hacking into the bits that are unacceptable, including contraventions of MOS and bloated, irrelevant, inappropriate statements. That's what should happen on the talk page, not the project page. So there will be insability on the project page: you and your self-congratulatory football lackies will be entirely to blame for that. Or you can do the proper thing, and post it HERE so we can get agreement on the wording. This idea of "rough" consensus serves absolutely no purpose. TONY (talk) 03:35, 28 April 2008 (UTC)[reply]
What you write demonstrates exactly what is wrong about your position because you demonstrate that you cannot support it with valid argument so instead you use personal attacks and threats instead. Fnagaton 16:20, 28 April 2008 (UTC)[reply]
  • You really should choose your words more carefully Tony. When you write/threaten “I will never agree to (blah blah)…”, or how the moment the page becomes unfrozen, you will instantly start unilaterally “hacking” away at it, you come across as if you think your buy-in is required to accomplish anything here and that you fancy yourself as the mayor of MOSNUM who can edit against the will of the consensus. Earth calling Tony: sorry it doesn’t work that way. Unless you’ve got a “I am special” license (please present it to us if you’ve actually got one of those), even you have to accede to the will of the majority. My basic point here is that just because you are highly animated with your feelings about the guideline, that doesn’t entitle you delete and censor against the will of the majority. Greg L (talk) 04:39, 28 April 2008 (UTC)[reply]
Ack! Don't leave (if you've got the time to spare), you're doing great, Greg. Every good Wikipedian gets discouraged by the process. - Dan Dank55 (talk)(mistakes) 03:08, 28 April 2008 (UTC)[reply]
You just don't get it, do you. One sentence? What gave you the idea that just one sentence is a problem? Read what I wrote below, which was just a start. TONY (talk)
  • Strong oppose Jim77742 (talk) 05:50, 28 April 2008 (UTC)[reply]
  • Strong oppose. And an even bigger problem is the inclusion of this on the page even if there had been such an "in principle" support, which there wasn't. This is a senseless attempt to prohibit the establishment of a house style in Wikipedia, to remove conversions to units widely used in the real world. It isn't about permitting anyting; its goal is prohibition. Gene Nygaard (talk) 07:21, 28 April 2008 (UTC)[reply]
    • The biggest problem is that it is simply an invitation for incessant haggling on hundreds of different talk pages, about a number of different issues, not all of them necessary in every proposal put forth here, but almost all of them including things such as
      1. What is the "current literature"? Somebody's rejection of automotive magazines, and strange acceptance of the New York Times, as part of the "literature" related to automobiles in the discussion above is a prime example of the silliness we will get. (Search the page for "Car and Driver" or "New York Times")
      2. How is that usage in the "literature" determined?
      3. What happens when there are two or three or more different usages found in the literature?
      4. What is the role of the recommendations of professional organizations in this issue. Somewhere, if I can ever find it again, is an extended discussion of the "literature" of some field using "millimolarity" (is that the correct term? the symbol is mM) per second, with an editor trying to keep out conversions of these obscure not-really-units measurements to real SI units, and after I repeatedly refuted the proponents claim that the literature doesn't use the SI units, the proponent also came back and acknowledged that the international professional organization involved also recommended Si units in this context. Does anybody know where that discussion was? It was a featured article, I think, at the time it was on the Main Page.
      5. Does Wikipedia need to "mirror" each of the practices found in the literature? Just one of the practices found in the literature? Any practice found in 13.7% of the publications of professional papers in some limited subdiscipline in the past 13 years? Three years?
      6. Who is the intended audience of an article?
      7. What is the "subject" of the article?
      8. What is the scope of the "discipline" involved? The kilogram article is not an article on gravimetry, is it? So what does that do to User:Greg L's repeated removals of SI conversions of the obsolete cgs units he insisted on using there, in the context of this proposal? Would this proposal require use of SI units in this article about another SI unit? Would it require use of the cgs units instead? If it allowed use of the cgs units, would it permit the conversion to SI units which GregL was so determined to keep out of there?
      9. What is the "level of technicality" of a particular article?
    • This isn't the place to discuss any of those details, of course. What is relevant here is the fact that it is an open invitation to edit-warring and haggling on similar points on hundreds of individual articles, much of which can easily be avoided. Gene Nygaard (talk) 08:05, 28 April 2008 (UTC)[reply]
  • Your arguments are silly and fallacious and we’ve seen them before. We’ve seen arguments like “what happens if one magazine says such ‘n’ such, then does that mean we’re supposed to use xyz unit?” or “how is anyone to know what unit is used in literature because it’s all such a big world out there and it’s all so confusing.” Or this one: “What is the "level of technicality" of a particular article?” As if that is all that hard to figure out and requires wisdom and insight not available to mere mortals. No it doesn’t. “Current literature on that subject” and “majority of reliable periodicals” provides all the required specificity to communicate to any reasonable editor and needs no further clarification. If you really have a hard time figuring out “who the intended audience of an article” is and “what is the ‘subject’ of the article” is, and “what the ‘level of technicality’ of a particular article” is, why are you here on Wikipedia editing articles?!? I have no interest in making personal attacks on you as an individual but your arguments are just silly and specious beyond all recognition.

    Project-wide consistency can not be achieved without Wikipedia being all alone on this issue. I would have thought that using examples of Honda motorcycle “450 cc” engines would make the basic point abundantly clear. But it’s clear than nothing will for some editors. A common-sense application of the spirit of the guideline is all that is sufficient in order for editors to know what is the proper thing to do. Whether it’s cc when discussing Honda motorcycle engines or gals and µgal in a technically-oriented article where precision gravimetry is part and parcel with the topic, one uses the units used in that discipline. Your opposition to this basic principle of technical writing and your unfortunate choice of examples to fight this battle only demonstrates the weakness of you guys’ position. The BIPM has officially recognized the gal as being suitable for use with the SI since 1978 and yet here you are again fighting that same battle.

    It is not your job Gene, to promote the adoption of the SI by writing articles in an “Oh… this is the units we use in this subject; don’tcha know”–fashion, when that is simply not the case. By using units used in current literature on that subject, we ensure the reader is properly prepared for their studies elsewhere—today, not some time in the far off future when SI has been better adopted. The rest of your objections are the same old tired arguments that try to dodge the fact that you simply think Wikipedia should be your platform to lead by example and promote the adoption of SI and the IEC prefixes (“256 mebibyte RAM card”). People don’t talk that way in the real world. Your writings remind me of the arguments a teenager gives for for all the reasons the lawn can’t be mowed. It’s not complex. If Encyclopedia Britannica and other encyclopedias use the units common to that industry, just pardon me all over if we look towards professional paid editors like them for guidance instead of you. Greg L (talk) 18:31, 28 April 2008 (UTC)[reply]

Greg L is wrong to claim that it is always easy to determine what units are preferred by the majority of reliable publications, and anyone who cannot do so is unfit to edit Wikipedia. --Gerry Ashton (talk) 21:34, 28 April 2008 (UTC)[reply]
  • Why is it that the opponents of this proposal so frequently base their arguments on untrue facts? Gerry, please point out where it is claimed—either in the guideline (a product of many authors) or my writings above—that “it is always easy to determine what units are preferred by the majority of reliable publications”? I implied the obvious: that figuring out “who the intended audience of an article” is and “what is the ‘subject’ of the article” is, and “what the ‘level of technicality’ of a particular article” isn’t complex and editors who claim as much are using fallacious arguments as smokescreens to justify continuing to do things their own way. Is it really necessary to state “If the current literature is all over the map and there is no clear consistent practice in that discipline, then this doesn’t apply”? Arguments that amount to “no no; looking to current literature is far too complex of a task to ask of editors and it’s really much better to just allow editors to do whatever they feel like, even if it is a weird unit unused in the real world” just doesn’t cut it. Greg L (talk) 22:28, 28 April 2008 (UTC)[reply]
The principle does not suggest what to do when the literature is all over the map, or if the editors can't agree on who the likely readership for an article is. --Gerry Ashton (talk) 23:58, 28 April 2008 (UTC)[reply]
  • Well… not the nutshell posted here. Here is the proposal, in its totality up to the point you are making:

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:

Preference for modern units
Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.

Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or metric rather than SI—Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline. Editors should write…

If the discipline doesn’t consistently use its own units, then this portion of the guideline simply doesn’t apply and editors default to the Preference for modern units.

The above-quoted part is a subset of the entire guideline and doesn’t speak to Level of difficulty. Anyway, the issue of “likely readership” (as you wrote above) isn’t (or shouldn’t be) complex at this state of the discussion; for the most part, Wikipedia articles are directed to a general-interest reader (either Planck units, or units for “the rest of us”). I’m just taking this a point at a time…

The guideline is written to recommend that editors follow “current usage” in a given discipline only when the discipline consistently uses its own units. How do you know what units are used in a discipline? In many cases, the editors of a given article are familiar enough with the subject matter to know this. If there is doubt, look to current literature. Greg L (talk) 02:46, 29 April 2008 (UTC)[reply]

  • For the integrity of this talk page, so the below comment has some context instead of being left floating, there was a comment which was later completely removed by the same user with an uncivil edit comment. Fnagaton 08:46, 29 April 2008 (UTC)[reply]
  • ‘MOSNUM shouldn’t be expanded anymore’ is entirely beside the point of what we’re trying to accomplish here. If you think there is something wrong with the basic principle, please say so. And if so, please stand up to the lectern, speak clearly into the microphone, and state precisely what it is about the basic principle you disagree with. Greg L (talk) 19:25, 28 April 2008 (UTC)[reply]
Did you really mean to remove your strong oppose with this edit? Fnagaton 10:55, 29 April 2008 (UTC)[reply]
  • Fnagaton, I see that this particular editor regrets having involved himself here with an “oppose” vote. I see that he even edited out his name from my above response, wherein I addressed him respectfully by title and name. It is clear as glass that the retraction of his vote was by design. One of his edit summaries in the history of this talk page states “I have made it perfectly clear. That I do not wish to be involved in this debate. Please stop dragging me into it.” I suggest that you, Fnagaton, revise your posting above to accommodate this editor’s wishes that he remain unassociated with this issue. As I said, I will let his edit of my post stand; such things would normally be unacceptable. I’ve worked with plenty of Ph.D.s before; I’m working with two now on an FDA animal study. Don’t read too much into the uncivil edit summary. Please, people should be allowed to bow out of things and save face at the same time. Greg L (talk) 17:37, 29 April 2008 (UTC)[reply]
  • Oppose. Now support (see discussion). The green box is bloated and cluttered. There are also a bunch of problem Jimp listed below and "in principle" votes are IMO trojan votes. Today we vote on the principles of the green box, which aren't even defined, and tommorow a sockpuppet named PrincessRaoul69 will use it against us saying that we agree "on principles" on whatever s/he wants us to agree on. (Apologies if there's a user named PrincessRaoul69 out there). IMO, we are much better if we start from scratch and vote on each sections of the green box. This way, slow but progress can be made towards a final "green box".[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 17:17, 28 April 2008 (UTC)
    • Shorter Headbomb: I'm not going to answer the question asked. This is an effort to show if there is consensus in principle; if there is, then discussing bloated wording is in order. If there isn't, it doesn't matter whether it's bloated; it ain't consensus. The answer to PrincessRaoul is "No, we don't". Septentrionalis PMAnderson 18:09, 28 April 2008 (UTC)[reply]
      • The question was "Who supports the sentiments in the green box in principle [...]?" and right now I can't tell what those "sentiments" are. But whatever they are supposed to be, there are a great deals of problem with them, as listed by Jimp and who are currently being debated. Thus oppose. The rest of what I said were general comments. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 18:46, 28 April 2008 (UTC)
  • Again, it’s not complex:

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere.

That’s the sentiment. We are asking that editors agree or disagree with this principle of technical writing in an encyclopedia. If disagree, please explain what is wrong with that principle. Greg L (talk) 19:39, 28 April 2008 (UTC)[reply]
  • If you're going to change on what we vote halfway through the vote it becomes a pretty meaningless vote. If we vote on that quotation, then I support the general idea although SI and units accepted along SI should be given preference over non SI units when it is not clear which units is most often used. But by now I don't know what's the value of this vote anymore. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 18:03, 1 May 2008 (UTC)
  • Thanks Headbomb. If we agree on the basic principle of what Wikipedia should be doing (and I think we do), then working out the details with you should be an interesting and rewarding collaboration. Greg L (talk) 19:19, 1 May 2008 (UTC)[reply]
  • Oppose. If a unit of measure is used in a way that would be regulated by law if the object or service were offered for sale, use the unit of measure currently prescribed by law in the country, or most of the countries, where the object or service is (are) located. Otherwise, follow the advise at the head of this section. --Gerry Ashton (talk) 21:39, 28 April 2008 (UTC)[reply]
  • Support in principle. I think that discipline specific stuff is a step in the right direction, but in its current form it maybe a little bloated. I feel that this addresses situations where a discipline may use a unit or unit symbol that is different from the SI standard (mbar vs hPa; cc vs cm3) or what is normally encountered for that measurement (psi vs lb/sq in; cu in vs cid). There are definitely some passionate (if that's the right word?) editors who advocate strict adherence to official SI policy. Which is ok if SI is the norm for that field, but if not, then it is heresy. There are situations in certain fields where 'cc' is the the norm not cm3 or mL; where mbar is the norm and not hPa (which are equal to each other yet displayed next to each other all the time). If steam engines in Europe have a gauge for pressure in kg/cm2, then that is what the article should report. I think that the purest of strict SI folks will know what is meant by kg/cm2; they just won't like it. Also, I do (and have in the past) echo the concerns of many that this whole green box should have been discussed first and longer before placing it on the mosnum. After a sizable discussion, we could then have placed the discussed version on the mosnum as a proposal with an invitation for more comment. I wouldn't object to the removal of the proposal from the mosnum and discussing it more on the talk if that helps. —MJCdetroit (yak) 15:41, 29 April 2008 (UTC)[reply]
  • Strong oppose There's no way that a MOS guideline page should be defining Wikipedia's Mission. If in fact this is intended to refer to an agreed definition elsewhere, it should be linked. The closest approximation I've found so far was at meta:mission but that doesn't much resemble the statement above.LeadSongDog (talk) 22:50, 29 April 2008 (UTC)[reply]
Good point that it should be a link instead, and agreed that the wording is unfortunate. However, I think I get where Greg was coming from; he's saying that the previous wording implied that people should use SI even in situations where few other people do, because that's a world we'd rather live in. If it's true that that used to be the viewpoint of WP:MOSNUM (and I'm not convinced that it was, but there is some sign of that), then that of course violates WP policy, and we should explain why we can't do that. Again, the problem from where I'm sitting is that both sides in this debate (when it's a debate) have successfully made the case that this is not a simple problem that can be handled with a few rules-of-thumb, but everyone is trying to handle it with a few rules-of-thumb. A few sources have been introduced, but not enough, and none that are broad enough to help us make the judgment calls in a variety of situations. I have to admit that I've lost interest at this point, but I'm still hoping someone will start quoting some relevant sources and perk me up. - Dan Dank55 (talk)(mistakes) 23:09, 29 April 2008 (UTC)[reply]
  • So if that “misson” wording was fixed, would that turn your vote into a “support” vote? Greg L (talk) 23:45, 29 April 2008 (UTC)[reply]
  • It would of course depend on the fix. In the case of eliminating the mission sentence, I would change to "Comment - would prefer:"

Use terminology and symbols commonly employed in the best of current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

or similar.LeadSongDog (talk) 08:03, 30 April 2008 (UTC)[reply]
  • LeadSongDog. Such wording is perfectly fine with those who support the basic principle being discussed here. I think that principle is merely a logical extension of MOSNUM #Which system to use, which states “In scientific articles, [editors should] use the units employed in the current scientific literature on that topic.” The proponents here have no hidden strings and hidden agendas. The effort here is only to advance a guideline that states that Wikipedia should use the SI unless there are industires and disciplines that universally, or near universally, use other units (e.g. gals in gravimetry, cc in Japanese motorcycles, megabyte in general-interest computers). If this is basically what you feel is proper, then we are in complete agreement on the basic principle (which is what this straw poll is about) and our differences lie only in the details of how to communicate the point. If so, may I suggest you change your vote to a conditional “support”? Greg L (talk) 20:44, 30 April 2008 (UTC)[reply]
If it plays out that way, sure. I'll wait a bit to see if there are others who see it differently from you. I would prefer that if we must choose examples, that they be somewhat less controversial ones, such as carat in jewelry or parsec in astrometry, simply in the interest of getting to an agreement. Others could be worked out individually later, perhaps on a sub-page specifically for those units under dispute.LeadSongDog (talk) 21:37, 30 April 2008 (UTC)[reply]
  • Support, yes in principle I support this proposal, as Wikipedia should use the language that is common to it's readers. Mahjongg (talk) 22:54, 30 April 2008 (UTC)[reply]
  • Support, for the same reasons other supporters already mentioned. Not much more I can add to them. --Marty Goldberg (talk) 00:26, 1 May 2008 (UTC)[reply]
  • Strong support. For binary units of measurement, KB, MB, GB, etc. are here to stay regardless of whatever efforts to change them. This principle will help stem the tide of pointless edits relating to the use of units. These edits don't help what so ever. I would prefer my contributions to be factual contributions, not reverts that later lead onto long debates that are of no benefit. Rilak (talk) 11:22, 1 May 2008 (UTC)[reply]
  • Oppose. The whole reason the IEC prefixes exist is that using "terminology and symbols commonly employed in the current literature" does not "communicate with minimal confusion." This proposal is therefore in conflict with itself. Jeh (talk) 21:55, 1 May 2008 (UTC)[reply]
  • That is a common sentiment of the “oppose” crowd. I appreciate, Jeh, that you had the courage to aim directly at the heart of the issue rather than indirectly nip at this proposal’s heels. IMO though, this is making a mountain out of a mole hill. All the mainstream computer magazines (PC World and dozens of others) and encyclopedias like Encyclopedia Britannica manage to effectively communicate with their readerships without using “mebibyte”. Wikipedia should too. All we have to do as volunteer, contributing editors is assume for a moment that the professional, paid editors of those publications might know more than we do and simply follow suit rather than put Wikipedia in the position of following its own course. Rilak above, made an important observation about the simple reality of where we are now. We need to fix this. Greg L (talk) 22:39, 1 May 2008 (UTC)[reply]
  • Greg, I do not think it is reasonable for you to write objections to every vote here with which you disagree. But since you opened it up... Ah, no, they are NOT "effectively communicating with their readerships". If they were, we would not have had the lawsuit against Seagate. Note that that lawsuit proceeded even though Seagate uses a disambiguation technique favored by the anti-IEC prefix crowd here, namely printing "1 GB = 1,000,000,000 bytes" on their boxes. Most other hard drive makers do the same. Nevertheless, many computer-oriented web forums still get periodic questions -- "why does my 300 GB hard drive show up in Windows as just 279 GB?" The number of people who try to answer by claiming "you lose it in formatting" is pretty telling, too. You obviously disagree, but you cannot claim there is consensus here to not use IEC prefixes. There are a significant number of people in favor of them, and you can't dismiss their arguments as simply "I like it". Jeh (talk) 00:55, 2 May 2008 (UTC)[reply]
  • Lawsuits over hard drive capacity proves only that the American system of tort law is lucrative for lawyers. It says nothing about the ability of magazines and encyclopedias to routinely communicate to their readerships without relying upon units of measure that the typical Wikipedia reader doesn’t recognize and will not likely encounter in the real world after leaving Wikipedia. As Rilak said, “[the] binary units of measurement, KB, MB, GB, etc. are here to stay regardless of whatever efforts to change them.” The IEC prefixes are simply a good idea that failed and their continued use here by some editors is just silly stubbornness rather than wise editorial policy. Greg L (talk) 02:04, 2 May 2008 (UTC)[reply]
IEC is not recognized by the typical reader but Jeh keeps on changing pages to include them and that is not right.DavidPaulHamilton (talk) 07:32, 2 May 2008 (UTC)[reply]
You are mistaken. I merely restored this page (note that that is "page" singular, David, not "pages") to its previous state. True, the previous state used IEC prefixes, but they were there long before the IP editor gratuitously removed them. What the IP editor did, and what YOU did, David (changing IEC prefixes to SI prefixes on a page that had used IEC for some time, by apparent consensus of that page's editors) is AFAICT exactly what Sarenne was banned for, but in reverse (and of course of much smaller scope). Your and the IP editor's changes furthermore are in violation of what is still WP:MOSNUM: "There is consensus that editors should not change prefixes from one style to the other". My reversions (not "changing pages") were to revert edits that violated this policy. Contrary to your accusation, I have not initiated any changes to any pages to include IEC prefixes. Jeh (talk) 07:58, 2 May 2008 (UTC)[reply]
  • During the lawsuit , Western Digital tried to use the IEC definitions to point out the GB was one billion and not a binary value. The plaintiff's successfully ridiculed the IEC binary prefixes. They claimed that the real world had not adopted this proposed standard. News story. Lawsuit settlement. It does not appear that using the IEC binary definitions will prevent lawsuits. All of the hard drive companies now specify the size of a GB on the drive packaging and documentation. This is their way of disambiguating the meaning of GB. -- SWTPC6800 (talk) 16:04, 2 May 2008 (UTC)[reply]
  • The only way to prevent lawsuits is to close the courts. Furthermore, there is no absolute guarantee that the judge or jury will come to a reasonable verdict. But if only IEC prefixes are used to mark a product, it would be asinine for a judge or jury to conclude the prefixes mean something other than what the IEC says they mean. Now, if you mean the mere existence of the IEC prefixes means that the SI prefixes no longer have a binary meaning, but only a decimal meaning, then your right, the IEC prefixes have failed to abolish the binary meaning of SI prefixes. --Gerry Ashton (talk) 16:19, 2 May 2008 (UTC)[reply]

Special:Contributions/Greg_L

Warning: votestacking in progressTarapotysk (talk) 12:01, 1 May 2008 (UTC)[reply]

My presumption i.a.w. WP:AGF is that Greg_L is giving equivalent notices to ALL the editors here. Is there evidence to the contrary?LeadSongDog (talk) 16:32, 1 May 2008 (UTC)[reply]
Sorry, I just fed a troll. I see Tarapotysk has just been blocked.LeadSongDog (talk) 16:37, 1 May 2008 (UTC)[reply]
He has? Where do you see that? Jeh (talk) 19:35, 1 May 2008 (UTC)[reply]
From the block log: "2008-05-01T11:42:13 Dmcdevit (Talk | contribs) blocked "Tarapotysk (Talk | contribs)" (account creation blocked) with an expiry time of indefinite ‎ (MOS troll)" LeadSongDog (talk) 21:01, 1 May 2008 (UTC)[reply]
Ah. I'm still somewhat new here, I expected it to appear on his (Tar's) user page. Anyway, Greg by his own admission contacted only editors who previously voted against IEC prefixes. Sure looks like votestacking to me. Jeh (talk) 21:30, 1 May 2008 (UTC)[reply]
That's not accurate, Jeh, he contacted me and I previously voted for them. Let's drop it. Tarapotysk is now banned as a troll. If we scatter troll food around we'll just attract others.LeadSongDog (talk) 18:18, 2 May 2008 (UTC)[reply]
  • To Tarapotysk: Argument rejected as completely invalid posturing. I examined the names of the “support” votes from the original vote on Archive 97 and posted a message to that subset of the list who hadn’t yet weighed in on the current vote. It is entirely fair and proper to let these editors know that their original votes to discontinue the unwise practice of using the IEC prefixes were now meaningless and they were currently disenfranchised voters because the “IEC prefix” issue had morphed into the broader policy being discussed today. Their vote back then was an effort to get something done about this problem. As such, they are involved editors who have a right to be notified that the issue changed in form and their original votes no longer applied. Such editors must be given an opportunity to vote on this issue in its current form. This is an entirely different matter from the “carpet bombing” on un-involved editors that anti-canvassing policy is directed at. Greg L (talk) 17:23, 1 May 2008 (UTC)[reply]

    P.S. I did my notifications only to involved editors and did so out in the open, with complete transparency for all to see. The reason for posting the “green-div” box to MOSNUM was to attract the widest-possible spectrum of editors; whether that would garner “support” votes or “oppose” votes could not be predicted. There better not be any of this secret e-mailing to “friends” who are otherwise uninvolved editors. Now that would be votestacking. We’ve already seen what happens when some poor bastard jumps into this without realizing what the issue was all about. Greg L (talk) 18:45, 1 May 2008 (UTC)[reply]

Since nothing wrong was done I propose removing this entire section to stop the sock from getting any more attention. LeadSongDog and Greg would you both agree to having your edits removed from this section? Fnagaton 19:30, 1 May 2008 (UTC)[reply]
Greg, you are not any sort of moderator here and as such you are not in a position to "reject" arguments except on your own behalf. Anyway... so... you admit you only contacted editors who had previously voted against IEC prefixes, yet you insist such is not votestacking??? So if I only contact (out in the open, with complete transparency) editors who previously voted in favor of IEC prefixes, I trust you won't consider that "votestacking" either? Even Fnagaton agrees that nothing wrong was done! (Not that votes matter much; consensus is not determined by vote.) And no, Fnag, this section should be preserved for this reason. Jeh (talk) 19:35, 1 May 2008 (UTC)[reply]
  • Jeh, where above did I say I was speaking on behalf of others? Your imagination has run wild. You may contact any involved editor you like. Greg L (talk) 20:08, 1 May 2008 (UTC)[reply]
No objection to striking/hiding/deleting my above edits.LeadSongDog (talk) 21:06, 1 May 2008 (UTC)[reply]

Discussion

I had hoped this straw poll would remove us from the insoluble circle of recrimination on what has been done in the past, by focussing on the soluble question of whether there was consensus on the principle of the new section. I post immediately after comments, which encourage me to comment that the old text without "follow current literature" is not only failing to be consensus, but is, at this point, distinctly a minority view. Septentrionalis PMAnderson 13:53, 28 April 2008 (UTC)[reply]

Perhaps a simpler solution, perhaps based on "prefer SI units, unless there is a strongly-established convention in a particular field to use another system." It's probably best to prefer and advise, rather than prescribe or proscribe. SHEFFIELDSTEELTALK 22:07, 30 April 2008 (UTC)[reply]
  • Any wording that accomplishes the same objective (following real-world usage) and can’t be gamed by the minority proponents of the IEC prefixes and the radical pro-SI minority is fine; the rest is just details. I think we’re all going to find that any wording that would really accomplish that end will be met with diversionary arguments by certain editors. And once it is posted to MOSNUM, it would further be met with wholesale deletions of the policy until it was so weak, it could be interpreted as permiting absolutely any practice any editor desires. We simply have to accept that we won’t get a buy-in from every editor if we do the right thing here. It’s simple: There is a preference for the SI and other modern units unless an industry or discipline consistently uses other units; in which case, follow current literature. Though the “oppose” crowd will argue that this is terribly complex (“what literature?”, “what is the subject of the article?”, “who is the readership?”, “is the difficulty level for a general-interest readership or for an expert readership?”), it’s not. Common sense works just fine. Greg L (talk) 17:52, 1 May 2008 (UTC)[reply]

Date preferences and non-breaking spaces

I have heard that dates and years should be linked so that there is a non-breaking space between the date and the year (e.g., January 11,<non-breaking-space>2007). However, it seems that inserting the non-breaking space breaks auto-formatting of dates per the user's preferences. Should there be a non-breaking space there? —Rob (talk) 15:52, 27 April 2008 (UTC)[reply]

I have heard that a non-breaking space there breaks the autoformatting (more evidence of "suckitude", as Stanton mentions above). - Dan Dank55 (talk)(mistakes) 16:12, 27 April 2008 (UTC)[reply]
Can't a hard space be incorporated in the autoformatting? There would be no need for a manual insertion then. Waltham, The Duke of 11:04, 29 April 2008 (UTC)[reply]
This autoformatting is in such terrible need of an overhaul and so little progress seems to have been made inspite of the pleas of dozens of editors. I'm sure hard spaces could be incorporated but I wouldn't hold my breath. &nbsp; does break the autoformatting. Use {{nowrap}} instead. JIMp talk·cont 01:33, 30 April 2008 (UTC)[reply]

Just added a "Manual of Style" cat

For the proposed distinction, see WT:MOS#New category. Feel free to revert, and comments are welcome, but please post them over there. - Dan Dank55 (talk)(mistakes) 16:08, 27 April 2008 (UTC)[reply]

P.S. Quick explanation: there are 67 pages in the style guidelines cat, and we can't keep track of them all, and shouldn't even try. But clearly, MOSNUM is one of the pages to keep track of; thus the new cat. - Dan Dank55 (talk)(mistakes) 17:05, 27 April 2008 (UTC)[reply]
P.P.S. I've decided to revert myself when the page protection expires. WP:MOSNUM is more in the category of a subject-specific style guideline; that is, the average editor won't have to read it ahead of time, they can wait and read it when they need it. - Dan Dank55 (talk)(mistakes) 17:23, 30 April 2008 (UTC)[reply]

User:CharlesFinnegan is a new account

User:CharlesFinnegan is a new account making reverts to the project page. Please an admin investigate this DavidPaulHamilton (talk) 20:33, 27 April 2008 (UTC)[reply]

David, there's nothing shocking about this. Like I said above, if someone has information that the account may be the sockpuppet of a banned user, report it at WP:AN. Don't bring it up during a poll. The account's userpage link and talk link are both red, so we can all see it's a new account. If they're really pissing you off, the thing to do is check their contributions from time to time, and see if they're doing things that qualify as vandalism...if so, post messages about it on their talk page. It takes several obvious attempts at vandalism, at the very least, to warrant mentioning it at WP:AIV. - Dan Dank55 (talk)(mistakes) 20:49, 27 April 2008 (UTC)[reply]
It took me a while to be convinced to create a user page; this account, however, is both new and suspicious enough to be discounted. Septentrionalis PMAnderson 20:52, 27 April 2008 (UTC)[reply]
Ah, I just noticed that Charles blanked that section 3 times within minutes. That's different. I just put {{subst:uw-3rr|WP:MOSNUM}} on his talk page. If he does it again, turn him in to WP:AN3. - Dan Dank55 (talk)(mistakes) 21:04, 27 April 2008 (UTC)[reply]
And then suddenly knows how to fill in a 3RR report. Not bad for a completely new user account which supposedly doesn't have an experienced user. ;) Very suspicious. Fnagaton 22:21, 27 April 2008 (UTC)[reply]
I just checked, the account has been indefinitely blocked. Fnagaton 22:24, 27 April 2008 (UTC)[reply]

Oh good lord. 2 or 3 people in current discussions just had a checkuser done on Tony to see if he was operating the sockpuppet! (The socks were untraceable TOR accts, btw). Tony and I don't always agree, and sometimes butt heads. He is very passionate about his goals for Wikipedia. But Tony is a genuinely nice guy, and he plays fair, and even if those things weren't true, he wouldn't be dumb enough to vote with sockpuppets :) - Dan Dank55 (talk)(mistakes) 23:39, 27 April 2008 (UTC)[reply]

Honestly. Isn't it finally time to bury the hatchets and get some work done on cleaning up these pages ?? I can't wait to see Tony's reaction when he wakes up, but this is just becoming a freak show. SandyGeorgia (Talk) 23:41, 27 April 2008 (UTC)[reply]
Dank55, do you know who actually made the check user request? Fnagaton 23:41, 27 April 2008 (UTC)[reply]
I saw the discussion, yes, Fnagaton. There's no need to point fingers, just ... get real, people. We've been working on the proposed text a long time; let's get finished and move on. - Dan Dank55 (talk)(mistakes) 00:30, 28 April 2008 (UTC)[reply]
Tony is a valued contributor. I don't know if he even wears socks. :-) -- SWTPC6800 (talk) 02:23, 28 April 2008 (UTC)[reply]

User:DavidPaulHamilton is a new account

User:DavidPaulHamilton is a new account making reverts to the project page. Please an admin investigate this CharlesFinnegan (talk) 21:01, 27 April 2008 (UTC)[reply]

  • He's actually made several edits to article space, and did not begin with blanking part of a policy page. But This would probably be a more effective place to file your complaint. Septentrionalis PMAnderson 21:12, 27 April 2008 (UTC)[reply]
We edit-conflicted, I was just typing more or less the same. Good work. That link is at WP:AN; they're a little more "formal" there, so if someone has more information and isn't sure what to say, you're welcome to leave a note on my talk page if you want to know something about which pages cover what before you report him for more stuff. - Dan Dank55 (talk)(mistakes) 21:20, 27 April 2008 (UTC)[reply]

The trouble with following current literature

I'll try to explain in detail what I object to in the new "policy". The section starts with the following.

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia is a general encyclopædia written for a general readership. Let us not start directing articles to this or that readership. Terminology and symbols used in current literature may well baffle the general reader. Often the unfamilar term or symbol can be simply explained or linked. Sometimes it would be better to rephrase.

What is the meaning of "When in doubt,"? Can we not do without this?

How are we to judge what constitutes that which is "most often employed in reliable periodicals". For any given topic there may be a huge amount of literature using a wide variety of units, prefixes, etc. What do we do when a the literature is dominated by publications from a certain country, group, organisation, etc. which uses its prefered units, abbreviations, etc. whilst another country, group, organisation, etc. uses a different set of perfectly valid set? This "policy" would have us quoting Albertan oil production figures in barrels per day even if our sources give their figures in cubic metres per day. Instead, why not simply tell editors to keep true to source figures giving conversions as appropriate?

The bit about prefixes obviously has its roots in the binary prefix war, however, (along with the rest of this "policy") it has grown beyond this to touch new ground. In discussions above there had been shown a feeling that we could do without the quasi-Roman-numeral/"short-scale" set of prefixes, {M, MM, B, T} (for {103, 106, 109, 1012}). This new "policy" runs counter to this encouraging these rather than banning them.

Similarly, in other discussions above a general feeling that "lb" and "kg" should be reserved for the units of mass not force was shown. There can be found in the literature examples which go against this rule. Again this "policy" will override this encouraging "kg/cm²" & "lb/in²" for pressure and "lb·ft" for torque.

Suppose an editor wants to ... (quick quiz: try guess what "Tcm" might mean before you click) ... convert "Tcm" to standard notation, is this policy going to be thrown at him?

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:

A minor point but the last sentence introduces this list as exhaustive whereas there may exist other important elements not yet considered. The easiest fix to this would be to delete the first letter of that second sentence.

Do we need a statement of "Wikipedia's mission" in this section? Indeed, is this our mission exactly? I do, of course, agree that we ought to communicate with minimal confusion. My concern is that this "policy" is likely to worsen things in this respect rather than make them better. Consistency within the encyclopædia minimises the confusion. The "policy" will put consistency with the outside literature above internal consistency.

Preference for modern units

Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.

I support this, though, it might be useful to go into what other modern systems there are.

Discipline-specific practices

Wherever a discipline consistently uses its own units—either conventional or metric rather than SI—Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline. Editors should write…
  • “a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm3 Honda motorcycle engine”;
  • “Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude” (unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices);
  • “a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10−6 s–2”, in the science of gravimetry.

The paragraph does not clearly distinguish between units and symbols/abbreviations. Barrels and cubic metres are different units. "cc" and "cm³" represent the same unit, they differ only in that one is the standard symbol and the other a non-standard abbreviation.

How are we to determine what is in consistant use? The crude oil example is enlightening. As noted, Canadians use cubic metres but they are not the only ones not to use the barrel (an American unit). The tonne is also widely used. Things are not as consistant as they might seem at first.

We don't need the detail about Canadian this and Canadian that—just reflect the source units.

Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems. Even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no best way. For instance, writing "a 450 cc (450 cm3) motorcycle engine" is inappropriate even though it is in conformance with the SI. "The Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inches (5,766 cc)” is appropriate for a historical, American-made engine. "The Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 in3)" is appropriate for a modern, American-label engine that is classified in liters. But writing "the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches" would be inappropriate in an article primarily about a European-made sports car.

This is a little vague. Exactly when does one do a conversion and to what? If it weren't for the good ol' Canadians with their heads screwed on well enough to ditch this barrel nonsense in favour of the cubic metre, would this policy force us not to give cubic metre conversions and to hell with us metricated folk? Is this policy going to the the favourite tool of the metric matyrs who go about removing metric conversions from articles?

Certainly a "conversion" from "cc" to "cm³" is inappropriate: these are the same unit. Moreover, I'd say that trivial conversion, such as those from millibars to kilopascals are likewise unecessary. By the way, writing "a 450 cc (450 cm3) motorcycle engine" is not in conformance with the SI since "cc" is not SI.

There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities but the new units didn’t see widespread adoption. Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB)". However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, such as "kilobyte (KB)" and "megabyte (MB)", for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to "Binary prefixes", below).

Is that first sentence of any use? It doesn't appear to give us any instruction. Cut it. We see the words "unfamiliar to the typical Wikipedia reader" here—ironic seeing as this policy is about to open the flood-gates to more of the like ... or is this just my pet fear? This whole policy, I'm guessing, was first hatched as a means to get some acceptance for conventional binary prefixes. I'd be happy if that were as far as it went but now it seems to put in jeopardy conventional systems of units and unit notation.

Level of difficulty (Do not write over the heads of the readership)

For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.

This seems perhaps to be pointed in the right direction. I wonder whether the challenge of judging this level of difficulty will lead to more strife than the inclusion of this is worth.

JЇѦρ 07:07, 28 April 2008 (UTC)[reply]

That "level of difficulty" issue is merely one of a dozen different ways in which the proposal would cause more strife than it is worth. Gene Nygaard (talk) 08:14, 28 April 2008 (UTC)[reply]
Your discussion, Jimp (what's the silly, incomprehensible symbols, some attempt at going incognito?) also touches on the biggest points of induced, unnecessary strife:
What is included in literature in this context?
What in literature is relevant? How is that determined in any particular case?
Among the relevant literature, what is included as being "current"?
Why is there an assumption in this discussion that whatever we determine to be relevant, current literature is going to be speaking with one voice? That seems highly unlikely to happen, so what happens when the relevant, current literature exhibits two or three or a dozen or more different usages? Part of the problem here, of course, is that when there is some other way in which the "literature" can be subdivided, you are going to have each side arguing that the other sides supporting literature is irrelevant on some other grounds (e.g., geography, medium, audience), and the vague, uncertain, and unpredictable proposals that have been put forth here leave lots of room for such claims and counterclaims. Gene Nygaard (talk) 09:13, 28 April 2008 (UTC)[reply]
The silly incomprehensible symbols were just a bit of fun ... I'm all sensible now ... JIMp talk·cont 16:29, 28 April 2008 (UTC)[reply]

←Jimp's questions are good, and this is hard. A little research here would probably pay off big, if someone wants to do it. Some of Wikipedia's science articles are roughly on the level of Scientific American and other science-popularizing magazines in the audience they're trying to write to; that is, SciAm tries not to use too brutal an editorial policy with its contributors, because it needs them, and wants to show that it is "in the know" by using units appropriate to the various fields, while not interfering too much with comprehension. If we can show that our judgments calls are roughly in line with theirs, then this process becomes much less contentious (and most important to me, takes less of my time :). We would also be much more appealing to a wide range of scientists and scholars if we can reassure them that our rules on units have some kind of support in the wider scientific community. Does anyone have time to ask at WP:REFDESK for help from some people in library sciences? If you want to talk with journalists to get some answers, I've got some contacts, but I don't have time to follow this up myself. - Dan Dank55 (talk)(mistakes) 12:29, 28 April 2008 (UTC)[reply]

I've realized I have a hidden agenda here (not hidden now). My sense is that Tony is having a negative reaction because this all seems like a whole lot of discussion without any useful outcome in sight; I'm having a positive reaction because of the new blood, the cordiality and give-and-take, and many references to specific useful sources. This is a direction for MOSNUM that would lead to better results and to less work for everyone else who is in this for the long haul. Maybe we're both right, I don't know. I think what I am really after with asking people to find more and more authoritative sources that support their beliefs is to find out whether we're really on the right track here, or if Tony is right and this is taking more time than it's worth. - Dan Dank55 (talk)(mistakes) 13:31, 28 April 2008 (UTC)[reply]
But this proposal doesn't apply only to the "scientific community", does it? Do you think those are the only fields of human activity which uses units of measure?
And, in any case, how would you ensure that
  1. Scientific American is considered relevant literature in this regard?
  2. How would you do to give it some kind of priority for our use in this determination?
  3. How far back do we go in determining its "current" usage?
  4. What's the fallback when Scientific American usage cannot be determined?
Gene Nygaard (talk) 13:40, 28 April 2008 (UTC)[reply]

Yes, all well-thought-through questions that underline why the text should never have been inserted in MOSNUM in the first place. The fact that no one was allowed even to place a dispute tag on it, let alone remove it to to the talk page—its rightful place for discussion—shows an arrogant, narky attitude by some people here. TONY (talk) 14:31, 28 April 2008 (UTC)[reply]

Red herrings, rather. Scientific American has been used as an example of a source in this discussion exactly once, as part of a long list of WP:reliable sources. These problems are met all over Wikipedia: Is X a reliable source? Is X a reliable source on this topic? Is it the most reliable source? Is this issue of X still current? If they are well-put objections here, then they are well-put objections everywhere, and WP is impossible. Septentrionalis PMAnderson 15:44, 28 April 2008 (UTC)[reply]
The trouble with not following current literature is that it breaks one of the founding ideas of Wikipedia meaning that instead of directly reporting what our article sources say about a subject, writing articles then becomes a matter of an editor pushing a point of view about what system they think should be used. Which isn't what Wikipedia is about at all. Fnagaton 15:54, 28 April 2008 (UTC)[reply]
I was using Scientific American as an example. Examination of units used in such a magazine, done either by the Scientific American editors themselves or by scholars or standards committees, might be helpful, because they face some of the same problems we face. The problems that, for instance, IEC faced are nothing like the problems we face. I have a feeling that many of us are agreed, despite the apparent differences: we're waiting to see if there's some kind of successful process here that is able to resolve itself, including reasoned arguments from provably relevant sources. If so, then we could probably maintain a high level of interest in the discussion. - Dan Dank55 (talk)(mistakes) 16:38, 28 April 2008 (UTC)[reply]
I don't believe that you're right there, Fnagaton. This proposal advises us to follow current literature. Now, assuming we could pin-point what that might be (something not necessarily all that simple) there could arrise an instance where our source uses a unit not commonly found in other publications on the topic. This policy, as it reads in its current (protected) form, would suggest we follow current literature inspite of the conflict with the source. All this hooplah could be so easily avoided by a simple rule to put the source value first and (a) conversion(s) in brackets where appropriate. We can point to a particular source and discuss whether it is reliable. We can clearly see what units are used in one particular source. It's much more difficult when we start attempting to talk about "the literature". Do we even need to when, in the end, we're going to follow the particular sources we've got making the conversions we believe useful to our readership, which we should pretty-much always be able to assume to be a general readership? JIMp talk·cont 16:57, 28 April 2008 (UTC)[reply]
That makes a great deal of sense; it would be natural for historic discussions of units no longer in use ("Arago measured 18,765 toises (.. km; ... mi;)". It will answer for motorcycles too; the only problem is when two sources are speckled through an article, one using miles, the other kilometers. Septentrionalis PMAnderson 17:04, 28 April 2008 (UTC)[reply]
It is certainly desirable not to lose the units as given in the source; they should be somewhere so that we can decide for ourselves how many significant digits were intended, and check whether there were conversion errors. But if someone's source gave the area in acres, should we say "X acres (Y sq ft, Z m2)"? Or should all original units that aren't one of the two recommended units for the text all be lumped together in a footnote? - Dan Dank55 (talk)(mistakes) 17:23, 28 April 2008 (UTC)[reply]
Random crazy suggestion: Imagine a magic conversion that takes as input the source value in source units (with all significant figures quoted by the source) plus a number of significant figures to be displayed, and displays as output only the converted value. In other words the script "convertsourceunits(X,acres,2)" would appear to the reader "Z m2 (Y sq ft)", rounded to 2 significant figures. That would retain the source information for posterity while at the same time presenting a uniform format to the reader. But is it realisable? Thunderbird2 (talk) 17:40, 28 April 2008 (UTC)[reply]
I could live with "x miles (y km)" and "a kilometres (b mi)"'s being used interchangeably within an article. Others would prefer consistency, in which case choose whichever seems best suited to the article and swap some of the conversions around noting the switch with ref tags. In general I'd prefer the original units to be in the main text rather than in footnotes ... or usually even in brackets. The magic conversion is very realisable ... the idea has been suggested before. It seems a good idea ... quite useful. It'll probably be coming in the not too distant future. JIMp talk·cont 17:53, 28 April 2008 (UTC)[reply]
Agreed with both of you. - Dan Dank55 (talk)(mistakes) 19:49, 28 April 2008 (UTC)[reply]
"All this hooplah could be so easily avoided by a simple rule to put the source value first and (a) conversion(s) in brackets where appropriate." - It doesn't solve the problem in all situations though. Who decides what is a suitable conversion? If it is left to the editor of an article then that still allows for the editor to push their personal opinion about what they think. Now in the specific case of the IEC prefixes they are not at all widely used in the real world. They are unfamiliar to the majority of our readership. There already exist, in the real world, other methods to disambiguate non-IEC prefixes (I'll call non-IEC prefixes "JEDEC prefixes" because they appear in the JEDEC standard). For example specifying the exact number of bytes is commonly used in displays regarding file and disk sizes. The question is, what better serves the average reader that articles are targeted towards? Using unfamiliar IEC prefixes isn't going to help the reader as much as using other methods that are already commonly found in the real world. The argument that IEC prefixes can be Wikilinked is missing the point because it's not the place of Wikipedia to advocate something that is unfamiliar and not widely used. The argument that Wikilinking teaches the reader something is also missing the point because if our sources used in articles think IEC prefixes should be taught then we as article writers can report that, otherwise trying to force something that is opposite to the real world sources we use is promoting an artificial view of that world we are meant to be reporting without bias. Common sense, right? Fnagaton 17:44, 28 April 2008 (UTC)[reply]
No,it doesn't solve the problem in the presence of a POV-pushing idiot unconstrained by dispute resolution. So what? What part of Wikipedia space does? Septentrionalis PMAnderson 18:03, 28 April 2008 (UTC)[reply]
I think by placing something along similar lines in the guideline it can help mitigate a lot of the POV pushing that can happen and still be flexible enough to allow IEC prefixes for those rare articles that need to report them. This helps article writers by giving them obvious guidance in the form of the guideline and then in turn this helps the reader who is going to be reading the articles. Fnagaton 18:09, 28 April 2008 (UTC)[reply]
A lot of what you're writing here is common sense—unfamiliar terms/units/symbols/abbreviations/etc. are not what we need—but I don't see this proposal more help than hinderence in this respect. We, as a whole, decide what's appropriate. Consensus has shown that conversions between metric and customary units are generally desireable. Exceptions will exist but these can generally be sorted out on a case-by-case basis. Instead, will be find editors debating over what "the literature" uses ... what constitutes this "literature"? JIMp talk·cont 18:13, 28 April 2008 (UTC)[reply]
I'm not too worried about the metric and customary aspect, I think generally it's fine but that's because I'm not exposed on a daily basis to articles related to that subject. OK I've seen some articles where they talk about World War II guns and someone thought it would be "an excellent idea" (i.e. it's not a good idea in reality) to change the measurements into metric, making the article completely opposite to all the sources used on that subject. It's just that I think computer memory and computer storage are large enough topics and POV pushing about IEC prefixes happens often enough that instead of it being "an exception" a guideline should give specific guidance about not using unfamiliar units unless specifically and obviously used by the majority of sources relevant to the article. Fnagaton 18:38, 28 April 2008 (UTC)[reply]
I've always thought of "the literature" meaning sources cited by articles and by other closely related topics. Fnagaton 18:41, 28 April 2008 (UTC)[reply]
Then you probably have a different notion of "literature" than most people are going to use in the interminable arguments. And, going back to what Jimp said above in discussing the "current (protected) form", I just want to make sure that everybody involved understands that the "protection" is not supposed to be any endorsement whatsoever of that form; I'm sure Jimp was just being clear in his identification of what he was talking about, but I want that point made clear here. Gene Nygaard (talk) 13:04, 29 April 2008 (UTC)[reply]
I agree with Fnagaton that the IEC binary prefixes need to be covered totally independently of this proposal. (It isn't like they are something never used outside Wikipedia, either—it is perfectly legitimate for our house rules to require them, or not to.) Gene Nygaard (talk) 13:10, 29 April 2008 (UTC)[reply]

I would like to elaborate on one of my objections to "follow current literature". Sometimes measurement units are a consensus-driven process (that is, consensus on the level of the world, a nation, or a disipline). Other times it is legislated. (In today's world, there is no such thing as world-wide legislation; only nations or groups of nations (like the E.U.) pass legislation that can actually be enforced on the ground.) It would be wrong for Wikipedia to ignore this distinction. Wikipedia editors should use the units required by legislation, if applicable, even if the current literature is slow to adopt them. This argument does not apply to voluntary standards, such as the IEC binary prefixes. Although Wikipedia is practically immune to weights and measures laws, because we don't sell anything, our readers are not. We should not encourage those of our readers who sell stuff to violate the law. --Gerry Ashton (talk) 14:29, 2 May 2008 (UTC)[reply]

Default units, specialist units

The proposal is just an extension of the current "In scientific articles, use the units employed in the current scientific literature on that topic." What is the correct "scientific literature" to follow? -- SWTPC6800 (talk) 19:33, 28 April 2008 (UTC)[reply]

Indeed. As you say, it has a similar problem for editors. It was simpler for editors when it provided a default and said:
  • In scientific articles, SI units are the main units of measure, unless there are compelling historical or pragmatic reasons not to use them (for example, Hubble's constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s−1)

As I understand it, the current wording was suggested by Septentrionalis PMAnderson Wikipedia_talk:Manual_of_Style/Archive_93#Units_of_measurement. The default option should be put back and a 'literature' option can be provided for cases where the default is not acceptable to specialists. I declare this to be a proposal. Lightmouse (talk) 21:53, 28 April 2008 (UTC)[reply]

Thanks, but I prefer "scientific literature"; it improves on what I wrote A more general reference to "reliable sources" would also be acceptable. Septentrionalis PMAnderson 17:24, 29 April 2008 (UTC)[reply]

The problem is the absence of a default. An editor should not be required to study an entire set of literature before making a single edit. I propose that the wording matches the previous bullets about UK and US units as follows:

  • For science-related articles, the main units are SI units.

If there are a few exceptions where primary place for SI is forbidden, then they can be listed. Lightmouse (talk) 14:31, 2 May 2008 (UTC)[reply]

    • This is twice in error:
      • Consulting the literature begins, and will usually end, with checking the source from which the measurement comes. If other editors come with extensive citations from standard sources all using a different system, then and only then do we do our own conversion. This is not difficult.
      • We need no default. We do not need to rule on this; we can let editors, in their several fields, decide what is clearest for the readership. Septentrionalis PMAnderson 17:23, 2 May 2008 (UTC)[reply]
        • Actually there's another error. WP:MOS doesn't "forbid" anything. It's a guideline.LeadSongDog (talk) 17:38, 2 May 2008 (UTC)[reply]

Ah, I think I am beginning to change my view of what you mean by consulting literature. The worry of many people is that each editor is required to study an entire set of literature for each edit. Are you saying that 'Put the source value first and the converted value second' should be the starting point? Lightmouse (talk) 18:57, 2 May 2008 (UTC)[reply]

Please can we have semi-protection?

During the past several days we've had multiple new users appearing (most of them Tor users that have been indefinitely blocked) making reverts and edits. Would adding semi-protection help stop IP anonymous and new users from editing? While I hate to close this page to legitimate new users who have something productive to contribute I also think the sock related vandalism is not helping this topic. Fnagaton 11:27, 29 April 2008 (UTC)[reply]

There hasn't been anything subtle about the socks. I just created a sock report for Zimbian, and if they post anything more in this discussion, I'll have them checkuser'd and out the door. - Dan Dank55 (talk)(mistakes) 12:19, 29 April 2008 (UTC)[reply]
Thank you. Fnagaton 12:55, 29 April 2008 (UTC)[reply]
then 'checkuser' me. I am new but you are being uncivil, you must stop nowZimbian (talk) 12:35, 29 April 2008 (UTC)[reply]
"Dmcdevit (Talk | contribs) blocked "Zimbian (Talk | contribs)" (account creation blocked) with an expiry time of indefinite ‎ (troll)" Fnagaton 14:16, 29 April 2008 (UTC)[reply]
Given the above recent Tarapotysk and CharlesFinnigan instances too, I've submitted a (semi) at RfPP.LeadSongDog (talk) 21:37, 1 May 2008 (UTC)[reply]
I'm assuming the semi you submitted was meant to be for the actual page, and not this one ('cause I don't see any disruption here). Anyway, the main page has been protected for a few days now; that'll end in three. If vandalism starts up again, resubmit. Cheers to you all, and keep up the good work! Master of Puppets Call me MoP! :) 05:56, 2 May 2008 (UTC)[reply]

enough is enough

I have recently noticed this unjustified accusation of “disruptive editing”, following a BRD edit by Omegatron on MOSNUM, and this unjustified accusation of “malicious attacks”. The “disruptive editing” claim is especially rich considering the events on MOSNUM over the past couple of days.

I withdrew from the binary prefix discussion after incivility towards Omegatron made it unproductive to continue there. After the above-mentioned edits I am no longer prepared to continue discussing here either. I now withdraw from the 'follow current literature' discussion. I will consider returning if one of the following two things happen:

  1. either Omegatron assures me that the editor in question has withdrawn the accusations
  2. or Omegatron assures me that his continued absence from this debate is unconnected to these accusations.

Thunderbird2 (talk) 15:41, 29 April 2008 (UTC)[reply]

What Omegatron did was not BRD, therefore what I wrote is completely justified. Also it is not an accusation, it is a statement of the facts that happened which demonstrates the bad faith attacks Omegatron has made. His edits are a matter of record here and the content of them cannot be disputed. He made a change without any talking about it first, when his edit was reverted and I asked him to talk about it first he just reverted back again and made threats regarding blocking "Fnagaton should have been blocked with Sarenne", for example. Making such threats is an abuse of his position as admin, hence the ANI. Lets see what SMcCandlish said following Omegatron's abusive post, from the same link as before: "I don't agree with Fnagaton on this, but I hardly need to suggest that he's got a crazy-making brain disease to make a case that he's misinterpreting how to go about changing the guideline. The fact that Fnagaton is passionate about this issue, as others have been before (on both sides) has nothing to do with the validity of their arguments either way. Having been accused of WP:DE simply for being passionate and steadfast myself in the past, I sympathize in a Voltaire way - I defend Fnagaton's right to express what he is thinking (civilly), but if I disagree with his logic I'll certainly say so, since that's where the reason in argument is. Debate by flamethrowing is unproductive pen...sword-waving.". Omegatron makes threats and he was using unproductive flamethrowing. You see now why I am justified? What is different to this situation is that there was plenty of talking about it before, then the guideline changed (BRD), then it was talked about more and then edited some more. The two situations cannot logically be compared. If you want to recuse yourself because of Omegatron's bad behaviour then that is your right. If you want to see unjustified accusations then just read the bad faith accusations and bullying Omegatron wrote first of all. Fnagaton 16:10, 29 April 2008 (UTC)[reply]
There's nothing wrong with some passion. In some editors cases, however, the best of intentions regularly spill over into tendentious editing, to the point where it borders on incivility. If I were to say "You are wrong", I would in effect be saying "I know the TRUTH (and you don't)." At best, it's unproductive and at worst it leads to the kind of bickering that has been endemic on this page. There is no need to tell people they are wrong when we can simply demonstrate the error of their argument. If the flaw isn't easily demonstrated, we can take a page from Oliver Cromwell and form a request instead: "I beseech you, in the bowels of Christ, think it possible you may be mistaken." Please lets all try a little harder to assume good faith.LeadSongDog (talk) 23:35, 29 April 2008 (UTC)[reply]
From WP:PA "A posting that says "Your statement about X is wrong because of information at Y", or "The paragraph you inserted into the article looks like original research", is not a personal attack." Fnagaton 08:31, 30 April 2008 (UTC)[reply]
(Inserted out of sequence): Correct, it is not. It would, however, be better if phrased without the pronouns "Your" or "you", as in "The statement about X is contradicted by information at Y" or "Is there a WP:RS to show for the para inserted by [difflink]? It looks like WP:OR". Same result, without risk of picking a fruitless fight. LeadSongDog (talk) 14:41, 30 April 2008 (UTC)[reply]
I agree we all do need to try harder to assume good faith. So if Omegatron will apologise for and retract his personal attack comment "Fnagaton should have been blocked with Sarenne." and his other personal attack comments "Please try to edit productively and cooperatively. If you continue revert warring without justification, you'll be blocked." I will consider that to be him demonstrating he is interested in assuming good faith and then I will retract my comments. Fnagaton 08:28, 30 April 2008 (UTC)[reply]

Day 5: for how long will this important page be frozen?

The page should be unfrozen and the disputed text—which clearly does not have consensus (not in its current form, anyway)—should be pasted HERE, where it should have remained. That way, you people can argue over it in an appropriate place and there will be no trouble on the project page itself. That is what talk pages are for. TONY (talk) 09:21, 2 May 2008 (UTC)[reply]

It has consensus to stay because the counter arguments are not as good as the arguments to keep it.DavidPaulHamilton (talk) 09:38, 2 May 2008 (UTC)[reply]
Um ... I don't think so. TONY (talk) 09:47, 2 May 2008 (UTC)[reply]
An example of a lack of good argument is above.DavidPaulHamilton (talk) 09:59, 2 May 2008 (UTC)[reply]
Oh, this is tedious. I'm not talking about specific arguments I myself might have, for or against. I'm referring to the lack of consensus, which is obvious above. If you and your crowd fail to agree that the disputed text should be removed from the project page until a consensus is achieved, I don't see how the page can be unfrozen. Yes, I agree that some form of guideline is necessary WRT to the topic of the text that was prematurely shoved into the project page, and I don't necessarily disagree with all of that text; but I do have qualms with some of it, and have explicated this above. TONY (talk) 12:18, 2 May 2008 (UTC)[reply]
Just because some people have voted "oppose" it doesn't mean there is a lack of consensus because those oppose votes are using reasons that are refuted/fallacious/weak when compared to the arguments for the "support" votes. Your argument about the process of the consensus reached, for example, is refuted by the comments on this page (and the village pump) by other editors, yet you still continue to have an existing oppose vote logged. As for unblocking the page, since you did earlier state "as soon as the page is unfrozen, I and others will quite justifiably start hacking into the bits" then no, I don't think the page should be unblocked if you're going to be making edits without consensus. Fnagaton 13:39, 2 May 2008 (UTC)[reply]
Fnagaton, the "oppose" voters are not doing so by ignoring the arguments. We happen to think the "support" votes are using reasons that are refuted/fallacious/weak when compared to the arguments for the "oppose" votes. Each position is simply our, and their, opinion. There is no absolute fact on either side. Jeh (talk) 14:27, 2 May 2008 (UTC)[reply]
Not correct because the weak oppose vote arguments are refuted by the stronger arguments, this is demonstrated, for example, by the counter arguments presented at the village pump and the comments on this page by uninvolved editors. What this means is that there are no substantive oppose vote arguments left. i.e. there are no oppose vote arguments that have not been refuted. Fnagaton 15:12, 2 May 2008 (UTC)[reply]
The stuff at the Village Pump had only to do with the consensus process. The fact that "MB" is ambiguous, and for precision must be disambiguated at every use, remains unrefuted, even supported by an overwhelming majority at previous straw polls. Jeh (talk) 15:25, 2 May 2008 (UTC)[reply]
That is a red herring because it mentions something that doesn't tackle the issue being discussed. This is because the current guideline text does already state "existing prefixed forms of the byte are ambiguous" followed by "clarify their meaning where necessary using familiar techniques" which refutes the need to make such a comment in the first place. It is like me saying "The sky is blue, that remains unrefuted" and then presenting that, like the comment above did, as if it somehow supports an oppose vote. For the avoidance of doubt the statement "The fact that "MB" is ambiguous, and for precision must be disambiguated at every use, remains unrefuted" is irrelevant and does not support an oppose vote. Fnagaton 15:40, 2 May 2008 (UTC)[reply]
Congratulations on the recent improvements in the level of civility here. Please let's keep it up. May I remind editors that Protected is not the same as "Frozen". If there are partial changes that have concensus, they can be implemented using the {{EditProtected}} template. LeadSongDog (talk) 14:01, 2 May 2008 (UTC)[reply]
  • Significant numbers of users clearly do not think much of the arguments in favour of the text. Simply asserting again and again that one side has strong arguments and the other side has weak arguments will get us nowhere. LeadDog, that mechanism is hardly applicable when the text was inserted without consensus in the first place. This will become a key issue when the page is unblocked: the text should be removed and discussed here in the proper way. That is due process. TONY (talk) 15:52, 2 May 2008 (UTC)[reply]
  • Repeating the same refuted or weak arguments will not get us anywhere, i.e. it is unreasonable to exepect refuted or weak arguments to be accepted as part of the guideline. Consensus and compromise does not mean having to accept every single weak refuted argument and minority point of view. A way forward is for those using refuted or weak arguments to produce much more substantive arguments or to let the process continue without obstruction. The claim the text was added without consensus and without due process has already been refuted by the comments on this page and at the village pump. As Francis Schonken wrote earlier "Yes the procedure was somewhat unusual. Nothing inappropriate or whatever though, congratulations!" and the opinion of Francis matters because they are an uninvolved admin. Again, consensus does not need an individual to agree when that individual does not provide substantive argument or provides argument that has already been refuted. Fnagaton 15:56, 2 May 2008 (UTC)[reply]
  • NIce try Tony. There is no question about it; the only thing that would happen if those who support the new guideline showed goodwill and allowed it to be stripped out of MOSNUM and worked on here is nothing would be agreed upon and nothing accomplished. The intransigence of the proponents of the IEC prefixes and the wild extreme fringes of the proponents of the SI would block all progress towards following the common-sense practices observed by the rest of the world. All they have to do is dig in their heels. This isn’t a failure to “assume good faith” on my part—that policy doesn’t require that people suspend common sense!

    All general-interest magazines and all encyclopedias routinely communicate to their readerships without relying upon units of measure that the typical Wikipedia reader doesn’t recognize and will not likely encounter in the real world after leaving Wikipedia. And yet those who would delete this common-sense guideline still insist on doing it their own way. The result is that one article on Wikipedia uses entirely different terminology than another and this just makes Wikipedia look foolish.

    What part of “There are now ten archives dedicated exclusively to battles over the IEC prefixes” don’t you understand? As Rilak said, “[the] binary units of measurement, KB, MB, GB, etc. are here to stay regardless of whatever efforts to change them.” It’s time to get real and deal with this entire, broad issue to bring Wikipedia in line with the rest of the world. The only possible way that can happen is when the guideline stays in MOSNUM as is (no edit warring over there) and a green-div version is worked on here. Any other way and I absolutely guarantee you that there will be a B20 archive before something is finally done about this. Greg L (talk) 17:22, 2 May 2008 (UTC)[reply]

It is even more obvious that there is no consensus for always use SI. Therefore the former text does not represent consensus, and should not be reverted to. Septentrionalis PMAnderson 17:17, 2 May 2008 (UTC)[reply]

  • I agree to that point too. I also agree with DavidPaulHamilton’s point and with what Fnagaton had to say. Greg L (talk) 17:55, 2 May 2008 (UTC)[reply]

Tony: To answer your rhetorical question posed by your choice for this section heading, MOSNUM protection will end when editors no longer behave as you threatened earlier (“I will never agree to (blah blah)…”, and how the moment the page becomes unfrozen, you will instantly start unilaterally “hacking” away at it), and we agree to work collaboratively on Fourth draft, below, in good faith and actually accomplish something constructive. Nothing will have been accomplished if all the above becomes the “B11” archive and we immediately have to go to a “B12” archive (and B13, B14… etc.). Greg L (talk) 18:41, 2 May 2008 (UTC)[reply]

Copy from current MOSNUM

{Quick link to version on MOSNUM}

The following red-div section is a reference version to start with. Please make edits to Fourth draft, below.

Follow current literature

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:

Preference for modern units

Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.
Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or metric rather than SI—Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline. Editors should write…
  • “a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm3 Honda motorcycle engine”;
  • “Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude” (unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices);
  • “a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10−6 s–2”, in the science of gravimetry.
Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems. Even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no best way. For instance, writing "a 450 cc (450 cm3) motorcycle engine" is inappropriate even though it is in conformance with the SI. "The Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inches (5,766 cc)” is appropriate for a historical, American-made engine. "The Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 in3)" is appropriate for a modern, American-label engine that is classified in liters. But writing "the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches" would be inappropriate in an article primarily about a European-made sports car.
There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities but the new units didn’t see widespread adoption. Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB)". However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, such as "kilobyte (KB)" and "megabyte (MB)", for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to "Binary prefixes", below).
Level of difficulty (Do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.

Fourth draft

{Quick link to version on MOSNUM}

The following green-div section is a “live” version for making proposals on. Please don’t do edit warring here. Discuss your proposals and edits in Discussion of “Fourth draft”, below.

Let’s not treat the fourth draft as so sacrosanct; that’s what this is here for: a sandbox. If someone has what they think is a good idea, toss it out there for others to look at. And don’t be defensive if someone replaces it with something else; we always have the red-div for reference. If someone is considering trying an edit they really know would be unhelpful and they know full well that the edit would be strongly opposed, don’t bother. Give & take. If someone has what they think is a truly bright idea that will gain consensus, add it to the below green-div ASAP. If everyone embraces the philosophy that they will only make edits intended to be one-and-a-half steps forward and only a half step backward (greater consensus with each move), this may go smoother. That’s my 2¢. Greg L (talk) 01:07, 3 May 2008 (UTC)[reply]

Follow current literature

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:

Preference for international units

Wikipedia generally prefers international systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write "He was 1.83 metres (6 foot) tall", not the reverse.
Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or non-SI metric—this should be followed, since our readers should be able to converse with those knowledgeable in the discipline. For example:
  • “a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm3 Honda motorcycle engine”;
  • “Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude”;
  • “a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10−6 s–2”, in the science of gravimetry.
Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems. To retain accuracy when quoting sources, editors should generally use the units used by your cited source as the primary value for that particular measurement. The units to choose for parenthetical conversion througout an article is highly dependent on the subject matter. Even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no best way. For instance, writing "a 450 cc (450 cm3) motorcycle engine" is inappropriate even though it is in conformance with the SI; simply linking the first instance of “cc” to the Cubic centimeter article is sufficient. Writing "the Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inches (5,766 cc)” is appropriate for a historical, American-made engine. And writing "the Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 in3)" is appropriate for a modern, American-label engine that is classified in liters. But writing "the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches" would be inappropriate in an article primarily about a European-made sports car.
There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities but the new units didn’t see widespread adoption. Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB)". However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, such as "kilobyte (KB)" and "megabyte (MB)", for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to "Binary prefixes", below).
Level of difficulty (Do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.

Discussion of “Fourth draft”

{Quick link to “Copy from current MOSNUM”}

  • I’ve started this process by addressing a concern of LeadSongDog in his 22:50, 29 April 2008 (UTC) post. Greg L (talk) 18:24, 2 May 2008 (UTC)[reply]
"Uniting" many-field topics

I would give SI or unit accepted with SI preference when writing an overview of many topics that do not use the same units. An example of that would be an article North American oil importations. Since US uses barrels, Mexico uses [insert Mexican unit here] and Canada uses m3, when uniting the three in one, give preference to SI units, even if the US article is written in barrels and the Mexican article is written in [insert Mexican units here]. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 19:18, 2 May 2008 (UTC)

Maybe then, we should find a better example to use that oil production. I thought I was safe to use this example because barrels of oil are universally used by the world press, the CIA fact book, and in all world-wide commodities transactions. If one reads up on oil production in any professional print encyclopedia, the convention is to simply follow standard practices in the oil industry: barrels. Thus, I felt it was a good choice for an example to use here: use barrels of oil (like “11 million bbl/day” as the CIA factbook says) like all the rest of the world unless you are writing of an article specifically about Canadian oil production. Even then, when a Canadian producer is selling their oil on the world market, they quote in cost per barrel. Why should someone hear about how oil costs $120 per barrel on the TV or radio news, or read of it in the newspaper or Newsweek, or in Encyclopedia Britannica, and then go to Wikipedia and see cubic meters first? That makes no sense whatsoever to me. Thus, it seemed like a perfect example to use in order to get this point across Greg L (talk) 19:14, 2 May 2008 (UTC)[reply]

Add "unless there is a predominant international usage for the non-SI units." to what I just said. What I say may not apply to oil imports, but you get the idea.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 19:18, 2 May 2008 (UTC)

      • Yes, the choice of oilbbl was unfortunate, it too is a ratsnest. The problem arises not with small quantities but rather with the large multipliers. Multiplied units like MMbbl or Mbbl are very much subject to locally variant interpretation. When discussing the size of global reserves or even global trade, we need to discuss numbers in the (short scale) trillions of barrels. Add to that the fact that barrels have more than one size and it just gets too confusing for the average young reader who (through most of the world) only uses SI and may never have seen a barrel. Nearly all the international trade in oil is conducted via oil pipeline or supertanker by specialists who would not be in the least confused by the choice of bbl, tonne, or m3 units, while the commodities and futures markets are dealing in pure abstractions of value that would happily use any unit that doesn't take up too many characters in abbreviated form on their trading screens but would only use one unit and one multipler in any dealings done. They will of course treat Brent Crude, West Texas Intermediate, and a few other benchmark types as seperate commodities that may differ in price by as much as a few percentage points from one to another or as much as twenty or thirty percent over a year. Why not leave this choice up to the editors at Petroleum to work out? LeadSongDog (talk) 20:09, 2 May 2008 (UTC)[reply]
        • I would appreciate some evidence for the existence of this fantasy young reader who reads English and is interested in oil and has "never seen barrels". We are not here to write for Neverneverland, but for the same audience who takes other English-speaking publications. Septentrionalis PMAnderson 20:18, 2 May 2008 (UTC)[reply]
          • My point was a simple one and I ran on too long. Oil barrels make a bad example. Try light-years or carats instead.LeadSongDog (talk) 20:31, 2 May 2008 (UTC)[reply]
            • Light-years and parsecs are, like barrels, more likely to be known to the average young reader of the subject than petameters, and far more likely to convey an idea. Septentrionalis PMAnderson 20:46, 2 May 2008 (UTC)[reply]
              • Running this google news query just now found various recent English-language stories reporting oil spills in gallons, litres, tons and barrels. Should we convert to all of them?LeadSongDog (talk) 21:34, 2 May 2008 (UTC)[reply]
                  • Who suggested doing so? But your link presently begins with a WSJ article which says 11 million gallons; if that is the only source for the spill, we should use it (even converting to a quarter-million barrels, which was probably what their reporter heard, would mistate the precision). The next says 100 liters (less than a barrel). Again, we should not convert; we should state what our source tells us. Septentrionalis PMAnderson 21:53, 2 May 2008 (UTC)[reply]
Or the current wording: “Wherever a discipline consistently uses its own units”. Regardless of how the basic principle is conveyed, if we can agree on that principle, and can then agree that the example points properly demonstrate the principle, then we’ve got it. Greg L (talk) 19:21, 2 May 2008 (UTC)[reply]

Yes, I guess adding what I wrote would be kind redundant.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 19:34, 2 May 2008 (UTC)

A problem for many users is that the current text could be interpreted as *forbidding* SI units. If the intent of the text is about putting non-SI units in primary position and still permitting SI units in secondary position, then perhaps the wording should be made clearer. Lightmouse (talk) 19:36, 2 May 2008 (UTC)[reply]

How do you read it to do that? It recommends against giving SI primary position when, as with bbl, some other unit is customary, but that's all. Septentrionalis PMAnderson 19:43, 2 May 2008 (UTC)[reply]

The proposal is huge that nuances are lost as soon as you get 20 words further on. There are examples of what 'not to do' that quote SI units and these could be taken to mean that the intent is to forbid SI. Lightmouse (talk) 19:51, 2 May 2008 (UTC)[reply]

I would have thought Preference for modern units (SI) and all the examples of engine displacements would address any possible ambiguity in this regard. If your feel that a fair, honest, straightforward interpretation (no hidden strings assumed) can be construed as somehow forbidding parenthetical conversions to the SI, then let’s fix it. Note that the current wording says “Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise.” There are so many examples—besides oil—that could be added but things would get cluttered awfully fast. I would think the general principal of Follow current literature should suffice. Greg L (talk) 19:48, 2 May 2008 (UTC)[reply]

The four bullets in the current guideline are succinct enough to be explicit and usable. Headbomb's example above looked like it could become a succinct bullet and do all that you seem to want. Lightmouse (talk) 19:58, 2 May 2008 (UTC)[reply]

The phrase “Saudi Arabia exported 9.0 million barrels of crude” from the fourth draft does not contain a conversion to SI units, thus implying there should be no such conversion. Also, the forth draft says "'a gravity gradient of 3.1 µGal/cm', not 'a gravity gradient of 3.1×10−6 s–2'", which implies that if a unit that is metric but neither SI nor accepted for use with SI is used, it is incorrect to provide a conversion to the appropriate SI unit. I suggest the draft be immediately updated to show any acceptable conversion, and a statement that conversions other than those shown in the examples are incorrect. Otherwise it is difficult to judge just what conversions the draft is, or is not, advocating. --Gerry Ashton (talk) 19:59, 2 May 2008 (UTC)[reply]

Exactly. Look at the bullet style in the current guideline that predates this proposal. It is good. The prose style in the proposal takes too long to read and it is clear from this little discussion that even we do not fully understand its intention. It is a problem that gets worse as more nuances, more examples, and more justification is added. Lightmouse (talk) 20:08, 2 May 2008 (UTC)[reply]

Does anyone here know how current periodicals on these subjects handles these two conversions? Or how Encyclopedia Britannica and other professional encyclopedias handle this issue. Or how a really general-interest, English-language periodical like Newsweek would handle it barrels of oil? I don’t know the answer to how the Canadian-version of Newsweek handles barrels of oil, but I would argue that if even they don’t disambiguate to cubic meters, then doing so here wouldn’t be appropriate. In the case of gravimetry (gals), the unit SI-equivalent (“reciprocal seconds squared”) wouldn’t found anywhere but here and is a really hard unit to get one’s mind around. Just linking to the linked gal/cm link and reading that it is a centimeter per second squared of acceleration for each centimeter of elevation is all that is required to properly educate the reader and prepare them for their studies elsewhere. Why teach them a hard-to-understand unit they wouldn’t encounter in the real world? This issue cuts precisely to the heart of the discussion: to follow current literature and not run off doing our own thing promoting the adoption of the SI when it doesn’t really “clarify” anything for anyone. Greg L (talk) 20:10, 2 May 2008 (UTC)[reply]

You do not need to solve that now. Simply state the guideline that is no longer than any of the existing bullets. I do not believe that there is a clear and present danger that needs to be solved today relating to oil and gravimetry articles. You are clearly interested in binary prefixes but I suggest that you give just one example in its own sub-bullet. The whole thing can be wrapped up in one bullet with one sub-bullet of one sentence each. Lightmouse (talk) 20:18, 2 May 2008 (UTC)[reply]

As Mencken said, "For every problem, there is a solution that is clear, simple, obvious, and wrong." Attempting to say what exactly should be done in a bulletpoint is one of these. No bulletpoint is complex enough to fit the universe; but

  • Use the units customary in a given field.
    • For the sciences, often, but not always, this will be SI.
    • It is often advisable to state a measurement in the style and units of the source. This may increase accuracy as well.
  • Add parenthetical conversion to other units, SI, US customary, or imperial, if this will make the article clearer.

would be a good start. Septentrionalis PMAnderson 20:31, 2 May 2008 (UTC)[reply]

(ec with Gerry Ashton's remarks, which follow). Septentrionalis PMAnderson 20:33, 2 May 2008 (UTC)[reply]

Please don't waste your time defending barrels of oil or gal/cm. Since these are examples, they should represent what to do in a wide variety of similar cases, and readers shouldn't have to be gravity or petroleum experts to understand the examples. Consider the gravity example: a non-SI unit that is accepted for use with SI in some circumstances. Another such unit is the astronomical unit. The absence of a conversion for gals implies that one shouldn't provide a conversion for astronomical units either. If the reasons for not providing a conversions for gals can't be understood by anyone lacking a degree in physics, it's useless as an example. --Gerry Ashton (talk) 20:25, 2 May 2008 (UTC)[reply]

    • If one understands accelleration and the concept of a gradient, one can see why μGal/cm is an intuitive unit of measure for the change in gravitational accelleration with position, and can also see why s-2 does not suggest accelleration. If one is unfamiliar with accelleration and gradients, the reason for the appeal of μGal/cm is not apparent, and so one will not prepared to deal with other units, where the same line of reasoning does not apply. For example, calories and joules are both recognized as energy units, so it would be more natural to provide a conversion to joules when calories are mentioned. --Gerry Ashton (talk) 21:04, 2 May 2008 (UTC)[reply]
      • But it doesn't need vector calculus to understand "the rate at which acceleration varies from place to place" or to see the units (unit acceleration)/(unit length) as natural. What requires training is the idea of restating these as L/T2 and L, and cancelling the Ls. Septentrionalis PMAnderson 21:36, 2 May 2008 (UTC)[reply]

I now see those bullets. Thanks. Will they be put in a green box as a proposal on this page? Lightmouse (talk) 20:38, 2 May 2008 (UTC)[reply]

Feel free to do so. Septentrionalis PMAnderson 20:40, 2 May 2008 (UTC)[reply]

Has your proposal got support of anyone besides yourself? Lightmouse (talk) 20:46, 2 May 2008 (UTC)[reply]

It's not a proposal. It's a stub. But since it says nothing that isn't in the green box, it should be at least as widely supported as it was. Septentrionalis PMAnderson 20:52, 2 May 2008 (UTC)[reply]

What is a stub? Lightmouse (talk) 20:54, 2 May 2008 (UTC)[reply]

That is to say, those few bullets stand to a proposal as a Wikipedia:stub is to an article. Septentrionalis PMAnderson 20:58, 2 May 2008 (UTC)[reply]

I am getting confused now just when I thought I was beginning to understand you better. A stub article is an article that happens to contain few words. Are you saying that your text in bullet form is a proposal that happens to contain few words? Lightmouse (talk) 21:05, 2 May 2008 (UTC)[reply]

No; nor is a stub article only defined by being short. Septentrionalis PMAnderson 21:42, 2 May 2008 (UTC)[reply]
Well regardless of definition, I thought a stub article is still an article. I will take your word that it is not. I am having trouble understanding why you wrote the bullet text. Are you proposing that bullet text should be put into wp:mosnum? Lightmouse (talk) 21:54, 2 May 2008 (UTC)[reply]
We could do worse; but I wrote them because you demanded bullet-points. Septentrionalis PMAnderson 21:58, 2 May 2008 (UTC)[reply]
OK. So if it is a proposal, it is a lot easier to understand. If it has support of Fnagatron and GregL (and any other proposer), then put it in a green box in a new section. I think it shows progress. Lightmouse (talk) 22:04, 2 May 2008 (UTC)[reply]
All: Real life calls. I only want to add that “barrels of oil” seems to be a perfect example to use (among others) because it can be understood by anyone and perfectly illustrates the principle of Follow current literature since it illustrates a not-so-clear-cut principle that there is often no need for a parenthetical conversion, but sometimes there is if the topic is dealing with Canadian oil production. Though seemingly complex on the surface, the gal seemed like a good choice because it is a non-SI unit that is universally used in a particular field. If someone else wants to suggest another example to replace it because it’s too complex, that’s fine by me. But, if the suggested replacement appropriately comes with a parenthetical conversion, I would still advocate keeping the gal because it is an example of a unit that universally needs no parenthetical conversions. Greg L (talk) 21:38, 2 May 2008 (UTC)[reply]

Let us deal with the bullet first. Work on the example can come second. Lightmouse (talk) 21:40, 2 May 2008 (UTC)[reply]

  • Nonsense. Examples are what matter; if we agreed on them, refining bullet points would be a triviality; but this entire page is a triviality. Septentrionalis PMAnderson 21:48, 2 May 2008 (UTC)[reply]
Has anyone actually done a yahoo/google search for "Canadian oil production"? Check out the returns, especially the ones from Canadian sources here. Not one mention of cubic metres—not one in all those articles. They were all in barrels. Some like this one from Canadian News Wire used barrels and cubic feet to describe Imperial Oil's oil and nature gas production. A quick search of Imperial Oil's website found the use of barrels. And just in case anyone was wondering, the French word for barrels is barils, which can be found on the French version of that page ici. Saying that cubic metres are the common way that the Canadian literature states Canadian oil production just doesn't hold water and should be removed. —MJCdetroit (yak) 02:15, 3 May 2008 (UTC)[reply]

Thanks MJCdetroit. I’ll go revise the fourth draft per your teachings. We’ll see if that’s “one-and-a-half steps forward” or backwards ;-). Greg L (talk) 06:29, 3 May 2008 (UTC)[reply]

"The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere." Aren't these objectives of all writing? Why presume that a reader wants to learn even more in their studies elsewhere? Are non-students and non-researchers unwelcome? TONY (talk) 08:18, 3 May 2008 (UTC)[reply]

Proposal by Pmanderson

Has the bullet text proposal by Pmanderson got any support from Fnagatron or GregL? Lightmouse (talk) 08:23, 3 May 2008 (UTC)[reply]

Editprotected

Please add {{disputedtag|section=yes}} after the section heading Units of Measurement on the project page; the above interminable discussion should justify it. If I were the responding admin, I would consider whether there is evidence that any of this page has ever had enough consensus to be a guideline. Septentrionalis PMAnderson 21:48, 2 May 2008 (UTC)[reply]

When in doubt
  • I would write something like "When SI (or units accepted along SI units) and non-SI units such as U.S. Customs are used in about equal frequency in the literature, give SI units preference for main text and list non-SI units in parenthesis". [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 19:19, 2 May 2008 (UTC)

I don’t even see why you would advocate such a statement Headbomb. The current wording seems to promote use of the SI even stronger than your wording. It broadly prefers SI except for those weird cases (motorcycles in cc) where disciplines consistently use other units. Greg L (talk) 00:52, 3 May 2008 (UTC)[reply]

I’ve been busy for a few tending to a problem. I don’t understand about “protecting a discussion page”. What is that about? Will someone explain what is currently going on? Greg L (talk) 00:32, 3 May 2008 (UTC)[reply]

Let me make this suggestion: Let’s not treat the fourth draft as so sacrosanct; that’s what it’s there for: a sandbox. If someone has what they think is a good idea, toss it up and change the forth draft gree-div. And don’t be defensive if someone replaces it with something else. If someone is considering trying an edit they really know would be unhelpful and they know full well that the edit would be strongly opposed, don’t bother. Give & take. If someone has what they think is a truly bright idea that will gain consensus, change the gree-div fourth draft ASAP. If everyone embraces the philosophy that they will only make edits intended to be one-and-a-half steps forward and only a half step backward (greater consensus with each move), this may go smoother. That’s my 2¢. Greg L (talk) 00:45, 3 May 2008 (UTC)[reply]

I think I now understand what that above tag is for. If it is a request for permission to edit the version on MOSNUM, that seems like an utterly inane idea to me. That’s what the fourth draft green-div is for: editing. So far, only Pmanderson has used it! I suggest this section be deleted. Greg L (talk) 01:03, 3 May 2008 (UTC)[reply]

Minor Request

Since you're already discussing changes to this section anyways, is there any chance that the phrasing of “the auto weighs 1450 kg (3200 lb)”, not the reverse. could be changed to make it more technically accurate? Since kg is not a measure of 'weight', it doesn't seem to be the best example. I know it sounds like nitpicking, and I'm not even suggesting that things shouldn't be phrased that way in general articles. I just don't think that even a minor error such as that should be in the document that sets the example for how to phrase things. :) (Surely you could change it to saying that an auto measures xm long(y ft), right?) Anyways, just a request. Dismiss entirely at your discretion. 139.57.100.104 (talk) 03:32, 3 May 2008 (UTC)[reply]

  • It is entirely a reasonable request and it shouldn’t be a deal breaker either way. You might be interested to know that the U.S. Dept of Commerce and the European equivalents allow that the term “weight” (as in “net weight”) to legally mean “mass” in trade and commerce. This is to legally endorse the common practice of referring to mass as weight. In so doing, one doesn't have to have awkward syntax like “I massed myself at 71 kilograms today.” I subscribe to Aviation Week & Space Technology (a magazine that has advertisements for AWACs planes and missile defense systems) and noticed that even NASA recently avoided the use of the term “mass”. They were talking about a spacecraft for going back to the moon and wrote of how it would have a “weight on Earth of such ‘n such kilograms” even though a “mass of such “n such kilograms” (with no specificity for what heavenly body it was sitting on) would have sufficed. This ‘mass v.s. weight’ issue is one of two misconceptions on the whole, broad subject. The other misconception is that the kilogram is a unit of mass whereas the pound is a unit of weight. In fact, both are units of mass. Greg L (talk) 06:23, 3 May 2008 (UTC)[reply]
  • The pound is a unit of mass? Since when? I thought that the slug was the unit of mass.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 12:20, 3 May 2008 (UTC)

2 by 4 inches (50 mm × 100 mm)

The guideline recommends "1.2 in × 1.8 in" over "1.2 × 1.8 in", fair engough, but what if the "×" is spelt out as "by" and/or the "in" (or whatever unit) is spelt out as "inch(es)"? "1.2 by 1.8 inches" would seem quite normal to me, "1.2 inches by 1.8 inches" being perhaps a little over the top but not wrong. How about "1.2 × 1.8 inches" verses "1.2 inches × 1.8 inches"? How about "1.2 by 1.8 in" verses "1.2 in by 1.8 in"? I sort of feel it's a question of "×" vs "by" more than "in" vs "inch(es)". Thoughts anyone ... JIMp talk·cont 07:08, 3 May 2008 (UTC)[reply]

  1. ^ "599gtb.pdf" (PDF). Ferrari. Retrieved 2008-04-24.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers&oldid=209890989"