Manual of Style

This page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style articles This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing. For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

Archives

General 1, 2, 3, 4, 5, vote, 6, 7, 8, 9 (AD/CE), 10, 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161 Binary prefixes B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11, B12, B13, B14, B15, B16, B17 Years and dates D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14 See also Wikipedia:WikiProject Dates Wikipedia talk:Date debate Wikipedia talk:Naming conventions (calendar dates) Wikipedia talk:Timeline standards Wikipedia:Measurements Debate Wikipedia talk:Manual of Style (dates and numbers)/Date autoformatting Complete rewrite of Units of Measurements (June 2008) Dec. 2008 RfC on Date linking/autoformatting (three proposals) Dec. 2008 RfC on Date linking/autoformatting (detailed)

This page has archives. Sections older than 7 days may be automatically archived by Lowercase sigmabot III.

I've often come across several IPs (here, here, here, and several more) that change regular date format to something like this. These IPs (probably all the same person) continually make these edits and often go on unreverted. I usually make it my job to go and revert all the edits the IP makes. These IPs have been repeated been warned, explained to, blocked, and sometimes, just get away with it. It's become real tiresome to continually revert these edits and I don't know how to deal with it. Thought their edits are easily detected (they use the name of the article as the edit summary), they often go by for minutes to hours without the edits being reverted, and I can only do so much with limited time. I really can't think of a possible solution, considering the range of these IPs and I can't fix it all alone. So basically, what I'm asking, is there any possibles solutions do this, or will other editors and I have to just revert each edit? DiverseMentality 07:08, 3 February 2009 (UTC)[reply]

Maybe reverting is the wrong answer. Some of the edits that they have done have substituted a date for a year. If the date is correct, and can be verified, then substituting a date is good. It is a pity they use an ambiguous mm-dd-yyyy format, since some readers will think it is dd-mm-yyyy. The best thing to do is to convert to a normal dd mmmmmm yyyy format, and to add {fact} by it, to indicate that no source is quoted. Simply reverting is unhelpful when the user has added information.

Some of the edits have delinked dates - a bit like Lightbot - only they have used a mm-dd-yyyy format. The best thing to do is not to revert but to change to the normal dd mmmmmm yyyy format.

I am sure whoever is doing this means no harm. They should not be treated as a vandal. If you are an unregistered user of wikipedia (or a registered one using a computer where it would be inappropriate to log in) it is really annoying and unhelpful if someone treats you as a vandal just because you change content that is wrong.--Toddy1 (talk) 08:42, 3 February 2009 (UTC)[reply]

Both 3 February 2009 and February 3, 2009, are normal, Toddy. Septentrionalis PMAnderson 14:31, 3 February 2009 (UTC)[reply]

I guess that by "mm-dd-yyyy" he meant "MM/DD/YYYY" (e.g. 02/03/2009) and by "dd mmmmmm yyyy" he meant "DD Mmmm YYYY" (e.g. 3 February 2009). The first of these is ambiguous, so I would never use it (although "February 3, 2009" is fine). --A. di M. (talk) 18:30, 3 February 2009 (UTC)[reply]

To DiverseMentality:The best thing to do is revert Date Warriors, of all kinds, at least once. Leave things in the established style, especially when the alternative, like 09/06/2008, is at best unclear. If they keep on, have them blocked at AIV. Thanks for spending time on this. Septentrionalis PMAnderson 14:28, 3 February 2009 (UTC)[reply]

Toddy, I'm sure the user(s) mean no harm, but the fact that the IPs, such as the first one I linked (among others), have been directed to WP:DATE several times and have ignored these warnings, they continue to make such edits. Their edits start to become disruptive. DiverseMentality 20:27, 3 February 2009 (UTC)[reply]

• The numerical/slashed format is not recommended by the style guides; it can be interpreted in two different ways. I believe it should be reverted for the moment. Tony (talk) 13:15, 4 February 2009 (UTC)[reply]

The fundamental problem with a date like 09/06/1994 is that it is ambiguous in the global context, and should be prohibited for that reason. To an American reader, it would mean September 6, 1994; while to a British reader it would mean 9 June 1994. The original date format, September 6, 1994, or the alternative 6 September 1994 would be unambiguous to either. Although they might be annoyed at being confronted by an alien date format from the other side of the Atlantic, they would know what it meant. The only unambiguous numeric date format is the ISO one, 1994-09-06, which is why I prefer it for computer input. Computers are somewhat unforgiving of ambiguity.RockyMtnGuy (talk) 00:22, 5 February 2009 (UTC)[reply]

The numeric date 1600-01-01 is ambiguous, because it might be governed by ISO 8601, in which case it is either in the Gregorian calendar or erroneous. On the other hand, it might not be goverend by ISO 8601, in which case it might be either in the Gregorian or Julian calender. In short, people who have not read the relevant ISO standard should not write the letters "ISO". --Gerry Ashton (talk) 01:06, 5 February 2009 (UTC)[reply]

