Wikipedia talk:Manual of Style/Dashes

"Figure dash"

The figure dash is first described under "Dashes and hyphens used on Wikipedia" as being the same as the minus sign ("−"), and then later under "Dashes not used on Wikipedia" as something that is used in telephone numbers etc. ("‒"). This is a bit confusing. —skagedal^... 01:07, 16 December 2006 (UTC)

The figure dash (U+2012) is meant to be the same width as lining figures, for use in tables. It is a dash for telephone numbers, etc, and not a minus sign (U+2212). There's also a modifier letter minus sign (U+02D7). None of these should be used in Wikipedia, because (from memory) MSIE borks them up. —Michael Z. 2006-12-16 01:34 Z

I came to this Talk page to raise the contradiction that skagedal raised. This really needs to be clarified on the project page. The footnote is not sufficient to distinguish the two different characters that the page refers to as a figure dash. As the two statements stand, they appear to be, and indeed are, contradictory. I am not sufficiently knowledgable to do the clarification myself. Finell (Talk) 22:10, 24 February 2007 (UTC)

Dashes in article names

This was brought up by an anon on the Help Desk, and then my user talk page. See WP:VPT#Dashes in article names for info; I'd prefer if discussion was held there (I'm cross-posting it here because WP:MOSDASH is relevant to the discussion and may change as a result). --ais523 16:27, 12 January 2007 (UTC)

A related issue was running at WP:VPP#Style: dashes in page names.

I don't see "inconsistency" in the guidelines (who said that?)

Neither the VPP discussion, nor the VPT/UT:ais523/UT:Nightstallion discussion make clear imho why anything should change wrt to the current guidance? --Francis Schonken 17:03, 12 January 2007 (UTC)

• The question is, does If hyphens and dashes are needed to write a page name correctly (e.g., Piano-Rag-Music, Jack-in-the-box, Nineteen Eighty-Four), prefer simple hyphens, and avoid hair spaces, even in the odd case of a range forming part of the title, e.g., History of the Soviet Union (1985-1991). in section Dash guidelines for Wikipedia editors overrules Wikipedia should use standard rules of English punctuation for dashes., the first sentence in that manual, or not. --213.155.224.232 23:02, 12 January 2007 (UTC)

Why don't you quote the third bullet too? It reads:

If for greater precision another type of dash is used, always provide a redirect from the variant with simple hyphens and without hair spaces. Note however that using less common types of dashes in non-redirect page names can easily break Wikipedia:Naming conventions (common names), for the reasons given in the Rationale section of that guideline.

Or, to put the same question otherwise: is something wrong with that? --Francis Schonken 00:27, 13 January 2007 (UTC)

The problem is, if you're saving a file locally, browsers by default take the title of the HTML page as a file name. For WP articles that is the article name. I don't know how US-en based Windows systems behave, but in CE (Central Europe) systems there's a problem if you want to reload that locally saved file back to your browser. In W95 and W98, what I checked, loading a file including an em dash in its file name, fail to load in total. In XP, what I use, reloading the file into IE works, but any pictures, styles and so on are missing since the browser doesn't recognise the subdirectory in which that data is stored in. I am pretty sure that effects any Latin 2 based Windows systems, maybe even Latin 1 (but I have no available). The test to verify would be. Save an article with an em dash, e.g. War in Somalia (2006–present) but don't change the name. Then finish your internet connection, empty the browsers cache. Then double click on the file in the Windows explorer. If now the article appears in your browser window without any images then you see the problem I am talking about. --213.155.224.232 14:47, 14 January 2007 (UTC)

I'm all for usability (see e.g. Wikipedia:Usability). What you describe is very much an Old versions of MS Windows problem ('95 and '98 are currently "officially" not even supported any longer by their manufacturer...). OK, I think Wikipedia technical people should do as much as they can to keep MediaWiki software (and its implementation on any Wikipedia site) as compatible as they can with whatever system that is still more than marginally used (across unicode compatibility or not). Then, the actual problem you describe is a problem that only occurs in an off-site situation (a problem that furthermore can be avoided by the way you save the files on such older systems). I'm not sure what the community thinks about this (that is: keeping absolute compatibility to all systems, whatever their age, and as well both in off-line as on-line situations, even for easily avoidable issues). In this case (for the easily-avoidable off-line problem with MS Windows 95 and 98 etc systems), I'd be inclined to drop that far-reaching backward-compatibility issue (why don't you ask Microsoft to solve it? They're the ones that for instance fail to give a correct implementation to the unicode standard!) - certainly if this far-reaching backward compatibility issue couldn't be saved without making the MediaWiki software lose too much of the unicode-related advantages. (could someone technically-experienced check the viability of the technical issues I asserted above)

See also Wikipedia:Naming conventions (standard letters with diacritics)#Printability for characters/glyphs/... that should be avoided in Wikipedia page names for compatibility of the on-line Wikipedia with older systems, AFAIK the "ndash" is however not an unprintable character in that sense. Or is it? --Francis Schonken 15:38, 14 January 2007 (UTC)

The issue occurs at XP as well as W95/98. AFAIK, XP isn't an older system so far. --213.155.224.232 18:15, 14 January 2007 (UTC)

