Wikipedia talk:Manual of Style/endash spacing

---

---

Purpose of this page

To relieve the overload of en dash stuff on WT:MOS, I'm going "sub" again to work out what I hope can become a consensus compromise on the spacing guidance for en dashes. It's a minor issue, that not many people seem to care a lot about, but a few people, including JeffConrad and PMAnderson, objected that the version in Noetica's recent new en dash version doesn't have consensus. And that one was replaced by one by GregL already, which nobody has said the like, either (and only Jeff and I and have quibbled with it, so that's a sign of how little most people want to deal with this). So, I'm going to work on a proposal here and invite Jeff and Greg and Noetica and PMAnderson and whoever else to tell me if it's one they can live with, and go from there. Dicklyon (talk) 05:43, 29 July 2011 (UTC)

The purpose of this page is a private discussion ground, where Dicklyon can ignore dispute and declare his preference consensus. i shoudl have knowen better than to respond to this trick. Septentrionalis PMAnderson 00:02, 2 August 2011 (UTC)

The purpose of this page is to avoid death threats from people who don’t appreciate WT:MOS being cluttered with this discussion (my comments included). JeffConrad (talk) 03:02, 2 August 2011 (UTC)

That would be the good faith explanation. (Literal death threats should be reported, but I don't think that's what you meant.) Art LaPella (talk) 03:36, 2 August 2011 (UTC)

I’ll concede that common courtesy and consideration for other editors may also be a factor. Recall the discussion on quotation marks not long ago, in which several people pleaded with us to take it elsewhere. I could swear that someone with a trombone case came to my door and said something to the effect of “Youse might wanna consider takin’ your silly-ass discussion down the hall.” He may have arrived in a black UN helicopter—I forget the details. JeffConrad (talk) 03:45, 2 August 2011 (UTC)

Noetica's version

The en dash in a range is always unspaced, except for times and dates (or similar cases) when the components already include at least one space.

• *23 July 1790–1 December 1791;    *14 May–2 August 2011
• 23 July 1790 – 1 December 1791;    14 May – 2 August 2011
• 10:30 pm Tuesday – 1:25 am Wednesday;   Christmas Day – New Year's Eve;   Christmas 2001 – Easter 2002
• 1–17 September;   February–October 2009;   1492? – 7 April 1556
• Best absorbed were wavelengths in the range 28 mm – 17 m.

GregL's version

For simple ranges where the en dash replaces the word “to” between two values (numbers like 20 and 30), the en dash is unspaced.

• The usual amount added to Olympic-size swimming pools is 20–30 liters.

It is best to add spaces on both sides of the en dash whenever the en dash does not directly separate two values (numbers like 20 and 30). This occurs when units of measure (millimeters and meters, for instance) appear on both sides of the en dash:

• Wrong: wavelengths in the range 28 mm–17 m
• Right: wavelengths in the range 28 mm – 17 m
• Wrong: 23 July 1790–1 December 1791;    14 May–2 August 2011 (inappropriately suggesting 1790–1 and May–2)
• Right: 23 July 1790 – 1 December 1791;    14 May – 2 August 2011
• Right: 10:30 pm Tuesday – 1:25 am Wednesday;   Christmas 2001 – Easter 2002;   1492? – 7 April 1556 (avoid suggesting Tuesday–1:35, 2001–Easter, and 1492?–7)

Editors should consider recasting complex measures; particularly where space is not at a premium (i.e. body text and not tables). Measures with units of measure (meters and millimeters or their unit symbols) on both sides of the en dash are generally more readable when fully written out:

• Wrong: wavelengths in the range 28 mm–17 m;   Christmas Day–New Year's Eve
• Right: wavelengths ranging from 28 millimeters to 17 meters;   from Christmas Day through New Year's Eve
• Right: from 23 July 1790 to 1 December 1791

JeffConrad's short and long versions

Approach 2

Dashes are spaced when both endpoints are full dates (e.g., some combination of numerical date, spelled-out or abbreviated month, and year):

• 23 July 1790 – 1 December 1791 not 23 July 1790–1 December 1791
• June 25, 1988 – April 3, 1989 not June 25, 1988–April 3, 1989

---

We’re done . . .

This didn’t seem to be what most folks wanted; allowing for other personal preferences, I might add

---

Approach 3

Dashes may be spaced in other ranges of dates for which both endpoints contain a space:

• 24 June–23 July 2010 or 24 June – 23 July 2010
• May 1–December 3 or May 1 – December 3
• Christmas Day–New Year's Eve or Christmas Day – New Year's Eve
• Christmas 2001–Easter 2002 or Christmas 2001 – Easter 2002

Dashes are always unspaced in ranges of dates, times, physical quantities, or similar, for which only one endpoint contains a space:

• 17–22 April not 17 – 22 April
• August 6–8 not August 6 – 8
• 5:45–6:30 p.m. not 5:45 – 6:30 p.m.
• 4–20 mA not 4 – 20 mA
• 24–105 mm not 24 – 105 mm

Dashes are always spaced in ranges of time that span more than one day:

• 10:30 pm Tuesday – 1:25 am Wednesday not 10:30 pm Tuesday–1:25 am Wednesday

Dashes may be spaced in other ranges of time for which both endpoints contain spaces:

• 10:30 pm–1:25 am or 10:30 pm – 1:25 am

Dashes may be spaced in other ranges for which one or both endpoints are long or complex, and for which closed-up use could be confusing; it is impossible to cover every case, so sometimes the editor must exercise judgment.

Dashes may be spaced in ranges of physical quantities for which both endpoints contain spaces, as when units are repeated for both endpoints or when the endpoints have different units:

• 28 mm–70 mm or 28 mm – 70 mm
• wavelengths in the range 28 mm–17 m or wavelengths in the range 28 mm – 17 m

Care should be taken when spacing en dashes in ranges of physical quantities because of possible confusion with the minus (−). Confusion seldom arises with ranges of dates because they are usually not subtracted; however, subtraction of physical quantities is a common occurrence. Because the minus is normally spaced, confusion can sometimes be avoided by closing up the dash:

• 20 Hz–20 kHz

Quantities with units or unit symbols on both sides of the dash are often more readable when written out using to, especially when the units are spelled out:

• wavelengths in the range 28 mm–17 m; sometimes better, wavelengths ranging from 28 mm to 17 m
• 20 Hz–20 kHz; sometimes better, 20 Hz to 20 kHz
• wavelengths in the range 28 millimeters – 17 meters; better, wavelengths ranging from 28 millimeters to 17 meters

Recasting may not be practical when space is at a premium (as in a table), or when the use is adjectival:

• 20 Hz–20 kHz response not 20 Hz to 20 kHz response or 20 Hz-to-20 kHz response

Complex ranges of dates are also often better recast:

• Christmas Day–New Year's Eve or Christmas Day – New Year's Eve; better, Christmas Day through New Year's Eve
• from 23 July 1790 – 1 December 1791; better, from 23 July 1790 to 1 December 1791

Dicklyon's new compromise proposal

The en dash in a range is usually unspaced; however, for complex starts and ends, when both components already include at least one space, spaces around the en dash can clarify that it is not intended to bind just the immediate elements. In particular, Wikipedia uses spaced en dashes in birth–death date ranges in biographies. In other complex ranges, choose between spaced and unspaced for clarity; rephrasing may be better than choosing in many cases.

• *23 July 1790–1 December 1791;    *14 May–2 August 2011
• 23 July 1790 – 1 December 1791;    14 May – 2 August 2011
• 10:30 pm Tuesday – 1:25 am Wednesday;  
• Christmas 2001–Easter 2002 or Christmas 2001 – Easter 2002
• 1–17 September;   February–October 2009;   1492? – 7 April 1556
• 20 Hz–20 kHz or 20 Hz – 20 kHz; sometimes better: 20 Hz to 20 kHz

Discussion

I've tried to keep it short, like Noetica's, while allowing the optional spaces, like Jeff's. Few red examples since not much is ruled out here, but several green ones to illustrate good choices.

So, what do you think? Which version? Or a new one? Dicklyon (talk) 05:43, 29 July 2011 (UTC)

Dick, I didn’t necessarily intend to include everything I wrote—I just wanted to illustrate most of the cases, as has been done in some past discussions. As I said, easier to trim a long one than guess at a short one. Your version is fine with me except for

• 14 May – 2 August 2011 not 14 May–2 August 2011

I would of course have

• 14 May–2 August 2011 or 14 May – 2 August 2011

And I would add

• 11:30 am–1:15 pm or 11:30 am – 1:15 pm

I think directly contrasting the prescribed and proscribed usages (or showing the acceptable alternatives) on the same line, as I have it here, is more clear, but it’s not a big deal. Some wording would need to be added saying why the full date and time ranges proscribe closed-up usage while the others do not, but one sentence would probably cover it.

Because the closed-up usage here finds almost universal acceptance in the US (which has a fair proportion of the world’s English-speaking population), it seems unreasonable to ban it here. And unless I’ve missed something, I haven’t seen much reason for doing so other than personal preference. I think it’s been mentioned that a reader might make the misassociation “May–2”, to which I would say “C′mon . . .”. To me, “14 May – 2 August 2011” first parses into two tokens: “14 May” and “2 August 2011”. Why? The groups are separated by 7/6 em while the components are separated by only 1/3 em. I can quickly put it together as “14 May through 2 August” and “in 2011”, but it does give me pause; with the closed-up usage, I initially parse the expression as it was intended. Is my analysis of this “better”? That’s of course impossible to answer. But my approach does find a lot of support, so it’s probably not out in left field. And again, Butcher, one of the main proponents of spacing the dash, has the spacing permissive rather than mandatory. And she follows with a caution on using it if there are any nearby spaced en rules used as parenthetical dashes—so it’s much more complicated than the US rules.

[Added in the interest of full disclosure] I should probably add that CGEU (s.v. dashes 2) says that the en dash is spaced when the words and numbers to be separated have internal spaces: the example give is of a full date: 1 July 1991 – 2 June 1992. I find this a bit confusing, because earlier in the same entry is the example quasi–open government policy, though the former is specifically mentioned in the context of prefixing an open compound (see, it’s not just American). CGEU apparently doesn’t sell quite as well as Butcher in Canada or the UK, but actually outsells it by quite a margin in the US. In any event, it qualifies as a major guide. So there—I′m not cherry picking my sources. JeffConrad (talk) 09:24, 30 July 2011 (UTC)

Citing authorities here can be challenging, because so few give examples such as we have here: CMOS and the M-W Manual for Writers & Editors show the closed-up usage for dates, but most other guides (including APA, GMAU, OSM, NHR, and TCS) only imply it by calling for closed-up use without mentioning exceptions (Turabian refers the reader to CMOS for the en dash).

Butcher is certainly a highly regarded work (she’s listed as a reference in CMOS and most other “major” guides), and she clearly refutes the suggestion that spaced usage is a Wikipedia invention. But CMOS is highly regarded as well, and like Butcher, is listed in almost all the “major” guides. And the snapshots of ASRs we’ve looked at suggest that CMOS sales match or exceed those of Butcher even in the UK, and do so by substantial margins in the US and Canada. So CMOS carries considerable weight, which I think most of us knew even without looking at ASRs

I agree with Noetica that ASRs aren’t everything, but they are a widely used measure of comparative sales. Does anyone have a better suggestion? Using ASR as a rough guide seems preferable to proponents of different practices simply screaming “My One True Guide is bigger than your crummy guide!!!” Recall that I gave some listings to address a claim about the “top” guides in the US; the top sellers at that instant turned out to be quite different from what had first been suggested. And even if ASRs fluctuate daily (which they do) and may not tell the entire story, a book with an ASR of 500 clearly has more followers than one with an ASR of 1,000,000.

Although some here would probably disagree, I’m not so arrogant as to insist that what I suggest is “right”. But it is considerably more than “I like it”, and I provide both a rationale and citation of support in highly respected well selling guides. Perhaps I make too much of “quality of the arguments”, but WP:CONSENSUS says what it says. And it makes sense to me. I’m not saying that numbers should not matter, but simply that something like “I hate em dashes” should not carry as much weight as something more reasoned.

Finally, I don’t suggest that the practice to which I am accustomed is the only one—my short proposal was only pro forma, to illustrate that I really had indicated my preference. But I do suggest that the spaced usage isn’t the only approach, either, especially when the closed-up usage is every bit as logical, and is at least as (arguably far more) common. My longer proposal reflects this. JeffConrad (talk) 07:48, 29 July 2011 (UTC)

Yes, I had a bug in putting 14 May–2 August 2011, not noticing that it wasn't full dates. And I can add the times. I'm willing to continue to take on the burden of proposing the version that you won't write (your "I didn’t necessarily intend to include everything I wrote"). The rest TL;DR. I'll see if anyone else comes with an opinion before I re-do it. Dicklyon (talk) 19:18, 29 July 2011 (UTC)

I think you misinterpreted my comment—I′d have been fine with proposing it as written, but had no objection to trimming it. I listed everything initially to illustrate the various usages. As I said, it’s easier to delete lines that it is to add them. I’d have been glad to carry the burden of revising it, and would be glad to pick it up from here if you would prefer–you’ve certainly done more than your share. I suspect the latest version will meet with some objection, and I have no problem being the one to address that, including revisions if needed. If you’re OK with it as it now stands, I’ll be glad to invite comment from others.

I’ve tried to provide a rationale above for allowing closed-up usage in some cases, so that part is done. I doubt that everyone will agree, but at least I have presented a case. JeffConrad (talk) 07:09, 30 July 2011 (UTC)

At the risk of belaboring a point: I ran across the following line in a well-known guide in a table defining mathematical symbols:

s²   Sample variance (unbiased) – denominator n – 1

My first reaction was “WTF?”, but after looking at it again, I realized the first rule was a spaced en dash used in place of an em dash (I’ve used a dash for the minus sign here because that’s what it looked like in the original). Now perhaps part of the problem is that this guide (APA) calls for and normally uses a closed-up em dash, so the en rule was unexpected. But it does illustrate that issues can arise from spacing, just as perhaps sometimes they can from closed-up use. The example is from Table 4.5, p. 121 of the 6th ed. (paperback). JeffConrad (talk) 08:44, 30 July 2011 (UTC)

<rant>Of course someone who thinks that being unbiased is by itself a desirable feature of an estimator won't give a damn about readability. Hell, do you know what the unbiased estimator of exp(−2λ) for a Poisson distribution is?</rant> ― A. di M.​_plé​^dréachtaí 00:24, 31 July 2011 (UTC)

Revised consensus candidate

The en dash in a range is usually unspaced; however, for complex starts and ends, when both components already include at least one space, spaces around the en dash can clarify that it is not intended to bind just the immediate elements. In particular, Wikipedia uses spaced en dashes in birth–death date ranges in biographies, and on complete time ranges, to prevent difficulties of interpretation. In other somewhat complex ranges, choose between spaced and unspaced for clarity; rephrasing may be better than choosing using dashes in many cases.

• Not 23 July 1790–1 December 1791;  but  23 July 1790 – 1 December 1791
• Not 10:30 pm Tuesday–1:25 am Wednesday;  but 10:30 pm Tuesday – 1:25 am Wednesday
• 14 May–2 August 2011;  or  14 May – 2 August 2011
• 11:30 am–1:15 pm;  or  11:30 am – 1:15 pm
• Christmas 2001–Easter 2002;  or  Christmas 2001 – Easter 2002
• 1–17 September;  February–October 2009;  1492? – 7 April 1556
• 20 Hz–20 kHz;  or  20 Hz – 20 kHz; sometimes better: 20 Hz to 20 kHz

---

Jeff, please say if this is OK; or edit it to make it OK. Then I will invite others to comment. Dicklyon (talk) 02:17, 30 July 2011 (UTC)

Dick, what can I say? Wording is clear and succinct, and the examples seem to cover. It looks fine to me, though I suspect some others may not like it so well. I made a couple of minor changes

• The asterisks were confusing after not, so I removed them.
• I tried to clarify what was intended by rephrasing (the italics are to show added words, not for emphasis).
• I made the spacing around but and or uniform; I used &ensp to make these padding spaces easy to distinguish from the nonbreaking spaces used within some of the compounds.
• I removed the italics from one instance of or; I originally used italics tp distinguish from example text, but with the typeface change from the templates, italics probably aren’t needed.

Great job as far as I’m concerned. JeffConrad (talk) 06:55, 30 July 2011 (UTC)

Yes, but why is this weird spacing disallowed: 23 July 1790–1 December 1791, but this one allowed: 14 May–2 August 2011. I think this will cause confusion. The current system of spacing the dash in all internally spaced dates is simpler, and more importantly, is already used in hundreds of thousands of places (like ... just about everywhere). Tony (talk) 08:35, 30 July 2011 (UTC)

I think we were distinguishing full date from shorter less complicated ones; we didn't want to allow the option of not spacing the full dates, as that could start to cause inconsistency in bios and such. But for the shorter ones, it seems a reasonable option to allow them to be unspaced. I don't have a strong opinion about this, and will change it if you and Jeff agree on which direction. Should we disallow unspaced month-day ranges as in 14 May–2 August? or allow unspaced everywhere, even in full dates? Either way would be more consistent; I'm not convinced that's less confusing. Dicklyon (talk) 16:27, 30 July 2011 (UTC)

I don’t find the unspaced usage with full dates all that weird (in fact I find just the opposite), though as I mentioned, I sometimes first see “1790–1” as “1790–91”. And I again point to my example of 14 May – 2 August 2011: at least for me, the initial associations (“14 May” and “2 August 2011”) are different from the ones intended. We could probably debate the logic of the two different approaches forever and conclude only that we’re both right, because both approaches find support in highly regarded guides. I think I could (and have) made the case that unspaced usage finds support in more of the top-selling guides than does the spaced usage, so apparently quite a few people have no problem with it.

One problem with most of the guides is the same as with the polling question: not enough examples were given. In retrospect, I’d have given more examples for polling, but juding from the reaction to my “long” proposal here, I might have been shot if I had done so. APA calls for unspaced usage, but gives no examples, and I haven’t yet found any date ranges actually used elsewhere in that guide. Of course, if usage is always closed up, arguably no examples are needed. Omission of examples perhaps does lead one to wonder whether all of the cases in my “long” proposal were considered. CMOS16 (at 6.78) gives the most examples of ranges that I’ve seen, and CMOS of course closes up in all cases. In any event, given the very strong popularity of APA and CMOS in the UK as well as Canada and the US, it seems unreasonable to disallow usage they advocate. As so many people have suggested, I think it ultimately boils down to the practice with which we are familiar.

I would have no problem allowing unspaced usage in full dates, but deferred to Tony’s earlier observation about the well-established usage here (and probably elsewhere) in bios.

For simplicity, recall my short proposal that was so simple no one noticed that I proposed it: en dashes are always unspaced, as called for in a plethora of guides that I cited. I recognize that this would never fly here, and probably should not, so I proposed what I have here.

And finally, on the logic once again: with a system of em dashes (spaced or unspaced) and unspaced en dashes, there is almost no chance of confusion with a minus, as in the example from APA that I cited above. Again, this isn’t to say that such a system is the only approach, but it is one that’s completely reasonable. JeffConrad (talk) 22:06, 30 July 2011 (UTC)

Jeff, maybe I didn't make myself clear before, but I don't really give a flying rat's ass about your logic, your guides, and your explanations of what you find better and why. Just tell me where your sticking point is on this one remaining tiny issue so we can find a version we can all live with. Dicklyon (talk) 23:28, 30 July 2011 (UTC)

Note that “both components already include at least one space” does not apply to 1492? – 7 April 1556. :-) ― A. di M.​_plé​^dréachtaí 23:37, 30 July 2011 (UTC)

