Cannabis Ruderalis

thcscience_admin
Archive
Years and dates archives

Binary Prefix discussion moved

To make more room to discuss Wiki linking years on this page, the Binary Prefix discussions have been moved to this page Wikipedia talk:Manual of Style (binary prefixes). -- SWTPC6800 (talk) 01:18, 12 April 2008 (UTC)[reply]

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]

Uncertainty vs. repeating decimal

I have just edited the Conversion of units article because it used parentheses to indicate a repeating decimal. For example, it used "3.3(3) × 10−4 m" to mean that the rightmost 3 repeats forever. I changed it to read "3.3 ×10−4 m" because this notation is also used for repeating decimals, and it will not be confused with uncertainty.

An example of an expression of uncertainty is in Seidelmann's Explanatory Supplement to the Astronomical Almanac (1992, p. 693) where the Newtonian constant of gravitation is given as 6.67259 (85) ×10−11 m3kg-1s-2. A longer expression for the same thing would be 6.67259 ×10−11 ±0.00085 ×10−11 m3kg-1s-m3kg-1s-2.

I believe this guildeline should have a section added to specify that repeating decimals are expressed with overbars, not parentheses, to avoid confusion with an expresion of uncertainty. I also believe that it should have a section recommending that uncertainty should be expressed with ± notation rather than parentheses because people unfamiliar with this notation would not know the order of magnitude of the uncertainty. That is, in the previous example, it isn't obvious whether the uncertainty is ±0.00085 ×10−11, ±0.000085 ×10−11, or ±0.0000085 ×10−11. --Gerry Ashton (talk) 19:22, 8 March 2008 (UTC)[reply]

Good point. This looks like sensible advice to me. Thunderbird2 (talk) 19:32, 8 March 2008 (UTC)[reply]
±8.5 ×10−15 may be easier to read, as long as we're recommending; but the deprecations should include a caveat: 3.3(3) × 10−4 m would be fine, if it were clear what was meant. Septentrionalis PMAnderson 21:40, 8 March 2008 (UTC)[reply]
BIPM advocates use of parentheses in this way. And that would be fine if it were clear to everyone, but that's a big if isn't it? Thunderbird2 (talk) 21:50, 8 March 2008 (UTC)[reply]

The problem with overlines for repeating digits is that there are at least two variants and both have their issues.

  1. Inline CSS: 0.1<span style="text-decoration:overline">37</span> – 0.137
  2. Unicode: 0.13̅7̅ = 0.13&#x305;7&#x305; (U+0305) or 0.13̄7̄ = 0.13&#x304;7&#x304; (U+0304) – 0.13̅7̅ or 0.13̄7̄

— Christoph Päper 20:30, 13 March 2008 (UTC)[reply]

The span approach displays properly on Windows XP, both Internet Explorer 7 and Firefox. The unicode approach does not display properly in either case; it displays as a square after the 3 and the 7. --Gerry Ashton (talk) 02:35, 14 March 2008 (UTC)[reply]
Yes, the problem with the Unicode approach is its state of support, but the CSS approach is more fundamentally flawed in that the style, which conveys the information, is lost in plain-text environments, such as copy and paste, text or non-CSS browsers, search engines. Using a different HTML element that, unlike span, has a default styling only helps in few of these cases. Years ago I used a non-combining overline (or macron) in front of the first digit to repeat: 0.1¯37 – 0.1¯37. It doesn’t look as good, but is very safe. One could also imagine using brackets or braces instead of parentheses: 0.1[37] or 0.1{37}, but I think this would be a WP-specific convention, which we try to avoid. — Christoph Päper 09:09, 14 March 2008 (UTC)[reply]
I've never seen a non-combining overline before; I didn't even know this character existed. I suspect few people would know how to enter it. I think it would be just as much a WP-only convention as square brackes or curly braces. --Gerry Ashton (talk) 00:30, 22 March 2008 (UTC)[reply]

Major objection: "3.3" is completely illegible-as-intended in Mozilla-based browsers (Firefox, Mozilla, SeaMonkey, Camino) under MacOS X using default fonts (i.e. for probably half of all Mac users, since many have abandoned Safari as a slow, feature-poor and crash-prone piece of frak). For those who will even notice the difference at all, it does not look like a three with an overline, it looks like a three with a flat top, like those found in many serif fonts. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:43, 5 April 2008 (UTC)[reply]

Ga, Ma, ka preferred to bya, mya, tya

Resolved
 – Consensus agreed to (edited) change.

Wikipedia talk:Manual of Style (dates and numbers)/Archive 78 danced around the question, but never quite addressed the question of whether to discourage use of mya, focussing instead on discouraging MYA. Everyone seemed to prefer ka, Ma, Ga although there was some confusion over capitalization (SI usage for multipliers is quite unambiguous: k for kilo, M for mega, G for giga, T for tera, but it seems this wasn't universally grasped). Once archived, the discussion ended without addressing it. As phrased now, it leaves the impression that mya is an equally desirable choice to Ma, yet I don't believe that was the intention of those discussing the question. Reopen? LeadSongDog (talk) 07:40, 14 March 2008 (UTC)[reply]

I prefer to spell it out in full as "million years ago" wherever it occurs in the article, and use Ma where abbreviation is necessary (e.g. in taxobox fossil ranges). I feel this looks smarter and saves people translating it in their heads each time they see it. I agree that mya is obsolete though. That said, I've not got a very firm opinion yet... Verisimilus T 08:36, 14 March 2008 (UTC)[reply]
My feeling from working with a number of geophysicists is that Ma is preferable, and I'm quite willing to agree to a prescription here that it should be preferred. I can't agree with Verisimilus that the whole three-word phrase should be trotted out many times in an article, unless used only twice or three times, perhaps: tedious to read. Besides, the fact of the abbreviation itself helps to focus the readers' minds. Tony (talk) 08:47, 14 March 2008 (UTC)[reply]

The present text reads

I would suggest a change to read

Would something like this work for us? LeadSongDog (talk) 17:37, 14 March 2008 (UTC)[reply]

Is it really necessary to wikilink each term if you've explained what it means? I find excessive links distracting. What more could a user want to know about "mya" than what it means? Verisimilus T 18:18, 14 March 2008 (UTC)[reply]
Fair enough. I had them each wikilinked to annum anyhow, the one time should be enough.LeadSongDog (talk) 19:53, 14 March 2008 (UTC)[reply]

Now we have

Absent further comment, I'll make the above change in a day or two.LeadSongDog (talk) 18:10, 17 March 2008 (UTC)[reply]

emend: strike "and wikilinked"; RC only gd 4 ¬50000a. --Verisimilus T 19:56, 17 March 2008 (UTC)(no kb!)[reply]
How on earth did I miss that??? Good catch!LeadSongDog (talk) 21:56, 17 March 2008 (UTC)[reply]

checkY Done. LeadSongDog (talk) 18:00, 18 March 2008 (UTC)[reply]

Just a followup note to the geophysicist point: That may be true, but I know from equally direct experience that anthropologists definitely (and paleontologists sometimes but not always) prefer kya, mya. I'm happy with the current text since it isn't FORCING one or the other. I strongly suspect that anthro types editing anthro articles will initially use, and reject reversal of, the format they use, and geo/astro types will do likewise with their preferred symbols, so it shouldn't be a big deal. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:39, 5 April 2008 (UTC)[reply]

{{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]

  • 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]

  • 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]

Years

Start of discussion moved from Lightmouse talk page
You had best stop un-bracketing years until you get some consensus. I'm reporting this to WP:ANI. Baseball Bugs What's up, Doc? 12:59, 20 March 2008 (UTC)[reply]

You were already blocked once for this activity. STOP IT. Baseball Bugs What's up, Doc? 13:03, 20 March 2008 (UTC)[reply]
Right I don't know what is going on here but please stop for now. Contribute to the discussion on the AN/I but stop delinking the dates. Theresa Knott | The otter sank 13:10, 20 March 2008 (UTC)[reply]
As I understand it, the place to debate policy on dates is Wikipedia talk:Manual of Style (dates and numbers). Feel free to raise it there. Lightmouse (talk) 13:13, 20 March 2008 (UTC)[reply]
First rule: Don't cop an attitude with an admin. Baseball Bugs What's up, Doc? 13:17, 20 March 2008 (UTC)[reply]
That's fine I don't care. Lightmouse I do not wish to debate the policy. I only wish to make sure that you actually have concensus for your changes. Can you point me to the discussion that shows this please. Theresa Knott | The otter sank 13:20, 20 March 2008 (UTC)[reply]
At the very least, the user did not get consensus from anyone to clobber the "year in baseball" template entries. Baseball Bugs What's up, Doc? 13:41, 20 March 2008 (UTC)[reply]

Lightmouse, you continued making controversial edits after you've been contacted abouts this. I've withdrawn your AWB approval for duration of discussion at WP:ANI#Units and Years. Please respond there. MaxSem(Han shot first!) 14:02, 20 March 2008 (UTC)[reply]