Sorry, no, I couldn't trigger the problem you describe on my windows XP system. Pictures in the article are fine, even after disconnecting network/internet and emptying browser cache (don't even see what disconnecting internet and emptying browser cache would change, but I did it). I even rebooted.

I did this both for:

• War in Somalia (2006–present) (containing an en-dash, not an em-dash as you contended above)
• Etobicoke—Lakeshore (containing an em-dash)

True, when saving as "html, complete" the bar with the current donation amount in the template currently on top of each page didn't render, and neither did the non-article related sidebar, and some of the css info (hardly surprising, but that is completely unrelated with this hyphen/ndash/mdash issue: I did the same procedure with Lake, with exactly the same result). When saving as .mht ("single file"), the sidebar & css info is contained in the file. Note that in the current IE (v. 7) saving as .mht is set as default (this used to be "html, complete" in previous versions).

So no, there is no problem with Windows XP specifically related to n-dashes or m-dashes in Wikipedia page names. Maybe try "make available off-line"-function if you don't have an up-to-date browser (which is however a free update, so I wouldn't see why not to update). --Francis Schonken 06:42, 15 January 2007 (UTC)

So it seems that's an issue with not-US-en installations only. But, who is installing IE 7.0 without being sure that the system will run afterwards (never change a winning team) - me not. I had to redo too much complete installations with loosing to much data in my life. So I use IE 6 with the latest updates, also because MS so far doesn't offer IE 7 in Czech and many other Eastern Europe languages as it did with IE 6 or as does Firefox. --213.155.224.232 12:06, 15 January 2007 (UTC)

I was using a "not-US-en" installation all the time.

Anyway, I ran the same tests on a Win XP not-US-en - SP1 (the other was SP2) - IE6, and I've seen the problem now (so still not sure whether it's "SP1→SP2" that solves the issue or IE6→IE7, or *both*). The problem occurs both with n-dash and m-dash, and can't be solved by saving as .mht, nor by saving under a different name that doesn't contain these dashes. As far as I can see the problem occurs when the browser sends the "save as file" request to the Wikimedia servers: the browser window doesn't seem to have a problem to get "%E2%80%93" translated to an en-dash in the page name (and similarly to have "%E2%80%94" translated to em-dash), while the same transformation doesn't seem to happen when the same request is sent by the "save" function of the same browser. Might be the problem can be solved server-side (MediaWiki software? Webserver software?), but I'm not sure about that. The file & folder names proposed by the browser neatly distinguish between hyphen/n-dash/m-dash, so that's not where the problem lies.

OK, what we've got thus far:

• Something that needs to be mentioned at bugzilla: (if it isn't already, some of the tech people should check that);
• Something that should be mentioned as a technical restriction at Wikipedia:Naming conventions and Wikipedia:Naming conventions (technical restrictions)
• A change is needed to this "dashes" guideline, I'll start with that one: I'll cancel/rewrite the third bullet of the "naming conventions" section of this guideline, warning about the problem --Francis Schonken 13:55, 15 January 2007 (UTC)

I rather think its IE6 -> IE7, because I've SP 2 installed. --213.155.224.232 20:35, 15 January 2007 (UTC)

I just noticed this; it seems that not many people are aware of it yet. I recently got a speedy rename of Category:IRT Broadway-Seventh Avenue Line stations to Category:IRT Broadway–Seventh Avenue Line stations. --NE2 00:33, 7 April 2007 (UTC)

What's the difference between a figure dash and a figure dash?

From the article:
"The minus sign or figure dash (−) is ... supported in almost all browsers, and can be used in Wikipedia."
"The figure dash ("‒") should not be used on Wikipedia."

The reference at the end points out that they are summoned differently, so why do we call them exactly the same thing? Should one be the x2012 figure dash or similar? — Ianiceboy 06:08, 15 March 2007 (UTC)

The minus sign and the figure dash might in practice be identical, but they have different Unicode characters. It looks like "figure dash" in the first line is meant to be an alternate name for "minus", a character which is fine, but the "figure dash" in the second line refers to the specific Unicode character called "figure dash". The question is: is the figure dash practically identical to the minus sign? —Centrx→talk • 03:11, 24 March 2007 (UTC)

this is joke right? figure dash=figure dash is identity always true ha ha--MajorHazard 02:25, 12 April 2007 (UTC)

This context

Which of the four dashes is recommended for Bedhead#Discography? This widely used context is not mentioned in this page, and should be. Badagnani 10:09, 4 April 2007 (UTC)

"Widely used"—that's for sure. Personally I wouldn't use a dash there, and I don't think I've seen it much in professionally edited text. If I'd entered the discography, it might start this (except that if I knew what "4-songEP19:10" means, I might write it differently):

Singles

• Bedside Table / Living Well (Direct Hit Records, 1992)
• The Rest of the Day / I'm Not Here (Direct Hit Records, 1993)

EPs

• 4-songEP19:10 (Trance Syndicate, 1994)
• The Dark Ages (Trance Syndicate, 1996)
• Lepidoptera (Trance Syndicate, 1998)
• Macha Loved Bedhead (Jetset Records, 2000)

Other possibilities for related situations are colons (for instance, in a real timeline, where the years are important) and tables. —JerryFriedman 17:44, 13 April 2007 (UTC)

Too wishy-washy for guideline

Lots of talk about what different people do (like article of how dashes are used around world), but short on guidance of what to do here at wikipedia. Specific question: leave spaces around em-dash? Yes/no? Fast answer makes good guideline.--MajorHazard 14:15, 7 April 2007 (UTC)

Thinking more on subject, I think em dash aught be used only rarely in wikpedia, which suppose neuter in points of view. Em dash used mainly for drama effect, and thus show writer mean particular point of view.--MajorHazard 02:18, 12 April 2007 (UTC)

Question

So you use hyphens to combine words, such as copy-editing correct? Howard Cleeves 19:36, 11 April 2007 (UTC)

If it's a compound adjective. —Ben FrantzDale 00:28, 12 April 2007 (UTC)

Could you be a little less coy and clarify? Howard Cleeves 06:45, 13 April 2007 (UTC)

Somebody needs to put this in the MOS (probably as a guideline, not a rule, unfortunately). I will, if I can find references. When you use a phrase as another part of speech, it should be hyphenated. Thus "They are monitoring air quality" (noun phrase) but "It is used for air-quality monitoring" (adjective), "They set up (phrasal verb) the experiment" but "They changed the set-up" (noun). There are other ways of looking at the first one: adjectives in English associate to the right, so to show that "quality" goes with "air" before it goes with "monitoring", you need a hyphen. Or one-word adjectives in English go before the noun but multi-word adjectives go after ("an article too long to read"), so when a multi-word adjective goes before the noun, it needs hyphens to make it one word. Some linguists call this last "the eleven-year-old-boy rule".

Exceptions: some phrases seem so naturally compound that people don't normally hyphenate them in any situation. Examples include "natural gas" and "high school", so you see "natural gas well" and "high school teacher" even in edited text.

Then there are the open-hyphenated-solid problems: "copy editing", "copy-editing", or "copyediting"? The Chicago Manual of Style has tables for various situations, as I recall. I write "copyediting" because Terry McGarry, a copyeditor as well as a novelist, writes it that way, and I knew her in college. Simple but maybe not the answer for everyone. —JerryFriedman 18:06, 13 April 2007 (UTC)

Clarification and possible technical solution re dashes in page title

The guideline currently reads

Please do not use an en dash, em dash, or any type of dash other than a standard hyphen in a content page name because such symbols prevent some software (including Internet Explorer 6 on Windows XP) from saving the page as a file on a computer.

My understanding from the discussion earlier is that saving works, but loading images from the saved pages doesn't. Regardless, that's not my question. I'm wondering if someone who has software exhibiting this problem can tell me whether it applies only to dash characters, or whether it applies to any non-ASCII character that must be percent-encoded in a URL. For instance, is Poincaré–Birkhoff–Witt theorem problematic only because the name contains dashes, or would it be problematic even if renamed to Poincaré-Birkhoff-Witt theorem (as someone tried recently but was reverted)?

If any non-ASCII character triggers the policy, could we amend the policy to allow dashes in cases of titles that have good reason to contain other non-ASCII characters? Because in that case the only effect of the policy is to prevent proper typography (assuming appropriate redirects exist to allow searches etc).

If, on the other hand, dashes alone trigger this problem, I wonder whether there might be a technological solution. Currently, the wiki software automagically translates spaces to underscores both when forming a url from a title and when interpreting urls that contain spaces. How feasible would it be to add similar translation from en-dashes to double hyphens (--) and from em-dashes to triple hyphens (---), matching the TeX conventions for those characters? I'd imagine such translation happening only when forming urls from titles, not in other contexts in the wiki, and I'm assuming (perhaps incorrectly) that this would be unambiguous due to there being very few articles already containing double or triple hyphens in their names. —David Eppstein 02:47, 1 May 2007 (UTC)

Could someone explain how the dash "prevents" people from saving the file? Not having Windows, I can't check it myself. But it seems like a bogus reasons (i.e., what if they type another filename into the save box). CMummert · talk 12:09, 1 June 2007 (UTC)

Unicode characters vs. character entities dispute

Resolved

 – Conflicting sentence deleted.

I dispute the following: "If possible, avoid typing their related codes (e.g., – for en dash) to display dashes, as this clutters up the text when editing and may not be understood by new editors."

1. It conflicts with the entire rest of this guideline, which consistently tells editors they are free to use the character entity codes, and in fact generally recommends them first (and should).
2. It does not "clutter up" the code; it clarifies it. Many of us do not have good enough eyesight to 100% reliably tell which Unicode character in the dash "family" is which, and many fonts do not adequately distinguish them at all, even for people who do not need better glassess. The only way to be reliably certain that there is in fact an en dash in the middle of that date range and not some other dash is to have the entity code in there instead of the Unicode character.
3. The "may not be understood by new editors" excuse is a farce. Virtually everthing about writing wikitext is using (initially) unfamiliar, geeky, and mostly-manual encoding to achieve the desired results; this is no different at all. And all anyone has to do is look at the source, then look at the rendered version (or vice versa) to figure it out. Again, just like everything else about wikitext.

— SMcCandlish [talk] [cont] ‹(-¿-)› 18:26, 12 May 2007 (UTC)

Proposal: Delete the disputed sentence

Resolved

 – Garnered no further activity.

• Delete — SMcCandlish [talk] [cont] ‹(-¿-)› 18:26, 12 May 2007 (UTC) (nominator)

After half a month of silence, I'm taking silence as assent and just doing it. — SMcCandlish [talk] [cont] ‹(-¿-)› 18:44, 27 May 2007 (UTC)

font differences

See Talk:Dash#font_differences. ∞Σɛ_Þ² ^(τ|c) 13:44, 30 May 2007 (UTC)

Proposed expanded version of advice on hyphens and dashes in MoS

I'd appreciate expert advice on the new proposal. Please see Wikipedia_talk:Manual_of_Style#Hyphens_and_dashes_in_the_MoS and from there the draft version.

This page seems to be written from a computer-code aspect; although it does contain advice in stylistic terms, it's not in good shape. One solution might be to rewrite this page, but my view is that the use of hyphens and dashes is important enough to treat in more detail in the summary MOS. Such detail, I think, should at least match that in other sections (e.g., capital letters and italics). Tony 07:44, 6 June 2007 (UTC)

I agree that this page is poor shape, Tony. It needs fundamental re-thinking.

– Noetica^♬♩ Talk 08:06, 6 June 2007 (UTC)

Can someone advise why en dashes are not permitted in article titles, as apparently written on this page? Tony 13:26, 7 June 2007 (UTC)

Here's the text at issue:

"Please do not use an en dash, em dash, or any type of dash other than a standard hyphen in a content page name because such symbols prevent some software (including Internet Explorer 6 on Windows XP) from saving the page as a file on a computer. The non-hyphen dashes can be used in redirect pages if an enhanced precision for the page name is desired for use in wikilinks elsewhere."

Is this still the case? Just how much software still suffers from this problem? Why would someone want to save a page as a file? Who cares? En dashes are important enough to drop this rule, IMV. Tony 13:29, 7 June 2007 (UTC)

As anyone who runs a bot can tell you, Unicode is widely used in article titles and this guideline is lagging quite far behind current practice. Removing the silly objection to en dashes in titles would be a good start, in my opinion. I find it hard to believe that users are incapable of saving articles with dashes in the title; they can just choose a different name, for saving, if nothing else works. Based on the comments higher on this page, it does appear that an updated Windows system will not have the problem. — Carl (CBM · talk) 18:11, 7 June 2007 (UTC)

I agree. I was not aware of this guideline until just now, and I have moved many pages to the more correct title with en dash, and so far received not a single comment or complaint on doing so. Let's fix the guideline. The en dash in the title is important to helping people use the correct typography when they make links, since they may notice the redirect from the hyphen version to the correct version; it doesn't work the other way. And the en dash is very often important to the correct semantic interpretation of the text, as in metal–oxide–semiconductor structure. Dicklyon 16:43, 10 June 2007 (UTC)

Proposal for three substantive alterations

1. Removal of spaced em dashes. Name one major style manual or publisher that approves of them. In fact, all of the major style manuals are in agreement that unspaced em dashes be used as interruptors; some major publishers use spaced en dashes instead. No reputable publisher uses space em dashes. Many WPs feel that they should not be used, because they are too space-hungry, too visually intrusive, and stretch the limits when it comes to overhang at the ends of lines. The draft MOS section revision provides for either unspaced em dashes or spaced en dashes as interruptors.

2. Removal of statement concerning double hyphens (in conflict with the current and draft new MOS sections).

3. Removal of proscription on using dashes in article titles (apparently spurious and outdated reasons: see above).

Please state any objections to these changes here, with cogent arguments. I propose to make the changes next Wednesday unless a good case is mounted not to. Tony 12:41, 9 June 2007 (UTC)

• Oppose #1. It's been my experience that major style manuals actually do not say anything about this at all. I have in my lap all of the following: Fowler's Modern English Usage (rev. 3rd ed.; Burchfield's Oxford revision, i.e. the British one), The Chicago Manual of Style (15th ed.), and Strunk & White (Tenney's 4th ed) — i.e., the latest version of all three — and none of them prescribe, proscribe or advise in this regard at all. All three illustrate the usage without spaces, but the lack of spaces around an em dash is a typographical convention, so this is expected. Wikipedia is not a paper encyclopedia. Despite being a largely American (in genesis, hosting and majority authorship) publication, Wikipedia is not constrained to follow American (or any other) typographical conventions; cf. WP's eschewing of "interior end punctuation in quotations," like that, for "exterior". In online prose, spaced em-dashes are a very common and strong counter-tradition. Historically, this is because people used the hypen-minus as an em dash for many years in Usenet, e-mail, etc., and many still do, and presently also because it is an aid to readability. In many fonts there is virtually no (and in some cases absolutely is no) visible difference between hyphen minus, en dash, em dash, etc. — the only way to tell that what is intended is a em-dashed comment and not a compound word is the spacing. Wikipedia does not force any particular font on anyone; we all have userspace stylesheets we can use, and even for readers with no accounts, many browsers allow the user to override styles asserted by sites they visit. This strongly militates against going with a dead-trees typographical convention simply because it is the most common in printed works, but which conflicts with real-world usability needs of online reading material, no to mention a countervailing more recent tradition specific to the new medium. Cf. also the extreme dearth of curly quotes (typesetters' quotes) in Wikipedia; the overwhelming majority usage in online material is straight quotation marks and apostrophes, and Wikipedia has wholeheartedly adopted the e-traditional version over the paper-traditional version. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:00, 9 June 2007 (UTC)

Which begs the question: Is there something inherently advantageous about straight quotation marks and apostrophes, which are just an cost-saving artifact inherited by ASCII from the long-gone era of mechanical typewriters, or are they nothing but a consequence of the sorry state of contemporary English-language keyboard design, which still lack them? In the former case, we should not use then on Wikipedia, in the latter case, we should go and fix the root problem (the outdated keyboard standards). Markus Kuhn 21:00, 10 June 2007 (UTC)

• Oppose #2 in part: It should not simply be removed, but replaced with an explanation that while some editors use "--" for em-dash (and we should retain the explanation why) that this is deprecated, and should be replaced with "—" where ever found. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:00, 9 June 2007 (UTC)
• Support #3. Makes sense. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:00, 9 June 2007 (UTC)
• Comment: This passage, "Spaced en dashes – like this. (Note: an unspaced en dash is properly used to indicate a range of numbers; unspaced en dashes should not be used for the parenthetical or colon-type uses, as discussed above.)", is far more problematic. It appears to imply that en dashes are used for set-apart comments, but then says they should not be, and that only unspaced en dashes are used for indicating ranges of numbers. This is just nonsensical gibberish, as is the misuse of the word "parenthetical", and the awkward construction "colon-type". This passage needs to be rewritten from scratch, using material from major style guides to explain how to use en dashes properly. For example, spaced en dashes are properly used to separate the two ends of a numerical range when its specfication is complex: "1994–1996", but "December 12, 1994 – May 30, 1996". En dashes, spaced and unspaced, have other uses as well. Unlike the use of "--" which is e-traditional but deprecated, en-dash used in place of em-dash should simply be declared wrong. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:00, 9 June 2007 (UTC)
• Strongly support #3. Grammatical and typographical correctness should extend to subject lines and not just the text. Support SMcCandlish's modification of #2, deprecation with explanation rather than removal. No opinion on #1. —David Eppstein 00:36, 10 June 2007 (UTC)

Noetica's comments

1. Removal of spaced em dashes

Name one major style manual or publisher that approves of them.

Well, AGPS Style Manual doesn't recommend them, but allows that "another variant that is used is the spaced em rule". With typical ineptness, it gives a curious and exceptionable consideration as the reason for preferring the unspaced em dash for sentence punctuation, and confuses terms in an illogical way that it would be tedious to tease out here:

The style recommended for the standard dash in Australian government publications is an unspaced em rule; this eliminates any possibility of confusion with the spaced en rule.

In fact, all of the major style manuals are in agreement that unspaced em dashes be used as interruptors; some major publishers use spaced en dashes instead.

Penguin Working Words uses and explicitly allows spaced en dash (this being Penguin house style), but equally notes unspaced and spaced em dashes as options. (Don't get me started on Cambridge Guide to English Usage.)

No reputable publisher uses space em dashes.

Not sure about that. In a quick look at books I have to hand, I find the spaced em dash consistently in Greek Philosophy, John Burnett, MacMillan, in a 1968 re-setting. And, for what little it is worth, very many newspapers use it consistently.

Many WPs feel that they should not be used, because they are too space-hungry, too visually intrusive, and stretch the limits when it comes to overhang at the ends of lines.

I'm with them. But then, I'm for spaced en dashes as exclusively, as sentence punctuation.

2. Removal of statement concerning double hyphens (in conflict with the current and draft new MOS sections)

Deprecate them and all similar makeshifts; and license summary conversion to a regular style.

3. Removal of proscription on using dashes in article titles

Remove it; force action to make Wikipedia searching more intelligent. (Note, incidentally, that in some quarters it is a typographical norm to convert all hyphens to en dashes in all but the lowest-order headings, for appearance' sake along with large, fat, or bold type.)

A comment on SMcCandlish, above: Sorry, SMcCandlish: you are simply mistaken on one important point. The spaced en dash is widely accepted as an alternative to the em dash (spaced of unspaced), here at Wikipedia and in general print publishing. It is house style at Penguin, Routledge, Cambridge UP, and others. It is even seen in several major works from OUP in recent years, though they now call for the unspaced em dash in their house style. Apart from that, I think your points are worthy of note. [This paragraph I added later.– Noetica^♬♩ Talk 06:06, 11 June 2007 (UTC)]

Beyond all that, I favour getting rid of this WP:MOSDASH altogether. See Noetica's other issues.

– Noetica^♬♩ Talk 01:32, 10 June 2007 (UTC)

• Support all 3. SandyGeorgia (Talk) 02:49, 10 June 2007 (UTC)

• Support all 3, esp. #3. Make it clear that when an article has an en dash in the title, a redirect from an article with a hyphen there is required. Dicklyon 16:46, 10 June 2007 (UTC)

• Support all 3, especially #1. For a proper house style, we should really agree one just one single style of punctuation dash. Forget about the fights between other style guides. Wikipedia is well on its way of becoming bigger and more influential than several of the usually quoted ones, and able to set standards, rather than just copy them. Be bold. I now frequently hear: "Let's follow the Wikipedia style, it just makes much so more sense than [insert your least favorite dust-collecting last-century dead-tree style guide here]." Let informed debate and consensus about matters of practicality and functionality win over archaic style dogmas. The dash style is really an area where a clear standard should be set. I personally would certainly favor the "en-dash with spaces" option, on grounds of (a) finding a punctuation without nearby space very odd indeed, (b) "em-dash plus space" been just unnecessarily long, (c) "em-dash minus space" not permitting a line break in many systems during paragraph formatting (leading to bad column breaks), and (d) having one type of dash less just makes life simpler for teachers, typists, keyboard manufacturers, and all the rest of us. I happily admit that I might also be influenced by the fact that "en-dash plus space" is pretty much the only form commonly used in Britain and in other European languages, where the em-dash is hardly known in traditional typography. It is used – if at all – only for some special applications such as marking empty cells in tables or the like. But I'm happy to agree to other solutions as well, as long as there is a single clean one identified and justified. I'd like to see better justifications for the (IMHO ugly-long) em-dash than just quoting as authority old style guides that do not explain their choices very well. Markus Kuhn 20:51, 10 June 2007 (UTC)

• Support, with proviso. I agree with the removal of the effective invitation to use spaced em dashes, but I would not support an active deprecation since the following challenge from Tony was too tempting for a language nerd like me: "Name one major style manual or publisher that approves of them. In fact, all of the major style manuals are in agreement that unspaced em dashes be used as interruptors; some major publishers use spaced en dashes instead. No reputable publisher uses space em dashes." Well, here is what it says in the New York Times Manual of Style and Usage: "Because newspaper lines are usually narrow, with few words to a line, the dash should be surrounded by spaces; they provide openings for the computer to distribute spacing evenly when justifying the type. The dash used in news copy is one em wide. Do not use the shorter en dash." It may be argued against this that Wikipedia is not a newspaper; but the same problem of narrow columns sometimes arises, for example between pictures: an unspaced em dash can in that case induce an unsightly gap because the processor counts it as a letter joined to the words on either side of it. Despite this self-indulgent quibble, I don't use spaced em dashes myself. I support the other two proposals without proviso. qp10qp

I said "reputable". The NYT also—bizarrely—says to use an apostrophe in 1990's. Um .... Try Chicago instead. Tony 03:34, 12 June 2007 (UTC)

They also use S.U.V.'s as the plural of SUV. Their style guide is best avoided when you don't work for them. — Carl (CBM · talk) 04:46, 12 June 2007 (UTC)

Yep, for a great newspaper, they sure do have a shitty in-house styleguide. Tony 05:27, 12 June 2007 (UTC)

While the NYT style guide does give a plausible justification for using spaces, they give no justification for why you still have to use the extra-wide em dash; if you have already substantially increased the visibility of dash by surrounding it with spaces, the shorter en dash seems perfectly adequate. Markus Kuhn 09:16, 12 June 2007 (UTC)

This is a matter of taste. There will never be total uniformity on dashes, which is why, though I agree that Wikipedia should not invite spaced em dashes, it should not deprecate them. If it did, it would become just one more set of conventions to add to the existing ones. Publishers vary enormously, and we should be flexible enough to absorb the results of that, for example when quotations are used from books with divergent conventions. As far as en dashes are concerned, spaced en dashes are fine but not, in my opinion, as useful as unspaced em dashes. The graduation from hyphen, through en dash, to em dash is useful, which I expect is the reason why the New York Times maps it out in the guideline. For example, think of those messy openings to our biography articles, with em dashes dividing dates of birth and death, length of reigns etc. If you are also using spaced en dashes as interruptive dashes in the article, it may look as if there is a break between the dates rather than a range indicator; other uses of the en dash would also be compromised. qp10qp 16:17, 12 June 2007 (UTC)

I agree, Qp, but I think we're going to have to live with spaced en dashes as an alternative; a large proportion of WP articles use them consistently, and they have none of the problems of spaced em dashes. People have become more accepting of them through newspapers' use of them, and now in the publications of several of the major houses. Tony 00:24, 13 June 2007 (UTC) In addition, your example of spaced eM dashes in date ranges is of wrong usage on another account: em dashes—spaced or unspaced—can't be used for ranges. Tony 01:12, 14 June 2007 (UTC)

Let it be noted that many newspapers use spaced em dashes, as I have pointed out above. At least two of Australia's biggest broadsheets do (The Age and The Australian). But I would stress three things touched on by others:

• Wikipedia is big enough now to set standards, not merely go begging for them.
• Wikipedia is different from a newspaper in important ways. (Sure, printed books use narrow columns in some of their components; so does Wikipedia; so what? That isn't a salient consideration for us as it is for newspapers.)
• Wikipedia is not a print product, and must find standards that are appropriate to HTML, or whatever protocol is used in the future.

Anyway, I'm still firmly in favour of spaced en dashes, myself.

– Noetica^♬♩ Talk 00:58, 14 June 2007 (UTC)

• Oppose #1. The objection that em-dashes and spaced em-dashes are space-filling and visually arresting misses the point: they are meant to be. An em-dash is used for emphasis and dramatic effect, to make a contrast or a pointed aside. Consequently they should be used sparingly — especially in encyclopedic prose (although they can be useful on talk pages). If an article overuses em-dashes then the inappropriate em-dashes should be replaced by parentheses or (for end-of-sentence em-dashes) a colon or semicolon. Geometry guy 17:58, 13 June 2007 (UTC)

technical issue

• Regarding "#3", the use of dashes in article titles is an accessibility issue in some configurations of modern, up-to-date operating systems. Gimmetrow 00:51, 13 June 2007 (UTC)

• • I have tried and failed to find any confirmation that it is still a problem. There is some description higher on this talk page from several months ago, but nothing recently. Even in that discussion it was not a problem for fully up to date systems, apparently. If you have any details, I would appreciate them. There's no reason to keep the prohibition indefinitely for what was likely a passing bug. — Carl (CBM · talk) 00:56, 13 June 2007 (UTC)
    • I run pywikipedia bots. I've tested all available encodings in OS X 10.4.9, and when I type or copy-paste an article name in the terminal, any dashes prevent the typed article name matching the article on wikipedia. Similar issues exist in Red Hat Enterprise release 4, but I have not exhaustively tested every available option. Gimmetrow 03:02, 13 June 2007 (UTC)
      • I thought you were referring to an issue with saving pages in Windows, sorry. I don't think the issue of typing names at the console is an important consideration here. The same problem will affect most Unicode characters, not just dashes. There's no reason to make a special exception for dashes, when then entire wiki is going Unicode anyway (just wait for single login). I can't type general Unicode into an XTerm on my computer but I manage to run User:VeblenBot nevertheless, by never copying article data by hand. — Carl (CBM · talk) 03:38, 13 June 2007 (UTC)
        • Actually, this is pretty much only an issue with dashes. Every other unicode character that is likely to appear in an article title seems to work fine (é, è, ñ, etc.) Gimmetrow 03:55, 13 June 2007 (UTC)
          • é, è, ñ, etc. are part of the MacRoman character set, which is very far from "every other unicode". What about other unicodes that are not in that set, for instance the ő in Erdős–Szekeres theorem? —David Eppstein 04:01, 13 June 2007 (UTC)
            • The most common problem is, by far, dashes. Occasionally some other characters are a problem, but these are very infrequent. I don't think I've encountered one in the last couple months. Gimmetrow 04:17, 13 June 2007 (UTC)
              • To clarify, which is it: you haven't encountered a non-MacRoman character, or you have encountered non-MacRoman characters but they haven't caused you problems? And you do know about this OS-X Python Unicode tip, right? —David Eppstein 05:01, 13 June 2007 (UTC)
            • The issue is not with output, which is fine, but with input. To clarify then: I don't recall a software problem involving an article title without a dash in a couple months. I haven't really paid attention how many of those articles had non-MacRoman characters. I tested an article with a ő (no dash), and it worked. Gimmetrow 14:26, 14 June 2007 (UTC)
• (←) With SUL we will gain a lot of foreign usernames in Japanese, Chinese, Hindi, etc. We already have these chars in the interwiki links, which bots parse with no problem. In the end, we have to use bot setups that support the same titles as mediawiki, which means arbitrary Unicode chars. — Carl (CBM · talk) 04:43, 13 June 2007 (UTC)
  • Assuming it is merely an issue with "bot setup", could not one also argue that we should hold off making a change which breaks things until the bot frameworks handle it appropriately? Gimmetrow 14:26, 14 June 2007 (UTC)

• To add my bit (in greater detail), substituting hyphens in article titles causes considerable tension when the same compound item is used in the text of the article (typically this occurs many times). IMO, to ban the use of en dashes in article titles would be justified only on the grounds of very serious technical drawbacks that:

• • adversely affect more than a few techies; and
  • involve significant functions; and
  • are inescapable (i.e., there's no way of getting around it); and
  • are unlikely to be resolved technically in the near future.

I'm not convinced that all of these conditions pertain. Tony 09:09, 13 June 2007 (UTC)

I find these criteria rather dismissive. If it is a "few techies" complaining about this, that is because the "techies" can narrow the problem to a specific issue. Other users encountering such a problem will simply assume that wikipedia is broken. When there are known accessiblity issues, would not some caution seem reasonable? This issue has come up with names of saved files, so it likely manifests in other ways. Gimmetrow 19:50, 13 June 2007 (UTC)

So far, nobody has said they oppose #3. If you're hinting that you oppose it, please provide the actual reason; so far, all I see is unsourced speculation that there might be a problem. So far, it is justfiable to be dismissive. Dicklyon 20:00, 13 June 2007 (UTC)

Indeed, and Gimmetrow, many more users are likely to see WP as "broken" when they see a hyphen in a title followed by en dashes in the main text. Tony 01:13, 14 June 2007 (UTC)

Summary of feedback on proposals for the removal of three points

Proposal 1—the removal of spaced em dashes from the dash guidelines

• Oppose: SMcCandlish, Geometry guy
• Support: Noetica, Markus Kuhn, Dicklyon, Tony, Sandy
• qp says remove the invitation to use them, but don't proscribe them. David Epstein declares no opinion.

Although most people are in favour, there's doubt or objection by a significant minority. Thus, a compromise appears to be in order, viz., to follow qp's suggestion of not explicitly inviting the use of spaced em dashes, but not proscribing their use.

Old:

The following five dash styles are currently in use in Wikipedia:

• Tight (unspaced) em dashes—like this.
• Spaced em dashes — like this.
• Spaced en dashes – like this. (Note: an unspaced en dash is properly used to indicate a range of numbers; unspaced en dashes should not be used for the parenthetical or colon-type uses, as discussed above.)

New:

The following dash styles are used in Wikipedia:

• Em dashes, which are normally unspaced on Wikipedia—like this.
• Spaced en dashes – like this. (Note: an unspaced en dash is properly used to indicate a range of numbers; unspaced en dashes should not be used for the parenthetical or colon-type uses, as discussed above.)

Consistent with this, the MOS style draft section on em dashes (about to be implemented) has been adjusted from:

Em dashes are always unspaced on Wikipedia.

To

Em dashes are normally unspaced on Wikipedia.

---

Proposal 2—the removal of the statement allowing double hyphens (in conflict with the current and draft new MOS sections)

• Oppose: nil
• Support: Noetica, qp, Markus Kuhn, Sandy, Dicklyon, Tony
• SMcCandlish and David Eppstein, in essence, support, with the rider that an explanation as to why some WPians use the double hyphen, it should be replaced with an em dash.

Everyone, then, disapproves of the use of the double hyphen. I think that the explanation and replacement is best dealt with here, in this article, but not in the MOS, where the current brief proscription should remain unchanged.

Old:

Some Wikipedians use a double hyphen ("--") to represent an em dash. This is a carryover from the typewriter, which does not have an em-dash key. The double hyphen was never used in typography because typeset fonts, like the digital fonts used on computers, include em dashes.

New:

The double hyphen ("--"), used by some writers to represent an em dash, is not used on Wikipedia. The double hyphen is a carry-over from the typewriter, which does not have an em-dash key. The double hyphen was never used in typography because typeset fonts, like the digital fonts used on computers, include em dashes.

---

Proposal 3—the removal of the proscription of dashes in article titles

• Oppose: nil
• Support: Noetica, qp, Markus Kuhn, Sandy, Dicklyon, Tony, SMcCandlish, David Eppstein, Carl (CBM)

Gimmetrow appears to oppose, although has not formally done so. He cites an accessibility issue in some configurations of modern, up-to-date operating systems, but has not, IMO, effectively addressed counterarguments by Carl (CBM), David Eppstein, DIcklyon and me.

I've retained the hair-space stuff, because I just don't know enough about it to change it.

Old:

For page names:

• Hyphens and dashes are used in article titles only when absolutely necessary (e.g., Piano-Rag-Music, Jack-in-the-box, Nineteen Eighty-Four, Eye–hand spand). In that case simple hyphens are preferred. Avoid hair spaces, even in the odd case of a range forming part of the title, e.g., History of the Soviet Union (1985-1991). Years of birth and death are not used in an article title to distinguish between people of the same name.
• If for greater precision another type of dash is used, always provide a redirect from the variant with simple hyphens and without hair spaces.
  '[Guideline change 14:14, 15 January 2007 (UTC), see talk page:]
  Please do not any type of dash other than a standard hyphen in a content page name, because such symbols prevent some software (including Internet Explorer 6 on Windows XP) from saving the page as a file on a computer. The non-hyphen dashes can be used in redirect pages if an enhanced precision for the page name is desired for use in wikilinks elsewhere.

New:

For page names:

• When creating an article, a hyphen is now not used as a substitute for an en dash in the title. Eye–hand span). Avoid hair spaces, even in the odd case of a range forming part of the title, e.g., History of the Soviet Union (1985-1991). Years of birth and death are not used in an article title to distinguish between people of the same name.
• Consider providing a redirect page using a hyphen (or no hair spaces) where a dash or hair spaces are used; see wikipedia:naming conventions (precision).

_____

I note that Noetica, with my support, has expressed significant misgivings about the quality of this page and its disorganised relationship with Dash (punctuation), Hyphen and the relevant sections in the WP:MOS. I expect that there will be a proposal to merge this page with Dash (punctuation) and Hyphen. Thank you all for you input. Tony 09:12, 14 June 2007 (UTC)

I fixed the History example so that it conforms to, and illustrates the guidelines (if I have understood correctly!) Geometry guy 10:59, 14 June 2007 (UTC)

In reply to Tony1's summary above, I would have thought discussion more relevant than !voting. I have replied to the last statements of Carl and Eppstein, but I see no counterargument from the third. Your argument is that the title should match the text of the article, which of course it should in general. However, I've run into problems with article titles with dashes, and I would like this sorted out before the MOS changes. Two things can be done to lessen the issue: require a redirect fom a non-unicode title, and insist that the article and talk pages titles match. It's not uncommon to find confusing redirect cycles leftover from partial page moves. Gimmetrow 14:26, 14 June 2007 (UTC)

Can you propose here a wording, then, for overleaf? Tony 14:44, 14 June 2007 (UTC)

I did strengthen the wording to require a redirect. I'll also add the talk page, which is a good point. — Carl (CBM · talk) 14:46, 14 June 2007 (UTC)

I took out the sentence about redirects needing to be mirrored by talk page redirects. I'm sure it wasn't intended to be so broad, as many articles, with dashes or not, have a dozen or more redirects. The only case that really matters is if a page is moved, in which case a talk page redirect is made automatically. There's no dash-specific issue here. Dicklyon 18:22, 14 June 2007 (UTC)

For my part I am busy (offline) and still reading through and thinking about this. Will get back to this within 24hrs. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:06, 15 June 2007 (UTC)