Good point; I can remove the example, and I'm also open to suggestions as to what to say to make it OK. Dicklyon (talk) 23:42, 30 July 2011 (UTC)

Dick, there’s no call for this to get nasty—be assured that I can do that as well as anyone, and I usually don’t follow flying with just rat’s ass—ask any telemarketer who has been so foolish as to call me. For those who prefer brevity, I can also scream “I like it!” and “f—k you” and far worse things with the best of them, but that doesn’t strike me as appropriate here. My comments were directed more at Tony, who didn’t seem to like the idea of allowing spacing. I simply responded that what looked weird to him didn’t look weird to me.

I should think it obvious that I said your version as I slightly revised it is fine—if you look, I said it looks great, and complimented you on your effort. What else do I need to say? Again, I still like the long version that I proposed—otherwise I wouldn’t have put the effort into writing it. I concede that it may have been longer than some would like, so I raised only minor objection to your shortened version. I had thought we were now in agreement. Which is why I don’t understand the hostility.

Getting to a resolution: the version just above is fine with me—there is no sticking point. But I’m not even sure what the current proposal is—you seem to have suggested being consistent by requiring either unspaced or spaced usage across the board. Though I’m obviously fine with the former, I have a strong feeling that it will never fly with Tony and Noetica, and perhaps it should not; with the latter, everything I have suggested gets thrown out, so of course I don’t support it. I had proposed what I thought was a compromise, and it now seems that we’re back to “my way or the highway”. JeffConrad (talk) 00:18, 31 July 2011 (UTC)

