Jump to content

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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 115←Archive 118Archive 119Archive 120Archive 121Archive 122→Archive 125

Proposal: Delete guideline that bans "70 × 90 cm" and mandates "70 cm × 90 cm"

Somebody kindly brought my attention to Wikipedia:Manual_of_Style_(dates_and_numbers)#Conventions that says:

  • When dimensions are given, values each number should be followed by a unit (e.g., write 1 m × 3 m × 6 m, not 1 × 3 × 6 m3 or 1 × 3 × 6 m).

I propose deleting this guideline. I suspect the motivation for the guideline is that it resolves a potential ambiguity when the reader could mistake each value. For example, a glass door might be 8 millimetres thick, 2 metres high and 1 metre wide. Therefore it needs to be presented as "8 mm x 2 m x 1 m". However, I would like to be able to describe a painting as having dimensions of:

  • "70 x 90 cm"

This seems to me to be perfectly reasonable but the guideline would require.

  • "70 cm x 90 cm"

It is unlikely that the height of a painting will be 100 times the width. But if it were, any reasonable editor would add the unit labels without needing to be told i.e. "4 cm x 4 m". The guideline requires an additional eight characters (four metric, four non-metric) for two dimensional applications and sixteen characters for three dimensional applications. It adds no value but adds a burden. I propose that it is simply deleted. Does anyone support the proposal? Lightmouse (talk) 11:31, 27 January 2009 (UTC)

A most excellent proposal and a welcome if small step against instruction creep.Dejvid (talk) 11:39, 27 January 2009 (UTC)

70 × 90 cm can be interpreted as seventy times 90 cm, e.g. something composed by 70 pieces, each 90 cm wide and of unspecified height, placed side-by-side. -- Army1987 – Deeds, not words. 12:09, 27 January 2009 (UTC)

Lets look at an example article such as Mona Lisa. It doesn't repeat the unit and therefore breaks the guideline. I don't think it is ambiguous. Does anyone? Lightmouse (talk) 12:24, 27 January 2009 (UTC)
I agree with LM here, the wording isn't necessary. In cases of ambiguity (such as a scenario suggested by Army1987), of course the extra units may be used, but in the vast majority of cases, the unit is implied and is not a requirement.—MDCollins 12:33, 27 January 2009 (UTC)
(edit conflict)And I propose to edit that so it's in English: "...values each number..."? To my way of thinking, clarity trumps everything, especially in an encyclopedia. Most of the "rules" in the MoS have been hashed out and thought through by people with experience in this sort of thing, and we mess with it at our peril. I like the tidiness of the recommended form, and it leaves no doubt whether the writer forgot the first unit or not. And I hope you will forgive an observation that might be somewhat insulting, dear Lightmouse: It's hard to make a case for changing the MoS when you yourself display so little proficiency in matters typographical. All I'm saying with that is let the style guys and gals do their thing if you're not going to study the matter yourself. --Milkbreath (talk) 12:37, 27 January 2009 (UTC)
So by your reasoning, Milkbreath, should we discount your opinion because of your unwarranted personal attack on Lightmouse? — Bellhalla (talk) 13:01, 27 January 2009 (UTC)
(ec) "70 x 90 cm" is correct, idiomatic English, while "70 cm x 90 cm" is correct, pedantic English. In the long run, the pedants always win, so why bother fighting against windmills? The problem is that "70 x 90 cm" looks like a mathematical formula (an incorrect one), when it is really an abbreviation for a natural language expression. I would support adding the qualification "in technical contexts" (and fixing the grammar mistake in the rule). --Hans Adler (talk) 12:44, 27 January 2009 (UTC)
But this is an encyclopedia and should use pedantic English, not idiomatic English. There is a prohibition against contractions such as it's or doesn't, which are definitely no more incorrect than 70 x 90 cm is (I've seen them used in university-level textbooks), and the uncontracted forms can be very awkward in some sentences (such as negative questions). I think this is a similar issue. -- Army1987 – Deeds, not words. 18:15, 27 January 2009 (UTC)
No, this is an encyclopedia; it should be readable, accurate, and clear. Pedantry interferes with two of those, and may inhibit the third. Septentrionalis PMAnderson 01:18, 28 January 2009 (UTC)

Milkbreath said "you yourself display so little proficiency in matters typographical". I am always seeking to improve but sweeping criticism isn't something that I can work with. Can you provide an example of a typographical error that I made? Lightmouse (talk) 12:51, 27 January 2009 (UTC)

Sorry, again. I was only trying to make the point that we shouldn't fiddle with things we don't understand. We wouldn't monkey with the circuitry down at the hydroelectric plant, at least partly because it would probably kill us. And although we face no real danger to ourselves in monkeying with typographical conventions, we are no more qualified to do that than the other thing. To answer your perfectly reasonable and courteous question, not only is "i.e." Latin and therefore takes italics, it must be set off with commas. Also, it's "two-dimensional" and "three-dimensional". People get very touchy about being corrected this way, but that's what we're talking about here, fine points of typography. --Milkbreath (talk) 13:28, 27 January 2009 (UTC)
(edit conflict) It is a mathematical formula. And mathematical formulas are abbreviation for natural language expressions. For example the mathematical formula ∇ · B = 0 is an abbreviation for the natural language expression "The divergence of the magnetic field is zero", and is an abbreviation for the natural language expression "the curl of the magnetic field is the sum of the the electric current density multiplied by the vacuum permeability and the time derivative of the electric field divided by the square of the speed of light". And you wouldn't omit the 1/c2 on the grounds that the formula would be unambiguous anyway. How is this particular example being discussed special? -- Army1987 – Deeds, not words. 13:06, 27 January 2009 (UTC)
Mathematical formulas are written in a highly formalised language that is (incompletely) optimised for aspects such as unique readability. Not too surprisingly, this formalised language influences the much less formal spoken English in some areas, and that's why we say things like "seventy times ninety centimetres", which is usually written as "70 x 90 cm". It's like many examples of French words that are used in English, often with a meaning that is slightly different from the original French meaning. The particular example (I suppose you mean Mona Lisa) is not special, it's just one in an art context, so that the natural language context dominates over the technical context. "77 x 53 cm" is more correct here. On the other hand, "77 cm x 53 cm" is more correct for the dimensions of a solar panel. --Hans Adler (talk) 13:25, 27 January 2009 (UTC)
The article Heterosexuality mentions "sexual relations between male and female individuals". This could be interpreted as meaning: individuals who are male and female, such as hermaphrodites. So would you advocate a style rule mandating that this construction be changed to "sexual relations between male individuals and female individuals"? But that could possibly be misinterpreted as meaning: "sexual relations between male individuals and sexual relations between female individuals". Trying to avoid all potential ambiguity is not only doomed to fail, but also leads to unreadability: instead of a potentially incorrect meaning, none get across to the reader. By the way, if you use natural units you would omit the 1/c2. 199.3.224.3 (talk) 10:44, 29 January 2009 (UTC)

I was uneasy about the insistence on the repetition from the start. The guideline should be changed to allow what is almost always an unnecessary repetition to be dropped. Tony (talk) 14:01, 27 January 2009 (UTC)

Would it not be a much clearer solution to require either 70 by 90 cm (English, no repetition) or 70 cm x 90 cm (formula, each number a unit). −Woodstone (talk) 18:20, 27 January 2009 (UTC)
Yes. (Though I guess that by should be surrounded by hyphens not spaces? I'm not sure about that, though...) -- Army1987 – Deeds, not words. 20:01, 27 January 2009 (UTC)
Either would be a clear rule; both would be bad advice, at least some of the time. That's why we shouldn't give either. Septentrionalis PMAnderson 01:18, 28 January 2009 (UTC)

Problem: "70 × 90 cm" could be mistaken for 6300 cm, whereas in fact it's 6300 cm2. In some contexts that is crucial. Michael Hardy (talk) 20:20, 27 January 2009 (UTC)

  • I hate to go against two valued Wikifriends, but I agree with Lightmouse. For highly, highly technical or mathematical articles, the extra discipline advocated by Army1987 is fine. But writing "70 × 90 cm" is more natural and fluid and confuses no one in the normal contexts one would expect to find the expression. I’d also bet $10 that the Associated Press does it this way. Their manual of style is followed throughout the English-speaking world and is what our minds expect. It’s all for not anyway; MOSNUM is locked down tighter than Fort Knox. Greg L (talk) 00:47, 28 January 2009 (UTC)
  • A slighly outdated version of the Chicago Manual of Style (14th ed.) does not mention the issue as such, but in paragraphs devoted to other numerical matters, mentions "three-by-five-inch index cards" (¶ 8.12) under nonscientific usage, and "26 mm × 45 mm' under abbreviations. The Associated Press Style Manual is arranged alphabetically. and I can't think of a word to look up that would lead me to a relevant example or rule. --Gerry Ashton (talk) 01:07, 28 January 2009 (UTC)
The Sixth Trade Edition of the AP Stylebook (1996) addresses this question, albeit inadequately, under "dimensions". It doesn't seem to acknowledge the form with the "times" symbol, it being a newspaper guide that has only standard characters to work with for the most part. One example that is germaine here is "The rug is 9 feet by 12 feet, the 9-by-12 rug." (I own two editions of it.) --Milkbreath (talk) 12:54, 28 January 2009 (UTC)

This would be a perfect example for giving advice: When giving the dimensions of an object, "70 × 90 cm" is more natural and idiomatic; in some contexts, however, it may be ambiguous, in which case use "70 cm × 90 cm". This is what rational editors would do if we were silent; can we either say something like this, or leave the point alone?

If we can agree, we can use {{editprotected}}. Septentrionalis PMAnderson 01:15, 28 January 2009 (UTC)

But what's wrong with Woodstone's proposal? It is not a mathematical formula, but unlike 70 × 90 cm it doesn't pretend to be one. -- Army1987 – Deeds, not words. 02:18, 28 January 2009 (UTC)

If you want to ban this popular format, you have to tell us that you think it is confusing in real articles. Please look at Mona Lisa and tell us if you think you are confused by how it describes its dimensions. Seriously. Lightmouse (talk) 11:58, 28 January 2009 (UTC)

According to that logic, we shouldn't ban contractions such as aren't either, since they can't ever be the least bit confusing or ambiguous, in any context that even the most anal-retentive pedant could even think of. -- Army1987 – Deeds, not words. 12:31, 28 January 2009 (UTC)
I agree. Danger of confusion is an overused and often invalid argument by prescriptivists. This can hardly be the standard we have to meet before making a prescription. I think "77 x 53 cm" is OK, and possibly a bit more idiomatic in the Mona Lisa context than "77 cm x 53 cm". I like "77 by 53 cm", but I think it wouldn't work in the Mona Lisa template.
At this stage in the discussion I am leaning towards leaving the rule essentially as it is, but fixing the grammar and proposing the "77 by 53 cm" style as an alternative. I think that's a good compromise between uniformity and freedom and likely to minimise the back and forth between equivalent formulations. --Hans Adler (talk) 12:48, 28 January 2009 (UTC)
Every extra rule means the others are less likely to be followed. Are people really claiming that relying on editors' common sense will be so disastrous that this rule is needed?Dejvid (talk) 16:22, 28 January 2009 (UTC)

Question: Is it actually true that "70 × 90 cm" is "idiomatic" as has been claimed above? Is it common in publications? In my anecdotal experience, while "70 cm × 90 cm" and "70-by-90" (with no units) are common in everyday speech, "70 × 90 cm" is not. Shreevatsa (talk) 17:19, 28 January 2009 (UTC)

It is not uncommon in print. Some occurrences in books or journals: [1],[2],[3]. 88.234.217.196 (talk) 11:03, 29 January 2009 (UTC)
To me "70 by 90 cm" (What's with the hyphens?) or "70 cm × 90 cm" dependant on context seems a decent compromise. The "by" works best in prose (as opposed to the cold multiplication sign), it is a word so is clearly covered by the idiom argument and cannot, even in isolation, lead to any ambiguity. The multiplication sign, on the other hand, might be better in tables, captions, infoboxes and the like at which a reader might just take a fleeting glance. With the mathematical sysmbol, the expression is more of a mathematical entity and so might be expected (at least by some) to conform to rigid mathematical rules. So I'm proposing softening the rule to allow ommission of the extra unit names/symbols/abbreviations where we use "by". JIMp talk·cont 19:51, 29 January 2009 (UTC)
Putting away my personal distaste for the clunky "90 cm × 70 cm × 45 cm", I can't see the point of insisting on either that or the more streamlined and easier-to-read "90 × 70 × 45 cm". MoS, I believe, should recommend either, and editors, when they see the choice laid out, might come to their own conclusion. Tony (talk) 07:48, 31 January 2009 (UTC)
50 × 50 cm will always mean 2500 cm, so if you mean 50 cm × 50 cm, then write 50 cm × 50 cm. Even in prose it should appear as "A 50 centimeters by 50 centimeters area". If you're giving a technical information, make sure that what you're giving is technically correct. "Knowing what is meant" is not an excuse for sloppiness. Headbomb {ταλκκοντριβς – WP Physics} 07:07, 4 February 2009 (UTC)
I agree with the part about the symbol ×, but not with that about prose – "by" is a preposition, not a mathematical operator, so "50-by-50 centimetres" is no worse than, for example, "ranging from 50 to 70 centimetres", "in two or three hours", "We have 5-, 10-, and 15-euros phone cards", etc. --80.104.231.233 (talk) (formerly known as Army1987) 10:47, 4 February 2009 (UTC)

Attack of the incorrect date format

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)

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)

Both 3 February 2009 and February 3, 2009, are normal, Toddy. Septentrionalis PMAnderson 14:31, 3 February 2009 (UTC)
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)
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)

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)

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

Birth date - tag to show age

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. --132 18:29, 3 February 2009 (UTC)

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! --132 18:42, 3 February 2009 (UTC)
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)

Removal of metric units because they 'make things less legible'

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)

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

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

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)

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

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)

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)

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

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)

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)

Admin change to MOSNUM

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

 DoneCompleted as non-controversial and necessarily informational updates. --MASEM 17:32, 10 February 2009 (UTC)
  • 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)

Commas after year in dates

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