Baseball Bugs, I am not sure what 'cop an attitude' means but that phrase along with the word 'defiant' used elsewhere sounds like an accusation of incivility. I have no incivil intentions in my responses. I try to be polite and expect the same from others. Please assume good faith.
There are popular misconceptions about date links so it does not surprise me that it is being questioned. I would prefer not to describe the policy here. Quite apart from anything else, you may not feel comfortable with what I say about it. There are plenty of other editors there that have extensive experience with this issue at Wikipedia talk:Manual of Style (dates and numbers). I would be happy to see you there. I hope that helps. Lightmouse (talk) 14:36, 20 March 2008 (UTC)[reply]

End of discussion moved from Lightmouse talk page

  • Hard to discern what this is about. If Lightmouse is delinking trivial chronological itmes, such as 1998 and 1970s and 20th century, I applaud it. He has the weight of MOS behind him. Read the guidelines, please.Tony (talk) 02:57, 23 March 2008 (UTC)[reply]
I randomly selected about 25 of Lightmouse's recent edits of this nature, and they all seem well within current date policy to me. -/- Warren 04:25, 23 March 2008 (UTC)[reply]
I have the impression that Lightmouse was, as usual, implementing MOSNUM consensus, when an admin over-reacted to a change that was not to his liking. The discussion of the entire non-incident is archived here. Thunderbird2 (talk) 15:31, 23 March 2008 (UTC)[reply]
I've just noticed that Lightmouse has not done any editing since posting the avove message. I hope he is just taking an Easter break. Thunderbird2 (talk) 15:36, 23 March 2008 (UTC)[reply]
I have been watching the discussion. I appreciate the contributions made by all. I would appreciate your further assistance in getting my AWB approval reinstated. See the statement above by MaxSem (I've withdrawn your AWB approval for duration of discussion at WP:ANI#Units and Years) and my request for reinstatement at Wikipedia_talk:AutoWikiBrowser#Please_reinstate_approval.
Lightmouse (talk) 11:03, 24 March 2008 (UTC)[reply]
If Baseball Bugs is the admin in question (I'm not sure I followed the rant correctly), he should actually be severely sanctioned at ANI. It is unbelievably inappropriate for an admin to attempt to intimidate another editor into yielding on a legitimate editing dispute by pulling rank and very obviously implying a blocking or other admin-level retaliation threat, especially a borderline-incivil one at that. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:13, 5 April 2008 (UTC)[reply]

Units

Which system to use

* For US-related articles, the main units are US units; for example, 23 miles (37 km). * For UK-related, the main units are either metric or imperial (consistently within an article).

* For other country-related articles, the main units are metric; for example, 37 kilometres (23 mi).

Let us end the confusion by adopting the Metric first, Colonial/Imperial second rule (Option 3). It will make editing easy when the U.S. metricates. I must also add that some items like broadcast antenna heights are always listed in meters and the current rule is a very ambiguous burden to subjects such as these. SirChan (talk) 17:18, 25 March 2008 (UTC)[reply]

I agree - it does seem confusing and unnecessary to make a special exception from the general "use SI units" rule in this instance. Verisimilus T 21:07, 25 March 2008 (UTC)[reply]
I diagree. There is no guarantee that the US will ever metricate, and for US articles it makes sense to have the nationally preferred system of measurement listed first. Cheers, Rai-me 22:48, 25 March 2008 (UTC)[reply]
To Verisimilus: The American has to tilt their head to read the Colonial units on a non-US or international article, the Brit might have to change mindsets every time he reads an article, and the others have to tilt their heads in order to read the metric units in a US specific article or might not have an appropriate metric value in a British article.

To Rai-me: My mom has a maxim, "Always be prepared." The U.S. government has stated since 1866 that this is the preferred system but has been busy with other matters. Metrication has been increasing in recent years--just look at bottled water! This is on the internet; any English-speaking person can find out information about something U.S. or U.K. specific. (To all:) These rules are Byzantine! I might as well include Julian dates in articles also to accommodate historians and Eastern Europeans. SirChan (talk) 02:30, 26 March 2008 (UTC)[reply]

By your mother's philosophy, should we also create an article for the 2096 Summer Olympics to be prepared? Wikipedia is not a crystal ball. It is very unlikely that the US will metricate completely at any point in the near future. Whether the US government has stated that the metric system is the preferred system or not has no bearing on this situation. What matters here is what readers will understand, and for Americans, that is obviously imperial units over SI ones. Metrictaion may be increasing slightly (bottled water is actually still mostly in imperial units - soda bottles, however, are in litres), but the system used by far the most often is imperial. I fail to see how the feet (m) system is "Byzantine" when used in American-related articles, as the imperial system is the one that Americans, who are the most likely to read about American topics, understand the best. Wikipedia is optimized for readers over editors, so the guidleines should remain as is. Cheers, Rai-me 01:35, 29 March 2008 (UTC)[reply]
By the same token, it is very much true that many measurements in U.S.-related articles were originally made in metric units. The present rule is ludicrous. Original units should be first; for articles related to the United States, that will often mean English customary units—but that is by no stretch of the imagination an invariable truth, nor something to aspire to in our MoS. Gene Nygaard (talk) 03:47, 29 March 2008 (UTC)[reply]
I am not arguing that we should continue to use the "imperial (metric)" system because it was used first in American-related articles, and shouldn't be changed now. The rules are not, nor should be, the same as those outlined in WP:ENGVAR. The present rule is no more "ludicrous" than the rule to use US$ for American articles, £ for British articles, € for French articles, etc., and not US$ throughout. It makes sense to use the system in an article that is used by the readers of the country relating most to the article topic, so the status quo should not be changed. -- Rai-me 17:06, 29 March 2008 (UTC)[reply]

I fail to see how the feet (m) system is "Byzantine" when used in American-related articles, as the imperial system is the one that Americans, who are the most likely to read about American topics, understand the best.

I'm not talking about the measuring systems here, I'm talking about the rules on the units. (BTW, the Imperial system is not used in the U.S., only in the U.K. and the pre-metric system for the Commonwealth realms.)SirChan (talk) 02:02, 31 March 2008 (UTC)[reply]

I am talking about the rule as well. The rule is not "Byzantine" if it makes sense to use in order to optimize conditions in American-related articles for American readers. See the article about United States customary units, "Imperial units" is often used to describe US units. It is not used in the same context as English units, but it is still correct. -- Rai-me 02:14, 31 March 2008 (UTC)[reply]

←outdent←
I'd been meaning to put my thripence in but Gene's pretty much stated my main point. Currently we've got the following.

  1. For US-related articles, the main units are US units; for example, 23 miles (37 km).
  2. For UK-related, the main units are either metric or imperial (consistently within an article).
  3. For other country-related articles, the main units are metric; for example, 37 kilometres (23 mi).
  4. American English spells metric units with final -er (kilometer); in all other varieties of English, including Canadian English, -re is used (kilometre).
  5. In scientific articles, use the units employed in the current scientific literature on that topic. This will usually be SI, but not always; for example, natural units are often used in relativistic and quantum physics, and Hubble's constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s−1.
  6. If editors cannot agree on the sequence of units, put the source value first and the converted value second. If the choice of units is arbitrary, use SI units as the main unit, with converted units in parentheses.

I've replaced the bullet points with numbers for ease of reference. Suppose we replace all of that with "Original units should be first."

  1. For US-related articles, the original units will generally be units US units.
  2. For UK-related articles, the original units will generally be either metric or imperial units.
  3. For other country-related articles, the original units will generally be metric.
  4. How a unit is spelt in this or that dialect is irrelevant here.
  5. In scientific articles, the original units will be use the units employed in the current scientific literature on that topic.
  6. If editors cannot agree on the sequence of units, the original units should be first.

What have we not covered?

  • the case where the choice of units is arbitrary
  • consistency within an article

The choice would be arbitary if the source(s) give(s) both metric/SI and imperial/US/other. Consistency within an article is a minor concern when stacked up against fidelity to the sources. If the order is changed, this should be noted as a footnote, unless the original was a rough approximation to start with. Jɪmp 07:41, 31 March 2008 (UTC)[reply]

Regarding Option 2 (UK Articles), an American or anyone else who reads a UK-centric article that's only in Imperial units is going to be a useless article if the metric value isn't included in parenthesis. The site is worldwide, so the information must be available to the widest possible audience. This Babel of units narrows audiences to a specific group and restricts the flow of information. SirChan (talk) 06:22, 1 April 2008 (UTC)[reply]
Similarly, an article with only US units is going to be useless to a non-American. In fact, as an Australian, I have a better feel for imperial units than I do for US units. Conversions to metric should generally be given. JЇѦρ 08:07, 7 April 2008 (UTC)[reply]

Ton vs. Tonne

    • Use long ton or short ton rather than just ton (the metric unit—the tonne—is also known as the metric ton).

The tons are very confusing especially in this international context (the Internet). In the U.S. a "ton" is the aforementioned short ton while in the rest of the Anglosphere, the "ton" is the aforementioned long ton. Someone might unknowingly, incorrectly use "tonne" because it is similar to "ton." I'd rather use Megagram over tonne and put the type of unit when talking about the non-metric tons (e.g. Imperial Ton, U.S. Ton).SirChan (talk) 02:55, 26 March 2008 (UTC)[reply]

The problem is that megagram is not all that familiar a term to most. Jɪmp 04:01, 28 March 2008 (UTC)[reply]
The comfort of a familiar "word", even when you (whether referring to the editor adding the information, or "you" as readers of Wikipedia in general) don't have the foggiest idea what it means, is an illusionary goal. I'd say we should just outlaw all "tons" of any sort on Wikipedia. Use megagrams, teragrams, and the like for metric units of mass; use meganewtons and the like for the metric units of force; use megawatts and the like for the units of power, joules with appropriate prefix for the units of energy, use pounds for the English units of mass, Btu per hour for the English tons as units of power, cubic feet for the English tons as units of volume, etc. Gene Nygaard (talk) 03:54, 29 March 2008 (UTC)[reply]
One of the key concepts of the metric system is, if you know what mega- means, and you know what gram means, then you know what megagram means. I think most people know what mega- means; I'm not so sure about gram. --Gerry Ashton (talk) 04:24, 29 March 2008 (UTC)[reply]
SirChan claims "In the U.S. a "ton" is the aforementioed short ton" which isn't quite right. An oversimplification, and thus useless. In some contexts in the United States, even when you limit the discussion to talking about "tons" as units of mass rather than as units of force, of energy, of power, and who knows what all the ton of other tons are used for, an unidentified "ton" is not a short ton. For example:
  • " accounts for roughly 5% of global wheat production, or about 30 million tons (1.1 billion bushels) in 2004" (in Durum)
  • "In 1967, Pakistan imported 42,000 tons, and Turkey 21,000 tons." (in Norman Borlaug)
  • "Displacement: 27,000 tons (27,433 metric tons)" (in USS Guam (CB-2))
  • "At 4,200 metric tons (4,130 tons), with a length" (in Knox class frigate)
SirChan also claims that "while in the rest of the Anglosphere, the "ton" is the aforementioned long ton", apparently unaware that people in Canada don't use long tons except in contexts in which they would be used in the United States (i.e., mostly for ship displacements; in old documents from more than half a century ago, perhaps for some mining such as iron ore or coal production). Gene Nygaard (talk) 14:35, 12 April 2008 (UTC)[reply]
Furthermore, it is likely that an unidentified tonne in Canadian French from pre-metrication days is a short tonne (or a long tonne in shipping), not a tonne métrique. Gene Nygaard (talk) 14:44, 12 April 2008 (UTC)[reply]

Sea of blue

The template name {{nowrap}} is linked four times (on every occurrence) in the section Non-breaking spaces. I would like that we do as we teach, so I would like to fix that. That is, only have the first occurrence linked and the other as normal text. Easy enough to do, just use {{tlf|nowrap}} instead of {{tl|nowrap}}, which will render like this: {{nowrap}}. Any one that disagrees?

--David Göthberg (talk) 18:41, 27 March 2008 (UTC)[reply]

So fix it. Nobody's going to worry about as minor an edit as that. If anyone even notices, they'd probably wonder why they hadn't noticed such a glaring oversight. Jɪmp 23:30, 27 March 2008 (UTC)[reply]
Well, personally I think that any edit to the MOSxxx pages should be discussed first (except really minor things like fixing some spelling etc). And even though tradition and recommended style is to not wikilink a word many times in one page or section, tradition up until now has been to wikilink template names on every occasion in documentation. So I don't like to just be bold and make an edit to the MOSNUM that goes against tradition.
Of course, the reason people have been wikilinking the template names all the time might have been that up until now they did not have a simple way to write a {{template name}}. But now we have the brand new {{tlc}}, {{tld}} and {{tlf}}. They produce output like this: {{name|parameters}}, {{name|parameters}} and {{name|parameters}}.
Anyway, I did the edit to the MOSNUM since it seems no one disagreed.
--David Göthberg (talk) 18:21, 28 March 2008 (UTC)[reply]
Generally I'd agree that edits should be discussed first except minor ones. I'd call that minor. Jɪmp 15:32, 31 March 2008 (UTC)[reply]
WP:BOLD, WP:BRD. While the R in BRD is more likely to happen here than on many other pages, the B is policy, and the D is the only way that WP works in the first place. Major changes certainly should be discussed, but I've seen a great number of really good ideas introduced into MOS* pages by bold edits, often reverted, discussed, modified and reinstated, less often but still pretty frequently simply accepted because they were wise. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:20, 5 April 2008 (UTC)[reply]

sq mi v. mi²

While I had no part in the edit to this page that User:MJCdetroit reverted (save for indirectly making him aware of it that changed the use of sq mi instead of mi² for square miles and other square and cubic U.S. customary units from a shall to a may. I'd argue that may is the better option, especially where the metric measurement is the primary measurement and the customary is a conversion. Caerwine Caer’s whines 05:53, 31 March 2008 (UTC)[reply]

Or that the page uses too many bytes. His hatred of the metric system made him call the SI symbols abbreviations on my edit. SirChan (talk) 06:12, 31 March 2008 (UTC)[reply]
Every change to this page, no matter how small, should be discussed first. SC's changes were not discussed and they changed content that was thoroughly discussed and agreed upon in the past. That's why I reverted your changes.—MJCdetroit (yak) 13:43, 31 March 2008 (UTC)[reply]
Could you kindly point out that prior discussion? Unless this was settled very recently, I'd like to bring this point up now that it's been brought to my attention. The general style guide that I most often refer to, the GPO Style Manual is fairly conservative in its usages, but it calls for mi² and doesn't even discuss the possibility of sq mi. Caerwine Caer’s whines 18:44, 31 March 2008 (UTC)[reply]
The two most recent times it came up was here and here. I think that some of those early discussions also explored the usage of non superscripted abbreviations for metric units; which were pretty heated discussions. There is an earlier discussion somewhere regarding this, but I haven't found yet. —MJCdetroit (yak) 20:34, 31 March 2008 (UTC)[reply]

The discussion was rather thin in both those links, and given that the style guide I've got access to specifies the use of exponents only, banning the use of exponents for customary units in science articles strikes me as excessive. The arguments given for the current policy stuck me as mostly (with some slight exaggeration) of the variety that since customary units are so quaint and archaic, the people who understand them better than SI can't possibly know what exponents are anyway. Caerwine Caer’s whines 01:05, 1 April 2008 (UTC)[reply]

Symbols are only used in SI; all other systems use abbreviations. It is obvious that calling shorthand SI abbreviations instead of symbols is incorrect thus doesn't need to be discussed. Pushing a half-truth to further your agenda is intellectually dishonest. SirChan (talk) 06:12, 1 April 2008 (UTC)[reply]
Nonsense. "Symbols" are a terminology preferred by metrologists in any context in which they want to distinguish them from run-of-the-mill abbreviations. We have symbols for non-SI metric units. We have symbols for metric units. A number of factors are involved, including a fair amount of uniformity (but we don't even have total uniformity in the symbols acceptable for use with SI.
Some of the factors which lead to a preference for this terminology is to emphasize the point that as "symbols" they
Gene Nygaard (talk) 00:20, 13 April 2008 (UTC)[reply]

Since Caerwine says the discussion was thin in both the cited links, I'm not going to bother with them. Let me weigh in strongly in favor of at least permitting mi² in the MoS. I'd like to see it recommended.

This usage (mi³, in², etc.)is in fact quite common in English; there isn't going to be any problem with anyone understanding it. It is even more common in other cases such as lb/ft³ where the ft³ in the denominator is more common than "cu ft". And then, though many people do use all sorts of weird abbreviations such as "cusecs", we should insist on standard symbols being used in that context. That is, we should require "ft³/s" for this unit. Not "cusecs", not "cu. ft./sec.", not any of the sloppiness we see in general usage. We can set our standards higher than that and achieve sensible results. Gene Nygaard (talk) 00:35, 13 April 2008 (UTC)[reply]

While I don't feel strongly about this, I like Gene's suggestion because it would be clear and unambiguous. Thunderbird2 (talk) 06:18, 13 April 2008 (UTC)[reply]
I don't have a strong feeling about whether superscripts should be used with American customary units of measure in non-technical articles. I do feel that when they are used, they should be created with <sup> and </sup> rather than the tiny superscript numbers available in the editor. Various people have presented various disadvantages of the tiny superscripts in other threads, but I don't like them becase they are hard to read. --Gerry Ashton (talk) 11:40, 13 April 2008 (UTC)[reply]

The discussion here seems to be favor of being permissive in the use of exponents with non-SI unit symbols. However rather than being 100% bold, I've added a dispute tag to the relevant section of the page to see if more comments can be attracted before making a change. Caerwine Caer’s whines 19:16, 13 April 2008 (UTC)[reply]

The of contrasting the two most common styles of km² and sq mi has worked very well for the last few years. We should try to be as consistent as possible with our style. We wouldn't want to reintroduce the use of sq km debate again. If anything, maybe we should make a noted exception in the case of denominators, but in general stick with what as worked in the past—exponents for SI and no exponents for imperial. —MJCdetroit (yak) 14:55, 14 April 2008 (UTC)[reply]
IIRC the MoS preferred “mi2” (or “mi²”) once, i.e. one simple rule for all systems of measurements still in use. Then enough people pleaded for the amateurish “sq mi” (or perhaps “sq.mi.”) to be allowed. Afterwards others came who wanted to extend this to allow “sq km” and possibly disallow “mi²”, which of course was rubbish, but – anyhow – the compromise was to have incompatible rules for metric and US units. Articles and templates were changed. Sure, this looks silly if you see both close to each other, which happens a lot with our (IMHO unnecessary) conversion requirement (or advice) for (alledgedly illiterate) US readers. Even with enduring and conclusive discussion, readability loses against mannerisms almost every time around here.
Similar things can be said about “mph” vs. “mi/h”, although more people spoke up for the former, illogic but custom style in this case.
I hope my memory does not remember things too wrongly. — Christoph Päper 16:35, 14 April 2008 (UTC)[reply]
MJCDetroit, I don't see how allowing exponents with non-SI unit symbols would encourage the use of "sq km". If anything, I would think that the current system encourages it more. More to the point, can you give an example of any other style guide that uses the current arbitrary distinction that MOSNUM has at present? I've already pointed out one guide which specifies the use of exponents for both SI and customary units, and no one who has ever used the GPO style guide would ever accuse it of being a source of innovation. If anything, it is decidedly conservative in its approach to style. Caerwine Caer’s whines 17:11, 14 April 2008 (UTC)[reply]
The NIST allows for both by stating: Squares and cubes of customary but not of metric units are sometimes expressed by the use of abbreviations rather than symbols. For example, sq ft means square foot, and cu ft means cubic foot (on page C-3). NASA's style guide has a section for mph, but says nothing more. The style guide of the guardian uses some other variation of sq miles. I don't have copy in front of me but, the Chicago Manual of Style (CMS 15.55-8) makes mention of imperial measures using sq and cu except they add a period with them (sq. mi.); which we don't do.
The argument was to allow for the most commonly used (km² and sq mi) and discourage others. I don't think it was done to irritate the far superior intellect of our German contributors or to make it easier for our "alledgedly illiterate" [sic] amateur U.S. readers (or any other amateur readers in the Commonwealth). Those were just beneficial side effects.
Wikipedia doesn't specific have to follow any said style guide in this area; we can (and do) create our own. Which is what other online encyclopedias like Encyclopedia Britannica and Encarta do by using the amateurish abbreviations for alledgedly illiterate readers. They probably do what they feel is best by adhering to the saying, if it ain't broke don't fix it. I think, in general we should stick to what has worked for us so far. —MJCdetroit (yak) 19:57, 14 April 2008 (UTC)[reply]
Problem is, you seem to be the only one who thinks that MOSNUM ain't broke on this subject. Both the Guardian and Encarta use sq for both SI and customary units, probably because they feel that consistency in application is preferable. Can't comment on the EB link as I'm not signed up for that site. The NIST document you cite uses sq only for the survey units (and even then inconsistently as the square rod is is given as both sq rd and rd2). The inconsistency in that 2002 version of the document is fixed in the current version. There sq is used only with synonyms of the rod (pole and perch) that have no symbol. In all usages, including the square rod (rd2), squares of symbols are indicated by an exponent. To the degree that there appears to be a standard used elsewhere, it is to use the same convention on which form to use for both SI and customary units. Caerwine Caer’s whines 21:08, 14 April 2008 (UTC)[reply]
I object because I don't want to mess with any consistency that our style guide has built. It's kind of ironic coming from someone who insists on U.S. over US. Check your link to the NIST on the bottom of page C-3 note 3; sq & cu are still there. Why, in my opinion because they are still more common than the superscripts; just like U.S. is still more common than US. However, at this point, if this is the "cheese" that you seem to need— then take it. I just really don't care anymore. —MJCdetroit (yak) 00:38, 15 April 2008 (UTC)[reply]
I'll admit to overlooking that explanatory footnote, but on reading it, it seems to me that NIST prefers the use of exponents as the footnote reads as an explanation of what one might encounter, not what they prefer be used. Indeed that footnote pretty accurately sums up my position on what the MOSNUM should say on this topic. "Squares and cubes of customary but not of metric units are sometimes expressed by the use of abbreviations rather than symbols. For example, sq ft means square foot, and cu ft means cubic foot." (Emphasis added.) As for the cheese, I'll give it a bit more time to age first. Caerwine Caer’s whines 02:28, 15 April 2008 (UTC)[reply]

ISO 8601 dates

I'm seeing a rash of these in various articles within the text. Any chance there is a bot that can go in and change these when not used with a reference? Vegaswikian (talk) 06:52, 31 March 2008 (UTC)[reply]

Any such bot would have to be semi-automatic, with a person approving every change, because there is no automatic way to detect whether a piece of text is a direct quotation. --Gerry Ashton (talk) 17:45, 31 March 2008 (UTC)[reply]

There are thousands of links to common units of measurement, some in templates. As with links to plain english words, this is contrary to wp:overlink.

It might be hard to get agreement on a complete list of common units. However, the *most common* are responsible for the most overlinking. The following are the most common units:

  • inch, foot, yard, mile, millimetre, centimetre, metre, kilometre. Plus their squares and cubes.
  • avoirdupois pound, avoirdupois ounce, milligram, gram, kilogram
  • millilitre, litre
  • millisecond, second, minute, hour, day, week, month, year
  • Any combination of the above

Comments? Lightmouse (talk) 17:00, 31 March 2008 (UTC)[reply]

Hi Lightmouse. Welcome back :). My view is that there is no need to link to common units of time, nor to the most common SI units (eg m, kg); the entire universe is familiar with these! But I see some units in your list (like pound, inch and foot) that, while common to native speakers of English, are not to those who have learnt it as a second language. I think WP should be accessible to non-native speakers, which means that such units should be linked. Thunderbird2 (talk) 17:33, 31 March 2008 (UTC)[reply]

Thanks for your support. I agree with your first and second sentences. In your third sentence, I agree with the principle but not the concluding word 'linked' i.e. I would say 'should be converted'. Lightmouse (talk) 20:34, 31 March 2008 (UTC)[reply]

Glad to help.
Yes, if a conversion is included, that weakens the case for a link. I'm not sure if it eliminates it though. What do others think?
A separate, but related point that is specific to feet and inches is the widespread use of ' and " to represent these. Can these be replaced by ft and in? Thunderbird2 (talk) 21:02, 31 March 2008 (UTC)[reply]
I think it is time for a proposal. I propose that where wp:overlink says common units should not generally be linked, the following are given as a *examples*:
  • millimetre, centimetre, metre, kilometre. Plus their squares and cubes.
  • milligram, gram, kilogram
  • millilitre, litre
  • millisecond, second, minute, hour, day, week, month, year
  • Any combination of the above
The list can be extended, but I think it is important to get a small list in place than to spend ages in debate. Lightmouse (talk) 09:22, 1 April 2008 (UTC)[reply]

I agree with Lightmouse's list. Thunderbird2 (talk) 16:23, 1 April 2008 (UTC)[reply]

There's nothing special about unit names. Common unit names are common words. We needn't link them. We certainly want the encyclopædia to be accessable not only to native speakers of English also to those who have learnt it as a second language. However, if we link every word that may be unfamiliar to these people, WP will turn blue. There exists no word in the English language that everyone in the World knows. A balance must be arrived at, it'll be case by case, but the names of units are not special amongst the words of the language. Also, I think we should not underestimate how well known the common imperial/US units are outside of the English speaking world. JЇѦρ 02:24, 2 April 2008 (UTC)[reply]

I concur with the gist of all this; don't care what the specifics of the list are, unless they get goofy. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:16, 5 April 2008 (UTC)[reply]

I have updated wp:overlink.
Lightmouse (talk) 10:58, 6 April 2008 (UTC)[reply]

It has now been reverted. Lightmouse (talk) 21:35, 6 April 2008 (UTC)[reply]

I thought that it was a fairly uncontroversial edit. Is anyone else willing to resolve this? Lightmouse (talk) 21:31, 8 April 2008 (UTC)[reply]

I have added a section at the talk page of wp:overlink inviting contributions here. Lightmouse (talk) 21:53, 9 April 2008 (UTC)[reply]

I was the one who reverted it. I did so not because I disagreed but because it seemed so patently obvious that it was unnecessary to explicitly list these examples. Instruction creep is a real problem for Wikipedia policy and guideline pages. My concern is that when we list out the measurements, someone will misunderstand and one of two things will happen. Either they will attempt to expand the list with all the thousands of other common words that shouldn't be overlinked and we'll end up with a page that's unreadable and ignored or they will try to argue that the lack of inclusion of something from the list now means that it should be linked. A general statement of principle is better for our readers.
WP:OVERLINK already says "Plain English words, including common units of measurement." It's even the very first bullet on the page. If that's not clear enough, I can't see how including a longer list of examples will make it any clearer. Rossami (talk) 22:42, 9 April 2008 (UTC)[reply]

If the issue is confusion over the definition of a "common" unit of measurement (as opposed to an uncommon one, I suppose), perhaps the list could be included as a footnote rather than in-line with the text? Or perhaps a footnote linking to a relevant section of this MoS page? I'm still concerned about instruction creep and would only recommend that approach if there is evidence of significant confusion and/or dispute rather than mere ignorance about the policy. If people are overlinking because they don't know any better, we just need to fix those. Rossami (talk)

I understand and even share your worry about instruction creep. However, some people still insist on linking terms such as those listed here and I have found myself trying to persuade them that everybody else thinks they are common even if they do not. An explicit statement would allow such tedious debates to be resolved quickly. We do not have a big problem with common words but we do with common units. The common unit articles rank almost as high as year articles in terms of number of links to them. Square mile and square kilometre are in the top 50 destination articles, just above '1996'. Metre is almost in the top 100, just above '1969' and 'foot' is in the top 250, just above '1954' (it is interesting to me that 'metre' is more linked than 'foot' even though the former is more common). I don't care how this issue is fixed so if you have a suggestion, that is fine by me. I can't see any means of educating users about this but I can see that explicit statements would allow janitorial editors to remove unremarkable links without getting bogged down in metaphysical discussions about what 'common' means to each disputing user. Lightmouse (talk) 23:20, 9 April 2008 (UTC)[reply]

I took a crack at it in footnote format. (And added some things that seemed obvious to me even though they may have gone beyond the short discussion here.) Opinions on readability would be appreciated. If it's too cumbersome, we can always back it out. Rossami (talk) 04:57, 10 April 2008 (UTC)[reply]

Thank you. It looks fine in general. I do not understand why the human body weight comment is relevant. What do you want editors to do with that information? The phrase 'regardless of measuring system' appears to suggest that readers must always consider the non-metric reference value that is written there even if using kilograms. The unit symbols are 's' and 'lb' rather than 'sec' and 'lbs'. But thanks for reconsidering, I appreciate that. And I agree that some non-metric units should be there. Lightmouse (talk) 08:54, 10 April 2008 (UTC)[reply]
The intent of the body-weight comment was to provide an example of an irrelevant distinction - that the standard deviation of the average weight of an adult male is far greater than the difference between Troy pounds and AD pounds. Pretty much regardless of which version of "pound" you pick, the answer is still going to round to 180 lbs. If you don't think it's helpful, we can leave it out.
On you other point, the official symbols might be 's' and 'lb' but the longer versions are far more common and far more readily understood by the average reader. Ease of comprehension is more important than technical compliance. Rossami (talk) 15:44, 11 April 2008 (UTC)[reply]

The relevant part of MOSNUM reads:

  • Symbols have no plural form, i.e. an s is never appended (‘kg’, ‘km’, ‘in’, ‘lb’, ‘bit’, not ‘kgs’, ‘kms’, ‘ins’, ‘lbs’, ‘bits’).

Thunderbird2 (talk) 16:00, 11 April 2008 (UTC)[reply]

Pressures

I've asked for a conversion template to be made to convert pounds per square inch into kilograms per square centimetre. I'd like the format to be displayed as x lb/in2 (y kg/cm2) but apparantly this may be against the MOS. The discussion is here, along with my reasoning for the use of the display in the proposed format. Comments please. Mjroots (talk) 08:11, 1 April 2008 (UTC)[reply]

It seems we have three possible abbreviations:
  1. psi
  2. lb/sq in
  3. lb/in²
Mjroots points out that 2 and 3 are used in the locomotive industry. 1 is a common abbreviation elsewhere. Which do we allow which do we ban? How do we weigh the desire for consistency against the desire to reflect what is used in specific industries? Is 3 against the rules being a US unit (it's also an imperial one) with an exponent 2 instead of "sq" or do we now apply different rules since pounds per square inch could be considered a unit unto itself? JЇѦρ 08:40, 1 April 2008 (UTC)[reply]
It is largely a historical unit, although it is still used by various heritage railways in connection with their steam locomotives today. What I'm aiming to achieve is to enable readers in Europe, where kg/cm2 is the normal measurement to easily be able to compare our boiler pressures to their locomotives. It will also help us to understand their boiler pressures in comparison to our locomotives. Do you know what 12 kg/cm2 is in lb/in2? I don't, wouldn't have a clue without a conversion! Mjroots (talk) 10:39, 1 April 2008 (UTC)[reply]
This reminds me of using mi/h for miles per hour. While mi/h may be used by some technical publications, the vast majority of people would better recognize mph. As a matter of being consistent throughout the encyclopedia, we should do our best to use one abbreviation—the most common one. In this case psi is the most common so we should use it. However, it also reminds me of the automotive industry (the one I work in) using cid for cubic inches displaced and the medical fields using cc for cubic centimeters. Question being: Do we want to be consistent throughout the entire encyclopedia; even if that means that certain industry articles (locomotive, auto, medical, etc) would use abbreviations different than what is normally encountered in that industry (psi for in/sq in; cu in for cid; cm³ for cc)? Or do we want to make exceptions? —MJCdetroit (yak) 13:59, 1 April 2008 (UTC)[reply]
It is not possible to convert from a unit of pressure to kg/cm2, because kg/cm2 is a unit of mass per unit area, not pressure. I advise against making such a template. Thunderbird2 (talk) 16:22, 1 April 2008 (UTC)[reply]
I agree with Thunderbird2. The one and only correct unit of pressure in the International System of Units is the pascal. No template should be created to convert to any other metric pressure unit; all the others are obsolete and depricated. --Gerry Ashton (talk) 16:34, 1 April 2008 (UTC)[reply]
Just because you don't like the units, it is no reason to make untrue statements. psi or lb/in2 is pounds per square inch, strictly pounds force per square inch (sometimes written as lbf/in2); and it is a pressure measurment. kg/cm2 is strictly kilograms force per square centimetre, which is also a unit of pressure. 1 lb/in2 is 0.07 kg/cm2.Pyrotec (talk) 17:06, 1 April 2008 (UTC)[reply]
As Pyrotec has pointed out, both are valid units of pressure. As far as I'm aware, 1 kg/cm2 is equal to 1 technical atmosphere (at). Although the Pascal is the modern unit of measurement that does not invalidate the kg/cm2 as a historical unit of measurement. All I'm asking for is a comparable, easy to understand conversion. Mjroots (talk) 18:01, 1 April 2008 (UTC)[reply]
It's just not something that should be converted on a regular basis; if a reference unit is non-SI, we convert to SI; if it's SI but there's a reason to express it in some non-SI unit, we might give that as well SamBC(talk) 18:24, 1 April 2008 (UTC)[reply]
I think that some editors that have entered the discussion on this subject need to go back to school. Pressure is the force applied over a unit of area. This is where people forget the difference between force and weight. A kilogram is a unit of mass, which is a fundamentally different quantity to weight, which is actually a force. As an example, 1 kilogram does not weigh the same on the moon as is does on the earth, but the mass (1 kg) is the same. To some extent the kg/cm2 unit is not truly a unit of pressure, as a kilogram is not a unit of force! So it cannot be an SI unit of pressure. Olana North (talk) 18:51, 1 April 2008 (UTC)[reply]
Also being pendant, can I suggest that you read what I and Mjroots (and others) said above. For pressure the units have to be strictly pounds force per square inch, written as lbf/in2 and kilogram force per square centimetre, written as kgf/cm2. We are not intending to run steam engines on the moon, so on Earth the units are measures of pressure; and I'm not aware of any claims that they are an SI unit. kg/cm2 is apparently a common unit used in Europe for recording boiler pressures; and lb/in2 has been used in the UK for a very long time as a unit of pressure. Even if we accept unconditionally that lb/in2 and kg/cm2 are not units of force it is still possible to convert from one set of units to the other set; since they have the same dimensions of weight per unit area. Please explain, as you have apparently been to school, why two authors above consider lb/in2 to be a (Non-SI) unit of force whereas they regard kg/cm2 as not. Being pendant, it is lbf and kgf per unit area. It is also possible to convert from lbf/in2 to kgf/cm2 since they have the same dimensions of weight per unit area. They are being used as gauge pressures not absolute pressures; and we are not intending to compare boiler pressures on different planets, or in space.Pyrotec (talk) 19:38, 1 April 2008 (UTC)[reply]
The psi is a unit of pressure that is defined unambiguously as one pound-force per square inch. As a unit of pressure it can be converted to another unit of pressure, like the pascal. You will find a list of valid pressure conversions (which does not include kg/cm2) in the psi article. Thunderbird2 (talk) 21:24, 1 April 2008 (UTC)[reply]
Actually, it is there, under a different name, the Technical atmosphere. So, all I'm asking for is an alternative way to display an existing conversion. Mjroots (talk) 22:16, 1 April 2008 (UTC)[reply]
In that case could you rephrase the question so that we can understand the requirement more clearly? Are you saying you need a conversion from psi to technical atmospheres? Thunderbird2 (talk) 11:36, 2 April 2008 (UTC)[reply]

(outdent)Rephrase As 1 kg/cm2 = 1 Technical Atmosphere, what I need is a different way of displaying Technical Atmospheres as kg/cm2, to enable an easy comparison with lb/in2, with the two units displayed in a similar format.

The trouble with that is that the at is a unit of pressure, whereas kg/cm^2 is not, so you can't convert between them the way you'd like to. Do you have an example article in mind where you see the need for such a conversion? Thunderbird2 (talk) 13:50, 2 April 2008 (UTC)[reply]
Well, there's the Chemin de Fer du Finistère article for a start. There are plenty of articles on UK steam locomotives that would benefit from conversion in the other direction.Mjroots (talk) 17:37, 2 April 2008 (UTC)[reply]
I see. That helps illustrate the problem. If it were me doing the editing the first thing I would do is change all those kg/cm2 to kgf/cm2. Is that what is meant? (For the reasons pointed out by Olana North, kg/cm2 is not correct). Regarding unit conversions I would say the most important one would be to pascals. Do I understand correctly you wish to convert also to psi? Thunderbird2 (talk) 18:51, 2 April 2008 (UTC)[reply]
I'm just trying to stick to what is common usage. i.e lb/in2 and kg/cm2. This is the usual way of writing boiler pressures, even if it is not strictly accurate. I have no problem with an additional conversion into HPa being added it that is the correct modern unit to use. We convert imperial to metric and metric to imperial throughout wikipedia. Again, I've no problem with that. I understand feet and inches, miles and chains etc. Others understand metres and kilometres. Personally, I would prefer not to have psi displayed. One never sees boiler pressures quoted as 120 psi, it would be quoted as 120 lb/in2 or 120 lb/sq in. Mjroots (talk) 20:09, 2 April 2008 (UTC)[reply]
I'm afraid that takes us back to where we started. The kg/cm2 is not a unit of pressure. Thunderbird2 (talk) 22:41, 5 April 2008 (UTC)[reply]
What is written - kg/cm2. What is meant - kgf/cm2! Looks like I'll just have to enter a manual conversion. Mjroots (talk) 06:48, 7 April 2008 (UTC)[reply]
Mjroots is correct and Thunderbird is wrong; "kg/cm2" is most often (not always, however) a unit of pressure. But we at Wikipedia, unlike other places, don't use "kg" for kilograms force; we kgf to distinguish them from the mass units. Likewise, we at Wikipedia don't use "lb" for pounds force; we use "lbf" to distinguish them from the normal mass units "lb". We should not change that.
Even other sources use the "kg/cm2" or "lb/in2" notations do so consistently; we've just chosen to go with more sensible standards here on Wikipedia. Furthermore, while there are hundreds of car magazines and the like which use "ft./lbs." and the like for torque, we at Wikipedia don't use dots in our symbols, we don't don't add an s to lbs even when it is used for the units of mass and we don't use lb instead of lbf for the unit of force, and most of all, we do not use a slash when there is no division involved, even if a whole slew of car magazines do use symbols like that. We use "ft·lbf" (which as units of torque convert to newton meters, but as units of energy or work convert to joules) or "lbf·ft" (which are normally used only for torque, not for energy).
There is almost no symbols which you cannot see misused (and not just outside Wikipedia; even lots of Wikipedia articles using kgs for kilograms, Kms for kilometers, gm for grams, mtrs for meters, and the like). But that doesn't mean we shouldn't set our standards higher, and use consistent symbols in accordance with modern standards. The whole notion of standard symbols is a recent idea, origination in the 1948 resolutions of the CGPM. Consequently, they gained their foothold first in the metric system, and the notion was more firmly established when the International System of Units when that was introduced 12 years later. But the best usage today has broadened those concepts far beyond those particular units.
The kilogram-force was an unquestionably legitimate unit until the introduction of the SI in 1960, and it still sees far too much use even today. In 1901, the CGPM made grams-force well-defined units of force, by adopting a "standard acceleration" of gravity of 980.665 cm/s² (note that pounds-force were never well defined units before then either, even though pounds were, and in fact by then were already defined as an exact fraction of a kilogram in the United States). This "standard acceleration" is a concept of metrology, not of physics; it serves no purpose other than defining units such as kilograms-force and the manumetric units of pressure based on the height of a column of mercury or water or whatever (mmHg, cmH2O, inHg, etc.). Since the SI is the only system of units still fully supported and updated, nobody is going to bother to tell us not to use pounds-force without telling us not to use pounds of any sort.
Mjroots should not be adding a manual conversion to those improper symbols. If I find any of them, I'll fix them. Gene Nygaard (talk) 15:04, 13 April 2008 (UTC)[reply]
I don't see any mention on the page of pounds-force or kilograms-force nor do I see mention of the slash's being restricted to division. I'm not saying that this is not the way things should be. I'm just pointing out that whilst this page is silent about this it's hard to say that this is the way things are. The other point raised but not conclusively dealt with is whether "lb/in²" is permissible. The page says to abbreviate square inch as "sq in", would this rule out "lb/in²" in favour of "lb/sq in"? JЇѦρ 17:48, 13 April 2008 (UTC)[reply]
Pounds force and kilograms force don't need to be mentioned on this page; we have a de facto standard without having to confuse anyone here. We simply do not use "lb" for pounds-force nor "kg" for kilograms-force. It isn't a problem; it has never required a solution. There's no need to fix it if it ain't broke. Gene Nygaard (talk) 21:25, 13 April 2008 (UTC)[reply]
Part of the reason, of course, is that it has been discussed ad nauseum in some other places, such as Wikipedia:WikiProject Aircraft (now on some old sub-pages about units, I think) and I think an automotive wikiproject as well. That takes care of most of the places where kilograms-force are used, and many of the places where pounds-force are used. There never was any need for any Manual of Style involvement. Gene Nygaard (talk) 21:29, 13 April 2008 (UTC)[reply]
See, for example, the "lbf" in the standard format at Wikipedia:WikiProject Aircraft/page content. Gene Nygaard (talk) 21:39, 13 April 2008 (UTC)[reply]

I believe the real situation is this: most of the people at NIST are scientists, who understand the superiority of SI and want American customary units to disappear as soon as possible. They have already abandoned customary units, and will never devote any resources to creating authoritative standards of usage for customary units. So Wikipedia should follow the usage in good style guides, such as the Chicago Manual of Style. Essentially, if you ask anyone in authority what's wrong with expressing torque in ft/lb, they'll tell you the problem is you're not using N·m. --Gerry Ashton (talk) 18:00, 13 April 2008 (UTC)[reply]

If it ain't broke, then what are we doing with {{Auto lb·ft}} & {{Auto lb ft}} (currently transcluded on only about a dozen pages & soon to be deleted but they're there)? What do we tell someone who wants to use "lb" for pounds force or "S/T" for short ton? What do we tell someone who might argue that what was discussed on the plane and automobile project pages doesn't apply to train articles? It would be nice to be able to point to something concrete. JЇѦρ 00:35, 14 April 2008 (UTC)[reply]
The train pages/wikiproject have also discussed, and use, lbf. Thanks for reminding me of that. But yes, it would be helpful to have somebody besides me to tell you not to use the siemens per tesla symbol to stand for short tons in the pet project of you and a couple of other editors, namely the {{convert}} program. At least I certainly don't see any division involved in short tons, and I can't imagine why anybody ever though that S/T, or M/T, or L/T also with the solidus, would be acceptable symbols for tons as units of mass.
Especially not when it apparently allows you to convert nautical miles to siemens per tesla
Of course, converting nautical miles to short tons doesn't make much sense either.
Obviously we are able to get rid of the improper usage without anything specific about it on this MoS subpage; as you say, it is already being done. In that particular instance, we do have decisions that it should be lbf on some Wikiproject for automobiles, and we do have the example of the more-often used {{Auto ft.lbf}} with proper symbols, which itself I suspect that someone has replaced with "convert" in many of the places where it was used.
Part of the problem with the {{Auto lb ft}} templates results from a failure by the creators of {{Auto ft.lbf}} to accommodate those who believe in following the rules promoted by some experts that unit of torque should be distinguished from units of energy, just as in SI the units of torque are newton-meters, while the units of energy are joules (they are dimensionally and numerically equivalent units, either is equal to 1 kg·m²/s²). There is no {{Auto lbf.ft}} (not even as a redirect to the one in the other order), so it is possible that the primary concern of the creators of those two templates you mentioned was with the order of the units, rather than a refusal to accept lbf for the pound-force symbol. Gene Nygaard (talk) 03:04, 14 April 2008 (UTC)[reply]
It's being done (the getting rid of those two auto templates) because this discussion prompted me to look around for instances of this, I found those templates and decided to eliminate them. Whether there is a general trend is another matter. I never did like "S/T", "L/T" and "M/T" for the very same reason. They were a hang-over from {{ConvertWeight}}. Looking on the Internet seemed to indicate that the abbreviations were used. The are even mentioned on the articles Short ton and Long ton. Had there been a clear ruling against this I'd gladly have excluded them from our little pet project. But, no, I guess we don't absolutely need the rule stated here, we can stamp out improper usage without it, I just think having such would make the job a little easier. JЇѦρ 04:33, 14 April 2008 (UTC)[reply]
Don't get me wrong, I'm not totally opposed to having such rules here. And I'm not even saying that it wouldn't be good to specify the rules for lbf and kgf here now; just pointing out that they really haven't been necessary in the past. They should be here, when someone insists on going contrary to what has become the Wikipedia standard, when a couple of Wikiprojects or whatever have come up with contradictory rules, or if someone wants to change something that has become common in at least part of Wikipedia. We just shouldn't expect to set down rules for everything here. And when such rules are proposed here, we should be making a concerted effort to see if the particular unit symbols or other abbreviations have been discussed elsewhere on the talk pages or in Wikipedia: namespace, and to put some notice on the pages where this was done that the issue has come up on MOSNUM. In some cases, we might accept two or more alternatives, while still rejecting other possibilities for the same unit (for example, either lbf·ft or ft·lbf for English units of torque, either mL or ml for milliliters.
If we are going to accept anything besides "psi" for pounds-force per square inch, it should include an "lbf", not "lb". And it should specify that it is lbf, not the lbf with an upright lowercase f used in some Wikipedia articles (since F is a common symbol for the quantity force in the sciences, some people outside Wikiepdia also use lbF where the subscript is italic and uppercase). But both of them go against the modern rule against attaching information to the units of measure (something done in the old psig and psia abbreviations for absolute and gauge pressures which we should also discourage on Wikipedia). Using "kgf" or "lbf" (which are the symbols used by measurement standards organizations such as NIST and NPL) can be interpreted in a way not violating that rule; that is just a different symbol for a different unit; by not subscripting it (and not separating it with a space or a dot as should be done if two different symbols are involved), it looks less like we are saying that these are really kilograms being used in a different context rather than using a different unit, one no longer acceptable for use with the International System of Units. Gene Nygaard (talk) 12:42, 14 April 2008 (UTC)[reply]
True, we can't cover everything. The more rules you have, the more diluted each one gets. is this a flash in the pan or are we likely to have more people wanting "lb" or "kg" for the force? JЇѦρ 17:37, 14 April 2008 (UTC)[reply]
On reflection it occurs to me that lb/sq-in would be more appropriate that lbf/sq-in for steam systems using a centrifugal governor. Local variations in g will change the regulation point...LeadSongDog (talk) 22:03, 14 April 2008 (UTC)[reply]
Perhaps LeadSongDog is joking? If not, one is still talking about the pressure exerted by steam, which is a force per unit area. Mass per unit area would be more appropriate for measuring armor plate. --Gerry Ashton (talk) 22:23, 14 April 2008 (UTC)[reply]

Cubic feet

According to Cubic foot the following abbreviations are used.

  • CCF for a hundred cubic feet
  • MCF for a thousand cubic feet
  • MMCF for a million cubic feet
  • BCF for a thousand million (109) cubic feet
  • TCF for a billion (1012) cubic feet

No mention of abbreviations for such large units of volume is made on the the page. It could be useful to have some abbreviation for these units for use on WP but would we want abbreviations such as these? On the other hand, it might be best to stick with "cu ft" and use scientific notation. JЇѦρ 02:50, 2 April 2008 (UTC)[reply]

The "Cubic foot" article does not cite any reference for these abbreviations. I think they are too obscure to use in Wikipedia. While they might be used in certain industries, the deceptive similarity to metric prefixes make them undesireable. --Gerry Ashton (talk) 03:04, 2 April 2008 (UTC)[reply]
More or less my feelings about them. I wonder whether the MOS should expressedly ban these and/or ban the quasi-Roman numeral/"short scale" prefixes that form them. I don't want to see the likes on WP but on the other hand I don't recall ever having done. JЇѦρ 03:16, 2 April 2008 (UTC)[reply]
"... don't recall ever having done ..." but I didn't have to look too far. JЇѦρ 03:26, 2 April 2008 (UTC)[reply]
Actually put it down to a bad memory. I went looking for "mcf" and found one that I'd been meaning to kill. I found a couple more. JЇѦρ 04:27, 2 April 2008 (UTC)[reply]
I've found nine hits for "MMCF" three of which were mentions of the abbreviation itself. The other six are listed below.
It's time to fix this. JЇѦρ 05:10, 2 April 2008 (UTC)[reply]
Given that most usages of cubic foot will be either US based or historical, it seems sensible to use the short scale billion and trillion vice the long scale thousand million and billion in explaining the prefixes B and T (if the initialisms are retained.) Certainly I would like to see clear disambiguation to the real-world metric units that define them (per the US NIST).LeadSongDog (talk) 05:33, 2 April 2008 (UTC)[reply]
I reserve the right to stick stubbornly to logic, tradition and dialect thus shunning this short scale nonsense ... on talk pages. Yeah, you're right, it is sensible. The question is whether these prefixes should be allowed on WP at all (apart from in articles which describe the abbreviations themselves). JЇѦρ 06:32, 2 April 2008 (UTC)[reply]
I wouldn't object to their use, especially if they were the source units. However, they'd definitely have to be wiki-linked back to the cubic foot article (which needs references for these abbreviations) and we'd have to make some note of them in the MOSNUM. I've only seen CCF used (on water and gas bills) in the past. If they were not the source units it would probably be better to use "cu ft" in scientific notation. —MJCdetroit (yak) 14:04, 2 April 2008 (UTC)[reply]
I support the general tone of this discussion. I am sure that most, if not all, instances of those obscure and esoteric abbreviations can be replaced with something that is more widely accessible. Lightmouse (talk)
Good point, MJCdetroit, but might you not argue that converting "1.23 TCF" to "1.23 trillion cubic feet" or "1.23×1012 cu ft" involves not a change in units but simply in how those units are expressed? JЇѦρ 16:38, 11 April 2008 (UTC)[reply]
But how those units are expressed is a legitimate concern. We can and should allow "trillion cubic feet" while disallowing "TCF" as an abbreviation for them. The Roman-numeral–based (but multiplicative rather than additive, 1000×1000 rather than the conventional 1000 + 1000 in Roman numerals) MMCF or MMCFT or MMcft or even mmcft should especially be deprecated. We can and should encourage use of cubic kilometers/kilometres and "km³" rather than "billion cubic meters/metres" and especially "billion m³". Gene Nygaard (talk) 15:46, 14 April 2008 (UTC)[reply]
I'd also say that "hundred cubic feet" should not be used on Wikipedia, not even spelled out let alone in symbols, unless as part of a newspaper headline in the references. Just multiply by 100 and use cubic feet. Sure, in similar fashion, I can show you Canadian hog markets giving prices as $x/ckg, but I doubt that anyone is going to argue here the we should allow "ckg" as an abbreviation for "100 kilograms". We shouldn't accept those $x/ckg even if we accept the very same market's cattle prices, at the very same time, in $x/cwt. We can accept "cwt" an exception for an ubiquitous abbreviation, though one needing disambiguation because between those who think hundred is written in symbols and "100" and those who thin it is "112", but otherwise that Roman numeral "C" or "c" as a prefix for 100 is especially bad and confusing, because the standard meaning as a unit prefix is not 100 but rather 1/100 for "centi-". Gene Nygaard (talk) 16:06, 14 April 2008 (UTC)[reply]
Centikilograms ... How those units are expressed is exactly the concern I'd like addressed. I've seen the likes of "MMBTU" and "TCF" on Wikipedia pages. I hope to see them eliminated. I've also seen the argument that cubic kilometres are for geology whilst the natural gas industry uses billion cubic metres instead. To me that goes against my feeling of the spirit of the SI, which would call a cubic kilometre a cubic kilometre whether it be of rock or of luminiferous æther. JЇѦρ 17:26, 14 April 2008 (UTC)[reply]

Decades fix rationale

Sometime in the intervening long while since I looked at it, someone added an "okay" to abbreviate decades as long as the century was obvious. This is clearly untenable, because we (people who write and speak, I mean) simply don't do this outside of our own immediate past and future (with exceptions, like "Gay '90s" or "'49ers", that have become stock phrases and even re-used for other purposes like sports teams). When's the last time you saw something like "In 1075 BC King Grognar was ousted from his throne by his brother, but by the '60s had regained his kingdom with the help of the neighboring Fnord Empire"? I can't imagine ever seeing that in a scholarly or even vaguely serious work. Furthermore, the text as of a few hours ago ignored the fact that we use abbreviated decades most often, most pointedly, to refer to social periods that roughly coincide with decades, and with such consistency that they can become (sourceable) buzzwords or even signifiers for everything about society at a vaguely-defined range of time, and that this really isn't related in any way to identifiability of the century (see previous 2 examples). When I say "I grew up in the '80s" that conveys an enormous amount of information about me and my probable world-view. If I say "that model of our product was discontinued in the '80s", referring to a literal decade, this (lazy and unencyclopedic) usage conveys no such additional latent information. The usages are radically different, and the current (as of this writing) re-draft solves these problem. The redraft clearly also reflects consensus current practice, as it is a very regular AWB/bot or gnome edit to convert things like "the next phase of her career began in the early '40s" to "...1940s" (as far as I know I have never been reverted, ever, on such a correction), but articles about counterculture, civil rights, etc., can and do use "the '60s" when appropriate because it has nothing to do with the literal span of 1960 to 1969, but the societal changes that began happening in the mid-1960s and carried through to the early 1970s. No one would go to the article on the 1890s and change the phrase "popularly called the 'Gay '90s'" to read "'...Gay 1890s'". Anyway, I don't think anyone would revert me on this, but I like to provide rationales for major changes, especially here. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:55, 5 April 2008 (UTC)[reply]

We might want to add a clarification along the lines of "Decades should not be abbreviated in this manner even if they can be unless there is some connection between the usually-abbreviated social period and what is being discussed in the sentence (She grew up in the 1960s, and moved to Boston in 1971. Growing up in the '60s, her attitude about civil rights differed significantly from that of her parents.)" Maybe someone can come up with shorter examples that get the point across as clearly. The lead sentence could probably be tightened too. Season 3 of Battlestar Galactica is about to start so I'm losing focus... Anyway, I think the clarification is important; I really have seen articles consistently abbreviating "'60s" but not other decades, because someone is not quite realizing that every reference to the "special" time period is not a reference to what was defining about the period and its societal goings-on. There's a world of difference between a '60s rock band in San Francisco and a 1960s classical quintet (even in S.F.!), or a '60s civil rights activist in Chicago and a 1960s accountant in the same city (or a 1960s activist for better funding of Chicago elementary schools). The distinction is important. I'll see if I can think of a way to stick the idea in there in just a few words, but may need help. — SMcCandlish [talk] [cont] ‹(-¿-)› 03:18, 5 April 2008 (UTC)[reply]
After a dozen or so attempts, I think I finally got it. I managed to compress (I think) every single idea above into a passage that's only slightly longer than when I raised the "meaningful connection" issue above, and also took the time to tighten up, clarify, flow-improve and bulletize. I think it is quite clear and readable now, and hints at all of the guidance that it needs to. Yes/no? — SMcCandlish [talk] [cont] ‹(-¿-)› 03:54, 5 April 2008 (UTC)[reply]

Graphics

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. SandyGeorgia (Talk) 02:35, 8 April 2008 (UTC)[reply]

Misconstruing of the manual of style

There is a discussion at Wikipedia:Bot_requests#Misconceived_links_to_date_fragments_such_as_Wednesday_and_April. Please look at the comments by User:Huaiwei. It indicates that there is confusion about what wp:mosnum means in respect of linking dates. Either it is compulsory or it is not, yet two experienced editors have read the text and one concluded that it is compulsory and the other concluded that it is not. Please help clarify this point. Lightmouse (talk) 09:13, 10 April 2008 (UTC)[reply]

Proposal to create a new talk page

There is a lot of discussion about a single topic. Discussion is a good thing.

I have various mechanisms of keeping up to date with the wider range of topics discussed this page:

  • The page appears at the top of my watchlist.
  • I sometimes scan the page history to check activity
  • I review the edit summaries to see if there is something I am interested in

Unfortunately, those means are becoming less useful. The page is almost always at the top of my watchlist, the page history is so full that it gets hard to pick out things of interest, and the edit summaries frequently look like other other topics. Consequently, I have to work harder or I reduce the amount of attention I pay to page activity.

I am sure other editors use similar mechanisms. Consequently, I am convinced that the quality of discussion on other topics has got worse.

I propose that we create a separate page for the single topic. I think that would benefit all topics, including the single topic. Lightmouse (talk) 10:04, 10 April 2008 (UTC)[reply]

In the absence of any feedback, I have moved discussions on the single topic to Wikipedia talk:Manual of Style (binary prefixes). I think that provide the benefits described. If anyone objects, feel free to revert. Lightmouse (talk) 08:41, 11 April 2008 (UTC)[reply]

Although I've just added a comment to the new page, doesn't moving this section slightly confuse the archives for binary prefixes that are on this page? Fnagaton 08:54, 11 April 2008 (UTC)[reply]

I don't know. It had not crossed my mind until you mentioned it. If there is a better way of making the move, that is fine by me. Lightmouse (talk) 09:17, 11 April 2008 (UTC)[reply]
I must confess to not being able to think of a better alternative at this time in the morning before my cup of tea. Fnagaton 10:13, 11 April 2008 (UTC)[reply]

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]

Orders of magnitude

Begin: Discussion moved from User talk:Lightmouse

Why have you been removing all references to the order of magnitude articles? They survived AFD. Has their been any discussion about this? -- ☑ SamuelWantman 20:05, 5 April 2008 (UTC)[reply]

I am not removing all references to order of magnitude articles. Is there something that makes you think that? Lightmouse (talk) 20:43, 5 April 2008 (UTC)[reply]

This edit made me think so, but since it seems it was not your intent, it was probably an unexpected result of your using AWB to clean up so many articles. -- ☑ SamuelWantman 22:45, 5 April 2008 (UTC)[reply]

Yes. Keep up the good work. Lightmouse (talk) 08:16, 6 April 2008 (UTC)[reply]

I wonder if there are other links that you inadvertently removed. Have you checked? -- ☑ SamuelWantman 11:00, 7 April 2008 (UTC)[reply]

Can you clarify exactly what it is that you would like me to check and I will try. Lightmouse (talk) 20:40, 8 April 2008 (UTC)[reply]

This edit (the same one mentioned above) removed a link to an article. -- ☑ SamuelWantman 08:08, 9 April 2008 (UTC)[reply]

I did not inadvertently remove the link from '1,991' to '1 E3 m'. I removed it deliberately because I think the article is better without it. Perhaps this issue is generic to many articles and it would be good to read what others think. Have you considered raising it wp:mosnum? I would be interested to see what other people say. Lightmouse (talk) 21:43, 9 April 2008 (UTC)[reply]

Which article do you think is better? The linked bridge is mentioned in the 1 E3 m article, and might be of help to a reader of the list to get a sense of the scale of the spans. The link was added quite some time ago (not by me), but seemed to be a useful addition. The order of magnitude articles have been around for quite some time. They are very hard to find if you don't stumble across them by clicking on the links like the one you removed. If you don't like those articles, you should discuss them on their own talk pages. The links seem pretty harmless, at most they will distract your attention for a couple of seconds if you are not interested. What is the problem with keeping them? I think the person or people who think they should be removed would consider starting a discussion about removal. I don't see how it is my responsibility to start a discussion about leaving things the way they have been for quite some time... -- ☑ SamuelWantman 11:05, 11 April 2008 (UTC)[reply]

End: Discussion moved from User talk:Lightmouse

Please can people comment on this general issue. Lightmouse (talk) 11:10, 11 April 2008 (UTC)[reply]

I agree with Lightmouse's edit. In fact I do the same. I don't believe that links to these articles from specific measurements make much sense. I have nothing against the articles themselves, though, I would have them renamed and reorganised. If there need be a link to 1 E3 m, let it be from around one kilometer as appears in the article's introduction. JЇѦρ 16:29, 11 April 2008 (UTC)[reply]
Strong agree Linking from 1991 to 1E3 (or even 1000) is bound to confuse readers.LeadSongDog (talk) 19:02, 11 April 2008 (UTC)[reply]
I don't mind the move of the link to around one kilometer but I object to removing them entirely. The order of magnitude articles are useful and enlightening, especially to younger readers. It makes sense to have them linked from many articles, especially those that are mentioned in the order of magnitude articles. I don't see how this confuses readers, I think it educates them. -- ☑ SamuelWantman 05:26, 14 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]

I received the following comment on my talk page:

  • Hi there. While most of your date fixes using AWB are fine, be careful about removing ones such as "...is a [[2007 in film|2007]] film..." - there is some disagreement as to this use of the pipe trick, but current consensus seems to be to leave them alone, where editors want them. All the best, Steve T • C 12:50, 11 April 2008 (UTC)[reply]

Is this consensus documented anywhere? Lightmouse (talk) 12:04, 13 April 2008 (UTC)[reply]

Is bit/s/Hz an ambiguous unit?

A discussion has arisen at Eb/N0 about the possible ambiguity in the unit bit/s/Hz. Any comments? Please respond at the article talk page. Thunderbird2 (talk) 06:21, 14 April 2008 (UTC)[reply]

Units of measure

This section if for discussing MOSNUM:Units of measure Greg L (talk) 02:46, 16 April 2008 (UTC)[reply]
source: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29&oldid=205938125

Leave a Reply