Jeff, it's good you can sling the nastiness with me. But all I want is a simple answer. I'm not advocating for any position. I want you and Tony to tell me if there's a version you'll both support, but so far I don't know from either of you whether I should move to more permissive (allowing closing up full dates) or more prescriptive (saying not to close up 14 May–2 August). I know Tony prefers more spaced, and you prefer more closed up; if either of you will propose an answer that you think the other will accept, we'll be about done. Except for the bug the A. di M. brought up, which will require another bit of negotiation, I'm sure (I'd fix it by removing the example, and leaving the rest). Dicklyon (talk) 07:16, 31 July 2011 (UTC)

I have no problem allowing closed-up use in full-date ranges, but it seemed to me that Tony’s objection was to barring 23 July 1790–1 December 1791 but permitting 14 May–2 August 2011. With regard to consistency, he has a point; if consistency is the main concern, I would address it by allowing closed-ed up usage for full dates and times, with perhaps a recommendation to space the dash in full-date ranges in bios as a Wikipedia convention established independently of dash rules.

My biggest objection was with requiring spacing in 20 Hx – 20 kHz, followed closely by 14 May – 2 August 2011. What looks weird is in they eye of the beholder; spacing the dash in the latter example here looks just as weird to me as the unspaced dash in a full-date range does to Tony. But if consistency is required and spacing is mandated the second example, it’s tough to make the case for allowing spacing in ranges of physical quantities, and so on, putting us back to where we started. Things can be simple if spacing is either always banned or always required; the former isn’t likely to fly, and the latter would require 4 – 20 mA which is at odds with just about all recommendations. And then what of New York–London flight? I don’t think the complexity is unmanageable—we’re simply talking two different but widely used practices, and I think those accustomed to either will use them naturally. But I suppose those new to dash might not find it so easy.

So again, if consistency is required, I’d allow closed-up use for all ranges. But I can’t support mandating the spacing in 14 May–2 August 2011. JeffConrad (talk) 22:35, 31 July 2011 (UTC)

Thanks, Jeff, that's clear enough. Then it's up to Tony; if he wants consistency, he can get there by allowing closed-up full dates. If having spaces in full dates is important to him, he can give up consistency between full and shorter date ranges. Or he can stick and we have no overlap between your positions, and we stick with the current version by Greg. Dicklyon (talk) 22:48, 31 July 2011 (UTC)

In case it helps, here’s how I’d address it, including A. di M.’s comment:

• 23 July 1790 – 1 December 1791, not  23 July 1790–1 December 1791
• 10:30 pm Tuesday – 1:25 am Wednesday,  not  10:30 pm Tuesday–1:25 am Wednesday
• 1492? – 7 April 1556;  not  1492?–7 April 1556
• 14 May–2 August 2011;  or  14 May – 2 August 2011
• 11:30 am–1:15 pm;  or  11:30 am – 1:15 pm
• Christmas 2001–Easter 2002;  or  Christmas 2001 – Easter 2002
• 1–17 September;  February–October 2009;
• 20 Hz–20 kHz;  or  20 Hz – 20 kHz; sometimes better: 20 Hz to 20 kHz

