Misplaced Pages

Revision as of 00:06, 2 August 2011

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)

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, Misplaced Pages 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.

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 Misplaced Pages 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é​ 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, Misplaced Pages 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é​ 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 Misplaced Pages 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é​ 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 Misplaced Pages 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é​ 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é​ 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é​ 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é​ 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é​ 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é​ 13:49, 1 August 2011 (UTC)

Memorializing the facts regarding other MOSs

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)

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)