That applies to any date format. 01/01/1600 is ambiguous because it occurred in the middle of the Great Calendar Switchover, and would be on the Gregorian calendar in Italy, Spain, Portugal, Poland, France, and the Catholic parts of Germany and Switzerland, but on the Julian calendar in England, Sweden, Russia, Greece and the Protestant parts of Germany and Switzerland. Interestingly, 01/01/1600 is the date Scotland adopted the Gregorian calendar, so from 1600 until 1752, England and Scotland were on different calendars. This is something of a problem in dating events in that period of British history. As a result, people often used dual dates and wrote down the dates in both calendars (e.g. 10/21 February 1750/51) until England adopted the Gregorian calendar in 1752. One interesting solution to the ambiguity is to use different separators for ISO-style dates: 1600-01-01 is deemed to be on the Gregorian calender (since it is ISO format), but 1600/01/01 is identified to be on the Julian calendar (since it doesn't follow the true ISO format).RockyMtnGuy (talk) 07:06, 5 February 2009 (UTC)[reply]

And here's an interesting fact: William Shakespeare and Miguel de Cervantes died on the same date, 23 April 1616, but not on the same day. Shakespeare died in England on the Julian calendar, while Cervantes died in Spain on the Gregorian calendar. So Cervantes actually died 10 days before Shakespeare.RockyMtnGuy (talk) 07:32, 5 February 2009 (UTC)[reply]

Something April 23 should explain; more readers will see the explanation if the articles on Shakespeare and Cervantes link to it. ;->Septentrionalis PMAnderson 01:42, 7 February 2009 (UTC)[reply]

Regarding this page: 17 Kids and Counting, the tags to show birth date and age in the chart for the children keeps getting removed by anonymous IP editors. The few explanations given for the removals are that we don't know the ages of the children (which makes zero sense considering we know their exact birth dates) and that figuring out the age is basic math (despite the fact that this tag was created for the sole purpose of identifying the age, simple math or not).

I was iffy on whether to include the tagged dates when I merged the articles, but decided to since all the birth dates are known and I don't see any reason why the ages should not be included, if the birthday is included (especially given the subject matter). The second time the tags were removed, it was identified as vandalism by another long-time, established user, which prompted me to continue reverting the changes...but now I'm not so sure since it keeps getting changed by IPs (yet explanations are no longer being offered in the edit summaries and no one changing it is bothering to discuss this on the talk page). Are the tags appropriate in this case? Should they be removed? I don't care either way, but it's getting a bit ridiculous. Can someone give me some help here? Thanks. --13² 18:29, 3 February 2009 (UTC)[reply]

Also, please let me know if I should move this somewhere else. I'd be happy to move it if this isn't the best place for this (but please let me know where). Thanks! --13² 18:42, 3 February 2009 (UTC)[reply]

Generally, there shouldn't be a problem with this usage of the birth date/age auto-calculator templates. That seems appropriate usage for cases such as this. However, the consensus and discussion on this would ideally be confirmed at the article's talk page. Dl2000 (talk) 02:53, 8 February 2009 (UTC)[reply]

It would solve the problems of {{val}} with numbers with many digits, although users would have to specify breaks by hand. For example {{User:A. di M./margins|−2.002|319|304|3622(15)}} would yield −2.0023193043622(15).

It could also have other uses, too. See more examples on User:A. di M.#Testing /margins. The template itself is at User:A. di M./margins. I've put it in my userspace rather than in the template space because I'm not sure about how to name it.

(I haven't included support for automatic handling of exponential notation, uncertainty, etc. yet, but I might add it later. As for the margin size, I've used 0.25em for consistency with what {{val}} does, but personally I would use smaller margins, e.g. 0.2em.) --A. di M. (talk) 11:02, 5 February 2009 (UTC)[reply]

• This is great. The advantage is that it can handle big values, which Val can not, and it can handle values that Val generates rounding errors on. I’ve been working on [Wikitech-l] with developers trying to find a solution to the Val problem (so far, to no avail). The only trouble with this new template is it needs to have big bold instructions to users on how to properly delimit values per ISO / NIST / BIPM convention, which never leaves a single dangling digit; you either have two, three, or four digits in the final group as a consequence.

  As for the em-width, it is a tradeoff; different editors see different widths on their hardware/software platforms.

  Are you going to be doing the scientific notation aspect too? Greg L (talk) 23:22, 6 February 2009 (UTC)[reply]

There's no template template:thinspace yet that simply replaces each "|" with a thinspace; that would be nice, for when people want to use thin spaces. - Dan Dank55 (push to talk) 15:26, 7 February 2009 (UTC)[reply]

Done. For example, now {{thinspace|J.|R.|R.}} Tolkien displays J. R. R. Tolkien. --A. di M. (talk) 21:23, 7 February 2009 (UTC)[reply]

A bug-free version of {{val}} could be implemented using the string-manipulation functions in mw:Extension:StringFunctions. That extension is not installed (see Special:Version), and I don't know where to ask to get it installed. —AlanBarrett (talk) 14:11, 9 February 2009 (UTC)[reply]

Val is now fixed

• (*Whew*) I just got through with a full month of interacting (cajoling, pleading on my worn knees) with the developers who provide the parser functions that template authors rely upon. mw:Extension:StringFunctions is buggy and hasn’t been released. Besides, it would still be lacking a couple of features necessary to make a {{val}}-like tool. Really, the string functions required for {val} would be extraordinarily easy for a skilled developer to code—perhaps a half-evening of work. The problem lies with intangibles like “setting precedent” by making a software tool every time we whiney-ass editors and template authors have a wild notion of what we *think* might be valuable to Wikipedia; the developers have their own ideas on important matters like these.

  Now that I’ve done my prima dona-bashing on developers, one of them, Robert Rohde, fixed some behind-the-scenes math business that {val} relies upon so it no longer suffers from its seemingly random rounding errors. In other words: {val} now works!

  By “fixed”, I mean that {val} now is perfectly predictable. And, though predictable, {val} is not perfect. According to Robert, {val} is good only up to 10 significant digits. I haven’t done elaborate experiments, but I see that it can do twelve-digit tasks like this:

1.23456789012 (ends with 12)

1.23456789011 (ends with 11)

1.23456789013 (ends with 13)

1.23456789014 (ends with 14)

1.23456789015 (ends with 15)

1.23456789016 (ends with 16)

1.23456789017 (ends with 17)

1.23456789018 (ends with 18)

1.23456789019 (ends with 19)

Note that {val}’s math-based delimiting technique means it still can’t handle tasks like {{val|1.2300|(20)|e=-23|u=kg}} because the trailing zeros disappear and you just get 1.2300(20)×10⁻²³ kg. At least this is consistent behavior. When one encounters a value that ends with a zero, they can use Margins, by A. di M.

Although {margins} won’t ever choke on values that end with zeros or which have loads of digits, it needs to be used with care by editors to ensure the values are delimited per ISO/NIST/BIPM convention, which never leaves a single, dangling digit. Thus, the last group of digits must always have two, three, or four digits. And, last I checked, authors using {margins} to make scientific notation with negative exponents must remember to not type a keyboard hyphen and to use the true minus sign (−) from the Insert pallet so it looks good when superscripted.

Admin fix needed

BTW, this means someone can temporarily unlock MOSNUM and correct the last sentence of the the “Decimal points” passage on {val} to read something like this:

Note that {{val}} will not work with values that end with a zero (which can happen when uncertainty is expressed), and may not properly work beyond about 10 to 12 significant digits.

Also, at the “Uncertainty” section, it can be revised to something like this:

{{val}} is meant to be used to automatically handle all of this. Note that {{val}} can not handle digits with more than about 10 to 12 significant digits and can not properly display signficands that end with a zero. Thus, if you have a value that should display like 1.452800(25) × 10⁻²³, {{val}} will generate 1.452800(25)×10⁻²³.

Note that I tested {val} to 13 digits, and it works most of the time, but—randomly—it will generate error codes about 20% of the time.

Greg L (talk) 22:23, 9 February 2009 (UTC)[reply]

Revised Decimal subsection's line goes over margin

I don't know what is the optimal solution, but, depending on your screen, resolution, text size and sidebars, you may see the line that includes the dozen significant digits and breaks go over the right end of your screen. (I use the "mini-browser" sidebar in Netscape Navigator 9.0.0.6 for my Watchlist.) It's possible that the "nowrap" required by the example means that this problem isn't fixable, but perhaps some administrator (since the page is fully protected) could insert an appropriate break, unwrap or blockquote to keep the text within the margins. Thanks.—— Shakescene (talk) 01:06, 11 February 2009 (UTC)[reply]

Epiphany behaves like that too. But this works correctly. Maybe that's a problem with using the thin space character within "nowrap" spans; if this is the case, they might be deprecated in favour of the new template {{gaps}}. --A. di M. (talk) 20:35, 11 February 2009 (UTC)[reply]

Over at Krupp Diamond the text was changed from:

• The Krupp Diamond is a 33.19 carats (6.64 g) stone

to

• The Krupp Diamond is a 33.19 carats stone

on the grounds that the metric units make things less legible. I re-added them but I don't want to get into a revert war with what appears to be a genuine concern by an editor that may be more familiar with 'carats' than I am. Can people take a look and see if metric units cause any legibility problems in that article? Lightmouse (talk) 11:48, 8 February 2009 (UTC)[reply]

This is nonsense. Adding metric makes things more legible ... at least for those of us who are unfamiliar with the carat. JIMp _talk·cont 12:56, 8 February 2009 (UTC)[reply]

Ditto. Other than jewelers, I think more people know how heavy a gram is than know how big a carat is, or even know that a carat is a unit of mass. However, the link to Carat (mass) should probably have been preserved for the benefit of those who want to know how much a carat does weigh (200 mg).RockyMtnGuy (talk) 15:49, 8 February 2009 (UTC)[reply]

An additonal factor is that there have been various definitons of carat, and the diamond in question is old enough that many people wouldn't know if it was cut before or after the metric carat was defined; providing the mass in grams removes the ambiguity. --Gerry Ashton (talk) 17:04, 8 February 2009 (UTC)[reply]

You make an excellent point. Sometimes people have criticised metric units on the basis that the template converts an error, or reveals/highlights the presence of an ambiguity. For example we see things like: The Royal Mile "The street is, as the name suggests, a mile long". The error/ambiguity is concealed to all but those with specialist knowledge. A significant number of readers will think it refers to the statute mile. If a conversion to '1.6 km' is added, some of those with specialist knowledge point out that the Mile is actually a Scottish mile (1.8 km) that predates the mile that was imposed by Statute. Converting errors/ambiguities is not the fault of conversion, it is a benefit that often leads to better article text. Lightmouse (talk) 18:50, 8 February 2009 (UTC)[reply]

Do Americans find it difficult to use the carat value plus the gram value and then get an 'aha moment' when they see the grain value? Lightmouse (talk) 19:23, 8 February 2009 (UTC)[reply]

I only found out the real value of a grain about twelve years ago, when comparing aspirin dosages. A standard aspirin of 325 mg is five grains; a "baby aspirin" of 81 mg is consequently 1 1/4 grains. (1 grain = just under 64.8 mg.) Notice those are metric milligram(me)s, not customary (U.S. or Imperial) equivalents.

• [Grains are difficult because for the relatively tiny number who delve this far, you don't know whether you're dealing with Troy (jewellers') or Avoidupois weights. In the former, 24 grains = 1 pennyweight, 20 pennyweights (480 grains) = 1 ounce troy, and 12 oz troy (=240 pennyweights = 5,760 grains) = 1 pound troy. One pound avoirdupois (16 oz avdp. ≈ 453.6 g) = 7,000 grains. I didn't know this off the top of my head, but had to look it up.]

My World Almanac & Book of Facts is curiously coy about giving a direct conversion of carats into ounces, which is about the smallest weight that most unschooled people like me understand, but since a carat (= exactly 200 mg or 0.2 g) weighs about 3.086 grains, the Krupp diamond at 33.19 carats or 102.4 grains would weigh about a quarter of a ounce avoirdupois (exactly 437.5 grains). A quarter of an ounce doesn't sound like much to me, but it gives me an idea; if you were writing in an informal, popular vein, you could also tell Americans that its mass is just over that of twenty regular-sized aspirin (or acetaminophen) tablets (100 grains, 6,500 mg or 6.5 g).

I understand why the default conversion would be from carats to grains, but in this case a conversion to fractions of an ounce would probably be more useful. Those who understand grains probably also understand carats. —— Shakescene (talk) 21:05, 8 February 2009 (UTC)[reply]

For the benefit of American readers, you could point out it is slightly heavier than the current U.S. 25 cent piece (5.67 grams). It's actually very close to the weight of a pre-1965 silver quarter.RockyMtnGuy (talk) 23:08, 8 February 2009 (UTC)[reply]

My concern in the revert was that (1) I felt that the link to Carat (mass) should be preserved and (2) that carat is a metric unit anyway (not a base unit, but metric nonetheless). There is certainly an open question over whether the Krupp diamond's reported mass dates to before the 1907 standardization, but as it was last heavily reported on in the 1960s, I imagine that the mass is in post-1907 carats. I do not have a problem with using converted units in general, but I saw no benefit from this conversion. A link to Carat (mass) was sufficient for those who don't have a good feel for what 33.19 carats means. Avram (talk) 21:20, 8 February 2009 (UTC)[reply]

Thanks for the helpful explanation, but I think it misses a couple of points.

1. One is that it's a real inconvenience to jump to another page just for a conversion and then back again, and most people won't do it. (It was over six months, and two thousand edits, before I installed pop-ups so that I could just mouse over a wikilink to read the lede, and the vast majority of readers don't even edit, let alone register.) That doesn't mean you shouldn't keep or restore the link to carat (mass) -- you definitely should; just that in my opinion it's not sufficient. Since this is English-language Wikipedia, a conversion to gram(me)s and fractions of an ounce would be most useful.
2. Secondly, while Lightmouse's method may not appeal to everyone, his point is extremely sound. If it's unclear what unit is being used, then taking it out to two decimal points makes no sense. (Needless to say, this applies a fortiori to taking out the grammes to three decimal points if you don't know that the conversion is sound in the first place; at least it's 33.12 carats of some kind, but it may not be 6.638 grammes of any kind.) [If I were writing about the tonnage of Laird rams, Confederate raiders built in British shipyards, decimal points would be literally pointless if no one knew if the tonnage was Imperial (2,240 lbs), U.S. (2,000 lbs) or metric (1,000 kg).] If the editors are unsure of the unit, perhaps they should let the readers know. —— Shakescene (talk) 22:25, 8 February 2009 (UTC)[reply]

Yup, WP:NOT PAPERS says you shouldn't rely on the reader clicking on any particular link in order to be able to understand a sentence. As for "that carat is a metric unit anyway", that depends of what you (Avram) mean by "metric". It isn't a unit approved for use with the SI, and it isn't a unit that most people in Europe are familiar with. Maybe by "metric" you mean "defined as an exact multiple of a SI unit", but the same is true of the inch ... --A. di M. (talk) 10:16, 9 February 2009 (UTC)[reply]

• Scanning through the above thread, I’m not seeing where anyone has asked if diamonds are sold in Europe in grams or milligrams. If they are sold only in carats world-wide, then there is no point to showing a conversion to grams since no one “thinks” in those terms as it relates to diamonds. Greg L (talk) 21:30, 9 February 2009 (UTC)[reply]

• But people do think in those terms as relates to objects in general, and for those of us not wealthy enough to have extensive experience buying and selling diamonds, carats do not signify much. So it can be argued that adding the weight in more familiar units actually makes it more legible. Shreevatsa (talk) 21:44, 9 February 2009 (UTC)[reply]

• OK. So maybe the best way to handle this would be, for say, a record-setting diamond that weighs 87 carats, to have a one-time conversion to grams so people can get grounded in the basic magnitude of the measure. From thereon in that article, if mention is made of a 54‑carat diamond, there is no need to clutter up the article with more gram conversions because all these are comparisons and it is now clear that the smaller diamond is 57⁄87ths the size of diamond that is the subject of the article. A one-time conversion. Greg L (talk) 23:13, 9 February 2009 (UTC)[reply]

• Yes, that seems most reasonable. Shreevatsa (talk) 23:29, 9 February 2009 (UTC)[reply]

• Then we'll have people coming along saying that metric (or US) conversions clutter up lots of pages. Where's the end of it. I, for one, have little idea of what a carat means. Tony (talk) 02:55, 10 February 2009 (UTC)[reply]

• It’s like oil being sold at US$50 per barrel. Most wouldn’t know whether its a 42-gallon barrel or a 55 gallon barrel of oil, or if it’s a British gallon or a Martian barrel. Oil is pumped, traded, and quoted in barrels and that’s what readers really need to know. A one-time link to Barrel is just fine for those who want to better understand the magnitude of the measure. Gravimetry is measured in gals (world wide). Diamonds are measured in carats—world wide. Japanese motorcycle engines are measured in cc.

  All we’re doing in these examples is following current literature (FCL), which varies from discipline to discipline. If a record-setting diamond like the Hope Diamond is particularly notable because it’s so damn big, it would be rather nice to know how many grams it is and to state as much right in the article without requiring readers click on a link and do some math. But for regular, pedestrian purposes, a 0.5-carat diamond is a 0.5-carat diamond and there is simply no point to cluttering up Wikipedia with conversions to units of measure that are unused in the discipline—even if its the splendorific SI by the French. It’s not like we’re preparing to get earth ready to join the United Federation of Planets. Also, we are really and truly not “heading down some path” or “opening the door” to any practices to rid Wikipedia of the SI when we do this; we are simply embracing Follow Current Literature, which best prepares our readership to be conversant in the art and best readies them for their continuing studies elsewhere. Also…

  This is, after all, an electronic encyclopedia; let’s exploit the true power of links. For pedestrian purposes, all we need is a first-time link to carat, which explains that a carat is 200 mg. Or, at most, a one-time conversion or explanation right in a given article that one carat is 200 milligrams will certainly do no harm.

  And no, an 81 mg diamond or a 200 mg diamond is not the same weight as an 81 or 200 mg medicine tablet. All tablets have “excipients” (non-active tableting ingredients) like microcrystalline cellulose as a binding agent, and flow agents and other excipients. These inactive additives contribute significantly to the mass of tablets. I know, since I’ve formulated tableting formulas before. I went through 32 iterations on my last effort until I had one that had all the right properties, which is now called “Formula #33.” Greg L (talk) 05:28, 10 February 2009 (UTC)[reply]

• Some people use a Wikipedia article as an introduction to a subject they intend to learn more about; they benefit from the concept of following the current literature. For others, the Wikipedia article will be the last word they read on the subject. These readers benefit from units that allow them to compare the quantities in the article to quantities in other topics they understand; SI satisfies this need the best. A reasonable balance in serving both kinds of readers is appropriate. --Gerry Ashton (talk) 05:54, 10 February 2009 (UTC)[reply]

I agree with Gerry. The world of oil might think in terms of the 42-US-gallon barrel but I don't, nor do I have any burning need to be prepared to be conversant in the art nor readied for continuing studies. They've got their wacky units and they can keep them, let me read an article without having to multiply every number I run across by 0.2. JIMp _talk·cont 07:34, 10 February 2009 (UTC)[reply]

A liberal amount of conversions to more familiar units is good thing. Many readers will use WP to get a grip on the lookup subject, not to prepare for further study of the literature. Literature is written by experts for people especially deeply interested in a subject, not for the general public as WP. Units used in the current literature are by no means the best choice for WP. −Woodstone (talk) 08:31, 10 February 2009 (UTC)[reply]

That's essentially what WP:NOT PAPERS says. But, on the other hand, if an article used the carat fifteen times in a sentence, providing a conversion everywhere might be overkill; after a while, one would have learnt that a carat is a fifth of a gram. In such a case, I would provide a conversion for each such measurement in the lead section (and link the first measurement to carat), then I would create a footnote such as "A carat is equal to 0.2 grams." and stick it after the first sentence which uses that unit in each section. (This would not apply to temperatures, because you can't reason like "if 50 carats is 10 grams, 25 carats will be 5 grams"; I would use conversions such as "6 °C (43 °F)", "43 °F (6 °C)", or even "279 K (6 °C, 43 °F)" for each single temperature, even if there were hundreds of them in the article.) --A. di M. (talk) 10:44, 10 February 2009 (UTC)[reply]

• Exactly. What A. di M. said. All we are only talking about is over-converting. There is no need to say “They offer 1-carat (200 mg) synthetic diamonds but used to sell only up to 0.6-carat (120 mg) diamonds. Their competitor offers yellow synthetics as large as 3 carats (600 mg)” Yeah, we get it. We get it. So too do the readers. We’re not kicking sand in the face of the SI system; we’re saying that to strike a reasonable compromise with providing sufficient information and cluttering up the article with conversions, all that is necessary is to mention once—via either a short sentence explaining that there are 200 milligrams in a carat, or via a one-time conversion—and to not bother after that. There is simply no need for repeatedly converting when diamonds are measured only in carats world wide. Greg L (talk) 17:22, 10 February 2009 (UTC)[reply]

If you have any unit used fifteen time in one sentence, you probably should do a rewrite. Clutter for one is useful information for another. JIMp _talk·cont 20:55, 10 February 2009 (UTC)[reply]

The MOSNUM was clearly on Lightmouse's side in this edit example and he should have had the discussion pointing this out over at the page in question (Krupp Diamond) first. —MJCdetroit ^(yak) 00:02, 11 February 2009 (UTC)[reply]

I am sorry if I asked the question in the wrong place. Lightmouse (talk) 09:07, 11 February 2009 (UTC)[reply]

No, considering the response, I think this was probably the right place, especially as Lightmouse was seeking general guidance that he might not have found at Krupp Diamond. The question is important, but not so significant for Krupp Diamond, which most of us would never otherwise have visited. And what may be clearer about the Manual of Style now wasn't so clear earlier. —— Shakescene (talk) 11:07, 11 February 2009 (UTC)[reply]

Thanks. There is also a debate going on at Template_talk:Convert#Excessive_use_of_double_output about whether carat conversion should continue to be unusual. Lightmouse (talk) 11:55, 11 February 2009 (UTC)[reply]

Readers of this thread may be interested in examining the documentation for {{start-date}}. This is an example of a date-time template that imposes fewer restrictions described by opposing camps in previous date formatting debates. It addresses the numerical accuracy interests such as those of the microformat / metadata camp interested in accurate ISO8601 dates, and those interested in readability, imposing far fewer restrictions concerning formating or using templates such as for Julian dates precisely. Examples:

I have proposed that the old way of specifying dates in wonky error prone forms be deprecated. Specifically, this sort of template is completely unnecessary: Eg:{{Start date|1941|12|7|18|Z|df=yes}} might seem to be the correct syntax for the december 7 example above, but the user must do their own conversion to UTC, and they can't format the way they like to. They also may run into bugs. The above example displays as:

18:0Z, 7 December 1941 (1941-12-07T18:0Z)

I propose that a new family of templates that allow contributors total freedom in formatting dates, using links or templates, which simultaneously allowing the precision folks such at the microformats/ ISO8601 crowd to express dates in their gregorian oriented with the accuracy they desire. This particular template correctly generates ISO8601 date/times between -6999 BC to 6999 AD in natural language and properly handles time zones and date arithmetic in natural forms (eg "february 08, 2009 next sunday" delivers 2009-02-15). Most of the magic is not in the template but an underlying wikitext function, but the point is that in many if not most cases there is no longer any technical need to use wonkey templates requiring separate parameters for year month and days as many have advocated in the past. If anyone is interested in a customized form of this free form template or have ideas for it being even more simplified or able to perform additional functions, please contact me.

Users interested in verifying the ISO values emitted by these examples may see them by turning off CSS in their browsers, (eg: in Opera, use the view Author versus user mode and set one mode to no style sheets). -J JMesserly (talk) 08:50, 9 February 2009 (UTC)[reply]

As has already been pointed out to you elsewhere, the example which displays as "18:0Z, 7 December 1941" is not in one of the formats listed on {{Start date}}'s documentation. "GIGO" applies. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:09, 9 February 2009 (UTC)[reply]

That's fine. As I asked before, if the example is wrong, then what is the correct way of expressing it using the old {{start date}} template, and why should it be so complicated for users to read and understand? {{start-date}} is a different approach that many contributors will find much more flexible and intelligible for their editing requirements. Of course, the MOS community can make their assessment. It is true this is a new untested template and there may be bugs to fix with it. I am ready to address the bugs that come up, so if you find any, please report them on the template's talk page and I will get to them as soon as possible. -J JMesserly (talk) 22:58, 9 February 2009 (UTC)[reply]

I don't recall seeing you ask that before; but {{Start date|1941|12|7|18|00||df=yes|-10:00}} returns 18:00, 7 December 1941 (-10:00) (1941-12-07T18:00-10:00). If you have an issue with that, I can only reiterate, once again, that you have been invited to raise them on that template's talk page. You appear to still not have done so. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:08, 10 February 2009 (UTC)[reply]

(undent) The issue I raised here is obvious from your example. The syntax is needlessly unintelligible and complex. I propose that the Manual of style state that human readable templates are preferred to that are less human readable. -J JMesserly (talk) 17:45, 10 February 2009 (UTC)[reply]

That's not a MOS issue, but feel free to take that to WP:VPP. I suggest you first make {{Convert|one and three-quarter inches|cm}} work. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:42, 10 February 2009 (UTC)[reply]

A surprising assertion. Your proposal at Bot requests is to convert large numbers of intelligible dates into the unintelligible form above. Let's see if others agree if readability for editors is not a relevant issue for MOS to address. -J JMesserly (talk) 18:53, 10 February 2009 (UTC)[reply]

MoS is concerned with article content, not the internal format of templates. The proposal at BOTREQ, which already has consensus and would already be completed if the bot operator concerned had not suffered a bereavement, is to replace prose dates with a widely-used-by-consensus template, emitting both hidden microformat properties, also agreed by consensus, and an equivalent prose date for human readers. If you wish to prevent the use of {{Start date}}, please demonstrated consensus by nominating it for deletion. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:59, 10 February 2009 (UTC)[reply]

P.S. Here is an example of the change requested in the BOTREQ; note that the text visible on the page does not change. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:08, 10 February 2009 (UTC)[reply]

Andy, the Hudson's Bay Company article contains the {{Infobox Company}} template, which the proposed bot would act upon. Please explain what the result would be, both in terms of the new parameter, and in terms of the microtext that would be emitted, for the parameter foundation = May 2, 1670. --Gerry Ashton (talk) 20:33, 10 February 2009 (UTC)[reply]

If I could step in here Gerry, the microformat date emitted would look like this: 1670-05-02. The old template syntax would be {{start date|1670|5|2}} = "May 2, 1670 (1670-05-02)". A bigger question is what he does with Bacardi, which also uses {{Infobox Company}}

foundation = [[Santiago de Cuba]], [[Cuba]] ([[February 4]], [[1862]]) 

With the new template, it would be {{start-date|February 4, 1862|[[February 4]], [[1862]]}} Andy, what do you propose your concensus of one bot do to Barcardi's foundation date? What will the wikitext for the template look like? -J JMesserly (talk) 04:41, 11 February 2009 (UTC)[reply]

If J JMesserly is right, and the bot actually replaces "May 2, 1670" with {{start date|1670|5|2}} then the HTML source sent to the browser will be

May 2, 1670<span style="display:none"> (<span class="bday dtstart updated">1670-05-02</span>)</span>

This is wrong, because microformats, like ISO 8601, are always in the Gregorian calendar, and the founding date of the Hudson's Bay Company is May 12, 1670, Gregorian. --Gerry Ashton (talk) 05:06, 11 February 2009 (UTC)[reply]

You can verify the answer above with the Opera browser by going to View.Style.User Mode, the template emits Gregorian date of (1670-05-02) as you feared. Of course the new template format is trivial: {{start-date|May 12, 1670|May 2, 1670}} = May 2, 1670 (1670-05-12), which produces the correct date normalized into gregorian calendar form had it existed back then: (1670-05-12Z). (Note to self- got to get rid of the superfluous Z when no time specified) BTW- I am pretty good at Bots and would be happy to make the bot runs so that Julian dates would be expressed correctly in ISO8601. Of course, this would require use of the newer template. I am pretty sure I can dig up the code that does Julian to Gregorian conversions, but we would do small trial runs to spot check it before going whole hog on everything. -J JMesserly (talk) 05:17, 11 February 2009 (UTC)[reply]

I propose that the BOT run ignores dates before (IIRC) 1750. Later, once {{T;|Start date}] is changed to emit the correct Gregorian date, another run could be made. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:22, 11 February 2009 (UTC)[reply]

George Washington's family bible recorded his birth as the "11th Day of February 1731 / 2".[1] We now state the first President's birth date as February 22, 1732. The old style dates were often expressed as "1731 / 2" because the New Year could be March 25 or January 1. Happy birthday George. -- SWTPC6800 (talk) 05:39, 11 February 2009 (UTC)[reply]

By the way, for those concerned about this normalization of Julian dates into Gregorian values- these microformat emitted ISO values are not necessarily seen by users- it is an interchange format. A historical application would presumably know very well that it would have to convert the Gregorian distored ISO date back into the correct Julian form before displaying it. -J JMesserly (talk) 05:47, 11 February 2009 (UTC)[reply]

Microformats use ISO 8601. The standard is very clear about that. What I've seen of the microformat standards are equally clear. If a historical application sees a microformat, it knows that the date is (A) Gregorian, (B) a mistake, or (C) a damn lie.

As for using a bot, how is the bot supposed to figure out what calendar the date is in? It depends on the time period and the location. If the location is someplace that observed neither the Julian nor Gregorian calendar, it's anybody's guess what calendar was used. --Gerry Ashton (talk) 06:08, 11 February 2009 (UTC)[reply]

• REQUEST FOR CLARIFICATION: Is this a discussion/proposal to replace our currently 'layman' dates with "computer nerd" dates throughout WP? Ohconfucius (talk) 10:03, 11 February 2009 (UTC)[reply]

• Sounds like a recipe for chaos. We have a very good system now—basically a binary one, both formats readily understandable by everyone in the world. The community takes a conservative line now on needless complications in date formatting. Tony (talk) 11:46, 11 February 2009 (UTC)[reply]

Ohconfucius: the Bot request referenced earlier would convert numbers into the form of the example above by PigsontheWing: {{Start date|1941|12|7|18|00||df=yes|-10:00}} and would eliminate any date links they used. The counter proposal is to use a less nerdy alternative template that would express the date in human readable form. The template with the dashes is the new template. The templates with no dashes is the older more numerically oriented template.

Tony1- The existing system is good, and the principle of needless complication of formatting is a good one. What is driving this change request to either accept {{start date}} or the alternative {{start-date}} is admittedly speculative at this point. You no doubt have seen those world icons with coordinates popping up on many pages. Today using browser toolbar addons, and next year as browser standard functionality, users visiting these pages will see a map button activate- could be (google maps/ yahoo maps/ name the user's favorite selected map site). You click the button, and suddenly you are looking at the 1000 foot view of the Parthenon. Pretty cool. The requirement to do this is for wikipedia to emit dates using standard templates that emit the metadata, and some of these make the wikitext markup look pretty nerdy. My proposal is to use a format with the least Frankenstein effect while also emitting the needed dates. Now, I said, admittedly speculative. Here's why. Today, there is no applications like Yahoo or google maps that show people times and locations in their historical context. But they could. Imagine a google earth where you could navigate in the fourth dimension of time. You could visit the battlefields of WWI, and see photos of the carnage and the battlefields, see 3D models of the trenches, etc. So just as you can click on the activated map icon in your browser, you could click on an event and see its time and location depicted on their site. Why should we do anything before these sites materialize? Chicken egg problem. You have to have data to make such applications anything more than toys. No one wants to provide the data until the applications materialize. What I am proposing is a template that emits the needed metadata (microformat) dates with the hope of enhancing Wikipedia's role in being the preeminent source of free and accurate knowledge that these leading edge applications use. I personally come at this from the history enthusiast point of view- I don't care about microformat technology in particular, but I am willing to go with anything that works, and it does. I should also note that hours and minutes are not supported in current templates and this is relevant for some events. For example, JFK assassination, or military events- first naval engagement between Japan and US in WWII outside the entrance of Pearl harbor at 8:43am Hawaii Standard time on December 7, 1941. -J JMesserly (talk) 17:33, 11 February 2009 (UTC)[reply]

There are already applications which parse hCalendar microformats. For that reason if no other (and there are other, good, reasons) it is important that the microformat metadata which we emit is valid, accurate, precise, but not overprecise. Wikipedia already has templates which emit dates for use in microformats, and you have been invited time and again to raise any issues with them on their talk page, but have still not done so. Perhaps you should leave these matters to people who do care for microformat technology; and therefore take great care to apply it correctly. As to your claim that "hours and minutes are not supported in current templates"; JFK was declared dead at 1:00 p.m., CST (19:00 UTC); {{Start date|1963|11|22|19|00||-07:00 renders as 19:00, November 22, 1963 (-07:00) (1963-11-22T19:00-07:00) and emits 1963-11-22T19:00-07:00; alternatively {{Start date|1963|11|22|13|00||}} renders as 13:00, November 22, 1963 (1963-11-22T13:00) and emits 1963-11-22T13:00.  () is currently transcluded around 10,000 times, and has been in use - without any significant complaints - since July 2007. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:39, 11 February 2009 (UTC)[reply]

Folks did Julian dates wrong for a long time too. Inertia of bad practice is not argument for its needless perpetuation. The assertion appears to be that is that the MOS community has no place in making a statement that wikitext markup not be needlessly complex. I suggest that it is precisely their duty to do so, because errors are much more difficult to correct if they are needlessly complex. Lack of clarity with data encoding leads even engineers to make mistakes of assuming miles when the units were kilometers, resulting in a billion dollar pile of junk on mars. Consider the following markup for the time JFK was died, reported as approximately 1pm CST:

Besides the ease in coding and understanding the time, note the glaring difference that should be obvious to affeciandos of time. The first case due to its obscurity and non reliance on robust system support for time calculation the editor did not make the correct adjustment for it not being daylight savings time. Time zone adjustment is what the meaning of the -7:00 is, and for Dallas, it is either -6:00 for winter, or -5:00 for summer as explained in the upcoming link. Actually that's not the only error this hypothetical contributor has made, the correct microformat expression of this time with the time zone adjustment as the editor is attempting to do is actually 1963-11-22T13:00-06:00, and their syntax in the wonkey {{start date}} template should be changes to reflect that (for explanation see ISO time zone syntax. Everyone makes mistakes, even microformats enthusiasts. So how can we expect content experts to understand this stuff? Who is going to spot that error with the syntax in such a unnecessarily complex form? I am interested in exposing this kind of information, and it is true I am not religious about one particular technology or another. I study what a particular format requires, and I am good at writing code that adheres to standards. I just don't see any need for the requirements of the microformats folks to make it more difficult for contributors at WP to spot and fix errors. -J JMesserly (talk) 20:57, 11 February 2009 (UTC)[reply]

Can we have a specification for this design at: Wikipedia talk:Manual of Style (dates and numbers)/Specification for 'son of autoformatting'? Lightmouse (talk) 12:54, 11 February 2009 (UTC)[reply]

There are two competing designs being discussed: One family of templates using dashes in the name, and one family that doesn't. I champion the newer templates with dashes in the template name eg: {{start-date}}. These newer, templates takes no sides in autoformatting questions. Do you require a specification to that effect? The contributor is in control of format and can choose to use auto formatting templates in the second parameter or not. All the template cares about is the accuracy of the date-time in the first parameter. This is the value exposed to the outside world, and if the second parameter is present, then the only people that see it is those with CSS turned off. The old template {{start date}} does do autoformatting, and so I leave it to the champions of that template to respond on their position regarding autoformatting. -J JMesserly (talk) 18:00, 11 February 2009 (UTC)[reply]

{{Start date}} can have auto-linking/ formatting of dates, or not; whatever the community decides. It used to Auto-link dates, but this was removed recently (not by me). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:42, 11 February 2009 (UTC)[reply]

Moratorium on futher conversions to use older template:Start date

Given the example that even one of the authors of the template {{start date}} forgot how to use it (see above example on date of JFK death) due to its obscure rules, I propose that there be an indefinite moratorium on any future bot runs converting articles from use of intelligible dates to the far less human readable form that {{start date}} uses. Unnecessarily complex encodings present obstacles to contributors to Wikipedia. As shown, they can present obstacles even to those who are expert in their use. Since there are templates that achieve the same goal and are far more readable, there is no need for conversion to the old {{start date}} template. Presumably if no one comments, this principle is recognized as well supported by the example above. -J JMesserly (talk) 15:39, 12 February 2009 (UTC)[reply]

Completely agree. Such a template should not be used if it can only be understood by persons of an IQ greater than ten. Ohconfucius (talk) 16:13, 12 February 2009 (UTC)[reply]

I agree for a different reason: the template is incapable of working with non-Gregorian dates, and it is difficult for a bot to tell what calendar a date is in. --Gerry Ashton (talk) 16:30, 12 February 2009 (UTC)[reply]

I have already told you that I suggest not converting non-Gregorian dates. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:03, 13 February 2009 (UTC)[reply]

Yet again, J JMesserly resorts to falsehood to further his arguments. I "misnunderstood" nothing; I merely neglected to amend the text copied from the "-07:00" example on [[2]].

−

Start date

+

This was a test!

is already used in over 10,000 articles. J JMesserly has been repeatedly invited to raise any concerns with {{Start date}} on its talk page (as indeed any editor may), but has yet to do so. Though I created that template some time ago, I am not the author of its current code.And consusus-buiilding is Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:01, 13 February 2009 (UTC)[reply]

I apologize for any offense taken about my mischaracterisation of the error. Whatever the reason for the error, if even an enthusiast can make such an mistake when making his case for a template, then this is strong evidence that templates with obscure encoding rules should not be used when substitutes are available. Human readability is a strong principle in standards these days, and it seems to me this principle ought to be a general MOS guidance for all wikitext. For now, I propose that the MOSNUM guidance specifically make Tony's "needless complications" principle explicit as it applies to use of date templates when more human readable substitute templates are available. Any objections to this addition to the page? -J JMesserly (talk) 21:10, 13 February 2009 (UTC)[reply]

{{editprotected}} Will some admin please make two, uncontroversial updates to MOSNUM, as outlined above at Val is now fixed? Greg L (talk) 05:34, 10 February 2009 (UTC)[reply]

 DoneCompleted as non-controversial and necessarily informational updates. --MASEM 17:32, 10 February 2009 (UTC)[reply]

• Thanks Masem. And… Darn! Oh well, the new information is now correct for today anyway. I was rushing back here to say that User:Dragons flight, who is a developer, fixed all of {{val}}’s issues. See Template_talk:Val#The_final_solution. His replacement code apparently is waiting for some admin with God powers to unlock {val} and replace the code with some do-all, ultra-tight code that fixes trailing zeros and is good for more digits. When that has been done, I’ll repost the request here with new suggested wording. Greg L (talk) 20:20, 10 February 2009 (UTC)[reply]

I don't see this addressed in the style: commas after dates. In standard written English, this sentence has the comma after the year: "His popularity fell after his arrest on June 12, 1987, became known." Many Wikipedia pages render this incorrectly, leaving out the comma after the year. Should this standard rule be included in the manual on dates and numbers? Is this addressed by any of the bots that fix dates?BlackberryHacks (talk) —Preceding undated comment was added at 22:00, 10 February 2009 (UTC).[reply]

How would a date-fixing bot address this sentence? "The band announced that the concert on February 10th 2009 was to be their last." -- Earle Martin [^t/_c] 23:05, 10 February 2009 (UTC)[reply]

If it were working correctly: "The band announced that the concert on February 10, 2009, was to be their last." The operative rules are: Chicago Manual of Style, 15th ed., 9.35: "When specific dates are expressed, cardinal numbers are used, although these may be pronounced as ordinals, for the month-day-year date form versus the day-month-year form." and Chicago Manual of Style, 15th ed., 6.46: "In the month-day-year style of dates, the style most commonly used in the United States and hence now recommended by Chicago, commas are used both before and after the year." - Nunh-huh 03:30, 11 February 2009 (UTC)[reply]

Bandying around style guides now, are we? Well, here's what my copy of Hart's (37th ed., 1970, which I should pay more attention to) has to say about dates:

In dates, print 25 June 1967. Omit the comma between month and year.... As to the form May 19, 1862, Sir James Murray said, "This is not logical; 19 May 1862 is. Begin at day, ascend to month, ascend to year; not begin at month, descend to day, then ascend to year."

But that's irrelevant on Wikipedia, so it doesn't matter what you or I can quote at each other.

Anyway, what you're claiming doesn't make any sense. When read, the pause introduced by the comma is totally spurious, whether in British or American English. The only way it would be appropriate would be if it were used to terminate a relative subordinate clause, as follows: "The band announced that the concert, on 10 February 2009, was to be their last." But that changes the meaning of the sentence. -- Earle Martin [^t/_c] 16:28, 11 February 2009 (UTC)[reply]

Of course style guides are useful for determining standard English usage - certainly more useful than opinions of random Wikipedians! The one I've quoted has the benefit of actually being applicable to the question asked, which was about the month-day-year style of dates. And the question was about correct practice, not about what makes "sense" to Earle Martin. - Nunh-huh 16:41, 11 February 2009 (UTC)[reply]

"Standard usage" and "correct practice" are in the eye of the beholder. There's not a person I know that would use a comma in such a fashion. And what's with the odd usage of my name in your comment? -- Earle Martin [^t/_c] 16:45, 11 February 2009 (UTC)[reply]

Apparently your acquaintances don't include any authors publishing in the U.S.: they would all have their manuscripts prepared for publication in accordance with CMS. There's nothing odd about your name, or its use: you have been stating your personal opinion (and now those of your friends) rather than actually citing an authoritative source. - Nunh-huh 16:54, 11 February 2009 (UTC)[reply]

My acquaintances include friends and family members with decades of experience in the British publishing industry, both as publishers and authors. Once again, you're pushing this canard that Wikipedia is uniquely guided by American stylistic opinions. It is not.

Regarding the other point, over here it's considered rude to use someone's name like an object while talking to them. I guess your style guide didn't tell you that. You could have chosen to say "what authoritative source does this stem from?", and I would have answered "Hart's makes no such order regarding commas, and that is the principle I work by"; however, you chose to make an ad hominem instead. Well done. -- Earle Martin [^t/_c] 17:17, 11 February 2009 (UTC)[reply]

You've misrepresented me. I haven't even intimated that "Wikipedia is uniquely guided by American stylistic opinions", I've simply cited an authoritative source on American dating style. Surely it's not controversial that we should consult American sources on American styles? Does your British experience equip you to opine authoritatively on American style?

As for the other point, a talk page is not a personal conversation. As for Hart's Rules, we might usefully consult them if the question were about British style dates or preparing manuscripts for the Oxford University Press; but as the question is about American style dates, Hart's silence is neither relevant nor persuasive. - Nunh-huh 17:32, 11 February 2009 (UTC)[reply]

Your very first comment above implied that a bot operating "correctly" should follow Chicago opinion.

"A talk page is not a personal conversation" is one of the most bizarre assertions I've heard this week. Are we not talking to each other? I commend you for this tremendously quirky attempt to lawyer your way out of being pointed out as rude. -- Earle Martin [^t/_c] 17:48, 11 February 2009 (UTC)[reply]

[1] A bot fixing an American style date should fix it correctly. You seems to be obsessing about which style to use, but that is not the concern either of myself or the original questioner. [2] You and I are talking, but others are reading. I used your name. I confess to the crime. I don't need a lawyer. [3] The only relevant point: correct American style dates use a comma both before and after the year. - Nunh-huh 17:57, 11 February 2009 (UTC)[reply]

The only "obsession" - if we are going to use that sort of language - appears to be yours, on the topic of American style dates. Both the original questioner and I were discussing the issue of commas after dates. You appear to have misconstrued a sentence using an American style date as an example as being a sentence specifically about American style dates. (The correctness of the original assertion about "standard English" is a separate issue.)

I'm leaving this conversation now, as it is draining me of the will to live. Goodbye and good luck. -- Earle Martin [^t/_c] 18:45, 11 February 2009 (UTC)[reply]

I'm more than happy to let those who read decide which of us has misunderstood the original question. Bye! - Nunh-huh 18:51, 11 February 2009 (UTC)[reply]

No, standard written English does not have "His popularity fell after his arrest on June 12, 1987, became known." Either drop the comma, or write "His popularity fell after his arrest, on June 12, 1987, became known." Shreevatsa (talk) 01:38, 11 February 2009 (UTC)[reply]

First, BlackberryHacks should read Lynne Truss's book Eats, Shoots and Leaves, then he should read David Crystal's book The Fight for English - How language pundits ate, shot, and left. Then he will know more about English punctuation.RockyMtnGuy (talk) 03:18, 11 February 2009 (UTC)[reply]

It would be better if he consulted a reliable reference rather than a humorous popular work. In the Chicago Manual of Style (15th ed.), for example, in section 6.46, he would find, "In the month-day-year style of dates, the style most commonly used in the United States and hence now recommended by Chicago, commas are used both before and after the year." - Nunh-huh 03:30, 11 February 2009 (UTC)[reply]

Perhaps we could stick to the original question. I'll try again: If a date is expressed in the style of month day year (the most common American style), the style in publications is to place a comma after the year. One commenter already quoted the Chicago Manual of Style. And news publications primarily use the Associated Press style, which follows the same guidelines: "The attacks of Sept. 11, 2001, prompted the American invasion of Afghanistan." Wikipedia's style does not seem to address this point, so I'm asking, what is the style here?BlackberryHacks (talk) 21:16, 11 February 2009 (UTC)[reply]

Here is the style in the Associated Press stylebook: "When a phrase lists only a month and a year, do not separate the year with commas. When a phrase refers to a month, day and year, set off the year with commas. EXAMPLES: January 1972 was a cold month. Jan. 2 was the coldest day of the month. His birthday is May 8. Feb. 14, 1987, was the target date." I'm not suggesting that Wikipedia style must follow the style of the Associated Press (used by news organizations) or the Chicago Manual of Style (used in academia), but these are the standard stylebooks for English-language publications, at least in the U.S. What is Wikipedia's style, or what should it be, on commas after full dates?BlackberryHacks (talk) 23:17, 11 February 2009 (UTC)[reply]

The Canadian government style manual uses a comma after the year for dates in month-day-year order, e.g. January 12, 1972, was a cold day, but not after the year for dates in day-month-year order, e.g. 12 January 1972 was a cold day. Americans would normally use the former and British the latter.RockyMtnGuy (talk) 00:18, 12 February 2009 (UTC)[reply]

The comma following the year is required because the year is parenthetical. It's required for the same reason that a comma is required in the sentence: I believe that Jack Smith, my brother, is a good man. It's just a different way of writing: His popularity fell after his arrest on June 12 (in the year 1987) became known. By the same reasoning, the year should actually be made parenthetical even when using DMY format, although I've not seen any style guides that recommend that. --UC_Bill (talk) 16:35, 12 February 2009 (UTC)[reply]

To elaborate on UC_Bill's comment, some style guides have decided the year is parenthetical. But in reality, people have an innate ability to speak and write grammatically correct language, and style guides are an imperfect attempt to figure out what goes on in peoples' brains. If a person thinks of a full date as a unit, and thinks of the spoken pause between the day-number and the year as merely a way to tell where the day-number ends and the year begins, that person will naturally not want to put a comma after the year. We could decide that Wikipedia's style is to put a comma after the year, but there is no getting around the fact that this will cause friction in the brains of some of our readers. --Gerry Ashton (talk) 16:50, 12 February 2009 (UTC)[reply]

There is no style guide yet cited - indeed, there probably is no style guide - which does not mandate a comma after the year in month-day-year dates. The reason UC_Bill infers is not stated in those style guides. It's incorrect to say "some" style guides mandate it: every style guide which speaks to the issue insists upon the comma. It's not for Wikipedia to mould the English language to the whims of Wikipedians; we should simply accept the fact that a comma is called for. There's no getting around the fact that to fail to do so would cause friction in the brains of some of our readers. - Nunh-huh 17:00, 12 February 2009 (UTC)[reply]

The reason I inferred is stated in some places, such as here:

Note that we use a comma or a set of commas to make the year parenthetical when the date of the month is included (Reason 10)

I don't have a strong opinion on this, as I both agree that following style guides is a good idea and I agree with Gerry's point that "proper" grammar is determined by how people actually use the language, not by what a style guide says. I was just addressing the claim that the comma is "illogical" or "makes no sense" when, if seen as setting the year as parenthetical, it does make sense. Now, one can still question whether the year should be parenthetical, but as long as it is, the comma is correct and logical. --UC_Bill (talk) 18:56, 12 February 2009 (UTC)[reply]

A style guide is prescriptivist by its very nature. A "descriptivist" style guide has no reason to exist. The discussion here is aimed at formulating a set of rules to follow - rules somewhat more exacting than "write like you speak" and "punctuate (or not) as the feeling moves you". - Nunh-huh 20:23, 12 February 2009 (UTC)[reply]

As WP:POL says, our guidelines are descriptive; these pages could easily be so by being phrased as Most Wikipedia articles do X or The following guides to English usage recommend Y. The first approach would encourage a MOS that actually reflected Wikipedian consensus; the second would encourage sourced claims, and a judicious selection of sources would produce a MOS that actually recommended English, instead of the pipe-dreams of language reformers. Either would be an improvement over what we have now. Septentrionalis PMAnderson 03:44, 13 February 2009 (UTC)[reply]

WP:POL may say it, but it's descriptivist in its description: when the rubber meets the road, the date-delinking bots don their hob-nail boots and enforce the "recommendations". - Nunh-huh 03:51, 13 February 2009 (UTC)[reply]

Is one doing so now? (Not that this section is discussing date delinking.) Septentrionalis PMAnderson 03:56, 13 February 2009 (UTC)[reply]

As I suspect you well know :) , they are on temporary hold. -Nunh-huh 03:59, 13 February 2009 (UTC)[reply]

And may be on permanent hold. That would place the peace of WP above the prejudices of a handful of editors. Septentrionalis PMAnderson 04:02, 13 February 2009 (UTC)[reply]

Well, yes. Maybe. - Nunh-huh 04:06, 13 February 2009 (UTC)[reply]

{{editprotected}} After a couple days of troubleshooting and e-mailing back and forth with the developers, it turns out that {{val}} has inconsistent results with 13 and 14-digit significands because roughly 20% of Wikipedia’s servers are old ones running Fedora. In a matter of weeks, those outdated servers will all be replaced so all are like the new ones, which are running Ubuntu. Once that happens, {val} will reliably handle 14-digit numbers. In the mean time, it can only properly generate 12-digit numbers 100% of the time. User:Dragons flight, who is a developer, has volunteered his efforts and done a fabulous job revising the number-crunching engine that {val} uses. Val now requires ten times less processor cycles (overhead) to render numbers than it previously did, and it now handles significands that end with zeros. Thus, values with uncertainty, such as 1.2345678900(32)×10⁻²³ kg properly display without dropping off the (seemingly) non-significant digits.

In the mean time, MOSNUM needs to be updated with the proper advise regarding {val}…

At Decimal points, please replace the last paragraph with this:

• For numbers with more than four digits after the decimal point, these can be separated (delimited) into groups of three by thin spaces protected by {{nowrap}}, or with {{val}}, which obtains the same appearance using margins instead of thin space characters. Per ISO convention (observed by the NIST and the BIPM), there must never be a single, dangling digit so the last group must always comprise two, three, or four digits. Thus, the progression is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles the grouping details automatically, e.g. it knows to take "0.1234567" and generate 0.1234567 (with a four-digit group at the end). Due to server-related issues, {{val}} can reliably handle no more than 12 significant digits. Optionally, truncated representations of mathematically defined constants with fifteen or more digits after the point can use groups of five digits (e.g. "e = 2.71828 18284 59045…"); in this case, the number of digits used between the point and the ellipsis, being arbitrary, should be a multiple of five (or of three, if three-digit groups are used).

At Notations, add this bullet point at the top:

• The template {{val}} can be used to facilitate the generation of scientific notation. It is a flexible tool that allows editors great latitude and should must have arguments (each section between the vertical bars) properly entered in order for it to generate output that is compliant with formating conventions.

At Uncertainty, replace the last paragraph with this:

• The template, {{val}}, may be used to automatically handle all of this.

I can see that this entire section covering big numbers, decimal points, delimiting, etc., needs to be revised and harmonized. That is for later after MOSNUM is no longer locked down. Though editors will have to hunt for relevant information, at least what they find will be correct. Greg L (talk) 01:25, 12 February 2009 (UTC)[reply]

•  Done per noncontroversial documentation update. --MASEM 02:07, 12 February 2009 (UTC)[reply]

• Thank you much, Masem. Greg L (talk) 02:20, 12 February 2009 (UTC)[reply]

Ahem. <nitpick>Actually, BIPM doesn't say "never". In the SI brochure, they say "However, when there are only four digits before or after the decimal marker, it is customary not to use a space to isolate a single digit. The practice of grouping digits in this way is a matter of choice; it is not always followed in certain specialized applications such as engineering drawings, financial statements, and scripts to be read by a computer." The examples in the margin read "either 3279.1683 or 3279.1683". While I think that allowing the latter format would only make Wikipedia more messy than it already is, we shouldn't misquote the BIPM (even if that is not a quote), so "... there must never be a single, dangling digit so the last group must always comprise ..." should be replaced with "... it is customary not to leave a single digit at the end, so that the last group comprises ...". (Also, the 2008 draft of ISO 80000-1 says "If the groups are separated this shall be done consistently, i.e. the first group in the integer part and the last group in the decimal part may contain one, two, or three digits, but not four digits", but fortunately it hasn't been approved yet; that is just one of many unreasonable requirements such as "Numbers shall be printed in roman (upright) type, irrespective of the type used in the rest of the text", which would declare the '74 Jailbreak in {{AC/DC}} incorrect.) </nitpick> Also, Shakescene and I have noticed that using "thin spaces protected by nowrap" can produce silly output (see #Revised Decimal subsection's line goes over margin above), so it should be deprecated.

So I suggest to replace the above with:

• For numbers with more than four digits after the decimal point, these can be separated (delimited) into groups of three. Per ISO convention (observed by the NIST and the BIPM), it is customary not to leave a single digit at the end, so that the last group comprises two, three, or four digits. Thus, the progression is as follows: 0.123, 0.1234, 0.12345, 0.123456, 0.1234567, 0.12345678, 0.123456789, etc. The template {{val}} can be used to handle the grouping details automatically, e.g., {{val|0.1234567}} generates 0.1234567 (with a four-digit group at the end); but due to server-related issues, {{val}} can reliably handle no more than 12 significant digits. In cases where {{val}} fails, the template {{gaps}} can be used, but the position of the gaps has to be specified by hand.
• Optionally, truncated representations of mathematically defined constants with fifteen or more digits after the point can use groups of five digits (e.g. e = 2.718281828459045…); in this case, the number of digits used between the point and the ellipsis, being arbitrary, should be a multiple of five (or of three, if three-digit groups are used).

--A. di M. (talk) 10:50, 12 February 2009 (UTC)[reply]

• Agreed; “never” was wording I should not have used. Your wording is very logically precise. Of course, we could have always used the words “on Wikipedia, editors should not” in order that we have a consistent house style. Thanks A. di M.. Greg L (talk) 22:00, 12 February 2009 (UTC)[reply]

  P.S. Here at leŭksman: Your donations at work: new servers for Wikipedia, is something that relates to how {val} will one day soon work consistently at 14 digit resolution. Greg L (talk) 22:04, 12 February 2009 (UTC)[reply]

  But isn't the whole MOS about what Wikipedia editors should and should not do? :-) --A. di M. (talk) 22:43, 12 February 2009 (UTC)[reply]

• Certainly. The difference lies in the subtleties of the wording. Note our *advice* on percentages:

The [percent] symbol is unspaced (71%, not 71 %).

That is quite blunt. One could just as easily have made a more factual statement about it that was more suggestive via a bully pulpit:

According to the BIPM’s SI Brochure–5.3.7 Stating values of dimensionless quantities, or quantities of dimension one, the BIPM is clear about the SI writing style with regard to the “%” symbol; it states as follows: “When it [the percent symbol] is used, a space separates the number and the symbol %.” This calls for 75 %, not 75%. However, it customary to not do so.

Quite rightly, we flout the rule of the SI and simply follow current literature on this issue. And, quite rightly, we make a very definitive statement that one does not put a space between the numeric value and the percent symbol; we have a consistent, non-awkward-looking house style as a result. Now…

I agreed with your proposed wording regarding {val} and digit grouping. I think your wording is better by being more accurate without opening up Wikipedia to an unnecessary hodgepodge of number formats.

If you are trying to make a broader point about the purpose of MOSNUM and the extent to which editors should (or must) comply, I don’t feel I can contribute to this tangent. Perhaps this discussion belongs on one (or both) of our talk pages. I think, as a practical matter, MOS and MOSNUM are style guides that must have flexibility on certain points and be more specific and definitive for others. Greg L (talk) 00:40, 13 February 2009 (UTC)[reply]

←My point was that "On Wikipedia, editors should" is redundant wording serving very little purpose, as it could apply to most of the MoS. (Anyway, you agree with my proposed wording, so this is moot.) As for percentages, I prefer the current, "blunt" wording. Most users will have never heard of the SI brochure nor care about what it says. Most users will be used to seeing unspaced percent signs. And I wouldn't be surprised if there were style guides recommending not to put a space before % signs.^[1] So the "blunt" statement perfectly serves its purpose; the "more factual statement" with "a bully pulpit" would only bloat the MoS text even more. (There already are such statements as "Use discretion when it comes to using scientific and engineering notation. Not all values need to be written in it (e.g., do not write the house was 1.25×10² y old, but rather the house was 125 years old in 2008 or simply the house was built in 1883)", I wander how <sarcasm>many</sarcasm> people would write "the house was 1.25×10² y old" if the MoS didn't tell them not to do that.) Anyway, I don't care about that too much, arguing on the wording of some style rule when everyone agrees about its content is quite a waste of time.

Next question is: Who can afford and is willing to buy the new ISO standard when it is officially published in order to decide whether the "Per ISO convention (observed by the NIST and the BIPM) ..." above should be replaced with "Per BIPM convention, also observed by the NIST, ..."? :-)

^ English Style Guide: A handbook for authors and translators in the European Commission 4.14: “In English, the sign is always closed up to the figure. Note that section 6.4 of the Interinstitutional Style Guide requires a space before the sign in texts for official publication. However, this requirement need not be observed by authors or translators as the space will be inserted automatically at the publication stage.” See also: "Percent_sign#Spacing".

--A. di M. (talk) 10:50, 13 February 2009 (UTC)[reply]