I like what’s wanted first, but it’s not a big deal. If necessary, the first three could be changed to or. If that were done, the spaced and unspaced versions should all be presented in the same order. JeffConrad (talk) 23:02, 31 July 2011 (UTC)

I can't think of any rule which would allow 20 Hz–20 kHz, Christmas 2001–Easter 2002, 11:30 am–1:15 pm, 14 May–2 August 2011 but not 1492?–7 April 1556, 10:30 pm Tuesday–1:25 am Wednesday, 23 July 1790–1 December 1791. Understanding the MOS shouldn't be like a game of Mao... ― A. di M.​_plé​^dréachtaí 23:20, 31 July 2011 (UTC)

I can’t think of any single rule, either, which is why I suggested stating these cases as exceptions. The simplest rule is to call for closed-up usage in all cases, which some people here will never go for. Absent that, it necessarily becomes more complex. Another approach, of course, is to make spacing optional in all cases in which both endpoints contain spaces (and something to cover your case). I’m OK with any of these. The extra complexity arises mainly from insisting on one personally preferred practice—you pays yer money and you takes yer choices. JeffConrad (talk) 00:14, 1 August 2011 (UTC)

Thinking some more, I suppose the rule could be to space when the combination to be joined becomes too long or just too complex, as Dick originally suggested. Now this would be open to interpretation, but the examples should clarify. In any event, I don’t think anything can be completely formulaic—judgment may sometimes be needed, as Dick suggested and as I suggested in my “long” version. I don’t think that makes it unmanageably complex. JeffConrad (talk) 00:23, 1 August 2011 (UTC)

Jeff, thanks, I think that softening may let us find a path to consensus. Maybe Tony will show up and tell us what he thinks. My 5-way proposal is probably moot if we agree to allow some inconsistency via complexity and length, if Tony will go for that. Dicklyon (talk) 00:41, 1 August 2011 (UTC)

Complexity? Compared with spelling? I have the SOED handy on CD-ROM, and two other British guides. But if I don’t first realise I need to look . . . What we’re talkin’ here is a piece of cake by comparison. JeffConrad (talk) 00:53, 1 August 2011 (UTC)

• This is the sticking point: 14 May–2 August 2011;  or  14 May – 2 August 2011. So we've had a nice simple rule until now concerning dates: if there's an internal space in either or both elements, space the dash; it works consistently, logically, and intuitively for full dates and partial dates. Editors (and readers) are used to seeing this applied for dates in probably millions of locations in en.WP. This new proposal to "loosen" the logical consistency of this rule risks confusing WPians. What is the advantage? While it purports to make things easier by allowing two styles (easoer to comply?), it does this by creating another boundary that editors have to learn. Tony (talk) 02:33, 1 August 2011 (UTC)

• You're saying we need to rule out closed up 14 May–2 August 2011, right? If I got that right, then there's no intersection of acceptable positions between you and Jeff. No problem, I can just retire from this now, and we'll keep Greg's version, unless and until someone finds a way to move toward a more complete consensus to include Jeff. Thank you all for your efforts. Dicklyon (talk) 03:25, 1 August 2011 (UTC)

Tony, we’ve focused on dates, but what would you do with “20 Hz–20 kHz”? JeffConrad (talk) 04:31, 1 August 2011 (UTC)

The question is kind of moot now, isn't it? Tony was a fan of spaced en dash whenever either component had spaces, but had compromised on this up to the point of dates. Dicklyon (talk) 15:57, 1 August 2011 (UTC)

Be careful with moot—it generally has a different meaning in BrE than in AmE . . . I asked the question because Tony had said

Agree strongly for dates, which has been just about universal on Wikipedia for a long time (3 June 1816 – 18 August 1840}, avoiding the squashing of the central elements, which would often be harder to read (3 June 1816–18 August 1840). There are probably more than a million examples of the spaced en dash in full dates on WP, and it seems to be widely accepted. For en dashes between compound words, I agree it should now be optional, at editors’ discretion (“New Zealand – South Africa” or “New Zealand–South Africa”).

I think inferring from this that Tony would be OK with “20 Hz–20 kHz” would be pushing it. And absent allowing this, there would be no change from the current position, and accordingly, no compromise. JeffConrad (talk) 21:30, 1 August 2011 (UTC)

Actually, since Tony has just objected to Greg's version, too, it seems it makes nobody happy on either end. So I've taken it back to Noetica's majority-consensus version, which should be OK unless/until we find some better consensus. Dicklyon (talk) 15:57, 1 August 2011 (UTC)

Agree. Material here may serve as a starting point for future discussions. JeffConrad (talk) 21:30, 1 August 2011 (UTC)

A. di M.'s version

En dashes in ranges are normally unspaced, but may be spaced for clarity when at least one of the endpoints^* contains a space:

• 23–27 July, not 23 – 27 July; 23 July – 5 August (or 23 July–5 August).
• June–July 2010; December 2010 – January 2011.
• 1989–2001; 1492? – 7 April 1556
• 10:30–11:30 a.m.; 10:30 a.m. – 2:30 p.m..
• 1–50 cm; 50 cm – 20 m.

Avoid the latter usage when the range modifies a following noun: 100 MeV–10 Gev muons, not 100 MeV – 10 Gev muons. In such cases, rewording to avoid dashes entirely might be even better: muons from 100 Mev to 10 Gev.

* Not counting elements before the start or after the end intended to apply to both endpoints, as July in 23–27 July or July 23–27.

---

― A. di M.​_plé​^dréachtaí 00:04, 31 July 2011 (UTC)

I’m OK with the wording except for “one of the endpoints”, because except for your special example, I can’t see any reason to space. If the spacing is optional when both endpoints contain spaces, it’s not obvious from the examples (e.g., is 23 July–5 August OK?). Whatever is intended, I prefer to clearly show right/wrong usage or acceptable options using the same examples except for spacing, so the reader doesn’t need to guess. The exact wording isn’t that important. The issue again seems to be whether we require spacing when both endpoints contain spaces, require closed-up usage across the board (a nonstarter), or permit either approach except for full dates, as I have proposed. With that resolved, the details should be easy. JeffConrad (talk) 00:42, 31 July 2011 (UTC)

Which one is the “special” example? (The only difference it makes if one is replaced by both is that the latter would disallow 1492? – 7 April 1556. Anyway, I'm replacing one with at least one just in case someone took it to mean one and only one, and adding an example like yours. ― A. di M.​_plé​^dréachtaí 01:23, 31 July 2011 (UTC)

This seems generally OK, though as I mentioned, I prefer Dick’s version mainly because of the layout. It’s no a big deal though—I’m more about the concept than the specific expression, provided the latter is clear.

The problem with one is that spacing the dash would be suggested as an option with 23 – 27 July, June – July 2010, or 4 – 20 mA, which I don’t think is intended. One way to handle the special case would be something like

• 23 July – 5 August 2009 or 23 July–5 August; but 1492? – 7 April 1556, not 1492?–7 April 1556

though a few words of explanation might be needed. And I honestly have no problem with the closed-up usage in all cases here. One more thing: would you require spacing in ranges of full dates and times? JeffConrad (talk) 02:11, 31 July 2011 (UTC)

I'd consider the ‘operands’ of the dash in 23–27 July to be 23 and 27, and July to be ‘factored out’, if you will. I know that's not the only possible interpretation, and that's why I added the footnote to explain what I exactly mean by endpoint, to prevent X-treme wikilawyering. I have no strong opinion on whether to allow 1 January 1999–31 December 2000. ― A. di M.​_plé​^dréachtaí 10:05, 31 July 2011 (UTC)

What are our options?

Currently, on WP:MOS, we have Greg's version, which encourages spacing:

• It is best to add spaces on both sides of the en dash whenever the en dash does not directly separate two values.

I think this is to the liking of the Brits of Aussies, even though it was written by an American. Maybe it's OK to Jeff and A. di M., too? It's not clear to me; but if it is, we can stop. If it's not, let's keep looking for a version that nobody objects to.

Among the options are:

a. Just rephrase Greg's a bit, to say it's an option, not "best".

Or take my "revised consensus candidate" that Jeff liked, but patch up the problems that Tony and A. found. That means a couple of choices have to be made:

b. Make spacing in 23 July 1790 – 1 December 1791 optional, as it is in 14 May–2 August 2011; and remove the example 1492? – 7 April 1556 that doesn't fit the description. (I think Jeff would go for this, but maybe Tony wouldn't).

