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

Archive 70

←

Archive 74

Archive 75

Archive 76

Archive 77

Archive 78

→

Archive 80

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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 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 Wikipedia. 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 Wikipedia" by not needlessly telling editors that they cannot use a standard abbreviation just because "a user [does not] 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 Wikipedia: abbreviations are most useful to conserve space, & Wikipedia 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 [talk] [cont] ‹(-¿-)› 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 Wikipedia, 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 Wikipedia (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 [talk] [cont] ‹(-¿-)› 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 Wikipedia, 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 [talk] [cont] ‹(-¿-)› 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 Wikipedia: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 [[As of 2007|as of]] 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 [talk] [cont] ‹(-¿-)› 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 Wikipedia: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 [[February 17]] (US editors) or [[17 February]] (others) will be rendered as either February 17 or 17 February, according to a registered user's set preferences; and
  • either [[February 17]], [[1958]] (US editors) or [[17 February]] [[1958]] (others) will be rendered as either February 17, 1958 or 17 February 1958, according to a registered user's set preferences.
• Wikipedia 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 ([[1997 in South African sport|1997]].

---

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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 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 Wikipedia 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 [talk] [cont] ‹(-¿-)› 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 Wikipedia'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 Wikipedia, 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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 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 Wikipedia, 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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 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[er|re]", 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 Wikipedia 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) Wikipedia 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 [talk] [cont] ‹(-¿-)› 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. [End screed, much of which is simply a restatement of what I said before that got archived before being resolved.] — SMcCandlish [talk] [cont] ‹(-¿-)› 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 [yes, I'm aware of the humorous ambiguity there] 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 [talk] [cont] ‹(-¿-)› 20:46, 28 July 2007 (UTC)