How would a date-fixing bot address this sentence? "The band announced that the concert on February 10th 2009 was to be their last." — Hex (❝?!❞) 23:05, 10 February 2009 (UTC)
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)
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. — Hex (❝?!❞) 16:28, 11 February 2009 (UTC)
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 Hex. - Nunh-huh 16:41, 11 February 2009 (UTC)
"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? — Hex (❝?!❞) 16:45, 11 February 2009 (UTC)
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)
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. — Hex (❝?!❞) 17:17, 11 February 2009 (UTC)
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)
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. — Hex (❝?!❞) 17:48, 11 February 2009 (UTC)
[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)
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. — Hex (❝?!❞) 18:45, 11 February 2009 (UTC)
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)
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)
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)
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)
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)
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)
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)

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)

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)
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)
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)
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)
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)
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)
Is one doing so now? (Not that this section is discussing date delinking.) Septentrionalis PMAnderson 03:56, 13 February 2009 (UTC)
As I suspect you well know :) , they are on temporary hold. -Nunh-huh 03:59, 13 February 2009 (UTC)
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)
Well, yes. Maybe. - Nunh-huh 04:06, 13 February 2009 (UTC)
Back on track: The style guides clearly show that it's standard to include the comma after the year when a date is expressed as month day, year, as in "His birth on Sept. 9, 1999, was celebrated internationally." Now, how do we add this to the manual of style? - BlackberryHacks (talk) 23:02, 13 February 2009 (UTC)
Procedurally, we would just propose the text change (under section 2.4 "Dates" with the other bullet-point items, I presume) and ask for feedback, then (since the page is currently protected) we ask an admin to make the change. I'd suggest we use a wording that's more of a suggestion than a requirement ("should" or "may (in accordance with best practices)" instead of "must") and try to phrase it in a way that will satisfy as many people as possible. --UC_Bill (talk) 00:14, 14 February 2009 (UTC)

I'm working on a {{val}}-like template

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)

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

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)
Done. For example, now {{thinspace|J.|R.|R.}} Tolkien displays J. R. R. Tolkien. --A. di M. (talk) 21:23, 7 February 2009 (UTC)
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)

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−23 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−23, {{val}} will generate 1.452800(25)×10−23.

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)

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)

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)
  • That was a half-day-long bug due to unclosed <spans>. It was quickly fixed and {{val}} is now bug-free. That little incident lead me to quickly make this Val sandbox to check for a wide variety of template behavior. If you get two error flags in the top section of the page, append ?action=purge as a suffix to the end of the URL and hit [enter]. This occurs when the server that fed the request has math settings that can only handle up to 12 digits. If you purge/refresh and the error flags go away, then your request was served by a 14-digit-capable server. Eventually, as they replace old servers in Wikipedia’s server farm, the percentage of time that this happens will go to zero (a matter of weeks). Then, only the 15-digit numbers on the page should produce error flags.

    If you want to speed up the purge iteration time, you can try using Val microsandbox Greg L (talk) 03:36, 18 February 2009 (UTC)

Free form way of specifying dates

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:

Start-date & End-date usage (colors for emphasis only):
Sample below displays 7 December 1941 (1941-12-07), and microformat date: 1941-12-07TZ

{{start-date|7 December 1941}}

Sample below demonstrating how days, timezones and hours, minutes and seconds can be shown. (Order often not important). Displays 5:43PM HST, December 7, 1941 (1941-12-08UTC03:43), and microformat date (corrected for UTC): 1941-12-08T03:43Z

{{start-date|5:43PM HST, December 7, 1941}}

Sample below demonstrating use of links with dates. Displays links to day of month and year pages. December 7, 1941 (1941-12-07), and microformat date: 1941-12-07Z

{{start-date|December 7, 1941|[[December 7]], [[1941]]}}

Sample below demonstrating use of Julian calendar dates. Displays 9 June [O.S. 30 May] 1672 (1692-06-09), and microformat date: 1692-06-09Z

{{start-date|9 June 1692|{{OldStyleDate|9 June|1672|30 May}} }}

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)

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

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

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

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)

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

George Washington's family bible recorded his birth as the "11th Day of February 1731 / 2".[4] 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)

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)
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)
  • 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)
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)
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)
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:
wikitext display microformat
old {{Start date|1963|11|22|19|00||-07:00}} 19:00, November 22, 1963 (-07:00) (1963-11-22T19:00-07:00) (1963-11-22T19:00-07:00)
new {{start-date|November 22, 1963 1pm CST}} November 22, 1963 1pm CST (1963-11-22UTC19) (1963-11-22 T19Z)
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)
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)
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)
{{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)

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)

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)
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)
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)
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 [[5]]. {{Start date}} 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)
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)
To date, there have been no arguments opposing the moratorium. -J JMesserly (talk) 23:24, 14 February 2009 (UTC)
…apart from all those in my responses to J JMesserly's misleading FUD on WP:BOTREQ. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:02, 15 February 2009 (UTC)

You oppose the moratorium? The argument at BOTREQ was that the bot run was uncontroversial. Clearly that is not the case. What is your argument in favor of the old {{start date}}? I think it is fair to represent opinion here that it needlessly complicates wikitext representation of dates. Your response? -J JMesserly (talk) 23:25, 15 February 2009 (UTC)

My response is already at WP:BOTREQ. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:27, 15 February 2009 (UTC)

(Quote Copied from BOTREQ by J JMesserly)::There is no controversy. Please avoid unnecessary drama. There is no obscurity and the template is not "error prone"; unlike the supposed alternative. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:06, 13 February 2009 (UTC)

If this is an out of context quote, then perhaps Pigsonthewing could add the additional context. How it is accurate on the BOTREQ page to represent this issue as one with no controversy (when multiple contributors here have stated the old template is unnecessarily complex), or asserting that the old template is not obscure or error prone without countering the arguments presented here? -J JMesserly (talk) 21:40, 17 February 2009 (UTC)

{val} wording update

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

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.
{{editprotected}}
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)

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)