c. Make spacing in 14 May – 2 August 2011 required, as it is in 23 July 1790 – 1 December 1791. And again remove the example 1492? – 7 April 1556 that doesn't fit the description. (Tony would probably see this as an improvement, unless he doesn't want to see that odd example removed, but I don't think Jeff would like it)

d. Like b but extend optionality to a wider class of cases, as A. di M. proposes, to include 1492? – 7 April 1556

e. Like c but extend optionality to a wider class of cases, as A. di M. proposes, to include 1492? – 7 April 1556

If we go with d or e we need to pick a wording, hopefully not needing a footnote to clarify what we mean, but we can deal with that.

So how do we determine if there's an option in here that we can all live with? That's all I'm trying to find. If each person who cares will give me a string of 1–4 letters indicating the cases they can accept, we can do a set intersection and see if it's non-empty. If it's empty, we stick with Greg's version by default, which is not so bad, but prevents us from claiming that we've found consensus. For example, I'll go first (and I'm going to try to make some money off-wiki, with a side bet about how many lines Jeff's response will take):

• abcde – that is, I'm OK with any of the five outcomes. Dicklyon (talk) 21:37, 31 July 2011 (UTC)
• bd, if I understand them. But with b, wouldn’t the spacing already be optional for all cases? In any event, I’ve shown a possible example in the section above. JeffConrad (talk) 22:56, 31 July 2011 (UTC)

  With b, you wouldn't be allowed to space 1492? – 7 April 1556 because it's not the case that “both components already include at least one space”. ― A. di M.​_plé​^dréachtaí 23:05, 31 July 2011 (UTC)

  Damn! Only two lines; you're costing me money, Jeff. Dicklyon (talk) 23:16, 31 July 2011 (UTC)

• debca, in this order. ― A. di M.​_plé​^dréachtaí 23:02, 31 July 2011 (UTC)
• None of the above. All of these are already "optional"; it's only a matter of how they get cleaned up. Therefore IMO "best" is the proper wording: that suggests that you don't have to do it that way, but if you don't someone may be along after you to fix it up. I don't like Christmas 2001–Easter 2002 or 20 Hz–20 kHz; I find them jarring when I read them as inline text. (Not so much in a table column with parallel ranges.) 11:30 am–1:15 pm isn't so jarring, but I see no reason not to space it as well, if only for consistency and to avoid arguments over whether s.t. is more like 11:30 am–1:15 pm or more like 20 Hz–20 kHz. If we start giving lots of options, I'm afraid we'll just make things messier and spark more arguments. — kwami (talk) 06:43, 1 August 2011 (UTC)

• I agree with kwami. Greg L (talk) 17:00, 1 August 2011 (UTC)

Tony's sticking point is that he doesn't want the closed-up version to be an option in date ranges. He's not the only one who has pushed back on too many options. Even's Greg's version was not to his liking, even without softening the "best". His response would be just e probably. Dicklyon (talk) 17:08, 1 August 2011 (UTC)

Tony’s opinion—like that of PMA and my own—has to be considered when discerning a consensus. Greg L (talk) 17:51, 1 August 2011 (UTC)

• abd. There is no reason, and Jeff Conrad's extensive citations show there is little if any authority in style guides, to require these spaces. They serve no function; 20 July 2008–30 July 2011 is not ambiguous in any practical sense. There is therefore no consensus that these are "best" practice, and the claim that they are should be removed. Septentrionalis PMAnderson 20:00, 1 August 2011 (UTC)

Thanks; your position on dates was previously difficult to discern. The use of spacing in dates was almost unanimously agreed to for WP style (with acknowledged exceptions of you, Jeff, and one other guy); most of the rest has been changed to unspaced, per "The en dash in a range is always unspaced, except for times and dates (or similar cases) when the components already include at least one space." So far, no better consensus is in sight, with people wanting to move different directions. Dicklyon (talk) 20:24, 1 August 2011 (UTC)

Where there is no consensus, we should be silent. This will have the practical advantage of brevity. Septentrionalis PMAnderson 20:48, 1 August 2011 (UTC)

Indeed. And we did have good consensus for spaced in dates and unspaced in most other places, but with some fuzziness in between. If you'd like to push to say less about "always unspaced", feel free. Based on my attempts here, I think it will be hard to find a more brief or acceptable alternative. Dicklyon (talk) 21:44, 1 August 2011 (UTC)

LThe poll is here; WT:Manual of Style/dash drafting, Section 6b. Some support, some oppsoe, some are hestiant. There is no point to futher discussion to anybosdy who invents his polls. Septentrionalis PMAnderson 00:06, 2 August 2011 (UTC)

file names and categories

We had a note on discouraging dashes in file names and categories. I was removed while I was away, so I didn't see the discussion. I think it's a good idea, however.

1. One of the complaints about dashes is that they're awkward to enter. That's irrelevant when you can just use a hyphen and someone will clean up after you. (We can even leave a note to that effect: AWB cleanups will convert double hyphens between words to em dashes, and double hyphens between digits to en dashes. We can make requests of for other AWB conversions, such as spaced hyphens etc.) However, one place where you have to get it right is in file names. That really is a pain if you don't have a good way to enter them. Categories sort themselves, so are a lesser issue.
2. If you set up a cleanup conversion, that may affect file names or categories; if you have a line to revert changes to them, it may change existing dashes to hyphens. Again, it's basically a pain, and there's no benefit: file names are not meant to be seen, and they're often gibberish anyway, so it doesn't matter how they're formatted. Again, categories are not as extreme.

I would suggest asking people not to use dashes in file names at least, and maybe cats. We could have a bot move those which do have them. For those at Commons, we could provide redirects with hyphens. — kwami (talk) 06:30, 1 August 2011 (UTC)

This subpage is intended only for discussing the spacing issue. Probably you want to get a better audience for this other issue. I agree we should say something about file and cat names, but probably that's not an issue for MOS, at least not for the main MOS sections that are about article content and style. Dicklyon (talk) 06:35, 1 August 2011 (UTC)

As for files, most of them are on Commons, so this discussion doesn't even belong to en.wiki. (And do people actually type file names to include them in articles, as opposed to copying and pasting them?) As for categories, that depends on whether they've finally fixed the bloody category redirects. ― A. di M.​_plé​^dréachtaí 13:49, 1 August 2011 (UTC)

Memorializing the facts regarding other MOSs

Click here: Wikipedia talk:Manual of Style/endash spacing/Other manuals of style, to edit the lede of this section, which is actually a transcluded page.

Before we go too far with discussions as to what we personally like, what we don’t like, and declaring it’s my way or the highway based upon personal preferences, why not we first assemble a reference library of established manuals of style?

Greg, I can do this, but it’s gonna be l-o-o-o-ng? Are you sure you really want me to do so? JeffConrad (talk) 21:33, 1 August 2011 (UTC)

Thanks for your summary, below, Jeff. I’m sure I have an hour into what I added. Do you have it in you to provide the complete text of what the Chicago Manual of Style says regarding en dashes, or would that take more than an hour? BTW, (I’m apparently *new* to this because some acronyms make no sense to me), a quick Google search on “NHR” came up with Network Hardware Resale and Neuro Hypnotic Repatterning. Can you spell out some of these things or add a glossary? Greg L (talk) 01:14, 2 August 2011 (UTC)

