Jump to content

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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 95Archive 96Archive 97Archive 98Archive 99Archive 100→Archive 105

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)
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)

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)

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)

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)
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)

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)

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

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

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

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)

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)

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)

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)

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)

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)
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)
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 · ... 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)
This (and subsequent related discussion) is what I was looking for. Thunderbird2 (talk) 15:54, 15 April 2008 (UTC)
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)
It would not be at all silly for us to require kW·h. That is in use outside Wikipedia. But we, like anyone else, have a right to choose our own house style. It is part of the "look and feel" of Wikipedia. There is no reason whatsoever for us to be even tackling the elusive task of determining "most common used" because it isn't relevant. If we follow consistent, systematic rules, that is quite enough. Google results are often useless or deceptive in such cases anyway. Consider the fact that while a search for "kWh" gets 12,200,000 hits, a search for "kWh" but not "kW·h" gets only 610,000 hits. And, like you said, many of those hits on the simplest search are for "kwh" rather than "kWh"; you forgot to mention the "KWH" hits, and you didn't even try to search for "KWHR" which gets hundreds fo thousands of hits. Of course, searching for kW·h will also find people who write it kw/h even though this unit involves a multiplication, and not a division, but "kW·h" and not "kWh" gets 6,620,000 hits, more than 10 times as much as the other way around. Gene Nygaard (talk) 13:05, 16 April 2008 (UTC)
After I said that, I looked around at abbreviations, and saw that we have 3 different sets of guidelines on abbreviations, with little apparent hope of reaching consensus on many issues. I'm thinking that abbreviations is a subject I'm not ready to tackle. - Dan (talk) 13:17, 16 April 2008 (UTC)
That's part of the reason why consistent, systematic rules are especially important for a collaborative project such as Wikipedia. Don't be saying that people writing about rugby players can add an s to their ins and kgs and lbs, but nobody else can (we don't do so here—our rule applies across the board—but because of a couple of persistent editors, we certainly do need more help in cleaning them up—just Google lbs rugby site:wiki.riteme.site[1] to see how bad it is). Gene Nygaard (talk) 13:24, 16 April 2008 (UTC)

Circa and century

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

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

Queries

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

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


My reading is that before the change:

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

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

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

Tony (talk) 15:53, 18 April 2008 (UTC)

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

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

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

Frequent changes to MOSNUM

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

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

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

Survey foot versus international foot

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

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

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

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

Capitalisation and pluralisation of the Erlang unit

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

I found this definition at Rowlett's site:

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

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

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

Using a policy page as a scratchpad to develop a proposal

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

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

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

I tried this out in the sandbox and the first attempt failed:
  • {{delimitnum|1234567.7654321| |12}}
  • with template functioning: 1,234,567.7654321 × 1012
  • 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)
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:
  • {{delimitnum|1579800.2987281}}: 1,579,800.2987281
  • {{delimitnum|1579800.29872801}}: 1,579,800.29872801
  • {{delimitnum|0.2987281}}: 0.2987281
  • {{delimitnum|0.29872801}}: 0.29872801
Woodstone's example has 14 digits. A different issue:
  • {{delimitnum|1.000001}}: 1.000
Gimmetrow 23:00, 14 March 2008 (UTC)
  • 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)
There is still a problem with a single digit in the integer portion: {{delimitnum|1.01}} = 1.1, {{delimitnum|1.001}}: 1. This can be fixed, though, as it's not a fundamental limitation (like 13-14 digits). Gimmetrow 23:38, 14 March 2008 (UTC)
  • 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)
  • 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))

{{delimitnum|12345.6789012}} → 12,345.6789012
{{delimitnum|12345.6789012||12|}} → 12,345.6789012 × 1012
{{delimitnum|12345.6789012||12|Hz}} → 12,345.6789012 × 1012 Hz
{{delimitnum|6.02214179|30|23|kg}} → 6.02214179(30) × 1023 kg
{{delimitnum|1579800.298728}} → 1,579,800.298728
{{delimitnum|1.356392733||50|Hz}} → 1.356392733 × 1050 Hz
{{delimitnum|0.45359237|||kg}} → 0.45359237 kg
{{delimitnum|6.022461}} → 6.022461
{{delimitnum|6.0224613}} → 6.0224613
{{delimitnum|6.02246134}} → 6.02246134
{{delimitnum|6.022461342345}} → 6.022461342345
{{delimitnum|1579800.298728|||}} → 1,579,800.298728
{{frac|{{delimitnum|1.602176487||–19|}}}} → 1⁄1.602176487 × 10–19

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

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

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

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

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)
{{delimitnum|1.0001}}: 1.0001
{{delimitnum|1.00001}}: 1.00001
{{delimitnum|1.00101}}: 1.00101
{{delimitnum|1.00102}}: 1.00102
{{delimitnum|1.000001}}: 1.000
{{delimitnum|1.000002}}: 1.000002
  • 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)
  • 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)
  • 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)

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)
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)
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)
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)
(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)

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

Section start

100,000.000001

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)

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

  • For convenience, I’ve here provided a triple-view of some of the above. They parse as follows:

    input → live template return / (at time of this posting)

    0.125402 → 0.125402 / (0.125 402) ✓ The following are all supposed to end with three-digit groups
    0.125403 → 0.125402 / (0.125 402)
    0.125404 → 0.125403 / (0.125 403)
    0.125405 → 0.125404 / (0.125 404)
    0.125406 → 0.125405 / (0.125 405)
    0.125407 → 0.125406 / (0.125 407) ✓
    0.125408 → 0.125407 / (0.125 407)
    0.125431 → 0.12543 / (0.125 43)
    0.125432 → 0.125431 / (0.125 431)
    0.125433 → 0.125432 / (0.125 433) ✓
    0.125434 → 0.125433 / (0.125 433)
    0.125435 → 0.125434 / (0.125 434)
    0.125436 → 0.125435 / (0.125 436) ✓
    0.1235436 → 0.1235436 / (0.123 543 599) This one is supposed to end with the four-digit group “5436”
    0.29872821 → 0.29872821 / (0.298 728 209) This one is supposed to end with the two-digit group “21”

    Most of this data was discovered at Delimitnum sandbox in the newly added section with 3960 possible variations, which displays all possible variations of numbers ending in two, three, and four-digit groupings.

    Greg L (my talk) 00:34, 16 March 2008 (UTC)

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)

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

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)

  • 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 1.567892 × 10+9 kg, just as can currently be done with the existing {{e}} template. You can put anything in these templates, including 2.468 × 10useless “+” sign 9 kg. 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)
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)

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)

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 1.12(25) (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)

  • 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)
In my opinion, numbers should never be truncated. Just use whatever digits the editor supplies. −Woodstone (talk) 09:18, 24 March 2008 (UTC)
  • 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)
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)

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)

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

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)

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)

Comma's

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

The claims were confirmed BTW. You can check NIST - Grouping Digits. Headbomb (talk · contribs) 05:39, 27 April 2008 (UTC)

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

I propose adding the following bullet text:

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

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

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

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

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

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

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

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

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

Vote to keep, delete or amend Wikipedia:As_of

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

The 1700s

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

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

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

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

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

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

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

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

Numbers as words or numerals when converting

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

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

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

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

Big money

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

I suppose the second one is not wrong, but why would you normally bother? The dollar sign is so recognisable and makes for easier reading. Tony (talk) 08:03, 27 April 2008 (UTC)
That was my feeling as well — someone changed the former to the latter, and I wanted to make sure that there wasn't some reason for spelling out "dollars" that I was missing. —Josiah Rowe (talk • contribs) 05:43, 28 April 2008 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_98&oldid=1146550179"