←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×102 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×102 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, ..."? :-)
  1. ^ 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". <rant>Sounds like the frog eaters are trying to impose the typography of their *cough* lan... *cough* ...guage *cough* to the whole worldthose at BIPM were more familiar with French than English typography, and maybe they didn't just realize that the latter has different rules. IIRC, they used to only allow the comma as a decimal point regardless of language, before they realizing that in English everyone used the period and eventually allowing it.</rant>

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

    The wording immediately below the {{editprotected}} tag above (same instruction as now w.r.t. placement of gaps, but without the "must never" normative wording, and with thin space characters replaced with {{gaps}} to work around the problem Shakescene has found) would be OK, I guess. --A. di M. (talk) 00:24, 15 February 2009 (UTC)


    I’ve taken the liberty of borrowing heavily from A. di M.’s proposed wording (particularly the “it is customary” language) and added more detailed guidance in several places for the benefit of less experienced editors. The two bullet points below would replace the last bullet point in Decimal points. It also clarifies a distinguishing point about 12 digits to the right of the decimal point v.s. 12 digits total in the signficand. Per Jimp’s suggestion below, I’ve also revised ‘manual’ delimiting to the use of {{gaps}}, which I see is now in article-space.

    • Numbers with more than four digits after the decimal point (high-precision numbers) can be separated (delimited) into groups using the {{val}} template, which uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g. {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). Due to server-related issues, {{val}} can reliably handle no more than a total of 12 significant digits in the significand. For significands greater than this, editors should delimit high-precision values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|45}} → 1.23456789012345.
    • 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 (the character comprising three periods), being arbitrary, should be a multiple of five (or groups of three if three-digit groups are used).

    If someone finds a mistake or has some other improvement, please consider the above two paragraphs between the rules as a group-product worksheet to which anyone may contribute. Just leave a short note below stating your edit summary. Greg L (talk) 01:06, 18 February 2009 (UTC)

    "47° S" or "47°S"?

    In a sentence such as

    The latitude of New Zealand, from approximately 34 to 47° S, corresponds closely to that of Italy in the Northern Hemisphere.

    should there be any space between the degree and the S for south? MOS:NUM isn't consistent with itself: the section "Non-breaking spaces" uses one in "5° 24′ 21.12″ N" uses one; the 'Quick "how-to"' in "Geographical coordinate doesn't, the output of the templates mentioned there doesn't, the example about Oslo does.

    Does that mean that both formats are acceptable? (FWIW, I did use a space in that sentence,[6] as I think it is more legible with the space.)

    (BTW, sometimes the double prime ″ sign is replaced by a quotation mark " or by two prime signs ′′. Should that be fixed?)

    A. di M. (talk) 10:11, 15 February 2009 (UTC)

    The usage should be consistent with the standard for degrees Celsius or Fahrenheit, e.g. "The temperature was 36°C at 36°S latitude". Since there's no essential difference between the two usages, and Wikipedia specifies no space in degrees of temperature, it should probably be the same for degrees of geographical coordinates. Checking the Canadian government style manual, I see that's their standard. It's probably best not to use quotation marks for the double prime, although those of us with smudged reading glasses have trouble seeing the difference, e.g. "5°24′21.12″N".RockyMtnGuy (talk) 18:39, 15 February 2009 (UTC)
    Why do you say there's no essential difference? Temperature are not angles, after all. BTW, there often is a space between the number and the symbol in temperature, e.g., “36 °C”, so there is no consistence between the two, anyway (it would have to be “47 °S”, but I haven't seen anybody put a space before the symbol for the degree of arc). Anyway, in “36 °C” (or “36°C”), the “°C” is the symbol for the unit of measurement, whereas in “47°S” (or “47° S”) the “°” is the symbol, whereas the “S” just specifies what is being measured. --A. di M. (talk) 19:45, 15 February 2009 (UTC)
    Hum... Our article "Geographic coordinate system" not only doesn't address this issue, but is also inconsistent with itself. And "Degree symbol" only says that there is no space before the sign for degrees of arc, but some people use a space and some don't for degrees Celsius and degrees Fahrenheit. --A. di M. (talk) 19:53, 15 February 2009 (UTC)

    Within the US, the way to symbolize "degree Celsius" is officially decided. The Congress authorized the Secretary of Commerce to interpret the International System of Units (SI), and the Secretary of Commerce recognized the National Institute of Standards and Technology's Special Publication 330 as one of two documents interpreting SI for the US. That publication states

    The numerical value always precedes the unit, and a space is always used to separate the unit from the number. Thus the value of the quantity is the product of the number and the unit, the space being regarded as a multiplication sign (just as a space between units implies multiplication). The only exceptions to this rule are for the unit symbols for degree, minute, and second for plane angle, °, ′, and ″, respectively, for which no space is left between the numerical value and the unit symbol.

    This rule means that the symbol °C for the degree Celsius is preceded by a space when one expresses values of Celsius temperature t.

    I believe the interpretation is the same in other countries, and that it would be reasonable to follow the same style for °F. --Gerry Ashton (talk) 20:20, 15 February 2009 (UTC)

    The Canadian government style manual differs from the US government style on this point (as well as a number of others). The US government would say 10° N. (space after ° and a period after N) and 10 °C (space before °, but no period after C) while the Canadian government would say 10°N (no space, no period) and 10°C (no space, no period). It would be interesting to see how the other Commonwealth countries approach this matter.RockyMtnGuy (talk) 23:59, 15 February 2009 (UTC)
    I don't know what manuals RockyMtnGuy is referring to. The manual I quoted indicates that when writing an angle, it would be 10°. It does not address what to do when that is combined with a direction. Unfortunately, the US government does not speak with one voice. A variety of styles can be found in various US government publications. Special Publication 330 is authoritative with respect to SI, but not necessarily with respect to other units. --Gerry Ashton (talk) 00:59, 16 February 2009 (UTC)
    Sorry, I was looking at the US Government Printing Office Style Manual; and the The Canadian Style by Dundum Press in co-operation with Public Works and Government Services Canada. They differ on a variety of issues, including this one. The US NIST Special Publication 330 seems to be derived from the USGPO style manual, but is not as extensive. Other sources vary. I think most authorities view the difference as being inconsequential since it's unambiguous either way. The Wikipedia coord template gives 57°18′22″N 4°27′32″W / 57.30611°N 4.45889°W / 57.30611; -4.45889 which seems to be as good as anything.RockyMtnGuy (talk) 18:30, 16 February 2009 (UTC)
    Huh? In chapter 9, paragraph 50, it writes "10° N. 25° S." with the space after the ° sign... --A. di M. (talk) 19:38, 16 February 2009 (UTC)
    It would appear that A. di M. correctly quoted the U.S. Government Style Manual and that RockyMtnGuy's summary made at 23:59, 15 February 2009 (UTC) is incorrect with respect to that manual. It would also appear that as far as angles measured in degrees are concerned, the U.S. Government Style Manual and Special Publication 330 are not inconsistent. --Gerry Ashton (talk) 19:46, 16 February 2009 (UTC)
    Oops! Sorry, I wasn't paying close enough attention. Yes, the USGPOSM uses 10° N. (space after °) but 10 °C (space before °). A subtle point. It's not an issue if you don't use spaces, since the ° symbol serves in lieu of a space, so it slipped past me. I corrected my comments above to correspond.RockyMtnGuy (talk) 22:20, 16 February 2009 (UTC)

    Why is this page fully protected?

    There was no edit warring at the time of protection, the only reason given what "Oh noes, what about the vandals!" as if they would not be reverted in less than 5.39124(27)×10−44 s. (turns out there was edit warring ... back in november!) It's been nearly 3 months now. It's ridiculous that we have to ask permission to move a comma around. This is not kindergarten! Let experienced editors freely edit the page by default. If there's actually a problem, then lock the MOSNUM down, but don't lock it down for something silly like fear of vandals. The biggest level of protectiion that this pages warrants by default is edit=autoconfirmed and move=sysop. Headbomb {ταλκκοντριβς – WP Physics} 11:25, 15 February 2009 (UTC)

    Wikipedia:Requests for arbitration/Date delinking. —Locke Cole • t • c 11:38, 15 February 2009 (UTC)
    Ah. But if that is the problem, couldn't one just merge the subsubsection "Linking and autoformatting of dates" into MOS:LINK#Chronological items? Surely it is silly to lock the whole MOS:NUM because of concerns about one three-sentence subsubsection. (BTW, the last link in the "See also" should be updated to point to Wikipedia:Manual of Style (links)#Chronological items, now that WP:CONTEXT#Dates was merged there.) --A. di M. (talk) 14:16, 15 February 2009 (UTC)
    Trying to speak unbiasedly here, but given the arbcom case has brought up concerns on general behavior issues here, even if just the problem is with date delinking, it is probably best to keep it fully protected until at least some indication which way ArbCom is going to take the case (if it's just about bot behavior, then I don't see the need to be protected, but there's so much its impossible to tell which way). Editprotected requests work on non-controversial changes, and I'm watching this (greg l has dropped a message when one was needed as well), so other sections that have to be updated can be. --MASEM 15:10, 15 February 2009 (UTC)
    • The ArbCom is a fiasco-and-a-half that won’t be ruling on much, if any actual substance; they seem to be primarily interested in addressing who’s been sticking their tongue out the farthest. I’m all for working out guidelines here on this talk page with Masem and others keeping a watchful eye over editor conduct, and posting work product to MOSNUM when something is ready for prime time. If that proves to be successful, maybe we can dip our toes in unlocking MOSNUM. If it doesn’t prove successful, maybe we can take a long hard look at why we can no longer make progress on anything.

      Right now, there are some areas of MOSNUM, such as the entire Section 3 (Numbers), that needs to be harmonized and streamlined so there is less duplication and editors can find information where one would reasonably expect it. I see no need to have complete paralysis here while ArbCom tries to decide if their processes suffer from a serious hiccough, or are galactically dysfunctional.

      BTW, some time ago, I saw a post on an admin hangout here on en.Wikipedia from an admin from the Persian (Iranian) Wikipedia. He had problems with editors putting death-to-Israel flags and pictures of SCUD missiles on their user pages. These editors were also editing articles with a strong, POV-pushing, anti-Israel bent. He came to en.Wikipedia for guidance as to what to do. The advise from our admins was along the lines of “WTF? Get some help, here’s the Wikipedia principle you adhere to, and get tough.” It seems to me that circumstances here on en.Wikipedia can sometimes spiral out of control to the point that even admins here question whether they can do anything about it. Greg L (talk) 01:44, 18 February 2009 (UTC)

    Most talk pages have links to all the archive pages in the archivebox. This one currently does not. Apparently there was an effort to keep DA discussions in separate archives? Sometime before Dec 7, >3000 edits ago, someone added the (mislabelled) links "118 (D12)" and "118 (D13)" and since then the archive index is untouched. The missing archive links 113-115, 119, 120 are basically all DA discussions.

    So what is the scheme and what can be done to fix it? I can update the index easily enough, but is it also desired to strip out the non-DA threads into a separate archive? Franamax (talk) 18:17, 16 February 2009 (UTC)

    No, just label them as D something and provide separate links to them in the D series - the third section of the existing box. That would be very helpful. Septentrionalis PMAnderson 17:16, 21 February 2009 (UTC)

    "John is thirteen years old" or "John is 13 years old" ?

    When this sentence occurs mid-paragraph and is the only occurrence in the article of a number which is the proper or preferred style? I can't seem to find a specific mention of this in the MoS. Also, is there an easy way to search the archives of all the MoS talk pages, and ONLY the MoS talk pages? -- OlEnglish (Talk) 19:19, 16 February 2009 (UTC)

    WP:MOS#Numbers as figures or words says "As a general rule, in the body of an article, single-digit whole numbers from zero to nine are spelled out in words; numbers greater than nine are commonly rendered in numerals, or may be rendered in words if they are expressed in one or two words (16 or sixteen, 84 or eighty‑four, 200 or two hundred, but 3.75, 544, 21 million)." There are some exceptions, but I don't think any of them apply to this case. --Gerry Ashton (talk) 19:30, 16 February 2009 (UTC)
    I see, I recall seeing that but I was wondering if there's a general rule when dealing specifically with references to someone's age, not birthdate, just age number; I wasn't sure if maybe there's a preference when referring to how old someone is to use numerals instead of words, because I've seen it in several GA-class articles where numbers are expressed in words throughout the entire article EXCEPT in sentences such as the one in the heading. -- OlEnglish (Talk) 21:33, 16 February 2009 (UTC)
    Some style manuals indicate that all ages should be in numerals, even if they are less than 10, e.g. "John is 9 years old. Jane is 7." The US and Canadian government style manuals both use this rule.RockyMtnGuy (talk) 22:29, 16 February 2009 (UTC)
    But the Wikipedia style manual doesn't it seems. So should it be updated to clarify this? -- OlEnglish (Talk) 22:43, 16 February 2009 (UTC)
    The whole section should be removed, or made into a discussion of alternatives. This is an effort to codify English usage, and as such foredoomed. Septentrionalis PMAnderson 00:20, 17 February 2009 (UTC)
    Absolutely. It's pointless to try and force usage in this fashion. — Hex (❝?!❞) 05:38, 17 February 2009 (UTC)
    Much of that is fine as useful guidance or hints, so long as it's clear that none of it's obligatory. There are just far too many variables to give any strong rules. In writing the lead for The Bronx, I wrote that, among New York's Five Boroughs, it was 4th in population, 4th in area and 3rd in density of population, not because it's my usual preferred style, but because this particular sentence seemed more readily readable that way. Someone else changed the ordinals to third and fourth, and I haven't yet tried to revert because it doesn't make that much difference to me. But there are other cases where I'd very much want to use "third" and others where I'd strongly prefer to write "3rd". Similarly the MOS's line about 19th-century versus nineteenth-century or 19th century vs nineteenth century (or as many of us would still write, Nineteenth Century) doesn't make much sense to me. Much better to trust the editors who are actually writing a specific article with some feeling for who their potential readers would be.
    But, although I have not the patience to dig up the relevant archive, my opinion is that about a fifth (20%) of the current MoS needs to be fairly directive, such as where certain machines or people (e.g. the colour-blind) can't read certain formats, or where there's a danger that something might be incomprehensible, ambiguous, misleading or defamatory to readers of a different background, another fifth should be strong advice, and the rest should be simple guidance. There should probably be at least two discrete documents. With those 384 policies that every editor is supposed to know and follow, the danger is that the most important ones will just get lost in the muddle of trivia. And uniformity for its own sake is neither desirable nor possible, because Wikipedia is very different from printed books. —— Shakescene (talk) 01:38, 18 February 2009 (UTC)

    OlEnglish, the link and excerpt given by Gerry Ashton seem to answer your question. You have freedom of numeral! Use tact, poise and reason. And please ignore the sniping from the peanut gallery. These poor unfortunates have nothing better to do :D --Goodmorningworld (talk) 01:15, 18 February 2009 (UTC)

    Thinspaces

    It's time to remove the bit about thin spaces. There was a discussion some time ago about the use of these and it was found that they were problematic because they don't render properly on all browsers (including the version of Internet Explorer I'm using right now). Greg's gaps (used by {{val}} and {{gaps}}) came to the rescue with the added advantages (or what some, including me, might consider essential features) that they are already non-breaking and vanish on copy & paste (allowing numbers to be directly input into spreadsheets or other calculational applications). JIMp talk·cont 23:37, 17 February 2009 (UTC)

    • Definitely. It’s much easier that way for editors too. Last I had looked, {{gaps}} was in user-space. I see it is now in prime time. I’ve revised the wording to reflect this.

      BTW, I completely douched 3⁄4 of this page by accidentally coding {[tl|gaps}} (with a curly bracket followed by a square bracket) in the first paragraph of this post.[7] Man-oh-man, Wikipedia’s server engine doesn’t like that; it simply wouldn’t show the entire last three-quarters of the page, including my post with the goofed-up brackets—not even in edit view. I had to go to a pre-edit, historical page, grab all that pre-goof code, and completely replace the contents here. Maybe {[tl|gaps}} is a fluke, or maybe this is a purposeful code I didn’t know about that is intended to mess with spacetime so you can go back into history and make it so Hitler had never been born. Greg L (talk) 01:11, 18 February 2009 (UTC)

    {{editprotected}} The text in question is under Large numbers and is as follows.

    In large numbers (i.e., in numbers greater than or equal to 10,000), commas are generally used to break the sequence every three places left of the decimal point, e.g. "8,274,527". In scientific context, thin spaces can also be used (but using {{nowrap}} to prevent line-breaking within numbers), e.g. "8 274 527" ({{nowrap|8&thinsp;274&thinsp;527}}, or using the thin space character instead of its HTML entity). Consistency within an article is desirable as always.

    I'm proposing that the text be changed to the following,

    In large numbers (i.e., in numbers greater than or equal to 10,000), commas are generally used to break the sequence every three places left of the decimal point, e.g. "8,274,527". In scientific and mathematical contexts, {{gaps}} may be used to insert thin spaces, e.g. use {{gaps|8|274|527}} to produce "8274527" (note: the thin space character and its HTML entity, &thinsp;, do not render correctly on some browsers). Consistency within an article is desirable as always.

    JIMp talk·cont 07:33, 26 February 2009 (UTC)

     Done, thanks. I think it's probably time that the protection level of this page was reduced. Thoughts? Martinmsgj 10:35, 26 February 2009 (UTC)

    en-gb / en-us

    Paragraph 2 seems to be a valid argument for having at least two English Wikipedia versions. 84.9.125.170 (talk) 23:09, 22 February 2009 (UTC)

    As an American, I can deal with center, program, and defense being spelled centre, programme, and defence in neutral articles. And I suspect that most people who learned English in the British Empire/Commonwealth will take an equally open minded approach to neutral articles. In my opinion, two separate English wikipedia versions would be a hassle for editors, admins, and readers. —MJCdetroit (yak) 04:04, 23 February 2009 (UTC)
    Although someone like Churchill once praised the friendship of "two peoples, divided by a common language", the differences can be (and often are) wildly exaggerated. They're no greater than the differences of either "dialect" (or Indian, Malaysian, African, Australian, Canadian or other variants) from the acceptable English prose of the 18th century. And since I crossed the Atlantic between Britain and the U.S. at ages 6, 8 and 11, and thus had to deal as a schoolchild with the differences as I was learning to write English, I'm fully aware of the many ways that usage, punctuation, spelling, plurals, vocabulary and meaning do differ, because what was compulsory in one school was incorrect in another (e.g. putting punctuation inside or outside quotation marks/inverted commas or brackets/parentheses, the meaning of a "ton" or "corn", the names of "Z" and "0"). There's certainly not the slightest need to create two encyclop(a)edias to accommodate the easily-managed differences, so long as editors are aware of possible obscurities or differences in meaning, not only between those whose mother-tongue is English, but for those whose mother tongue is not. Books, songs, magazines, newspapers, letters and documents have crossed the Atlantic for centuries without needing translation. Few Americans would refuse to buy or borrow a book printed according to Oxford's or Cambridge's house style, and few Britons have any difficulty reading the original Time magazine or New York Times. If someone wants to develop some template or autoformatting as a Wikipedia equivalent of what happens when a U.S. publisher prints its own edition of a U.K. book, and vice-versa (e.g. the Oxford University Press, U.S.A.), so as to reduce the possible delays and confusion that an unfamiliar format may cause, more power to her or him, although I think there are just too many subtleties to make this workable even if the enormous technical difficulties were overcome. English is not, I earnestly hope, becoming a uniform, homogenised/homogenized language, but, print, song, the telegraph, telephone, gramophones/phonographs, film/movies, radio/wireless, television, the Internet and software-driven media have made English-speakers so familiar with different usages that they often (and sometimes unconsciously) use an overseas version of English (especially slang) to make a point or distinction that might be erased by auto-formatting (or, not to put too fine a point on it, you don't want to throw the baby out with the bath-water.) —— Shakescene (talk) 05:58, 23 February 2009 (UTC)

    An ARBCOM-proposed RfC on date linking/autoformatting

    As many of those who keep tabs here know, there has been an ongoing arbitration case on (de)linking chronological items. One of the clerks has started the framework for perhaps the most intricate RfC on the issue yet, which includes date autoformatting and other definitions of said feature. Please see User:Ryan Postlethwaite/Date linking RfC for the draft of the RfC and discuss its scope and questions at its corresponding discussion page. Opinions on the formatting of such an RfC are welcome here. Dabomb87 (talk) 23:43, 23 February 2009 (UTC)

    Commas after year in dates

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

    How would a date-fixing bot address this sentence? "The band announced that the concert on February 10th 2009 was to be their last." — Hex (❝?!❞) 23:05, 10 February 2009 (UTC)
    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)
    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. — Hex (❝?!❞) 16:28, 11 February 2009 (UTC)
    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 Hex. - Nunh-huh 16:41, 11 February 2009 (UTC)
    "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? — Hex (❝?!❞) 16:45, 11 February 2009 (UTC)
    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)
    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. — Hex (❝?!❞) 17:17, 11 February 2009 (UTC)
    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)
    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. — Hex (❝?!❞) 17:48, 11 February 2009 (UTC)
    [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)
    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. — Hex (❝?!❞) 18:45, 11 February 2009 (UTC)
    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)
    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)
    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)
    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)
    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)
    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)
    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)

    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)

    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)
    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)
    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)
    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)
    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)
    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)
    Is one doing so now? (Not that this section is discussing date delinking.) Septentrionalis PMAnderson 03:56, 13 February 2009 (UTC)
    As I suspect you well know :) , they are on temporary hold. -Nunh-huh 03:59, 13 February 2009 (UTC)
    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)
    Well, yes. Maybe. - Nunh-huh 04:06, 13 February 2009 (UTC)
    Back on track: The style guides clearly show that it's standard to include the comma after the year when a date is expressed as month day, year, as in "His birth on Sept. 9, 1999, was celebrated internationally." Now, how do we add this to the manual of style? - BlackberryHacks (talk) 23:02, 13 February 2009 (UTC)
    Procedurally, we would just propose the text change (under section 2.4 "Dates" with the other bullet-point items, I presume) and ask for feedback, then (since the page is currently protected) we ask an admin to make the change. I'd suggest we use a wording that's more of a suggestion than a requirement ("should" or "may (in accordance with best practices)" instead of "must") and try to phrase it in a way that will satisfy as many people as possible. --UC_Bill (talk) 00:14, 14 February 2009 (UTC)
    Could you (or someone) do that? I'm a newbie and do not know how. Thanks. BlackberryHacks (talk) 01:02, 25 February 2009 (UTC)
    The date format February 25, 2009, normally has a comma after the year, as the Chicago Manual of Style and the AP stylebook recommend. Do we want to mention that this is a difference from the British format, and a minor reason not to autoformat? Septentrionalis PMAnderson 16:38, 25 February 2009 (UTC)
    I don't think it necessary to mention specific style books (what about MLA? New York Times ?, Eric Partridge, H.W. Fowler, etc., etc.) I think what should be indicated is why the formats may differ (one comma needed to separate day from year in MDY begging for another comma to close it so as to avoid breaking a sentence unnaturally, while adding one comma, or even two, in Day-Month-Year might cause that unnatural break in a different way). I'm the kind of editor who responds much more readily to plausible reasons for a conventional practice than to the simple brandishing of prescriptive rule-books. —— Shakescene (talk) 20:17, 25 February 2009 (UTC)
    We should ideally include both a reason and an authority; citing a style guide is evidence that a published grammarian has been convinced by the reason. Septentrionalis PMAnderson 18:46, 27 February 2009 (UTC)

    Meaning of "customary format"

    I have recently seen the argument put that the line in #Strong national ties to a topic that says

    "In certain subject areas the customary format may differ from the usual national one."

    means that WikiProjects are at liberty to adopt a particular format across the board, irrespective of national ties. For example, WikiProject Hats may adopt a convention of using US-style date formatting for all hat articles.

    I think this is a misunderstanding of what was intended here. I believe "customary format" means what people customarily do out there in the real world, not what Wikipedia editors in the subject area customarily do. Can I get a clarification on this point, both here and in the guideline text?

    Hesperian 04:52, 7 March 2009 (UTC)

    Edit request

    {{editprotected}} There was a protected edit request in the archive from 12 February, which I have just deactivated. Is this edit still needed? If so, please could you provide a clear and succinct instruction here, as there was a huge amount of text in that thread. Martinmsgj 10:18, 25 February 2009 (UTC)

    Most of what was needed to do was done. Now you should just replace {{nowrap|299&thinsp;792&thinsp;458}} and {{nowrap|149&thinsp;014&thinsp;769}} in the sentence starting with "Avoid overly precise values where they are unlikely to be stable or accurate" in the "Large numbers" section with {{gaps|299|792|458}} and {{gaps|149|014|769}} respectively (the instruction was changed but the examples weren't; this one should be uncontroversial). There is a similar example in the last bullet point of the section "Decimal points", but there is no consensus about the precise wording to use (although there is consensus about what it should say). I'd go with replacing that bullet point 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 {{gaps}} with 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).
    but let's wait for a while (e.g. 24 hours from now) in case someone sees some problem with the wording. --A. di M. (talk) 10:54, 26 February 2009 (UTC)
    (1) Is it possible to translate "Per ISO convention (observed by the NIST and the BIPM)" into something closer to the natural language that one would use in an oral explanation to a layman or laywoman? "Encyclopedic tone" is one thing; commercialese and pseudo-legalese such as "Per" is not.
    (2) Perhaps somewhere there might be room to explain that the reason that international (and Canadian) statistical, financial, scientific and mathematical sources often separate thousands and millions with spaces (rather than commas) is that French and Continental generally use periods/full stops (.) for this purpose and commas to separate units from decimal fractions. —— Shakescene (talk) 05:40, 28 February 2009 (UTC)
    (1) Maybe removing that phrase altogether, remaining with "... into groups of three; but it is customary not to ..."? (2) That should be added to the "Large numbers" section, not to "Decimal points". The digits to the right of the decimal point are separated with spaces because nobody ever separates them with anything else (even if the Wikipedia MoS used to recommend a format such as "3.141,159", I don't recall seeing any article actually using it). --A. di M. (talk) 10:53, 28 February 2009 (UTC)
    • I endorse what A. di M. has above between the horizontal rules. I understand the concern about technobabble, but this issue sometimes attracts the attention of technophiles and it is good to be specific so the guideline is fully self-explanatory whenever editors such as me, or A. di M., or someone else who is familiar with the history of this doesn’t happen to be available. For laymen, they just read “ISO, BIPM, and NIST” as “big-ass formal standards bodies of some sort”. Let’s get this one posted before it gets archived again please.

      The above text (between the rules), replaces the last bullet point in WP:MOSNUM#Decimal points.

      Alternatively, the wording I had in my last proposal (also archived) works for me. It is as follows:

    • Numbers with more than four digits after the decimal point (high-precision numbers) can be separated (delimited) into groups using the {{val}} template, which uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g. {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). Due to server-related issues, {{val}} can reliably handle no more than a total of 12 significant digits in the significand. For significands greater than this, editors should delimit high-precision values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|45}} → 1.23456789012345.
    • 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 (the character comprising three periods), being arbitrary, should be a multiple of five (or groups of three if three-digit groups are used).
    Either one; it doesn’t matter to me. When all of Wikipedia’s older servers have been replaced so {{val}} works consistently to 14 digits, I’ll let you know. Greg L (talk) 21:39, 3 March 2009 (UTC)
     Done --MASEM (t) 00:45, 4 March 2009 (UTC)

    {{editprotected}} You forgot fixing the examples. As I said above, “Now you should just replace {{nowrap|299&thinsp;792&thinsp;458}} and {{nowrap|149&thinsp;014&thinsp;769}} in the sentence starting with "Avoid overly precise values where they are unlikely to be stable or accurate" in the "Large numbers" section with {{gaps|299|792|458}} and {{gaps|149|014|769}} respectively (the instruction was changed but the examples weren't; this one should be uncontroversial).” --A. di M. (talk) 16:22, 6 March 2009 (UTC)

    • Well, I had certainly been confused. The specific wording we had long been discussing was for replacing the last paragraph of Decimal points, which now appears to be fine. But the 299 792…” number your are talking about is further up in Large numbers; two very different things. But now I understand what you are talking about. The section instructs editors to use {{gaps}} and then gives example numbers that weren’t really created with that template. I frankly think few people are going to discover that the example numbers in that paragraph were actually created using thinspaces (clearly, the ones that do detect this are going to be detail-oriented people like you). I don’t oppose what you are suggesting. To me, the whole numbers section needs to be harmonized and cleaned up once the lock-down ends. Greg L (talk) 06:32, 8 March 2009 (UTC)
    It was actually noticed by Shakescene, because they rendered weird in his browser (namely, if the number was found near the end of a line, the browser would display it on the previous line making it longer than the screen and requiring horizontal scrolling, instead than putting it at the start of the next line). I found the same quirk in my browser. Jimp found that they are displayed incorrectly by Internet Explorer, too. So, the danger is not that someone to which the thinspaces look right can somehow notice that they are actual characters; it is that they can look wrong to someone else. --A. di M. (talk) 10:00, 8 March 2009 (UTC)

    ← In order not to confuse any admin going to address this: both I and Greg agree that the point above still applies, namely

    Now you should just replace {{nowrap|299&thinsp;792&thinsp;458}} and {{nowrap|149&thinsp;014&thinsp;769}} in the sentence starting with "Avoid overly precise values where they are unlikely to be stable or accurate.

    --A. di M. (talk) 10:00, 8 March 2009 (UTC)

     Done. Note that it is much easier when asking for editrequests to list out the current line(s) in source and what you want changed instead of being descriptive about what needs change (beyond explaining why its needed); less work for the editing admin to work through. --MASEM (t) 12:41, 8 March 2009 (UTC)

    Edit request for "Scientific notation, engineering notation, and uncertainty" section typo

    {{editprotected}} Under the heading "Scientific notation, engineering notation, and uncertainty" appears the bullet:

    • When using either scientific or engineering notation in articles, consistency is preferred (e.g., do not write A 2.23×102 m region covered by 234.0×106 grains of sand).

    Since a region's measurement would be an area and not a length (and since the unit isn't the error/inconsistency being illustrated!), the first figure should be corrected to 2.23×102 m2. — Taper (talk) 11:39, 6 March 2009 (UTC)

    Done. Cheers. --MZMcBride (talk) 05:03, 8 March 2009 (UTC)

    NBSPs and compound numbers

    When writing the phrase "12 billion lightyears", which of the following is the best way to write it:

    • 12&nbsp;billion lightyears
    • 12 billion&nbsp;lightyears
    • 12&nbsp;billion&nbsp;lightyears
    • {{nowrap|12 billion lightyears}}

    This issue does not seem to be clearly addressed in the MoS. Regardless of the correct answer, I suggest adding a statement explicitly explaining how to deal with compound numbers. --Cryptic C62 · Talk 03:00, 28 February 2009 (UTC)

    • "12&nbsp;billion lightyears" is good. You don't need the nbsp with the spelt-out unit but it might be useful between the "12" and the "billion". JIMp talk·cont 10:40, 28 February 2009 (UTC)
      • I don't see why. The chief effect is that the line can't break after "12", but there is no real risk of confusion if a new line begins with "billion lightyears", unlike a line beginning with "m". On the other hand, long strings of unbreakable text tend to produce bad layout. Septentrionalis PMAnderson 18:03, 28 February 2009 (UTC)
    • I would push for "12&nbsp;billion lightyears". I feel that any potential problem with formatting is subordinate to the benefit of helping the semantics by ensuring there is a better flow with the unit always being associated directly with the number.  HWV258  22:30, 1 March 2009 (UTC)
      • That reasoning would similarly support non-breaking spaces after the; or indeed everywhere there is not an explicit punctuation mark, and consequent semantic break. I disagree with this proposal to revamp English punctuation back to the seventh century BC. Those pedants who support it should endeavor to get it endorsed by other writers of English, not use WP as a test-bed for NewSpeak. Septentrionalis PMAnderson 22:40, 1 March 2009 (UTC)
        • Heavens. Responses such as this are excellent in a permanent record of the bigger picture of the responder. Thanks. (Quite an amazing extension of an argument to link what should follow a number, and what should follow the.)  HWV258  22:52, 1 March 2009 (UTC)
          • Not at all. If the man, or 12 man-loads cannot break between lines, why should the green man? If that doesn't break, why should the man went? Spaces are where the string of characters is intended to break; truly professional publications hyphenate and break long words to make line-breaks more frequent, not less.
          • It is no longer professional, as it was in the seventeenth century, to adorn the end of a page with the first word on the new leaf, for the sake of smoothness; yet that makes more sense than HWV258's proposal. Septentrionalis PMAnderson 23:26, 1 March 2009 (UTC)
                • À propos de nothing significant here: I always understood that the reason the last word of a page was repeated on top of the next one by old printers, as by many 20th-century typists, was to help collate the pages in the correct order without gaps. The additional benefit, to those not thrown off by repetition, was that it helped to keep some phrases (and numbers) together in the reader's eye. (It would also have obvious benefits, besides keeping the pages in logical order, for someone delivering an address or report from a written text rather than a TelePrompTer, just as a musician wants to have a page turned before (s)he's finished playing the previous page's notes. Old hymnals repeated previous pages' last words for similar reasons.) —— Shakescene (talk) 12:22, 2 March 2009 (UTC)
                  • Both are real benefits; more real than the smoothness discussed here. But printers don't repeat words anymore, although it is all too common to have pages miscollated, so I can't suppose they are very great benefits. Septentrionalis PMAnderson 15:49, 2 March 2009 (UTC)
            • Another extension. A careful reading of my response will reveal no statement as to whether something like "the man" should break—so the logical leap (if...then) is based on a misinterpretation of what was written. A further careful reading will reveal that it wasn't my proposal; rather, it was my preference to support the inclusion of a &nbsp; between "12" and "billion" (as suggested by others—including the originator). For some reason this page seems to invite the responses of people who feel the need to tear down the suggestions of others. It is quite okay for opinions to be placed here (of all sorts) and to let the person who raised the original question take their pick of the resulting consensus (as I'm confident will now be done). If the responder above really wants something to do, perhaps considering the different nuance between "digit—unit" versus "definite article—noun" (and why extending an argument from one to the other is not necessarily valid) would be a good place to start.  HWV258  00:17, 2 March 2009 (UTC)
              • I careful analysis of HWV258's statement shows that his position is WP:ILIKEIT; but if it had a basis in general principle, it would be vulnerable to reductio ad absurdum, since the usual justification (that a unit abbreviation would be less than intelligible without its numeral) for such joins is lacking here. All I ask is that this rule-monger go peddle his rules somewhere else; his nbsp will rarely cause harm (although it may cause confusion), and if it actually causes ugly layout, somebody will fix the folly. Septentrionalis PMAnderson 00:28, 2 March 2009 (UTC)
                • Ah yes, the old "I will now reverse into a corner whilst applying paint to the floor in front of me" stage of the debate. "reductio ad absurdum" would only be relevant if it were correct to extend an argument for "digit-unit" to other areas; and as suggested, it isn't. As has been noticed on many previous occasions, the respondent's argument is exhausting itself when the exaggerated "supporting" language ("intelligible", "rule-monger", "peddle", "harm", "confusion", "ugly") deteriorates into an attempt to counteract arguments that weren't there in the first place. Perhaps now we can anticipate the final burst of Latin, so we can all get back to the real world (relatively unscathed)?  HWV258  00:56, 2 March 2009 (UTC)
    Playful banter is one thing, but when several consecutive comments have nothing to do with the topic at hand, someone has to say "enough is enough." Forget about Latin, forget about "argument extensions", just stick to the issue at hand: NBSPs and compounds numbers. What should I do in my particular case, and how should the MOS be changed to inform others in my situation? --Cryptic C62 · Talk 01:03, 2 March 2009 (UTC)
    • Use an ordinary space. There is a shadow of a reason to use a non-breaking space when the unit is an abbreviation like kg or m (the m may be confusing sitting by itself at the beginning of a line), but no reason to treat "digit-unit" combinations differently than any other character strings in your situation. Septentrionalis PMAnderson 01:08, 2 March 2009 (UTC)
    • This page is silent on the question, as it ought to be. Demoting this page from guideline status would be the shortest way to improve on that; it would lessen the temptation to use unnecessary nbsp's at all. Septentrionalis PMAnderson 01:25, 2 March 2009 (UTC)
    Crytic C62: I'm not sure what the problem is. A number of suggestions were given to you, so if you believe one to be useful, feel free to implement it in your editing. If you feel one to be outstanding, based on consensus, and of use to others, feel free to edit the MoS to reflect that preference.  HWV258  03:07, 2 March 2009 (UTC)
    Would that I could, but the page is protected. It seems to me that the most correct answer is that "12 billion lightyears" should have no NBSPs, as neither "billion" nor "lightyears" would be awkward if they appeared at the beginning of a line. After all, the page currently reads "in compound expressions in which figures and abbreviations or symbols are separated by a space," implying that non-abbreviated units of measurement don't need to be NBSP'd.
    As for amending the page, it seems clear to me that, regardless of whether my above conclusion is correct or not, a few lines of the NBSP section should be dedicated to disambiguating when NBSPs should not be used, specifically mentioning the issues we have touched on here. --Cryptic C62 · Talk 03:23, 2 March 2009 (UTC)
    Fair enough.  HWV258  03:35, 2 March 2009 (UTC)
    What is awkward with "12 billion" is not the "billion" at the beginning of the line, but the "12" at the ending. BTW, it looks like most featured articles (e.g. Japan, Australia, ...) use a non-breaking space between a figure and "million", but a normal space between "million" and whatever noun follows it. Heh, on a clooser look it appears that many featured articles aren't even consistent with themselves. Looking at those currently on the Main page, "King Vulture" uses a normal space before both occurrences of "million"; Edgar Speyer has eight instances of "&nbsp;million" and two of " million"; on Scene7 there are ten of the former and four of the latter; Caspar David Friedrich never uses the word million at all. (None of them ever uses the word billion.) In total, they are 18 hard spaces and 10 soft spaces. --A. di M. (talk) 09:51, 2 March 2009 (UTC)
    BTW, FWIW, as for what "the page currently reads", it tells to use a hard space in "£11 billion". --A. di M. (talk) 10:20, 2 March 2009 (UTC)
    That may be another borderline case. It is possible to be confused by The project cost £11<br>billion, because the £ sign supplies a substantive, so the part before the break is complete; but "12 billion lightyears" doesn't fall under this either. Septentrionalis PMAnderson 16:28, 3 March 2009 (UTC)
    • Coming late to this… Were it me, I’d write it 12&nbsp;billion lightyears. I might even do so for six&nbsp;billion lightyears. I think it looks better to have this:

    Lorem ipsum dolor sit amet, consectetuer adipiscing
    12 billion lightyears sed diam nonummy nibh euismod.

    Instead of…

    Lorem ipsum dolor sit amet, consectetuer adipiscing elit 12
    billion lightyears sed diam nonummy nibh euismod dolore.

    For really important documents, like technology white papers, I’ve used ligatures like fi and fl, so keeping the numeric value and named number together doesn’t seem to be overboard. Were it me, I would have MOSNUM not require this practice, but simply acknowledge that it is a better practice. Greg L (talk) 21:28, 3 March 2009 (UTC)
    Would you settle for acknowledging that it is a reasonable practice, with arguments for and against it (it's harder to read the edit space, and it can really distort layout)? Septentrionalis PMAnderson 21:15, 4 March 2009 (UTC)
    • I’d settle for anything since this is a relatively minor issue and many novice editors won’t pay any attention to such a guideline anyway. However, for non-breaking expressions like 12 billion, most of what wraps consists of the seven characters comprising “billion” or “million”; the two extra characters comprising “12” or “71” isn’t too much more to add to an end-of-line wrap. It shouldn’t be an issue unless one is in a very narrow column adjacent to a big picture on a small screen.

      I’ve attended to these details in articles I work on. For instance, if it is a date like 8{{nbsp}}May, I’ll keep such a short expression together. But if it is a longer date, like 27{{nbsp}}September and it is next to a picture, where it might be in a very narrow column on some users’ 800 × 600 monitor (or worse), I manually drag my window width narrower to see how the word wrap flows in the paragraph and tweak if necessary.

      These sort of issues crop up in more significant ways than dates; high-precision numerical equivalencies can be really nasty when word wrapping. For instance 0.45359237 kg appears in Kilogram right next to a picture. The extra two characters comprising kg don’t make it too much worse. Some editors like to keep the numeric value and the fully written-out unit of measure tied together; e.g. 0.45359237 kg. That’s quite a long sting to not allow to word-wrap so I try to use such an expression only very early in a new paragraph, where I am sure it won’t have to word-wrap (or check the word-wrap flow in variable window width). Of course, I don’t horse around with this level of detail on articles that are in a state of flux with many other contributors.

      I would say a guideline could be as simple as “If it is just a two or three-digit numeric value next to a written-out named number, make it non-breaking since the extra word-wrap burden of the numeric value is minimal.” Or, alternatively…

      Sinc their arr a lot uv edeters out their with a widde vareity of skeels, I woodnt bothre triing to git all of these into a guideline. I think I might just acknowledge that it is an acceptable practice and shouldn’t be reverted when done properly. Greg L (talk) 04:14, 5 March 2009 (UTC)

    Okay, so this seems to be a very situational issue, but definitely one that needs clarifying so this discussion doesn't repeat itself five months from now. Any suggestions on how the page should be revised/expanded to better explain the different ideas brought up here? --Cryptic C62 · Talk 22:19, 8 March 2009 (UTC)
    • Well, you didn’t make it easy by electing to not provide any links to any existing wording on MOSNUM that might be germane to the issue. My cursory look shows that this issue could be handled at either WP:MOSNUM, Non-breaking spaces, or at WP:MOSNUM, Numbers, Numbers as figures or words. I think the latter location would be where editors would most often look for this sort of information. Were it me, I’d insert this as the fourth bullet point here:

    • When writing two, or three-digit compound numbers, such as 12 billion lightyears or 420 million metric tons, it is often a good idea to use a non-breaking space, either &nbsp; or {{nbsp}} between the value and named number (e.g. 12{{nbsp}}billion lightyears). This will improve readability by preventing the expression from breaking at a line-end word-wrap.

    The named numbers like “million”, “billion”, and “trillion” are already very short because proportionally spaced font technology, combined with the fact that these named numbers all contain the same, four narrow-width characters “illi”, means the entire named numbers are only about 2.8 em wide. Proof:
    |million|
    |billion|
    |trillion|
    || (the space is coded <span style="margin-left:2.8em">)
    So adding two or three numeric digits just doesn’t create too large of a potential gap at the end of a line and greatly improves readability. Examine this:

    12 billion
    lightyears
    99 billion

    The unit “lightyears” actually takes up more room than both “12 billion” and “99 billion”. There is simply no problem when the practice of attaching digits to these named numbers is limited to two and three-digit numeric values; the combination ain’t that big of a character string. Greg L (talk) 21:08, 9 March 2009 (UTC)

    Disputed nature of "Linking and autoformatting of dates"

    {{editprotected}} Considering we're currently in arbitration over this, and given the willingness of those involved to continue to cite this fully protected page as if it were not in dispute, I propose adding {{disputedtag}} with section=yes (so {{disputedtag|section=yes}}) to "Linking and autoformatting of dates". —Locke Cole • t • c 02:44, 8 March 2009 (UTC)

    What exactly is disputed? The fact that linking dates purely for autoformatting was deprecated was accepted long ago, and supported by the December RfCs. I thought we went through this already. Dabomb87 (talk) 02:55, 8 March 2009 (UTC)
    The community expressed an interest in auto formatting that worked, so it seems to be getting ahead of ourselves to suggest in MOS that they're deprecated. —Locke Cole • t • c 02:57, 8 March 2009 (UTC)
    The community is clearly against the current form of autoformatting. While there is definitely significant support for autoformatting, there is no clear-cut consensus on the matter. Dabomb87 (talk) 03:02, 8 March 2009 (UTC)
    Hence the dispute, we shouldn't be acting as if this has all been resolved and is behind us... —Locke Cole • t • c 03:03, 8 March 2009 (UTC)
    • While there may be support for 'some form of autoformating' by half the respondents possibly influenced by the 'nearly ready software', the other half have clearly expressed opposition to any form of it. By the way WP works, this is a classic "no consensus" result, and not a slight majority in favour of DA. Ohconfucius (talk) 13:01, 8 March 2009 (UTC)
    • Right, so they've all decided via backchannelling to open another front: putting tags on long-standing parts of MoS that don't suit their campaign. It's not on. Please desist from these guerrila tactics. Tony (talk) 03:10, 8 March 2009 (UTC)
    • Do you have something new for us, Locke, besides the fact that there is a dispute raging over date delinking, which is a bit of *news* that every corpuscular being caught in linear time in our universe doesn’t already know? The MOSNUM page already says, right at the top, This protection is not an endorsement of the current version, which is standard practice when pages get locked. And why is it locked down(?) and why has it been that way so long? You have no one to blame but yourself for bringing on the ANI/ArbCom in the first place and fighting tooth & nail against the inevitable with every imaginable tool at your disposal (and some stunts no one would have imagined). In the end, it all amounts to nothing more than pay no attention to those RfCs behind the curtain.

      Please Locke; your disruption to Wikipedia, high and low and in every nook and cranny, started getting tedious quite some time ago. Greg L (talk) 03:53, 8 March 2009 (UTC)

    As someone with no stake in the date (de)linking dispute, I am going to disable the editprotected tag. Since there is disagreement about the requested edit, no admin is going to make the change that has been requested. However, I am certain that, even if there is not a "disputed" tag, it is well known that there is disagreement over the issue of date linking. And the protection template at the top of the page is a clear sign to any reader that there is a dispute. — Carl (CBM · talk) 04:07, 8 March 2009 (UTC)

    The problem here is that despite there being a dispute, and this page being protected to The Wrong Version, editors who think they've "won" something by getting it protected like this are using it at FAC/FAR/etc. to bully their view over the opposition. That's not how consensus works, and it's certainly not something that should be tolerated or encouraged. Marking the section(s) as disputed should resolve this, at least for people who follow these links and wonder why disputed sections are being enforced. —Locke Cole • t • c 11:33, 8 March 2009 (UTC)
    • Quoting you: That's not how consensus works… Ah yes, “consensus.” I note that you have been busy at WP:Consensus, ( [8][9][10][11]) where one of the long-timers there reverted one of your recent contributions, and did so with this edit summary: “Right in front of our noses.” Note too that your last edit was the same as your first. You got reverted on that too and you tried it again.

      (*sigh*) Could it be that I recently quote MOSNUM in an ANI? Unable to change what MOSNUM says, you asked, above, to have a {disputed} tag slapped on the text with which you disagree. Someone then quotes “consensus”. WP:Consensus is not locked down so there you go, making edits to WP:Consensus to push a POV that, IMO, is A) self-serving in your crusade on date linking, B) amounted to editing against consensus on WP:Consensus; all of which is C) part of a crusade on an issue—date linking—which past RfCs clearly show the community has no stomach whatsoever for.

      Please chill and let the ArbCom on all of this run its course. I know you won’t believe me, but what I say is true: your running around trying to change the foundation principles of Wikipedia’s guidelines and policies won’t feed into and influence the outcome of the ArbCom; if anything, it is the other way around.

      As for “bullying”, well… Do you see me running around, insisting upon unwelcome changes to long-standing Wikipedia policy pages? Cow patties. Greg L (talk) 17:59, 8 March 2009 (UTC)

    • Greg, as usual, misrepresents things. I added no text to WP:CON Greg. Nobody removed text I added. Please look more carefully before firing off accusations (as you always seem to do). All I did was replace an image. Another editor carelessly reverted me (intended to revert someone else). I reverted them, then self reverted, then fixed the image link manually again. The editor who reverted me even apologized on my talk page for what they did. But the truth isn't convenient to MOS regulars, it's much simpler to assume bad faith and MAKE IT UP AS YOU GO ALONG. Now, as for the disputed tags, it's ridiculous that when there's ARBITRATION over something some people still INSIST there's no dispute. Arbitration is the final step in dispute resolution, it is the prime example that, yes, there is a dispute. —Locke Cole • t • c 21:36, 8 March 2009 (UTC)
    • Oopsy. My misteak. Quoting you: Another editor carelessly reverted me (intended to revert someone else). I reverted them, then self reverted, then fixed the image link manually again. Now, why didn’t I figure that out?! Yes, I see that Orangemarlin apologized for this edit. And I wont try to attach any particular meaning to Butwhatdoiknow’s “Right under our noses” edit summary immediately following your series of edits due to everyone’s shooting themselves in the foot and walking all over each other and reverting their own edits. So I take that part back. Greg L (talk) 23:31, 8 March 2009 (UTC)
    It seems to me that the FA people will do what they will do, regardless whether the section is marked "disputed" or not. I say this without any strong concern for which way the outcome goes here. — Carl (CBM · talk) 13:53, 8 March 2009 (UTC)
    Echoing Carl here, most FA people don't pay attention to the daily changes to MOS pages. They go with the general movement, and the general movement is that dates are not linked anymore. Dabomb87 (talk) 14:26, 8 March 2009 (UTC)
    If you say it is so often enough it doesn't magically make it so. As far as I'm concerned the only reason people might be going along with this is because of the bullying via FAC, BOTS and scripts that those here have engaged in. —Locke Cole • t • c 21:36, 8 March 2009 (UTC)
    The FA people work off of WP:WIAFA, which stipulates an article must follow the MOS. Obviously if there is a dispute (and it is noted in the page) then they wouldn't have to. —Locke Cole • t • c 21:36, 8 March 2009 (UTC)

    Edit protection request to add disputed tag to disputed sentence

    {{editprotected}} Can someone please add the {{disputed}} tag at the end of the sentence here reading "Dates (years, months, day and month, full dates) should not be linked, unless there is a reason to do so." This is still a matter of dispute, but I'm seeing this cited as an actual standing guideline by editors unfamiliar with the protected nature of the page. -- Kendrick7talk 05:22, 8 March 2009 (UTC)

    • I think it's not about the exact same point. Anyhoo, User:Kendrick7 seems to be one of only a small number of editors disputing it — the point was the result of an overwhelming community endorsement, so the disputed tag cannot have any validity unless rejected by an equally overwhelming community opinion. Ohconfucius (talk) 05:45, 8 March 2009 (UTC)
    • LOL @ "overwhelming community endorsement". Just saying that over and over doesn't make it true anymore now than repeating this myth has for a year now. The dispute is why the page is locked, remember? So you just prefer to leave editors confused, right? -- Kendrick7talk 06:15, 8 March 2009 (UTC)
    • Methinks you are trying to bait Ohconfucius by *laughing* in his face. Please try to be civil Kendrick. The MOSNUM page already says, right at the top, This protection is not an endorsement of the current version, which is standard practice when pages get locked. Everyone knows there is a big honking dispute over date linking. The ArbCom will be over soon enough and you aren’t solving anything by jumping up and down and insisting that {disputed} tags be placed on everything with which you disagree—even if you vehemently, *pinky-promise* disagree with it. Greg L (talk) 06:39, 8 March 2009 (UTC)

    I am going to disable the editprotected banner. There is obviously a dispute, but the protection banner already indicates this. I strongly doubt that any admin would edit this page while it is protected to place a disputed tag on it, since it would never be feasible to get agreement about such an edit. — Carl (CBM · talk) 13:57, 8 March 2009 (UTC)

    Birth/ death date template guidance

    {{editprotected}} The numerically oriented birth and death templates eg: {{death date and age}} have a number of problems as discussed last month in MOSNUM discussions. Due to the needless complexity these older templates introduce, their error prone nature, their inflexibility with date display, as well as their inability to handle Julian dates, I suggest the following change to the guidance regarding their use. The new guidance steers contributors to the templates that accept plain text dates rather than the numeric dates:

    In biographical infobox templates, provide age calculation with {{birth-date and age}} for living people and {{death-date and age}} for the deceased when the full birth or death date, respectively, is known. Death-date and age may be used for Julian dates, but both parameters must be in Julian. With Julian dates, if strict microformat emission is a concern, the gregorian parameter must be used to indicate what the Gregorian date would have been, had that calendar been in existence at the time. See {{death-date and age}} documentation for an example.

    The current passage may be found in the birth and death dates section. Comments/ improvements? -J JMesserly (talk) 19:55, 11 March 2009 (UTC)

    I have added the editprotected template since this received no comments today and the concensus opinion from the prior discussion almost universally supported the less complicated syntax of the new templates. -J JMesserly (talk) 04:41, 12 March 2009 (UTC)
    Done--Aervanath (talk) 07:08, 12 March 2009 (UTC)

    Date linking for "oldest people"

    Personally, I think the birth and death years should be linked for EVERY biography, as history is important and a person's life is lived in context. However, when it comes to articles on "oldest" or "last survivors," the year of birth becomes an imperative part of the story. That Henry Allingham was born in 1896 and is still living beggars the question: how has the world changed in 112+ years? Having a convenient link to the year 1896 makes sense in these cases. Therefore, an exception should be made even if a decision is made to not link birth and death dates. Ryoung122 10:50, 12 March 2009 (UTC)

    The year articles are too scattergun to be worth linking to. 1896 contains a random selection of items, few of which would have any relevance to Henry Allingham's life (to pick a couple: April 9 - The National Farm School (later Delaware Valley College) is chartered in Doylestown, PA.; October 5 - After a long siege, Brazilian government troops take Canudos in north Brazil, crushing Antonio Conselheiro and his followers). Much more focused and informative links would be History of English society or Economic history of Britain, or similar. Colonies Chris (talk) 13:24, 12 March 2009 (UTC)
    The rational solution to this problem (if it is a problem) is to improve the year article. This is what we do for every other sort of article; we don't abstain from linking beause the present version of an article is controverted, erroneous, or even non-existent; indeed, we encourage making redlinks so that other editors will write the article.
    As for the examples given, both are relevant at least as context; the change from Farm Schools to commmunity colleges is part of a change in the whole structure of education, parallel to the change from the council schools he did attend - to the High School at which he spoke recently; note that council schools are younger than he is, being established by the Education Act 1902. Septentrionalis PMAnderson 17:39, 12 March 2009 (UTC)
    The 1896 article gives the reader no hint that the establishment of the school had anything to do with a structural change in education, it's just a bare fact with no context, like virtually every item in every year article. (And the farm school concerned is in Pennsylvania and HA is British, making it even less likely that it has any relevance to HA's experience of the changes in the world in his lifetime.) It's all very well to say 'we should improve the year article', but people have been saying that for a long time and it isn't happening (with a few rare exceptions). Colonies Chris (talk) 22:38, 12 March 2009 (UTC)
    • …if Greg wishes to propose that ArbCom set policy… I don’t; Locke Cole does. Guidelines won’t be settled by ArbCom, nor you, nor me. It will be established by community consensus, which is one of the guiding pillars of Wikipedia. And “community consensus” on Wikipedia is determined through RfCs. In this case, it will have to be an ArbCom-supervised RfC, since Locke et al. refused to accept the previous RfCs conducted here at MOSNUM. Greg L (talk) 20:43, 12 March 2009 (UTC)

    I'll have to disagree with Ryoung & Anderson here. Trivia about the particular year that a person happens to have been born in has little connexion to a serious biography. By all means link to the century/centuries he lived in but not a particular year. JIMp talk·cont 18:49, 12 March 2009 (UTC)

    Decade articles could also be a possibility.  HWV258  21:20, 12 March 2009 (UTC)

    All kinds of interesting things happened in 1896, such as the first modern Olympic Games, the 40-minute Anglo-Zanzibar War and a pivotal (realigning) U.S. Presidential Election. Whether they (or equally-important but completely-apolitical events) are properly featured is a matter of editing 1896. ¶ But that's really not the point, the editors working on Henry Allingham's article are those who should discuss and decide whether that particular article is interesting enough or relevant enough to their article to merit a link. Trying to establish a single policy in such matters for two million articles is far worse than madness. —— Shakescene (talk) 22:03, 12 March 2009 (UTC)

    An article's editors can decide such issues, but just a reminder that if something such as 1896 is deemed important-enough to be referenced, it can also be added to the See Also section of the article.  HWV258  22:22, 12 March 2009 (UTC)
    Very interesting alternative. Vegaswikian (talk) 22:41, 12 March 2009 (UTC)
    And again, contrary to our general treatment of links, which puts something in See also only if it can't be worked into the main text. Septentrionalis PMAnderson 23:05, 12 March 2009 (UTC)
    Thanks. And the other good thing about the See Also section is that it can provide a brief descriptive assistance as to which points might be of interest on the destination page (amongst the multitude of superfluous points that will be encountered there). A simple date link can never provide that assistance.  HWV258  23:09, 12 March 2009 (UTC)
    WP:SEEALSO seems to suggest using links in prose over using links in a "See Also" section. I'm failing to see how linking the year causes any problems that this resolves. —Locke Cole • t • c 23:23, 12 March 2009 (UTC)
    As mentioned above, it's an alternative that can be considered as the need arises. Numerous editors have pointed out the problem with a link that simply drops a reader at the start of a long list of nebulous facts. I've also just pointed out (but will do so again) that a See Also section can add a brief description—something a date link never can (as pointed out in WP:SEEALSO: Also provide a brief explanatory sentence when the relevance of the added links is not immediately apparent). Thanks for the link to WP:SEEALSO—I find the sentence These may be useful for readers looking to read as much about a topic as possible, including subjects only peripherally related to the one in question illuminating. In any case, there's nothing at WP:SEEALSO that prevents date links being placed in a See Also section: whether a link belongs in the "See also" section is ultimately a matter of editorial judgment and common sense.
    The more I think about it, the more I prefer date links to be moved to the See Also section. For example, in the Handel article, an entry in the See Also section could include the point: Note that Bach was also born in 1685. That provides a contextual reason (musicians having overlapping life spans) for clicking the link.
    As to my belief that the three people who will ever read "1685" and be interested enough to find out what else happened in that year, can simply enter the four digits "1685" near the top left of any WP screen and click the "Search" button—don't get me started. :-)
     HWV258  00:27, 13 March 2009 (UTC)
    Maybe a footnote would do the trick better than either SeeAlso or a wikilink. (Since Handel ended up in England, maybe a footnote that says "1685 was also the year when J.S. Bach was born and Charles II died." Since Henry Allingham served in the very-young Royal Naval Air Service, his birth in the year of the last old-fashioned colonial takeover by RN gunboats might be noted to show a contrast or transition.) Just thinking out loud (to use a wikifigure of speech). —— Shakescene (talk) 06:55, 13 March 2009 (UTC)
    Date links are a long standing convention on Wikipedia. They link to almanac-style articles with information on events that occur on the linked-to date/year. Not necessarily directly relevant except as a method of browsing other articles. I'm still unconvinced of the harm, and obviously most of Wikipedia is unconvinced as well, or else this convention would not have been maintained for nearly six years prior to this one-man crusade to abolish them. —Locke Cole • t • c 01:36, 13 March 2009 (UTC)
    "One-man"? I think we're getting closer to the nature of the "problem" here. I know it's probably too late for you to ever try to get out of the corner of the room you are in (you know, the one with all the wet paint around you), but to anyone else who may read this, please review the results of the various RfCs here and see if the epithet of "one-man" really applies (the 190 "oppose" votes to the first proposal mentioned on that page are an eye-opener). I'm also sad (again) to see that a whole heap of rationale (and well-meaning analysis above—from more than one editor) remains unaddressed, except to summarily dismiss everything with words such as "crusade". I suppose I'm nervous to ask, but whom is the "one-man"?  HWV258  03:14, 13 March 2009 (UTC)
    Tony1 (talk · contribs). —Locke Cole • t • c 03:31, 13 March 2009 (UTC)
    I'll say this again, in case anyone reading this discussion hasn't heard it before. Dates were linked, not through careful consideration of their relevance, but en masse as a side-effect of autoformatting, which until last year was recommended by the MoS. The unintuitive nature of the autoformatting syntax ('day month' and 'year' have to be linked separately) misled many editors into believing that all years were supposed to be linked. Almost all of the year links we have throughout WP were made because editors thought that's what they were supposed to do. The proof of mass indifference to these links is to be seen in my evidence to the ArbCom case - thousands of articles delinked with scarcely a peep of objection.
    An excellent example of the confusion among editors about date linking can be seen in an article that was linked from the main page only a couple of days ago: psychedelic frogfish. You'll see there that January and June are linked - pointlessly, even LC would agree; the years 1992 and 2008 are linked, though very unlikely to have any relevance, and the date [[April 2]], 2008, is partially linked for autoformatting; presumably the year is not linked there because the editor, not understanding how autoformatting works, felt that 2008 had been linked already. Colonies Chris (talk) 11:42, 13 March 2009 (UTC)
    We already have a principle that we only make links that are relevant and help to deepen a reader's understanding of the subject. In the unlikely event that the 1896 article is ever turned into something that provides some insight into Henry Allingham's life experience, by all means link to it. But for now and for the foreseeable future, it's not relevant, and neither are any of the year articles. There are plenty of better ways to provide that sort of context. Colonies Chris (talk) 22:38, 12 March 2009 (UTC)
    Such dogmatism. Those who find something for their hand to do should remember that others may think differently. Septentrionalis PMAnderson 22:58, 12 March 2009 (UTC)
    What a bizarre response. Dogmatism? If it's relevant, link to it. If it's not, don't. If that's dogmatic, I plead guilty. Colonies Chris (talk) 23:50, 12 March 2009 (UTC)
    To this I agree; the dogmatism consists of the assertion that 1896 isn't relevant, and will never be. Septentrionalis PMAnderson 17:44, 13 March 2009 (UTC)

    This matter will be addressed in depth in an Arbcom-spawned RfC, I suggest that users direct opinions and input about the RfC here. Dabomb87 (talk)

    Where's the discussion

    A while back I saw a discussion where many editors voiced opposition to any form of date autoformatting that caused registered users to see different content from unregistered users. Does anyone else remember this? Where is this discussion archived?

    I'm wondering because there's now a proposal to open a new can of worms by creating a "formatdate" function that does exactly the same date autoformatting that was rejected before, just without the brackets. —Remember the dot (talk) 01:10, 17 March 2009 (UTC)

    Some thoughts on that proposal were expressed here and here.  HWV258  02:02, 17 March 2009 (UTC)
    Thanks for the links, but there was a different discussion before those. It's that previous discussion that I'm looking for. —Remember the dot (talk) 02:07, 17 March 2009 (UTC)
    I'm not sure. Was it one of the links at the end of this essay?  HWV258  02:15, 17 March 2009 (UTC)
    No. It was a discussion page, probably a talk page. —Remember the dot (talk) 02:19, 17 March 2009 (UTC)
    I believe you are looking for /Archive D6. -Rrius (talk) 05:14, 20 March 2009 (UTC)

    Edit request to add shortcut

    Please add the shortcut WP:COMPUNITS for the discussion of how to represent binary/decimal values. Ham Pastrami (talk) 03:11, 17 March 2009 (UTC)

    Done. (This appears non-controversial; let me know if there is a problem.) Cheers. --Ckatzchatspy 03:31, 17 March 2009 (UTC)

    Proposal to unlock MOSNUM

    It seems that cool heads, peace, and civility has broken out—completely unchecked—all over the place on the ArbCom and its related subpages. I have this proposal: Why not unlock MOSNUM with the proviso that anything related to date formats, autoformatting, and date linking be left alone. Greg L (talk) 04:40, 17 March 2009 (UTC)

    P.S. After MOSNUM is unlocked, maybe we might see that everyone standing around on Wikipedian street corners will have a confused, blank look, and say to their neighbor “Instead of running for our AK‑47s, wanna play a game of checkers or something?” Greg L (talk) 04:47, 17 March 2009 (UTC)

    If desired (and for our sanity) one could consider temporarily moving the "Chronological items" section to a sub-page, protect only that sub-page, and then display it in the main page. That way, no-one would be tempted... Thoughts? --Ckatzchatspy 05:21, 17 March 2009 (UTC)
    • Perfect. By “display”, you mean transclude that page into the relevant section of MOSNUM; yes? That’s a great way restore some sense of normalcy. Greg L (talk) 06:05, 17 March 2009 (UTC)
    That's the term I was looking for... sorry for the momentary blank-out. If that sounds reasonable to everyone, I can make the change. Thoughts? --Ckatzchatspy 20:14, 17 March 2009 (UTC)
    • I, for one, can not possibly imagine any downside. I don’t even perceive a need to transclude the entire Chronological items section since most of it is uncontroversial stuff. I suggest unlocking everything except except the Linking and autoformatting of dates section, which would be moved and transcluded back. If editwarring starts on adjacent material, it will be only too easy to expand the transclusion range.

      Unlocking MOSNUM will help everyone settle into a feeling of normalcy, which has been sorely lacking for a while. Greg L (talk) 03:34, 18 March 2009 (UTC)

    All right, per Greg's request (and seeing no objections) I have changed the page's protection level to "semi-protected". The "Dates" subsection has been moved to the sub-page "Wikipedia:Manual_of_Style_(dates_and_numbers)/Datestempprotectedsection" (which is then transcluded back to the main page) and that sub-page remains fully protected until the dispute is resolved. If this works as planned, editors should be able to make necessary changes to the bulk of the guideline, while preventing edit wars in the controversial "Dates" section. Please let me know how this is working, so that we can tweak or revert as needed. --Ckatzchatspy 09:11, 19 March 2009 (UTC)
    It should also have a dispute tag, or tags, since it is. Septentrionalis PMAnderson 15:32, 19 March 2009 (UTC)
    • Even Marvin the Martian knows Wikipedia’s date-related stuff is the subject of a raging dispute. He’s got his telescope focused on the Capitol steps to see if some Wikipedian goes there, douses himself with gasoline, and sets himself alight over date linking. Greg L (talk) 19:59, 19 March 2009 (UTC)

    Hallelujah. (I had proposed this on 15 February, but it was ignored.) --A. di M. (talk) 16:37, 20 March 2009 (UTC)

    Your suggestion wasn’t being ignored. There wasn’t enough “war fatigue” at that time. Also, key combatants back then were still in “wide-eyed” mode, trying to eat the still-beating hearts of their enemies. What has changed in the interim is there is now a more amicable relationship to hating each other. Greg L (talk) 17:30, 20 March 2009 (UTC)

    Compound numbers

    As previously discussed (archive), would anyone object to my adding this as the fourth bullet point here on MOSNUM:

    • When writing two, or three-digit compound numbers, such as 12 billion lightyears or 420 million metric tons, it is often a good idea to use a non-breaking space, either &nbsp; or {{nbsp}} between the value and named number (e.g. 12{{nbsp}}billion lightyears). This will improve readability by preventing the expression from breaking at a line-end word-wrap.

    Greg L (talk) 22:06, 19 March 2009 (UTC)

    I'd rather say "numbers written partly as figure and partly as words" rather than "two, or three-digit compound numbers", as it would also apply to, e.g., 1079 million. But, where we are at it, this could be merged with the bullet starting with "The use of words rather than figures..." like this:

    • When expressing large approximate numbers, it is preferable to write numbers in words, or partly in figures and part in words, for example: Japan has the world's tenth largest population, with about 128 million people (it is just an approximation to a number likely to be anywhere between 127,500,000 and 128,500,000), but It grossed $28,106,731 on its opening day (the exact number). When both a figure and a word are used in the same number, it is useful to use a non-breaking space, as in 128&nbsp;million, to prevent a line break from occurring between them.

    What do y'all think? --A. di M. (talk) 18:25, 20 March 2009 (UTC)
    • I think what you have here is great. Have you checked the rest of the wording on MOSNUM to ensure we would be adhering to a consistent convention for the terms “numbers”, “words”, “figures”? If what you have is consistent, then I think it’s fab. If the terminology is inconsistent, I trust that you will make the peg fit the hole or the hole fit the peg. Greg L (talk) 20:53, 20 March 2009 (UTC)
    No, I haven't. Does that really matter that much? --A. di M. (talk) 21:01, 20 March 2009 (UTC)
    • IMO, sure. You and I are very familiar with this stuff and understand the intended meaning of the points. But for some 16-year-old editor trying to make heads and tails of all those guidelines, consistency with naming our nouns should be a high priority. I wouldn’t have a cow about your posting it as is. But I would just be reluctant to do so myself unless I made sure my verbiage was harmonized with what I was imbedding it into (rather than leaving such details for someone else later on). Greg L (talk) 21:13, 20 March 2009 (UTC)

    (outdent)
    I took the initiative and looked at the existing verbiage. I’ve revised the key nouns to be harmonious with adjacent text and added the following:

    • When expressing large approximate quantities, it is preferable to write them spelled out, or partly in figures and part as a spelled‑out named number, for example: Japan has the world's tenth largest population, with about 128 million people (it is just an approximation to a number likely to be anywhere between 127,500,000 and 128,500,000), but The movie grossed $28,106,731 on its opening day (the exact quantity).

    • When both a figure and spelled-out named number are used in a quantity, it is useful to use a non-breaking space, as in 128&nbsp;million or 128{{nbsp}}million to prevent a line break from occurring between them.

    Be my guest to tweak and revise to your heart’s content; I’m not stuck on anything—just the basics here. Greg L (talk) 04:31, 21 March 2009 (UTC)

    Careful with what browser you use for proofing

    An aside on browsers. Many of us have tweaked the appearance of our code with thinspaces and whatnot to make rendered pages appear better. This is just a reminder that if something doesn’t look quite right and you are using Internet Explorer 8, that it would be a good idea to try other browsers too. According to ChannelWeb, IE 8 rates a 20 out of 100 on The Web Standards Project’s Acid3 Browser Test, which “is the third in a series of test pages written to help browser vendors ensure proper support for web standards in their products.”

    The ChannelWeb article mentioned also that “Apple's Safari 4 browser scores 100 on Acid 3”. Whereas Safari is only third in market share, with nearly 11% of Web activity, it will show you how pages are supposed to look. Greg L (talk) 21:25, 21 March 2009 (UTC)

    I'd argue that it's best practice to ensure that any site is designed to support all the major browsers and as such you should ensure that we rely on a subset that works on all the popular browsers (IE7, FireFox 3, IE6, IE8, and Safari in order of market share). I'd also argue that Acid3 shouldn't be used as an excuse for finger-pointing and using it as such is an extremely bad idea: I believe that no current browser has complete implementations of /any/ of the web standards. -Halo (talk) 18:13, 22 March 2009 (UTC)
    Uninvolved with this, but I'd like pop in and point out that the Acid test is not a good measure for what you are trying to use it for. Acid tests mainly nonstandard and broken tags, not common and important tags. It's more of a test of robustness rather than proper layout engine functionality. Gigs (talk) 03:10, 26 March 2009 (UTC)

    Problem on Era conversion

    This topic has been removed from Wikipedia:Village pump (miscellaneous)

    Many writers have converted the years under Buddhist Era (BE) to Christian Era (AD) in an incorrect way for they left one exception behind.

    We should take notice that:

    1. For Thailand only, BE commenced as of one year following the death of Gautama Buddha; but for another countries adopting BE, the Era commenced as of the death of Gautama Buddha.
    2. Converting Thai BE to AD can be made by subtracting 543 from such BE, the outcome is AD. Example: 2552 BE is equivalent to 2009 AD.
    3. However, in converting a date prior to 1 January-31 March of 2484 BE (1942 AD), the number to subtract is not 543, but 542.
    4. Perversely, converting AD to BE can be made by adding 543 or 542, as the case may be, into such AD.

    Article 3 is an exception usually left behind by many people, and this led to a great problem about inaccuracy of year counting or conversion in many Wikipedia articles as to Thailand, Thai persons, Thai stuffs, Buddhist stuffs and any others in connection with the said.

    Therefore, I suggest us to lay down a project to check and rectify the said mistakes. I cannot say how to carry out the project, but I can say that checking whether this one is a correctly-converted year or not would be much difficult and we need to seek Thai Wikipedia for cooperation. Thai Wikipedia is also meeting with the same problem as us. ——PORtrait | chit~chat - 24 March BE 2552 (2009), 03:17 hours (GMT+7)

    If you don't get any discussion going here, you might want to post at Wikipedia talk:Manual of Style (dates and numbers). -- John Broughton (♫♫) 00:22, 25 March 2009 (UTC)
    How about a template to convert automatically? Both years could be displayed & there should be no errors since it's automated. JIMp talk·cont 11:38, 25 March 2009 (UTC)

    Wikipedia:Date formatting and linking poll

    The above link leads to a community poll regarding date linking on Wikipedia. The poll has not yet opened, but the community is invited to review the format and make suggestions/comments on the talk page. We need as many neutral comments as we can get so the poll runs as smoothly as possible and is able to give a good idea of the communities expectations regarding date linking on the project. Ryan PostlethwaiteSee the mess I've created or let's have banter 19:43, 21 March 2009 (UTC)

    Note The first phase of this poll will start on 30 March. Dabomb87 (talk) 03:59, 28 March 2009 (UTC)

    Abbreviating months

    Is there any standing on the abbreviation of months in an article? Is abbreviation ever acceptable? In what cases can they be accepted? or can not? Is it known as unacceptable in infoboxes? FireCrystal (talk) 16:59, 27 March 2009 (UTC)

    The official MOS standard is: Abbreviations such as Feb are used only where space is extremely limited, such as in tables and infoboxes. That is, you spell them out in in full, unless you don't have enough space, which would never occur in the body of the text or in footnotes. If you do have to abbreviate months, a useful guideline is that only the military abbreviates June and July, and nobody abbreviates May. RockyMtnGuy (talk) 17:35, 27 March 2009 (UTC)
    I wasn't quite sure where something on this was. Thank you for the response. FireCrystal (talk) 17:45, 27 March 2009 (UTC)

    Kilogram calorie

    When unit names are combined by multiplication, separate them with a hyphen. A kilogram-calorie (kg·cal) is not the same thing as a kilogram calorie (kcal). Pluralization is achieved by adding an s at the end (e.g., write A force of ten newton-metres).

    I don't think kcal is kilogram calorie but kilocalorie, which is different. --SLi (talk) 18:05, 24 March 2009 (UTC)

    The official U.S. document on the subject indicates that cal is the symbol for the small (gram) calorie, and that kilogram calorie is an obsolete term for kilocalorie, which is symbolized as kcal. Presumably a kilogram-calorie would be the unit that results when a certain number of calories is absorbed by a mass of a certain number of kilograms. I really think a better example should be found, since this example defies the official advise of the United States government in that it mixes an SI unit, kilogram, with a non-SI unit that is unacceptable for use with SI, the calorie.
    I think my emphasis on U.S. policy may be justified here, because my impression is that the calorie is being de-emphasized in other countries in favor of the joule. For example, I understand that UK food labels now use joules to state the energy contained in food --Jc3s5h (talk) 18:36, 24 March 2009 (UTC)
    There is the gram calorie based on the energy it takes to increase the temperature of one gram of water by one degree Celsius and the kilogram calorie based on the energy it takes to increase the temperature of one kilogram of water by one degree Celsius. Thus 1000 gram calories (1000 cal) is 1 kilogram calorie but kilo- is 1000 so 1 kcal is equal to one kilogram calorie. So, yes, 1 kcal is one kilocalorie which is defined differently but equal to a kilogram calorie. No "mixing" of SI and unacceptable units: it's an unacceptable unit based on and SI unit. JIMp talk·cont 12:01, 25 March 2009 (UTC)
    The point is to illustrate that you should hyphenate compound units (newton-meter rather than newton meter). The choice of kilogram-calorie vs. kilogram calorie is to give an example of where not using a hyphen introduces an ambiguity, not to say that kcal is officially called kilogram calorie rather than kilocalorie or that kcal is prefered over joules. Use another example if you feel like it.Headbomb {ταλκκοντριβς – WP Physics} 09:38, 27 March 2009 (UTC)
    I think the usage "out there" is more mixed: you will find both "kilowatt hour" and "kilowatt-hour". The BIPM themselves write "newton metre".[12] Maybe it is a good idea to specify which our house style is, maybe we should just say "just pick one and be consistent within each article", I don't have a strong opinion about which; but ambiguity is not a real concern here. (While we are at it, why do we only allow the middle dot to multiply units? The hard space is also commonly used, and for a few units even justapposition is, e.g. kWh and mAh.)
    As for this particular example, who really uses the unit kg·cal? It is a unit of squared momentum, and anybody in their right mind would use, er..., the square of a unit of momentum. On the other hand, if there are a unit "foo baz" and a different unit "foo-baz", both in actual use, with the latter being equal to the product of one foo by one baz, feel free to add such an example.
    A. di M. (talk) 15:23, 27 March 2009 (UTC)
    I don't like the example, because there are too many different difficulties with it, which distracts from the point being made. However, A. di M.'s point about the kilogram-calorie not being in actual use is only partly true. It is very unlikely that a finished result, such as would be written about in a Wikipedia article, would involve the compound unit kilogram-calorie. It is entirely possible that such a unit would arise in an unpublished calculation that shows every calculation step. But in the latter case, it would almost certainly be written as a symbol (kg·cal) rather than spelled out. --Jc3s5h (talk) 16:47, 27 March 2009 (UTC)
    As far as I can tell, the example given is wrong in many respects. A kilogram calorie is the same thing as a kilocalorie, and you should not, in any case, hyphenate the name of either kilogram calorie or newton metre - See the NIST conversion table at http://physics.nist.gov/Pubs/SP811/appenB9.html . The kilogram calorie is, in fact, an obsolete name for the kilocalorie, which is itself an obsolete metric unit, replaced by the kilojoule in the SI system. Some people still use it, but unfortunately it has several different definitions, depending on the application, which is why it was replaced by the joule. The kilogram-calorie might be construed as a kilogram multiplied by a calorie, but I'm not sure why anybody in their right mind would use such a unit, particularly since it is ambiguous in several different obscure ways. Bad example, really bad.RockyMtnGuy (talk) 17:16, 27 March 2009 (UTC)

    RockyMtnGuy exaggerates the case against using a hyphen. The source he(?) uses has this to say in another section:

    9.4 Spelling unit names obtained by multiplication

    When the name of a derived unit formed from other units by multiplication is spelled out, a space, which is preferred by Ref. [6] and this Guide, or a hyphen is used to separate the names of the individual units.

    Example: pascal second or pascal-second

    --Jc3s5h (talk) 17:49, 27 March 2009 (UTC)

    Well, okay, some people (not me) might use a hyphen. The NIST says "a space, which is preferred...". However, that just makes the situation worse, because then a kilogram-calorie (kg·cal) IS the same thing as a kilogram calorie (kcal), and what the example says is completely wrong. Personally, I'd just keep my hands in the air and back away from it very slowly before somebody gets hurt.RockyMtnGuy (talk) 20:53, 27 March 2009 (UTC)
    (edit conflict) To Jc3s5h: Well, a "calculation that shows every step" in which you multiply a mass by an energy would very likely be a theoretical one, in which you would just use symbolic names for quantities and plug the actual values only at the end. "A particle of mass m with kinetic energy E has a de Broglie wavelength h/√2mE; if m = 9.109×10^−31 kg and E = 5.210×10^−19 cal, then λ = 3.325×10^−10 m." And it would most likely not use the small calorie as a unit of energy, anyway. --A. di M. (talk) 17:52, 27 March 2009 (UTC)

    I went ahead and removed the example. If no-one objects, I'm going to mention that spaces can also be used. --A. di M. (talk) 20:17, 27 March 2009 (UTC)

    I object. As mentionned, a kilogram-calorie (kg·cal, units of mass·Energy) is not the same as a kilogram calorie/kilocalorie (kcal, units of energy). Headbomb {ταλκκοντριβς – WP Physics} 06:58, 29 March 2009 (UTC)
    Having been corrected on this point by Jc3s5h, I have to point out that if you follow the rules of the US National Institute of Standards and Technology (NIST) as quoted above, and allow people to use either a space or a hyphen to separate names of individual units, then a kilogram-calorie IS the same as a kilogram calorie. This represents something of a fundamental problem. My own personal solution would be to ignore what the NIST says and never use a hyphen, but the NIST is the standard-setter for the US, so this is a problem for Americans writing for Wikipedia.RockyMtnGuy (talk) 11:55, 29 March 2009 (UTC)
    The kilogram calorie is an old name for the kilocalorie (symbol: kcal) and it is always spelt with a space, as "kilogram" is an adjective here. The product of a kilogram by a calorie, if anyone ever used such a unit, could be called either "kilogram calorie" or "kilogram-calorie" and its symbol could be either "kg cal" or "kg·cal". So one spelling is ambiguous and the other isn't, but I don't think this ambiguity is serious enough for us to forbid a spelling such as "newton metre" which is explicitly allowed by BIPM and other such bodies and also widely used in practice.[13] I think this ambiguity is mostly hypotetical: no-one calls the kilogram calorie like this any longer, and I can think of no other unit name in which another unit name is used as an adjective. --A. di M. (talk) 21:17, 29 March 2009 (UTC)

    Islamic dating in the English-speaking Wikipedia

    Hi. What do you do with articles that only use Islamic dating (A.H. - After Hejira) for reference in the English-speaking Wikipedia? Do we leave the dates alone? It renders the article essentially useless for English-speaking individuals accustomed to western (Gregorian calendar) dating traditions. I can accept there being co-dating with Islamic dating along side Gregorian dates as it provides us with more information - although I don't know what Wikipedia's policy is for it - but it seems self-defeating (from an information perspective) to leave articles such as this, uncorrected. Is there a Tag/template located somewhere that we can post, urging the article to be converted to Gregorian dates and/or that any new dates be entered using Gregorian calendar dating? In particular, many of the scientific and scholarly Arabs do not have Gregorian dates assigned to their articles but instead use A.H. dating, such as Al-Juwayni... Stevenmitchell (talk) 04:52, 29 March 2009 (UTC)

    Switch everything in Gregorian dates or Julian dates as appropriate. When important, also give the Islamic dates as a conversion, in the same way we give conversion to Chinese dates when important. But non-Gregorian or non-Julian dates are unacceptable as primary dates. Headbomb {ταλκκοντριβς – WP Physics} 06:50, 29 March 2009 (UTC)
    Gregorian or Julian dates must be included. The Islamic year is shorter by almost 11 days than the Gregorian calendar so it is too much to expect the general reader to do his or her own calculations. I am not fussed if the Gregorian or Julian date comes first or second, but the date must be included as a matter of course. Michael Glass (talk) 01:00, 30 March 2009 (UTC)

    Wikipedia:Date formatting and linking poll now open

    The date linking and formatting poll is now open. All users are invited to participate. Ryan PostlethwaiteSee the mess I've created or let's have banter 23:00, 29 March 2009 (UTC)

    Heads up

    I've gotten a positive response at WT:MOS#Which is it (i.e.)? to my request to stop monthly updates of the WP:MOS page for the 4 reasons I gave there. This is the only other page that, conceivably, all 4 reasons apply to; it's too soon to tell. I'll ask for opinions at the end of the month. - Dan Dank55 (push to talk) 22:42, 20 March 2009 (UTC)

    So far so good; lots of changes, but that's expected after a long lockdown, and I understand the changes. This page doesn't seem to have the problem that WP:MOS does that people feel a need to change minor details all the way down the page every month. But "1700s ... could refer to either 1700–1709 or 1700–1799"? See Talk:1800–1809 to see how much discussion there's been on that point. I believe someone was able to find a few sources of marginal reliability that used "1900s" for 1900-1909; no one could find any sources for that use of 1800s or any other century, and we asked all over the wiki. - Dan Dank55 (push to talk) 12:38, 23 March 2009 (UTC)
    Okay, end of the month ... I think I can keep up with the changes on this page, but please look over my shoulder at WP:Update (or feel free to jump in yourself!) to make sure I don't miss some crucial point. Anyone want to remove this page from Category:General style guidelines? - Dan Dank55 (push to talk) 04:16, 31 March 2009 (UTC)

    Range of death

    What is the correct format to use if you know the range of years within which a person died? The problem occurs in Adam de Stratton, who was alive in 1292, but dead by 1294. Using a dash seems a bit silly, as if he spent two years dying. Some publications use an "x", as in 1292x94. Lampman (talk) 19:09, 1 April 2009 (UTC)

    Units of measurement in general articles.

    Section moved from WT:MOS --A. di M. (talk) 01:12, 28 March 2009 (UTC)

    At present the Manual of Style gives guidance about which units of weights and measures to use in scientific articles and articles that refer to particular countries. However, there is no guidance about general articles. I propose a small revision of the guidelines.

    • For other country-related articles and general articles, the main units are metric: 37 kilometres (23 mi).

    It reflects present practice (see Mountain, Lake and Ocean so I don't think it should disturb anyone. I seek consensus to make this small revision (without the bolding, of course).

    What do other editors think? Michael Glass (talk) 00:15, 28 March 2009 (UTC)

    (I guess that "main units" means the units which appear first, as opposed to that between parentheses.) I would say that the "main unit" should be whatever unit the source for that particular measurement used, whereas any conversion done by Wikipedia editors should be between parentheses. --A. di M. (talk) 01:12, 28 March 2009 (UTC)
    In particular, I don't think that the requirement that "[a]n article should only have one set of primary units" is necessary. There would be nothing wrong with writing "a 10-kilogram (22 lb) bag of potatoes and an 11-pound (5 kg) bag of carrots" in the (admittedly unlikely, but not impossible) event that the bag of potatoes were originally weighed in kilograms and the bag of carrots were originally weighed in pounds, and Wikipedia editors had to convert the former to pounds and the latter to kilograms. --A. di M. (talk) 01:24, 28 March 2009 (UTC)
    I'm a science tutor in the UK. My tutees have all heard of feet, miles, pints and gallons from everyday speech, but they are all taught in metric only. In my experience, not one of them knows how many pounds are in a stone, let alone in a kilogram, even amongst those who worry about their weight. Sadly, they are also generally poor at arithmetic compared to my generation. Even with inline conversions, inconsistent ordering of metric and imperial often confuses, and if imperial units come first, they find it more difficult to remember as it conflicts with what they're taught in school. In the interests of helping my tutees and their contemporaries, who often use Wikipedia for revision purposes, I would vote for the proposition to add "and general articles" to the MoS wording.
    Re. the potatoes and carrots: The purpose of encyclopaedias is to give readers a digest of the topic of interest, and therefore ease of comprehension is paramount. Fidelity to the wording of a source will be irrelevant to the general reader, and using inconsistent units to maintain that fidelity will not aid his or her comprehension of the article.
    So, if I were editing an article about potatoes and carrots, I would write:

    a 10-kilogram (22 pound) bag of potatoes and a 5-kg (11 lb) bag of carrots

    (where I have highlighted the measurements found in the source)Peter Barber (talk) 12:03, 1 April 2009 (UTC)

    The words "main units" came from the style guide as it stands. The meaning is clear enough even if it is not ideal. My proposal is only whether or not to add the words and general articles to what is there. Do you agree? Michael Glass (talk) 01:55, 28 March 2009 (UTC)

    A. di M.: The purpose of writing an encyclopedia article is to bring together information from scattered sources into a coherent whole. If you are not willing to integrate information from various sources, including selecting one main system of units, you should be writing bibliographies rather than encyclopedia articles. However, in high precision measurements (which are not usually "general" articles) in makes sense to indicate which values are exact. It also makes sense to make it clear if certain values ara a round value because of a deliberate design choice (e.g. 100 yard American football field). --Jc3s5h (talk) 02:50, 28 March 2009 (UTC)

    I'd have to know what proportion of the readers of English Wikipedia are in the United States. General readers in the U.S. most definitely are unfamiliar with metric units (the 325-mg [5-grain] aspirin tablet and the 2-liter soda bottle almost the only ones they'd see regularly—while milk is still sold in pints, quarts or gallons and cough syrup by the fluid ounce), so they are certainly not well-served by the general measurement being metric. But whether most En.Wikipedia readers are in the U.S. or outside, this (applied to general rather than technical, athletic or country-specific articles) seems to me a good example of where it's better not to add to the unmanageably vast range of the Manual of Style, and instead leave the choice to the editors who are writing, reading and revising a specific article. (Needless to add, the large number of Anglophone readers in both the U.S. and metric countries is the reason why it's so important, even when tedious, to convert both ways everything that can be conveniently converted.) —— Shakescene (talk) 03:50, 28 March 2009 (UTC)

    Somebody with a network analyzer or superuser access to the servers could find out how many readers are in any given country by analyzing the IP addresses, but I don't know if that ever has been done. About half of the people who speaker English as a first language are in the United States, but there are at least another billion people worldwide who speak English as a second language, and they do most of their web browsing in English. As I'm fond of pointing out, there are more people in China who speak English than there are in the United States, and more Chinese have internet access than Americans. The majority of the people who speak English as a second language do not understand American traditional units.
    It's interesting that you mention milk being sold in pints in the US, because it's still being sold in pints in the UK. Unfortunately, the UK pint is a different size than the US pint (20% bigger). In fact, none of the units you mentioned (pints, quarts, gallons, and fluid ounces) is the same size in the US as the British imperial system. That's one of the reasons all the Commonwealth countries converted to metric, and one of the reasons we need to baseline everything in SI units.RockyMtnGuy (talk) 12:48, 29 March 2009 (UTC)

    Many Americans are familiar with metric: scientists, engineers, medical workers, government employees, teachers, military people. It is hard to go through life in the US without encountering metric units either on the face of things or behind the scenes. It isn't just on soda labels, it is on wine, water, liquor. Almost all packaged goods in a US supermarket have metric units on the label by law (FPLA), just look next time you are there. Lightmouse (talk) 13:11, 29 March 2009 (UTC)

    While it might be tedious to provide metric measures, it is necessary. If Americans are unfamiliar with metrics, other people are even less familiar with the traditional measures used in the United States. For an amusing example of what confusion this can cause see the following clip on Youtube: [14]. But how many of the English-medium countries use the metric system? Nigeria has 154 million, South Africa has 48 million, Canada has 33 million,Uganda has 32 million, Ghana has 23 million, Australia has 21 million, Zambia and Zimbabwe each have 12 million, Singapore Ireland and New Zealand each have 4 million, and I haven't even mentioned India or the United Kingdom. Let's just say that a lot of English speaking and English medium countries use metrics. In many of these countries, English is not the first language of most people, so this is barrier enough without an unfamiliar set of weights and measures. Michael Glass (talk) 13:49, 29 March 2009 (UTC)

    It's not as if the average American has never heard of a kilo or a centimeter. And within specialized contexts, non-scientists may use metric much more than non-metric measures. But that doesn't mean that a "government worker" (e.g., a postal carrier or a Social Security clerk, even a teacher of history or English) has much intuitive sense of how the whole metric system fits together. An American nurse who uses cc's and mcg's all day still weighs patients in pounds and measures them in inches, while thinking about miles per gallon, Fahrenheit temperatures and pounds of groceries. The metric equivalents are always on grocery labels (e.g. 454 something or other) but rarely considered (price comparisons, for example, are given per pound not per kilo). But since I know that many English speakers (and even more English-readers) live outside the U.S., I know the reverse is true for millions of others. What I don't know is the proportions, not among potential or theoretical readers of Wikipedia, but current ones. And so I completely agree that (wherever practical)†, measures should be given in both metric and non-metric forms. †[An example of where it was difficult to fit useful metric conversions is the table of historic batting distances at Yankee Stadium (1923), although there are conversions almost everywhere else in the article. I imagine the same problem might crop up in a discussion of cricket matches or running distances in American football.] My general feeling right now is that, just as with U.S. and British spellings and punctuation, there's no need to set a standard of measure for general articles, so long as they're properly converted. —— Shakescene (talk) 17:24, 29 March 2009 (UTC)

    • If it’s an article closely associated (or more associated) with the U.S., use U.S. Customary units of measure and parenthetically convert to SI. If it’s a general article not closely associated with the U.S., use SI and parenthetically convert to U.S. Customary. If it’s very scientific in nature, use SI only. Greg L (talk) 20:28, 29 March 2009 (UTC)
    My apologies for getting a bit sidetracked from the precise proposition. It makes sense to start with kilometres in articles about France and astronomy, and yards in ones about American baseball. The question to me (and as it was originally posed) is this: should there be a general preference as to the starting unit for articles which have no clear tie to science, technology or a particular country?
    My response is this: if most of the ordinary English-language readers (not editors) are in the United States, I don't think that they're particularly well-served by making unfamiliar metric/SI measurements the principal ones (followed by conversions to U.S. customary), rather than the other way 'round. But if the bulk of Wikipedia's readers are outside the U.S., it would make just as little sense to have a rule preferring U.S. customary measures. So, both because this is uncertain and because I dislike extending the already-gargantuan reach of the MoS (of which the huge and endlessly-debated MOSNUM is just one sliver) any farther than absolutely necessary, I just don't favour such a suggested rule, well-intended though it certainly is.
    Any existing variations and inconsistencies are (like those in U.S. vs British spelling) ones that don't seem to have caused any great difficulty so long as conversions are provided. (If we do find that 70-80% of our readers are either inside or outside the U.S., then some non-prescriptive guidance might well be in order.) —— Shakescene (talk) 21:33, 29 March 2009 (UTC)
      • Much as I'd like our readings to agree, Greg, I'm afraid they might not. If an article is associated with the U.S., we agree that (normally) U.S. Customary measures should be used (with conversion to metric/SI). We also agree that in technical and scientific articles, the normal preference would be to start with SI (metric) measurements. The same applies to articles about metric countries (including articles dealing with Canada, Britain and Ireland in the present, though not always those about their past). This, as I understand it, follows the Manual of Style as it's currently written.
      • But the specific question is what about non-technical articles that have no particular connection to a specific country? As I read your comment above, you'd want a rule that favours SI (Système International) as a starting system, while I say (at least for the moment or until we find a great disproportion in our readers' base) prescribe nothing. —— Shakescene (talk) 23:04, 29 March 2009 (UTC)

    The wording I proposed would not change the recommendation for US based articles, which are supposed to be US measures first, or for UK based articles, which may be either Imperial first or metric first, as long as the choice is consistent in the individual article. The wording I proposed applies to general articles, that is, articles that are not based on one country, like Mountain, Lake and Ocean, which are already metric first. The wording recognises and accepts the status quo. Do I have consensus for making this change to the Manual of Style? Michael Glass (talk) 01:32, 30 March 2009 (UTC)

    Oppose: I dissent from (and thus do not join any consensus for) adding "and general articles" to the text proposed at the top. I hate to be so repetitive or so short, but somehow my point (whether you agree with it or not) gets lost. It's not the subject that concerns me, it's the readers. If most of the readers of a non-technical general article like Oceans are in the U.S. and thus unfamiliar with square kilometers, etc., then I don't think we should be advising (or, given the peremptory way MOSNUM is currently being imposed, all but ordering) editors of such general articles to use SI measurements first. On the other hand — whether or not most readers are in the U.S. — I don't think we should be telling them to start with U.S. Customary (or Imperial) measures either. While I certainly respect the intentions and views of other editors here, I think (at least until we get more information, and perhaps even afterwards), we should leave the Manual's language just the way it is. —— Shakescene (talk) 03:19, 30 March 2009 (UTC)

    At the moment there are two policies on weights and measures on Wikipedia. One is to be found at [15] and the other can be found at [16]. Instead of worrying about adding sentences or phrases to either of the policies, our time would be better spent making sure that both policies are consistent. Michael Glass (talk) 20:35, 2 April 2009 (UTC)

    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_120&oldid=1142534975"