• The abbreviations are listed on Noetica’s page, transcluded at the top of this page.
• I think including everything CMOS has to say about en dashes would violate copyright, but I guess I’d be safe with the examples showing closed-up usage in ranges with spaced endpoints (under 6.78 in the 16th ed.). JeffConrad (talk) 01:26, 2 August 2011 (UTC)

• We’re having a scholarly discussion out of articlespace comparing and contrasting how different manuals of style handle en dashes. For the purposes of what we are doing, it is fair-use. The World Book Dictionary is thousands of pages; I quoted a thousandth of a single percent of it by quoting what it says on en dashes. Besides, I just now made this whole thread its own page, which is now transcluded to here on this page. When we are done with this discussion, we can blank the page so it isn’t discoverable by Google. What does CMOS say on the issue? Greg L (talk) 02:09, 2 August 2011 (UTC)

  You can make any page “undiscoverable by Google” using {{NOINDEX}}. (Though IANAL so I'm not sure it makes any difference wrt copyright. IIRC sometimes old revisions of pages are deleted for copyright reason, so I suspect blanking the page might be not enough either.) ― A. di M.​_plé​^dréachtaí 10:54, 2 August 2011 (UTC)

I’ve got the following:

World Book Dictionary

From The World Book Dictionary, 1976, Pg. 28

---

1. In place of to between numbers or dates.
   
   You will find helpful information on pages 27–36.
   The years 1930–1936 were hard ones for the family.

   
   

2. Between proper names showing terminals of airplanes.
   
   The New York–Chicago flight was late.

---

I hope others here can cite the advise provided by other manuals of style. Then perhaps we can discuss what we think is correct, in error, in conflict, or is not addressed. After that much is done, I think our task at hand towards crafting our own MOS will be easier. Greg L (talk) 18:45, 1 August 2011 (UTC)

Webster’s Style Manual

From Webster’s New Encyclopedic Dictionary, 1993, Pg. 1335

---

En Dash

15. En dashes appear only in typeset material. The en dash is shorter than the em dash but slightly longer than the hyphen, and it is used in place of the hyphen in some situations. The most common use of the en dash is the equivalent to “(up) to and including” when used between numbers, dates, and other notations that indicate range.

1984–85
8:30 a.m.–4:30 p.m.
GS 12–14
Monday–Friday
ages 10–15
levels D–G
35–40 years
pages 128–34

NOTE: The use of the en dash to replace the hyphen in such cases, although urged by most style manuals, is by no means universal. Writers and editors who wish to have en dashes set in their copy need to indicate on their manuscripts which hyphens should be set as en dashes, and this need to mark en dashes can obviously be an inconvenience and an invitation to errors. However, many writers and editors prefer to use en dashes because of the visual clarity they provide between numbers and because of the distinction they make between en dashes used to mean “to” and hyphens used to connect elements in compund words.

16. Publishers make varioius uses of the en dash, and no one set of rules can be said to be standard. Some common uses of the en dash include using it as a replacement for the hyphen following a prefix that is added to an open compound, as a replacement for the word to between capitalized names, and to indicate linkages, such as boundaries, treates, or oppositions.

pre–Civil War architecture
the New York–Connecticut area
Chicago–Memphis train
Washington–Moscow diplomacy
the Dempsey–Tunney fight

---

Contributed by Greg L (talk) 19:46, 1 August 2011 (UTC)

---

Chicago Manual of Style

The Chicago Manual of Style, 16th ed., at 6.78, gives the following examples of en dashes in ranges whose endpoints contain spaces:

• Join us on Thursday, 11:30 a.m.–4:00 p.m., to celebrate the New Year.
• I have blocked out December 2009–March 2010 to complete my manuscript.
• Her articles appeared in Postwar Journal (3 November 1945–4 February 1946).

Merriam-Webster’s Manual for Writers & Editors

Merriam-Webster’s Manual for Writers & Editors gives the following examples, under En Dash and Long Dashes, 13:

• September 24–October 5
• 8:30 a.m.–4:30 p.m.

MLA Handbook

The MLA Handbook for Writers of Research Papers, 7th ed., under 3.5.6, Inclusive Numbers, gives

Do not abbreviate ranges of years that begin before AD 1.

748–742 BC

143 BC–AD 149

Editing Canadian English

Editing Canadian English, 2nd ed., shows closed-up usage under Compounds with en dash, at 2.27

pages 30–35 or 30–35

member of the provincial assembly 1942–48

a range of 23%–43%

An example of a full-date range is given under Documentation, Parliamentary records, at 10.82

March 9, 1983–April 21, 1983

Unlike TCS, ECE uses the spaced en dash rather than an em dash for a parenthetical dash. JeffConrad (talk) 01:58, 3 August 2011 (UTC)

New Hart’s Rules

New Hart′s Rules, under 4.11.1, En rule, gives

Use the en rule closed up in elements that form a range:

pp. 22–36 1939–45 Monday–Saturday 9:30–5:30

Under 10.7, Abbreviations with dates, it further says

With a span of dates c. must be repeated before each date if both are approximate, as a single abbreviation is not understood to modify both dates:

Philo Judeas (c.15 BC–c. AD 50)

[Comment: this is very odd, with no space after the first c. and a space after the second c. The BC–c looks like a catalogue number. Hart on a bad day?] Tony (talk) 07:43, 2 August 2011 (UTC)

Butcher’s Copy-Editing

Butcher’s Copy-Editing, 4th ed., gives the following, under 6.12.1, En rules:

En rules meaning ‘to’ and ‘and’ are usually unspaced: theocratic–military, chapters 8–9, 101–50. However, spaced en rules may be used between groups of numbers and words to avoid implying a closer relationship between the words or numbers next to the en rule than between each of these and the rest of its group:

6.6–8  but  6.6 – 7.8

September–January  but  18 September – 19 January

1215–1260  but  c. 1215 – c. 1260

But these spaced en rules should be used cautiously, especially if there are also parenthetical dashes, as the reader may not be able to tell one from the other; and it may be better to substitute ‘to’ in such cases.

---

Added by JeffConrad (talk) 02:21, 2 August 2011 (UTC)

Jeff’s quick summary

A quick review of the guides I have (plus BCE via Google Books) gives a tally something like this:

• Call for closed-up usage, many examples: CMOS
• Call for closed-up usage, few examples: NHR
• Call for closed-up usage, discourage dash with spaced endpoints, few examples: OSM
• Show closed-up usage, few examples: ECE, GPO, MWG, MWSM, MWM, Tur, MLA, MLAM (MLA and MLAM use hyphens)
• Call for closed-up usage, no examples with spaced endpoints: WIT
• Call for closed-up usage, no examples at all: APA
• Show closed-up usage, no examples with spaced endpoints: GMAU, TCS, Garner’s Dictionary of Modern Legal Usage
• Permit spaced usage when endpoints contain spaces, several examples: BCE
• Call for spaced usage when endpoints contain spaces, few examples: CGEU
• Call for spaced usage in number range if symbol changes, few examples: EUESG

In some cases, “few examples” means “one example”. Now I could enter some of the specifics, but doing so would entail quite a bit of work, so I don’t want to waste the time unless it will serve some purpose. JeffConrad (talk) 00:45, 2 August 2011 (UTC)

Thanks for the summary, Jeff. To further summarize, the MOS guidelines recently adopted by WP editors (and restored by me a couple of times after being mess with) include a little bit of the "spaced usage" from BCE, CGEU, and EUESG, but otherwise follow the "closed-up usage" of the other guides. Finding a direction to move from there that everyone can live with has proved intractable, so that's where we are. Only a very few editors have said they can't agree with it (see Wikipedia_talk:Manual_of_Style/dash_drafting#Spacing_of_endashes, 6b); only JeffConrad, Pmanderson, and Macwhiz disagree with spacing dates (Pmanderson's response there was too confused to be interpretable with respect to dates, but we finally know); only JeffConrad and Pmanderson continue to object to Noetica's consensus compromise version, as far as I've heard. Please correct me if I've missed anyone; Pmanderson keeps telling me there are lots (maybe some who said they're OK with spaced usage in dates didn't really mean they're OK with saying so in the MOS?). Noetica and Tony and probably others (sometimes including me, when I'm not in a generous mood, which is usually) are not willing to back down on requiring spaced usage in date ranges, a usage that was accepted by the other 23 editors there, if I've counted correctly, since that would start to introduce inconsistency and confusion into biographies and such, where presently things are in pretty consistent shape, based on guidelines that have been in place for quite a few years. Jeff, thanks again for your earnest interest in this topic and process, even if we couldn't come to terms; and thanks for agreeing that my revert to Noetica's version was the right move for now. I appreciate Greg's attempt to help with what he thought was a good compromise, but it didn't really help on either end. Dicklyon (talk) 03:26, 2 August 2011 (UTC)

Evaluating our MOS in light of other manuals of style

• So let’s talk about how the current guidelines on MOS covering recommended practices for en dashes. I’m all for allowing as much latitude in our MOS as is backed up by established, well-respected manuals of style. Does anyone object to any practice that our MOS currently recommends or permits that is not mentioned in the other manuals of style? Does anyone object to a practice that is forbidden or frowned upon in our MOS that other respected manuals of style recommend? If neither of these, then I move that we are done here. If one or both of these, then let’s talk about them and resolve the issue(s). Greg L (talk) 04:09, 2 August 2011 (UTC)
  • I clearly disagree with requiring spacing in a range in which the endpoints contain spaces, and the sources seem to suggest that the current guideline is swimming against the current.
  • I think Dick and I would restore use of an en dash in place of a hyphen in a compound that contains spaces. The current guideline allows this use with prefixes (e.g., pseudo–page transition) but does not mention a use such as San Francisco–based company. Although the latter isn’t specifically proscribed, I could imagine use leading to arguments.
  • A usage that was not considered but that finds support in APA and CMOS is something like University of Wisconsin–Madison. Offhand, I can’t think of a better alternative. Again, usage isn’t currently proscribed, but it would seem desirable to largely preclude argument.

I can add some examples of the second use from the sources if you wish. JeffConrad (talk) 05:26, 2 August 2011 (UTC)

Jeff, the current guideline isn't "requiring spacing in a range in which the endpoints contain spaces," except in the case of dates (or similar cases, by which I think it means times). "The en dash in a range is always unspaced, except for times and dates (or similar cases) when the components already include at least one space." I don't know why the example "28 mm – 17 m" got left in there; I just noticed it's not as simple as I thought. Oh, well, nobody much objected besides you. As for wanting en dashes in San Francisco–based, yes, I'd like that, but it's no big deal; same with the U W–Madison. You could probably find a consensus to add those if you work at it. I'm not encouraged to work on this any more, personally. Dicklyon (talk) 05:36, 2 August 2011 (UTC)

What other “ranges” are there? As someone mentioned earlier, the “or similar” is the gotcha, which probably can be read as including “28 mm – 17 m” (I think A. di M. was the only one to raise the issue). In any event, that’s why I specifically asked Tony about this above. I haven’t received an answer, so I assume he would require spacing.

In any event, just for the dates, the current guideline is out in left field. My count above is 15–3 (I recognize three Australian usage guides were also cited in a previous discussion); if global sales are factored in using any reasonable estimate, the balance is even more skewed. I seem to be the only one who considers anything other than personal preference.

I didn’t want to invest time on this in the first place, because as I repeatedly said, unless there is agreement in concept, no number of drafts matter. And my conceptual question (one of them, anyway) was simple: would people entertain making spacing optional in ranges whose endpoints contain spaces? And the answer apparently was “No”, as Tony indicated above. Had that question been asked first, we could have avoided all the effort here. I know you don’t seem to like that approach, but in over 30 years of dealing with stuff like this, I don’t I’ve ever seen things turn out otherwise—believe me, I don’t do things just to be difficult.

As for my first comments here, GregL asked a question and I responded. JeffConrad (talk) 06:20, 2 August 2011 (UTC)

FWIW, I think it is clear that the standard practices as disclosed by other manuals of style is that date ranges have no space beside the en dash. However, Butcher’s Copy-Editing gives this example: 18 September – 19 January and provides excellent reasoning: However, spaced en rules may be used between groups of numbers and words to avoid implying a closer relationship between the words or numbers next to the en rule than between each of these and the rest of its group.

I think since Wikipedia is the encyclopedia anyone can edit, we will get an ocean of editors. Some contributors to Wikipedia will be highly experienced writers and others won’t. Many highly experienced editors will follow the examples given by the widely available Chicago Manual of Style and Merriam-Webster’s Manual for Writers & Editors (December 2009–March 2010; 3 November 1945–4 February 1946; September 24–October 5) where no space is along side the en dash. I strongly suggest that WP:MOS be written so it is inclusive (permits) the full gamut of practices generally recommended by well-respected manuals of style.

The only caveat I have regarding this *be inclusive and embrace diversity*-angle is that if there is practice on Wikipedia that has become a de facto standard of sorts, such as spaces beside the en dash in the first sentence of biographies (like our Winston Churchill article), then we should prescribe that in MOS for consistency. Greg L (talk) 15:50, 2 August 2011 (UTC)

Greg, wrt "I strongly suggest that WP:MOS be written so it is inclusive (permits) the full gamut of practices generally recommended by well-respected manuals of style," this approach has been pretty roundly rejected. We call it "chaos". There has been a lot of sentiment for having the MOS specify a house style for WP, drawn from good guides, but not just allowing everything that any of them do. That's sort of the whole point of the discussions around WP:ENDASH, and it was very strongly supported, even by people like Jeff who don't like every provision that came out of the discussion. Dicklyon (talk) 15:54, 2 August 2011 (UTC)

(edit conflict)Anyway, if Wikipedia has not collapsed because it allows both American and British spelling, both Mmmm DD, YYYY, and DD Mmmm YYYY dates, both the Oxford comma and the lack thereof, both unspaced em dashes and spaced en dashes as sentence-level punctuation, both dx and dx for differentials, etc., it's not going to collapse if 3 November 1945–4 February 1946 and 3 November 1945 – 4 February 1946 are both allowed, either. IOW, free variation in natural languages is no more “chaos” than many other features of them. (That said, if there were consensus to forbid either of those formats I'd have no problems with using the others exclusively in Wikipedia articles.) ― A. di M.​_plé​^dréachtaí 16:20, 2 August 2011 (UTC)

FWIW, I think it is clear that the standard practices as disclosed by other manuals of style is that date ranges have no space beside the en dash. However, Butcher’s Copy-Editing gives this example with spaces: 18 September – 19 January and provides excellent reasoning: However, spaced en rules may be used between groups of numbers and words to avoid implying a closer relationship between the words or numbers next to the en rule than between each of these and the rest of its group. I personally agree 100% with that line of reasoning and think the spaced construction is easier to read. I think Butcher’s has nuanced, thoughtful guidance; I’ll have to go get myself a copy.

I think since Wikipedia is the encyclopedia anyone can edit, we will get an ocean of editors. Some contributors to Wikipedia will be highly experienced writers and others won’t. Many highly experienced editors will follow the examples given by the widely available Chicago Manual of Style and Merriam-Webster’s Manual for Writers & Editors (December 2009–March 2010; 3 November 1945–4 February 1946; September 24–October 5) where no space is along side the en dash. I strongly suggest that WP:MOS be written so it is inclusive (permits) the full gamut of practices generally recommended by well-respected manuals of style.

The only caveat I have regarding this *be inclusive and embrace diversity*-angle is that if there is practice on Wikipedia that has become a de facto standard of sorts, such as spaces beside the en dash in the first sentence of biographies (like our Winston Churchill article), then we should recommend that as a preferred practice in those instances for the sake of consistency.

BTW, I strongly suggest that my last bit of advise regarding recasting be incorporated. That’s the bit that reads as follows:

Editors should consider recasting complex measures; particularly where space is not at a premium (i.e. body text and not tables). Measures with units of measure (meters and millimeters or their unit symbols) on both sides of the en dash are generally more readable when fully written out:

• Wrong: wavelengths in the range 28 mm–17 m;   Christmas Day–New Year's Eve
• Right: wavelengths ranging from 28 millimeters to 17 meters;   from Christmas Day through New Year's Eve
• Right: from 23 July 1790 to 1 December 1791

And that brings this one to mind: Who in the world thought mixed units of measure like wavelengths in the range 28 mm–17 m was a good idea? I see no precedence for it in other manuals of style and it looks like it is *pushing it* way too far. Constructs like that, where the unit of measure changes dramatically should not have the word “to” replaced with an en dash; it is far too easy to just write the word “to”. Greg L (talk) 16:05, 2 August 2011 (UTC)

(edit conflict)Yes, I can't understand what “times and dates (or similar cases)” is supposed to exclude, if it includes 28 mm – 17 m. Is there any kind of range where “the components already include at least one space” but doesn't qualify as a “similar case”? If not, I'd just scrap that phrase altogether (leaving “... unspaced, except when the ...”). (But I can't recall point this out before, BTW.) ― A. di M.​_plé​^dréachtaí 16:20, 2 August 2011 (UTC)

