Misplaced Pages

talk:Manual of Style/Dates and numbers: Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages talk:Manual of Style Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 03:31, 23 August 2007 editMJCdetroit (talk | contribs)Extended confirmed users19,377 edits →Metric/SI only: Don't like the conversions...skip them← Previous edit Revision as of 03:44, 23 August 2007 edit undoTony1 (talk | contribs)Autopatrolled, Extended confirmed users, Pending changes reviewers, Template editors275,858 edits →Metric/SI only: Removing conversion clutter from non-US articles is the sensible thing to do.Next edit →
Line 335: Line 335:


::::::Don't like the conversions in parentheses; then skip over them when you read the article. That's why they are in the parentheses. Unless of course it is your system of measurements that is in the parentheses. &mdash;] 03:31, 23 August 2007 (UTC) ::::::Don't like the conversions in parentheses; then skip over them when you read the article. That's why they are in the parentheses. Unless of course it is your system of measurements that is in the parentheses. &mdash;] 03:31, 23 August 2007 (UTC)

*I strongly agree with the push to reduce unreadable clutter in non-US articles, and I have little time for people who can't or won't take on the world-standard measurement. (I also have no time for US obstruction of and refusal to join such institutions as the World Court; it's outrageous.) If this proposal is to move forward, it will have to be raised at MOS as well. ] 03:44, 23 August 2007 (UTC)


==Contradictions II== ==Contradictions II==

Revision as of 03:44, 23 August 2007


Archives
General Binary prefixes Years and dates See also

editArchive
Years and dates archives

Centuries

Centuries should always be written out in prose (i.e. "eighteenth century") and should never be written using numerals. Both the MLA style guide (in section 3.5.5 of the 6th edition) and the Chicago style guide (in section 9.36 of the online edition) recommend this style. Awadewit | talk 21:38, 7 July 2007 (UTC)

The only argument I can think of against this is that those two style guides are aimed at people who are fluent in English, but for some Misplaced Pages readers, English is a second language. It might be easier for someone who is not fluent in English to understand 18th century than eighteenth century. --Gerry Ashton 22:11, 7 July 2007 (UTC)
If someone is having that many problems, wouldn't the simple English wikipedia be better for them? I did think that the English wikipedia was for people fluent in English. Awadewit | talk 22:37, 7 July 2007 (UTC)

Contradiction

  • Nothing against (at least) allowing for centuries to be spelt out (note, however, that their corresponding article titles are not) but I see not reason that we need conform to either MLA or Chicago. Jɪmp 15:16, 8 July 2007 (UTC)
  • I thought that we were aiming for "professional" writing standards. MLA or Chicago is one way to define them. Right now, the MOS is not really a MOS since so much of it simply says, "do what you want, within reason and consistently". It would really be best if wikipedia had an in-house style. MLA and Chicago are the most common. That is why I used those. They are also the two most cited in debates at FAC, etc. Awadewit | talk 21:22, 8 July 2007 (UTC)
  • We are "aiming for 'professional' writing standards." I would agree. "MLA or Chicago is one way to define them." I would agree with this too (emphasis added). I don't know that an MoS becomes more or less of an MoS by becoming more or less prescriptive but in this case perhaps stricter rules might help. Yes, it would be best if Misplaced Pages had an in-house style ... that's what we're working on but it'll be Misplaced Pages's style not someone else's. This should be arrived at through consensus of Wikipedians not simply by reference to some other style guide. Quoting other style guides is all well and good as a step towards reaching such consensus but should not be used in place of it ... not that I'm accusing anyone of so doing (one way of gaining consensus it to throw something on a page and see how long it stays). Note also that I'm not opposing your edit: I'd suggest where ordinals can be spelt out in one or two words they generally should be within text. Jɪmp 04:33, 9 July 2007 (UTC)
A MoS is supposed to be prescriptive, by definition. Consensus usually does not achieve a prescriptive style (note wikipedia's current MOS and this discussion which seems to be drifting off topic slightly). It is helpful to rely on other style guides which ponder these questions much more deeply than we. Awadewit | talk 05:27, 9 July 2007 (UTC)
I s'pose I meant to refer to how much detail the prescription contains. Is it better for an MoS to be more detailed in its prescription? Perhaps consensus does usually "not achieve a prescriptive style" but this is not to say that it cannot. Where it does not succeed, though, you've got to ask why. Is it that parties cannot agree, is it that no one could be bothered, is it that consensus is against a prescriptive approach? For better or worse, though, this is how its done here. It may be helpful to refer to other style guides which may indeed have a greater depth of ponderance but these are no substitute. We are getting off topic, yes, but I did mention I'm not against your edit itself. I reckon that Art LaPella has a very strong argument: this page specifies spelling intergers from zero to ten out & doing the same for ordinals as for cardinals since century names from the tenth BC to tenth AD contain ordinals this entails their spelling out. As for the likes of the twenty-first century, is this any worse than writing 21? I would say that it isn't and so if we've got 21, then we'll have to cop 21st century. My argument is, though, that we needn't have to have 21 either. I fail to see any logic in stopping at ten. It had been mentioned before that an alternative might be to spell out those numbers which can be written as one or two words. Yes, there's an example of consensus' failing: the topic was archived and we're still stuck with ten. It can, of course, be brought up again & I think I might ... Jɪmp 07:07, 9 July 2007 (UTC)

Dates are usually considered separately from other numbers (I don't know why, but they are). One of the reasons that I mentioned these other style guides in the first place is because they define professional writing. When I see "21st century" I recoil in horror. Such typography does not appear in professional prose (at least in the humanities). However contradictory it may seem, that is the way it is - dates are treated differently. I simply wanted to raise the issue that wikipedia's MOS reflects an unprofessional style. Awadewit | talk 07:16, 9 July 2007 (UTC)

I don't recoil in horror at either convention. I'm not convinced that there should be a rule at all, but since there is, how should I edit the Main Page to keep everybody happy? If your rule is that dates are treated differently, then say so in the rules. As it is, if I take your rules at face value I should sign this "July Ten". Art LaPella 03:15, 10 July 2007 (UTC)
Manuals of style are all about rules. Also, please look at the title of this section - it is a discussion about how to treat centuries. Days of the month have separate rules. The Chicago manual of style and MLA both say that days should not be spelled out (section 9.35 in Chicago (15th edition - online) and section 3.5.2 in MLA (sixth edition). I quote from Chicago: "When specific dates are expressed, cardinal numbers are used, although these may be pronounced as ordinals." Awadewit | talk 03:27, 10 July 2007 (UTC)
Yeah, July Ten ... okay, dates probably should be considered separately from other numbers. "... style guides ... define professional writing" (emphasis added) or do they describe it ... a well worn debate ... perhaps they do a bit of both ... but either way you've got a point. If this is not how it's done in professional prose, let's not do it here. All I'm saying is that User:Chris the speller is not wrong to have reverted you until the matter had been discussed. For discussion takes precedance over appeal to some other style guide (though such an appeal is an absolutely valid part of such discussion). And discussion is what we're having here and I don't see anyone's opposing the edits that Chris reverted (including Chris). As for myself, I'd prefer centuries to be spelt out (at least those between the one hundredth BC & the one hundredth AD ... just about all that you'd normally want to mention) if only for æsthetics. Jɪmp 04:05, 10 July 2007 (UTC)
Whether style guides "define" or "describe" professional writing is irrelevant. They, in some mysterious way, arbitrate what professional writing is, particularly research-based writing. I did not think that my change would cause a big brouhaha. I think that I was right - the only thing we seem to be really discussing is style manuals themselves. There is no real debate, yet, over the change. As we are all in agreement that centuries should be spelled out, can we make the change now? As much as I love my dog-eared copies of Chicago and MLA, I am not really interested in having an existential conversation about them right now. :) Awadewit | talk 04:37, 10 July 2007 (UTC)
And can we also agree to something like "Whole numbers from zero to ten should be spelled out as words in the body of an article, excluding dates, times and measurements."? Art LaPella 07:06, 10 July 2007 (UTC)
If you exclude measurements, there isn't much left; just counts. I believe that it is customary to spell out whole numbers from zero to ten in general writing, even for measurements, but it is customary to always use numerals in scientific writing. --Gerry Ashton 07:17, 10 July 2007 (UTC)
What is this discussion about? It began about centuries only (note heading "Centuries"). Are we talking about all uses of numbers and dates? Please note that the only changes I have proposed are related to the writing out of centuries discussed here. Can we keep the discussion focused on one thing at a time? It will be much easier, I promise. :) Let's decide the century problem and then move on to the next issue. One step at a time. Awadewit | talk 07:41, 10 July 2007 (UTC)
You're quite right if we're to talk of other issues this should be done under another heading. "Whether style guides 'define' or 'describe' professional writing is irrelevant." ... absolutely hence my "either way" bit. You never know where the next brouhaha is going to pop up. The point that it "might be easier for someone who is not fluent in English to understand 18th century than eighteenth century" has been brought up ... whilst this is true I'd suggest that for such readers there would exist far greater obstacles to comprehending Misplaced Pages than ordinals spelt out as words. "can we make the change now?" Why not? But hasn't the existential conversation been fun? Jɪmp 19:52, 10 July 2007 (UTC)
I have changed the MOS. Awadewit | talk 22:31, 10 July 2007 (UTC)
Should the actual articles be moved as well then? 18th century→eighteenth century and so on? Otherwise we'll be having a hard time trying to copyedit countless existing references to use the spelled-out version since the main articles are still using numbers in their titles. What an article is titled is usually a clue to what a link should be.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 12:33, 11 July 2007 (UTC)
What a nightmare domino effect! This is why I usually try not to get involved in these things. The article titles should probably be changed, but since the rule is only about prose, I'm not sure that it is absolutely necessary. Isn't the redirect enough? What do others think? Awadewit | talk 12:55, 11 July 2007 (UTC)

However

Millennium
Centuries
  • '
Timelines
  • ]
  • ]
  • ]
State leaders
  • '
Decades
Expression error: Unrecognized punctuation character "{".
Expression error: Unrecognized punctuation character "{".

I would, however, suggest that it be pointed out that spelling out the century name applies to its appearance in prose. Generally when the century name appears in a table, navigation box, info box or the like (such as {{Centurybox}} featured to the right), you'd not want it spelt out. Then there is the question of what to do about titles (be they article names or subheadings). I would not oppose the moving of century articles to spelt-out versions but would like to note that this would involve a lot of work. Jɪmp 23:57, 10 July 2007 (UTC)

I said that centuries should be spelled out in prose in the MOS change that I made. Doesn't that address this concern? Should the table, etc. issue be made clearer? Awadewit | talk 00:34, 11 July 2007 (UTC)
Oh, yeah, so you did ... but I reckon it might be helpful if it were pointed out that unspelt-out century names are generally preferred in (titles), tables, etc. Jɪmp 00:43, 11 July 2007 (UTC)
I say be bold and change that right away. Awadewit | talk 03:11, 11 July 2007 (UTC)

Hold on, can we look at some stats?

I'm late in joining this discussion, but I strongly prefer to see centuries written in numbers (no strong views on pre-10th centuries!). Can I draw to your attention some statistics? If you search in Misplaced Pages you find usage as follows:

"seventh century": 897
"7th century": 3207
"sixteenth century": 2,638
"16th century": 11,433
"twentieth century": 12,503
"20th century": 41,221

So a large majority of editors (more than 3:1), whether addressing ancient or modern topics, have chosen to use numbers for their centuries. That looks like near-consensus. The Guardian newspaper's Style Guide, which many UK people accept as a useful handbook, specified "sixth century, 21st century, etc" . I hope that we can reconsider this decision, as it seems to go against the majority view of active editors: a small group of people here are telling three-quarters of editors that they are wrong. PamD 10:31, 12 July 2007 (UTC)

A bit more research: Encyclopedia Britannica online: "Sixteenth century" 95 and "16th century" 4623. Grove Dictionary of Music 51:500 for the same pair. But Oxford Dictionary of National Biography seems to have a style guide specifying spelled-out centuries. So, practice varies, though the online version of the other large encyclopedia goes for numbers. I suggest that we should not start changing text in article away from the format in which a large majority of editors have written it. PamD 11:24, 12 July 2007 (UTC)
  • I think it's most inappropriate to be forcing the spelling out of two-digit centuries. Personally, I'd much prefer that the insistence was the opposite: ninth century, but 14th century. I really dislike the extra length and, I believe, slightly greater difficulty in reading spelt out two-digit numbers. Tony 11:19, 12 July 2007 (UTC)
Many thanks for these stats, which are I think very persuasive as to correct encyclopedic style. I don't mind "ninth century", but only in articles that don't move on to the "11th century" etc. Johnbod 15:00, 12 July 2007 (UTC)

Month and year

The MoS page currently says:

  • Do not put a comma or the word "of" between a month and year:
    • Incorrect: "December, 1945" and "December of 1945"
    • Correct: "December 1945"

Why is this? When relating a sequence of events in narrative text, not in a time line or a bulleted list or a table, i think the "of" form is bstter style. An invented example: "In December of 1985 there was a further development: Jones wrote to Smith, saying..." Why is that IMO completely reasonable format conceded "incorrect" by the MoS? DES 02:51, 11 July 2007 (UTC)

I'm not sure why it says that either. I already use "of" because it sounds better. I think the comma example is incorrect but not the "of" example. Awadewit | talk 03:10, 11 July 2007 (UTC)
It doesn't sound better at all: it sounds clunky and is redundant, just as "outside of" is unacceptable in formal written registers. Tony 15:19, 12 July 2007 (UTC)
That is a matter of opnion. I have certianly encounterd the usage "<month> of <year>" in formal written history. In any case "clunky" is not much of a reason for an MoS guideline. I maintain that this form emphasizes the sequence more than "In December 1985...". I would favor changing this section fo the MoS. What do others think? DES 16:34, 12 July 2007 (UTC)

The Four Seasons

The MOS page currently has a rule about using season names as an indication of period (hence avoiding "spring 1917" - since this occurred at different times in the Northern and Southern Hemispheres, and not all in the tropics). While I can see this being a problem if reference was to the whole Earth as opposed to a particular country or region - if the context is clearly localised, and the "seasonal reference" has some relevance then what is the point of this rule? For instance, how can there be serious objection (on MOS grounds anyway) to "spring 1917" or even "the spring of 1917" in the context of historical events related to the the Western Front in WWI France? Either the rule needs scrapping as unnecessary, or a short caveat needs adding to it (something like "unless it is clear in context what months are covered by the reference, especially if the weather of the season concerned is not irrelevant to the issue at hand"). A current campaign being mounted by an editor with a very strong POV about "Hemisphere Bias" needs in my opinion to be countered. It would help if he were no longer permitted to hide his trivial but irritating agenda behind an MOS rule. Soundofmusicals 08:54, 14 August 2007 (UTC)

It's northern hemisphere readers, particularly Americans, who I worry will not know when "winter" is in a SH context. Tony 09:10, 14 August 2007 (UTC)
If that is the purpose, it is better achieved with a suggestion, not a requirement, that editors consider specifying the time of the seasons on Southern Hemisphere articles. This could not be used for the anti-bias campaign; and it should only become an FA comment if the article is genuinely unclear. Septentrionalis PMAnderson 18:34, 14 August 2007 (UTC)
I actually think the current rule is pretty sensible - but it needs a slightly stronger caveat about not taking the avoidance of season names too "Biblically". There are clearly many instances where the use of a season name (or names, as "spring and early summer" 1918) is a perfectly appropriate, and quite unambiguous, method of indicating a time period. Something like "The Second World War broke out in autumn 1939" is clearly inappropriate, and "whose autumn??" is fair comment, but "The Battle of Britain was fought in the unusually fine English summer of 1940" is in a totally different class, and may well in fact be a better way, assuming that exact dates are either not appropriate in context, or possibly even unknown or disputed. We know where England is (perhaps except for Americans??) and so the time of year, while imprecise, is clearly not in the least ambiguous. It may well be preferable - for instance if one were making a point about the season being deliberately chosen for strategic or tactical reasons. For Southern hemisphere seasons it is perhaps more reasonable NOT to assume "common knowledge", and say something like "In the summer (December - February) of 1901/1902 there were unprecedented bush fires in the district". I DO think that the MOS needs to be rewritten a bit at this point, anyway. Am I allowed to do it? Sorry if that's a silly question but I've not been in this area before. Soundofmusicals 23:02, 14 August 2007 (UTC)
How would this go as a replacement for the current rule?
Because the seasons are reversed in each hemisphere — while areas near the equator tend to have just wet and dry seasons — neutral wording is often a more appropriate way to describe times of the year (“in early 1990”, “in the second quarter of 2003”, “around September”). A precise date, where known, is usually better still, of course. Do not use a season name if this use results in ambiguity, especially if consideration of the time of year adds no real information. For instance it is ambiguous to say that "Apollo 11 landed on the Moon in the summer of 1969" — whose summer? On the other hand where the season is in context unambiguous, especially if it has at least some relevance, avoidance of season names should not become too dogmatic. For instance, assuming we are talking about a particular place, "Before the autumn harvest" is probably appropriate, as might be "The offensive recommenced the following spring". For southern hemisphere subjects disambiguation with brackets "that summer (December to February) there was a severe drought" is probably appropriate. Seasons are normally spelled with a lower-case initial.
I am the editor that Soundofmusicals is referring to, and I take issue with his assertion that my edits are POV. A few points:
  1. I try to focus on seasonal references when those seasonal references are de facto date references and the season appears to have no real impact on the events concerned. These are the only ones I consider questionable.
  2. Usually I suggesting changes on the talk pages of articles and tag the seasonal reference within the article itself. Occasionally I do make a change within the article but I generally avoid this if I cannot confidently make the change myself.
  3. I try not to discriminate between seasonal references for either hemisphere. It appears to be a northern-hemisphere cultural phenomenon that almost all such usage is in articles pertaining to the northern hemisphere. Should I happen to find such a usage in a southern-hemisphere context I would also call it into question in the same manner. Despite Soundofmusicals' unfounded assertion of POV bias, I try to be impartial; it is not my own bias but the northern hemisphere bias in Misplaced Pages in general that makes it necessary for me to question a lot more seasonal references for the northern hemisphere.
  4. I am not perfect, I sometimes tag the wrong references. Good editors will recognise the fallibility of others and will be able to refute the need for such changes with clarity and in a reasonable manner.
This disagreement arose when I queried the following seasonal references on the Sopwith Triplane article: (1) By the autumn of 1917, (2) in the spring of 1917. (Click here to see these in context.) In my opinion these were in violation of the MOS because they appeared to be examples of seasons used as dates, and a reason for giving seasonal context in these instances was not established within the article. Instead of defending the need to retain these references within the scope of the MOS, this editor chose to attack me on the talk page of the article, and apparently got so worked up at my questioning this wording that he ran off to this MOS talk page in order to force through his own POV in the MOS so I cannot cite it in future as a reason to use more neutral wording.
His proposed wording change in the MOS is not acceptable, particularly in that it imposes a northern-hemisphere POV: For southern hemisphere subjects disambiguation with brackets "that summer (December to February) there was a severe drought" is probably appropriate. This POV must not be imposed in the MOS as it is in contravention of geographical NPOV guidelines. The example of an acceptable seasonal reference The offensive recommenced the following spring given as another example is vague and incomplete and some clarification is required here. If the war restarted because it was too cold to fight during the winter, this is acceptable if the reasons are explained and it is appropriate (... once the snows thawed, enabling supplies to be transported) but it is not acceptable if the seasons had nothing to do with the events and appear to be just a date reference (... after diplomatic efforts to bring peace failed). A well-written article will use seasonal references judiciously to convey a clearer picture of what is going on and also provide dates to clarify when things are going on. A well-written article will not confuse the two; that is, it will not use seasons as a substitute for other date references to describe when things are going on.
This only pertains to seasons being used as a substitute dates. When discussing the seasons themselves, or their effects, these guidelines should not apply. -- B.D.Mills  (T, C) 03:16, 17 August 2007 (UTC)
I have already answered the substance of this rant on the specific page where it came up. The MOS has been changed NOT because I "forced" it, or, as I may well have done, changed it myself, but because the consensus was that the rule you invoked so dogmatically was pedantic in the extreme, unnecessary, and POV driven, and badly needed moderating. PLEASE don't get into a revert war with the people (NOT ME) who changed it - accept that this is yet another case where you are wrong, and have been from the start.
WHY is your attitude POV? Basicaly, because, far from being driven by a genuine desire to improve the style of Wiki articles it concentrates on your peculiar idea that "Southern Hemisphere People" are a some kind of persecuted minority who need YOU to protect their right to have NOT their religion, nor their culture, nor their language but their SEASONS (of all things) recognised as equally valid with those of the evil oppressive Northern Hemisphere people. All I can say is I do wish you could have a go at being a real member of a real persecuted minority (of whom there are, alas, far too many in this wicked world) - it might bring you to your senses a bit!!
I haven't done a detailed survey and I have no intention of doing so, but I suspect that about 80% of all mentions of seasons of the year in Wiki are pretty justifiable, and ones that given a moment or two of even your thought are quite appropriate. Of the remainder - most are probably very like the Sopwith Triplane example - really pretty much six of one and half a dozen of the other. WHO CARES? I don't care enough to revert it - but I still say that to claim bluntly that the article as it was was "in violation" of the MOS was (even with the rule as it was) extremely silly. Changing it may make very little difference - but that is the whole point - it cuts both ways, doesn't it???
The very tiny percentage of cases (most of them manufactured) of real "hemispherical bias" that have been demonstrated that ARE objectionable - NOT as a matter of persecuting poor SH folk by the way, but because of poorly written and ambiguous style - are very well covered by common sense anyway - but are still quite specifically covered by the rule in its modified (advisory rather than prescriptive) form. My suggestion was if anything kinder to you, in that it treated your basic idea much more sympathetically. None the less I am more than happy with the new rule. Are you? If not, why? If so - for goodness' sake let's hear no more of this!
Now - how about finding something that is not a misuse of your evident gift of eloquence. A more worthy cause, in fact. And doing it. Now. Soundofmusicals 05:52, 17 August 2007 (UTC)

Projects adopting their own MOS

Is this actually possible? --fullcourt 23:14, 11 July 2007 (UTC)

I suspect the editor is just confused about the difference between bare years and full dates. A WikiProject can usefully make its own guidelines specific to its subject area, but they shouldn't contradict the encyclopaedia-wide guidelines. Stephen Turner (Talk) 00:19, 12 July 2007 (UTC)

Coordinates, again

See also: Misplaced Pages talk:Manual of Style (dates and numbers)/Archive 70

Time to deprecate 'coor *' templates

Now that Google Earth have confirmed that they are parsing {{coord}}, and WikiWorld and Geo Names have said that they will do so, are people content to restore the wording removed in this edit, deprecating the older coor * coordinates templates? Andy Mabbett 14:56, 26 June 2007 (UTC)

Put it another way: I shall do so, shortly, unless anyone objects. Andy Mabbett 16:41, 27 June 2007 (UTC)
Do we have a real world in the wild example of {{coord}} actually being parsed and appearing in the wild? If not, it is too early. Regan123 17:43, 27 June 2007 (UTC)
I fail to see why that's a requirement. Andy Mabbett 17:52, 27 June 2007 (UTC)
How do we know it is working until we can see an example. Therefore I object until one is seen. Regan123 17:57, 27 June 2007 (UTC) Additonal: It appears that {{coord}} has not made it over to Google Earth yet. See . Regan123 18:01, 27 June 2007 (UTC)
See http://earth.google.com/userguide/v4/geoweb_faq.html Andy Mabbett 18:26, 27 June 2007 (UTC)
I have seen the FAQ. There is still the issue that coord is not actually shown to be working with Google Earth in the wild, unless you have an example that shows that it is? When that can be shown then depreciation, conversion, deletion and amending the MOS is not an issue. At the moment it is. Regan123 18:41, 27 June 2007 (UTC)
We do have examples in the wild of {{coord}} showing up in geonames (Para captured one - Netherton Tunnel Branch Canal) plus http://earth.google.com/userguide/v4/geoweb_faq.html (which announces that coor has been deprecated by Misplaced Pages, rather to my surprise) so I am content to accede to the restoration of the wording per nom. (I think conversion and deletion need an overall plan as adumbrated on AM's talk page by the Anome, which I would also support.) -- roundhouse0 20:19, 27 June 2007 (UTC)
Curiously that particular article is no longer visible in GeoNames service, though some others with coord are. The disappearance may be related to a bug on their side where they weren't showing the most important coordinates from the article, but the first found. Anyhow, people are mostly interested of Google's support, and Google Earth doesn't show any of the coordinates that have been on Misplaced Pages with coord only. On the support they have said that "We can make our parsing tools recognize the new template; however, we definitely do not want our decision to support this template to be misconstrued as an endorsement or ultimatum." The arguments here shouldn't then be that Google is recommending the template, but that they are now supporting it. We seem to have trouble agreeing on what "support" actually means.
Almost everyone involved in this so far has agreed that we should help maintain the quality of Misplaced Pages data in notable external services, and that's why we're talking about it here. Basically we could deprecate a data entry format with external dependencies when a) a wikipedian says that an external service is planning to support the new template, or b) when an external service announces that they are planning to support the new template, or c) when an external service announces that they are currently supporting the new template, or d) when we can verify that an external service is supporting the new template but seems to be struggling, or e) when we can verify that an external service is correctly supporting the new template in all the use cases we have.
Personally I would go somewhere after c, where we actually are now for the most part. Our database dumps are so few and far apart that if someone has problems changing their parser, it may push our migration months forward. In this case that might not matter though, as the change isn't critical. I'm just disappointed on how the new template has been allowed to spread without ensuring the support before. With Google Earth we're currently in the situation where the new coordinates added using coord are not visible to the users, and it's also uncertain what has happened with coordinates that have been converted from the current templates to coord. But that's where we are now, and it wouldn't be very convincing to pretend that we can keep a narrow field such as geographical coordinates under control, when we have seen how people determined to get their way through really can do so. What the Manual of Style says now as a guideline isn't going to change a whole lot one way or the other. --Para 23:46, 27 June 2007 (UTC)
"The arguments here shouldn't then be that Google is recommending the template" - See http://earth.google.com/userguide/v4/geoweb_faq.html Andy Mabbett 08:58, 28 June 2007 (UTC)
What's written in the FAQ is just a misunderstanding of what's going on in Misplaced Pages, based on what a single wiki contributor out of hundreds of thousands has told them. They may just be far-sighted and don't want to constantly be updating the page to reflect the state of an everchanging community. So far nothing has been deprecated and the only Google person who has communicated with us has said that "we definitely do not want our decision to support this template to be misconstrued as an endorsement or ultimatum". Therefore you must not use anything from Google to endorse deprecation. The issue here is whether for us support means a public announcement of it or our verification of the data being visible. --Para 11:54, 28 June 2007 (UTC)
"based on what a single wiki contributor ... has told them" - really? Who's that? Google have said more than once that they're parsing coord, and are happy for us to start converting existing coor * templates to coord. That's a matter of record. the argument for deprecating coor * templates in favour of coord is that coord offers far greater functionality for our editors and users. That should be enough, but some wanted to wait until Google Earth and other external bodies were aware of, and then until they were parsing, coord. Now that they are, they seem to want to introduce further, unnecessary, delays. Andy Mabbett 12:09, 28 June 2007 (UTC)
This is not about how Google feels about the template, they're not part of Misplaced Pages. The community here wants to see the data in Google's service, and so far none of it is there, despite it having been available in all the database dumps since April. The single contributor who has agressively pushed the change forward regardless of support or its absence would be you my dear Andy. You could have avoided all this if you had just discussed with the community in the beginning of the terms of the change and tried to reach consensus, instead of ignoring them and then pretending to be representing the whole of the community with your personal opinion. The delay may feel unnecessary to you, but as you have seen repeatedly, it is not for others. --Para 12:31, 28 June 2007 (UTC)
"This is not about how Google feels about the template, they're not part of Misplaced Pages" - quite, which is why (that fact we know that they're aware of coord, and have said they will parse it, not withstanding), we should go ahead on the basis described by SEWilco, below. I have been discussing coord and trying to reach consensus for some time now; it's difficult to do so when the goalposts keep moving, as I've recently described, and when a handful of editors keep making unfathomable or simply false claims about what's proposed. Andy Mabbett 13:30, 28 June 2007 (UTC)
Coord follows no standard, it's just an improvement over the existing templates, and unrecognised at that. Had you tried to reach consensus at first before starting to apply coord in articles and templates, you could always refer to that discussion and its goals, pointing out that that's what the community wants. Instead it's all in bits and pieces everywhere of the shortcomings of the template and about it having been applied prematurely. The discussions always get sidetracked and you never try to direct it back to the original propositions. Such discussions show no consensus. It is very tiring to have this bickering every time you try to move forward with whatever it is you're doing. I can just see you insisting on doing the eventual conversion little by little starting as soon as possible, instead of all at once after a long discussion somewhere. Disagreeing people will come in trickle and you end up defending your position over and over again without anything to back it up with, but still go ahead with the project. Oh yes, my crystal ball is mighty, and I for one want nothing to do with all that. --Para 16:21, 28 June 2007 (UTC)
Coord both follows standards and is a standard. Of course it is "recognised"; and I did reach consensus first. I agree with you about the tiresomeness of the bickering; feel free to stop at any point. If your arguments rely on a crystal ball, don't expect me or anyone else to be swayed by them. I can't see how your edit summary, "AM fails" is either meaningful or helpful. Andy Mabbett 16:33, 28 June 2007 (UTC)
Or we just use coord because it follows a standard, whether an external service is presently using the information or not. (SEWilco 00:16, 28 June 2007 (UTC))
Amen! All the services concerned are aware of that standard, have said that they will use it, and in the case of Google Earth, have said that they are happy for us to convert existing coordinate templates to it. I still fail to see why we are delaying the provision of {{coord}}'s extra functionality to our many users. Andy Mabbett 08:58, 28 June 2007 (UTC)

Whatever it's worth, there seems to be some misunderstanding by the author of http://earth.google.com/userguide/v4/geoweb_faq.html as Misplaced Pages hasn't really depreciated the other templates.

Either solution would still need to address the problem of {{coor dms}} or {{coord}} being used within other templates. In these cases, {{coord}} just adds a lot of overhead and formatting problems, but it's unlikely that it's being parsed by anyone.

A solution, formulated by sk on Wikipedia_talk:WikiProject_Geographical_coordinates#Formats, is to standardize variable names (e.g. "latitude_degree") to indicate coordinates in other templates, such as Template:Geobox Settlement (which currently uses lat_d, lat_m, lat_s, lat_NS, long_d, long_m, long_s, long_WE). -- User:Docu

Meersbrook (53.353889,-1.472778) tagged with coor title d by Anombot2 on March 14 and then subjected to a struggle between coor title d and coord, doesn't seem to show up in either geonames or Google Earth. Sheffield Cathedral (53.383,-1.4694), which I changed from coor title to coord on May 18, also shows on neither. (Google Earth has added a lot of Sheffield tags in the last week, eg Fargate, coor title d, April 17.) An example of coord showing up unequivocally on Google Earth would certainly be handy. -- roundhouse0 08:15, 28 June 2007 (UTC)
why would it? Andy Mabbett 08:58, 28 June 2007 (UTC)
I withdraw the support given above, as AM persists in turning a blind eye to objections. -- roundhouse0 12:15, 28 June 2007 (UTC)
Oh FFS! To what objections do you think I have "turned a blind eye"? The evidence cited in your now struck-through post remains: We do have examples in the wild of {{coord}} showing up in geonames (Para captured one - Netherton Tunnel Branch Canal). Andy Mabbett 12:21, 28 June 2007 (UTC)
"In these cases, {{coord}} just adds a lot of overhead and formatting problems" - please don't make such claims, without substantiating them. -- Pigsonthewing
The formatting problem was acknowledge by Pigsonthewing himself here and the overhead question raised on here, but eluded by pigsonthewing as well. -- User:Docu
What I said about the supposed "formatting problem" was: "This is a bug with the template's use of font-size:90%. Please fix that and do not remove microformat markup as a work-around." In the end, I did fix it, but you reverted that. I "eluded" nothing; you asked if something was a problem, and nobody seemed to think it was; though I pointed out to you that "it would seem far more sensible for any concerns you may still have to be raised on the template's talk page, where the author of the template is more likely to see them". Did you do that? Andy Mabbett 11:18, 28 June 2007 (UTC)
"it's unlikely that it's being parsed by anyone" - that's already provably false. You keep making false claims about coord. Why? Andy Mabbett 08:58, 28 June 2007 (UTC)
Why is that claim false? You already avoid responding answering to questions about {{coord}} being used directly in articles, so why do think using {{coord}} on Templates would work? Are there any users who claim they would support it? -- User:Docu
Just a few entries above your claim is roundhouse0's post time-stammped "20:19, 27 June 2007 (UTC)". If you think I've failed to answer any questions about coord, please point them out and I shall do so ASAP. Using coord on templates does work. Why would you think otherwise? Many users do support it, not least in this section of this page. Andy Mabbett 11:18, 28 June 2007 (UTC)
Google doesn't. Googel even claims it's "depreciated" to use coordinates on article in any other template on articles, but {{coord}} - odd no? -- User:Docu
<sigh> Google does'. See http://earth.google.com/userguide/v4/geoweb_faq.html Andy Mabbett 11:26, 28 June 2007 (UTC)
Would you provide us with a quote explaining that google does support using {{coord}} on Templates? -- User:Docu
See http://earth.google.com/userguide/v4/geoweb_faq.html Andy Mabbett 11:41, 28 June 2007 (UTC)

This FAQ does not say that Google supports using {{coord}} in templates. Since this is also an issue for other geo data consumers I think sk's approach is worth considering. I think it is premature to change this MoS until it has been decided whether to use that approach. -- Patleahy 16:00, 28 June 2007 (UTC)

The cited FAQ makes it abundantly and unambiguously clear that coord in other templates is parsed by Google Earth. sk's approach is untenable, for the reasons given at the link you cite. Andy Mabbett 16:36, 28 June 2007 (UTC)
Let me re-iterate my request, would you provide us with a specific quote from the FAQ, rather than just an URL? -- User:Docu
"This template can be used anywhere within the article text.". My emphasis. Andy Mabbett 16:58, 28 June 2007 (UTC)
"article text" = Article namespace. -- User:Docu

Accuracy of coordinates

Pardon me for jumping in here. I have not been following this discussion, and am unsure whether this is the proper forum for raising an objection to the current usage of coord. Perhaps what I have to say will be relevant to the ongoing discussion & reevaluation. I have found that the coordinates published in Wiki for many high-rise buildings are seriously incorrect, compared with NGS benchmarks, surveyor measurements, GPS measurements, and the FAA & FCC databases. This is apparently because the "coord" information has been derived from Google Earth. The latter has a notorious parallax problem with high-rise structures due to not looking straight down on these structures. Centering on a rooftop will generally give a considerable error. (Somewhat better accuracy is achievable using a building's footprint, when that is sufficiently visible). The illusion of great accuracy is given when the coordinates are stated to the hundredth of an arcsecond, but what use is that when the error can be two full seconds or more? If I substitute well-established NGS, FAA and/or FCC coordinates for the erroneous ones, will my edits only be reverted by a robot? Am I misleading users of Google Earth who will expect the erroneous coordinates, in order to facilitate locating the structure? That would seem a case of the tail wagging the dog. Shouldn't we be providing the best available information, regardless of possible impact? Hertz1888 23:33, 28 June 2007 (UTC)

This is better discussed at Misplaced Pages talk:WikiProject Geographical coordinates (feel free to move my comment). I agree with everything you said, though Google Earth certainly isn't the only source for our coordinate data. Perhaps the footprint part would actually be on topic in the Manual of Style as well? It would be best if any automatic changes would first compare the distance of the two points and put differences too long on the talk pages instead. Could there be a database rights issue with the use of the whole of such data though? Anyhow, please continue at the project talk page. --Para 00:02, 29 June 2007 (UTC)
Note also that WikiProject Geographical coordinates has a section on issues of precision. Andy Mabbett 09:05, 29 June 2007 (UTC)

Thank you both, Para and Andy. I will pursue as time permits. Clearly the global or generic implications of this issue are far-reaching, when the question of automated reference to databases is brought in (well beyond the scope of my original query). For all its easy access and convenience, Google Earth and its cousins seem to have brought with them a tendency for overdependence. When coordinates are derived by centering on portions of structures well above ground level (e.g., rooftops or spires), and the camera was not directly above the structure, the results will inevitably embody gross errors. Hertz1888 01:04, 3 July 2007 (UTC)

On re-reading your original comment; I should also point out that the issue is not related to {{coord}} and applies equally to the old coor * templates, and indeed any others which use coordinates. Andy Mabbett 14:46, 5 July 2007 (UTC)

Misplaced Pages has announced that Google Earth supports coord

Note also that Misplaced Pages itself has now announced that Google Earth supports coord. Andy Mabbett 14:46, 5 July 2007 (UTC)

Please see Template_talk:Infobox_UK_place#Google_Earth_compatibility:_geotags_are_invisible Regan123 17:14, 5 July 2007 (UTC)
Thank you. I have done, and have replied there. My point remains: Misplaced Pages has announced that Google Earth supports {{coord}}. Andy Mabbett 19:26, 8 July 2007 (UTC)
We have articles using coord that have vanished from Google Earth. Regardless of what they say, evidence these articles have reappeared is needed before changes. Regan123 20:38, 8 July 2007 (UTC)

It looks like the Misplaced Pages Signpost got it somehow wrong as Google doesn't claim to support {{coord}} within templates. -- User:Docu

I refer you to my earlier refutation of your fallacious belief. Please stop spreading FUD. Andy Mabbett 08:07, 9 July 2007 (UTC)
Please provide a link to your "earlier refutation" rather than resorting to personal attacks. -- User:Docu
What "personal attacks"? Andy Mabbett 19:11, 9 July 2007 (UTC)

Standardize names for coordinate variables in template namespace

Following the lenghty discussion above, please see a proposal for a section to be added to MoS at Wikipedia_talk:WikiProject Geographical coordinates#Standardize names for coordinate variables in template namespace. -- User:Docu

(previous comment by Docu (talk · contribs) There is no consensus for this change, which was not included in the proposal at the above link. Andy Mabbett 14:16, 5 July 2007 (UTC)

Deprecating old coordinates templates

Once again: are people now ready to begin deprecating and replacing the old coor * family of templates in favour of {{coord}} ? Andy Mabbett | Talk to Andy Mabbett 22:40, 7 August 2007 (UTC)

As Regan123 points out above, people want to see the fruit of their work in the external services before they can be sure the changes here are properly supported. I still can't see any articles in Google Earth that have had coord coordinates only. --Para 09:30, 8 August 2007 (UTC)

Can we end the coordinates section dispute?

I would love to remove the disputed tag I added to this section months ago. Now that User:Pigsonthewing (aka Andy Mabbett) is blocked perhaps we can have a discussion leading to consensus on the wording. Can someone suggest wording for this section? Thanks, Patleahy (talk) 16:13, 20 August 2007 (UTC)

The standardized template parameters are already at the end of the section. What other issues remain? I suggest a new discussion with a list of remaining issues, if any. (SEWilco 22:10, 20 August 2007 (UTC))

minus signs

This page says:

The minus sign may be represented by a hyphen ("-") or by &minus; ("−").

The hyphen is far too short for that purpose. No respectable typesetter would use it. Compare:

5 - 3
5 − 3

Within TeX, of course one uses a hyphen, and the reader sees this:

5 − 3 {\displaystyle 5-3\,}

Michael Hardy 22:48, 27 June 2007 (UTC)

WP:DASH seems to agree with you. Stephen Turner (Talk) 08:55, 28 June 2007 (UTC)
Misplaced Pages editors are not, in the main, typesetters, respectable or otherwise. Andy Mabbett 11:27, 28 June 2007 (UTC)
See also: Misplaced Pages talk:Manual of Style#Minus signs/Archive 82 Jɪmp 15:41, 28 June 2007 (UTC)

Roman numerals

The Transactions of the Linnean Society of London express their volume numbers in Roman numerals. Should I follow their lead and write:

"... and was published in Volume X of Transactions of the Linnean Society of London."

or should I convert to Hindu-Arabic:

"... and was published in Volume 10 of Transactions of the Linnean Society of London."

? Hesperian 04:42, 29 June 2007 (UTC)

  • Why not

    "... and was published in Transactions of the Linnean Society of London, Volume X."

    thereby making it clear that "Volume X" is their usage? Andy Mabbett 09:07, 29 June 2007 (UTC)
Nothing wrong with Roman numerals in my book. Go ahead. I like Andy's suggestion: not only would it be clear to readers that this is their usage but also to any editor who might otherwise feel like changing it to Hindu-Arabic. Jɪmp 23:55, 2 July 2007 (UTC)
Thanks folks. Hesperian 12:41, 9 July 2007 (UTC)

Metric/SI only

Why is their any allowance for non metric systems of measurement? Ancient units I can see, simply for historical purposes, but only the US still uses a system other than metric today; even they are starting to move over. Should not, due to the fact this is a global encyclopaedia, only use the metric system? Spacedwarv 07:19, 7 July 2007 (UTC)

Because the articles should be accessible to everyone. So it's appropriate, especially in articles about the U.S., to use units which Americans are familiar with. Of course, a conversion to metric should always be provided. Stephen Turner (Talk) 09:55, 7 July 2007 (UTC)
Metric is everyone’s system. US units are – well – US-only, Misplaced Pages is not. (Mandatory) dual units lessen readability for everyone, without relevant gain in universal understandability. Christoph Päper
It's not up to you or Misplaced Pages to change the way Americans think. The concept is obnoxious. Chris the speller 01:52, 23 August 2007 (UTC)
And another reason: it's usually correct to quote the units which the source used. Stephen Turner (Talk) 10:23, 7 July 2007 (UTC)
That actually only applies if the source was constituting something using non-metric units, not if it was reporting measurings. Christoph Päper
Also, many people from British commonwealth countries still don't "think" in terms of metric measurements, despite some of their governments being officially metric for years. To use only metric units would actually make the encyclopedia less universal. —MJCdetroit 19:52, 7 July 2007 (UTC)
How should they learn to think metric if they’re nannied with old or dual labels all the time? Christoph Päper
Any chance of a requirement to list all articles in SI instead of a simple recommendation? I can see the logic in that people do not think in it yet, but the acceptance of metric is global and in the few strongholds otherwise, it is inevitable. Spacedwarv 21:58, 11 July 2007 (UTC)
No! Current system is the right compromise, I think. Tony 11:38, 12 July 2007 (UTC)
Yes, too many people do feel or believe that way, not much thinking involved. (Actually I was just checking whether that had changed lately. I’m gone again now.) Christoph Päper

I find the current system just awful when it comes to readability. Most pages you read have both a unit and a conversion. Only 4% of the population are non-metric. That's technically a minority. I'd bet that higher than 4% of the population have "," instead of "." when expressing a decimal number, but "." has been made mandatory. I'd rather see the style for technical and scientific articles adopted for all articles: only SI, except for specific historical reasons. I can see the argument that for example an article on a town in the US, that it is reasonable to have both units. Misplaced Pages is international and non-SI units are way way in the minority. I'm sure all would agree that eventually the US will use SI - so why not lead the way? Jim77742 13:51, 22 August 2007 (UTC)

Please see my reply to Christoph Päper above. The US does not need you to lead it. Chris the speller 01:52, 23 August 2007 (UTC)
OK Jim77742, please try removing the use of "yards" from the article on American Football. ;) Fnagaton 14:18, 22 August 2007 (UTC)
I think I indicated above it would be appropriate to use yards in those types of cases. But it would need to explain what a yard is. Your US yard is defined as 914.4mm (exact). Jim77742 01:25, 23 August 2007 (UTC)

I'd strongly support a dual system in which US-related articles are US units (main) and metric (converted), and all other articles are metric alone. Tony 15:54, 22 August 2007 (UTC)

This is exactly what I'm saying.Jim77742 01:25, 23 August 2007 (UTC)
Me too. In the meantime, I think that the unit section can be simplified and improved. For example, replace the 'Which system to use' and 'Conversions' sections with:
*Editors are encouraged to use the metric system. Non-metric units may be primary at the consent of editors in the following cases:
**The article is US-related and non-scientific.
**The article is UK-related and discusses quantities that are not currently metricated (e.g. road speed in mph).
**There are compelling historical or pragmatic reasons why metric units should not be the main units.
**If editors cannot agree on the sequence of units, put the source value first and the converted value second.
**American English spells metric units with final -er (e.g. 'kilometer'). All other varieties of English, including Canadian English, use -re (e.g. 'kilometre').
* In general, editors should not remove conversions.
* Conversions adjacent to units can sometimes make common expressions (“The four-minute mile”) or quotes awkward. If this is an issue, consider a non-adjacent conversion (e.g. in a subsection).
* In general, units in text should be spelled out. Editors may agree that it is appropriate for text to contain symbolic forms after the first occurrence.
* Units in parentheses should be in symbolic form. For example, "a pipe 100 millimetres (4 in) in diameter and 16 kilometres (10 mi) long” or “a pipe 4 inches (100 mm) in diameter and 10 miles (16 km) long".
* Precision of source and converted values should match. For example, "the Moon is 380,000 kilometres (240,000 mi) from Earth", not "(236,121 mi)".
* Editors may wish to take advantage of conversion templates such as .
Actually, I would eliminate the last five of those bullets. That would simplify it even further. Guidelines should only exist if they solve a significant problem that would not be solved by the wiki. Lightmouse 18:08, 22 August 2007 (UTC)
Agreed. I'd even remove the UK exception. Miles are used on the roads, but that will be gone by the time of the 2012 Olympics. Jim77742 01:25, 23 August 2007 (UTC)

Can I propose the following words (stolen and modified from above :-)

  • Editors are highly encouraged to use the metric system alone without conversions. Conversions make articles less readable.
  • Non-metric units may only be primary (at the consent of editors) in the following cases:
  • The article is specifically US-related and non-scientific.
  • There are compelling historical or pragmatic reasons why metric units should not be the main units.
  • When the non-metric unit is used as primary, a conversion should nearly always be provided. Keep readability in mind though, for example in an article on American Football it would be appropriate to explain that a yard is 914.4 mm exactly the first time a yard is mentioned, but not thereafter.
  • Note that American English spells metric units with final -er (e.g. 'kilometer'). All other varieties of English, including Canadian English, use -re (e.g. 'kilometre') and so this can be simplified by generally using the formal abbreviations "km".
  • In general, editors should not remove conversions from these US-based articles
  • Precision of source and converted values should generally match. For example, "American football is played on a field 120 yards (109.728 m) long" is incorrect. Use "(110 m)" instead. Note that defining one yard (as exactly 914.4 mm) may be approriate.
  • In a direct quotation, if the text contains an obscure use of units (e.g., five million board feet of lumber), annotate it with a footnote that provides standard modern units rather than changing the text of the quotation
  • In scientific articles, SI units are the only units of measure, unless there are compelling historical or pragmatic reasons not to use them (for example, Hubble’s constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s−1)
  • Where footnoting or citing sources for values and units, identify both the source and the original units.

Jim77742 01:25, 23 August 2007 (UTC)

This strikes me as blatantly and staggeringly pro-UK and anti-US. Mountains in England will be measured in metres, conversion to feet being forbidden, while mountains in California will be measured in feet, with a mandatory conversion to meters? Perhaps you think American readers of Misplaced Pages are an extremely small minority? Chris the speller 01:44, 23 August 2007 (UTC)
It's not pro-UK or anti-US it is pro-World. Three countries and 4% of the world's population use imperial units. And even in the US, science, medicine and the armed forces all use metric exclusively. The number of people who do not know what a litre is would have to be very much under 4% of the world's population. This is the internet. Misplaced Pages is not a US thing, it is a world-wide encyclopaedia. I've never read an encyclopaedia that has unit conversions on every measurement. It read's terribly! And while we're on mountains I'd even go as far to say that US mountains should have the primary measurement in metres with a conversion to feet. After all there is a template for all mountains on wikipedia. By the way, your surveyors measured your mountain in metres and then converted to feet for local publication. Jim77742 02:16, 23 August 2007 (UTC)
This is the English Misplaced Pages, correct? According to Wiki's own article on the English language, more than 2/3 of all native speakers are American. That being said, your 4% statistic is worthless. Americans do not only read articles regarding American subjects. So to have US-centric subjects have conversions and all others metric only is unfair if not completely retarded and counter-productive. Your proposal makes wikipedia less universal instead of more universal. The MOS as written is very fair to everyone. —MJCdetroit 02:32, 23 August 2007 (UTC)
The English language article says that 1.8 billion people speak the language and that "Modern English is sometimes described as the global lingua franca". So when you want to speak globally on this planet - you use English. When you want to measure you use metric - that's what the world does. A lot of non-Americans from all over the world read the English Misplaced Pages - and the constant barrage of things like "the 10 km (6.2 mi) long and 100 mm (4 in) wide pipe branches into a 3 km (1.8 mi) long and 70 mm (2 3/4 in) wide pipe and a 7 km (4.3 mi) long and 40mm (1 1/2 in) wide pipe." makes readability so bad. (I know this is an exaggeration but a lot of articles look like this.) On the other side of the coin, the scientific articles with only SI read so much better. Jim77742 03:07, 23 August 2007 (UTC)
Jim77742 misses the point about the mountains example. Having the height of a mountain to the nearest millimeter is not important, it's presenting the information so the readers can understand and grasp it that's important. Using his logic, the majority of native English speakers write "color" instead of "colour", so all of WP should use "color", except in UK and Australia, where we will now write "The national colours (colors) of the United Kingdom are red, white and blue." I am not proposing that, since I am not insensitive to the traditions and feelings of the many readers who still cling to the archaic spelling even though they can understand "color". I am kidding, of course! Chris the speller 03:12, 23 August 2007 (UTC)
Don't like the conversions in parentheses; then skip over them when you read the article. That's why they are in the parentheses. Unless of course it is your system of measurements that is in the parentheses. —MJCdetroit 03:31, 23 August 2007 (UTC)
  • I strongly agree with the push to reduce unreadable clutter in non-US articles, and I have little time for people who can't or won't take on the world-standard measurement. (I also have no time for US obstruction of and refusal to join such institutions as the World Court; it's outrageous.) If this proposal is to move forward, it will have to be raised at MOS as well. Tony 03:44, 23 August 2007 (UTC)

Contradictions II

Here's what I wanted to talk about - someone else moved my heading under "centuries" and then wondered why I want to talk about other contradictions under the wrong heading. If we don't exclude measurements, then it contradicts several examples in the Measurements section - 4 inches, 10 miles, 5° C, and 5 ft. Why do contradictions matter, whether or not they are about centuries? Spelling out numbers zero throught ten is the most frequently cited item on the page in my experience. If we don't tell people to do opposite things at the same time - as defined by the rules Misplaced Pages expects us to follow, not by the Chicago manual - then people would be more likely to obey, cite, and otherwise respect this guideline, and all the other headings on this talk page would be more likely to matter. Art LaPella 20:36, 10 July 2007 (UTC)

That someone else was me. I did so because it sure looked as if you were specifically referring to centuries and that's the way the discussion had been progressing. Sorry to cause you strife. I would say that a distinction can be made between contradictions and exceptions. If we have this spell-numbers-out-from-zero-to-ten-but-not-from-11-up rule, then I'll be signing this post 11 July 2007 in the usual fashion but yours would have to have been something along the lines (the) ten(th) July 2007 or July (the) ten(th), 2007. Would we want this? I'd suggest not. So exceptions should be allowed for. Jɪmp 00:17, 11 July 2007 (UTC)

Does that mean you endorse "excluding dates, times and measurements" or some variation that meets my goal of self-consistency? Or does it mean there should be a general disclaimer that there are exceptions to everything? Art LaPella 15:53, 11 July 2007 (UTC)

I would say that, in general, measurements and times should be excluded. The problem with such a blanket statement is that it is not always true. In a scientific article that is peppered with measurements, numerals make it easier to read, so they should be used. But in other kinds of prose those numerals (e.g. "The book, when originally published in 1778, was four inches square".) might be out of place. Context matters in measurement, I'm afraid. (By the way, I agree with the "exception" theory articulated above.) Awadewit | talk 16:06, 11 July 2007 (UTC)

When someone writes "WP:MOSNUM" in an edit summary, I believe (but I can't think of a good way to prove it) that they usually mean "Whole numbers from zero to ten should be spelled out as words in the body of an article." So I don't think this is a Misplaced Pages:Ignore all rules situation; I think it should be fixed. How about "excluding dates, times and some measurements"? Art LaPella 18:57, 11 July 2007 (UTC)

Since you both like the word "exceptions", how about "Exceptions include dates, times and some measurements"? Art LaPella 19:09, 11 July 2007 (UTC)

Proposed revision of "Numbers in words"

I don't understand the title. Please provide feedback on this new version. Don't you all think it's time to bite the bullet on "billion"? (Except that it doesn't quite belong under the new title.) Should there be guidance on hyphenating spelled out fractions? I've added something, and I'm unsure about it. And what about hyphens in numbers such as "twenty-four"—mandatory or optional?

There's a problem with "*Fractions standing alone should be spelled out unless they occur in a percentage. If fractions are mixed with whole numbers, use numerals." that persists in my proposed amendment ("Fractions should be spelled out unless they occur in a percentage or with an abbreviated unit ("3.5 mm") or are mixed with whole numbers. Fractions are hyphenated ("seven-eighths")."). Fractions seem to be mixed up with decimal points.

EXISTING

Numbers in words

  • Whole numbers from zero to ten should be spelled out as words in the body of an article. Use numerals in tables and infoboxes.
  • Numbers above ten may be written out if they are expressed in two or fewer words, except in tables and infoboxes. Example: "sixteen", "eighty-four", "two hundred", "twenty million" but "3.75", "544", "21 million".
  • Proper names and formal numerical designations should instead comply with common usage. Example: Chanel No. 5, 4 Main Street, 1-Naphthylamine, channel 6.
  • Within a context or a list, style should be consistent. Example: "There were 5 cats, 12 dogs, and 32 birds" or "There were five cats, twelve dogs, and thirty-two birds", not "There were five cats, twelve dogs and 32 birds".
  • It is considered awkward for a numeral to be the first word of a sentence: recast the sentence or spell the number out.
  • Fractions standing alone should be spelled out unless they occur in a percentage. If fractions are mixed with whole numbers, use numerals.
  • Ordinal numbers should be spelled out in words using the same rules as for cardinal numbers. If digits are used, the ordinal suffix (e.g., "th") should not be superscripted. For example, "fourth", "twenty-third" or "23rd", "496th".

NEW

Spelling out numbers

General rule

  • In the body of an article, single-digit whole numbers (from zero to nine) are spelled out; numbers of more than one digit may be spelled out only if they are expressed in one or two words ("sixteen", "eighty-four", "two hundred", "twenty million" but "3.75", "544", "21 million"). Many people prefer all multi-digit numbers to be expressed generally as numerals, within the bounds of the exceptions below.

Exceptions

  • Dates and times.
  • Numerals that open a sentence are spelled out; alternatively, the sentence can be recast so that the number is not in first position.
  • In tables and infoboxes, all numbers are expressed as numerals.
  • Within a context or a list, style should be consistent (either “There were 5 cats, 12 dogs and 32 birds” or “There were five cats, twelve dogs and thirty-two birds”, not “There were five cats, twelve dogs and 32 birds”).
  • Fractions are spelled out unless they occur in a percentage or with an abbreviated unit ("3.5 mm", “⅛ mm”) or are mixed with whole numbers.
  • Ordinal numbers are spelled out in words using the same rules as for cardinal numbers. If digits are used, the ordinal suffix (e.g., "th") is not superscripted (“23rd” and “496th”, not “23” and “496”).
  • Proper names and formal numerical designations comply with common usage (Chanel No. 5, 4 Main Street, 1-Naphthylamine, Channel 6). This is the case even where it causes a numeral to open a sentence, although this is usually avoided by rewording.

Hyphenation

  • Numbers from 21 to 99 not ending in zero are hyphenated (“fifty-six”), as are fractions ("seven-eighths"). Do not hyphenate other multi-word numbers (“five hundred”, not “five-hundred”).

Large numbers

  • Where values in the millions occur a number of times through an article, upper-case "M" may be used for "million", unspaced, after spelling out the first occurrence. This is particularly useful for expressing large amounts of money ("She bequeathed her fortune of £100 million unequally: her eldest daughter received £70M, her husband £18M, and her three sons each just £4M each").
  • Billion is understood as 10. After the first occurrence in an article, it may be abbreviated to unspaced “bn” (“$35bn”).

Tony 04:47, 12 July 2007 (UTC)

I have no objection other than the one you probably read under the previous heading #Contradictions II. Nobody is arguing that 0-10 should always be expressed as words, so that rule should mention that there are exceptions. Art LaPella 05:03, 12 July 2007 (UTC)
I didn't read that previous entry, actually. Um ... can you be explicit as to your objection? I don't think this new version changes much WRT the ten/11 boundary for spelling out numerals, does it? If I could have it my way, I'd insist on numerals above nine as the norm, but I think too many people would object. Am I right?
So we need to know what change you'd require for this new version to have your total support. Tony 09:11, 12 July 2007 (UTC)
Since I had just called for "Exceptions include dates, times and some measurements" to be added to the "Whole numbers..." sentence, and your version omitted that suggestion without comment, I took that as unspoken opposition. But if you're not taking a position on my issue, your paragraph is otherwise fine with me. Art LaPella 21:33, 12 July 2007 (UTC)
If it were up to me, I'd have billion, trillion, etc. thrown out in favour of scientific notation.
Also, I'm not sure about your purpose behind the clause "many editors prefer all numbers above ten to be expressed generally as numerals". What does it matter what editors prefer (we're writing for readers)? What do I do about this tid-bit of information? ... so many other editors prefer this ... great, me too ... and ... If it were up to me, I'd have the two-word rule replace the zero-to-ten rule altogether. Who's hat was ten pulled out of?
Besides these points, I think this is an improvement. Here's food for thought, though. Consider the first two points.
  • Whole numbers from zero to ten are spelled out as words in the body of an article, but are expressed as numerals in tables and infoboxes.
  • Except in tables and infoboxes, numbers above ten may be spelled out only if they are expressed in one or two words ("sixteen", "eighty-four", "two hundred", "twenty million" but "3.75", "544", "21 million"); many editors prefer all numbers above ten to be expressed generally as numerals. Within the bounds of the guidelines below, usage should be consistent within an article.
The first discusses numbers one to ten. The second discusses number above ten. Both note the difference between prose & tables/info boxes. Would it not be more straightforward to reorganise this so that one point discusses tables/info boxes and another discusses prose? When to spell the number out need not then be mentioned in the former of these points. Something along the following lines might do the trick.
  • In the body of an article whole numbers from zero to ten are spelled out as words; numbers above ten may be spelled out only if they are expressed in one or two words ("sixteen", "eighty-four", "two hundred", "twenty million" but "3.75", "544", "21 million"); many editors prefer all numbers above ten to be expressed generally as numerals. Within the bounds of the guidelines below, usage should be consistent within an article.
Jɪmp 17:07, 13 July 2007 (UTC)
  • Jimp, I like your suggestions; I've tweaked and incorporated them. Please note:

(1) I've stuck my neck out by changing the ten/11 boundary to nine/10, because it's so simple to conceive the spell-out-single-digits rule. Happy to hear objections on that. (2) "What does it matter what editors prefer"? It's a polite way of strongly recommending a usage without making it mandatory. (3) I suppose there's no support for The Guardian's "bn" as an abbreviation for "billion", is there? (4) I'm uncormfortable encouraging the writing out of "twenty million" yet the use of numbers for "21 million"; I'd rather "20 million". Tony 02:09, 14 July 2007 (UTC)

  1. Whilst I'd rather see the boundary pushed up higher (perhaps to twenty/21 ... being where we begin having to use two words to name positive intergers), I do like the non-arbitariness of nine/10 over ten/11.
  2. I get what your saying about what editors prefer but can't help but feel as if the implication is that we're writing for editors rather than readers. Perhaps reword it so as not to mention who's doing the preferring.
  3. bn for "billion" seems fine to me: no more ambiguous than billion itself but, as I've mentioned, I reckon we'd be better banning billion than biting bullets on it. I'd rather scientific notation for 10 and up.
  4. Yeah, all words for 20 000 000 but numberals for 21 000 000 would be problematic but if we want 20 million we'll have to draw the line somewhere: we surely don't want 1 million ... I presume the boundary would be nine/10 million.
Jɪmp 16:42, 15 July 2007 (UTC)

Tony's responses:

  1. OK, so we'll stay with nine/10, I guess. It's very common.
  2. Changed "editors" to "people": is that what you meant?
  3. I'll insert "bn" as an optional abbreviation, pending objections from others.
  4. I suppose "eighteen million" and "18 million" are both allowed under both old and new versions. Guess the bit about keeping it consistent within a context or list will stop people mixing them awkwardly.

"Two- and one-digit numbers are hyphenated when spelled out ('fifty-six')..." But how would you hyphenate "nine"? There are no one-digit numbers like "fifty-six", so I don't understand why the words "and one-digit" were included. Art LaPella 03:45, 16 July 2007 (UTC)

Thanks for seeing that. Would this solve the problem? "Conjoined two- and one-digit numbers are hyphenated ...". Tony 05:56, 16 July 2007 (UTC)

I understood it, but it took me several seconds, perhaps because in mathematics, fifty-six is one number. An alternative is "Numbers from 21 to 99 not ending in zero are hyphenated...". Art LaPella 06:30, 16 July 2007 (UTC)

Clever man: my brain couldn't arrive at that. I'll insert it. Tony 15:39, 16 July 2007 (UTC)
1. Let's consider three options;
a) ten/11—a seemably arbitary choice
b) nine/10—one digit when written as a numeral
c) twenty/21—one word when spelt out
I prefer b) to a) because this gives us a sensible reason but wouldn't you agree that c)'s reasoning is just as good (& in a sense better ... more positive—"avoid single digits by spelling the numbers out" vs "when a number can be written as a single word, go ahead and do so") but mostly I would just rather see the boundary pushed up rather than down—æsthetically speaking, words tend to look better than numerals in prose (to me atleast).
2. People is good but how about recasting the clause into the passive?
3. bn for "billion" is fine by me, the problem I have is with billion for "thousand million" (a somewhat different issue) but perhaps I swim against the current here—alas the current flows against logic ... but this is the English language, what's new?
4. I think the consistancy rule solves a lot of these types of problem
Jɪmp 17:56, 16 July 2007 (UTC)

m for million - with or without preceding space?

An editor has added a space before various occurrences of "m" for million, both in numbers (populations) and currency sums: 1.2m to 1.2 m and £3.4m to £3.4 m. I find it clearer with no space (as do others: it wasn't my writing that was being edited). Is there any guideline or consensus on this? PamD 07:29, 12 July 2007 (UTC)

I don't like the space one bit. Tony 09:03, 12 July 2007 (UTC)
Curiously, I note that the editor who put the spaces in has now removed them! But is there a rule, anywhere? (Or is use of "m" for million deprecated anyway?) PamD 09:57, 12 July 2007 (UTC)
I don't mind them where values in the millions are used at least a few times in an article. It's easier to read—highly identifiable by the eyes. As to whether both upper and lower cases are acceptable ... I'm unsure. And I think people might balk at "k" for thousand, although I use it in writing grant applications and budgets. I do like "bn", the Manchester Guardian's abbreviation for "billion", as in "$3.2bn". In fact, "m" and "bn" are much more readily distinguishable than "million" and "billion". Tony 11:25, 12 July 2007 (UTC)
Space them, for the same reason we space everything else. BTW, I disagree strongly with the idea that "$3.2bn" is more distinguishable; it comes across to me as lazy abbreviationism for no particular purpose, and it is unfamiliar to most readers. My first thought was "huh? 3.2 buns? 3.2 in binomial notation? WTF does this mean?" Granted it only took about half a second to get it, but WP is written for people far below my level of education as well as us smarty editors; why make them get headaches for no reason? — SMcCandlish ‹(-¿-)› 16:05, 13 July 2007 (UTC)
Where did you get this idea that such abbreviations are "lazy"? My only concerns are readability, smoothness and concision. We need to compare sample texts for a bird's-eye view of spaced and unspaced. Tony 16:09, 13 July 2007 (UTC)
Frankly, I find I always tend to first think "meters/metres" whenever I see lower-case "m". An alternative I often see, at least in American financial writings, is to capitalize the initial letter: $4.5M or $4.5B. (Usually there is no space between numbers and letter.) Askari Mark (Talk) 19:47, 13 July 2007 (UTC)
I agree entirely. Unspaced cap is best. Tony 01:56, 14 July 2007 (UTC)
Lower-case m for million is an abomination. Any scientifically or technically inclined reader will see this symbol as "metre" or "milli", depending on context. It is cognitively wrenching otherwise: your lecture comes to a dead stop, you think furiously for a few milliseconds, and then you say to yourself « Oh ! It must mean million ! ». Urhixidur 15:28, 16 July 2007 (UTC)
So? Do you mind the upper-case “M”, and for that matter, “B” or “bn” for “billion”? Tony 15:36, 16 July 2007 (UTC)
I agree that it's an abomination, and 1.2m (as a population figure) should really not exist. As for currencies, I do get the point of £3.4m as spelling out "million" would require a space, making for "£3.4 million", which is strangely grouped, looking more like "(3.4 pounds) millions" than "(3.4 million) pounds". Of course, 3.4 million GBP and 3.2 billion USD, or 3.4 MGBP and 3.2 GUSD using an SI-style prefix, is another way to go. I don't know what our policy on this is, but I don't really like these unqualified $s and £s in a multinational encyclopedia. Of course, most of the time it's clear from context whether the dollars are American or Australian or Canadian, but we can really never be too clear. Anyway, as I said, avoiding the space is pretty much the only point of using m and bn, so no, no space. -- Jao 15:39, 16 July 2007 (UTC)

Space after "c."? Examples mixed in MOSNUM

Have just looked at MOSNUM (having earlier been deterred by the "Out of date" tag). There seems to be an inconsistency:

Dionysius Exiguus (c.470 – c. 540)
Rameses III (reigned c.1180 BCE – c. 1150 BCE)

Is there really supposed to be a space after the c. for deaths but not births? I saw Dionysius, thought it was a typo, then saw Rameses. Does this need tidying up? (As a newcomer to the MOSNUM pages I hesitate to tread on what's probably hotly-disputed territory) PamD 10:02, 12 July 2007 (UTC)

I'm afraid that this is the result of my impulsive change earlier today (adding the spaces, since c.1850, to my eye, looks awkward); someone came along later and reverted most of them. Sorry for my part in this. Do people really prefer this without spaces? Tony 11:27, 12 July 2007 (UTC)
Yes. Johnbod 14:53, 12 July 2007 (UTC)

No, I feel that a space is called for. More strongly, I think it should be either all-spaced (c. 470 – c. 540), or without any spaces (c.470–c.540), according to WP:MOSDASH "All disjunctive en dashes are unspaced, except when there is a space within either or both of the items". So the question is simply whether a space always follows "c."

I will add spaces around the en dash for Charles Darwin's and Genghis Khan's examples, which are currently flat wrong.

I will leave alone the (fl. 760–772), because "fl." pertains to both years of the date range, and so the space is between "fl." and the date range, and is not within an item of the range. Compare with (c. 640 – 687), which indicates an approximate year of birth with a known year of death (a common situation for folks killed in battle). Does (c.640–687) muddy the distinction? I think it might. Chris the speller 16:24, 12 July 2007 (UTC)

Hat taken off to you, Chris. Tony 16:29, 12 July 2007 (UTC)
Aren't you contradicting yourself in saying you prefer "(fl. 760–772), because "fl." pertains to both years of the date range"; should you not then also prefer (c.640–687), where only the first date is approximate? I just find a sentence like "Rameses III was ruler of Egypt c. 1180 BCE – c. 1150 BCE and was succeeded by his ...." too sprawling for easy reading. Johnbod 16:40, 12 July 2007 (UTC)
This inconsistency was introduced in the past couple of months, and circa does not belong with a space. —Centrx→talk • 01:41, 13 July 2007 (UTC)
Why not? Tony 11:49, 13 July 2007 (UTC)
Indeed, why not? "c." is an abbreviation of "circa", so "circa 1250" should logically become "c. 1250" (it's not an abbreviation of "circa1250", after all), and there has been no expanation for the disappearing space. I suspect that some editors have simply fallen into the habit of skipping the space, and it now feels right to them. Chris the speller 12:54, 13 July 2007 (UTC)
I think this would most usefully be addressed by considering the style used by other encyclopedias, as has proved so convincing (to me anyway) on the spelling out of centuries above. Johnbod 13:48, 13 July 2007 (UTC)
OED seems to use no space, no stop: "c1234". Times style guide specifies space, no stop: "c 1234". Britannica seems to use stop and space: "c. 1234". ODNB seems to use no space, stop: "c.1234". (Wonderful specimen there is "Smith, Theodore (fl. c.1765–c.1810x23)" - I've no idea what the "x23" means!) So there is precedent for all 4 variations: stop or not times space or not! Does that help? PamD 15:16, 13 July 2007 (UTC)
This shouldn't even be a debate. Of course it should be spaced, for the same reasons we don't write "fl.209-256CE". — SMcCandlish ‹(-¿-)› 14:36, 13 July 2007 (UTC)
I agree with SMc. And my personal preference would be for the dot. I don't like dots normally, but without it, this abbreviation seems just not as distinguishable as you'd like. We're so used to letter/number combinations, and c 1823 could be a train-engine number. BTW, I see ranges cropping up here with hyphens. MOS insists on en dashes. Tony 15:24, 13 July 2007 (UTC)
I also concur. Whether “c” or “c.”, it’s an abbreviation of a separate word, so there should be a space (although I’d ignore it in a table with space limitations). Since the standard is to use a period/stop to denote such an abbreviation, as with “fl.” for “flourished”, the same should apply here. I’m surprised that any style guide offers something as atrocious as “fl. c.1765–c.1810”; “flourished” itself means it’s an approximation, and is used when neither birth nor death information is available. Askari Mark (Talk) 19:58, 13 July 2007 (UTC)

First sentence of "Years, decades, centuries"?

MOSNUM "Years, decades and centuries" starts: "This section describes how to link to years, decades and centuries. See sections that follow regarding when such linking is appropriate.". But actually it describes how to write years, decades and centuries, whether or not they are links. Perhaps it should be worded: "This section describes how to write dates expressed as years, decades and centuries. See sections that follow regarding when linking of these dates is appropriate.". Our discussions concern all mentions of centuries, etc, whether these are links or not. PamD 19:34, 12 July 2007 (UTC)

Yes, i had noticed that, and i agree with you. Johnbod 19:36, 12 July 2007 (UTC)
Seems non-controversial. I went ahead and fixed it (well, to a slightly stripped-down version of the above). Stephen Turner (Talk) 00:25, 13 July 2007 (UTC)
Well, only having started to look properly at this submanual in the past day, my impression is that the top has been taken over by date-link obsessives. It seems to go on and on about it at the expense of a focus on style. And it's all spattered with blue, which is such a distraction and looks messy. In the summary of this submanual that I'm preparing for the main MOS, and will post on its talk page in the next week or two for feedback, style won't be crowded out by this linking thing. Tony 00:32, 13 July 2007 (UTC)

Date Ranges

Good - it would be nice if we could also address the question of ranges of years: 1354-5, 1354-55, or 1354-1355 - about which it currently says nothing. See two sections in the archives here and here. Johnbod 02:16, 13 July 2007 (UTC)
Indeed; it should say not to abbreviate, in my opinion, because that's lazy and not encyclopedic language. — SMcCandlish ‹(-¿-)› 05:08, 13 July 2007 (UTC)
By not abbreviating, do you mean don't use two digits for the close of year ranges? I'm afraid I'd rather make that the norm. So much easier to read. But not one digit. Year ranges, of course, must be separated by an en dash. Tony 11:47, 13 July 2007 (UTC)
Yes, I mean that, and disagree that it is easier to read, but that's beside the point. This usage is utterly unworkable. Proof: "1454–51 BCE" is hopelesslessly, undeniably ambiguous, indicating either a span of a handful of years or alternatively of approximately a millennium-and-a-half. The longer-span interpretation is the only one that makes any sense, because there is no other way to express it, yet without prohibiting abbreviated usage, there is a very strong chance that 1454–1451 BCE was actually intended! Don't be lazy; doing so on Misplaced Pages often has grotesque consequences. — SMcCandlish ‹(-¿-)› 14:34, 13 July 2007 (UTC)
I don't think an example in BCE can be used to argue against using two digits for end of range in AD/CE dates. What proportion of Wiki articles involve BCE dates? This is the tail wagging the dog. I consider that 2 digits for in-century date ranges AD is clearest, easiest to read. Not one digit (ie use 1996–98 not 1996–8),not 3 digits (ie 1896–1931 not 1896–931). Dates need to be written out in full for BCE, where they work differently and can confuse readers because they work "backwards". PamD 14:51, 13 July 2007 (UTC)
...and, your BCE example is not even ambiguous. The 1500 years span would be written 1451 BCE–51 anyway. 19xx–xx notation seems natural and very common, especially for two consecutive years (see here or here). MoS is supposed to document the common usage (except if not obviously wrong), not impose it. Duja► 15:07, 13 July 2007 (UTC)
I was about to write almost exactly what Duja did. Tony 15:15, 13 July 2007 (UTC)
I think he meant 1451 BCE-51 BCE, which I suppose confirms his point about ambiguity. I am essentially in favour of two digits (1921-23) being standard for the CE, but think Pam is probably right about BCE dates. Johnbod 16:21, 13 July 2007 (UTC)
What?!? How can you be unaware that the year 51 BCE exists? of course one would write 1451 BCE – 51 CE if one meant to span the BCE/CE divide; that is not at issue here at all, in any form. I think you have completely misread what I wrote. I also do not follow the logic of the extended objection; it seems to mean "because a majority of dates will be CE, it's just fine and dandy if date specification certainty for every ancient history article is totally hosed because I'm too lazy to type '1971-1972' instead of '1971-72' or '1971-2'". <frown> That sounds probably more personal than intended; I'm simply trying to point out that convenience has understandability-fatal costs in encyclopedia articles. This is not the Rolling Stone magazine. Our topics span every possible date range understandable by human beings, and our date specification standards must reflect that. PS: The purposes of the MOS is emphatically not to "document the common usage" (that is what style guides like The Chicago Manual of Style are for; rather, it is to document prescriptive practices for Misplaced Pages articles, from a varied base of style guides, disambiguation (the main point here), usability and accessability, and other conventions and concerns, to produce the most encyclopedic prose we can. — SMcCandlish ‹(-¿-)› 16:16, 13 July 2007 (UTC)
The full date solution just looks odd to me; I see no objection to having a different standard for BCE dates. Johnbod 16:32, 13 July 2007 (UTC)
I must take SMc to task about these accusations of laziness, as in the section above: at issue is readability and concision—from the reader's perspective, not the typist's. Tony 16:36, 13 July 2007 (UTC)
What on earth is unreadable about "1972-1979"? If it is felt that abbreviation is so essential and useful (despite the problems it introduces; and a different standard for BCE and CE will be very problematic, because no one will know or understand it other than WP:MOSNUM geeks like us!), why all the opposition to "1972-9" as opposed to "1972-79"? It comes across as confusingly hypocritical. (Clarification: I don't mean this is in a personal way; I'm describing ideational structures, not human individuals.) — SMcCandlish ‹(-¿-)› 16:46, 13 July 2007 (UTC)
Firstly, "1788-9" is I think very rarely seen in respectable print; secondly it looks bad when mixed with "1778-83". Consistently using 2 digits for CE is easy enough to explain. Whether anyone takes any notice is a different matter. Most WP editors never use BCE dates anyway, and at least those that do would find an answer here if they looked. No doubt gnomes & bots could patrol also. Johnbod 17:02, 13 July 2007 (UTC)
  • I think that a range such as 1878–81 helps emphasize the length of the range, and is therefore easier to read correctly than 1878–1881. That is, by removing repeated and redundant info (the second 18) it allows the eye to focus on the significant part of the date. Indeed I could make a case for 1992–4 on the same grounds, that it emphasizes that the span is less than 10 years. But I'm willing to live with two digit abbreviated end-points only, and limit them to CE dates only, to avoid the ambiguity mentioned above. DES 21:32, 13 July 2007 (UTC)
I have to state very clearly that I think this "abbreviate for CE dates only" proposed solution would be a mistake, because it assumes that readers (as opposed to editors) will read and learn the manual of style; the case study I started this side debate with is illustrative of the problem. If readers casually encounter things like "1971-75" (AD) for 1971-1975, then "658-52 BC" will necessarily be ambiguous for them, and I think that is a dreadful result, even if (e.g. for the purposes of formal citation in school papers) the extra-dedicated reader can eventually find something here at MOSNUM clarifying it for them. More along this line is the very strong likelihood that many editors will in fact write "658-52 BC" when they mean "658-652 BC", because very few editors can literally memorize every single recommendation of the MOS, and those that are internally inconsistent are notoriously difficult for the WP community to truly absorb. No bot can fix an ambiguous date like that, since it will require going back to the original sources cited, some of which may not be available except after months of interlibrary loan waitlisting. I.e. the problem I'm raising here is by no means trivial at all, regardless how dismissive some would like to be about it. PS: Just because you do not edit articles that have something to do with the BCE date range doesn't mean that no one does; many editors specialize in such topics; there are thousands of non-stub articles dealing with the Classical world on Misplaced Pages. — SMcCandlish ‹(-¿-)› 23:32, 13 July 2007 (UTC)
In my exerience (after a quick tour of some Pharaohs etc. to confirm) this would only be adding to the MOS what most editors are doing anyway, both for BC and AD. Most AD dates use two figures, though as I said in the archive, I have had one editor change my two to four figures, and another change them back. Johnbod 00:14, 14 July 2007 (UTC)
I intend to propose a change in the wording to the effect that the closing year in date ranges is "normally" written with two digits, except . Tony 01:55, 14 July 2007 (UTC) And here it is (an excerpt from the draft summary for the main MOS):

*Year ranges, like all ranges, are separated by an en dash (do not use a hyphen or slash: “2005–08”, not “2005-08” or “2005/08”). A closing CE/AD year is normally written with two digits (“1881–86”) unless it is in in a different century from that of the opening year (“1881–1986”). The full closing year is acceptable, but abbreviating it to a single digit (“1881–6”) or three digits (“1881–886”) is not. A closing BCE year is given in full.

Comments? Tony 03:21, 15 July 2007 (UTC)

fine so far, but I think BCE needs covering. Johnbod 17:03, 15 July 2007 (UTC)
It looks fine for AD dates. Perhaps we need to add this qualification: "The closing year, for dates AD/CE, is normally written with two digits....". - revised version addresses my concern. Only further suggestion would be as discussed in next section. (Previous comment wasn't unsigned, but got separated from sig in the splitting out of "2004/05"!). PamD 07:42, 16 July 2007 (UTC)

2004/5

Incidentally, one of the style guides I looked at specified that "/" is used for a period such as "financial year 2004/05" (or academic year, etc). I don't know whether that's worthy of a mention. PamD 17:09, 15 July 2007 (UTC)
Good point. Johnbod 17:22, 15 July 2007 (UTC)
The slash is proscribed in the current text. Are you suggesting that it be (1) allowed for consecutive years only, (2) allowed for any year range, or (3) proscribed as now? (I'd go with (3) only, or if pressed, with (3) and (1), which would be a substantive change to policy). Tony 02:12, 16 July 2007 (UTC)
I would be ok with (1) for the sort of thing it is common for - sports seasons, academic and financial years. As below, perhaps it should be permissable in tables only. Johnbod 02:20, 16 July 2007 (UTC)
I don't mind the slash for consecutive years, but it's a change in the policy on this page and on the main MOS, which proscribes slashes altogether. The exception can be inserted here and at the main MOS if people feel strongly enough ...? Tony 03:23, 16 July 2007 (UTC)
I've mini-sectioned, & moved your last up, which I hope is ok. I don't feel strongly myself, but then I never do that sort of article, or table. Johnbod 03:41, 16 July 2007 (UTC)
My take on it is this: the likes of 2004/5 is not a range but a year—it simply has a different starting and ending date to the regular ones (i.e. 1 Jan & 31 Dec respectively). So:
  1. No, it should not be allowed for consecutive years only i.e. ranges thereof.
  2. No, it should not be allowed for any year range.
  3. No, it should not be proscribed as now.
I say allow it for these non-calendar years. Jɪmp 05:06, 17 July 2007 (UTC)
Yes that it is my feeling too - better expressed. Only for regular defined periods of a year that do not coincide with the calendar year. Johnbod 15:14, 17 July 2007 (UTC)
Do we allow ranges of these years - eg "a steady increase in the financial years 1993/4–1995/6"? Or specify that "to" has to be used? And is it "2003/04" or "2003/4" - both are used in the above discussion. PamD 16:31, 17 July 2007 (UTC)
Can't see why not. Jɪmp 03:13, 18 July 2007 (UTC)
This "/"-style is also commonly used in sport where a year-long season crosses a calendar-year boundary, as in snooker. I.e., I agree with User:Jimp. — SMcCandlish ‹(-¿-)› 16:11, 26 July 2007 (UTC)
Further comment: I think that "2004/5" and "2004/05" should be deprecated in favor of "2004/2005", because the former two, though longer, are ambiguous. Many Americans especially use that shorter form to mean "May 2004". I see that all the time. Given that the largest bloc of readers of en.wikipedia is American, this would seem to be an obvious problem to avoid. — SMcCandlish ‹(-¿-)› 16:17, 26 July 2007 (UTC)
I agree. Not totally convinced that "/5" will often be taken as the month, but 2004/2005 removes all doubt. Chris the speller 19:07, 26 July 2007 (UTC)

2004-05

Looking to the ISO 8601 standard "1901-05" means "1901 May", so you need to specify "1901-1905" for a date range to remove that ambiguity.
Since the use of Month/Year dates in that format is not (surely to God) permissable in article text, there should be no ambiguity. Johnbod 00:40, 16 July 2007 (UTC)
Yep, and in any case would be hyphenated, not en dashed (although that distinction might not be conveyed to the quick reader). Should numerical month-year expressions be discouraged in the point elsewhere on the page that deals with ISO dates? I suspect so. Tony 02:12, 16 July 2007 (UTC)
I suppose people want to use them in tables - "date joined team", "date released" and so on. It ought to be easy enough to avoid confusion in those cases. Johnbod 02:20, 16 July 2007 (UTC)

Objection

I object to the guideline decided here. I think it should be left to a user's convenience whether to write down "1910-1915" or "1910-15". I do not object to rejecting the "/", I do not object to not allowing one or three digits, but this strikes me as a pointless tiresome rule, and more homework for editors over absolutely nothing. I personally deeply dislike using "1910-15", and I should not be expected to change this perfectly acceptable format because some users dislike it, especially since there is no question of it being "wrong" (while I share the view that it is simply lazy). The guideline should say that either of the two is acceptable, as long as they don't both show up together in the same article.

And let me add: there should be a limit on changing rules as we go, because some decision taken in some relatively obscure place, without proper exposure, can affect virtually the entire body of articles and waste a lot of energies in the process of correcting what does not need to be corrected. Dahn 18:58, 17 July 2007 (UTC)

Thanks for your comment, Dahn. The lazy thing is pure bunkum, IMV. As I've pointed out elsewhere (to SMcCandish, who was pushing this line), the change is from the reader's point of view. Otherwise, why would the very same people push for the hard-work thin spaces below (which looks to be inappropriate for implementation, sadly).
Please be aware that the proposal is to make two-digit closing year ranges only the preferred option, not a mandatory one. Subsequent wording directly refers to the use of four digits in that role. I'm sorry that you hate the two-digit option, but it's a standard usage (and much favoured where there are lots of numbers floating around in a text). Tony 02:38, 21 July 2007 (UTC) PS Please note that hyphens are unacceptable as range separators: "1910–1915", or "1910–15", not "1910-1915", or "1910-15"; see MOS. Tony 02:43, 21 July 2007 (UTC)

Template:daterange

Perhaps {{daterange}} should follow whatever the standard is. (SEWilco 22:13, 20 August 2007 (UTC))

I can't see what the point of this template is. Does it save typing? Does is avoid repetition of the year, if it's the same? (no) Tony 05:53, 21 August 2007 (UTC)

Commas in numbers

Why is text like this used?

"... large number such as 156,234,000,000,000,000,000,000,000,000 can be .... .... and a small number such as 0.0000000000234 can be written ..."

Shouldn't the 0.0000000000234 be written as 0.000,000,000,023,4 if commas are supposed to be used in large (I take that to mean large number of digits) numbers.

ISO 31-0 mandates digits be grouped into threes, with each group separated by a space, and with either a comma or a point as the whole-number to decimal-fraction delimiter.

This would give 156 234 000 000 000 000 000 000 000 000 and 0.000 000 000 023 4 (or 0,000 000 000 023 4 of course) respectively. Both are uncluttered and clear, and consistent. —The preceding unsigned comment was added by 85.210.61.32 (talk • contribs).

Commas are normally used instead of spaces in both British and American English, although only before the decimal point. Not in scientific literature any more, but in most contexts commas are still the normal way of writing large numbers. Stephen Turner (Talk) 00:00, 15 July 2007 (UTC)
I've never seen the commas in a small number. Looks odd, probably because I'm just not used to it. Your proposal is logical, but I don't think it's going to wash. Tony 02:01, 15 July 2007 (UTC)
I wouldn't support such a mandate. I think in the English world that the commas are just the norm in more places than the spaces. —MJCdetroit 04:01, 15 July 2007 (UTC)
I would prefer it with spaces. It is uncluttered and unambiguous
I'd prefer it with thin spaces as an optional alternative to commas, but they're a nuisance to key in (&thinsp;). Should it be an explicit option?
156 234 000 000 000
On a related issue, is there a problem in explicity allowing thin spaces between the common mathematical operators (+ – × = etc) and between values and units? Tony 01:31, 16 July 2007 (UTC)
Thin spaces are my preference. The nuisance that they are to key in is made worse by the fact that some machines have to be told it's Unicode ({{Unicode|&thinsp;}}) for this to work but the nuisance could be eased somewhat by writing a template (and/or adapting an extant one). However, since commas are the norm (and because of the nuisance), this could only be an optional alternative to commas rather than the preferred (or mandated) style. Jɪmp 02:45, 17 July 2007 (UTC)
I like what you're saying. But if it's explicitly mentioned as an option (my preference), do we have to go into all that Unicode stuff, or can it be tossed off in a brief phrase? Also, strikes me that thin spaces have many standard uses, not the least between units and values, and mathematical symbols (perhaps, dare I say it, even between the clock-time and the am or pm, like “2:30 pm”—nice, eh?). I just wonder whether a separate point about the use of thinspaces as an alternative to normal spaces “where spaces are explicitly required in this manual” should be made, thus avoiding the need to mention it locally. Tony 08:20, 17 July 2007 (UTC)
Sounds good. No, you wouldn't want to go into all that unicode stuff on this page—that's how-to stuff whereas Ms of S are meant to be made of what-to stuff (all's needed is a link). Jɪmp 03:11, 18 July 2007 (UTC)
Re: "However, since commas are the norm" ... It might be "your" norm, but it certainly isn't everyone elses. The word "norm" means "standard" in many European countries, and in this context the standard is ISO 31-0 which for numbers with many digits puts the only punctuation mark as the separator between the whole number and the fractional number. That is, "exactly one" can be represented by either "1,000" or "1.000" and "one-thousand" is always "1 000". Any website with an International audience would be wise to go for that common ground. 81.179.99.43 2007-07-19 15:05 (UTC)
Commas are the norm in the English-speaking world, and that's what matters in the English Misplaced Pages. Of course other Wikipedias wouldn't use them, but in the English Misplaced Pages we should stick to normal English language usage. Stephen Turner (Talk) 17:23, 19 July 2007 (UTC)

Abbreviations for months

Why do some people insist on spelling out every 'month' date, i.e. "17 October 2005" instead of "17 Oct 2005" and then cite this page? I see nothing on this page that says that dates must be spelled out in full...Ryoung122 07:33, 16 July 2007 (UTC)

In section "Incorrect date formats", it states 'Always express a month as a whole word' and 'Do not use abbreviations like "Feb" ...', which seems pretty clear. Chris the speller 13:33, 16 July 2007 (UTC)
I never knew until now that abbreviated months also respect readers' preferred date order: compare ] 17 Oct with ] Oct 17. Nevertheless, I agree with spelling them out. Stephen Turner (Talk) 15:12, 16 July 2007 (UTC)
Actually, they don't. On my system, your examples are order-preserved (i.e., they show up as "17 Oct" and "Oct 17". Urhixidur 15:24, 16 July 2007 (UTC)
They do for me. I suspect this depends on the skin. I'm using monobook. DES 18:16, 16 July 2007 (UTC)
Do you have date preferences set, Urhixidur? What do October 17 and 17 October show up like? Stephen Turner (Talk) 01:55, 17 July 2007 (UTC)

Abreviation for ante meridiem and post meridiem

a dot m dot

I know this issue has been discussed before, without resolution, but I want to raise it again. I see everywhere the dots omitted in real life, and want to give WPians the option of either using the dots or freeing the initialism of them. This will be in my draft summary for the main article, for the consideration of everyone here.

But I'm unsure of the spacing issue. Pretend that we allow both dotted and undotted:

  • (1) At precisely 2:30 p.m., the whistle blew without fail.
  • (2) At precisely 2:30p.m., the whistle blew without fail.
  • (3) At precisely 2:30 pm, the whistle blew without fail.
  • (4) At precisely 2:30pm, the whistle blew without fail.

(1) is endorsed currently, by explicit rule and examples. (2) is not proscribed currently, but I don't like the look. Both (3) and (4) are currently proscribed. Somehow (4) looks good to me while (2) looks too dense.

At the moment, I feel that (1), (3) and (4) should be allowed.

Advice? Tony 02:30, 15 July 2007 (UTC)

Sounds good to me. (2) had never occurred to me. Johnbod 02:58, 15 July 2007 (UTC)
I've not done a proper survey, but my feeling is that 2:30 p.m. is most common in British English, and 2:30 PM is most common in American English. pm in lower case without dots feels wrong to me. Stephen Turner (Talk) 04:28, 15 July 2007 (UTC)
I haven't heard a reason for having more than one style. Does (1) offend some group? Loosening the standards would make WP look sloppier and set us up for edit wars, and I don't see where encouraging new variations helps editors or readers. Chris the speller 13:30, 15 July 2007 (UTC)
Offend some groups? Unsure that it has to come to that before an alternative is explicitly allowed. I really don't like the dots (particularly ugly in (2), which is currently permitted by the silence on spacing). I'll put up with the dots if no one else agrees that undotted should be allowed, but I firmly feel that the unspaced shouldn't be allowed with dots—it's just too crowded. The "reasons for having more than one style" is the same as for analogous issues (Br and Am Eng, 12- and 24-hour clocks, plus many more). I see "pm" without the dots everywhere in real life. Tony 01:37, 16 July 2007 (UTC)
I prefer the 24-hour format every time. Is 12:00 a.m. exactly midday or midnight? What about 12 p.m.? Is midnight of July 15 at the beginning or the end of the day? All of that is avoided by using 00:00 and 12:00 (and 24:00 for special occasions).
The date ambiguity of midnight is covered in the existing text, although clumsily. I prefer the 24-hour clock too, but there's no way people will agree to the proscribing of the 12-hour clock. Tony 01:37, 16 July 2007 (UTC)
(2) and (4) look odd to me and I rarely see times written in those ways. Since p.m. and a.m. are abbreviations, they certainly shouldn't be run into the number (an issue addressed in several preceding topics), and technically they should be abbreviated – although personally I'm comfortable with either. However, I frequently see "PM" and "AM" and they seem to be as widely accepted as "BC" and "AD" (and so on). Perhaps it should be "with periods" when in lower case and without when capitalized – and consistent usage throughout an article? Askari Mark (Talk) 17:08, 16 July 2007 (UTC)
How about this:
12:00 am ≡ 00:00
12:00 noon  ≡ 12:00
12:00 pm ≡ 24:00
It avoids all the draw backs of the 12-hour clock, respects the actual meaning of am & pm, and makes so much sense. The major problem is, of course, I've just made it up ... oh well. Long live the 12-hour clock, though, warts and all. The 12-hour clock, I think, is what most of us English speakers relate to best, however, a distinction can be made. When talking about events confined to a localised context the 12-hour clock does fine but when talking about events of global significance I'd prefer the 24-hour clock for ease of translation to various time zones. Jɪmp 04:44, 17 July 2007 (UTC)
You just have to provide the date when you write 12 midnight, unless it's obvious. What could be simpler? It's better explained in my new text on this:
"“Noon” and “midnight” are used rather than “12 pm” and “12 am”; the date of “midnight” is ambiguous and will need to be specified unless this is clear from the context."
If a contract is stated to run from midnight July 1 to midnight July 31, would you not believe that to be valid from midnight at the begin of July till midnight at the end of July 31? So how does adding a date make midnight unambiguous? −Woodstone 11:16, 17 July 2007 (UTC)
You're quite right, more precision is required than just providing a date. Thank you for picking this up. How's this?
  • "“Noon” and “midnight” are used rather than “12 pm” and “12 am”; whether “midnight” refers to the start or the end of a date will need to be specified unless this is clear from the context." Tony 11:26, 17 July 2007 (UTC)
Sounds good to me. I don't reckon we want to go into a whole lot of detail on this one since the cases where it'd be relevant you'd expect to be few & far between. Jɪmp 02:52, 18 July 2007 (UTC)

consensus on the ay em pee em issue?

Looks like my wish to allow unspaced (2:30pm) has bitten the dust; and it seems that US usage is both upper and lower case. So we need to determine what's in and what's out. Here are another four options, concerning upper and lower case, dotted and undotted, but all spaced. Please voice your preferences.

  • (1) At precisely 2:30 pm, the whistle blew without fail.
  • (2) At precisely 2:30 p.m., the whistle blew without fail.
  • (3) At precisely 2:30 PM, the whistle blew without fail.
  • (4) At precisely 2:30 P.M., the whistle blew without fail.


  • First preference (1)
  • Second preference (1) and (2)
  • Third preference (1), (2), (3) and (4). Added after Johnbod's comment below: I think the caps stand out more than the numbers, which is a problem for me. Tony 03:27, 17 July 2007 (UTC)
The same Johnbod 03:34, 17 July 2007 (UTC)
How about (5) At precisely 14:30, the whistle blew without fail. :-)
Actually, would lean towards (1) since I've traditionally seen lowercase (uppercase may be a computer-era thing), and skipping punctuation would be faster to type.
However, the best solution would be to set up a user preference feature in the Wiki software, similar to how dates are handled e.g. how userprefs change the display of 16 July 2007. Dl2000 03:46, 17 July 2007 (UTC)
... similar to how dates are handled but without requiring the things to be linked. As for my preferences ... well, they're already listed in order of my preference so that's easy. Jɪmp 04:10, 17 July 2007 (UTC)
So we'll take that as first pref (1) second (2), third (3) and fourth (4), I assume. Tony 04:49, 17 July 2007 (UTC)
Yep, or in other words, in this context my aversion to capitals is stronger than my aversion to full stops (P.S. not fond of the unspaced versions either). Jɪmp 04:56, 17 July 2007 (UTC)

Some points: (i) We don't have any significant influence over what features are in the Mediawiki software. We should concentrate on advising usage given the current state of the software. (ii) "Would be faster to type" is not really a good reason for recommending one or the other, in my opinion. We should be looking at respected style guides to see what is recommended in formal writing. (iii) I write (1) in casual usage, but never in formal usage, so I would only recommend (2) here. Although I would let the Americans have the alternative of (3) if their style guides advise that format. Stephen Turner (Talk) 14:28, 17 July 2007 (UTC)

Stephen, these are worthwhile points, but I want to say that North American style guides tend to say to put the final punctuation within the quotes, where WP has bucked that illogical usage and gone with that of the other English-speakers. So while US style guides may carry some weight, they're not the definitive factor. Tony 14:31, 17 July 2007 (UTC)

  • First preference (2)
  • Second preference (2) and (2)
  • Third preference (2)
Americans have no trouble understanding or typing a.m. or p.m., and any assumed American/Commonwealth difference is probably imaginary, or at least wildly overestimated. Certainly people on both sides of the pond can understand "pm" or "p.m.", but I know which looks overly casual, and which looks encyclopedic. Chris the speller 19:35, 17 July 2007 (UTC)
Agree with this latest comment. Writing a.m. and p.m. is fine, not confusing and in line with other abbreviations (e.g., i.e.) according to other elements of the style guide. I can see no pressing reason to relax the guideline. Adding a remark confirming common practice in WP, to leave a space before them is justified. −Woodstone 20:20, 17 July 2007 (UTC)

"am" and "pm" without space or dots is what seems natural to me, but I seem outvoted. Style guide examples: The Times and Guardian both use am/pm with no space; Britannica online uses space and then small caps AM/PM. ODNB: no visible style guide, but most use seems to be "10.30 p.m." format. Can't find any times in Grove Music! I suppose this points towards "space and dots, lower case" as seems to be becoming consensus. But not capitals, please! PamD 23:22, 17 July 2007 (UTC)

I'm comfortable with any of the first three options, but capitals look more like an acronym, so (4) looks inappropriate and unappealing. The most "proper" option would be (2) – since it's an abbreviation – so that would be my first choice, followed by (1), and then (3) perhaps a somewhat more distant third. Askari Mark (Talk) 00:46, 18 July 2007 (UTC)

Summary thus far

Pam, I don't think this is a raw vote, but rather an attempt to form consensus.
Assuming that "spaced" is now not at issue, here's a summary of our attitudes thus far among the eight of us (hope I've got it right):
  • Option 1—lower case, undotted (2:30 pm) is the first preference of Johnbod, Jimp, Epbr123 (strongly), Pam and Tony; second preference of Askari; and not favoured by Chris, Woodstone and Stephen (although Stephen admits to using it "casually")
  • Option 2—lower case, dotted (2:30 p.m.) is favoured by Chris (strongly), Stephen (strongly), Askari, Woodstone; second preference of Pam, Jimp, Johnbod and Tony; no one ruled it out
  • Option 3—upper case, undotted (2:30 PM) is favoured by no one; tolerated by Stephen if US style guides are found to permit it, and not favoured by Pam (strongly), Askari, Jimp, Johnbod, Tony, Chris, Woodstone
  • Option 4—upper case, dotted (2:30 P.M.) is favoured by no one and not favoured by Pam (strongly), Askari (strongly), Jimp, Tony, Stephen, Chris, Johnbod, Woodstone

Others are welcome to enter this debate; but hurry, it can't drag on forever. At the moment, the results suggest that (1) and (2) be explicitly allowed, I think. Thus, the only change would be (1) the explicit allowance of lower-case undotted (currently not explicitly proscribed, and confused in the tabled example by the spaced/unspaced issue), and (2) the insistence on the space. Tony 04:15, 18 July 2007 (UTC)

The guideline states 'Times in the 12-hour clock end with lower case "a.m." or "p.m."'. By stating exactly what is allowed, it implicitly proscribes everything else, no? The only question it does not answer is whether "a.m." is preceded by a space, and we seem to have settled that. So the remaining question is whether to overturn the existing guideline and introduce alternative styles. I remain opposed to that. We already have a use for "am", as first-person singular present case of the verb "to be". Chris the speller 15:43, 18 July 2007 (UTC)

I prefer Option 1. The others look messy. Epbr123 19:08, 18 July 2007 (UTC)

Chris; whilst your arguments from the maintenance of the current consistancy and "which looks overly casual, and which looks encyclopedic" are strong; your argument from potential confusion with the first-person singular present case of the verb "to be" I've gotta say is kind of weak: it may confuse a robot (a poorly programmed one) but a human literate enough to read an encyclopædic article in English ... I doubt it.
Also, I just thought I'd throw these in not that I'd want to see this.
  • (6) At precisely 2:30 PM, the whistle blew without fail.
  • (7) At precisely 2:30 P.M., the whistle blew without fail.
Jɪmp 02:18, 19 July 2007 (UTC)
Jimp, on the first-person singular present case of the verb thing, kind of weak is a correct observation, especially if you recognize it as a weak attempt at humor. I better put a smiley-face in there next time. As for my poorly programmed robots, touché, but I'm still proud of them. ;-) Chris the speller 03:10, 20 July 2007 (UTC)
  • Jimp, small caps are definitely an improvement on the normal caps, but I think it's too much bother to include them.
Chris, you're right and I was wrong, the current text does proscribe Option (2). That is what looks like changing unless there's a sudden reversal of opinion here. To exemplify what Jimp is saying, the grammar of "7:45 am happy to oblige" doesn't quite work, does it. The dotters used the same argument to try to proscribe the widely used "US" as opposed to their "U.S."—looks like a pronoun, they said. But "in the us" and "us foreign policy" don't work as pronoun, even when wrongly used in lower case to make this point. There's been a clear and inescapable trend towards losing dots in English, in the US and elsewhere—for decades, in fact, since the demise of the typewriter. I see the allowance of "am" and "pm" as part of that trend. Tony 04:22, 19 July 2007 (UTC)

MOS:ABBR

What about actual sources?

I'll bring mine to the party. The Chicago Manual of Style 15th ed., which I believe is the most comprehensive style guide on the planet – my copy weighs 3.2 lbs. (400 kg), at over 950 pages – says to use "a.m.", lower case, regular font, and with periods, or (in typesetting to use small-capitals without periods, but not regular capitals: "PM" (in normal caps), "am" (which is a normal English word; see elsewhere on this talk page for this periodlessness problem with "is" and "gal", etc.), and especially "P.M." (normal or small caps) are "wrong". All of these things are prescriptivist as hell, but Chicago's take that upper case (whether regular or small-caps) acronyms and the like are not dotted is pretty well supported in general usage. No one but my grandmother would write N.A.S.A. PS: I have to observe that all of this stuff is culturally in wild flux. I have books that are not as old as me that refer to "327 B.C." (not "BC"), and I even have one that used "B.C.E." - must've had a stodgy editor, willing to accept the new terms, but not to give up personally internalize punctuation methods. Hmm. Reminds me of someone... Maybe I should become an editor. Oh, I already am. I just don't get paid for it. <heavy sigh>. — SMcCandlish ‹(-¿-)› 21:48, 28 July 2007 (UTC)

PS: By contrast, Strunk and White's Elements of Style uses periods with every abbreviation and acronym, period, but it is considered stodgy (and I don't mean the 1920's edition, I mean the new 4th ed., revised by Edward A. Tenney and Oliver Struck, who I assume to be Wm. Strunk Jr.'s son). Fowler's Modern Usage (newest ver, Burchfield's Oxford rev. 3rd ed.) doesn't (that I've found so far) address the topic directly, but examples in prose throughout show a "period-happy" style as well (and it is a British edition, not American). My conclusions are that traditional style guides prefer periods, period; general ones like Chicago have a hybridized approach with some fairly compelling (and real-world-usage-based) logic, and the science market style manuals, like the ALA are very "death to periods!" in attitude. If I can find my copy, I'll see what the Wired Guide to Online Style from around the peak of the dot-com bubble ays (not "authoriative" from a prescriptivist point of view, but probably the only book of its kind, not counting entirely virtual competitors that are newer (but necessary probably delve a lot into post-blog (which also means post-IM, post-texting) style concerns, most of which I for one consider to be degradatory not progressive. — SMcCandlish ‹(-¿-)› 21:48, 28 July 2007 (UTC)

Global coverage of non-breaking spaces, the nowrap template, and thin spaces

None of these three issues is dealt with properly in the manual. All three are mentioned once, I think, but their application, whether optional or mandatory, should be global. We have:

"Preferably, use &nbsp; for the space (25&nbsp;kg) so that it does not break lines. This can be accomplished with the {{nowrap}} template".

It might have been a little kinder by adding: "Thus, {{nowrap|34&thinsp;kg}} yields 34 kg".


And we have an obtuse reference to thin spaces that's a little negative in the context:

"The SI/ISO notation style uses a non-breaking thin space instead of a comma ".

I propose that these three issues be explicitly covered at the top in a separate section.

First, I want to sell you the idea of at least raising the profile of thin spaces in the manual. They look much nicer, IMO, and make reading linked items slightly easier by being closer than normal, but not bunched. They are a traditional technique for spaced items, and ISO requires it in some places. On WP, these two functions—non-breaking and thin space—cannot be achieved using both html codes together; however, they can be combined in the nowrap template. Here's an example:

Let me show you a few examples of how neat thin spaces look. The first in each example is unspaced (proscribed, quite rightly, by MOS); the second and third have a thin space and a normal space, respectively, both using the nowrap facility.

  • 4:45pm
  • 4:45 pm
  • 4:45 pm


  • 4:45p.m.
  • 4:45 p.m.
  • 4:45 p.m.


  • 3.5mm
  • 3.5 mm
  • 3.5 mm


  • 2+2=4,
  • 2 + 2 = 4
  • 2 + 2 = 4


  • p≤0.01
  • p ≤ 0.01
  • p ≤ 0.01


Here's a proposed wording for the top of the manual. I've gone for a recommendation to use non-breaking and a "look, it's available" for both the nowrap template and thin spaces.

Spacing

Non-breaking spaces

  • In compound items in which numerical and non-numerical elements are separated by a space, non-breaking spaces are recommended to avoid the displacement of those elements at the end of a line.
  • A non-breaking space can be achieved by keying in the html code "&nbsp;" instead of a normal space; thus, "19&nbsp;kg" yields a non-breaking "19 kg".
  • Non-breaking spaces can also be achieved by using the {{nowrap}} template; thus, “{{nowrap|19 kg}}” produces a non-breaking "19 kg".

Thin spaces

  • Thin spaces are smaller than normal spaces, and may be used as an alternative to separate:
  • Thin spaces should always be non-breaking. To make a non-breaking thin space, use the {{thinnbsp}} template, inserting the compound item using vertical bars instead of spaces; thus, "{{thinnbsp|34|kg}}" produces a non-breaking thin-spaced "Template:Thinnbsp".
  • The {{thinnbsp}} template accepts most common elements. A notable exception is the equals sign, which is input by the htlm code "&#61;", rather than "="; thus, {{thinnbsp|4|×|2|&#61;|8}} produces a non-breaking thin-spaced Template:Thinnbsp. If the template is confused a character, look up the code for it.

Tony 07:23, 19 July 2007 (UTC)

Thin spaces have the drawback of not being well supported in certain important fonts and browsers: they actually are wider than normal spaces there. Christoph Päper

Comments on the proposal?

Please write them here. Tony 15:18, 19 July 2007 (UTC)

Looks good. What's the procedure for trying to get the {{nowrap}} template and/or "&nbsp;" added to the collection of markup which is offered in the box below "Save page" (could someone tell me what it's called, for future reference?) when one is editing? I can see its usefulness for many situations, but we need to make things accessible to all editors. People won't necessarily consult the small print of MOS but might, once they're aware of it, use one of these options for dates, times, etc where a space really shouldn't split over lines. PamD 07:48, 19 July 2007 (UTC)
Would love to, and had thought of asking Jimp about this. It's below the "edit box", I think. Tony 08:10, 19 July 2007 (UTC)
You are thinking of the Edit Tools. — Aluvus t/c 19:59, 19 July 2007 (UTC)
Still looks good. Now how do we get "space", "thin space", and "nowrap template" added to the editing toolbox (just realised that's probably the name for it?), so that they are easily available to people with average-to-lousy memories? PamD 15:51, 19 July 2007 (UTC)
In Opera 9, the examples using thinspace look exactly the same as those using a regular space (Opera ignores the difference). In IE 6, they display as a box (IE does not understand the character). The only browser on my system that renders the thinspace as intended is Firefox. That seems like a major issue to me. This seems to get at why it is a problem. — Aluvus t/c 19:59, 19 July 2007 (UTC)
Consider me sold on the issue of "raising the profile of thin spaces in the manual". I'm all for them. I'd like to see a non-breaking thin space as the recommended space for all those uses mentioned by Tony above (there may be others). I do like the idea of working this into something more significant.
The procedure for adding stuff to the edit tools: we'd have to get in touch with the developers.
On this computer also thin spaces come out as boxes. However, this problem can be solved using {{unicode}} (at least on this machine). The problem is that {{unicode}} and {{nowrap}} seem to dissagree with each other. {{nowrap|4:45{{unicode|&thinsp;}}pm}}, for example, justs gives nonsense; nor does {{unicode|{{nowrap|4:45&thinsp;pm}}}} do any better.
Therefore, I've written a new template, {{thinnbsp}} (that stands for thin non-breaking space ... just had a nicer look to it than nbthinsp & it's easier to type). This new template solves both problems. It's also nice in that you don't have to type &thinsp;—the non-breaking thin spaces are inserted automatically between the given parameters. Currently the template can insert up to twelve dozen thin spaces ... it could easily be extended if ever there be the need. See the following for examples of use.
{{thinnbsp|4:45|pm}} gives  Template:Thinnbsp
{{thinnbsp|3.5|mm}} gives  Template:Thinnbsp
{{thinnbsp|2|+|2|&#61;|4}} gives  Template:Thinnbsp
{{thinnbsp|''p''|≤|0.01}} gives  Template:Thinnbsp
{{thinnbsp|12|000|000|000|000|km}}  gives  Template:Thinnbsp
Note the html code in place of the equals sign (but see below).
Jɪmp 02:09, 20 July 2007 (UTC)
Jimp, you're brilliant. Except for the equals sign, this solves the problem better than I thought possible. The only bug is the equals sign. I see that {{nowrap}} specifies that to include an equals sign in your non-breaking item, you have to add "1=" at the start of that item. Seems to indicate that the equals sign has some other (blanking-out?) function here and in your new template. I wonder whether there's a ready-made solution; tried "1=" in yours, but it doesn't help. Tony 02:33, 20 July 2007 (UTC)
Afraid the equals sign problem is pretty standard fair for templates. This is because they are used for naming parameters. Using 1= won't work because this would be to define the first parameter as empty. You could use 1== but that sets the first parameter to =. In this case it's the fourth parameter we want to equal =. Now, {{thinnbsp|2|+|2|4==|4}} doesn't work but numbering all of the parameters does.
{{thinnbsp|1=2|2=+|3=2|4==|5=4}}   gives Template:Thinnbsp as desired.
This is easier on the memory &/or avoids having to look code up but could get kind of tedious for large sets of parameters. Jɪmp 03:03, 20 July 2007 (UTC)
OK, I've updated the proposed text above accordingly. I think the ?html code for the equals sign ("=") is an easier solution than the one you've worked out just above here, and may not have to be looked up if it's displayed in the Spacing section of the policy. Tony 04:08, 20 July 2007 (UTC)
Don't be too quick with "The only element ..." statements. Like any template {{thinnbsp}} is going to get confused by such characters as pipes (&#124;), curly brackets (&#123; & &#125;) and ordinary spaces (&#32;). Jɪmp 05:05, 20 July 2007 (UTC)
OK, thanks, have a look now. Tony 05:50, 20 July 2007 (UTC)
Your template still produces a regular space in Opera, but no matter. Of greater concern is IE 6, where the spaces in your 12 trillion km example are basically invisible, rendering the number unreadable. There's also the nontrivial issue of the complexity of using (much less finding) this template; it's hard enough to get people to use the non-breaking-space to separate units from numbers. Going to all this trouble to insert a space is not likely to catch on quickly. After all, the space bar on most keyboards is quite readily accessible.
The large increase in complexity (and decrease in page-source readability) involved in using this template just does not seem justifiable for the sake of having a slightly smaller space. Particularly when one of the cited applications, equations, falls on its face when presented with something as common as an equals sign. Or when, as far as I can tell, Internet Explorer has no proper understanding of thinspace anyway. I'm genuinely not trying to rain on your parade (having used thinspaces in a number of non-Web documents in the past), but quite frankly none of this makes any sense at all. As much as I might like to have the option of using thinspaces here and there, the technical realities clearly get in the way. — Aluvus t/c 06:19, 20 July 2007 (UTC)
I don't go with your reasoning about the additional input involved, or the exceptional treatment required of the equals sign. No one is forcing anyone to use it. If Opera were a common browser, I'd be worried, but I've never heard of it. IE 6 is more of a problem. Jimp, do you have a response about IE 6? Tony 07:39, 20 July 2007 (UTC) PS Just tried it on IE 5.2 for the Mac (it's yucky compared with Safari): it renders the thin spaces as normal spaces. That's a minor problem, because it's likely to be fixed in later versions of IE. But this IE 6 (Windows, is it?) that renders the thin spaces as nothing—that's not so good. Tony 07:46, 20 July 2007 (UTC)
What I'm trying to tell you is that virtually nobody will use this template, because it is a lot more work to use this template than to just type a space. The fact that it breaks in a critical way when faced with the equals sign makes it useless for equations (for which there is always LaTeX anyway). IE for Mac will never be updated again, nor will IE 6 (discounting some mega-huge security vulnerability), so anything broken in those browsers is broken permanently. I can't test IE 7, but I wouldn't be surprised if it has the same issues with thinspace. Someone certainly needs to find out before anything about thinspace goes into the MOS. — Aluvus t/c 01:18, 21 July 2007 (UTC)
Again, extra keying in doesn't wash; otherwise, why would we suggest (and people already use) the code for non-breaking spaces? They're certainly more work than tipping the space bar once. But unless Jimp can come up with a technical solution, I think your point about IE 6 kills off thin spaces for the moment. Damn. Tony 01:51, 21 July 2007 (UTC)
My thoughts are the same as Aluvus’, particularly since I also use IE. Looking at Jimp’s five ‘thinnbsp’ examples, the first three read okay, but the fourth appears completely run together, and the fifth is practically unreadable (with no space at all showing between the 2 and the first zero). Assuming these issues can be worked out (such as with a slightly “fatter” thinnbsp, I would want to make sure that editors understand it’s an option to &nbsp, state which browsers have a problem with it, and ask for consistent usage in a given article. Askari Mark (Talk) 01:53, 21 July 2007 (UTC)
Thanks, Askari; but please read my previous entry here. Tony 01:59, 21 July 2007 (UTC) PS Does the same problem occur with the nowrap template? Since I now propose to implement only the first subsection above, concerning non-breaking spaces, we should consider removing the reference to the template if it's buggy. Tony 02:57, 21 July 2007 (UTC)
Why would people bother using such a template? Why do we bother editing Misplaced Pages at all? Decreased readability of source code ... but increased readability of the article: what do readers read? How do people find it? How do we find anything? We see examples of a thing's being used, we see references to it on pages like this. The more it's used the better known it becomes and the better known it becomes the more it's used. The fact that certain characters including equals signs have to have special treatment is less than ideal but I don't see it as a huge problem especially considering that this a problem not just with this template but with all Wikimedia templates. However, if thin spaces don't work on IE 6, then this is a problem. In fact, the main reason I made the template was to try getting rid of the boxes. On the version of IE I'm using {{unicode}} does the trick. Do I have a solution ... I wish I had ... or maybe I do. How's the six-per-em space work for you? Here's an example: with and without the unicode template. Works fine for me (with the unicode template): producing exactly the same as &ampthinsp; does.Jɪmp 07:52, 22 July 2007 (UTC)

New opening

To me, the current lead is lame. Like the wobbly second para of MOS central, which was removed last week, this lead seems to apologise for the existence of the manual. And it should take the opportunity to refer explicitly to its area of specialisation.

Just as an overriding statement has been inserted into the lead at MOS central that the guidelines don't apply to direct quotations, it would be neater to say that in the lead here, too, and thus to remove the references to this from the body of the text.

EXISTING

This Manual of Style, like all style guides, attempts to encourage consistency and ease of reading. The guidelines here are just that: guidelines are not inflexible rules; one way is often as good as another, but if everyone does it the same way, Misplaced Pages will be easier to read, write and edit.
New contributors are reminded that clear, informative and unbiased writing is always more important than presentation and formatting. (See Misplaced Pages:Editing policy.)

PROPOSED

Almost every Misplaced Pages article contains dates or numbers. This Manual of Style aims to achieve consistency in the usage and formatting of these key aspects of presenting human knowledge. In this respect, consistency within and between articles will make Misplaced Pages more authoritative and easier to read, write and edit. An overriding principle is that the style and formatting of chronological and numerical items should be applied consistently throughout an article unless there is a good reason to do otherwise, except in direct quotations, where the original text is generally preserved.

Your thoughts? Tony 12:46, 20 July 2007 (UTC)

  • The proposed is better. That this MOS page is not a set of rigid rules is pointed to well enough by its being labelled "guidelines" in the "style-guideline" template, atop it. The current language emphasising that its contents are merely guidelines fairly well encourages editors to pay them no mind. What ought be encouraged is that they be followed.
    -- Lonewolf BC 17:07, 20 July 2007 (UTC)
  • Human knowledge...as opposed to dog or monkey knowledge. How 'bout just knowledge. Other than my jokingly sarcastic minor observation, I think it is a great improvement and agree with Lonewolf BC's assessment. —MJCdetroit 18:21, 20 July 2007 (UTC)
Here's your proposal, copy-edited:

This part of the Manual of Style aims to achieve consistency in the use and format of dates and numbers in Misplaced Pages articles. Consist standards will make articles easier to read, write and edit. Consistency should be maintained, unless there is a good reason to do otherwise; or in direct quotations, where the original text should be preserved.

Andy Mabbett | Talk to Andy Mabbett 20:02, 20 July 2007 (UTC)
Hmm: perhaps:

This part of the Manual of Style aims to achieve consistency in the use and format of dates and numbers in Misplaced Pages articles. Consistent standards will make articles easier to read, write and edit. Consistency should be maintained unless there is a good reason to do otherwise. In direct quotations the original text should be preserved.

Direct quotations are a "good reason to do otherwise", not an alternative, surely? Could perhaps link last 2 sentences with ":"? PamD 22:50, 20 July 2007 (UTC)

Oh, these are all improvements on my offering. But further tweaking is required. May I chuck this into the ring, then?

This part of the Manual of Style aims to achieve consistency in the use and formatting of dates and numbers in Misplaced Pages articles. Consistent standards make articles easier to read, write and edit. Where this manual provides options, consistency should be maintained within an article, unless there is a good reason to do otherwise. In direct quotations, the original text should be preserved.

"Formatting" to match "use"— here, these are processes, not results, I think. I removed the future "will", coz it's stronger to suggest to all that the manual is influential now. "Within articles" is an essential point that is taken from both MOS central and the existing text and spirit of MOSNUM (i.e., don't use a mixture of 12- and 24-hour clock unless there's a good reason to do so.) But I see your concern about "consistency", which was used in two senses without clarity. Better now? Tony 01:49, 21 July 2007 (UTC)

This part of the MoS allows so many alternative styles that it’s derision to claim it truthfully was about consistency. (I liked it if it was.) Christoph Päper
I'm always open to opinions that there are too many options, but a wiki style guide needs to be a little more inclusive than one for, say, a publishing house, where people are employed to produce a more uniform product. Here, it's international, democratic and voluntary; I think the MOS does well at treading a line between too much and too little choice.
But more to the point, I think you may be missing the point about the statement on consistency within articles: it's there because of the options. Choose an option for an article and use it consistently throughout. Tony 14:24, 25 July 2007 (UTC)

Omitting commas in Wiki-formatted dates

I'd like to propose a guideline to be added to the MOS regarding formatting dates that are Wiki-linked.

Be it proposed: Editors should omit commas in Wiki-linked dates.

Example:

Markup in text Rendered result†
] ] April 11 1998
] ] 11 April 1998

† Depending, of course, on reader's preference settings. This is the default.

Rationale: 'Tis better to let the wiki-software handle the insertion (or not) of commas, since this is its intended purpose. The date will be rendered correctly, depending on the viewer's preference settings. This

  • Makes the task of the editor a tiny bit easier (no uncertainty over whether or where to insert commas)
  • Reduces the size of articles somewhat
  • Is consistent with the function of wiki-date-formatting

I don't see any downsides to this. So whaddya think? +ILike2BeAnonymous 20:50, 20 July 2007 (UTC)

I see no reason to forbid people from insterting the comma. It has no effect on what is displayed, saves a meaningless amount of storage space, and frankly seems like instruction creep. The software will handle this anyway, making it a non-issue. You're going to have a tough time convincing American editors to input their dates in a format that they know is grammatically incorrect. Not much point in making rules that don't improve anything and will be ignored. — Aluvus t/c 01:42, 21 July 2007 (UTC)
Objections noted. I certainly didn't see this in terms of "forbidding" the use of unnecessary commas. How about at least a mention in the MOS that one can write Wiki-linked dates in this fashion; I don't think this is stated there, at least not very clearly. +ILike2BeAnonymous 02:45, 21 July 2007 (UTC)
A very similar proposal was made here a few months ago, and abandoned after a huge amount of discussion. I doubt that some sea change has occurred since then. The proposal will ruffle the feathers of a lot of American editors. To balance this, what should we do to annoy British editors? ;-) My opinion is that readers who do not set any national preferences for date formatting should not have to see incorrectly formatted dates, just properly formatted Commonwealth or American formats. WP has enough problems with sloppiness without encouraging editors to depart from the guidelines. Chris the speller 03:37, 21 July 2007 (UTC)
Yes, but (at the risk of inflating this discussion even more) that shouldn't be an issue, since I'm talking about properly-Wiki-formatted dates, like ] ], which will always render a properly formatted result. The only issue is whether or not to put commas in the markup. The commas will appear (or not) correctly based on preferences set. I'm not advocating creating dates that could display incorrectly, like "April 11 1998".
By the way, could you provide a link to that earlier discussion? I don't feel like digging through the archives. Thanks. +ILike2BeAnonymous 04:07, 21 July 2007 (UTC)

The earlier discussion wasn't hard to find; Archive D4, Commas in dates. It's in the second box from the top right corner of this page. And you're not as insane as I started to assume; yes, Misplaced Pages adds the comma to American-style linked dates that lack the comma. But, as the earlier discussion points out, that can't be guaranteed for mirrors and forks. And the comma does not get inserted for the nav popup (at least it didn't, as I remember), and I found that fairly annoying. Chris the speller 19:18, 21 July 2007 (UTC)

This is /very/ bad idea. Here's something I told another user: It's a common misconception that commas should not be included within American dates, indeed they are automatically added in the rendered version. However, the MoS states clearly that an American topic should use American dates (there are commas in American dates), it would make it grammatically incorrect not to use commas (think of it like this: if the software fixed typos on the rendered version, would it be acceptable to have them?) Please remember that Misplaced Pages is forked, a lot of these mirrors don't use the same setup as Misplaced Pages (consequentially they may contain bad grammar if commas are removed). Matthew 20:38, 23 July 2007 (UTC)

But wait just a minute: if what you say is true—that "forked" Misplaced Pages content may render incorrectly if editors do things like omitting commas in Wiki-linked dates—wouldn't that be true as well for text containing any of the thousands of templates and other paraphernalia used here, which would also have to be correctly rendered by the mirrored site? Do mirroring sites simply discard things like Wiki-templates (which would surely cause rendering errors)? I'm asking because I don't know; it seems as if one (potential) problem is true, the other is as well. +ILike2BeAnonymous 05:43, 25 July 2007 (UTC)
I've seen forked articles that should have templates there... but there's nothing there. So yes, I expect they probably maybe just discard them. The same is said for images as well. Matthew 18:00, 25 July 2007 (UTC)
Then that's pretty much what I thought happened. So basically, all bets are off when it comes to material that gets web-scraped from here, so why should we be concerned with the penny-ante possibility of a comma being dropped from a date? There are much larger issues here, and in my view (and that of others), such web scrapers pretty much get what they deserve. +ILike2BeAnonymous 18:29, 25 July 2007 (UTC)
I was going to make the frequent argument that proper date formatting for dates like ] ] wouldn't work for anonymous users and for registered users with "No preference" for dates selected, but I just noticed that it magically is working for both now. I guess our developers have fixed this since the last time I checked it. ~ Jeff Q (talk) 23:57, 25 July 2007 (UTC)
ILike2B started out by saying he/she didn't see any downsides, and now that some have been pointed out, says there are bigger problems with mirrors and forks, so this downside is negligible; I hope it's not going to come to "Damn the torpedoes". I have already indicated that the nav popup does not format dates or insert the comma, so unless the comma is included when the date is entered, American-format dates look wrong through the nav popup, causing a waste of time and resources to investigate them. There is really no value added to WP by forbidding the commas, it will definitely annoy American editors who know the correct formatting, and if commas were proscribed, one or more goofballs would pick this up and run with it, ripping commas out of every article that has American-format dates. To me it seems wasteful to have humans taking out the commas just so the computer can put them back in. Chris the speller 03:00, 26 July 2007 (UTC)
I haven't followed this debate closely. Are there any implications for the proposed new "Autoformatting and linking" subsection? Tony 03:16, 26 July 2007 (UTC)

Yes, if the proposal to eliminate commas were to be accepted, you would need to deep-six the first comma in this line:

    • ], ] will be rendered as either “February 17, 1958” or “17 February 1958”.
While we're at it, you should add an example of how British-formatted dates would be handled:
    • ] ] will be rendered as either “February 17, 1958” or “17 February 1958”.
Chris the speller 03:35, 26 July 2007 (UTC)

This is a storm in a teacup. Personally, I prefer to eliminate commas in wikidates, because the software automatically formats them correctly. However, I would be opposed to making this compulsory, simply because it's not something that is worth enforcing. American editors are going to use a comma, because to them that is the way things are, and very few of them are going to bother hunting down the MOS or the various discussions. As to forks, let the forks look after themselves. --Pete 03:27, 26 July 2007 (UTC)

Let me repeat that I never contemplated making this scheme mandatory, just a suggested way of formatting dates. I agree with you on forks and web-scrapers. +ILike2BeAnonymous 05:29, 26 July 2007 (UTC)
Don't know the term "deep six" (=expunge?). So, I'm getting that there's no substantive change in policy or technical specs, and that I need to insert the other way of formatting dates in the example; will do. (Thanks, Chris. How could I neglect this? I'm not American.) Tony 05:46, 26 July 2007 (UTC)
I don't know it either, had assumed it was some baseball equivalent of "hitting for six" when a cricket ball is hit over the boundary and scores six. But it isn't! Wiktionary doesn't know "deep six" but WP does: dab page at Deep six tells us it's
"an American slang term that means, when used as a verb, to "ignore", "get rid of","toss out", or "throw overboard". "Deep-six" is a reference to the approximate depth of six fathoms needed for a burial grave at sea."
The six fathoms is interesting - Shakespeare had "Full fathom five thy father lies..."! Sorry if this is a bit of a digression. PamD 08:33, 26 July 2007 (UTC)
Since we're digressing, I wanted to ask "Pete" if he really meant a "storm in a teacup". I've never heard this expression, but I have heard "tempest in a teacup" plenty o'times. Is this an updated, 21st-century variant? +ILike2BeAnonymous 23:24, 26 July 2007 (UTC)

If linking of all dates was mandatory the above comma/no comma problems would be rendered pointless by the autoformat, with the added addition that registered users who had bothered to set their date preferences would see dates displayed in their chosen format, all registered users benefit regardless of their chosen national date format. - X201 18:52, 31 July 2007 (UTC)

Pluralizing of Units of Measurements

I'm not comfortable with the current restriction never to pluralize imperial units. While I understand metric units are not pluralized in their abbreviated forms, certain imperial units are nearly always abbreviated. Particularly 10 lbs. and 100 yds. (although yards are less commonly used than pounds, the primary measurement of mass in the imperial system). In mainstream American writing, I never see 200 lb. but rather 200 lbs. Some examples are: This is not advocacy to adopt a US-centric style, but since the United States, Liberia, and Myanmar are the only countries still using the imperials system, any article in English Misplaced Pages that does include pounds should abbreviate it as lbs. Talmage 00:01, 21 July 2007 (UTC)

Not sure I see the logic in the last sentence. Any Americans care to respond? I have no idea. Tony 01:57, 21 July 2007 (UTC)
I see it both ways, but more often with an ‘s’ for plurals; without ‘s’ is seen more frequently in technical sources. I think that what drives dropping the ‘s’ in Misplaced Pages, though, is more parallelism with SI metric usage whenever conversions are displayed. E.g., “a weight of 10 lb (4.5 kg)” looks a little bit less odd than “a weight of 10 lbs (4.5 kg)” and helps less experienced editors avoid mistakes like “a weight of 10 lbs (4.5 kgs)”. On the whole, though, I have no great objection to the proposal to permit it as an option – as always, with consistent usage throughout an article. Askari Mark (Talk) 02:08, 21 July 2007 (UTC)
Most appearances of lbs occur in non-scientific non-technical writings, since even in the United States, the vast majority of scientific documentation uses the metric system. I just think the following sentence looks extremely awkward: I weigh 195 lb. Also what I meant by the US-centric statement was that anytime pounds are used, it likely reflects American usage anyways since no other English speaking country uses the imperial system. Talmage 05:23, 21 July 2007 (UTC)
Talmage, English Canada and the UK still very much use the imperial system. Also, the sample sentence that you gave technically goes against the MOSNUM because lb. should be spelled out in full unless in parenthesis. I weigh 195 pounds (88.4 kg). However, as far as adding an s to certain imperial abbreviations, I could support that. —MJCdetroit 06:35, 22 July 2007 (UTC)
Normal spoken UK usage would actually be I weigh 13 stone 13 (if my mental arithmetic is right)! Weights in pounds alone are seen as US usage. PamD 09:03, 22 July 2007 (UTC)
Yes the common British English usage is to use stone as in the example above. Stone is singular and plural. Fnagaton 11:38, 22 July 2007 (UTC)
What on earth is "Talmage"? Tony 12:56, 22 July 2007 (UTC)
A more accurate question would be "Where is Talmage?" :) Fnagaton 09:40, 23 July 2007 (UTC)
Silly me; now I see that MJC was being wry.Tony 10:07, 23 July 2007 (UTC)
In the UK, most goods supplied by shops are primarily marked with Metric measurements (there are just a couple of notable exceptions; e.g. "pint of beer"). This has been the law for quite a few years. It is also permitted to mark the goods with equivalent Imperial measurements, but only if that is done in a smaller typeface. In this way, UK WP articles should use metric measurements first, with imperial measures optionally stated in parentheses. Metric measures have been taught in all UK schools since 1971. Anyone aged under 41 in 2007 will have been taught Metric from their very first year at school. Anyone born before 1955 will not have seen any metric tuition while at school. 81.178.213.159 2007-Jul-23 11:35 UTC (+ later edit)
I think you meant to say "primarily marked with Metric measurements"! That's what the law requires. Different from road signs which are in miles. (New babies announced to proud familes seem mixed - kgs for parents' generation, lbs for grandparents?) PamD 12:34, 23 July 2007 (UTC)

Unlike many guidelines, this one is comprehensive, simple to understand, and simple to apply. Plural symbols for some units, in some circumstances would be complicated. It would effectively end the guideline. I would rather delete the guideline.

I presume we are only discussing within-parentheses and within-tables. One method of thinking about a problem is to invert it. Instead of asking the question where is lbs acceptable, invert it and ask where is lb unacceptable.
Lightmouse 12:08, 23 July 2007 (UTC)

Good thinking. I suspect that we're going to come to the conclusion that the status quo should remain (no pluralising). Plurals look fine as exemplified above, but yes, in WP articles these abbreviations appear only within parentheses and in tables, where singular for all is fine, I think. Tony 13:05, 25 July 2007 (UTC)

Storm at MOS central

It's been over a clause I added to the very last section "Submanuals" (after posting the proposal at talk to no response, mind you):

Where a discrepancy arises between the text of this manual and that of a submanual, the former prevails.

The arguments for this clause are set out in detail on talk. I'm alerting my colleagues here because I think there may be support among them for better coordination between all 33 MOSs; my "discrepancy" clause is intended to encourage cross-checking and centralised discussion at MOS central when significant changes are proposed for daughter articles. It sees daughter articles as setting out greater detail rather than being separate empires.

Your thoughts? Tony 02:54, 21 July 2007 (UTC)

  • I strongly support, in theory. The only caveat or catch to my mind is that changing the core MoS is harder than changing one of its sub-guidelines, so it could potentially be difficult to keep "MoS Central" perfectly in-synch at all times with the more exploratory documents. PS: Until what to do with WP:DATED is determined, please make sure that it is listed as one of the 33; we wouldn't want to lose it again!  :-) — SMcCandlish ‹(-¿-)› 16:32, 26 July 2007 (UTC)

Proposal for the addition of a summary of this submanual at MOS central

The time has finally come to unveil a draft summary of the poorly named "dates and numbers" guidelines (dates are far too narrowly defined to encompass this topic). MOS central already has summaries of the important submanuals, with links to them at the subsection level. Therefore, it's inconsistent not to include this highly significant part of style at the central location. The role of the submanual, like that of others, will be to set out the topic in greater detail, tended by specialists. I'm also keen that there be more coordination between the submanuals and MOS central.

My aim is to produce a summary that:

  1. excludes detail that is less frequently at issue, unstable, or contentious (in that sense alone, it is a summary of this submanual)
  2. is better organised than the current submanual here
  3. is properly copy-edited
  4. includes changes arising from issues that have recently been resolved on this page, and
  5. includes changes in policy that occurred to me in the process (highlighted in <font-color=darkgreen>green). I hope I've captured all of them; you'll still need to refer to the existing submanual as you read through it.

I seek your advice and feedback on this draft over the next, say, two weeks, so that it can be refined before taking it to the talk page at MOS central. I suggest that consideration be given for using the text of the summary to improve the submanual (the which case the examples should be different).

I seek your consensus on:

  • (a) the proposal to include a summary of dates and numbers in MOS central in the first place
  • (b) the green-highlighted policy changes
  • (c) the copy-edited text—there are surely still glitches, and your attentive eyes will be appreciated
  • (d) using the text to improve this submanual.

Miscellaneous points:

  • I've deliberately excluded most of the first section here. Much of it is included in the new "Chronological items" section. I think that the stuff about linking (which is contentious) should be sequestered into a specifically named subsection at the end of the "Chronological items section" in this submanual. It's a visually and conceptually messy way of starting the submanual as it is, but this, I hope, can be a separate issue to the one at hand.
  • MOS central's section "Scientific style" would be subsumed by this, largely. I think this summary should be located where that existing section is.

To assist you in providing advice and feedback, I've set out the headings and subheadings of the proposal for you to add your comments on (b)–(d), with space at the top for general comments, particularly WRT (a). I expect that people will scrutinise and comment on portions at a time; please note that you can sign with four tildes at a number of locations below in the same edit. If you have no issues with a subsection, an "OK" or simply nothing might be enough.

Tony 05:30, 22 July 2007 (UTC)

These improvements have already made] on the basis of feedback from users. My only concern is MJCdetroit's addition of the UK to the existing list of countries (the US, Liberia and Myanmar) for which imperial units should be the main ones, with metric units in parentheses, rather than vice versa. On consulting Metrication in the United Kingdom, yes, it does appear to be a mixed bag in the UK. However, I'd still prefer the metrics to be the main units for UK-related articles. The alternative is to explicitly state that either way is acceptable for UK-related articles. MJC's edit forces imperial units to be the main ones, with which I disagree.

I can see that my line would lead to too much flak, so does anyone object if we explicitly allow both systems for UK-related articles? Tony 08:00, 23 July 2007 (UTC)

Both units seems wisest: I think the majority of people in the UK still think in miles first, and that's what's used on road signs, although an increasing number of younger people think metric. PamD 08:39, 23 July 2007 (UTC)
Done. ("For articles relating to the UK, the main units are either metric or imperial; the choice should be consistent within an article.") Tony 13:18, 23 July 2007 (UTC)
My thinking in adding the UK was exactly as PamD put it above, that most people in the UK prefer imperial measurements over metric and that the government is still not fully metric. I wouldn't want to force anyone to do anything that they're not comfortable with. Therefore, I am OK with giving guidelines to have both and letting the editors of the articles decide which is preferred. We may want to add and the British Commonwealth after UK, as I know Canada is a "mixed bag" in this area; especially if the source is non-governmental in nature (Example: ref#3 at this article). —MJCdetroit 17:19, 23 July 2007 (UTC)
(edit conflict)Re the UK, miles are something of a special case. For smaller distances, centimetres have largely taken over (eg measurements of paintings etc) in the sort of sources we should be using and emulating. Yards/metres are just in a muddle. Johnbod 17:49, 23 July 2007 (UTC)
I think countries and individuals who insist on holding onto the old system are being tedious, I'm afraid. I made it optional for the UK only under pressure; Canada, Australia, NZ and South Africa have had metrics for many decades: there's no issue there. Tony 04:03, 24 July 2007 (UTC)
Under "Conversions", I don't think the line, ...in highly scientific contexts where the likely readership can be assumed to be familiar with metric units should be included. That would be giving someone a license to start removing things like the length of insects in inches or Fahrenheit from the flash point of chemicals like Toluene. We should just leave this how it was—indicating that SI units should be the main units unless there is...
Done. Tony 04:11, 24 July 2007 (UTC)
Also, instead of directing editors to use one template ({{convert}}), direct them to the category Category:Conversion templates and allow them to choose. This way it does not appear that the MOSNUM is endorsing one template over another. I like {{convert}} for some things but I personally find some other templates in that category easier/faster to use in some cases. —MJCdetroit 17:44, 23 July 2007 (UTC)
Done. Tony 04:05, 24 July 2007 (UTC) Except, can you tell me whether all of the templates there include a non-breaking space? I've assumed they don't in the latest edit: "*Category:Conversion templates can be used to convert and format many common units, including {{convert}}, which includes non-breaking spaces." Need to adjust according to your new advice. Tony 04:09, 24 July 2007 (UTC)
I will go through the Category and let you know about the spaces. —MJCdetroit 14:25, 24 July 2007 (UTC)
  • General comments on structure, strategic intentions
  • I'm going with both inclusion in MOS central and the use of the draft to improve this submanual. Tony 05:58, 22 July 2007 (UTC)
    Any room in the summary for the binary prefixes section? Fnagaton 09:43, 23 July 2007 (UTC)
    Since this concerns a highly specialised area—computing—the link at the top of the (summarised) "Numbers" section to MOSNUM's detailed information on this topic might be sufficient. Same for Geographical coordinates. Is there a strong argument for squeezing it into MOS central? Tony 10:39, 23 July 2007 (UTC)


1 Non-breaking spaces

2 Chronological items

  • New 2.1: Precise language
  • 2.1 Times

Should a mention be made of hundred hours? As in "The attack was scheduled to start at 0700 hours"? --Philip Baird Shearer 13:28, 25 July 2007 (UTC)

This would be an extension of existing options. Is there a good reason? Would it be restricted to military contexts? Tony 14:40, 25 July 2007 (UTC)
  • 2.2 Dates

--- or put a comma or the word of between month and year. This seems to assume American style "October 25, 1976" not European style "25 October, 1976" --Philip Baird Shearer 13:28, 25 July 2007 (UTC)

Will fix tomorrow. Tony 14:40, 25 July 2007 (UTC) On re-examination, I wonder whether there's anything wrong with this? US style assumes a comma between the day and the year (both digital groups), and WP, right IMV, proscribes the redundant comma that might arise in the use of the European style between spelled-out month and digital year. Fine, yes?

Tony 01:48, 26 July 2007 (UTC)

Why is there no acceptance of dates like 25th October? --Philip Baird Shearer 13:28, 25 July 2007 (UTC)

This is an existing requirement that, I think, reflects a solid trend in English-speaking countries towards dispensing with ordinal suffixes in dates. Are you proposing that it be re-introduced? Tony 14:40, 25 July 2007 (UTC)

Years - not mentioned explicitly, but needed here (there's "Eras" in the next section). We need to add that both "BCE/CE and BC/AD are acceptable." but call for consistency, and to explain where to put "AD". PamD 08:39, 23 July 2007 (UTC)

I can find nothing about years alone in the first five subsections of "Dates" in the current MOSNUM that is worth putting in the MOS summary (tell me if there is something). I found a bit about yearless dates that I've now inserted into "Dates". These first five subsections are almost entirely about linking chrological items, a contentious issue. I suggest that it be moved down to the end of "Chronological items" in the revised MOSNUM; there's already a link to such a section at the top of the section in the proposed summary. On your last point, "BCE/CE" and "BC/AD" are already piped links to those explanations, under "eras". Tony
Piped link it may be, but it leads to:
"Traditionally English copies Latin usage by placing the abbreviation before the year number for AD, but after the year number for BC; for example: 64 BC, but AD 2007. However, the placing of the AD after the year number (as in 2007 AD) is now also common..."
which doesn't help much! I agree that "Years" doesn't appear in the MOSNUM, so can't be expected in the "Summary" - a defect which ought to be sorted out, but perhaps not as part of the current process. PamD 13:32, 23 July 2007 (UTC)
So what points do your think need to be made about years? Can't think of any, apart from year ranges, which is there already. I presume that you're suggesting it be pointed out that CE/AD is back to the year 1, and BCE/BC before that? It should be under "eras", I guess. Tony 15:44, 23 July 2007 (UTC)
I think it's all there under "Eras" but would be better further up, under "Years". The lead sentence is "This section describes how to write years, decades and centuries", but it doesn't go into BC/AD and BCE/CE: there are links to articles on these, but we need to say (a) either system may be used, (b) be consistent, (c) remember AD goes in front, the others all after. Perhaps "BP" and "MYA" should remain under "Eras": they seem to be rather different. PamD 16:18, 23 July 2007 (UTC)
I've removed the "Eras" subsection and put it all under years. Please comment now on "Years". Tony 09:25, 24 July 2007 (UTC)
"Years" looks fine now, thanks. Much clearer without the "Eras". One last small thought: might it be helpful to include an explanation of what CE/BCE mean, as it's a bit puzzling without if you don't know? PamD 17:33, 24 July 2007 (UTC)
I find that difficult. Did you have a brief explanation in mind? It's like explaining year as the period of time stretching from 1 Jan to 31 Dec. Tony 01:50, 26 July 2007 (UTC)
Sorry, perhaps "expansion" would have been clearer than "explanation". Something like
(Some writers use CE and BCE, ("Common Era" and "Before Common Era"), to avoid the overtly Christian associations of AD and BC ("Anno Domini" or "year of the lord" and "Before Christ".)).
Except that that version has ugly nested brackets! But that's the info I suggest adding - could perhaps omit the explanation of AD/BC as more people are familiar. I suspect some people may think CE stands for Christian Era. (I've just checked the article to which BCE redirects, and corrected what I'd written above from "Current" to "Common", so I had it wrong too!) PamD 08:17, 26 July 2007 (UTC)
(delurking) As a matter of chronological nicety, it might be quite helpful to explicitly define the year as stretching between those two dates. At various points before 1600 (& perhaps later, I'm quoting from memory at the moment), the year was defined as beginning on Christmas, 25 March, or 11 September depending on custom & usage. If someone is using a date from a calendar that does not map precisely onto a 1 Jan.- 31 Dec. year (for example, from a date given as "Anno Hajiri", but with no month or day), it would be convenient for them to provide the date in the original form either before or after the AD/CE version. -- llywrch 05:13, 26 July 2007 (UTC)
Llywrch, please lurk no longer. Should we then have to define "day" as stretching from midnight to midnight? I certainly think that these definitions are too detailed for MOS central; and unless there's solid support from others here, I suspect that they're too detailed and unnecessary for a back-pasting of the new sections into MONSUM. Who doesn't know now what the boundaries of a year are? I've insert boundary definitions for centuries and milliennia only because they're counterintuitive and often misunderstood. (That could come out of the MOS central text and be retained here if people want.) Tony 06:20, 26 July 2007 (UTC)
No, I merely pointed this out because confusion is possible. (Then I let myself be distracted from my point due to a specific case. Darn...) It would be helpful, though if the MOS included a simple statement to the effect that "unless otherwise stated, units of time begin & end at the points most commonly accepted in the English-speaking world." Perhaps this might discourage some arguments. As for centuries & millenia, I find some of these cases so confusing that I'd prefer to avoid writing statements like "the beginning of the 3rd century BC" entirely! -- llywrch 19:58, 26 July 2007 (UTC)
The draft doesn't say "the beginning of ..": it just gives examples of centuries and millennia (strictly speaking, decades, too, go from 1 to 0 (1981–90). But trying to get people to refer to 1990 as part of the 80s, well, I don't think that way. So I left it out. The only issue is whether the stuff about the year 0 and centuries and millennia should be omitted from the MOS-central summary text, while retained here. MOSNUM, after all, should be the place for extended details that people can link to from MOS-central. Tony 01:11, 27 July 2007 (UTC)
For an overview of some of the complexities of calendar changes etc you might like to look at from a site aimed at genealogists. Mind-boggling. Not for MOSNUM, though I'm sure historians will be aware of the usages for their own periods, just mentioned as of passing interest! PamD 08:26, 26 July 2007 (UTC)
Also Old Style and New Style dates, and on the talkpage Talk:Old Style and New Style dates#Two different interpretations --Philip Baird Shearer 08:16, 1 August 2007 (UTC)
Done. Tony

Supposing one is talking about the first RAF 1,000 bomber raid of WWII that occurred on night of 30/31 May 1942. How should such dates be represented given that 30 May will be inverted if linked and the option is set in the user options? --Philip Baird Shearer 13:28, 25 July 2007 (UTC)

You've raised a reasonable usage of the slash that I'd include if it wasn't for the stupid autoformatting function, which won't accept the slash, just as it won't accept a date range with en dash (or, for the matter, the hyphen). I hate that inflexible autoformatting; it needs an overhaul, but they won't do it. Tony 01:58, 26 July 2007 (UTC)

Convenience link back to the draft summary

3 Numbers

  • 3.1 Spelling out numbers
  • 3.1.1 General rule
  • 3.1.2 Exceptions
  • 3.1.3 Hyphenation
  • 3.2 Large numbers
    • Perhaps a need to mention crores and lakhs in articles relating to the Indian subcontinent, since they are used in daily life and news reports? Need to point out the old 10 usage of billion in older (say pre-1950s) British usage? -- Arwel (talk) 13:45, 22 July 2007 (UTC)
Has this come up before? These units are not mentioned in the existing version. Are they in the India-related MOS submanual? Is there point in using them if only Indians can understand them? It might be covered in a link to it, but there would have to be support for this. Want to raise it as an issue below in a stand-alone section? Tony 14:17, 22 July 2007 (UTC)
Oops, forgot. Examples completed now. Tony 13:18, 23 July 2007 (UTC)

Billion should be expanded to mention Long and short scales, and that Misplaced Pages uses the short scale Billion of 10 unless it is explicitly mentioned that in a specific context that it means 10. This is important to highlight for foreign language editors who's native system is long scale as they often work with figures from a foreign language translation an they may not be aware that in English it is usual to use the short scale. BTW UK was long scale before 1974. --Philip Baird Shearer 13:51, 25 July 2007 (UTC)

I'll make this straightforward change. Tony 14:34, 25 July 2007 (UTC)
Not so fast; why complicate matters? At the moment, the draft says "Billion is understood as 10. After the first occurrence in an article, billion may be abbreviated to unspaced bn ($35bn)." What kind of context would require the long scale? It would be nicer to keep this simple, don't you think? Otherwise, it has to be something like this, which is kind of complicated: "Billion is understood as 10, that is, on the short scale (unless it is explicitly mentioned that in a specific context that the long scale is being used, where billion means 10). After the first occurrence in an article, billion may be abbreviated to unspaced bn ($35bn)."Tony 04:35, 26 July 2007 (UTC)

Adding Long and short scales to the "See also Magnitude prefixes and Order of magnitude." would be useful. Any reason for not using the {{see also}}? --Philip Baird Shearer 05:57, 30 July 2007 (UTC)

Long and short scales added. Didn't know about the see-also template, but ... no, can't see much use for it. Tony 10:21, 30 July 2007 (UTC)

I think a better link than Commas is Commas. --Philip Baird Shearer 05:57, 30 July 2007 (UTC)

Indeed—done. Tony 10:21, 30 July 2007 (UTC)


I think the wording is silly. a "decimal point" is far clearer than "period". What is needed for those editors from Decimal separator#Comma countries that in English a decimal point is used between the between the integral and the fractional parts of a decimal, and that a comma is used symbol as the thousands separator. And probably a mention that when a number in numerical is taken from a non English language source that care is taken with the translation of the decimal seperator and the thousands separator. --Philip Baird Shearer 13:51, 25 July 2007 (UTC)

Let's agree on something: I won't call you "silly" if you don't call me "silly". Tony 14:04, 25 July 2007 (UTC)
I agree not to call you silly, because I never call any editor silly. I did not call you silly, I said "I think the wording is silly" --Philip Baird Shearer 14:23, 25 July 2007 (UTC)
Call my wording silly, you call me silly. Your input here is valuable. Please be positive. Tony 14:32, 25 July 2007 (UTC)
How is this? "A decimal point is used between the integral and the fractional parts of a decimal; a comma is never used in this role (6.57, not 6,57)." Commas as thousands separators are comvered under "Large numbers". Tony 04:14, 26 July 2007 (UTC)
But a comma IS widely used in that role in many places all over the world. However, it isn't common in many English-language (English as the main language) countries. Why doesn't WP just adopt whatever has been thrashed out in International standards? They have already done the donkey work of avoiding ambiguities and addressing conformity. 81.178.115.45 2007-07-25 20:00 UTC
I'm with Tony1 on this. The way around 81...'s objection is simply to change Tony's suggested language to "a comma is never used in the English Misplaced Pages" (an in point of fact, many of the non-English ones do use this weird comma-as-decimal thing.) — SMcCandlish ‹(-¿-)› 00:26, 27 July 2007 (UTC)
I've changed the draft wording thus. Tony 01:04, 27 July 2007 (UTC)
  • 3.4 Percentages
    • Perhaps a recommendation to use percentages rather than pro mille (/00) figures, since they are uncommon in English usage (I've only seen them in translated documents). -- Arwel (talk) 13:45, 22 July 2007 (UTC)
Unsure that the introduction of this point is appropriate in a summary. Does it need to be in the more detailed MOSNUM? Tony 13:18, 23 July 2007 (UTC)

Convenience link back to the draft summary

4 Units of measurement

Made it optional for UK-related articles—see notes above. Is that OK? Tony 13:18, 23 July 2007 (UTC)

The UK needs removing from the first bullet point --Philip Baird Shearer 14:18, 25 July 2007 (UTC)

Thanks; done. Tony 14:36, 25 July 2007 (UTC)
  • 4.2 Unit symbols and abbreviations
    • Seems OK, apart from the mis-spelling of "Fahrenheit", which I took the liberty of fixing. -- Arwel (talk) 13:45, 22 July 2007 (UTC)
    • Added or imperial gallon,... —MJCdetroit 04:00, 23 July 2007 (UTC)
    • Anyone know whether you say "degrees farenheit" with small "f"? Both Celsius and Kelvin articles seem to make a consistent distinction between, say, "Kelvin scale" and Celsius scale, and 20 degrees kelvin, and Celsius units and 20 degrees celsius; the Farenheit article contains no examples of the latter, and a search of the Internet reveals both upper- and lower-case f in that role. I'm confused. Tony 13:56, 23 July 2007 (UTC)
    • Whoa! At least Kelvin, Celcius, and Fahrenheit should always start with a capital letter (not sure about Centigrade though), as they are all names of people. Additionally, since Kelvin is an Absolute scale, you would say "two hundred Kelvin", and NOT "two hundred degrees Kelvin". 81.178.213.159 2007-Jul-23 15:41 UTC
The no-degree symbol point is already in the text. It needs to be said that you don't include the word degrees, as well, which I'll add. I think I'll leave notes at those articles about the upper/lower case inconsistencies, then. Tony 15:48, 23 July 2007 (UTC)
  • 4.3 Conversions
    • Mention the {{convert}} template here?
Done. Tony

5 Currencies

  • 5.1 Which one to use
  • 5.2 Formatting

6 Common mathematical symbols

7 Geographical coordinates

Partial dates seems to have become misplaced under this section heading.

It's a section I found bemusing on first encounter, and still feel is unclear. "Dates which do not reflect users' preferences ...": I thought it was telling me that a user following that link would end up at a page other than where s/he wanted to go. It's all very negative. Could usefully all be scrapped, replaced by the couple of sentences explaining how User Preferences affect day/month dates, which I've just seen elsewhere ... ah yes, it's your "Autoformatting and linking" proposal, which seems sensible, thanks. PamD 16:40, 25 July 2007 (UTC)

So are you suggesting it should just be removed? Is there nothing to say about the topic? I must say that I was perplexed as to what to do with it: my brain melts when I try to read it, and it's clearly been pushed and pulled about by parties who disagree on it. What to do? Tony 01:02, 26 July 2007 (UTC)

Convenience link back to the draft summary

Circa

Why are we recommending the use of "c.", when "ca." is at least as common, and less ambiguous ("c." or "c" is also often used to mean centrigrade/celsius and even centimeter, among other things)? — SMcCandlish ‹(-¿-)› 15:54, 23 July 2007 (UTC)

I hadn't thought about it; it's there in the existing text. Neither c. not c stands for centimetre: that's cm. Centigrade is now a no-no; the term is Celsius, and the abbreviation is upper-case C.
I don't care if people want to allow ca. as well, but they'll have to speak up. Tony 16:08, 23 July 2007 (UTC)
I always thought c. was more common. Stephen Turner (Talk) 22:31, 23 July 2007 (UTC)
There are online dictionaries that define both ca. and c. as abbreviations for "circa", each along with other possible meanings. Both are somewhat ambiguous, but I doubt that either has much potential for serious confusion. I think WP would look even sloppier than it already is if we allow or encourage the use of both abbreviations. Switching all "c." to "ca." would be an immense waste of time and resources, and could be the source of much strife. I see little or nothing to gain by this; a day doesn't go by without an editor trying to change some WP guideline to match a style that they feel comfortable with, or find personally appealing. If a group of three or four editors managed to declare a consensus about "ca.", the day would not be far off when another small group of editors would declare a consensus to switch back to "c.", so this kind of change should not be implemented without good cause. Chris the speller 22:51, 23 July 2007 (UTC)
Chris, no one's talking of forcing all instances of c. to ca.. The proposal, I think, is to ADD ca. to the allowable abbreviations. I don't care much either way. Tony 03:38, 24 July 2007 (UTC)
Every time I read the proposal (actually, it's just a question), I see it as favoring "ca.", and it doesn't say anything about keeping "c." as well. If "ca." is better (it isn't), why keep the older, inferior option?. And if it is not better, we already have "c." as unsurpassed, so why add an alternative that yields no benefit? Encouraging inconsistency degrades the guideline. Chris the speller 13:37, 24 July 2007 (UTC)
So are you happy with the current proposal on this point? Tony 15:52, 24 July 2007 (UTC)
I am happy with the current guideline, abbreviating to "c." Happy Simón Bolívar Day! Chris the speller 16:56, 24 July 2007 (UTC)
I agree with Chris ts - "ca." is pretty old-fashioned in my experience. Johnbod 17:03, 24 July 2007 (UTC)
To clarify, I am proposing to add "ca." as allowable; I thought I'd made that clear when I said that it "is at least as common", implying that "c." is certainly common enough to retain. My other points were basically "why I use 'ca.' instead of 'c.' (As I side point, I wasn't trying to suggest that c. is an official or widely accepted abbreviation for Celsius, centimeter, etc., just that it occurs, and that reader unfamiliar with circa are likely to misinterpret it. But, again, c. = circa is so common I would not at all recommend taking it out of the MOS!) As for "old-fashioned": I read a lot of nonfiction, on a variety of topics, especially ancient history and religion/myth, and I see "ca." very frequently. Many of the books on these topics are British, so perhaps it is a Briticism. I don't really know. So, yes, I'm saying let's change "c." to "c. or ca." in the guideline. — SMcCandlish ‹(-¿-)› 01:14, 26 July 2007 (UTC)
No it's not a Britishism, or a modern one anyway. I would certainly not agree with your statement above that ca. "is at least as common". Johnbod 16:26, 26 July 2007 (UTC)
As I said above, I'm easy about allowing the option, but I think it would have to garner more support. Tony 01:36, 26 July 2007 (UTC)
I still see a standard abbreviation that works, along with a MoS that encourages consistency, and on the other hand a user who prefers a different abbreviation. I can't support the proposal unless and until I see how it will improve Misplaced Pages. Chris the speller 03:14, 26 July 2007 (UTC)
It's not that "a user prefers a different abbreviation", it's that the different abbreviation is in long-standing common (including formal) usage. Not arm-twisting editors into unnecessarily writing in an overly restricted manner just to keep two words out of the WP:MOS is justification enough. It will "improve Misplaced Pages" by not needlessly telling editors that they cannot use a standard abbreviation just because "a user prefer" it. >;-)
Both "c." & "ca." are common enough in usage that I can't see one being eliminated without some bloodshed. However, I've always been puzzled over the use of abbreviations (except where done for reasons of style) in Misplaced Pages: abbreviations are most useful to conserve space, & Misplaced Pages is not paper. I'm not making a cause out of this (if I were to need a cause, I have other things I would choose first), just stating my observation. -- llywrch 20:09, 26 July 2007 (UTC)
Keeping the current long-standing guideline should not cause bloodshed, since it hasn't already. Chris the speller 00:20, 30 July 2007 (UTC)
I have to say that I agree with SMc, Johnbod and Llywrch, and I think that Chris is confusing consistency with standardisation. Aren't we all used to tolerating both in the literature? The difference between them is so minor. But 'can we have more opinions? Tony 02:28, 28 July 2007 (UTC)
If you agree with Johnbod, then you agree with me; he is not a fan of "ca." I am not confusing consistency with standardisation (or standardization). You seek consistency within an article, while I prefer the same abbreviation in the William Procter and William Proctor dab pages, as there is a good chance that a reader will visit the other if the first did not satisfy; this consistency among pages can only be achieved through standardization. Chris the speller 00:16, 30 July 2007 (UTC)
Both "c." and "ca." are common abbreviations for "circa" and widely recognized. I think both are acceptable as long as an article has consistent usage. I mainly use "ca." Askari Mark (Talk) 02:58, 28 July 2007 (UTC)
Right! I did not mean to elide discussion of intra-article consistency; I just generally presume that is always the case (e.g. if top half of article gives metric first, we don't do "X feet (Y m)" later in the article, etc., etc.), a general principle. PS: high five on "I mainlly use ca." :-) — SMcCandlish ‹(-¿-)› 15:08, 28 July 2007 (UTC)
It should be: build consensus first, change the guideline, then follow the guideline. By high-fiving editors for ignoring the guideline, you are tipping your hand. This topic started out as a question, then you admitted it was a proposal, and now it might be time for you to admit that it is a crusade. I feel that you have suckered me into wasting my time and effort. It's not the first time I have been sandbagged on a WP talk page, but it doesn't feel any better than the first time. I don't favor "c." over "ca." because of personal style preference, but because it's the WP standard, and there is no need to change it. I'm only trying to improve Misplaced Pages, and I'm not going to waste any more time on this. — Preceding unsigned comment added by Chris the speller (talk • contribs) 00:40, 30 July 2007 (UTC)
Whoever you are, if a simple debate about style guide details gets you so worked up your sense of humor goes into a coma, perhaps you should try a different talk page? Askari didn't say "I ignore the MOS and use ca. because I think MOS is stupid", and I didn't agree with that (imaginary) sentiment. He said "I mainly use 'ca.'", which I think most people would interpret to mean beyond Misplaced Pages (whether he also does that here is indeterminate). I don't feel like getting yelled at by someone at random for expressing happiness that I'm not the only general non-"c."-user here. So, try decaf.  :-) — SMcCandlish ‹(-¿-)› 06:40, 30 July 2007 (UTC)
I am sorry that I forgot to sign; I don't take anonymous potshots. I have not gotten worked up about a simple debate; a simple debate does not include slapping others on the back for sharing a personal taste. I was worked up as a result of your disingenuous question that started this, which then became a proposal, and then a crusade. Since this discussion is about Misplaced Pages, I don't think I am off-track when I assume Askari is talking about "ca." within WP. Once more, I will state that my efforts here were not about my personal taste, as yours were. I only opposed changing the guideline, which has worked just fine up to now. If there were good reasons to relax it, I would be fine with that, but there have been none. If the guideline had "ca." and you wanted "c.", I would oppose that as well, not to oppose you, but to keep the guideline simple and WP more professional. Chris the speller 13:36, 30 July 2007 (UTC)
There does seem to be more support for allowing both c. and ca. than the current restriction to just c. (am I correct?). I've changed the draft accordingly, with a little trepidation. Tony 15:18, 28 July 2007 (UTC)
With regard to being barked at, or to some kind of unintended side effect? — SMcCandlish ‹(-¿-)› 19:51, 28 July 2007 (UTC)

Cleaning up the scraps

OMG, what nooks and crannies does MOS have. I've unearthed a stubby yet "official" little style guide called Misplaced Pages:Avoid_statements_that_will_date_quickly. In the interests of cohesion, I feel that it should be deleted and the guts of it included here (there's not much, I assure you). I've left a note on its talk page, which hasn't been touched for nearly a year. Tony 00:47, 25 July 2007 (UTC)

OK, all I thought worth salvaging was something quite valuable concerning the need to avoid vague language. I've added a new subsection to our draft summary, called "Precise language". See if you like it. Tony 03:31, 25 July 2007 (UTC)
It's important to retain the ] 2007 business discussed in . I myself only encountered this last week, but I've found templates that make use of the "As of YYYY" stuff, and so on. It's not hugely known, but WP:DATED is in play in the background. I'm not sure it really should be part of WP:MOSNUM though, as it isn't really about date formatting, but (as it says) avoiding the use of statements that will date quickly; it's more a matter of writing structure than number formatting. My mind could be swayed on this point though. — SMcCandlish ‹(-¿-)› 16:26, 26 July 2007 (UTC)
Are you satisfied with the current draft of "Precise language"? Tony 03:21, 28 July 2007 (UTC)
I got an idea, why not put it on Misplaced Pages:Miscellany for deletion? That's the best solution, this page is so old, we shouldn't just get rid of it without some real discussion. TheBlazikenMaster 11:12, 14 August 2007 (UTC)

What to do with the existing link-related section

I'm not in favour of including stuff about linking dates in the summary for MOS central, beyond the link that you'll find in the draft.

If there's support for "retro-pasting" the summary back into MOSNUM (with different examples and other changes to be approved by users here), that will bring up the issue of what to do with the opening section. There are several problems as it now stands:

  1. MOS is not a "technical how to" guide, but a style guide. For that reason, the people at MOS central readily agreed to the removal of the odd explanations of how to produce bold and italic, etc. That is what How to edit a page is for. MOSNUM, then, shouldn't be cluttered with similar how-to advice, but should get straight into matters of style.
  2. Most of the substantive guidance in the first sections is now covered in the new draft.
  3. It's visually messy and complicated—not an engaging or attractive start to MOSNUM.
  4. It may be better in the submanual for links.
  5. Let me come clean: I take a conservative line on linking, which I believe should be based on functionality and readability, and undiluted by the linking of dictionary terms and items that don't help the reader. I like links to be highly focused on the topic at hand, and piped if possible. Linking years alone, let alone sole months, makes me want to puke. Yet this opening section seems to be obsessed with the linking of years. The continuing failure of the developers at Wikimedia to decouple the autoformatiing and linking functions, despite a petition by 85 of us last December, is gobsmacking; accordingly, I'm ambivalent about linking even full dates (although I suppose I can cope with that).

For these reasons, I'd be pleased to see the few remaining useful snippets plucked out of the opening sections and relocated elsewhere here, and the rest given to the Links submanual, with a link to them from here ... or not given to them, since "how to edit a page" tells you how to link. :-) Tony 05:36, 25 July 2007 (UTC)


  • I suggest that (1) the following text replace the subsections 1.1–1.6 of MOSNUM, to be located at the end of "Chronological items"; and (2) that a link to this be provided in the summary at MOS central, as in the current draft:

Autoformatting and linking

  • The WikiMedia software formats full dates, and days and months, according to the date preferences chosen by registered users. This function is activated by inserting double square-brackets, as for linking; it works only for the small proportion of users who are registered, and for all others will be displayed as entered. Do not autoformat dates in article and section headings, on disambiguation pages, or within quotations (unless the original text was wikilinked). The autoformatting mechanism will not accept date ranges (December 13–17, 1951) or slashes (the night of 30/31 May), which must be input without using the function. Thus:
    • either ] (US editors) or ] (others) will be rendered as either February 17 or 17 February, according to a registered user's set preferences; and
    • either ], ] (US editors) or ] ] (others) will be rendered as either February 17, 1958 or 17 February 1958, according to a registered user's set preferences.
  • Misplaced Pages has articles on days of the year, years, decades, centuries and millennia. A link to one of these pages will occasionally help to deepen readers' understanding of a topic. Piped links to pages that are more focused on a topic are possible (].

Tony 10:19, 25 July 2007 (UTC)

I disagree. That wording is incorrect and insulting. Date linking is clearly a style matter as long as the style is determined by the links. There are four supported date styles, not two as you indicate. The links certainly work for non-logged in users (which you have no grounds to claim are a minority - unneccessary and unsourced.) It is the date preferences that don't work if not logged in. "will occasionally help to deepen readers' understanding of a topic." clearly shows your bias against such links and is not Manual material. Rmhermen 15:02, 25 July 2007 (UTC)
To take your complaint sentence by sentence:
"That wording is incorrect and insulting." Why on earth is it insulting? It's a technical matter, and you've responded in a very personal frame.
"Date linking is clearly a style matter as long as the style is determined by the links." That is acknowledged by its coverage in this subsection. But date linking is very much on the techie side of style. The existing sections at the top are a long-winded exigesis of "how to", which is off-topic for a style guide. There is a Linking submanual.
"There are four supported date styles, not two as you indicate." Only two mechanisms are explicated in the current text (day/month and day/month/year); what are the other two, please, and I'll add them.
"The links certainly work for non-logged in users." Linking works for everyone, but the autoformatting mechanism doesn't work for non-registered users or registered users who either have not logged in or have not set a preference. Does that statement need to changed? Did I get it wrong?
"... which you have no grounds to claim are a minority - unneccessary and unsourced". Are you claiming that of the how many million visitors a day to WP, more than half are Wikipedians? I don't think so.
"... "will occasionally help to deepen readers' understanding of a topic." clearly shows your bias against such links and is not Manual material." Are you saying that linking doesn't deepen readers' understanding of a topic? If so, I agree WRT what is known as overlinking. I love the linking function, and want to see it skilfully targeted, that's all, not spattered indiscriminately over the text.

Tony 01:30, 26 July 2007 (UTC)

I'd like to strongly echo Tony's overlinking concerns. I terminate crud like "In 1999, Smith..." with extreme prejudice. If the language proposed here stays, please make it read "will occasionally help to deepen" instead of "will occasionally help to deepen". — SMcCandlish ‹(-¿-)› 16:40, 26 July 2007 (UTC)
PS: Re: the petition – What next? Should we do another petition? Take it to ArbCom? ;-) I feel as strongly as Tony does that the formatting and linking functions with regard to the dates need to be fixed way before yesterday. Maybe this should be a new topic (feel free to refactor it into one.) I remember commenting on an early topic about this here (long since archived) somewhere back around March. It's almost August now, and we still have bupkus in the way of any indication when/if this agonizing problem will ever be fixed. — SMcCandlish ‹(-¿-)› 16:40, 26 July 2007 (UTC)
The tech who took on our request (the same guy who'd deflected a previous, less well-organised and patronised request in early 2006) reponded to the effect that "we don't think it's worth the trouble to do the programming; do it yourselves and present it, and even then it would have to be approved by the powers that be." In other words, "Go jump in the lake."
One tech-savvy signatory (Rob Church) undertook to us to create a program—not to undo the existing function, which would have dire retro implications, but to create a new function for autoformatting dates without linking them. He got some way in this during January 2007, but has since dropped out of or drastically reduced his activities on WP. So it has stalled. I did a lot of work getting that petition together and servicing the process, so I'm kind of burnt out on it (as I'm nearly burnt out on the new MOSNUM thing). But I'd heartily support a fresh push to higher authorities. Heartily. We already have the by-now 85 signatures, and I'm sure more could be added in a new push.
Frankly, I'd be happy with a program that simply changed the colour of all (existing and new) autoformatted dates from blue to black, if that made it technically easier than producing a new, parallele code for autoformatting alone (our previous goal).
On a related topic, I'd much prefer that links were coloured a more subtle, but still quite identifiable blue colour than the current stand-out, disruptive blue; midnightblue perhaps? In bold, they're blue and midnightblue. My god, looking at the opening to some of the articles featured on the main page, where the text is squashed into half a page-width: spattered with so much blue that they're plain messy and hard to read. Tony 01:35, 27 July 2007 (UTC)
You can simply edit your own user stylesheet to change link colors. It is located at User:Tony1/monobooks.css (assuming you use the default monobook skin). Inserting the line "a { color: MidnightBlue }" should do it. On my screen, text in that color is almost indistinguishable from black, which is worse than being bright and garrish. Links are meant to be visible, though certainly there are lots of cases (dates among them) on Misplaced Pages where they can become annoying. That is a result of excessive linking; the solution is to link more carefully, not to make links less visible. — Aluvus t/c 03:50, 28 July 2007 (UTC)
Alvulus: brilliant, if I could get it to work. I tried the code you suggested, both with and without the double quotes. I then emptied Safari's cache. No luck. The link is the one you provided just above; would you mind having a look at it to see that I inserted the right code? Much obliged. Tony 04:38, 28 July 2007 (UTC)
I'm afraid there's a typo in the link I provided, which should be to monobook.css, not monobooks.css (I originally typed it incorrectly, changed it, and thought I pasted the fixed link... apparently I was wrong). If you go to the correct page and enter that line (without quotes), it should work. Depending on your browser there is maybe a possiblity that you will need to enter the actual hex value for the color, but it shouldn't be an issue. If you have any other problems, you may want to leave a message on my talk page (as it's getting a bit off-topic here). Sorry about the dud link. — Aluvus t/c 07:13, 28 July 2007 (UTC)
Minor changes to the proposed section just made: are they OK? Tony 01:45, 27 July 2007 (UTC)
Re: Date ranges: I'd like to see us directly discourage the blathery (and eventually hard-to-undo, when the underlying link/format problem is fixed by the developers) practice of kluging date ranges in this manner: "February 2 &ndash February 4 2007. I think that really blows, but I'm seeing it more and more. It is far more important for the article to be readable and not logorroeic than for every date to be formatted perfectly for registered users. — SMcCandlish ‹(-¿-)› 17:10, 27 July 2007 (UTC)
Having looked up kluge (I didn't even know kludge), I agree entirely with SMc. The autoformatting function is becoming a pest now that we're more aware of what it can't do, and are thoroughly exasperated by its conflation with the linking function and the disruptive blue display. That is why the overhaul will be a significant change, in removing the ugly, hard-to-read text at the top about linking, and expressing the whole damn thing in a small section tucked in at the end of the chronological items. It talks of no compulsion to use the autoformatting function; it merely says that it's there, and indeed points to disadvantages. What I can do is to explicitly say ... yes, have a look at what I've done: "The autoformatting mechanism will not accept date ranges (December 13–17, 1951) or slashes (the night of 30/31 May), which must be input without using the function." This is a significant change from the current policy (indeed, it's the most significant change in the whole exercise. At the moment, the text reads "the date should almost always be linked to allow readers' date preferences to work, displaying the reader's chosen format". I think most of us are decreasingly willing to bend to its inflexibility and other disadvantages. In fact, for some time I've been openly discouraging people from using the autoformatting function for any date. Putting up with US date formatting, where it occurs, is just fine. And vice versa. It's much less significant than the differences in spelling that we happily tolerate. Tony 02:17, 28 July 2007 (UTC)
"In fact, for some time I've been openly discouraging people from using the autoformatting function for any date." A lot of articles would look horrid if no one used the date autoformat feature. I have occasionally seen cases where dates in the same sentence or table are entered in different formats (occasionally even the ISO format that bewilders many people, myself included). The autoformatting system has its flaws, but discouraging people from ever linking dates is a baby-with-the-bathwater solution. — Aluvus t/c 03:50, 28 July 2007 (UTC)
But naturally, we insist on consistency within articles: that's basic to the whole MOS. I agree that autoformatting does it for you (if, indeed, all dates are consistently autoformatted, which is not always the case). That's handy, but the disadvantages of a functionality that has not been updated in a long time are becoming too great: that's my point. Tony 04:19, 28 July 2007 (UTC)
What if an article were consistently formatted in the ISO format? I'll be blunt: I've always thought the "use both American and British spellings, just be consistent within the article" policy was a bit daft (though perhaps unavoidable, in Misplaced Pages's culture), and am equally skeptical of the (many) policies that attempt to mimic it. It was never a good solution, only an adequate one. Similarly, merely keeping date formats consistent within individual articles will never be a good solution, and it will inevitably lead to new problems (similar to the current edits that do nothing but change spellings from one style to another). Date autoformating has essentially two flaws: that dates become links of questionable usefulness (which can be resolved with a technical fix), and that date ranges cannot be input in abbreviated formats. Date ranges could also be made to work via technical changes, but this would probably be fairly touchy and a general pain. But let's be realistic: there are many, many dates in the Misplaced Pages, and comparatively few date ranges that could be abbreviated. In any case, I don't see that these issues are severe enough to warrant tossing out a very useful feature. — Aluvus t/c 04:41, 28 July 2007 (UTC)
I'm not saying toss it out; I just don't think it should be mandatory. And I'm unsure of the matters that weight on your mind concerning the admissability of major varieties of English (not just US or British, as you stated). I think that consistency within an article is a practical principle in an English-language beast such as this. In French, they'd insist on a centralised approach; that's the way they've done things for a long time. English, by constrast, is big and baggy. PS ISO is strongly discouraged by MOSNUM. Tony 06:51, 28 July 2007 (UTC)
  • Alvulus, you are brilliant! It works! Now links are a much nicer, less instrusive colour, and I can't thank you enough. I'll be promulgating this improvement among all I know. On the colour, yes, midnightblue is probably not distinctive enough for most people/browsers, and I'm going to explore compromises such as sapphire and navy blue. I've put the instructions on my talk page, here, together with a comparison over whole paragraphs of the current default colour with four other, increasingly dark colours. Tony 13:33, 28 July 2007 (UTC)

Units

There seems to be no guidance on how units of area should be written in articles giving a mixture of sq ft/sq m, square feet/square metres and ft/m. Which one should be used? CR7 12:14, 27 July 2007 (UTC)

This issue isn't limited at all to units of area in particular. Unless the document has changed, it already recommends spelling it out the first time, and abbreviating later, especially in parentheticals: "The widget is X square feet (YYY square centimeters), while the superwidget is XX sq. ft. (YYYY sq. cm)" Or I think maybe it still says never use periods after nonmetric unit abbreviations like "ft" or even after non-unit abbreviations like "sq"; I remember getting in a debate about that here, but I don't think it resolved with consensus; my take is that it should absolutely be "sq.", just like "ca.", "etc.", and other general abbreviations, and should also be "ft.", and "in." and "mi." and such in non-metric units, per centuries of tradition and offline style guide recommendations.). The superscripted version should be deprecated, and I thought that it was, but this document has been changing so much I've lost track. Tony1 probably knows better, since he spends more time here. — SMcCandlish ‹(-¿-)› 17:16, 27 July 2007 (UTC)
I think it's necessary to define that more, I've also found some people are using both square foot and square feet as plurals. Which one should be used. Am I correct in asuming that from your last post you mean that all units should be written in full first time - square feet/square metres then abbreviated to sq. ft./m. Adding full stops after abbreviations is also sketchy because its a divider between BrEng and AmEng. Personally, as a Brit I'd write sq ft, but if sq. ft. should be used, I'll go with it. CR7 23:34, 27 July 2007 (UTC)
The draft that is soon to be implemented says no dots in unit abbreviations. The current text, unchanged in meaning, says to spell out units always in the main text, and always to abbreviate the converted unit in parentheses. Tony 02:06, 28 July 2007 (UTC) PS, SMc, there is a lot of usage of the superscript "square"; um ... retro problems in proscribing it?
You'll get a fight from me and probably others on "no dots in unit abbreviations" rather than "no dots in metric unit abbreviations, and dots or no dots are okay in Imperial/American/whatchallem abbreviations". :-/ I was getting notable traction on that issue already here, but all of the stuff I'd been pushing and pulling on several month ago got archived, because I was busy for a while and working on other things. I've hardly forgotten about the 10 or 20 MOSNUM improvements (from my point of view) that I individually delineated (though I do recall abandoning some of them, and saying so in their sub-topics). So here we go, new subtopic below... — SMcCandlish ‹(-¿-)› 15:05, 28 July 2007 (UTC)
So should sq ft/sq m be used or ft/m? CR7 13:09, 28 July 2007 (UTC)
The linear, non-superscripted one. Many of our readers are not terribly educated and don't even understand that can be prounounced "square". Granted this is not the Simple English Misplaced Pages, but there is no reason to make things pointlessly difficult for anyone (including editors – which of those two options would you rather have to type? Heh. — SMcCandlish ‹(-¿-)› 15:05, 28 July 2007 (UTC)
SMcC, are you calling, then, for a change in policy (proscription of the superscript)? I guess I'd don't like the superscripts because they alter the line-space above, giving a lumpy appearance. So I have no problem with your proposal. More opinions required. Tony 15:39, 28 July 2007 (UTC)
I hadn't planned on "going there" with this, but what the heck, if I'm destined to be the "MOS Bad Boy", then: Yes! The superscript thing has been driving me nuts, especially with those annoying fraction templates (there's nothing wrong with "2-3/4"; argh.) It does monkey the line spacing and make it look weird. However I'm also the prowikigenitor of WP:ILT, and support the superscripting of the inline cleanup and citation templates at issue. That might sound contradictory, but it's really more that I'd rather see <sup> used for annotation (only), and regular text to remain smoothly inline. Your label "lumpy" for it is perfect. I have the same utter detestation for old-school typefaces where the "9" and the "3" and various other characters are effectively partially subscripted. Hideous. To moderate this minirant, I would have no problem at all with 10 in mathematical contexts (though other notations exist that obviate that; I suck at math, so I find them confusing; entirely personal bias). Mathematical use of superscripts and subscripts are to me no different than use of proper diacritics in non-English words: It's just how they are supposed to be. I rankle at spreading the style outside the science context and feel that doing things like "ft" is just geekiness for the heck of it, a bit like referring to "4 inches" as "approximately 0.33 feet" for no good reason. Or akin to writing "coöperation" (a style that was briefly in vogue when I was a child, and fortunate died, died, died. Nestlé and Cẽpacol notwithstanding.) PS: The fix for the superscript issue is to use CSS to give us a hair more line height by default everywhere. Even after that, I would still cringe at "2 ft" for the "lumpiness" factor your raise. I like that the annotation templates are "lumpy"; they're supposed to be, while general prose isn't. Kind of like Southern (American) mashed potatoes vs. one's thighs (though too much of the former may engender the latter). — SMcCandlish ‹(-¿-)› 20:30, 28 July 2007 (UTC)
Will this be written into the Manual of Style in due course then, to avoid the mixture out there? CR7 15:55, 28 July 2007 (UTC)
There are four options: do as now—not mention it; mention both, recommending non-superscripted ("... normally used ..."); and proscribe superscripts. Will there be a significant retro problem is they're proscribed? Tony 16:57, 28 July 2007 (UTC)
Nothing serious I can think of; a few templates would get TfD'd (with bots cleaning up their mess), and slowly over time things would get normalized, a bit like "illogical quoting," like that instead of "logical", like that; I undo probably ten of the former every wikipedia-day, running across them randomly, but less and less all the time. Fortunately there are at least an order of magnitude fewer superscripted widgets vs. Yankee quotes. — SMcCandlish ‹(-¿-)› 20:30, 28 July 2007 (UTC)

Periods and traditional, non-metric, non-scientific units, redux

The stodgy and traditionalist Folwer's Modern English Usage (Burchfield's Oxford hardback rev. 3rd ed.) consitently uses periods with all abbrevations, without exception, so far as I can determine. I have yet to find a single instance of Fowler/Burchfield not spelling out "centimetre", etc., so I can't say whether F/B would permit lack of period after "cm", but I consider that a moot point; actual usage is very, very widely anti-period with metric units.

Chicago Manual of Style (15th hardback ed.), more modernly and less conservatively, uses no periods for units that typically don't have them in general usage ("SF" for "Swiss Franc"; "mm" for "milimet", etc.) and preserves them where they are common ("12:01 a.m.", etc.) Through pages and pages of abbreviation (sec. 15) and number (sec. 9) advice, two things stand clear: Chicago recommends not using periods with units of measure in scientific writing, because of standards like the AMA Manual of Style for that context, but otherwise advises that periods be used when the abbreviation/acronym is lower case and not used when uppercase (with various enumerated exceptions). This book does not recommend using abbreviated units (in. or in, preferring inch) at all unless in scientific usage, but we know that doesn't really fly; no one on Misplaced Pages is going to want to read "...may range in size from 4 feet 2 inches by 3 feet 7 inches, through intermediate sizes 5 feet 1 inch by 3 feet 11 inches, and 5 feet 5 inches by 4 feet 3 inches, up to 6 feet by 5 feet 4 inches..." (much less with metric equivalents in there too); only the first occurrence should be spelled out (and metric & scientific units need never be spelled out unless they are the very uncommon ones) in keeping with WP's general avoidance of redundancy to the extent possible (duplicate wikilinks, etc.) – we have an actual justifiable need to ignore Chicago (and Strunk and White, who also eschew unit abbreviations) on this particular matter. More to the core point, though Chicago notes that British (and French, e.g. "Mssr") style, in contrast to North American style, is to not use periods even when lower case. I think that this is a pretty authoritative source for this distinction, and thus "never put period after unit abbreviations/symbols" without exceptions for traditional US/Canadian usage is not tenable, because a) Misplaced Pages is not a science journal and b) per MOS itself, POV-pushing either US- or UK-centric spelling, grammar, and vocubulary is verboten.

There is ample evidence all around us that periods are (not universally, but commonly) used with traditional units, but not with metric (cm, etc.) and scientific (dB, BCE, etc.) ones. It's obvious from simple day-to-day reading exposure that usage with regard to traditional units is divided sharply, and not only across Atlantic lines. I do realize that standardizationists (think AMA Manual of Style, etc.) within the science community (ring any KB/KiB bells, anyone?) are adamant about no periods, ever, on unit symbols/abbreviations, but WP is not Nature, this is an encyclopedia written by and for an vernacular English-using audience, and an enormous number of them expect, prefer (even, in catankerous cases like mine, demand) periods after traditional units that have always had them until the technical standards people started exceeding their boundaries. Telling people who naturally write this way that they cannot use periods where they belong is tatamount to telling American writers that "Mr", "Mrs" and "St" cannot have a period after them in American-English articles or that Commonwealth English writers have to stop putting an allegedly superflous "u" in words like "colour". We just don't do that here. — SMcCandlish ‹(-¿-)› 15:05, 28 July 2007 (UTC)

The short version being, we have no business arm-twisting editors into contrived and arguably inapplicable style straight jackets without ironclad reasons. The most common rationale is avoidance of confusion and ambiguity, which is precisely the problem caused by no-periods usage on traditional units, since some of them are also words ("in", "gal", etc., withi "in" being the worst because its one of the most common words in the language, with multiple morphological/syntactic uses, making any phrase in which "in" is used as a unit of measurement double-take-hard to understand for far too many readers. — SMcCandlish ‹(-¿-)› 15:05, 28 July 2007 (UTC)

The existing MOSNUM and the new draft allow abbreviations of units only as conversions within parentheses. On WP, I see almost entirely in rather than in., and ft rather than ft. in US conversions; presumably, most of these are written by US editors. The existing MOSNUM didn't specify whether a dot should or should not be included; it was my assumption that proscribing dots in these conversions would reflect current usage. The abbreviations are already highlighted as such by their location after metric units and within parentheses.
Whether a practice happens to be (mostly) associated with British or American style shouldn't mean that we can't choose one of them. A perfect example is the so-called logical punctuation, placed outside rather than inside closing quote marks. Is a partisan argument about that necessary?
My first preference is to proscribe the dots in all converted units: it's simple, I believe that it looks better, usage in the US is by no means clinging to such dots (witness WPian usage), it has the support of external authorities, and it reflects a widespread trend towards dispensing with dots throughout the Anglo world. More opinions needed.
Are you raising the spectre of allowing main units to be abbreviated after first occurrence in an article? I pushed for that some time ago and was howled down here. I don't care now. It would need to have consensus to change the current policy. Tony 15:35, 28 July 2007 (UTC)
We had a debate over here a while ago about how to abbreviate units of measurement, in particular square/cubic miles, yards, feet, etc. It was hard to gather an overwelming concenus but what was roughly agree to is that traditional/customary measures should take the "traditional" method of abbreviating (i.e sq ft, sq mi, cu yd). Whereas, metric/SI measurements should take the opposite "scientific" approach and use symbols (i.e. m², km², m³). This provides a greater contrast between the systems and it seems to be the most common/preferred way to write them. We should include this to be consistent throughout. With or without dots...I prefer without but I don't really mind them either. —MJCdetroit 17:45, 28 July 2007 (UTC)
Not sure what order to take this in, so I'll just make one up:
  1. That Wikiepedia itself shows a preponderance of "in" vs. "in." is rather circular, because it is WP's own MOS calling for this style, and there are people with bots and AWB scriptlings (I'm not sure what to call them; "scriptlet" is already taken by something else) that auto-change natural American and majority-Canadian style to (for us unnatural) periodless British (or French or science journal, as you wish) style, even in articles written in American English (as I aluded to early, this is pretty much the direct equivalent of going through all British English articles and faux-fixing "Mr", etc. to "Mr." Americans are clinging to their style, and WP is a self-invaliding statistic in that regard. WP is not the bar of measure, general usage is. We can't just develop our style guide in an e-vacuum, or pretty soon WP articles will read D00d, U gotsta kno D fakts, 101!!!!!!!!! roflmao". I have to say: w3 don n33d dem 1ing0z. Sure, I exaggerate, but we are trying to preserve something of the fading, reeking, wrinkled flower of real civilization here, and the barbarians aren't at the gate, they grew up in the back yard. <sigh> The fact that I just used a <Usenetism> probably makes this look hypocritcal. Oh well...
  2. Re: "presumably, most of these are written by US editors" – Why would that be a safe presumption? Unless I just totally forget, I always try to provide metric and non-metric equivalents, at great calculating time-expense (exhibit 1: Five pins) and I don't posit that Europeans, Australians, etc., aren't as conscientious. If the MOS says "there shallt be no periods", that would cause a WP-decline in their appearance, regardless of the editing population (and regardless if the editors were actually happpy with it). Not a huge side-point to the one above, but worth considering I think. There's all sorts of things I do (here) because MOS says so that I wouldn't normally (not that I'm the perfect test-case or anything; I'm just saying...My usage patterns are all over the map, from having learned to read and write in England, mostly growing up in the US, and also living in Canada. <fzzt spark pop> DOES NOT COMPUTE! I'm not terribly consistent with US/UK usage as a result. Other than using periods with lower case abbreviations and acronyms.)
I don't particularly dispute that periods are declining in any form of abbreviation (and have to note that the external authorities are largely the science journals and science style guides, a rarified group with a special, extra need for absolute unit notation conformity). They may be fading slowly, but I sort of lament the periods' dottage. (Pun honestly entirely serendipitous). It's like the dropping of the hyphen in "e-mail", or abandoning spelling and case considerations and writing "u kno wot i mean". Pure laziness (or "efficiency" to some). I concur with Chicago that when an acronynm/initialism/wahtever is in ALL-CAPS the periods (full stops, whatever) are superflous. I could add a couple of theorizing paragraphs about the UK "Dr" vs. US "Dr." how that is more akin to de-italicizing of "i.e." and "e.g." than it is to the current spate of technolaziness, but it would be a bit off-topic. And no I'm not a luddite (or Luddite if you prefer propering the eponyms); I'm a long-time Web (or is it "web" now? saves a keystroke...) developer, but I don't pretend that the "cool" e-trends (why not etrends, if we're going to have email?) don't have side effects, basically. ANYWAY... (yes, I'm getting tired, so I'm rambling...)
Yes, I done reckon I am a-spect&#91re|er]-raisin'. Allowing main units to be abbreviated after first occurrence in an article makes eminent sense; we eliminate redundancy in everything else, why not here? You aren't going to (I hope!) encounter something like the following in an article: "National Business Machines (NBM) senior executive Mr. Sam Jones, Chief Finacial Officer, while at National Business Machines (NBM) from 1997–1999, at $120,000 per year, was fully, deeply involved in a scandal during his tenure in management, an imbroglio of an affair that approximately cost National Business Machines (NBM) an

estimated $5,000,000 dollar out-of-court settlement, at great cost, that was privately settled, and yet this CFO Sam Jones (a male, not female) was retained by the National Business Machines (NBM) company, and even given a raise above his original salary, believe it or not, all the way up to $180,000 per year annually, despite the mismanagement of his scandalous management tenure at National Business Machines (NBM) during the late 1990s." You and any other sane editor would immediately eliminate every single one of the at least 30 redundancies in that, regardless of what form they took, and produce a lean sentence about 1/10th as long, if not shorter. Why on earth would we not do that with the feet/inches example I gave above (which is based, by the way, on a real example; some of the billiards game article have to specifiy what table sizes are considered standard for competition, and often it is 4 different ones)? If you got shouted down on this before, I'll be happy to stand on your side and shout right back next time until reason prevails and we abbreviate secondary occurrences of units (not necessarily mandatorily, but where it makes sense).

~
To MJCdetroit (my edit conflict above forked our threading): I guess I can see that it does differentiate (when exponents are present at all, which is pretty narrowly) between ft/cm (etc.) systems. I don't like the funky line spacing effect, but that's a CSS problem, not a MOS problem per se. If I'm going to stomp my feet to get moldy pre-metric syntax for moldy pre-metric units, I can't really begrudge shiny new metric people wanting their shiny new syntax. I think my spectre just fell asleep on the couch. Rats. @#$%er Drank all my beer too. However, those line-and-half-tall fancy fractions are quite another matter, long with those unicode fraction no one can type and I would suspect that most screen readers for the blind don't understand, and which can't be searched for unless you are an expert at figuring out what freaky key cominbation to press to input one of them into a search field, and... Maybe I should sent a ghoul and vampire after those, respectively. Spectres just ain't cuttin' it. — SMcCandlish ‹(-¿-)› 20:46, 28 July 2007 (UTC)

%

It would be great to have a source, why there is no space between a number and the % - as far as I know, in good typesetting there should be a small space - so a space is far better than no space. Well a source for that rule would be great. -- 217.84.150.117 01:28, 28 July 2007 (UTC)

Dude, we are the source. Tony 01:39, 28 July 2007 (UTC) — Preceding unsigned comment added by Tony1 (talk • contribs)
Haw! Good one. I laugh longtime. Even if you are being at least half-serious. — SMcCandlish ‹(-¿-)› 14:08, 28 July 2007 (UTC)
no, that's something you missunderstood! -- 217.84.150.117 01:43, 28 July 2007 (UTC)
I don't think so; Misplaced Pages is no longer a child, and is quite able to formulate its own style guide to suit its own unique mode, readership and functions. Please log on if you want to debate the matter. Tony 03:20, 28 July 2007 (UTC) — Preceding unsigned comment added by Tony1 (talk • contribs)
Amen to that latter too, if I may get Wikipolitical for a moment. Anon editing, don't get me started... — SMcCandlish ‹(-¿-)› 14:08, 28 July 2007 (UTC)
I had no trouble finding an example of the Chicago Manual of Style site using a numeral and percentage sign with no space in between. This is standard usage in all web copy; I cannot recall ever seeing a space inserted, in any web page. Additionally, 15.65 (subscriber link) specifically notes that no space should be used. Misplaced Pages is not at all alone in the way it handles percentages. — Aluvus t/c 04:08, 28 July 2007 (UTC)
More sources: Strunk & White's The Elements of Style (4th ed.) is silent on the matter, suggesting (as it is the most concise of the world-renowned style guides) that the matter has never been seen as controversial or even confusing enough to bother mentioning. Chicago Manual of Style (15th hardback print ed.): no space (sec. 9.17, pp. 384-385). Fowler's Modern English Usage (Burchfield's Oxford rev. hardback 3rd ed.): no space (p. 584). Next. Less flippantly, there are two not necessarily conflicting ways of looking at this: 1) It's simply a typesetting convention like putting end-punctuation inside quotations even if it doesn't belong to the quoted material, an incredibly stupid and annoying American habit (I can say that; I'm American) that has fortunately be given the finger by WP, and is on the decline offline as well, but not fast enough for my tastes; or using curly quotes in print, and to my chagrin more and more online, which add no functionality/disambiguation at all, just because they look "pretty". 2) Percentages are not actually a unit of measurement, but rather a phrase; it's simply latin for "out of each one hundred" – "2%" is simply a funky abbreviation for "two per cent" which is a strictly speaking unnecessary Latinism for "2 of each hundred." — SMcCandlish ‹(-¿-)› 14:08, 28 July 2007 (UTC)
well that's not resolved: I was not aiming at something may be called "web-style". I think we try to come nearer to the good style of printing nice books. And if you take a look to older books, then you will see that there are mostly spaces in front of the %. Even better - the wikipedia now supports automatic non-breakable spaces in front of the %. So please don't always argue with circle references. Greetings, -- 217.84.168.130 09:16, 6 August 2007 (UTC)
There is nothing at all circular about my reasoning. And this has nothing to do with "web style" whatever that might be. It's simply modern style. The argument you present is essentially the same for sub-scripting numerals like "3" and "9" because that is how typefaces in the eighteenth century printed them. We don't use "older books" as our style guide mentors for a reason. What was considered good style in 1872 often is not what is considered good style today (or rather "to-day" if we were going by "older books"). — SMcCandlish ‹(-¿-)› 10:24, 6 August 2007 (UTC) PS: If you still feel it is not resolved, then remove the "Resolved" tag. — SMcCandlish ‹(-¿-)› 10:26, 6 August 2007 (UTC)
well ... what I wanted to say is, that because of the technical restrictions of the www a style may have established, which is not a modern style but just a workaround - and if the workaround no longer is necessary, it's a style of nescience (which definitly is the case with a lot of german writers) or maybe ignorance. (Not) By the way: even the BIPM couldn't decide - but they did last year, as I have seen a minute ago: in their actual SI-brochure, they say: When it is used, a space separates the number and the symbol % -- great, that's new to me too, well and also my point of view! -- Schusch 11:33, 6 August 2007 (UTC)
well, I removed the "resolved" with the unproofen claim -- even in the Misplaced Pages it's not clear, see Percentage and Percent sign -- and the SI (BIPM) and ISO 31 are not of little account in these things. -- Schusch 10:52, 7 August 2007 (UTC)
What some may call web-style is indeed a result of (partially just perceived or previous) technical restrictions, a successor to typewriter-style that brought us straight quotes and apostrophes among other ugliness. (Any print text actually makes a lot of compromises compared to handwritten text, e.g. regarding ligatures.) Non-breaking spaces are harder to enter than normal or no spaces; thin spaces (breaking or not) are not only harder to enter, but also are not that well supported (not as bad as few years ago, but still not well enough). The pragmatic approach therefore is no space between a number and a percent sign – some argue the same way for other symbols, like ‘kg’ – or between dots and letters in abbreviations (e.<here>g.).
I think it still is the best approach for Misplaced Pages, being mostly read in web browsers, to omit the space before ‘%’ and ‘°’ (with ‘′’ and ‘″’), but if this was primarily a seldomly edited print product non-breaking thin spaces would probably be preferable. They are both representing units of dimension 1, which of course also applies to ‘rad’ for instance, and they are not made of letters, unlike ‘rad’. That is what makes them special.
This is not at all saying we should embrace technical limitations as “modern style”, because typography is about readability, i.e. aiding the readership. We’re in a transitional phase where recent common tools slowly approach the utility of traditional professional ones, which they already largely replaced for different reasons. A major obstacle to general improvement are standardised keyboard layouts which seem hard to change. Previously it also was encoding and font availability, but at least the former has mostly gone with the advent of UTF-8 (the reasonable mapping to Unicode), the latter varies.
Concerning old-style numerals, they’re not only still common in typefaces they fit in, but are seeing a comeback currently due to Open Type features (or similar smart font techniques). They always belonged to the font and had not to be done manually by the typesetter. I’m actually reading WP with Georgia as my default font which uses them (1234567890) and they are in general preferable in prose for their alignment wiht lowercase letters, but not in tables or code where a common or fixed width is recommended. Christoph Päper 23:05, 7 August 2007 (UTC)
(repeating myself: Even better - the wikipedia now supports automatic non-breakable spaces in front of the %. (Bug 10334) -- just give it a try! Thanks for your comment and Greetings, -- Schusch 22:53, 8 August 2007 (UTC))
Wikimedia did that for the French, if you read the bug report closely. We have no need for it. Chris the speller 02:28, 9 August 2007 (UTC)

Precision

All that I can find about precision deals with conversions and geographical coordinates. But what about precision in measuring? The specific case is Interstate 79 and its talk page. The West Virginia Department of Transportation gives a length of 160.52 miles. But, when using trip planning software, the length comes out as 159.75. JA10 wants to use the trip planning software to calculate intermediate distances to exits, but I don't think it's valid, because a primary source that measures its own roadways disagrees with a third-party source that has numerous places in the process that errors can enter. --NE2 04:29, 28 July 2007 (UTC)

So can you state your question in precise terms; unsure what we should be deliberating on—are you proposing that a new point be incuded in MOSNUM? Tony 04:32, 28 July 2007 (UTC) — Preceding unsigned comment added by Tony1 (talk • contribs)
I'm asking for advice. --NE2 04:41, 28 July 2007 (UTC)
This seems like a "no original research" issue. As much as your colleague would like to do better, this is primarily an instrument for reporting third-party information. Tony 06:54, 28 July 2007 (UTC)
The thing is that it is third-party information: use the program and tell it to go from the beginning to the interchange. --NE2 07:17, 28 July 2007 (UTC)
Sorry, I meant that WP is primarily an instrument for reporting existing information, rather than new, fresh, original research (i.e., the results of which haven't already been published). Tony 11:27, 28 July 2007 (UTC)
Simple computations are not original research. --NE2 12:05, 28 July 2007 (UTC)
The difference is so insignificant I could run that distance in under a minute. Just approximate. That's what we have to do when we have two "reliable" sources that differ in their calculations. Just average the distance and call it "approx. x.yz". NB: I suspect that the cause of the error is either a) government incompetence, b) bad programming, or c) (most likely, really) that the points of measurement were different, e.g. from the furthest possible point to still be considered "on target" to the opposite furthest point, vs. the exact inverse of that determination. The underlying question is necessarily an approximation anyway, because we are not talking about geometric points, but landmarks. How far is it from my house to the mall? You'll get at least as big a variance as you are seeing in your data if you consider "my house" and "the mall" to be the center points of each, or the property boundaries of each on the inner side of the measurement. — SMcCandlish ‹(-¿-)› 13:50, 28 July 2007 (UTC)

IEEE/IEC binary prefix mess...less messy!

I just rewrote WP:MOSNUM#Binary prefixes, in plain English that is parseable by someone without an EE degree. I don't think I changed any facts or nuances about where things stand right now, or balance (though I note a very challenging HTML comment in there from a GiBi-booster that should probably come out (not only because it's PoV-pushing, but because extended commentary on rationales belongs on talk pages); didn't delete it myself as I was on useability patrol not PoV patrol). If I'm reflexively reverted on this cleanup spree, I urge others to actually look at the changes I made and reintegrate as many of them as possible without a flame/revert war ensuing, especially a) the reduction of utterly pointless geekery and organizational name tossing, and b) the much more consistent language so that we always know precisely what set of units is being discussed in what clause. There were many other clarifications and grammar/wording twiddles as well. I.e., it would be a mistake to revert the lot because someone disagrees with three details of the 50-something-detail overhaul. — SMcCandlish ‹(-¿-)› 13:40, 28 July 2007 (UTC)

Your changes imply (through use of the phrase "IEEE prefixes" and phrases like it) that the IEEE continues to endorse the use of decimal prefixes, which is not especially true. I personally suspect the MOSNUM would be just as well off if that entire first paragraph were excised in favor of a link to binary prefixes (and if the binary prefixes article were heavily revised). Neither of those is likely to happen without stirring up a new, massive fight though; so finding a better phrase than "IEEE prefixes" will have to do. — Aluvus t/c 22:29, 28 July 2007 (UTC)
I'm not sure I'd go that far, but the IEEE thing is a good point. — SMcCandlish ‹(-¿-)› 20:23, 29 July 2007 (UTC)
Done. Changed "IEEE" used as an adjective to "historical". Also, removed the combative HTML comment mentioned above. — SMcCandlish ‹(-¿-)› 20:26, 29 July 2007 (UTC)
The historical binary prefixes should not be called IEEE prefixes. The rewrite reads better but it is factually wrong.
In the 1950s, K was used for 1024 as in 8K words. By the 1970s, kilobyte (KB) and megabyte (MB) were common as binary units. In 1986 the IEEE (and ANSI) codified the computer industry's usage of binary units. In the 1990s several more standards affirmed the usage. The IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, 2000 is the most current one to defined KB, MB, and GB as binary units. This just recognizes the computer industry's common usage.
In the late 1990s various standards organizations defined new units that were codified by the IEC. These new units clarify the difference between decimal and binary but have not been adopted by the vast majority of the computer industry. In 2005 the IEEE recommended using the IEC units but even their publications still use the traditional ones.
Earlier version of this style guide implied that the traditional binary prefixes were haphazardly chosen by conniving marketers and slipshod engineers. That is not the case; the traditional binary prefixes were codified in ANSI/IEEE standards. The standards originations have attempted to convince the industry to use the new IEC prefixes but the industry does not see a benefit and has stayed with the previous standards. Use of IEEE and IEC standards is strictly voluntary.
A rewrite should explain the benefits of the IEC prefixes and note that the historical prefixes were also codified in standards. The IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, 2000 is a good example of the previous standards. If the Eight Edition uses the IEC prefixes, the industry may still follow the units that were defined in the Seventh Edition. -- SWTPC6800 00:06, 1 August 2007 (UTC)
Huh? This has already been fixed. A big long history lesson isn't helpful here. Please read the current version and explain briefly if you find anything still wrong about it. — SMcCandlish ‹(-¿-)› 00:27, 1 August 2007 (UTC)
You removed the fact that the historical prefixes were an official standard. For the past two years this style guideline has portrayed the choice between common usage and the "standard" prefixes. The choice is between the previous standard and a new standard. The guideline should say the industry is still following the previous standard. -- SWTPC6800 02:13, 1 August 2007 (UTC)
The opening sentence is totally wrong. The historical prefixes are not the current IEEE prefixes. That is what the conflict is about. The style guideline from before your current edits is factually correct. Your current wording is not. You should have proposed your changes on the talk page before making a radical change. If the facts are wrong a revert to the previous stable version is in order. -- SWTPC6800 02:28, 1 August 2007 (UTC)
I have corrected the opening and reduced the waffle. The guideline is not the place to have a history lesson, that should be for articles instead. I've also clarified the section about consensus because it was misleading and added confusion by mentioning both types of prefix in the same sentence. Fnagaton 08:20, 1 August 2007 (UTC)
Right. Per Fnagaton just above, I "should" have done just what I did, and you "should" have simply fixed any unintentional errors in it, instead of going on an on about it, SWTPC6800. WP:BOLD (and the related WP:BRD exists for a reason.  :-) — SMcCandlish ‹(-¿-)› 17:56, 1 August 2007 (UTC)
The binary prefix section was mired in a ferocious dispute for 6 months and had just become stable. I was concerned that the technical errors would start another dispute. I only voiced my concerns on the talk page and not by editing the main page. I asked Fnagaton to look at the binary prefix section which he did. I think the edits that you and Fnagaton made have improved the section. -- SWTPC6800 01:04, 2 August 2007 (UTC)
Understood. I believe that the bulk of that swampy argument was due directly to the amount of geeky, off-topic detail and namedropping in it. :-) — SMcCandlish ‹(-¿-)› 04:01, 2 August 2007 (UTC)
Thank you SWTPC6800. :) I also agree with SMcCandlish about the namedropping in the guideline, it was a bit much. Fnagaton 09:05, 2 August 2007 (UTC)

Decision time for this draft

Dear colleagues

I'm keen to implement the draft soon at MOS and here: it's taken a lot of my time and I have to get on with real life. What we have is an immense improvement on the existing situation. However, there are a few remaining issues. I'm calling for prompt, definitive feedback on these.

Dots after imperial-unit abbreviations (in. and ft. versus in and ft)

  • OPTION 1 (current): say nothing
  • OPTION 2 (as currently in the new draft): no dots after any unit abbreviation:
    • "The bridge, only 10 metres (33 ft) across, stretched for 8 kilometres (5 mi) across the bay"
  • OPTION 3: (SMcCandlish's proposal): dots optional after imperial unit abbreviations, but not after metrics:
    • "The bridge, only 10 metres (33 ft) across, stretched for 8 kilometres (5 mi) across the bay"
  • OPTION 4: (Tony-modified version of Option 3): no dots after metric abbreviations; dots after imperial units are acceptable, but dot-free is recommended


You're the only one, SMcC. Let's list this as an issue that needs to be resolved SOON. I'm keen to implement the text in MOSNUM alone. Tony 01:22, 30 July 2007 (UTC)
Huh? I count 2 before me saying (4) would be okay. It's still out-!voted, so I'll let it lie this round. — SMcCandlish ‹(-¿-)› 06:34, 30 July 2007 (UTC)

Abbreviated units in main text?

This has just been raised by SMcCandlish and has previously been supported by him and Tony, unsuccessfully.

  • OPTION 1 (as now and in the new draft): spell out main values throughout, abbreviate converted values throughout
  • OPTION 2 (change in policy): allow (not force) abbreviated main values on subsequent appearances:
    • "The bridge, only 10 metres (33 ft) across, stretched for 8 kilometres (5 mi) across the bay", and subsequently "The other bridge, only 5 m (17 ft) across, stretched for 10 km (6 mi) across the bay"
(1) It's nothing to do with laziness; it's from the reader's point of view. (2) No one is suggesting compulsion—just permission if (as always implied) there's consensus among contributors to an article, and usage is consistent within it. Can you revisit your comment in this respect? Tony 06:43, 29 July 2007 (UTC)
  • (2), intolerant of current, which is irrational: There isn't anything special about content "X" just because it is parentheses; for example "(Jones ain't gonna play in the 2007 championship)" is unacceptable inside parens as outside; parens do not magically transform the nature of the content inside them in any way. Furthermore, we have longstand principles elsewhere that the first occurrence of an acronym, or another form of shorthand, is given in full. And other concerns. The point is, the current text is conflicting with standard WP practice. — SMcCandlish ‹(-¿-)› 20:35, 29 July 2007 (UTC)
  • I have no problem with allowing the writing out of units with their first usage; it is consistent with the rest of our style guides and probably proper usage, if we think about it. However, should not the example for Option 2 be:
  • "The bridge, only 10 metres (33 feet) across, stretched for 8 kilometres (5 miles) across the bay", and subsequently "The other bridge, only 5 m (17 ft) across, stretched for 10 km (6 mi) across the bay"
Askari Mark (Talk) 21:08, 29 July 2007 (UTC)
Good point; I wasn't going to go there this round, but I've been thinking that all along. — SMcCandlish ‹(-¿-)› 06:34, 30 July 2007 (UTC)
Well, no: I'm assuming that current policy is that it's 8 kilometres (5 mi) across, then 16 kilometres (10 mi) across: all the same. The proposal is to allow the main units to be abbreviated as well, but only after first occurrence: 8 kilometres (5 mi) across, then 16 km (10 mi) across. I didn't want to fiddle with the requirement for converted units; I suspect that the rationale for abbreviating in every instance, including the first, is that the foregoing main unit and value and the parentheses are sufficient highlighting for even the dumbest reader to realise that a converted mi means mile, or km means kilometre. It's only an option where contributors agree, and is intended for articles in which a unit is repeated again and again. See what you think when it's pasted into MOSNUM. Tony 01:19, 30 July 2007 (UTC)

Proscribe superscript squared etc?

Just been raised by SMcCandlish. ft/m versus sq ft

  • OPTION 1 (as now and in the new daft): say nothing
  • OPTION 2 (change in policy): discourage superscript ("are normally written as")
  • OPTION 3 (change in policy): ban it ("are spelled out ..."


  • Prefer Option 2 Tony 02:47, 29 July 2007 (UTC)
  • (2), the superscripts are often hard to read. I was just editing Mauna Loa to prep for main page, and there is a superscript I can't read. SandyGeorgia (Talk) 02:56, 29 July 2007 (UTC)
    • That particular page uses an unusual character that is a superscript 3 (³), rather than making a superscript out of an ordinary 3 (), which is a fairly unusual way to go about it. The special character (which is available under "Symbols" in the Edit Tools box below the page-editting box) does has the advantage of not altering line spacings, and copy-pastes better than an ordinary superscript. I'm curious, do you mean you cannot read it because it is too small, or because it does not display correctly for you? As for the question of superscripts, I would like a little better definition of what is being discussed. All superscripts on units, or only on non-metric ones? — Aluvus t/c 03:38, 29 July 2007 (UTC)
  • I would say (as I did above) that only the imperial measurements should not use the superscripts because they are rarely encountered with the superscripts (outside of wiki, anyway). Whereas, metric/SI units are commonly encountered with the superscripts. In fact, NIST and SI handbook prescribe that only the superscript way of showing these abbreviations (actually they're symbols) be used. Therefore, I think that it is best to contrast between systems, e.g. Template:Sq mi to km2, Template:Ft2 to m2, 10 cu yd (7.6 m²). I also think that because these are the most commonly seen ways of abbreviating imperial and metric units, it would be easier to gain consensus for this proposal than trying to outlaw superscripts for SI units. —MJCdetroit 04:05, 29 July 2007 (UTC)
So the proposal, then, is that superscripts not be permitted for imperial-unit abbreviations ("use sq"), but must be used for metrics (km²). MJCdetroit's entry here brings up another point: I'm continually irritated by the use of the <sup> function, which yields a huge superscript, making the lineage lumpy. MJC has used ... yes, it's there down the bottom, a little "2" superscript in the edit tools. Why not make this compulsory for 2 and 3 (not m but m²)? Tony 06:36, 29 July 2007 (UTC)
  • SandyGeorgia notes above that the superscripted characters are too small to read on her screen, and I find that when I load IE (with basically all default settings, at a reasonable text size) they are in fact quite hard to read. Restricting editors to use only that way of writing superscripts would probably be an inconvenience to the majority of readers. — Aluvus t/c 06:58, 29 July 2007 (UTC)
Well, IE gets in the way of a lot of improvements. I hate it. It wouldn't be a Bill Gates invention, would it? Tony 07:00, 29 July 2007 (UTC) PS Does it get in the way of the "frac" template suggested below? Tony 07:01, 29 July 2007 (UTC)
I would agree: always use superscripts for metric units but never use them for imperial/US customary units. Jɪmp 08:07, 29 July 2007 (UTC)
OK, I'm updating the draft accordingly. Will avoid using the nice edit tool, and won't even mention it: surprised it's been included down there, frankly, if IE screws it up. Tony 08:41, 29 July 2007 (UTC)
Is this OK? "Squared and cubed metric-unit abbreviations are always expressed with a superscript number (5 km, 2 cm); squared imperial-unit abbreviations are rendered with sq, and cubed with cubed (15 sq mi, 3 cubed ft)." AND MORE: Should the subsection be called just "Unit symbols" rather than the current "Unit symbols and abbreviations"? MCJdetroit says that the abbreviations are symbols. And thus, instead of "squared imperial-unit abbreviations, we have "squared imperial symbols"? No, it's needed for imperial units. Tony 08:55, 29 July 2007 (UTC) AND another point: there is a huge difference between 15 square miles and 15 miles squared (= 15 mi × 15 mi). Should this distinction be mentioned? Tony 08:57, 29 July 2007 (UTC)
It would be cubic feet not cubed feet & do keep in mind that the imperial system & the US customary one are different. Jɪmp 09:39, 29 July 2007 (UTC)
Thanks on the "cubitc"—done. Confused as to which term to use for the system; and as to whether sq ft and ft squared are an issue. 3 metres squared is 9 square metres, yes? And when not abbreviated, I'm presuming that these words are all fully spelled out. Tony 09:49, 29 July 2007 (UTC)
What's the abbreviation for 3 metres squared? Is it (3 m)? Epbr123 10:41, 29 July 2007 (UTC)
I don't think "feet squared" (and similar expressions) are all that common in WP, but I could be wrong. They aren't hugely common in English, to begin with. 3 meters squared would be 9 square meters, or 9 m. The exponent indicates the unit is squared, not the unit and the quantity. — Aluvus t/c 10:46, 29 July 2007 (UTC)
So it's very important that we tell people that 3 m means 3 square metres and not 9 square metres, yes? And that if they want to, they can write out 3 metres squared, which does mean 9 square metres. I'll insert this unless there's a problem.
That one seems kind of silly to me. Who on earth is going to think that 3 m means 9 square meters?!? — SMcCandlish ‹(-¿-)› 06:34, 30 July 2007 (UTC)
Thanks, CR7, will change (later: Detroit beat me to it.).
SMcC, you think it's worth cluttering the "Common mathematical symbols" subsection with a statement not to spell out squared? I'd have thought anyone writing such sumbols would know that. Tony 01:03, 30 July 2007 (UTC)
<shrug> I'm not feeling that strongly on it either way. I was addressing more the possibility of if we "banned" sup for square footage/meterage, not to ban it for math usage. Moot point, I think. — SMcCandlish ‹(-¿-)› 06:34, 30 July 2007 (UTC)


How to write two and three quarters as numerals?

We say nothing on this: you people tell me! Tony 02:47, 29 July 2007 (UTC)

  • All things being equal, 2.75. Is there some particular case where fractions, improper fractions, or mixed fractions are preferable for some reason? Unless that is extremely common, I would say it is enough to say "avoid fractions unless you have a good reason" and be done with it. — Aluvus t/c 03:47, 29 July 2007 (UTC)
  • There has been some related discussion on this issue. The problem really only comes up with English measures and the sense of the earlier discussion was to discourage decimalizing them because of the problem of “false precision”. Certainly 2.75 in isn’t a problem since it’s a nice, neat conversion, but when you get to 2-3/8 it gets dicier. Askari Mark (Talk) 05:12, 29 July 2007 (UTC)
There is a ¾ in the edit box along with a ½, a ⅓, a ⅔, a ¼, a ⅛, a ⅜, a ⅝ and a ⅞. So 2¾ can be entered directly. Otherwise, use {{frac}}. {{frac|2|3|4}} gives 2+3⁄4. Jɪmp 06:23, 29 July 2007 (UTC)
I'm very happy to insist on the use of the edit box for fractions, and to ban the hyphen (2-3/4 yuck). How about it? Tony 06:40, 29 July 2007 (UTC)
I'm with you there. Would anyone actually write 2-3/4? Ban it: it looks too much like "two minus three-quarters". I rather see 2&3/4 or 2+3/4 but none of that nonsense is necessary: we've got the tool box & the frac template. Note that the tool box is no good for denominators five, six, seven or anything greater than eight. Jɪmp 07:56, 29 July 2007 (UTC)
Does IE screw up the frac template too? I don't have IE 6 to test it with. Tony 09:02, 29 July 2007 (UTC)
  • Exact opposite opinion as Jimp; many do in fact write "2-3/4"; this has been standard style since long before I was born. The unicode fraction are an accessibility problem for many (I don't just mean screen reader; they are so small that many cannot read them even with their glasses!), and the {{frac}} template is a hideous abomination. — SMcCandlish ‹(-¿-)› 20:41, 29 July 2007 (UTC)
The Unicode fonts are indeed a problem on IE6. I can only make out clearly the denominators ‘2’ & ‘4’ among Jimp’s examples, and the numerator ‘5’ could be a ‘3’ for all I can tell. The {{frac}} template seriously messes up line spacing. The hyphen – with no spaces – has long been the standard way to write mixed fractions, in my experience. Askari Mark (Talk) 20:55, 29 July 2007 (UTC)
{{frac}} and {{fraction}} are horrid. SandyGeorgia (Talk) 21:00, 29 July 2007 (UTC)
Then why don't we just remain silent on this, as now? Tony 00:54, 30 July 2007 (UTC)

Batting averages

Numbers between minus one and plus one require a leading zero (0.02, not .02). Except batting averages, which are never written with a leading zero. http://mlb.mlb.com/mlb/stats/index.jsp SandyGeorgia (Talk) 03:00, 29 July 2007 (UTC)

I've added to the point thus: "*Numbers between minus one and plus one require a leading zero (0.02, not .02); an exception is made for performance averages in sports where a leading zero is not commonly used." Tony
Do we know of any such sports other than cricket? Jɪmp 07:58, 29 July 2007 (UTC)
It is referring to baseball, not cricket. There would be very few batting averages in cricket between 0 and 1. Gizza 08:02, 29 July 2007 (UTC)
I was trying not to sound US-centric, and expecting that baseball would not be the only sport to which this applied. Not sure it has to be specified, since no one else will use the 'concession'. Tony 09:01, 29 July 2007 (UTC)
Calibers, when expressed in inches (as they often are), are also an exception here. It's always "caliber .22" and never "caliber 0.22". But that falls under WP:UCN so I don't know if it needs to be mentioned in this guideline. -- Jao 11:03, 29 July 2007 (UTC)
Quite so; thank you. So check my addition of "an exception is .... and common usage such as .22 caliber rifle"?
I'd mention it here anyway; it may be convered with regard to article titles at WP:UCN, but people will be confused if they coming looking in the number style guide and don't find mention of it. Also, I like the "and common usage" phrasing; oviates the need to keep adding exceptional examples every time someone thinks of a plausible one. — SMcCandlish ‹(-¿-)› 21:02, 29 July 2007 (UTC)
They are used broadly in sports, so don't limit to baseball (though a batting average example would be familiar to most American and Canadian readers); for example my VNEA eight-ball average this season is .73 (as of last Tue.)  :-) — SMcCandlish ‹(-¿-)› 06:27, 30 July 2007 (UTC)
Whatever VNEA is ... The current draft wording embraces this. Please sign. Tony 00:49, 30 July 2007 (UTC)
The point kind of was that it doesn't matter what VNEA is; the zeroless format is used in sporting broadly and generally (oh, and it is the Valley National Eightball Association, which is doubly misnamed since it has branches in Europe and Australia now, and they also have nine-ball leagues. Go figure.) — SMcCandlish ‹(-¿-)› 06:27, 30 July 2007 (UTC)

How to write "four by four"

At Super Nintendo Entertainment System, we find: Sprites can be 8x8, 16x16, 32x32, or 64x64 pixels, ... is that correct and is it covered? SandyGeorgia (Talk) 15:34, 29 July 2007 (UTC)

It's incorrect: well, it will be in 10 hours' time. Common mathematical symbols must be spaced on both sides, and the letter ex must not be used for a multiplication sign, which is rendered by clicking on the symbol in the edit tools below the edit box. Tony 15:36, 29 July 2007 (UTC)

Also, this (it uses {{fraction}} which is really ugly on my screen): RAM is accessed at 3.072 MHz, with accesses multiplexed between the SPC700 (1⁄3) and the DSP (2⁄3). SandyGeorgia (Talk) 15:38, 29 July 2007 (UTC)

Strongly disagree; "4x4", etc. do not mean "four times four" they mean "four-by-four"; in purely mathematical situations, the phrases are ultimately equivalent, arithmetically, but they are not identical. The former are dimensions (among other things, as in automotive usage), not mathematical formulas or formula fragments. If I smack you in da head wit' a big chunk o' wood, that headache generator was a "two-by-four" (if you were lucky; could have been a 4x6!), a "2x4", which is not spaced and uses a normal "x", not a "two-times-four", which is "2 × 4", spaced and with a different symbol. Don't confuse math and phrase. — SMcCandlish ‹(-¿-)› 20:49, 29 July 2007 (UTC)
PS: Concur that the {{fraction}} this is ugly, and should be deprecated.
PPS: Where do you see the mathematical "×" in the stuff below the edit box? It should be there, under "Symbols", but I don't see it. No true-minus, division sign, etc., either. — SMcCandlish ‹(-¿-)› 20:52, 29 July 2007 (UTC)
When in edit mode, there's a line beginning with Insert right below the line that says Do not copy text from other websites without a GFDL-compatible license. It will be deleted. SandyGeorgia (Talk) 20:58, 29 July 2007 (UTC)
Oh, duh. I was looking below that in the "Symbols" section. I don't see the point of having two lines of click-to-insert symbols, myself. Honestly, I really don't use that thing down there at all; I have a menu bar popup widget that lets me insert characters into whatever field I'm in in whatever app, and I've used it for years, so I've never felt a need to learn a new and less functional way of doing that on WP. — SMcCandlish ‹(-¿-)› 06:27, 30 July 2007 (UTC)
I hope IE 6 doesn't screw up the multiplication sign as well. Find it, SMcC? They're just after the big black word "Insert". Now, I understand the distinction you've made, which is going to be hard for many readers to understand. But I agree that the distinction is worth making if there's consensus to adopt it. Three issues: (1) is it established usage, and does any other authority suggest its use?, and (2) it's a very bunched-up look, (3) does 4 × 4 look bad, and will it be misunderstood in context? I ask the first question because, although WP is quite capable of making its own style decisions, I'd be less comfortable if we were "going it alone". Tony 00:41, 30 July 2007 (UTC)
The problem with #1 is I don't think any authority outside of science style guides even recognizes any difference between "x" and "×", so the question is kind of moot. You won't find that even in a truly huge and comprehensive modern general-usage style guide like Chicago, I'd wager, but I don't have it on my lap right now to be sure. Re: #2/#3 which seem to be the same question/issue, when referring to "four-by-four", the use of the mult. symbol as in "4 × 4" is simply "incorrect. Writing "4x4" for "four-by-four" actually helps disambiguate, for actual measurements, "4 in x 4 in", the space would be required, so maybe just say "use spaces", period. My main thrust with this was that x="by" and ×="times" are not the same thing and shouldn't be confused. It's another one of those things, though, that if the MOS recommends something wrong, people will just ignore it, and MOSwarriors will use AWB to "fix" it, and people who know it is wrong will revert that, etc., etc., and people will fight over something trivial. — SMcCandlish ‹(-¿-)› 06:27, 30 July 2007 (UTC)
Does this do it? "*For a multiplication sign, use ×, which is input by clicking on it in the insert box beneath the edit window or by keying in &times; do not use the letter ex. (However, the letter ex is accepted as a substitute for by in such terms as 4x4)." Tony 09:20, 30 July 2007 (UTC)
Yes, but for typo, "&times;". Fixing it would probably require a new sentence at "Do not use the letter ex". — SMcCandlish ‹(-¿-)› 09:44, 30 July 2007 (UTC)
Thanks; I think it's right now. Tony 13:52, 30 July 2007 (UTC)

So, is the Nintendo example (above) correct, or does it need spaces? SandyGeorgia (Talk) 14:01, 30 July 2007 (UTC)

Good question; we don't agree on this as individuals. The unspaced 4x4 is now the sole example for dimensional expressions in the text of MOSNUM (I'm unhappy about the visual appearance and the use of ex rather than the mulitiplicadtion sign, but we've all been compromising in this overhaul.) It does say only that it's "acceptable", after talking of the real multiplication sign (which below is billed as spaced). So I'd say it's not wrong to write 64 × 64 pixels under the new wording, and I'd do that myself. But the bunched-up ex now acceptable; therefore, there's no grounds for complaint at the FAC page. Others please correct me if I'm wrong. Tony 14:50, 30 July 2007 (UTC)
Works for me; I would write "64x64 pixels", Yankee style, but write in a math context "64–×–64=..." If I encounted "64–×–64 pixels", I wouldn't wig out. Might change it, but I wouldn't grumble in the process (and yes I would if I found "64x64=..." in a math context.)

Dates of birth and death

The section "Dates of birth and death" should , I feel, make some reference to the four templates:

indicating the correct way to use them, and mentioning that they are required, if birth dates are to be included in hCards produced by infoboxes. Andy Mabbett | Talk to Andy Mabbett 17:10, 29 July 2007 (UTC)

Forgive my questioning attitude, please: convince me that these templates are useful in the normal scheme of things. Isn't it easier to simply type the date? Will other editors know how to use them. (Mostly not, I think.) And do the templates work with IE 6? And since the subsection goes to pains to say that, at the start of an article, the dates of birth and death shouldn't be tangled up with location (and presumably age at death, too, it confuses things, doesn't it? Tony 00:47, 30 July 2007 (UTC)
They are actually getting a lot of buy-in in infoboxes. It's not such much whether J.Q. Editor will use them, but people who care about microformats will, with AWB. And some of us (my hand is raising) do it manually when editing anyway. I don't think MOS should tell people they have to use these things, by any means. That's what gnomes and bots are for. — SMcCandlish ‹(-¿-)› 06:27, 30 July 2007 (UTC)


New text implemented at MOSNUM, not yet at MOS-central

Please raise unresolved issues here. I know that SMcCandlish will want to present further arguments for dots after imperial units. Question marks over some of the templates (dates of birth and death). I haven't yet inserted anything about four by four, etc (dimensions vs. mathematical operations). Tony 01:57, 30 July 2007 (UTC)

Dots are a minor detail that we can beat each other up about at a later date. I wouldn't let that hold back implement this draft. —MJCdetroit 02:04, 30 July 2007 (UTC)
Thanks, MJC. Yes indeed; I'm hoping that when everyone reads through it in full structure, they'll pick up or think of other issues (hopefully minor ones!). Tony 02:30, 30 July 2007 (UTC)
<shrug> I'll live. I don't really have any "further arguments" to present. Seems pretty clear to me. There isn't any real-world evidence in support of no-dotting non-metric/scientific units, except in scientific writing. Not sure what else to say. The MOSNUM can continue treating WP like it was Nature, but I think what will happen is that most editors who normally use periods after such units will continue to do so, and that the recommendation in MOSNUM will not really have much effect, other than leading to editwarring, as MOS sticklers revert it, and others re-revert it because to them it is obviously grammatically incorrect, and so on, round and round. Seen it enough times already... — SMcCandlish ‹(-¿-)› 06:27, 30 July 2007 (UTC)
PS: The main reason to permit (not require) period after non-met./sci. units is simply strife and timewaste reduction in my book, for the same reasons that we permit US or UK (or whatever) English in articles, and so on. The headaches and hard feelings are not worth the over-standardization. (This is my reply to an earlier thread up there pushing for standardization about all else, as well). Anyway, I don't have anything further to say on the draft at issue. I'm happy with some of it, not with other parts, and so it goes. — SMcCandlish ‹(-¿-)› 06:45, 30 July 2007 (UTC)
Well, the article Inch gives in as the abbreviation right at the top. What more could you want? — Preceding unsigned comment added by Tony1 (talk • contribs) 14:53, July 30, 2007 (UTC)
Speaking of our very own articles, you might want to visit Circa, which mentions encyclopedia articles, but does not follow the style of this guideline. Chris the speller 15:03, 30 July 2007 (UTC)
I suppose there's no chance of resolving whatever was in dispute about the Geographical coordinates section, is there? Pity to have that fierce dispute sign hanging over our shining new version ... Tony 05:26, 30 July 2007 (UTC)
Just an odd thought, could the word tonne for the metric ton be encouraged over the term metric ton please. There are some articles out there that have just got ton written. CR7 11:55, 30 July 2007 (UTC)
Sorry, but I think that part of the MOSNUM is well written. The word tonne is completely foreign to most American readers. Most (even the well educated ones) could think that tonne is just the British way of spelling ton. The MOSNUM is written in such a way to let those readers know that tonne is actually a metric ton; the term most a Americans would be familiar with. Besides, the MOSNUM already covers not using the word ton by itself anyway. —MJCdetroit 12:43, 30 July 2007 (UTC)

Doublecheck on comma in date format

Does anyone know where/how to doublecheck on this:

  • either ], ] (US editors) or ] ] (others) will be rendered as either February 17, 1958 or 17 February 1958, according to a registered user's set preferences.

Once I came across a discussion that the comma is never needed, because the auto formatting inserts it automatically. I don't know where to doublecheck that, but it fits with my experience, whether logged in or out (user preferences). SandyGeorgia (Talk) 15:19, 30 July 2007 (UTC)

See the discussion above, "Omitting commas in Wiki-formatted dates", and there's an even earlier discussion in Archive D4. Chris the speller 15:47, 30 July 2007 (UTC)
Thanks; this talk page got a bit out of hand :-) So, the software does insert the commas, but tempest in a teapot. SandyGeorgia (Talk) 16:05, 30 July 2007 (UTC)
I think the long and short of it is that yes, the software inserts the comma if you don't, but that we're not about to burden people with a ban on its manual insertion. All for the good, too. Tony 13:56, 31 July 2007 (UTC)

"To"/"versus" hyphen, and "through"/"up to" en-dash

This stuff's been changing so much I'm not sure if this is even in there in any form. I think it should be specified that when a dash is a stand-in for "to" or "versus", as in "McDougal lost to Yamamoto, 3-12", it is a hyphen (or what some call a "hypen-minus" for some reason), in contradistinction to the en-dash used in "fl. 205–162 BCE", where is stands for "through" or "up to". En-dashes should emphatically not be used for sports statistics and the like, or the result will be misleading in many cases, implying a range rather than a 1:1 (or 1-1, but not 1–1 :-) comparison. — SMcCandlish ‹(-¿-)› 18:42, 30 July 2007 (UTC)

See WP:DASH. — Aluvus t/c 23:35, 30 July 2007 (UTC)
No, it emphatically should be an en dash; ranges are only one of that symbol's functions. Representing relationships and opposition are others. Sports scores should be presented with them, and not hyphens: 3–12, not the bunched-up 3-12. Tony 00:04, 31 July 2007 (UTC)
I'll concede on this one, but only because Chicago 15th ed. recommends it. I strenuously disagree with the logic of it, but I'm outgunned on this one. I do have to note, however, that I've been editing sports articles here for a year and a half, and have never even once seen sports scores use an en-dash in this way. Whether Chicago and MOSDASH advise it or not, it is not common usage, and getting people to use it is likely to prove essentially impossible. I'll try to remember to do it myself, but I doubt this will have any effect. — SMcCandlish ‹(-¿-)› 23:26, 31 July 2007 (UTC)
Endashes in sports scores has been the norm at WP:FAC for many months, and there's been no problem with acceptance. SandyGeorgia (Talk) 23:55, 31 July 2007 (UTC)
Yup, I've encountered absolutely no resistance when insisting on it. People soon see that it's much more readable. Tony 00:48, 1 August 2007 (UTC)
I didn't meany anyone would fight it, they simply won't do it. I've already seen ample evidence of that, if WP:MOSDASH has actually been around a while and saying what it says. — SMcCandlish ‹(-¿-)› 09:59, 2 August 2007 (UTC)

outdated.js — script for reformatting date links

While we wait for a server-side update that makes date auto-formatting and date linking independent, I've put together a script that will separate date links from the rest and allow you to specify your own style for them. With this script, "January 1, 2008" and "100 AD" will render as black text in articles, or any other format you can apply with CSS.

See User talk:Outriggr/outdated.js for instructions. –Outriggr § 08:00, 31 July 2007 (UTC)

Great idea! Thanks. Maybe you could make it understand non-North American date order too. Stephen Turner (Talk) 09:15, 31 July 2007 (UTC)
Thanks. It will—the dates mentioned above are simply examples. –Outriggr § 09:20, 31 July 2007 (UTC)
Outriggr, if this works, you're a genius! Tony 13:54, 31 July 2007 (UTC) PS Heartily recommended functionality, but I won't take it on yet, coz I need to identify overlinking in FACs and FAR/Cs and insist on remedial action. Tony 14:06, 31 July 2007 (UTC)
That's the dilemma, but someone's got to use the thing! With the script, you can reduce the visual impact of date links while still seeing that there are date links, if you so choose. Tony, do you know of any other talk pages related to the date linking problem where I could mention this tool? –Outriggr § 22:48, 31 July 2007 (UTC)
Yes, FAC, FAR, and some of the major, active Wikiprojects (don't know how to identify them, but they're there). Bill it as a new functionality for those who are sick of blue spattering all over WP's text from overlinking. I suppose you've seen my change-colour solution (Alvurus's, acutally). Tony 00:47, 1 August 2007 (UTC)

Too many large changes?

I'm concerned that there are too many large changes going on at the moment without sufficient discussion. The page may have needed some tidying up, but this is more like a complete rewrite. I can't keep up with everything that's been done, and I'm convinced that changes in meaning have been introduced without being properly discussed here first. Does anyone else share my concern, or am I just not putting in enough work to follow it? Stephen Turner (Talk) 09:13, 31 July 2007 (UTC)

I've posted a reply on Stephen's talk page. Tony 11:41, 31 July 2007 (UTC)

Your reply is not at Stephen's talk page yet, but no, I don't share the concerns. SandyGeorgia (Talk) 11:47, 31 July 2007 (UTC)
OK, I guess it's just me then. I wasn't paying close enough attention. Apologies. Stephen Turner (Talk) 09:51, 1 August 2007 (UTC)
My confusion was because I thought you were talking about putting a summary of this page on a central MoS page, rather than changing this one. So I skipped over the discussion. Stephen Turner (Talk) 10:26, 1 August 2007 (UTC)
It would have been good to have had your input at the time. Pity. Any serious issues? Tony 10:33, 1 August 2007 (UTC)
Well, one. I strongly disagree with the removal of the requirement to link full dates. I know you've disagreed with that requirement for some time, but I'm pretty sure there's a consensus for retaining it. I certainly don't think you should change it based on a conversation between about three people. Stephen Turner (Talk) 14:09, 1 August 2007 (UTC)
I don't think many of the 88 people who signed the plea for the autoformatting and linking functions to be separated, or at least for a parallel system of autoformatting without linking (thus retro-compatible), would agree with mandatory full-date linking. Since our well-organised and (IMV) highly reasonable request hit a brick wall, I changed my tune on autoformatting. If the system isn't going to be fixed, I can't support a guideline that forces people to use it. When the technical glitch is fixed, I'll willingly support a "mandatory" clause.
It's even worse that the autoformatting doesn't allow you to render date ranges without typing out (and reading) the full date twice. That is crude and, frankly, ridiculous (October 11–18, 1977 won't work). It won't allow slashes (the night of January 15/16). While the latter is a minor issue, the former is quite an irritant.
And after all that, the autoformatting works only for the vanishingly small proportion of readers who are registered and logged in and who have chosen a date preference. For all others, the original is displayed, so out there in the real world of WP use, almost everyone has learnt to accept the variety of standard date formattings—much as they accept the major varieties of spelling.
In the light of these shortcomings, forcing people to use it seems like a navel-gazing exercise, since it works for so few and gives WPian editors a false view of what everyone sees.
The new wording doesn't mean WPians won't use the autoformatting—indeed most people will continue to do so.
By analogy, technical issues have caused other functionalities to be downgraded in status. We've recently thrown out a proposal to recommend (although not compell) the use of a new template that produces a non-breaking thin space. It would have been just excellent, but silly IE 6 ruined everything by not rendering it properly. This shortcoming sank it completely. Tony 14:32, 1 August 2007 (UTC)
I share some of Stephen's concern about a lot of changes, at least to the point of requesting a summary of changes; an experienced editor who cares enough to try to follow these guidelines should not be required to grind through all of this to see if habits need to be changed. Can you put such a summary on this talk page, and consider mentioning it on the project page? I hate to request more work of you after such a Herculean task, but you can always decline. Chris the speller 14:54, 1 August 2007 (UTC)
I also agree with Stephen about linking full dates; I don't see a consensus to abandon, either. I don't know where you obtained the statistics to characterize the group who uses date formatting as "vanishingly small", but they at least care how the dates appear, and we should accommodate them. We have had visits from people telling us not to use suspenders (commas) because we have belts, and now you say belts are not required. Pants will fall down. Chris the speller 15:09, 1 August 2007 (UTC)
Tony, I understand your point of view, and I respect it; I just don't think it's the view of the majority. And I disagree with your belief that that " many of the 88 people who signed the plea for the autoformatting and linking functions to be separated would agree with mandatory full-date linking". I think you're letting your own point of view influence you here. Speaking for myself, I've been an advocate of separating them for a long time, but I believe it's important to continue linking full dates until they're separated. And my belief is that that's the view of the overwhelming majority of people who've thought about the issue.
I feel that you've sneaked in a major change to the MoS which affects the majority of pages, under the cover of a large copy edit. No, I take that back — "sneaked in" could imply a deliberate deception, which I'm not implying. I don't doubt your good intentions. I just think that the discussion got lost in the large amount of discussion about making a summary for MoS central; only involved three other people, two of whom disagreed with your proposal; only lasted five days; and doesn't reflect a consensus.
Stephen Turner (Talk) 17:06, 1 August 2007 (UTC)
User:Chris the speller notes in another thread (but in reference to this topic): "Stephen Turner and I question the removal of the requirement to link full dates. As of a few days ago, the guideline was clear that all full dates should be linked. My suggestion is to link them all until there is consensus to drop the requirement." I concur with this. I don't feel strongly that it should be done this way or that way, and do feel strongly that the developers need to fix the underlying problem, but in the interim, I think things on this score should stay as they were. — SMcCandlish ‹(-¿-)› 04:05, 2 August 2007 (UTC)
  • The current wording opens thus:

The WikiMedia software formats full dates, and days and months, according to the date preferences chosen by registered users. This function is activated by inserting double square-brackets, as for linking;...

Would you tolerate this opening, until the functionality is fixed?

Full dates, and days and months, are normally autoformatted, by inserting double square-brackets, as for linking. This instructs the WikiMedia software to format the item according to the date preferences chosen by registered users.

Tony 06:19, 2 August 2007 (UTC)

PS List of all of the substantive changes? Phew, you're right, I'm nearly burnt out from the process. I'll try.

I've only just noticed this discussion, but I also want to place on record that I strongly object to dropping mandatory linking of full dates. -- Arwel (talk) 06:36, 2 August 2007 (UTC)
Just to clarify myself, by "full dates" I mean "day+month+year" and "day+month", but not "month+year". -- Arwel (talk) 11:40, 2 August 2007 (UTC)
The revision works for me. Again, in the interim; this really, really needs to get fixed on the developer side so that the problem goes away, as it is a very noxious problem. — SMcCandlish ‹(-¿-)› 06:38, 2 August 2007 (UTC)

Viewing this from a European stand point makes the argument for only linking full dates look silly, if the policy is mandatory linking of full day/month/year dates but not partial (day/month) dates then that could lead to European users who have bothered to set their date preferences being confronted with articles where all the linked full dates are in their chosen format but partials are in the format they were entered eg On the 13 October 1980 the debate started and it finished on October 15. I gather from other discussions on this page that there is/was a request for alterations so that the Wiki software would format but not link dates. Until that happens the MoS for dates should either state that all dates, both partial and full, should be linked or it should state that the same line for English/American English in articles should be followed i.e British date format for British articles and American format for American. As an average user I just want a clear indication about what the accepted format is. - X201 09:33, 2 August 2007 (UTC)

That's pretty good reasoning, too. — SMcCandlish ‹(-¿-)› 09:59, 2 August 2007 (UTC)
As I understand it, day/month/year and day/month items are at issue for autoformatting, and months/years, months alone, and years alone are the "partial" dates that can't be autoformatted. Isn't the proposed revision clear on this point? The only issue now is acceptance of the word "normally" in place of "almost always"; I am strongly against forcing people to use a dysfunctional system. "Normally" seems encouragement enough. Tony 09:57, 2 August 2007 (UTC)
Sorry, X201, I wasn't clear. Anything with a day and month must be linked. The page was explicit about this until recently.
Tony, I'm sorry to have to say this, but I feel you're still imposing your own views on this page, and I'm very close to reverting it. I just can't decide whether to revert the section on linking, or the whole section on dates. You have made some improvements, but a lot of good stuff has been over-abbreviated or omitted too, for example the explanation about why ISO 8601 dates shouldn't be used in prose.
Stephen Turner (Talk) 10:12, 2 August 2007 (UTC)
You revert and I'll be seriously at war with you: there will be no peace on this page. I've put a HUGE amount of work into this—more than I wanted to—and I won't sit idly by while you crassly undo it without yourself gaining consensus. You absented yourself from continual debate here about the overhaul—for whatever reason—so don't think you can just walk back in after the event and revert. As far as I'm concerned, there was consensus for the changes. I flagged, I planned publicly, I managed compromises, and most of all, I spent many hours fixing up what was, frankly, shitty wording and bad formatting. So pay the courtesy of discussing or butt out completely. I'm angry to be faced with this after all of my work. And take your mock "sorry" and put it where it belongs. Tony 11:16, 2 August 2007 (UTC)
I would not support any wholesale revert; this was a long and consensual process. If there's a problem about date linking, pls discuss that separately from the rest of the work (although it's been well covered in the past). SandyGeorgia (Talk) 13:55, 2 August 2007 (UTC)
I too would be against any wholesale revert of the recent changes. —MJCdetroit 17:07, 2 August 2007 (UTC)

I apologise, I was out of order in threatening to revert. Stephen Turner (Talk) 20:01, 3 August 2007 (UTC)

No problem; I apologise for what was now appears to have been an overly strong reply. I'm keen to debate your concerns, and if I have time, will post a list of substantive changes in the recent overhaul to assist that process. Tony 23:48, 3 August 2007 (UTC)

Autolinking dates?

Concerning WP:MOSDATE#Autoformatting and linking - is the "2007-07-31" format no longer valid anymore? How come it doesn't include an example of that, while the rest of the MOS uses that format as examples of correct format? Hong Qi Gong (Talk - Contribs) 14:37, 31 July 2007 (UTC)

The "Dates" section says: "ISO 8601 dates (1976-05-12) are uncommon in English prose, and are generally not used in Misplaced Pages. However, they may be useful in long lists and tables for conciseness and ease of comparison." The thrust of this point is unchanged in the overhauled policy. Tony 14:50, 31 July 2007 (UTC)

Implementing the MoS

I'm adding this in hope it might start a productive discussion -- or at least not be ignored, as much of what I write seems to be -- but after the MoS reworked & all who have contributed are happy with it, how does it get implemented?

If we allow the usual kinds of people to make these changes -- with or without bot help -- there will be an uproar. If you forgot the AD/CE wars, then have a peek at the battling over "Fair use images" war -- letting the MoS become a "license to edit without fear & win conflicts" will only serve to embitter many long-term productive Wikipedians & drive many other productive ones away. Yet if it is not somehow implemented, is there any purpose to all of this work?

There must be some kind of soft, gradual process to implement this MoS that doesn't unnecessarily ruffle feathers. Education is one method: writing a regular column to the Signpost would be one way to do this. Engaging people is another: perhaps asking on Talk pages or at WikiProjects if the proposed changes could be made. This runs the risk that the more people who know about this work, the more likely much of what has been hammered out will go back to the furnace & a new consensus made.

But some form of a gradual, soft strategy should be adopted, otherwise I suspect that there will be months of even more hostility than usual on Misplaced Pages. -- llywrch 21:58, 31 July 2007 (UTC)

Very good advice. Those who participate in implementation are, of course, skilled diplomats, yes? Bad idea to continue with mass changes against significant local resistance. Bring it up here or at MOS-central. Tony 00:44, 1 August 2007 (UTC)

Old Style and New Style dates

See Talk:Old Style and New Style dates#Two different interpretations --Philip Baird Shearer 23:59, 31 July 2007 (UTC)

Now implemented at MOS-central

I've copied over much of Sections 1–6. In the process, I realised that the stupidly named "Long short big small" at MOS-central belongs within the summary, and here (see vagueness), as does some of MOS-central's "Scientific style". All that remains of the old Scientific Style section at central is a short section on chemistry at the bottom of central.

I'm now adding an invisible note at the top of MOSNUM about the need to coordinate changes with MOS. In the next week, I'll change as many surface details as possible in the examples here, so that readers are forced to process the same guidelines anew; that will be good for both their understanding and the separate identity of this submanual. Tony 01:46, 1 August 2007 (UTC)

Autoformatting and linking

The Autoformatting and linking section states how linking works and what it is for, it states what you should not link but it doesn't explicitly state that you should either link every date on a page or that you should only link certain dates. I've read through the discussion archives and they have left me non-the-wiser with some users saying link everything and some complaining about over linking. What is the MoS standpoint on linking dates? - X201 18:19, 1 August 2007 (UTC)

We're talking about full dates, then? And by "link", I presume you mean "autoformat"? The wording indicates that you don't have to use the autoformatting facitility: people aren't forced to do this. Most people probably still will. Do you have a specific suggestion for additional text? Tony 00:59, 2 August 2007 (UTC)
In the above section "Too many large changes?", Stephen Turner and I question the removal of the requirement to link full dates. As of a few days ago, the guideline was clear that all full dates should be linked. My suggestion is to link them all until there is consensus to drop the requirement. Chris the speller 02:41, 2 August 2007 (UTC)

I've replied in the "Too many large changes?" thread, but to clear a few things up...
I meant autoformating.
I was referring to both full (day+month+year) dates as well as partial (day+month) dates but I failed to explain that my main concern was where partial and full dates appear in the same sentence, with full dates linked/autoformatted but partial dates not linked/formatted. - X201 09:41, 2 August 2007 (UTC)

BC/AD and BCE/CE, again

The following long standing material was removed from the article. This perspective was based on several long and acrimonious discussions and at least one RFA, and many editors have strong opinions on the use of both systems. I have already noted some recent confusion on changing dating systems on some articles. With this permanently removed, I would expect the issue to return with a vengeance. Opinions on replacing this in the policy or clarifying the policy in another manner? Best wishes. WBardwin 19:46, 1 August 2007 (UTC)

When either of two styles are acceptable it is inappropriate for a Misplaced Pages editor to change from one style to another unless there is some substantial reason for the change. For example, with respect to British spelling as opposed to American spelling it would be acceptable to change from American spelling to British spelling if the article concerned a British subject. Revert warring over optional styles is unacceptable; if the article is colour rather than color, it would be wrong to switch simply to change styles as both are acceptable. See also Misplaced Pages:Requests for arbitration/Jguk.

I believe the default position is that if there is any conflict over usage of a term, spelling, etc it automatically goes back to the earliest non-stub. Unless there is a good reason, such as use of American English in a British article. John Smith's 21:44, 1 August 2007 (UTC)

This was not included because it applies generically in WP articles where a valid choice is first made. MOS-central says this. Tony 00:57, 2 August 2007 (UTC)

And we should say so as often as convenient. Stopping the stupid date wars is more important than removing redundancies; the assumption that every editor will have absorbed the entire MOS is unrealistic.. I will restore if no one else has done so.

Rewording of the Era section

Does anyone have a problem with rewording the section on BC/AD and BCE/CE to this:

    • Either CE and BCE or AD and BC can be used—spaced, undotted and upper-case—to specify the Gregorian era. Be consistent within the article. AD appears before or after a year (AD 1066, 1066 AD); the other abbreviations appear after (1066 CE, 3700 BCE, 3700 BC). The absence of such an abbreviation indicates the default, CE or AD.
    • When either of the two styles are acceptable it is inappropriate for a Misplaced Pages editor to change from one style to another unless there is some substantial reason for the change.
    • Year ranges, like all ranges, are separated by an en dash (do not use a hyphen or slash: 2005–08, not 2005-08 or 2005/08). A closing CE/AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year (1881–1986). The full closing year is acceptable, but abbreviating it to a single digit (1881–6) or three digits (1881–886) is not. A closing BCE or BC year is given in full (2590–2550 BCE). While one era signifier at the end of a date range still requires an unspaced en dash (12–5 BC), a spaced en dash is required when a signifier is used after the opening and closing years (5 BC – 29 AD).
    • A slash may be used to indicate regular defined yearly periods that do not coincide with calendar years (the financial year 1993/4).
    • Abbreviations indicating long periods of time ago—such as BP (before present), Ma and mya (million years ago), and Ga (billion years ago)—are spelled out on first occurrence.
    • To indicate about, c. and ca. are preferred to circa or a question mark, and are spaced (c. 1291).
  • Decades contain no apostrophe (the 1980s, not the 1980’s); the two-digit form is used only where the century is clear (the ’80s or the 80s).
  • Centuries and milliennia. There was no year 0. Thus, the first century AD/CE was 1–100 AD/CE, the 17th century AD/CE was 1601–1700 AD/CE, and the second millienium AD/CE was 1001–2000; the first century BC/BCE was 100–1 BC/BCE; the 17th century BC/BCE was 1700–1601 BC/BCE, and the second millennium BC/BCE was 2000–1001 BC/BCE. Note: Writers should choose one system or the other, but not both. It is shown in this explanation with both to express that the MOS does not favor one method over the other.

I took out the superfluous part about avoiding the Christian associations of BC/AD. All terms are linked within the section if an editor needs to know more about what the terms mean. I included the inappropriate to change from one style to the other...part because without that clause, an editor with a personal agenda WILL go through and start changing the era style in as many articles as they can. I changed the Centuries and milliennia part to include both methods; instead of just CE/BCE. I also included a note to pick one method or the other, but not both.

As it is written now, it tends to encourage writers to use CE/BCE and does not prohibit the changing from one method to another for personal/unclear reasons. Therefore, I tried to reword it as to be as neutral as possible and making it clear that the MOSNUM/MOS does not favor one over the other. —MJCdetroit 16:59, 3 August 2007 (UTC)

Sorry that I was unaware and did not participate in earlier discussions. I am particularly missing two things from the live version. As noted above, a statement discouraging changing between era notations should be restored. Also, I miss the part that says Normally you should use plain numbers for years in the Anno Domini/Common Era, but when events span the start of the Anno Domini/Common Era, use AD or CE for the date at the end of the range.-Andrew c  18:08, 3 August 2007 (UTC)

I fully agree. We have had enough disruption from idiots "correcting" dating styles in both directions. It's a good thing, by the way, that this text does not attempt to prescribe the placement of AD with respect to the number. The encouragement to be clear about the transition from BCE/BC to AD/CE is also needed. Septentrionalis PMAnderson 08:20, 10 August 2007 (UTC)


Problems: (1) "When either of the two styles are acceptable it is inappropriate for a Misplaced Pages editor to change from one style to another unless there is some substantial reason for the change." As I said above, MOS clearly states in its first lead paragraph the very same thing, so that specific options do not need to cover this principle. To do so casts doubt on the global application of the principle. It should be removed.

(2) The same applies to this: "Note: Writers should choose one system or the other, but not both. It is shown in this explanation with both to express that the MOS does not favor one method over the other." And let's not tell them to "note" this: they should note everything in MOS. The last sentence needs to be reworded. Similarly, someone has inserted "Remember that in ..." in MOS-central's mirror points concerning "Centuries and milliennia" (did I misspell it?). Tony 09:34, 10 August 2007 (UTC)

I respectfully disagree with your opinion of (1). The third paragraph of theMOS eludes to the American/British styles of English and leaves a "grey area" for things as this. There are more passionate feelings involved with BC/AD vs BCE/CE than whether something is spelled program or programme. Therefore, it doesn't hurt to reiterate the fact that it is inappropriate to change the established style of an article for personal reasons. I placed that sentence in there because I've seen the mass changing of styles before; even when there was a similar sentence in the MOSNUM. This extra sentence makes it clear that's it is not ok to change the eras because you want to and it gives editors more "ammunition" to revert such PPOV edits.
As for (2), it looks as if it was rewritten since I introduced it anyway and I don't have any objections to its present revision. —MJCdetroit 17:33, 10 August 2007 (UTC)
Please tell me what is unclear about this statement, glaring out from the lead of MOS:
"In June 2005, the Arbitration Committee ruled that, when either of two styles is acceptable, it is inappropriate for an editor to change an article from one style to another unless there is a substantial reason to do so ... Edit warring over optional styles is unacceptable". What more could one want? The variant spellings are given explicitly as an example of this principle, not, as you're assuming, as the only application of it. It weakens the global force of this statement to restate it locally. No one should have concern that they lack the backing of MOS to revert wholesale changes from one option to another without substantive reason. There are so many options permitted by MOS/NUM; are we to restate this basic principle for all? Should we, then, restate the "doesn't apply to direct quotations" for every single point, too?

I draw your attention to another statement in the lead; this embodies two further principles that should not be restated for specific points: "An overriding principle is that style and formatting should be applied consistently throughout an article, unless there is a good reason to do otherwise, except in direct quotations, where the original text is generally preserved." Tony 05:25, 11 August 2007 (UTC)

I disagree. Adding an additional statement in the MOSNUM regarding eras doesn't weaken the global statement. It reiterates it with a specific example of something inappropriate that is done very often regardless of what the MOS says. This only strengthens the global statement and makes it very clear that changing era styles is inappropriate. Remember, not everyone who edits Misplaced Pages has read the MOS and its submanuals top to bottom; I know I haven't. Therefore, if we make it easier for the beginning editor to find an answer to the very common problem of switching eras, then I think we've improved the MOS/MOSNUM. —MJCdetroit 16:14, 11 August 2007 (UTC)
As above. Septentrionalis PMAnderson 23:16, 12 August 2007 (UTC)

Under Longer periods, the sentence "Either CE and BCE or AD and BC can be used—spaced, undotted and upper-case—to specify the Gregorian era." should not state Gregorian because Julian dates are preferred before 15 October 1582. "Gregorian" should be deleted, leaving "to specify the era." — Joe Kress 05:02, 17 August 2007 (UTC)

MYA or mya

MOSNUM says MYA, but the article is mya (unit); I've always thought it was mya. Which is it? SandyGeorgia (Talk) 23:14, 1 August 2007 (UTC)

To further complicate the question, Talk:mya (unit) says the international standard is Ma, not mya or MYA. SandyGeorgia (Talk) 23:31, 1 August 2007 (UTC)
(edit conflict) I have always seen Ma (which stands for Mega annum, with the "ago" being implicit) in academic literature, but find mya to be more intuitive. --JayHenry 23:37, 1 August 2007 (UTC)
I always use "Ma" (or ka or Ga) when writing for the technical literature. To the extent it does appear, I think "mya" (lowercase) is more common than uppercase. Dragons flight 00:04, 2 August 2007 (UTC)
And the Ma article says mya is deprecated. SandyGeorgia (Talk) 00:28, 2 August 2007 (UTC)
A quick search of google found this page from the University of California. Which isn't diffinitive, but does use mya. --Rocksanddirt 00:40, 2 August 2007 (UTC)
It sounds like MYA is out. But there's a proposed merge of mya (unit) to Ma. Does anyone know how to track down SI on this? SandyGeorgia (Talk) 00:43, 2 August 2007 (UTC)
The official SI standard of time is, of course, the second. Dragons flight 00:50, 2 August 2007 (UTC)
I much prefer Ma if it still matters at this point. Mya is kind of amateurish (trying not to sound snobby and failing). Sheep81 01:46, 2 August 2007 (UTC)
However, when it is used, I think I always see "mya" uncapitalized. Sheep81 01:49, 2 August 2007 (UTC)

This says Ma is not SI but is in common use. Like DragonsFlight, to me Ma and Ga or ka is totally standard in geologic usage and is increasingly common in more popular literature, when the phrase "million years ago" is not written out. I have felt (with no hard data) that "mya" was something of a Wikipedian construct. Cheers Geologyguy 01:49, 2 August 2007 (UTC)

I first picked up mya and "million years ago" from a book back in my youth (1980s). What it has going for it is the meaning is easier to grasp when written out. In practical terms, I've never committed to one abbreviation on Misplaced Pages because of this very issue, preferring just to write out "million years ago". J. Spencer 02:18, 2 August 2007 (UTC)

Do any of you, then, have an opinion about what our Manual of Style should say? Do we say no MYA? Either Ma or mya? Or do we stay silent? SandyGeorgia (Talk) 02:33, 2 August 2007 (UTC)

Well, we should at least eliminate MYA from the MOS, since there is no consensus whatsoever for that one. My issue with Ma or Ga is that the casual reader may miss what it means, whereas mya can be guessed at rather easily. Never thought I'd participate in this type of discussion! OrangeMarlin 04:07, 2 August 2007 (UTC)
If the academic style is going towards MA that's fine with me (though i like mya). --Rocksanddirt 04:43, 2 August 2007 (UTC)
But it's Ma, not MA, right? SandyGeorgia (Talk) 04:59, 2 August 2007 (UTC)
FWIW, I think I would count as a "casual reader", and I've never heard of any of these terms, nor do I think I could pick up the meaning of any of them purely from context. "Mya" is easier to grasp after someone tells you what it means, but I can't imagine just guessing its meaning. — Aluvus t/c 05:07, 2 August 2007 (UTC)


  • The current wording is:

In articles on prehistoric topics, BP (before present) and MYA (million years ago) are spelled out on first occurrence.

As long as a standard form of abbreviation is used consistently in an article, and it is spelled out on first occurrence, I can't see the problem in being more inclusive. The current guideline, in any case, doesn't say that BP and MYA are the only forms permissable. So why not this simple addition of three words (which I've italicised here for clarity)?

In articles on prehistoric topics, abbreviations such as mya (million years ago), Ma (Mega annum) and BP (before present) and are spelled out on first occurrence.

Tony 05:27, 2 August 2007 (UTC)

It implies that MYA is the common usage, when in fact mya and Ma are, while MYA doesn't appear endorsed by anyone (see OrangeMarlin's current FAC on Cretaceous–Tertiary extinction event). SandyGeorgia (Talk) 05:33, 2 August 2007 (UTC)
Oops, I didn't read the foregoing discussion properly. How's that? Do we need BP? Both existing abbreviations, BTW, were unchanged in the recent overhaul: I didn't know any better. Tony 05:56, 2 August 2007 (UTC)
I'd just never abbreviated it nor seen any abbreviations before using WP, where I saw mya alot and now Ma. I don't care for any of them too much as I feel none is well known to the common reader, but my opinion is not too strong on this one. cheers, Casliber (talk · contribs) 07:24, 2 August 2007 (UTC)
I'm going to stick with mya in the article, since I think it's mostly clear. I'd be concerned if I had to spell it out in this article, since it's used so many times, it might make it look pretty trite. I still think MOSNUM needs a revision to remove MYA and move to either Ma or mya. OrangeMarlin 08:49, 2 August 2007 (UTC)
I'm a geosciences student and I only ever see Ma, and occasionally Ga in my course texts (and one of them was published this year.) saying that why not just write it as "X million years ago" as that is the least ambiguous way of all... no need for any interpretation then! --Vertilly 08:57, 2 August 2007 (UTC)
Heavily concur. These abbreviations are too specialist for use in a general-public encyclopedia, unless explained in context, e.g. "2.5 million years ago (Ma) ... Then, 1.4 Ma, ..." Abbreviation okay if both explained and linked to earlier. — SMcCandlish ‹(-¿-)› 09:09, 2 August 2007 (UTC)
MYA is not used in geological literature, it is always Ma, as it is Ga and Ka (Mega, Giga and Kilo Annum). In the Dutch wikipedia Ka, Ma, and Ga are used and explained in a lemma of their own, and if appropriate in the text where this is used. So I wonder why MYA has been here anyway. I assume that MYA is used by people who are ignorant of the geological literature. --Tom Meijer 09:23, 2 August 2007 (UTC)
Not entirely a geological issue at all. Biology/zoology and anthropology use some form of this as well; I'd be curious what the current lit uses (I'm used to stuff from over a decade ago in my university days, so I can't really say for sure). — SMcCandlish ‹(-¿-)› 09:59, 2 August 2007 (UTC)
  • (Outdent) So the proposed revision looks to satisfy these concerns. I've added Ga and Ma and removed BP; all are now linked here. Shall I implement it?

In articles on prehistoric topics, abbreviations such as Ma and mya (million years ago) and Ga (billion years ago) are spelled out on first occurrence.

Tony 09:31, 2 August 2007 (UTC)

  • What about ka/Ka? I've seen it spelled both ways in this discussion, but can't think of a reason that it would be "ka, Ma, Ga", given "KB, MB, GB", not "kB, MB, GB". Otherwise, no issues from my corner. Take that back, one issue: I'd change "Ga (billion years ago)" to "Ga (giga-annum or billion years ago)" — SMcCandlish ‹(-¿-)› 09:59, 2 August 2007 (UTC)
BP is absolutely standard for time periods less than a few thousand years, as comes up in paleoclimatology and carbon dating, and shouldn't be removed from the list of acceptable options. Dragons flight 10:04, 2 August 2007 (UTC)
OK, but does this have to be a comprehensive list? Why not just mention one or two? It does, after all, say "such as"; it's proscribing nothing, is it? I was probably unwise to add more to my proposal. This whole point is about "prehistoric topics", which doesn't include less than a few thousand years ago. Now it's becoming chaotic. Tony 11:19, 2 August 2007 (UTC)

I think the proposed revision covers all examples, while removing the incorrect MYA. SandyGeorgia (Talk) 12:43, 2 August 2007 (UTC)

I miss apparently the point of this entire discussion. Ga, Ma, Ka, BP and AD, all are standard abbreviations and normally used in literature (MYA is not), as far as I know not only geological (although, maybe not surprising, I consider geology as the most important user here). Shouldn't these conceptions be explained in an encyclopedia anyway? BP is before 1950 AD (so not before now) and is the common used expression in Carbon Fourteen dates, even if this is 30.000 year (I agree, this hardly makes sense, but it is an international standard), AD is after year zero from the Christian calender, etc. I don't understand why you shouldn't use these abbreviations that are already standard. As far as I am aware, the standard is also Ma, Ga, and Ka, and not MA, ma, mA, etc. There maybe not a proper 'reason' for this, it is just the standard (and that is apparently the reason)--Tom Meijer 12:46, 2 August 2007 (UTC)
I agree entirely with Tom Meijer. Ga, Ma, Ka are both widely used in geology and archaeology and are the official units/designations as approved by relevant professional societies, eg IUGS. Babakathy 12:25, 3 August 2007 (UTC)
You're a bit late. Tony 13:06, 3 August 2007 (UTC)

Changes and strategy

I've been bold and changed the autoformatting phrase from the current wording, which clearly had little support, to the wording that appears above (which did receive support from SMcCandlish, and is, is suspect, much closer to what Stephen et al. are comfortable with). Can we please continue discussion of this here, rather than threaten reverts? I'm keen that we keep the current text and work to address concerns one-by-one. Stephen has raised a problem with the ISO point. Let's gain consensus here. I've implemented the suggested changes to the "prehistoric abbreviations" point.

Another issue is that Crissov is unhappy with the amount of detail that has been transferred across to MOS. (See talk page there.) There's no reason that we can't negotiate the removal of a few points from that text, while retaining them here. I have a few in mind. Tony 00:47, 3 August 2007 (UTC)

List of substantive changes to MOSNUM in recent overhaul

  • I've done a fairly quick job, and hope that it's accurate; please edit it you find omissions or commissions.
  • Please add notes or comments in square brackets to the list, as I have in a few places, and sign. Important issues probably need to be raised below on this page.
  • It's categorized broadly by section, in terms of "Removed", "Added" and "Changed", but the distinctions between them are blurred in places.
  • I discovered that two mini-sections on numbers had been omitted (Natural and Non-base-10 numbers). I've copy-edited them and added here (but not at MOS).
  • "Magnitude prefixes" and the still-messy "Geographical coordinates" need to be filled in in the list.

Tony 01:05, 4 August 2007 (UTC)

Very nice; it helps me, especially as a sanity check, is bound to help editors who have not been following closely for the last few weeks. Check my slight tweak. Thanks, Tony! Chris the speller 01:50, 4 August 2007 (UTC)
I restored two items to MOSNUM (but not MOS) that were excised but which I believe are crucial (deprecate "17th Century", and "1700s" is a decade not a century in WP terminology). — SMcCandlish ‹(-¿-)› 19:32, 5 August 2007 (UTC)
I'm most concerned that many people take the 1700s to mean a century. Why is WP different? Tony 23:58, 14 August 2007 (UTC)

"The '60s" change proposed

I propose changing this:

  • Decades contain no apostrophe (the 1980s, not the 1980’s); the two-digit form is used only where the century is clear (the ’80s or the 80s).

to this:

  • Decades contain no apostrophe (the 1980s, not the 1980’s), and are not abbreviated except in contexts where the abbreviated form, with a leading apostrophe, is itself a culturally significant term, as in '60s counterculture and the Roaring '20s, but not '60s music or neo-conservatism of the '80s.
  • Decades contain no apostrophe (the 1980s, not the 1980’s), and are not abbreviated except in contexts where the abbreviated form is itself a culturally significant term, as in 60s counterculture and the Roaring 20s, but not 60s music or neo-conservatism of the 80s. (A leading apostrophe, as in '60s, is superflous, as it would be in 'phone, and can interfere with quotation and bold/italic formatting.)
‹(-¿-)› 01:34, 6 August 2007 (UTC)]

The reasoning I hope is obviously, but to spell it out anyway: Abbreviation like the latter two examples is simply sloppy and unencyclopedic. Also, there is no reason to permit leaving off the leading apostrophe in the rare cases that '60s is appropriate; "60s" is an age range, not a date range. — SMcCandlish ‹(-¿-)› 19:25, 5 August 2007 (UTC)

Do you use a leading apostrophe for 'phone, still? Or 'plane? It's a particular problem when it starts a quote, too. The whole idea is that if the context is clear, it's very recognisable (preferably after a decade has already been spelled out in full. I hate the look of the leading apostrophe; again, it's not about sloppiness or laziness, but a smooth read for the public. I'm away until Saturday. Tony 00:58, 6 August 2007 (UTC)
You've convinced me completely, actually. Revising proposal accordingly. — SMcCandlish ‹(-¿-)› 01:34, 6 August 2007 (UTC)
Actually, the examples obscure proper usage. They should preferably not express the decades as numbers, but rather as spelled-out words: the Sixties counterculture or the Roaring Twenties. Likewise, the counter-examples of 'phone and 'plane are obtuse; these are proper nouns in of themselves. The reason for the leading apostrophe in abbreviated decade identities is that they are missing information, as are other forms of contraction – and contractions properly require an apostrophe. Yes, a rendering of ’60s is ugly (especially in Arial font), but so is 60s (which normally is used to refer to an age range, not a calendar decade). Since Misplaced Pages eschews the use of contractions (outside of quotations), we should discourage such use with decades as well – or punctuate them accordingly. Askari Mark (Talk) 22:46, 10 August 2007 (UTC)

I agree with the proposal, as amended. Using two digits for years, instead of four, cost the world many billions of dollars (that's 1,000,000,000s) in software corrections as the '90s wound down and we approached 2000. Oops, I mean the 90s. Oops, oops, I mean the 1990s. ;-) Chris the speller 01:03, 11 August 2007 (UTC)

Fix misuse of italic emphasis

This document is misusing italics rather massively. Italics are a form of emphasis. Example text should be given in "quotes", rather than emphasized. Aside from simply being weird style, it makes it very difficult to actually emphasize anything without going bold (which is generally too heavy-handed), since everything italicized for emphasis just looks like more example text. — SMcCandlish ‹(-¿-)› 19:28, 5 August 2007 (UTC)

See "Words as words" in MOS. If you want to change it, propose at MOS talk. The only way I could see of interpreting that rule was to italicise nominal groups (nouns and noun phrases), but to treat larger chunks as quotes. I pleaded for advice at MOS talk several times, to no avail. Needs to be addressed globally, among all MOSs. Tony 01:01, 6 August 2007 (UTC)
Done. — SMcCandlish ‹(-¿-)› 01:47, 6 August 2007 (UTC)

Proposed clarification regarding comma usage in American dates

The article does not make clear that, in the American month-day-year usage, the year is set off with commas. One comma between the day and year, and one comma after the year (unless some other puncutation follows the year).

See Chicago Manual of Style, Section 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. In the day-month-year system—sometimes awkward in regular text, though useful in material that requires many full dates—no commas are needed. Where month and year only are given, or a specific day (such as a holiday) with a year, neither system uses a comma."

This problem contributes to the widespread misunderstanding that a phrase such as "September 11, 2001 attacks" is appropriate. (The Misplaced Pages article on 9/11 is incorrectly punctuated in accord with that misunderstanding; it should be "September 11, 2001, attacks.) Similar mispunctuations are ubiquitous on Misplaced Pages.

Let's start the process of fixing that by correcting this Manual of Style first. Thanks! Lowell33 16:25, 10 August 2007 (UTC)

Thought I would add some examples of the correct punctuation of September 11, 2001, for illustration:
The 9/11 Commission Report, Preface at xv: "September 11, 2001, was a day of unprecedented shock and suffering in the history of the United States"; New York Times, June 24, 2006, A3: "majorities in Egypt, Indonesia, Jordan and Turkey . . . said, for example, that they did not believe that Arabs had carried out the Sept. 11, 2001, attacks in the United States"; New York Times, June 19, 2006, A11: "The United States said a small cell of Al Qaeda, made up of foreigners, had set up shop in Mogadishu after the Sept. 11, 2001, attacks and were being protected by court leaders"; New York Times, April 30, 2006, 44: "Mr. Deutch also began to require special approval for the use of unsavory characters as agency informants -- a policy suspended after the Sept. 11, 2001, attacks, when officers argued that only terrorists would know of plans for the next attack."
Lowell33 21:54, 10 August 2007 (UTC)
Having heard no objection, I added the proposed clarification. Lowell33 21:33, 13 August 2007 (UTC)
I removed the change, as no other editors have agreed to it. In many cases, silence implies consent, but silence in WP is not necessarily consensus. This style seems a bit stiff to me, but that's not my main objection. As dates without a comma after the year "are ubiquitous on Misplaced Pages", as you say, I am not anxious to open the floodgates. The Chicago Manual of Style may call for a comma, but that doesn't make Misplaced Pages's style wrong, so it doesn't need a "process of fixing", as WP can set its own style. I didn't respond earlier because I didn't want to lead the opposition; it seems like that's all I get to do lately, as just about every other day brings a proposal to turn Misplaced Pages on its head. Nothing personal, but let's not charge ahead on this until we hear from some other editors. Chris the speller 01:01, 14 August 2007 (UTC)
Maybe I could have explained the rationale better. It's not just because the Chicago Manual says so; it's because the year in the American day-month-year format is a parenthetical element, just like the "Illinois" in "Chicago, Illinois, is a nice town." See also Purdue University Online Style Guide ("July 22, 1959, was a momentous day in his life."). I understand that "WP can set its own style," but it should still follow basic rules of grammar, right?Lowell33 14:51, 14 August 2007 (UTC)
I don't like it. Tony 15:11, 14 August 2007 (UTC)
No offense, Tony, but that's because you've gotten so used to seeing it the wrong way that the correct way doesn't look right any more. I know it's a very common mistake, but it's a mistake nonetheless. See also the University of Wisconsin School of Law Style Guide ("The year should be set off by commas when a complete date is given: He always said that February 8, 1990, was the most important day of his life"); another guide ("Classes begin Monday, Sept. 2, 2003, at the high school. "); Blue Book Guide to Punctuation, Rule 5a ("Use a comma to separate the day of the month from the year and after the year. Example: Kathleen met her husband on December 5, 2003, in Mill Valley, California."); University of Texas Style Guide ("When a phrase is used with a month, date and year, set both the date and year off with commas."); University of Minnesota Style Manual ("Use commas around the year when it follows a specific date . . . . The committee agreed on December 12, 1979, as the next meeting date."); Rutgers Editorial Style Guide ("If the day is included, the year is set off by commas before and after. . . . The events of April 18, 1775, have been celebrated in song and story."); Clemson University Editorial Style Guide ("When writing a date, place a comma between the day and the year as well as after the year. January 23, 2003, was cold and snowy."). Lowell33 15:22, 14 August 2007 (UTC)
  • I'm not at all convinced that a comma after the year needs to be enforced, or even mentioned. In Lowell's example, the first post-year comma is required to mark the end of a nested phrase; the second is good because it separates to numerical items. The third and subsequent instances are within direct quotes, so cannot be touched (I wouldn't have used them, especially the last one, which is silly—bump, bump, hiccup, bump). Tony 01:25, 14 August 2007 (UTC)
I'm not at all sure what a "nested phrase" is or how the date in the sentence "September 11, 2001, was a day of unprecedented shock and suffering" is "nested" in any way. It's a noun, and the year is set off by commas because it is parenthetical. Regarding "the second," I think you're referring to my citation. Regarding the "third and subsequent" instances, I don't understand what you mean by "cannot be touched." I was just using them as examples. Finally, I understand that you "wouldn't have used them" and think they're "silly," but do you have any reasons for that?Lowell33 14:51, 14 August 2007 (UTC)
The "direct quotes" are examples used by those sources. Offsetting years (at least in American-style dates) with commas on both sides is correct per every English teacher I have ever had. Omitting the comma after the year is incorrect. Lowell33 is right. — Aluvus t/c 22:40, 14 August 2007 (UTC)
These sources are all American, and Lowell is defining "right" and "wrong" purely in terms of Amercian practice. Everywhere else, commas have been dropped from dates, starting by moving the day away from the year (17 January 1903). It's not an American project, but international. Tony 23:57, 14 August 2007 (UTC)
Tony, I agree completely that no commas are necessary in the day-month-year format, but I don't see why that would lead us to omit a necessary comma from the month-day-year American format. I also hope I didn't offend with talk of "correct" and "incorrect" punctuation. It's nothing personal, but, in my view, it affects Misplaced Pages's credibility to keep repeating this punctuation error everywhere. You won't find it in mainstream encyclopedias, American or not. See Encyclopedia Britannica Online ("The second of two commercial jetliners hijacked by al-Qaeda terrorists and crashed into the World Trade Center in New York City on September 11, 2001, approaches the building, while smoke billows from the crash of the first airliner."); Britannica Concise ("Working in small groups, the hijackers boarded 4 domestic airliners in groups of 5 (a 20th participant was alleged) on Sept. 11, 2001, and took control of the planes soon after takeoff.").Lowell33 14:35, 15 August 2007 (UTC)
For American-style dates, American practice would be rather important to consider. Internationally, dates of that format have both commas. Dates of other formats, such as the day-month-year format seen in Europe and elsewhere, are a separate case. — Aluvus t/c 23:00, 15 August 2007 (UTC)
We willingly accept both American and British English; we should use either as their speakers do; a hybrid style evolved from sterile doctrine is less comprehensible to either division of the common language. Septentrionalis PMAnderson 23:28, 15 August 2007 (UTC)
Thanks for input, Septentrionalis, but I didn't follow. What is the "hybrid style" that you're opposed to?Lowell33 02:23, 16 August 2007 (UTC)
Yes, well most of what Anderson writes is hard to decipher. I did understand his calling me "ignorant" and "illiterate", though. I fear that we're heading towards a nasty war. On the issue at hand, Lowell, can you advise whether it's now mandatory to insert a comma after all autoformatted dates? I don't see how the final comma can be included without its inclusion in other date-forms (that would be very unsatisfactory). Tony 03:19, 16 August 2007 (UTC)
I don't know enough about autoformatting to answer that question. I'm thinking it would be easiest to get a consensus on the correct punctuation first.Lowell33 03:46, 16 August 2007 (UTC)
Well, our loose-cannon friend Anderson went ahead and inserted his own sloppy version of your proposal; I've fixed it, but if it's the case that all autoformatted dates will be displayed with a comma where it's applied to just (original) US ones, I think that's a serious problem. I've checked it below, and this is the case. Of course, if I had my way, we'd ditch the autoformatting for a whole bunch of reasons. But that doesn't seem to be on the cards.

1 January, 1959, stands out as ...

Tony 04:33, 16 August 2007 (UTC)

Rather than wait for consensus, and in spite of the limitations of Wikimedia's formatting, Anderson reinserted the faulty instruction into the manual. I removed it again. Chris the speller 17:39, 16 August 2007 (UTC)
And again. The manual should not be changed until problems are identified and dealt with. Chris the speller 18:01, 16 August 2007 (UTC)
This may not be something that can be autoformatted. Another problem is that, where another punctuation mark follows the year, there should be no comma. For example, a birth/death date should be punctuated as "January 1, 1930--August 2, 1965." Note that there should be no comma after 1930 because there is a dash, and there should be no comma after 1965 because there is a period. Is autoformatting sophisticated enough to recognize situations like that? I doubt it, but like I said I'm not up to speed on autoformatting. Lowell33 14:52, 16 August 2007 (UTC)

At the top of this manual, it states "These guidelines have been developed through the consensus of many editors and should be followed in Misplaced Pages articles. Before making major changes, please raise them on the discussion page to ensure consensus"

In light of that, I would like to point out that it is wrong for one editor to change the guideline before there is consensus. The manual is not the place for any one editor to offer general suggestions, or to insert directions that differ from what a consensus of editors has previously built on that page. Let's determine what a consensus of editors think is the desired style, and then determine how close we should try to come to that style, given the limitations of the Wikimedia software. Until we do both, and figure out exactly where we're going and how to get there, let's not dispense instructions to other editors that could disrupt Misplaced Pages. Chris the speller 18:47, 16 August 2007 (UTC)

Thanks, Chris. I agree that the first step should be to reach a consensus on the "desired style" before figuring out how to implement it. I've explained the substantive issue about as well as I can in my posts above. I couldn't find any reliable source advocating a form like "September 11, 2001 attacks," and that form doesn't make sense grammatically. I reiterate my proposal to clarify in the guidlines that the year in the American day-month-year format should always be followed by a comma (unless it is followed by some other punctuation). Thanks! Lowell33 19:13, 16 August 2007 (UTC)
Let's not have a "desired style". What Chris proposes here is contrary to policy, which has long since decided that we should not prefer any national variety of English. Speaking of consensus, does anyone else support Chris's preference of the Automagic date conversions over the American final comma? Neither Tony nor I do. 19:17, 16 August 2007 (UTC)
I didn't understand your post. Just to clarify, my original post had nothing to do with preferring any "national variety of English" over any other. There is a correct way to punctuate the British day-month-year format and a correct way to punctuate the American month-day-year format. I am talking only about the correct way to punctuate the American month-day-year form, in which the year is parenthetical and should be set off by commas before and after (unless some other punctuation follows the year). Thanks Lowell33 19:51, 16 August 2007 (UTC)
Then I misunderstood yours. I agree that the style actually used in American English is the final comma. Chris removed the following paragraph, which states that as fact, and one of the elements to be considered; I am still unclear whether he disagrees, and if so, on what grounds:
  • American English, the month-day-year style of dating ("The attacks of September 11, 2001, were among the most serious.") treats the year as parenthetical; as in the example, the year is divided off from the rest of the sentence by commas. If the year is immediately followed by other puncutation ("on September 11, 2001; the world..."), the trailing comma is omitted.
I trust this advice, for those editors who prefer to write American, can be restored. Septentrionalis PMAnderson 20:00, 16 August 2007 (UTC)
We're on the same page, then, Anderson. What prompted me to propose this clarification is the fact that many articles contain phrases such as "the attacks of September 11, 2001 were among the most serious," including the title and body of the article on 9/11. This guide should explain why it should be "the attacks of September 11, 2001, were among the most serious," instead. Chris, what do you think? Thanks Lowell33 20:14, 16 August 2007 (UTC)

You seem to be forgetting that the manual of style does not say that "American dates" can be used. All dates containing day, month and year (in any order) should be linked, to allow the date style preference to work. The comma between day and year is regulated by the template translator, to adapt to the preference. The trailing comma is not modified. So if you include the comma, it will also appear in the day-month-year or year-month-day styles, in which it is incorrect. So it seems there is no solution yielding always correct results. Perhaps the choice that makes two out of three styles correct should be preferred. −Woodstone 20:22, 16 August 2007 (UTC)

I would be fine not allowing "American dates" at all on Misplaced Pages, but I don't see that happening. If the American form is going to be used, editors should have a guide to how to use it correctly. As it stands, Misplaced Pages is reinforcing the commonly held misconception that a comma after the year in the month-day-year format is unnecessary. That's not right. Lowell33 20:43, 16 August 2007 (UTC)
You did not get my point. If an editor writes "On ], ], something happened", an editor with British preference setting will see "On 11 September 2001, something happened". Note the comma after the year, which is incorrect. So there is no guideline to make it appear correct in all cases. −Woodstone 21:17, 16 August 2007 (UTC)
Okay, I get it. It seems like we have a consensus (however limited) that, in the American style, a comma is required after the year (unless some other punctuation follows the year). The problem is how to implement that. The first option is for an editor writing in the American style to type the second comma manually (i.e., without changing autoformatting). The problem with that option is that a reader with a British preference setting will see an out of place comma after the year. That won't work. Option two: we change autoformatting to put a second comma after the year in American style dates. The problem with that option is that it will result in double punctuation after the year in many instances (for example, if the date is at the end of a sentence). Is there any way to fix that problem? Lowell33 21:42, 16 August 2007 (UTC)
Thanks, Woodstone, for getting through to everybody (well, all but one, the one who thinks I'm pushing one national variety of English). Although I'm American, I would be happy to settle on whatever would make Misplaced Pages look consistent, and then let viewers specify how they want their dates to appear. I don't have a subscription to Chicago Manual of Style, but I've seen enough websites discussing it, and according to them, Chicago is starting to recommend day-month-year over month-day-year. I can go with that. Americans are not so stupid as to be unable to understand 4 July 1776. But even if every editor who ever read this guideline agreed, we would still need Wikimedia software to properly add commas for those who prefer to see American month-day-year formats. Until they do (and it's not hard, folks, it's not hard at all, whatever they tell you), the imperfect status quo that has gotten us through the last several years will just have to do for another few months or few years. Chris the speller 02:15, 17 August 2007 (UTC)

(Outdent) It appears that there is consensus that: (1) US usage should properly include the final comma, unless the item is immediatly followed by another punctuation mark, including an unspaced en dash (as in full date ranges); and (2) manually inserting the final comma incorrectly renders the formatting of the non-US date preferences, and therefore cannot be done. There seems to be a general feeling that it wouldn't be an easy task to fix the software in this respect, let alone the other three issues that I've listed below. We have three options:

  1. Do nothing, thus continuing the incorrect rendering of US date formatting (we've put up with this for years, without mention) and the other dysfunctions as listed below;
  2. maintain the status quo and mount a renewed push to have the autoformatting system upgraded (will take time and energy, and may not succeed);
  3. change the wording in MOSNUM/MOS to something more explicitly optional than the current "normally" WRT the use of the autoformatting function; and/or
  4. actively discourage editors from using it (the strategy I've been pursuing).

I'm sorry to say that the original good intentions of those who developed the autoformatting are turning out to be poorly served by the system. I'm quite happy to put up with a number of date formats on WP, unlinked, as long as they're consistent within each article. This would be the same situation as for the varieties of spelling that we tolerate. Tony 07:28, 17 August 2007 (UTC)

  • I support the third of these four options, and perhaps the fourth. I approve of the automagic system; but the second option cannot succeed fully unless our display software becomes a flawless English parser (for it must decide whether the comma after "on September 11, 2001," is required by the rest of the sentence or only by 2001). The choice is, fundamentally, between requiring those articles written in American to be ungrammatical, or accepting that the mechanical translation of dates into British usage will sometimes be ungrammatical. We can duck this by not autolinking American dates; but I would prefer to say that those who rely on mechanical translation will sometimes be disappointed. Septentrionalis PMAnderson 15:53, 17 August 2007 (UTC)
  • I support option 2, and oppose options 3 and 4. It is not progress to have non-US readers begin to see month-day-year dates, or to have a comma pop up where it once did not, and where it does not belong. The devil you know is better ... Chris the speller 16:26, 17 August 2007 (UTC)
  • In light of the technical problems, I agree with option 2. I would, however, like to explain in the manual of style why things are the way they are. It should explain that readers with American settings will often see a "hanging" year such as "January 1, 2007" not because it is correct, but because otherwise readers with British settings will see a superfluous comma after the year.Lowell33 16:51, 17 August 2007 (UTC)
    • The technical problem will not be fixed; even if it were routine programming, Bugzilla is slow; and detecting needed commas is one of those things which requires a very complex program, if it can be done at all.
    • Why is it preferable to require all American readers to see a grammar violation so that some British readers do not? If it is true that very few readers set these preferences, why are we catering to them?
    • But Lowell is correct that we should at least explain the problem.Septentrionalis PMAnderson 17:34, 17 August 2007 (UTC)

"summer months" and "winter months"

I'd like to suggest an addition to the section on dates, if it's important enough for the MOS (3042 hits on "summer months").

  • When mentioning the season, summer and winter are used instead of the longer the summer months and the winter months, unless the reference is to something that changes on the first of some month exactly.

—JerryFriedman 03:55, 11 August 2007 (UTC)

This is good advice, but would be inconvenient as a rule. "Summer months" is a reasonable way to explain two-season years, like the Viking calendar or Thucydides; let's not make it impossible. What context are you thinking of? Septentrionalis PMAnderson 04:04, 11 August 2007 (UTC)
There's a point about Northern/Southern Hemispheres, too. Better to give the actual months. Tony 05:14, 11 August 2007 (UTC)
I don't think it needs to be included here specifically. It is just good practice to omit needless words. —Centrx→talk • 05:18, 11 August 2007 (UTC)

PMAnderson, I admit I can't see why "summer months" is better than "summer" for two-season years. Can you direct me to an example?

Tony, sorry to be unclear. This would go after the present paragraph on seasons, which makes the point about hemispheres.

For examples of the context I have in mind, I'll give the first few hits on "summer months":

  • Geography of Chile: 'The area receives considerable rainfall during the summer months in what is commonly known as the "Bolivian winter"'. I'm not going to fix this right now since it needs a little work, such as an explanation that in the Spanish-speaking tropics, the rainy season is called invierno (winter).
  • Lush For Life: "During the summer months, Avalon still finds time to go back to New Orleans, his hometown, where he still owns a condo in the historical French Quarter." and "He currently lives in Tampa, Florida, and during the summer months he resides at his remote villa in Key West…" Fixed.

In all of these I think "summer" is better than naming the months, which would be too precise.

Centrx, I think you may be right. —JerryFriedman 12:52, 11 August 2007 (UTC)

If I have no idea where the place is, "summer" and "winter" have no meaning. Mention the months by name. The word "approximate" appears in my dictionary. It seems a useful word. 81.178.208.1 2007-08-11 20:48 UTC.

I've found it useful myself, but "summer" is a good deal more concise than "approximately June through August" in articles about a place in the northern hemisphere. If you were reading those articles instead of my excerpts, you'd know which hemisphere they referred to. —JerryFriedman 21:10, 11 August 2007 (UTC)
We need to remember WP:CSB (aka Misplaced Pages is not American) - Misplaced Pages reaches a global audience, therefore notions of "summer" and "winter" will not be applicable or appreciated in all regions. Assuming a particular hemisphere viewpoint with season names becomes an WP:NPOV problem. Season name usage should be limited to specific cases e.g. quotes, material about seasons themselves, or where using season names is the lesser of evils. Even in those exceptions, the seasons should be deliberately identified by region for global clarity (e.g. "North American summer", "Australian winter months"). Note the WP:SEASON section of MOS:DATE suggests wording options other than month name ranges. These could be stated as "mid-2005", "early in the year", "second quarter", etc. Dl2000 22:31, 11 August 2007 (UTC)
Uh, there are summers in both the northern and southern hemispheres. Folks who live in the tropics and have only wet and dry season, and read English know generally what summer and winter mean. If you're talking about roads that can only be travelled when frozen solid in the winter in Siberia, its not necesary to relocate Siberia's hemisphere, because this has alredy been done in the introduction. KP Botany 23:17, 11 August 2007 (UTC)
Also, I agree with the MOS here: the seasons can be mentioned when "there is a need to do so", not merely as a lesser evil. For instance, "Apple trees bloom in spring and bear fruit in fall" would cover both hemispheres and be far better than anything that mentions months.
In regard to the examples above, such wording options as those suggested in MOS:DATE are not available. They work when talking about events—I understand the reason not to say, "Trade relations between the U.S. and South Africa worsened in the spring of 19xx"—but not when saying that a town is a summer resort or that a certain weather phenomenon occurs in summer in Chile.
Dl2000, I have no idea why you mentioned that Misplaced Pages is not American. I chose my examples essentially at random, two of the four were not American, and one was in the opposite hemisphere from the United States. I hadn't edited Geography of Chile at the time I mentioned it, but I have now, and I left "summer" with the southern-hemisphere meaning. —JerryFriedman 00:38, 13 August 2007 (UTC)
  • The examples quoted above would be covered by Don't use summer months or winter months when summer or winter conveys the same information. This is good advice, but why do we need it here? This is not a list of clichés; although we could make one (the link is not useful). I would support Eschew surplus words (with a citation to Strunk and White), if anyone feels they need a quote to employ on the stubborn. Septentrionalis PMAnderson 23:34, 12 August 2007 (UTC)
As I said when I proposed this change, it may not be appropriate for the MOS. I proposed it because I wasn't sure.
A real list of clichés to avoid in Misplaced Pages would help a lot, I think—if there could be a consensus. We could start with "A is located in B." (I added "to avoid" because I think some phrases are clichés that shouldn't or can't be avoided. For example, "In regard to", "summer resort", "weather phenomenon", and "essentially at random", all of which I used above.) —JerryFriedman 00:38, 13 August 2007 (UTC)
It's coming: MOS urgently needs to expand its "Usage" section. Tony 23:53, 14 August 2007 (UTC)

Bizarre spaces in the decimal part of numbers?

At Misplaced Pages:Featured_article_candidates#Uranus, the nominator responded to my query about the spaces in the infobox of Uranus thus:

The space separators to the right of the decimal appear to come from ISO 31-0. It's been applied to all of the Solar System planet articles by an unknown editor. — RJH (talk) 16:34, 11 August 2007 (UTC)
Note that I don't have an issue with this spacing scheme; they make a long string of digits easier to read. — RJH (talk)

They look seriously bad, so I wonder whether action is required. I'm no expert on this. Tony 23:56, 11 August 2007 (UTC)

Actually, they've been around for at least several decades. Since it's inappropriate to use commas after the decimal point (or comma), a space is inserted after each group of three digits to enhance readability and reduce transcription errors. I didn't know that it had made it into an ISO, though. Askari Mark (Talk) 02:28, 12 August 2007 (UTC)
Thanks for that, Askari. They have a link to this section. Tony 05:42, 12 August 2007 (UTC)

Dates of birth and death duplication.

If the biography has an infobox, can we have the dates in there only instead of duplicating it after the name? -- Jeandré, 2007-08-12t11:58z

Nothing would please me more. Is there any support for this? Tony 12:17, 12 August 2007 (UTC)
Wrong forum; we should work it out on the talk page for WP:MOSBIO. Chris the speller 15:43, 12 August 2007 (UTC)
Linked to this from there. -- Jeandré, 2007-08-13t11:02z
On that talk page, I reiterated the question and asked for it to be discussed there, not on this talk page. Chris the speller 15:11, 13 August 2007 (UTC)

OT: rules.

Add the option; the fewer piddling rules the better. Septentrionalis PMAnderson 23:26, 12 August 2007 (UTC)
You seem to be anti-rule. This is not the place for you. Tony 23:40, 12 August 2007 (UTC)
No, I endorse the policy in the paragraph we restored today: if two methods are both acceptable, as both would be here, either can be used; don't edit solely to switch from one to the other. Do you disagree? Septentrionalis PMAnderson 23:51, 12 August 2007 (UTC)
  • As for not belonging here: an editor who cannot tell the difference between, on the one hand, a choice among methods to convey information (which is our purpose), and, on the other, those rules to which English does not allow exceptions, is hardly the ideal writer here. Septentrionalis PMAnderson 00:11, 13 August 2007 (UTC)
All too subtle for me; or is it that I just can't be bothered trying to make out the meaning? Tony 06:02, 13 August 2007 (UTC)
Presumably the latter. After all an editor who is too politically correct to accept him as common gender, and so cunning that he cannot change to him or her (or change number to them) can hardly be lacking in subtlety, can they? Septentrionalis PMAnderson 18:46, 13 August 2007 (UTC)
Your'e right, I am too aware of the need to write inclusive language to pass over the now-unacceptable assumption that the male is the default gender. Singular they is one of several solutions, and not one I favour. Tony 01:17, 14 August 2007 (UTC)
I did not propose singular they; had I done so, I would not have written "changing number". It would be no problem to change the sentence to speak of readers. Please read what is in front of you. Septentrionalis PMAnderson 02:52, 14 August 2007 (UTC)

Unsatisfactory edit

"Always convert dates to correspond with years starting on 1 January."

has gone to:

"Always be clear about what style an article uses; in general, this will mean starting the year at January 1, and saying that the year does begin then, unless that is clear from context."

which is unclear, inconsistent and misleading. It will have to be changed.

Thanks for raising it here first. Tony 23:39, 12 August 2007 (UTC)

Nonsense; I will tag any such modification as disputed. This is both clear and consistent as an objective.

On a wider matter, I see that there seems to be some confusion on how to write a working manual of style; this edit summary (The local stuff about this will have to go, then; I'll remove later today. )supposes that if we have a general rule or objective, we don't need to give examples for specific cases. Precisely the opposite is true; many editors will look for the clause on the matter they have in mind, and not bother to read the header. If it is important to remind editors what is not worth revert warring over, it is often worthwhile to do it twice. Septentrionalis PMAnderson 23:48, 12 August 2007 (UTC)

Principles:

OK, then every single option—there are many, many of them—will need to be tagged with the clause about consistency within an article, and not changing from one option to the other without good reason. Every single one. Are you going to do that? And before you lable my comment as "nonsense", look at your own English, which is ... little short of it.

So then, who is to judge when a reminder "is needed" or "is useful" to duplicate again and again. I say that it's not needed there. And to claim that your edits were not unclear, inconsistent and misleading is just poppycock. Want me to point out in detail why? Tony 06:00, 13 August 2007 (UTC)

No, thank you; you have already demonstrated your level of competence in English usage and your understanding of how to write guidelines. More is not necessary. Septentrionalis PMAnderson 18:49, 13 August 2007 (UTC)

Sprinkling "reminders", as you call them, locally through a MOS is not a good idea. The shorter and cleaner the text, the more likely its comprehension by users. Overriding principles need to be stated at the top, preferably once unless there is some critical need to do otherwise. I don't see that here. The current imbroglio at MOS talk on the very issue of converting BCE to CE and vice versa would not have been prevented by the insertion of a local "reminder".

I must ask that you not unilaterally make major edits to the text without posting them here first, because of the extent to which they need to be fixed. The adjustments should be done here; that's what a talk page is for. Please address my invisible inline queries on your latest attempt. You have a talent for redundancy and vagueness, and they're difficult to fix without your specialised knowledge. Um ... collaboration, I think it's called. Tony 01:14, 14 August 2007 (UTC)

It is unfortunate when confusing edits are introduced to the Manual of Style; it can happen at precisely the time an editor is referred to MOS, and they find confusing information. I couldn't decipher today's edits; glad they're sorted out now. SandyGeorgia (Talk) 01:27, 14 August 2007 (UTC)
Tony's "fixes" are illiterate, and demonstrate ignorance of common scholarly usage. Analysis follows.
Where a calendar other than the Gregorian is used, this must be clear to readers.
For the Middle Ages, when the Gregorian calendar was unknown? For the Roman Republic, where the invariable (and largely unavoidable) custom is to use the Roman calendar (which is neither Julian nor Gregorian, and for parts of which the correction to Gregorian is unknown)? For ancient Greece (normally, where feasible, converted to Julian? Septentrionalis PMAnderson 02:39, 14 August 2007 (UTC)
There are three other options<comment: !--Is this for Greg/Julian only? Why "both" in the third bullet? If it IS for the two only, this should be flagged in the lead sentence. Either there are three options or there are not: "several" is unacceptable-->.
There are at least four other options; see the paragraph below: there are a large number of variants which include both calendars. Making clear that the "both calendars" involved are Gregorian and the local calendar, whatever it may be, would be harmless; it rarely hurts to spell out an implication, however clear it originally was.
Removed It is less important which option an article uses (they all convey the same facts) than that the article communicate to the reader which one it does use.
Why? This should be consensus. Clarity is the goal; the MOS is a means. It should not be used as an power-trip . Septentrionalis PMAnderson 02:39, 14 August 2007 (UTC)
  • I have a client now for five hours, so I'll address these points later, including an illiterate and ignorant proposal for wording the "both/several" issue. In the meantime, might you propose wording here as an improvement of "Where a calendar other than the Gregorian is used, this must be clear to readers." Please don't frame this as "an power trip" ; it's just crafting and negotiation, with a reward for all at the end. Tony 03:11, 14 August 2007 (UTC)

Old Style New Style

See also Old Style and New Style dates, and on the talkpage Talk:Old Style and New Style dates#Two different interpretations

This paragraph appears to be unwisely put:

If it is important to preserve consistency with primary sources, a date may be given in the original style with its equivalent in the modern style; for example, Elizabeth I of England died on 1602-03-24 (Old Style)/1603-03-24 (New Style). Although this would correspond to 3 April, 1603 if fully converted into the Gregorian calendar, the month and day of a British event are normally not converted.

There are at least four possible styles here:

  • 24 March 1602 (Julian, as used in England)
  • 3 April 1603 (Gregorian)
  • 24 March 1603 (composite)
  • 24 March/3 April 1602/3 (and its variants)

The first, the contemporary usage, is Old Style; but either of the middle two can be called New Style. To say that the composite is normal is simply wrong; It is probably most common, but it's more likely to be a plurality than a majority, and it depends on the level of competence the author expects of the reader (and the date of the subject; New Year on January 1 was more common in the early eighteenth century than before). Serious books at least use both years for dates between January and March. (This would be clearer, btw, if the example were earlier than March...) Septentrionalis PMAnderson 00:34, 13 August 2007 (UTC)

George Washington's birthday (February 11, 1731 OS) might be a better example here, because it is in February. This has nothing to do with Anglo-Americanism; but since someone will think so, unless denied, I propose it here.—The preceding unsigned comment was added by Pmanderson (talk • contribs) 19:22, 13 August 2007 (UTC)
Using birthdays of people alive during the transition are probably not the best to use because clause VI. of Calendar (New Style) Act 1750, specifically regulates how birth dates should be presented for those born before "14th Day of September". --Philip Baird Shearer 17:54, 15 August 2007 (UTC)
This may be an Anglo-American difference then; Washington chose freely among the possibilities, in choosing to celebrate the Gregorian date. Septentrionalis PMAnderson 21:06, 15 August 2007 (UTC)

There are two different interpretations of what constitutes New Style. One is a change of the calendar date to 1 January as in this document. The other is a full conversion to Gregorian calendar as in this source.

Now for what I think is wrong with the page:

There are several methods for dealing with dates before the local introduction of the Gregorian calendar; in Europe, the earlier calendar involved will be Julian:
  • Give dates in the local calendar only — with an adjustment for the start of year as 1 January if necessary. This means that the dates will match the dates in the primary sources for that period. In Europe, there should be explicit indication that the dates are in the Julian calendar if this is necessary; for non-European calendars, it will usually be obvious they are not Gregorian.

I am sorry but it is not usual to give an explicit indication that the dates are in the Julian calendar. For example with the exception of the Battle of the Boyne, all events during the C17 in the UK are usually recorded as Julian with year adjustment. The should not be in the Gregorian calendar.

The only problem comes when one is talking about events that take place in both Julian and Gregorian regions, for example in the article Glorious Revolution. This also throws up the problem of whether to refer to events as (Gregorian calendar) or New Style, because it is not clear if the date is New Style start of year adjustment or New Style Gregorian calendar adjustment. For example this sentence is wrong "William and Mary were offered the throne as joint rulers, an arrangement which they accepted. On February 13, 1689 (Old Style), February 23 (New Style) Mary II and William III jointly acceded to the throne of England." It should be February 13, 1688 (Old Style), not 1689. But then one has to decide if it is February 13, 1689 (New Style) or February 23 1689(New Style)


  • Convert the dates to the Gregorian calendar. This enables the correlation of dates in countries and at times in which different calendars are or were used. The conversion should be explicit unless this is obvious to readers; it is useful to check that the sources have not already converted them.

This is clearly wrong advise, all British dates should be Julian with the start of year adjustment until the conversion to the Gregorian calendar. What is needed here is follow the lead of reliable secondary sources.

This advise is not the best. Again it should be follow the advise of reliable secondary sources.

It is less important which option an article uses (they all convey the same facts) than that the article communicate to the reader which one it does use

Not true Misplaced Pages should follow the lead of reliable secondary sources, or it ends up with dates that look nothing like those in other reliable sources.

It is reasonably common, and may be useful for consistency with primary sources, to give both years for dates between January and March. For example, Elizabeth I of England died, according to her English contemporaries, on 24 March, 1602, the eve of New Year; the equivalent Gregorian date was 3 April, 1603. Either may be used, or the common composite form 24 March, 1603; but 24 March, -3.

The layout of this is wrong it should follow the normal convention that would be 24 March 1602/03.

--Philip Baird Shearer 10:34, 14 August 2007 (UTC)

Much of this is well taken; I regret being so conservative with what I found when I got here. There are two overall points, on which I think reasonable editors can agree:
  • There are some articles on which we should use Julian (Charles II of England); some on which we should use Gregorian (Fronde); some on which we must indicate which (War of the Spanish Succession).
  • We should be use local dating when it is expected (the English articles here; the birth and death of Julius Caesar — his birth is of course neither Julian nor Gregorian.)
    • It does no harm to remind readers that they are dealing with a non-Gregorian calendar; especially in Europe, when we are using the Roman months. But it is useless rule-making to require every article to do so. Septentrionalis PMAnderson 18:25, 14 August 2007 (UTC)

I would not revise this section into a mandate in the other direction either. We should remember that there will always be boundary cases (much of the eighteenth century in English-speaking countries) where a mixed approach is desirable. We should not prohibit it in favor of Julian any more than in favor of Gregorian. Septentrionalis PMAnderson 18:38, 14 August 2007 (UTC)

My own thoughts on this is that:
The dating method used in a Misplaced Pages article should follow that used by reliable secondary sources. Unless otherwise stated in the article, Julian calendar years will start on 1 January. If there is a need to mention Old Style or New Style in an article (Like in the Glorious Revolution) then on the first usage, a footnote should be provided stating if the "New Style" refers to a start of year adjustment or a conversion to the Gregorian calendar.
--Philip Baird Shearer 10:24, 15 August 2007 (UTC)
Included a recommendation to follow reliable sources. I am not as convinced as PBS that actual usage is as uniform as all that (I've seen a lot of double-dating works of reference); but if it is, the recommendation will apply.. Septentrionalis PMAnderson 21:35, 15 August 2007 (UTC)

percentage vs percentage point

I propose to add the following last point to the section on percentages.

  • Percent or per cent are commonly used to indicate percentages in the body of an article. The symbol '% may be more common in scientific or technical articles, or in complex listings.
  • The symbol is unspaced (71%, not 71 %).
  • In tables and infoboxes, the symbol is used, not the spelled-out percent or per cent.
  • Ranges are preferably formatted with one rather than two percentage signifiers (22–28%, not 22%–28%).
  • Use percentage points, not percentages, to express a change in a percentage or the difference between two percentages (The agent raised the commission by five percentage points, from 10 to 15%. If the 10% commission had instead be raised by 5%, the new rate would have been 10.5%). Percentage point is always spelled out; after the first occurrence, it may be abbreviated to point, unless this would be unclear, and should not be confused with basis point, which is a hundredth of a percentage point. Tony 14:19, 15 August 2007 (UTC)
    • Strongly oppose the last suggestion, which will produce unlimited confusion with basis point. A caution to be careful would be justified. The rest of these, which already exist, should be pruned; they are (except perhaps for no spaces before %) more examples of the sort of thing MOS should not be deciding. Leave articles which succeed in communicating with the reader alone. Septentrionalis PMAnderson 20:58, 15 August 2007 (UTC)
Thanks to Anderson his/her point about possible confusion with basis point, although a more measured tone would be welcome; I've removed mention of the abbreviation to point and cautioned against confusion with basis point, as suggested.
I strongly oppose his/her comment about the other points, and doubt that it has support among others, here or at MOS. The logical extension is that MOS and MOSNUM would be "pruned" to a skeleton, and cohesion in the project sacrificed.
I'm tiring of continually having to fix Anderson's edits to the page, which are made in what appears to be a casually incorrect version of English—basic errors have been evidence of a slap-dash approach. Please make amends. Tony 00:11, 16 August 2007 (UTC)
You may stop doing so at any time. Septentrionalis PMAnderson 02:25, 16 August 2007 (UTC)
That's the kind of attitude that will land this page in a mess. Again, I ask you to desist from blundering in with your error-prone language. I wonder why I bother to raise things here first, if you take it upon yourself to unilaterally make substantive changes to the page. Tony 03:11, 16 August 2007 (UTC)
No, the attitude that has landed this page in the mess it is in is provincial insistence on comprehensive-school shibboleths; as with the nonsense above about not having a comma after September 11, 2001. We should not insist on violations of idiom; and if we are going to play schoolmaster, we should get it right. Septentrionalis PMAnderson 16:34, 16 August 2007 (UTC)
No idea what he's talking about; can anyone decipher it for me? Tony 06:32, 17 August 2007 (UTC)

This page fails to distinguish between three kinds of recommendation:

  • Rules, which no competent writer of English would violate (without extraordinary reason). Even here, it fails to recognize differences of importance; the only example of these in the section on percents is the absence of space in "71 %", and does that really matter? If it turns out to be the standard usage in Indian English, for example, we should permit it, as we use Mumbai; and would lose little by doing so.
  • Recommendations, or good ideas. The example here would be using % in tables, because it's shorter. This recommendation has no more force that that; if there comes a time when a table doesn't need to squeeze out those characters, we should use "per cent". Two examples:
    • If the headers of a table are "Absolute change", "Per cent",...; we should usually spell out Percent; especially if we do not lose a column by doing so.
    • A table of powers of the Federal Reserve Board may mention "percent" in passing; there is no reason to abbreviate.
  • Choices, unmotivated, or barely motivated, between good methods of accomplishing the same end. The canonical example here is the choice between footnotes and Harvard referencing; each has its good points, and some editors feel strongly about the choice between them. Here we should permit both; ideally, we would describe the advantages and disadvantages of each.
    • The lengthy paragraph about percentage points comes under this head. There is a trade-off between the clarity of points and the additional length and weight it adds to the sentence; it should not be mandated. A caution is the proper action here; if it is necessary to refer to this, add a sentence: in this case, it's worth adding "points". Septentrionalis PMAnderson 16:34, 16 August 2007 (UTC)
  • Point 1: no, standard in Indian English isn't necessarily a reason for blanket acceptance. A spaced percentage sign is harder to read, IMV, and there's benefit in forcing a standardisation. Almost all instances are unspaced, anyway.
  • Point 2: Maybe, but % in a table header seems fine to me. I don't think it's worth making an exception for headers. This has been in the guidelines for quite a long time, I think. Why not abbreviate? The more white space in a table, the less cluttered and easier to read it is. I see no reason to change long-standing policy here.
  • Point 4: The use of percentage points is absolutely essential. People write statements such as "the proportion of the population who are privately insured has risen by 10% in five years"; do they really mean from 40 to 44%? Usually they mean 10 percentage points. This distinction needs to be enforced, as occurs explicitly in quite a few house styles. Tony 06:41, 17 August 2007 (UTC)

another inflexibility in the autoformatting system

Discussion on this page appears to have uncovered yet another disadvantage of WikiMedia's date-formatting mechanism: it won't allow the final (parenthetical) comma after North American date formatting without forcing it on other formats (which do not want it). In other words, you can't autoformat "The October 5, 1999, stockmarket correction ...", without forcing the display of "The 5 October 1999, stockmarket correction", which non-Americans will object to.

Here's a list of the dysfunctional aspects of the autoformatting system.

  • It's conflated with the linking function, thus forcing the intrusive blue colour and, depending on settings, underlining, for the display. This has all of the disadvantages of overlinking, such as the tendency to dilute the distinctive appearance of high-value links.
  • It won't allow the North American final comma.
  • It won't allow the economical rendering of date ranges, such as October 5–7, 1999, such as MOSNUM favours for percentage and unit ranges, instead forcing both dates to be spelled out in full hedgehog fashion (October 5, 1999 – October 7, 1999).
  • It won't allow the date-slash, specifically mentioned as an option by MOSNUM (the night of May 30/31).
  • It works only for Wikipedians who have selected a format (a tiny proportion of readers).

It's little wonder that I resisted the partial backflip on the relaxation of the mandatory use of autoformatting in the recent overhaul of MOSNUM. I want to put it to you that we should not be insisting that dates are "normally autoformatted". I, for one, actively encourage WPians not to use it until it's fixed. Tony 13:11, 16 August 2007 (UTC)

  • This, however, seems sensible. Simply not autoformatting date ranges would avoid a lot of this; and unless May 30/31 is followed by a year, it wouldn't be autoformatted anyway. A Bugzilla report should get the autoformatting to deal with the comma, both producing it when necessary and absorbing it when the date is changed from American to British English; although the latter runs the risk that the final comma is marking both the year and the end of phrase. Septentrionalis PMAnderson 16:42, 16 August 2007 (UTC) Septentrionalis PMAnderson 16:39, 16 August 2007 (UTC)
  • Saying nothing about the flatly ungrammatical "the attacks of September 11, 2001 are the" is contrary to the purpose of the MOS. The judgment that the automagic system is more important than American grammar is for editors to make; I think it is clear how I would make it, but others may differ. We should at least discuss the issue; silence encourages literate editors to add the comma, without realizing that there is a problem. Septentrionalis PMAnderson 17:55, 16 August 2007 (UTC)
    • What Chris removed was the statement of fact:
      In American English, the month-day-year style of dating ("The attacks of September 11, 2001, were among the most serious.") treats the year as parenthetical; as in the example, the year is divided off from the rest of the sentence by commas. If the year is immediately followed by other puncutation ("on September 11, 2001; the world..."), the trailing comma is omitted.
    Does he dispute this? Septentrionalis PMAnderson 18:36, 16 August 2007 (UTC)
    • I don't think any of us dispute it, but the problem remains that you can't autoformat and add the comma, because it will screw up the date in non-US formats. This, I suggest, is why the phenomenon of not inserting the commain the US format, contrary to what now appears to have been standard practice all along, emerged in the first place on wiki (non-US WPians, of course, come along and remove any comma because it looks odd in their display).
This is yet another reason, IMV, that we need to weaken the "normally" in the guideline for "Autoformatting and linking". Let me warn you that moving the developers over at Bugzilla is like trying to shift an ocean liner. We tried for a second time (with 84 signatures, as well written argument, and no objections) and failed WRT the relatively simple task of producing a parallel script (something like <<date>>, but whatever they felt like choosing) that would not link. I'm not a developer—nothing like it—but something tells me that they'll throw up their hands at being asked to solve all of the problems in the list above (well, the first four). I think the non-linking, the US comma, and the date-range issues are the priorities, in that order. The US comma is not easy to fix, because the function will have to distinguish between instances where there's another punctuation sign in place of the comma. Possible, but not straightforward.
I know that SMcCandlish is keen to make another push, and has hinted that this time we need to start higher up the food chain. Tony 23:38, 16 August 2007 (UTC)
I don't think that non-implementation will bother many American readers, anyway. The comma after the year is more commonly dropped than used. Askari Mark (Talk) 03:04, 17 August 2007 (UTC)
Anderson, months-days are explicitly enabled by autoformatting: May 30 responds to the order of the setting. The slashed date renders a broken link. Tony 06:43, 17 August 2007 (UTC)
Note that month-days are only autoformatted for some of the date settings: May 30 and 30 May do not generate the same thing with an ISO date setting. --PEJL 08:15, 17 August 2007 (UTC)

So get it fixed. — The Storm Surfer 17:14, 19 August 2007 (UTC)

Precision?

Tony1 is revertwarring for the following text:

  • The month-day-year style of dating ("The attacks of September 11, 2001, were among the most serious.") treats the year as parenthetical; commas are inserted before the year and, unless it is followed by another form of punctuation, after it.

to replace

The month-day-year style of dating ("The attacks of September 11, 2001, were among the most serious...") treats the year as parenthetical; it should be separated off by commas at both ends, unless already bounded by other punctuation.'


Tell me, what circumstance would give these sentences different meanings?

It may be possible to replace bounded with followed; but the clumsy repetition of it in the top text is no improvement. Septentrionalis PMAnderson 16:57, 16 August 2007 (UTC)

  • Another unfortunate effort at mindless precision appears to have provoked this edit. The text was
  • Yearless dates (5 March, March 5) are inappropriate unless the year is obvious from the context. If there would be any doubt, include the year.

As phrased, this would prohibit Guy Fawkes Day is celebrated on 5 November; and Kandolin attempted to clarify that this was not intended — as I trust it is not. The proper response is to recast, so it only prohibits ambiguity. Septentrionalis PMAnderson 17:10, 16 August 2007 (UTC)

In the second example, the antecedent of "it" is "style", which therefore makes the wording wrong. Using "it" a grand total of twice in one sentence is no crime, and is probably preferable to the awkward phrase "separated off". — Aluvus t/c 01:13, 17 August 2007 (UTC)

Modern times

Quite often in modern times or is now considered should not be replaced with "as of 2007". When they refer to the present state of scholarship, they can approximate "since 1950", "since 1895", or "since the Renaissance". To state that scholarship holds X as of 2007 implies that we have a source written, or at least published, this year; often we don't. We could require "since ", but that would be very difficult to source, and an invitation to original research. Septentrionalis PMAnderson 17:21, 16 August 2007 (UTC)

in modern times is just too vague. Remove now from the second one and it might be OK in some contexts. Tony 06:25, 17 August 2007 (UTC)
If you wish to include some other discussion of them, do so; but they don't belong where they were. Septentrionalis PMAnderson 15:36, 17 August 2007 (UTC)

Yearless dates

The recent (reverted) changes in the "yearless dates" subsection concerned the referencing of holidays. Under the prevailing wording, the following sentence violates the guideline:

  • January 1 is New Year's Day.

Since annual holidays do not predicate on any particular year, why not make an exception for it? —Kanodin 18:52, 16 August 2007 (UTC)

Reworded to Yearless dates (5 March, March 5) can be ambiguous. Either ensure that the context makes obvious what year is meant, or include the year.
I think this removes the implication that the sentence violates MOS; do we need more? Septentrionalis PMAnderson 19:10, 16 August 2007 (UTC)
I think the Jan 1 example still violates the MOS. The revised wording requires an editor to include a definite year, like January 1, 2007, or to ensure that January 1 refers to a definite year by virtue of context. A holiday implies no year and there is no yearly context (except historically). It happens every year; implying a year or writing a year would be inappropriate.
Simple alternative:
* Yearless dates (5 March, March 5) can be ambiguous. Either ensure that the context makes obvious what year is meant (if any), or include the year.
Complex alternative:
* Yearless dates (5 March, March 5) can be ambiguous. If the date refers to a recurring event, then specify how the date recurs. Otherwise, either ensure that the context makes obvious what year is meant, or include the year.
This sounds anal, but you know someone will hold other editors to the letter of the MOS, regardless of ignore all rules. —Kanodin 06:08, 17 August 2007 (UTC)
It says can be ambiguous. The wording is fine, except that "ambiguous" is wrong; ambi- means both, so "unclear" would be better. Tony 06:24, 17 August 2007 (UTC)
We are writing English, not Latin. The OED definition is Admitting more than one interpretation, or explanation; of double meaning, or of several possible meanings; equivocal. This explicitly permits "several possible meanings", and English usage clearly makes no such distinction. Since we use disambiguation freely, and as a quasi-technical term (see any disambiguation page), ambiguous is actually better here.
I suggest, and will include: Note: This caution does not apply to describing recurring events, such as "January 1 is New Year's Day", as there is no ambiguity to be resolved. It would be artful to quote our usage below: "dates other than 1 January were used as the start of the year"; but this is probably too long. Septentrionalis PMAnderson 15:02, 17 August 2007 (UTC)
No, you won't include it, or I'll revert. It's bloat, the whole thing. Why does can not provide sufficient lattitude for editors to work out for themselves that "January 1 is NYD" doesn't need a year attached? It's just too silly. Tony 15:33, 17 August 2007 (UTC)
I wrote can; but Kanodin wants more. Kanodin's complaint, which he has made several times, is clearly a genuine worry. He may be right to worry; I have seen enough semiliterate uses of the MOS by the half-educated not to include this pre-emptively, since he asks. Septentrionalis PMAnderson 15:40, 17 August 2007 (UTC)
Surely the "(if any)" revision is small enough? The verbose versions are admittedly more cumbersome, and I would like to keep things simple. The ambiguity sentence does not inform the reader what needs clarity. The sentence following it, in prescribing how to remedy the ambiguity, mandates one of two options: (1) implying a specific year, or (2) writing a particular year. The "(if any)" qualification allows an editor to imply that a yearless date refers to no particular year. —Kanodin 19:09, 17 August 2007 (UTC)
I considered (if any). The problem with only can is, if I understand you correctly, that it doesn't make clear in which cases yearless dates should be left alone, but forces the reader to deduce that we mean holidays and other recurrent events; if we are content to trust that every reader will follow this implication, why add anything? I think (if any) has the same problem. Septentrionalis PMAnderson 20:08, 18 August 2007 (UTC)
I like the current wording:
  • Yearless dates (5 March, March 5) can be ambiguous. Include the year if the meaning is unclear. There is no such ambiguity with recurring events, such as "January 1 is New Year's Day".
—Kanodin 07:40, 19 August 2007 (UTC)

Anderson, please cooperate and collaborate

There are too many reverts happening, because you act unilaterally, without talking things through here first. It's not a good look for the page. None of us owns MOSNUM; while there's often a bit of push and pull, when I see seven or eight of your edits in a row, some of them changing policy, I draw breath. Can you please cooperate? Tony 23:45, 16 August 2007 (UTC)

There are too many reverts happening because you revert even patently correct statements of English grammar, such as Michael Hardy's, below. Please stop being disruptive. Septentrionalis PMAnderson 14:46, 17 August 2007 (UTC)
It's a serious problem when you try to deflect such a critical comment. Tony 15:34, 17 August 2007 (UTC)
It's a fact that August has 31 days, that dates higher than 31 are incorrect, make WP look unprofessional, and should not be used, and that August 491 is laughably incorrect. But the manual should not have instructions added except by consensus, so it would be wrong for me to take it upon myself to insert those observations into the manual. And their being correct does not make them immune from reversion. Chris the speller 16:40, 17 August 2007 (UTC)

Certain distinctions not mentioned here

There is a difference in meaning between

Every number except one

and

Every number except 1.

When one writes "There are seven reasons for this", one writes "seven" and not "7", but when one writes "The only two prime numbers that were mentioned in that paragraph were 7 and 43", it would be incorrect, in my view, to write "seven and 43". I've adhered to that convention hundreds or perhaps thousands of articles here. When one is using "7" as a noun to refer to the mathematical object about which one is writing, it's not at all the same as saying "There are seven reasons".

I think this manual should make all this explicit. Michael Hardy 14:33, 17 August 2007 (UTC)

Of course it should. If any editor disagrees with the substance here, please say so. Septentrionalis PMAnderson 15:03, 17 August 2007 (UTC)
Mmm, glad to see that you're encouraging measured discussion and feedback here. Tony 15:27, 17 August 2007 (UTC)

Reversion of hastily inserted point on the US comma and autoformatting

No, consensus had not been reached. The following text needs to be throught through further and, at the very least, the English improved before being slapped into the Manual.

    • The use of punctation after the year creates problems for the autoformatting system; which will translate the standard American usage "The attacks of September, 2001, were among the most serious...." to the ungrammatical "The attacks of 11 September 2001, were among the most serious...." Editors differ on how to deal with these conflicting demands; one solution is to add the comma and not wikilink.

Tony 16:14, 17 August 2007 (UTC)

So what flaws do you see this time? Or is this another figment, like your treatment of ambiguous and only? Septentrionalis PMAnderson 16:27, 17 August 2007 (UTC)
The use of the semicolon in the first sentence is pretty obviously incorrect, which is ironic in a note about the grammatical usage of commas. I'm also not sure there is any real consensus about what MOSNUM should say on this matter. — Aluvus t/c 23:48, 17 August 2007 (UTC)
Yup, and the first clause is not quite right; punctuation doesn't always create problems, when, for example, a comma would normally occur whatever the format ("After , the legislation will be invalid"). That's one reason the software is going to be very hard to fix, and is probably also the reason that this issue has remained hidden for so long. Why is there a four-dot ellipsis at the end of the example? It's wrong unless the quoted material continues after that point. See MOS on this. I'm not entirely happy with the framing of the presence or absence of the comma as "grammatical"—it may or may not be, but let's not fly a flag here on one side of that issue. I don't think it's worth raising the confusion and indecision WRT this technical/stylistic issue to the level of a guideline ("Editors differ on how to deal with these conflicting demands") and the touting of just one solution. It's too arbitrary, and I wonder why editors can't just deal with the problem now, without the guideline. This also needs to be thought through in relation to a larger strategy for dealing with the autoformatting mess as a whole. "Not wikilink", for example, is in partial conflict with the phrase "normally" in the "Autoformatting and linking" section. Two asterisks were used, where one should have appeared.
Now, Anderson, unless you desist from your current strategy of launching in to make significant changes without allowing sufficient time here for discussion, I've a mind to revert everything you do. I'm tired of logging in and having to spend up to an hour cleaning up after you. And you can't even be nice about it: your attitude is pretty abrasive and self-righteous, and I find myself being ruder than I like to be in response. Tony 01:08, 18 August 2007 (UTC)
I note this declaration of intent to revert war. Tony should remember, but apparently does not, that he began with incivility in edit summaries; if this is his good behaviour, what is his bad? Horresco referens. Septentrionalis PMAnderson 20:03, 18 August 2007 (UTC)
Again, you deflect the issue. It's always someone else's fault, isn't it. Tony 23:12, 18 August 2007 (UTC)

3.4. Percentages and 4.3. Unit symbols and abbreviations

  • 3.4. It is said that "he symbol is unspaced (71%, not 71 %)". There are contradictory views elsewhere on Misplaced Pages - Percent_sign#Spacing. Does the manual have to be unambiguous in this matter or shouldn't it present rationale for both notations according to the NPOV?
  • 4.3. It is said that "alues and unit symbols are spaced (25 kg, not 25kg). There are two exceptions: angles in degrees are unspaced (45°); and Celsius and Farenheit temperatures may be either spaced or unspaced (15°C or 15 °C)". This is clearly obsolete comparing to newer discoveries of Wikipedians like ISO 31-0 or Celsius#Formatting or smaller discussions on other units pages. There are three exceptions - #°, #′, #″; but not #℃ (correct: # ℃) in short.

83.9.19.149 01:05, 18 August 2007 (UTC)

Your first point: I've inserted into the text of that article a note about the insistence of WP's MOS and other authorities on unspaced percentage signs. This was decided here by consensus. Your second point: you're quite right—it's been changed here, but not at MOS. I'll do this now. Tony 01:16, 18 August 2007 (UTC)

Later: Well, it was changed here about a week ago by a non-regular user, and MOS itself has the properly worked through change; but here, the text is still showing the earlier guideline:

Values and unit symbols are spaced (25 kg, not 25kg). There are two exceptions: angles in degrees are unspaced (45°); and Celsius and Farenheit temperatures may be either spaced or unspaced (15°C or 15 °C).

MOS:

Values and unit symbols are spaced (25 kg, not 25kg), including degrees of temperature (−15 °C). Angles are an exception to this (180°). Angular degrees, minutes and seconds are formatted 45°, 12', 59".

It seems reasonable to go along with the ISO rules about spacing. I propose this wording, for both MOSNUM and MOS:

Values and unit symbols are spaced (25 kg, not 25kg). The exceptions are degrees, minutes and seconds for angles and coordinates (“the coordinate is 5° 24′ 21.12″ N”, “the pathways are at a 180º angle”, but “the average temperature is 18 ºC”).

I guess non-breaking spaces should have been added to the coordinate example. Does anyone object, apart from Anderson? Tony 02:40, 18 August 2007 (UTC)

Does anyone support "The exception is degrees..."? The actual MOS text is better, although a semicolon after (180°) would be an improvement. Septentrionalis PMAnderson 20:13, 18 August 2007 (UTC)
All you have to do is to suggest the improvement—not to try to scrore your smarmy points during this process. And before you do that, fix up your own comment (read MOS on ellipsis dots). Tony 23:10, 18 August 2007 (UTC)

WP:DATE as applied to athletics articles.

There is a great deal of controversy surrounding how WP:DATE is applied to articles that are discussing athletic related topics. Many years are wikilinked to "season" articles within a given context. For example, many people like to wikilink 2002 to the 2002 in basketball article. The debate does not center around "is that appropriate" so much as - where in the article should that be done. For example, at Steve Nash - there is an infobox but none of the years in the "former teams" section are wikilinked to the relative "article". Similarly, in the same "relative section" on Barry Bonds you will see that the year 1993 is wikilinked to 1993 in baseball. There are some references to this throughout the WP:DATE article, but they seem somewhat unfocused and don't really allow for a clear understanding of the consensus. I would think we need to addressed better because it can also extend itself to things like the Al Pacino article because of 2003 in film. Juan Miguel Fangio| ►Chat  21:00, 20 August 2007 (UTC)

Again, the Baseball WikiProject already had this conflict, and it was agreed upon that the links in the infoboxes linking to ___ in weren't any helpful in the infoboxes. The links aren't helpful in deepening the reader's understanding of the topic, and WP:DATE says "Link to one of these pages only if it is likely to deepen readers' understanding of a topic," a criterion which I believe this fails to meet. Ksy92003(talk) 21:09, 20 August 2007 (UTC)
Ksy92003 - You and I have had intense disputes before and currently, I would appreciate if you would not follow me to every page i comment on and misstate information. Seeing as Alex Rodriguez and Barry Bonds (amongst thousands of others - Ty Cobb) do wikilink the information, it might help to appropriately present what is going on. Juan Miguel Fangio| ►Chat  21:16, 20 August 2007 (UTC)
You're criticizing me for coming here? If you think that you can begin a discussion about something that I'm related to, then you're mistaken. The reason why most of those articles have yet to be changed is the person who was gonna make those changes was Soxrock (talk · contribs), who was blocked for sockpuppetry shortly after, so nobody was able to do that. And I am not misstating information. I've told you, and Chrisjnelson has told you, that linking the years doesn't aid in the understanding of the article. It doesn't help the reader understand what it is, does it? Ksy92003(talk) 21:26, 20 August 2007 (UTC)
I'm not criticizing you from coming here. I'm saying that if you like to point things out to people , please do a better job of reporting the information. it seems unlikely that if there was an agreement there to remove the said content - that two of the most notable current athletes would have had their aritcles brought up to speed. Further more, that project, just as with any project, can certainly establish its' own consensus. However, it is difficult to apply one wikiprojects consensus to all of wikipedia. Then again, I don't have any evidence that the wikiproject did have a consensus on this. Juan Miguel Fangio| ►Chat  21:29, 20 August 2007 (UTC)
Since you decided to bring up the discussion here, I assume that you believe that there should be links. Since that is the case, how do you feel that it helps the reader understand the topic? In other words, the example that CJ gave, how do those links on Jay Cutler's infobox help the reader understand the Jay Cutler article? Ksy92003(talk) 21:35, 20 August 2007 (UTC)
  • You can believe that, but you aren't correct. I probably lean more on the side of inclusion of season wikilinks, ultimately - I believe that there should be a clarification of the points here that will allow others to understand what the current consensus is. Then, if that needs to be addressed as consensus can change, then we tackle that issue. As for you and Chrisjnelson (talk · contribs), you can speak for yourselves. But his latest declaration of "then I will continue" is not going to help the matter. Juan Miguel Fangio| ►Chat  21:58, 20 August 2007 (UTC)
I can't say anythign about CJ because I have nothing to do with what he does. We share the same perspective, so I'm not going to tell him not to do what I was doing. And I don't know why you come out and straight-up say "you aren't correct." This isn't a matter of right or wrong. This is a matter of which best improves the encyclopedia. And I don't feel that the links improve it at all. Additionally, I am fairly certain that the only reason you contest this is because I have been the one to make the edits. You have never yet said why there should be links. You've continued to revert without even giving me a reason other than that the reverts were controversial. Now, all of a sudden you bring it here without any reason. This is something you've done to me several times with the ANI and 3RR. Ksy92003(talk) 22:16, 20 August 2007 (UTC)
You said "Since you decided to bring up the discussion here, I assume that you believe that there should be links." My response to that was - you aren't correct. That had nothing to do with the issue at hand. I have addressed your behavior and will continue to do so, through the appropriate avenues. This post is not about you and I but about WP:DATE. Let's not have more than one argument at a time. You insist on removing wiki links to seasons in one section of the article but not in others. What you should be citing is "Do not autoformat dates that are: in date ranges (see below)." That's all you need to say. Now, that aside, and as this is so far off the beaten path, i'll start another subsection here to try and get this dealt with. Juan Miguel Fangio| ►Chat  22:29, 20 August 2007 (UTC)

Dates ranges in infoboxes/templates

In an attempt to refocus the previous discussion, i want to simplify this issue for people. There seems to be a wide variety of opinions on the wiki linking of date ranges within infoboxes. WP:DATE has some very controdictory statemetns on how to address this and I think we should dedicate some article space to this. I would suspect that we could title the section "Dates in Templates". Thoughts? Juan Miguel Fangio| ►Chat  22:32, 20 August 2007 (UTC)

Sorry to come late to this; the in year links shouldn't be used unless they add specific WP:CONTEXT to the article in question. Excessive links clutter the article unnecessarily, detracting from the worthwhile links. SandyGeorgia (Talk) 22:41, 20 August 2007 (UTC)
  • Hey Sandy - that's the "crux" of the debate. The fact that the MOS says "no links in date ranges" but that it is okay when it adds context is somewhat counterintuitive. There seems to be a drive amongst people to adopt a new consensus - take a look at Barry Bonds and Michael Jordan. Bonds links the information and Jordan doesn't. To say that the bonds stuff should be removed is logical; however, a large number of people have made a push to make it acceptable. So perhaps we should move forward with a section in the article that addresses how to use Date ranges within templates. Juan Miguel Fangio| ►Chat  23:10, 20 August 2007 (UTC)
  • Similarly, we need to consider here is how do we deal with single years listed in infoboxes. For example: If i list * Team I played for (2007), i believe it should be dealt with in the same way as * Another team I played for (2003-2006). Juan Miguel Fangio| ►Chat  02:56, 21 August 2007 (UTC)
    • One rule may not suit all of sports very well. For example, if Brett Favre plays for the Packers from 1992 until 2009 (or whatever), wikifying those two numbers doesn't help very much. But in something like college football where most players only start for 1-2 years, wikifying seasons is helpful to navigation. I think definitely single seasons or individually listed seasons (1999, 2002, 2003, 2006) should be wikified, but I don't see any compelling reason to wikify long ranges. --B 03:13, 21 August 2007 (UTC)
This is not unique to sports. One area it "could apply" is with films. As for the NFL v CFB link, is there any difference? A legitimate point of view would be that seeing the links to 1992 and to 2009 would help identify how much (or how little) things changed over an extensive period of time. It is important to reiterate that this is not meant to extend to areas outside of navboxes and such. Juan Miguel Fangio| ►Chat  03:43, 21 August 2007 (UTC)
The only difference really is that you aren't going to have a long range for college years. So it's a difference of degree, not of kind. I'd take it one step further, though. Linking to 2004 in baseball for someone who played for the Yankees from 2004-2006 isn't really meaningful. But linking to a team-specific page (2004 New York Yankees if it existed) is probably helpful. I don't really see any reason at all to link to 2004 in baseball. Awhile back, I created a template called {{cfb link}} that will link to the best available team-specific page (the first blue link of 2004 Richmond Spiders football team, Richmond Spiders football, Richmond Spiders, University of Richmond) - something like that could be done to link to a team-year page if it exists, otherwise leave it as plain text. Is that something that would be useful and mutually agreeable? Only link if there is a team-year page or something otherwise more appropriate than 2004 in baseball, 2004 in sports, 2004 in American football, etc? --B 03:56, 21 August 2007 (UTC)
Well I think we're starting to get into a closely related, but different topic - what we link to is not the same as "what do we link". If that template helps to identify what "related" page is useful - then it could be. Pardon my poor choice of words here - but if this convention is to apply outside of "sports" (as it should) - then i think we're better off going with a "specific topic year" instead of a "specific organization year". I would link to 2004 NFL season and not 2004 San Diego Chargers season. For example - dealing with films - i don't know that there is an equivalent link to 2004 San Diego Chargers season. I would identify 2004 NFL season in the same manner as I do 2004 in film. Let me know if that sounds confusing. Juan Miguel Fangio| ►Chat  04:06, 21 August 2007 (UTC)
Well, I think for a football player, the team-year page is the parent topic for that player. If Michael Vick joined the Falcons in 2001 or led them to the playoffs in 2004, then linking to the team-season page is useful. In other words, I think that Star Wars I : 1999 in film :: Michael Vick : 2001 Atlanta Falcons. --B 04:43, 21 August 2007 (UTC)
Hard to say - this "appears" to be one of those where we're going to have to get some outside opinion. If it was Michael Vick (2001-2007), i'd link to the NFL season article. That "appears" to be how it's done on articles like Bonds. I think there are some more issues that are "just under" the surface, but I want to see how this discussion goes before we inundate it with all the "sub issues". Juan Miguel Fangio| ►Chat  05:02, 21 August 2007 (UTC)
For ranges, especially, I fail to see any real reason to link to individual seasons or what have you. For Michael Vick, to me I don't see any purpose to link his years to NFL seasons. So he played for the Falcons first in 2001. Does linking 2001 to 2001 NFL season help the reader in understanding what that is? There isn't anything significant about that other than the fact that he played his first game that season. What one man does doesn't affect the entire league, which is why I don't think that they should be linked to ___ NFL season; those are independent events that don't affect each other. I mean it's just a year. In the infobox, it reads as just a number. An example: if somebody made $1 million, you wouldn't link that to million because you don't need to go to another article to know that a million is a large number. You don't need to link 2001 to anything really because you know what 2001 is. You know that it's a year and links shouldn't be provided unless it is going to help deepen the reader's understanding of the context. Linking to 2001 NFL season isn't gonna help the reader know that it's 2001. Even linking it to 2001 doesn't seem to do that much because you already know that it's a year, and that's all that you need to know when reading the infobox. I don't see how linking it to anything would help the reader understand that 2001 is a year, and especially how 2001 NFL season helps the reader know that it's 2001. Ksy92003(talk) 06:35, 21 August 2007 (UTC)
Hmm... I originally thought that linking ranges for the years players played for specific teams would be useless and messy-looking. However, I do agree with the earlier point that we link to the team's season pages. By the way, it does exist: 2004 New York Yankees season. There is currently a project to create these pages for all teams for all seasons in the MLB, but I don't know about other sports. In instances where years are listed because achievements were made (teams list years when they took various championships), or when the year is just mentioned in the prose, it should link to that year in whatever sport it is. -- Silent Wind of Doom 17:38, 22 August 2007 (UTC)
So we have two issues a) should it be allowed at all and b) what is considered appropriate for direction. Remember, this has to extend beyond sports related topics if it's going to be inserted here. Juan Miguel Fangio| ►Chat  02:22, 23 August 2007 (UTC)