The EU style guide has an example like that, but it comprises the range alone, not within a sentence, so maybe they were thinking more about tables and stuff like that than flowing text. ― A. di M.​_plé​^dréachtaí 16:27, 2 August 2011 (UTC)

Indeed, EUESG says "If the symbol or multiple changes, however, leave a blank space on either side of the dash: 100 kW – 40 MW." This doesn't seem all that unusual, but I agree that just saying "to" would make the issue go away (the issue being the strong preferences for different styling of such things among different people). Dicklyon (talk) 17:07, 2 August 2011 (UTC)

I agree, I find that there is nothing wrong with the look of 100 kW – 40 MW. But I find that 28 mm–17 m looks confusing. Perhaps it is a combination of the lack of spaces and the fact that it fools the eye into thinking there is a missing “m” in the second half of the range. Greg L (talk) 18:23, 2 August 2011 (UTC)

Butcher’s rationale may seem initially persuasive, but it’s ultimately self contradictory, especially as embodied in the current wording of the MOS. Butcher is definitely a very highly regarded source, as evidenced by her citation in the majority of other major style guides, but on this issue, she is very much in the minority. For what it’s worth: I don’t have a copy of BCE because it’s one of the most expensive guides there is—the Amazon US price has just dropped to $79, and used copies aren’t much cheaper. And I don′t have any more space on my shelf . . . JeffConrad (talk) 01:44, 3 August 2011 (UTC)

Soliciting inputs for another proposal

Everyone get their comments in here; I’m going to take a stab at proposing a guideline that factors in some preferred practices that are widely seen on Wikipedia and at the same time doesn’t pretend that it is wise to try to change the writing habits of experienced, knowledgeable contributors who actually own and abide by respected manuals of style.

I think it is clear that we can seldom take a position in our MOS that dictates to experienced writers that a punctuation style that is shown in a respected outside manuals of style, like CMOS, aren’t permitted here; to the greatest extent that is wise, we need to be accommodating and inclusive to writing styles widely accepted in professional writing. Like User: A. di M.​ pointed out: Wikipedia has not collapsed because it allows both American and British spelling, both Mmmm DD, YYYY, and DD Mmmm YYYY dates, both the Oxford comma and the lack thereof, both unspaced em dashes and spaced en dashes as sentence-level punctuation. Granted, there are certain circumstances where it might be best to eschew certain widely permissible practices in favor of one preferred style; that would be where Wikipedia clearly has a certain *look* that is expected (the first sentence in our biographies being one such example).

I plan on drawing heavily from what has already been proposed. For the most part though, I plan to produce a proposal that doesn’t diverge very far from standard practices as regards the sort of constructs that may properly be formed with an en dash. Nor do I plan on extending accepted practices for the en dash beyond the scope widely accepted by established manuals of style; particularly when doing so tends to read cryptically or confusing.

In short, I plan on a guideline that protects established traditions so Wikipedia’s look is preserved where that is important, doesn’t expand the scope of proper uses of the en dash beyond the bounds of established and respected manuals of style, and doesn’t preclude widely accepted professional writing practices. Greg L (talk) 18:15, 2 August 2011 (UTC)

Greg, I hope this works for you, but I'm not sure you understand the problem. The MOS already doesn't "pretend that it is wise to try to change the writing habits of experienced, knowledgeable contributors who actually own and abide by respected manuals of style," and no proposal that I've seen can be fairly described as moving it in that direction. It's OK for editors to enter text styled as they like, or with misspellings, even, if that's their habit. But the MOS provides guidance to editors who are interested in moving the encyclopedia toward an accepted house style. If you're trying to get more precision, or more options, for when the house style includes spaces around the en dash, that's a good thing. The trouble is that some editors really really want that style to specify spaces when separating multi-word date ranges, and some really really want to specify, at least as an option, unspaced for that. Both approaches find support in multiple style guides, as we've seen. So what should be in our style guide? Only a couple of people didn't accept the spaced usage currently described. Now a few more are complaining that the scope of the usage is not clearly defined, and that we've apparently cut off spaced usage in non-date-like constructions such as Mexico – United States relations, even though it's commonly used in WP. I'd like to see some fine tuning here, too. But maybe to get a consistent style, some other styles will still have to be "precluded". Like the style of using hyphens for en dashes – it's not forbidden, just not part of what MOS specifies as house style.

So, with that rant behind me, I can tell you my preferences. First, we should specify that full date ranges use spaced en dashes; we do that uniformly in WP, and several guides call for it, because it's more clear than the crowded wrongly-associated look that you get with the American closed-up style. Let's stick with that, even if that means we can't get Jeff on board; or, if you find a strong enough current away from that, I'll yield. On most of the other points, I'm quite flexible, but I'd like to explicitly allow, and perhaps encourage, spaced usage in articles like Mexico – United States relations, so we don't have to change a ton of stuff. Dicklyon (talk) 00:55, 3 August 2011 (UTC)

For the record here, Jeff has been OK with spacing the dash in full-date ranges from the beginning, even though he has no problem with closed-up usage, either. Whether this usage gives a wrongly associated look is in the eye of the beholder—and the overwhelming number of style guides that seem to call for closed-up usage suggest that the issue is mainly Butcher’s. For once in his life, Jeff would appear to be in the mainstream. Whatever; again, Jeff is and has been fine with spacing the dash in full-date ranges—he entertained allowing closed-up usage in WP only in response to a complaint about inconsistency with other mainstream usages Jeff proposed.

Hyphens for en dashes: I don’t think there is much support for this, though there are usages, such as San Francisco–based company on which there seem to be two schools of thought. JeffConrad (talk) 01:34, 3 August 2011 (UTC)

Look guys… if there is a general consensus on en dashes, we’re done. Reversing what I had put on MOS lead to PMA squirting out sideways on us. If there is a general consensus (PMA-spin notwithstanding) supporting that what is now on MOS is what we want, then we’re done. I was operating on the assumption here that there was a rather broad undercurrent of discontent with a variety of things on the latest text. Someone please make a declaration that we are good to go and have talked this one to death, and can go back to serial tweaking like normal. Forget about PMA shitting his shorts a week from now; we’ll deal with that when and if the time comes. Greg L (talk) 03:13, 3 August 2011 (UTC)

My disagreements (which apply only to a few points) clearly still stand. But I don’t further effort here is indicated at this point. JeffConrad (talk) 03:36, 3 August 2011 (UTC)

edit

In the geo section, I removed Poland-Lithuania, as it is just a dab, and added Ed Bird – Estella Lakes Provincial Park, as that's it's legal name and we've already hashed it out with a lengthy & rather cantankerous discussion, including input from the govt. of BC. — kwami (talk) 08:07, 3 August 2011 (UTC)

Can't find the discussion - where is it?--Kotniski (talk) 09:34, 3 August 2011 (UTC)

As for Austria-Hungary, that was moved last year to a hyphen from a dash, where it had been for two years. The nominator argued this would make it easier to keep track of links (some links to Austro-Hungary were dashed, creating red links). It was a dual monarchy, though, like the Polish–Lithuanian Commonwealth, and is dashed in some refs, so this is something which might come up again. — kwami (talk) 08:17, 3 August 2011 (UTC)