Privacy Policy Cookie Policy Terms and Conditions Wikipedia talk:Manual of Style (dashes) - Wikipedia, the free encyclopedia

Wikipedia talk:Manual of Style (dashes)

From Wikipedia, the free encyclopedia

Please browse Archive 1 before adding new proposals.

Contents

[edit] Contradiction on double hyphen use

According to "Dashes and hyphens used on Wikipedia":

Historically a double hyphen (--) was used to represent an em dash because on a typewriter the hyphens tend to connect, creating a dash in appearance. Since this is almost never the case in digital type, do not use this technique.

But according to "Dash guidelines for Wikipedia editors":

Editors who do not want the bother of keying in HTML entities or prefer to maintain the readability of the wikitext are free to type their dashes in this fashion.

(my emphasis)

It seems odd to me that such a broad exception to the rule would be placed in the bottommost section. Also the two section titles seem redundant, no? Dforest 12:45, 8 November 2005 (UTC)

Yep. I like the second one better. They should be allowed, but can be changed to a proper dash by anyone who wants to. — Omegatron 14:41, 9 January 2006 (UTC)
There can be problems displaying em dashes (and curly quotes for that matter) with some OS and character sets -- that is a reason why perhaps there should be tolerance for the double hyphen (and straight quotes) option. RomaC 03:12, 21 January 2006 (UTC)
But allow it in an inconsistent manner? That doesn't make sense. Either allow them or don't. There's no point in letting people use double dashes in a few articles so that they can read them in their browser, while all the other articles use Unicode dashes. Those same browsers have a problem with foreign characters, too. Should we remove foreign language Wikipedias?
Ideally, the Mediawiki would be smart enough to figure out where to use the real dashes, and we could use <nowiki> for the few cases where it would otherwise make a mistake. For instance, whenever it detects a dash between two dates, it renders it as an en dash. When it sees two dashes in a row, it renders it as an em, etc. Then you could turn it off in preferences if you had a broken browser. — Omegatron 19:40, 24 April 2006 (UTC)

"Allowed" should be changed to "tolerated". That would mean that if a user types a double dash when creating or adding to an article, nobody should get bent out of shape, and there would also be the encouragement (more than allowing) of editors to change them to em dash. Thus it would read something like: Hu 22:49, 18 November 2006 (UTC)

I agree 100% on this. There has been discussion and disagreement on this issue in the past, but I think it is worth revisting the topic. Especially now that the edit page has a link to insert the dashes without needing to use the HTML entity. —Doug Bell talkcontrib 23:08, 18 November 2006 (UTC)
I agree also, except that the wording should be: Double dashes may be tolerated, but editors are encouraged to convert any they might find to em dashes, or to spaced en dashes (depending on which of these two practices has already been established in the article). Remember that we allow spaced en dashes OR em dashes (spaced or not), as sentential punctuation. – Noetica 23:29, 18 November 2006 (UTC)

[edit] Suggest cutting moot point at bottom

Most of the bottom of this article (how to type em-dashes on various keyboards) is totally moot since anyone can just click the link below the edit box to add the em-dash. Any objections to me chopping it totally? It can always live at em dash or something. Stevage 22:19, 19 January 2006 (UTC)

Don't. Some people will want to type them in by hand instead of the edit thingy, which is slower. — Omegatron 19:25, 26 January 2006 (UTC)

[edit] Should have a preferred dash style—really

I'm sure I can't say anything here that hasn't been said before, so please be patient with a new editor.

I know about the many styles people use for dashes. I was hoping by coming to the manual of style I'd get some guidance about the preferred style on Wikipedia. My understanding—generally, not specific to Wikipedia—has been that the em dash without spaces (or with hair spaces) was the preferred style. After reading the style manual here it seems like the answer is "whatever you want to type."

Also, having the guide tell editors not to change existing dash styles seems to go against WP:BB and will just result in ugly pages that use multiple dash styles. It's OK not to require a particular dash style, but not even stating a preference is, in my opinion, a mistake. – Doug Bell talkcontrib 04:07, 4 February 2006 (UTC)

No one can agree on it, so it sits in limbo for now.  :-\ — Omegatron 04:44, 4 February 2006 (UTC)
I agree with Doug Bell. My ideal policy would be that we always use proper em and en dashes, but I think mandating hyphens would be a better solution than "do what you like, but don't change anything". Can't this just be voted on once and for all? Surely Wikipedia has settled thornier issues than this... —Chowbok 22:51, 2 March 2006 (UTC)
It should be "do what you like, but x is preferred. don't revert if people change to x." — Omegatron 03:10, 3 March 2006 (UTC)
I agree. And as I've said elsewhere on this page, flush em dashes are the only style—short of inventing a nonstandard &dash; entity—with a prayer of automatically extracting semantic dashes if someone wanted to automatically convert Wikipedia to a different dash style. (PS: Is it a coincidence that this is the only Wikipedia discussion I've read in which all participants sign with a Unicode em dash? :-) ) —BenFrantzDale 04:10, 3 March 2006 (UTC)
I second the agreement with Omegatron's recommended wording. Do we really need a vote to determine what the preferred x style is?—it seems pretty obvious to me. (I've changed my signature from an en dash with spaces to an em dash with no spaces as a sign of support. :-) —Doug Bell talkcontrib 02:27, 18 March 2006 (UTC)

I usually change double hyphens, spaced hyphens, and spaced dashes to flush em dashes when I see them, especially when they are inconsistently used in an article. I don't make it a crusade, just clean it up when I'm editing something else. Em dashes must look fine, because no one ever complains or reverts. Michael Z. 2006-03-03 03:43 Z

I think Omegatron's solution is exactly right. It won't effect anybody who doesn't want to bother with correct dashes, but we'll gradually move to proper usage. And I don't see why x should be so hard to resolve. These aren't actually controversial issues in the publishing world (unlike disputes like, say, the serial comma or the possessive of singular words ending in "s"); em dashes break up sentences, en dashes signify ranges and are used for compound hyphenation. —Chowbok 02:42, 18 March 2006 (UTC)
Why are unspaced better? — Omegatron 03:46, 18 March 2006 (UTC)
To appeal to authority, unspaced em dashes are the style used by CMS and by Strunk & White. —BenFrantzDale 05:07, 20 March 2006 (UTC)

We actually seem to have reached some sort of consensus here. Can we change the policy, then? —Chowbok 01:51, 26 April 2006 (UTC)

Sorry to rain on the parade, but I don't think 5 people is much of a consensus for the whole encyclopedia. I'd love to see an em-dash as preferred style for parenthetical clauses and similar breaking, but am very much against flush or hair spacing. Flush spacing, though common in print, is far from universal, and at Wikipedia seems to be in the minority of articles I've worked on (before tweaking them, that is). Hair spacing looks nice as displayed, but isn't worth the editing annoyance, especially when ordinary spaces look fine as well. — Jeff Q (talk) 02:18, 26 April 2006 (UTC)
Fine, let's ignore the spacing issue for now. Can we at least say that 1) it's okay to put in hyphens or em/en dashes; 2) it's okay to replace hyphens with em or en dashes, as appropriate; and 3) it's not okay to replace em or en dashes with hyphens? —Chowbok 04:03, 26 April 2006 (UTC)
  • Support. Jeff Q (talk) 04:09, 26 April 2006 (UTC)
  • Support. (Seems like the sensible place to develop consensus on this is the dashes talk page, isn't it . . .) —Simetrical (talk • contribs) 03:08, 17 May 2006 (UTC)
  • Support, preferably with the addtion that changes from en dash to em dash or em dash to en dash are discourgaed. Jeltz talk 14:31, 21 August 2006 (UTC)
How come? The usage of those is pretty well-established (unlike with spacing). —Chowbok 18:21, 21 August 2006 (UTC)
Well established? I have seen both en dashes and em dashes used in serious typograhy (news papers, books). I think we should ignore en vs. em for now since there is no well-established rule there that all of the typograhic world agree on. Jeltz talk 11:22, 22 August 2006 (UTC)
Right, both should be used. Whether it's an em or an en depends on the usage. Can you give me an example of a book that uses one or the other contrary to the standards? —Chowbok 16:00, 22 August 2006 (UTC)
Hmmm, I feel like we might be talking about different things. What I'm talking about is that both en dashes and em dashes can be used for parentethical purposes, depnding on what you prefer. See Dash#En_dash_versus_em_dash for what I'm referring to. Jeltz talk 17:49, 22 August 2006 (UTC)
  • Support, of course. Ignore the spacing issue, and the en vs em issue for now. (Of course, Mediawiki should just replace -- with — automatically.) — Omegatron 15:13, 21 August 2006 (UTC)
I personally prefer the LaTeX style where -- is replaced with – and --- is replaced with —. That way you can write both. Jeltz talk 11:24, 22 August 2006 (UTC)
I used to argue for that style, too.  :-) After creating the dash fixer, I realized that there is a vast number of double hyphens on Wikipedia already from people who learned it in typing class, and a few who just use a hyphen. Might as well just go with what they already use. (Besides, they'd just end up typing -- anyway, out of habit, getting an en dash, and leaving it that way; so we'd have ens everywhere we were supposed to have ems.) It could still be possible to create both dashes, if we were smart with the implementation. I tried to write up a Dash syntax summary, but never finished it. — Omegatron 11:45, 22 August 2006 (UTC)

[edit] X11

Following section was rather misleading, since e.g. most linux distributions have switched from xmodpad into using xkb, and the provided example does not work.

Under recent versions of X11, the shell command

xmodmap - <<EOT
keysym m           = m           NoSymbol U2014 NoSymbol
keysym n           = n           NoSymbol U2013 NoSymbol
keysym KP_Subtract = KP_Subtract NoSymbol U2212 NoSymbol
EOT

will add the em dash (—) to AltGr-M, the en dash (–) to AltGr-N, and the minus sign (−) can now be obtained by pressing the minus key on the numeric keypad while holding the AltGr key.

[edit] Ndashes are shorter than hyphens

Notice:

–––––––––––––––––––– twenty ndashes
-------------------- twenty hyphens
01234567890123456789 twenty digits

At least in my Lucida default font, the hyphen is at least a pixel longer than the ndash, contrary to this MoS section, and the hyphen matches the width of numbers, not the ndash.

So what I'm saying is, unless Lucida is unusual in this respect, please stop replacing hyphens in number ranges with ndashes. Thank you. --James S. 15:16, 16 February 2006 (UTC)

For the record: the character you describe as "hyphen" is the Unicode character U+002D called HYPHEN-MINUS. This is an old overloaded ASCII character that has in the past been used as both a HYPHEN (‐) and a MINUS (−). Some font designers make HYPHEN-MINUS look more like a hyphen (short), others make it look more like a minus (longer, higher, matching +). As long as there is no easy way to enter the proper unambiguous Unicode HYPHEN on non-specialist keyboards, this problem will persist. Markus Kuhn 19:19, 24 March 2006 (UTC)
If that is ineed the case, then your copy of Lucida is quite unusual. The computer I am at right now has crappy fonts installed, but I am quite sure that at home the above would render with the first line longer than the second and with the line of numbers longer than the hyphens. Compare:
–––––––––––––––––––– twenty ndashes
NNNNNNNNNNNNNNNNNNNN twenty Ns
These should be very close to the same length.
What operating system and browser are you using? —BenFrantzDale 16:13, 16 February 2006 (UTC)
Lucida Grande has an unusually long hyphen; I assume other Lucidas do too. Normally a hyphen is very short, indeed. Michael Z. 2006-02-16 16:27 Z
Okay, that's just bizarre. My copy of Lucida Sans has en dashes longer than hyphens, but in Lucida Sans Unicode the hyphens are longer. Why would they do this? How dumb.
But yes, that particular Lucida is extremely unusual in that respect, so we shouldn't base policy on it. —Chowbok 17:48, 20 March 2006 (UTC)
If you have Lucida Sans Unicode installed, this should demonstrate it:
–––––––––––––––––––– twenty ndashes
-------------------- twenty hyphens
01234567890123456789 twenty digits
Chowbok 17:54, 20 March 2006 (UTC)
Whereas plain Lucida Sans has
–––––––––––––––––––– twenty n-dashes
-------------------- twenty hyphens
01234567890123456789 twenty digits
nnnnnnnnnnnnnnnnnnnn twenty n's
The behavior of Lucida Sans Unicode is unusual and should be ignored. Arial, the default font, gives all elements their expected widths:
–––––––––––––––––––– twenty n-dashes
-------------------- twenty hyphens
01234567890123456789 twenty digits
nnnnnnnnnnnnnnnnnnnn twenty n's
Notice how the n-dashes are precisely as long as the n's. —Simetrical (talkcontribs) 03:19, 17 May 2006 (UTC)

[edit] Meta: navigation

The Template:Style (edit talk links history) at the top of WP:MOSDASH made navigation more difficult than necessary. I've moved it to the bottom and filled out the missing shortcut in Template:Style-guideline. - Omniplex 18:02, 28 February 2006 (UTC)

[edit] Dashes not used on Wikipedia

The article states neither the figure dash ("‒") nor the quotation dash ("―") should be used in Wikipedia articles because browser support for them is lacking. Is that still true? Under Mac OS X 10.3.9 (2003) they are rendered correctly: not only in the current version of Safari, but also in a 2003 version of Camino (a Mozilla-based browser) and in a 2001 version of Internet Explorer. Ian Spackman 08:13, 24 March 2006 (UTC)

As of 2005, the support of the UTF-8 end dash (–), em dash (—) and minus sign (−) in web browsers has been excellent and there is no reason not to use these characters in Wikipedia. Even VT100-terminal based text-mode browsers such as w3m or lynx haven't had problems with them for many years. I don't know whether the same can already be said for figure dash and quotation dash, which are missing in most commonly-covered Unicode subsets, including WGL4. Markus Kuhn 19:10, 24 March 2006 (UTC)

[edit] Article text now outdated after UTF-8 switch

This policy page needs to be throoughly reviewed for technical inaccuracies after the Wikipedia UTF-8 switch. I found one specifically wrong passage, and I suspect there may be others.

Use the HTML entity &mdash;, which the MediaWiki engine automatically converts into a numeric entity in the rendered HTML.

First, this appears to contradict the up-front, emphasized statement about using UTF-8 characters. The context suggests its point was recommending the type of dash, not necessarily the preferred means to use it, but that's my point — it doesn't comprehend the availability of UTF-8. Second, it's most definitely wrong about rendering "&mdash;" as a numeric entity — it's rendered as a UTF-8 em-dash character, as it should be. I suspect that whoever added the bold-statement update to the top didn't examine the rest of the article for now-inaccurate statements or undesirable advice. I'd be bold and do an update myself, but I'm not confident enough of my knowledge about these topics. (I had to do some careful testing just to be sure of even the single case I'm mentioning here.) ~ Jeff Q (talk) 11:45, 5 April 2006 (UTC)

Yes, the person who added the bold statement at the top (me) didn't alter the rest of the article very much. Originally it was more like a "this page is invalid now" notice. — Omegatron 14:08, 5 April 2006 (UTC)
I do have a problem with encouraging the use of the UTF-8 characters in wiki source, because n-dash looks exactly like a hyphen in the edit box, at least in Windows Courier (m-dash, while a hair longer, also looks the same unless you compare them carefully side-by-side). It's fine for the original editor, but (a) it can lead to confusion for subsequent editors ("hey, that's a date range, why did he put a hyphen there?") (b) it can mislead newcomers who use existing articles for style guidance, when all they can see is a dash (c) it can lead to a pointless discussion such as the one I just had with User Quoth over what I thought was the replacement of a &ndash; with a hyphen in John Wilkes. It takes a true geek to look at an edit box and figure out whether one is looking at an ASCII hyphen or a typographically correct dash.
Can we at least (1) say Entity and Unicode character are both valid; do not jump into an article and replace an HTML entity with a Unicode character just because you can (2) have the link in the Insert box create the entity instead of the Unicode character. David Brooks 00:09, 17 April 2006 (UTC)
But that makes the wikicode harder to read and more intimidating to the "technically impaired". Better to force the "true geeks" to deal with the complexity of unicode characters than to make it harder on all the regular people editing content by inserting all kinds of confusing HTML.
Ideally, the software would recognize all the major cases in which each type of dash is used and generate them automatically (and curly quotes, too, while we're at it). The special cases could be handled with nowiki tags just like everything else. But no one seems to want to implement this. Textile does it. — Omegatron 02:26, 17 April 2006 (UTC)

[edit] Birth–death dates

A discussion at Wikipedia talk:Manual of Style (dates and numbers) has revealed an overwelming consensus (with, I think, only one editor disagreeing) for the use of en-rules for connecting birth and death dates. As this is the universal English standard, is there a reason for not making it the Wikipedia standard? Editors wouldn't of course (indeed, couldn't) be forced to use it, but I can't imagine why any editor would complain because a hyphen had been corrected to an en-rule. --Mel Etitis (Μελ Ετητης) 16:08, 15 May 2006 (UTC)

Proposing to keep Wikipedia talk:Manual of Style (dates and numbers)#n dash as central discussion place on this issue. --Francis Schonken 16:48, 15 May 2006 (UTC)
That certainly seem to be the wisest approach. --Mel Etitis (Μελ Ετητης) 22:17, 15 May 2006 (UTC)

[edit] Special character list

The character to the left of the emdash (—) on the special character list under the edit box (–) appears to be an ndash (–). If this is correct, it would be helpful to have this fact added to Omegatron's bolded notice at the top of the article, for the benefit of casual skimmers of the page. With the broad lack of consensus over the styles discussed on this page, I don't feel so bold as to make the change myself. --Blainster 16:12, 18 May 2006 (UTC)

I second that, and I do feel so bold. —71.208.125.132 22:38, 1 September 2006 (UTC)

[edit] Negative numbers

I'd like to propose that negative numbers should use the traditional "hyphen/dash" character "-" rather than −. I believe this usage would make pages easier to maintain, and that pages using another convention would probably gradually migrate to this anyway just because of editor ignorance and common usage outside this wiki. I can see using − for subtraction in mathematical expressions (where length may be important for aesthetic reasons), but for plain negative numbers, I think the one or two pixel difference in length isn't worth the trouble. Thoughts? --P3d0 17:57, 23 July 2006 (UTC)

I just type minus in in Unicode (0x2212) like this: −. This shows up as correctly on the page and in the edit window. Anal typographers will certainly change dashes to minuses. I see no reason to avoid good typography when we have the tools to easily do it. —Ben FrantzDale 05:23, 24 July 2006 (UTC)
Generally, “+1-microsecond error” and “−1-microsecond error” look okay, but “-1-microsecond error” doesn’t look elegant, could be even confusing. Compare:
  • -1- to -5-microsecond error
  • −1- to −5-microsecond error
U+2212 should be encouraged for more readable, non-ambiguous typesetting, although U+002D for the MINUS sign should not be disallowed. —Gyopi 06:22, 24 July 2006 (UTC)

[edit] Dashes In Foreign Languages

i'm a new editor to wikipedia, so i don't know if this issue has been raised already somewhere else, and i'm not sure this is the correct place to post it. if it isnt, pick my discussion up, and put it where it goes. tell me on my user page where u put it, or i'll just come back here for responses. here goes: hyphens are used frequently in french (Ile-de-France) and arabic (Burj al-Arab). i'm guessing the short guy (hyphen-minus) is the correct one to use? its the only one i've ever seen used in those languages. and in french, when do we put hyphens in phrases? i think the french department's name of "Loir-et-Cher" literally means "Loir and Cher". since english doesnt put hyphens there, does french really need them? i've seen people's and places's proper names with and without hyphens. are francophones arguing about whether to put or not put them, as much as anglophones are arguing about which type of dash to use? perhaps this is clarified in the french-language style manual, but im not a francophone. someone lemme know.4.230.174.207 01:57, 11 August 2006 (UTC)

There is actually a very specific hyphen character: Unicode U+2010 hex (8208 decimal)—but it may not be widely supported in fonts or browsers.
In your browser/font it looks like this: ‘‐’. (Looks about right in Safari.) Ian Spackman 00:49, 26 August 2006 (UTC)
It looks like a hyphen to me in Firefox on Ubuntu. Jeltz talk 10:07, 26 August 2006 (UTC)

[edit] Clarification re dashes separating surnames in page names

Gene Nygaard and I have been having a discussion on dashes in pagenames that could perhaps be clarified by a discussion here.

Specifically, it concerns dashes in the names of pages such as Erdős–Straus conjecture that involve subjects named after multiple people. Clearly in text such phrases should use en-dashes but we are disagreeing on whether the same is true as part of a page name. MOSDASH says "Hyphens and dashes are generally rather avoided in page names" but it only specifically talks in that passage about numeric ranges, and also says that for greater precision dashes can be used (with appropriate redirects). I think that "precision" can be interpreted here to mean that dashes are appropriate as a signal that the page name refers to two people instead of to one person with a hyphenated name, while Gene thinks the preference for hyphens over dashes takes precedence. Also, the first example of a dash between names in MOSDASH is a seemingly-approving link to Poincaré–Birkhoff–Witt theorem; I think this example supports the position that dashes should be used in this context while Gene thinks that the dashed page name is a historical artifact related to the fact that the page name policy of MOSDASH was merged from elsewhere some time after that example was added.

Also, and I'm not sure how relevant this is, but in the specific case of Erdős–Straus conjecture the url already has percent-encoded unicodes, so hyphens aren't needed to keep the url pretty.

I'm happy to abide by whatever the consensus is on this issue, and I don't really want to turn this into an attempt to change policy, but I would like a broader sample of opinion on what the existing policy actually is. Anyone?

If anyone cares to see our existing discussion on the issue, it's here.

David Eppstein 05:55, 8 October 2006 (UTC)

Note that Wikipedia:Naming conventions main page now specifically defers to this MoS page for naming as well as use in articles, and the naming discussion on this MoS page is a recent addition here. I don't know where all the past discussions of this issue with respect to article names have taken place, but I do know that such discussions exist.
Erdős–Woods number has a redirect from Erdős-Woods number, because it is a remnant that was left behind when Daniel Brockman moved the page.[1] If use of dashes in this context in the article names is encouraged, there will be a great many of them created without having that redirect from the hyphen form, just as we now have a huge number of article names with diacritics in the names which do not have the redirects from the English-alphabet spellings.
Look at this list, then answer the following questions: Erdős-Woods, Erdős - Woods, Erdős‐Woods, Erdős‑Woods, Erdős‒Woods, Erdős–Woods, Erdős−Woods.
  1. How many different hyphens do you see as you view this page as you'd normally read it?
  2. How many different hyphens/dashes do you see when you view it in edit mode (normally displayed in a different font)?
  3. How many of the seven in the above list above are true duplicates?
  4. How many other distinct possibilities could other editors come up with?
Now, take a look at some of those possibilities contained in links to possible article names/redirects:
  • Erdős‐Woods number
  • Erdős‑Woods number
  • Erdős‒Woods number
  • Erdős—Woods number
  • Erdős−Woods number
  • ErdősߟWoods number (quotation dash displays as question mark on my computer)
As you can see, lots of missing redirects as I post this.
Even more important, as far as the article naming question goes, if a link is made on a page as [[Erdős&#150;Woods number]] (displays as Erdős–Woods number) or as [[Erdős&#x96;Woods number]] (displays as Erdős–Woods number) or as [[Erdős&ndash;Woods number]] (displays as Erdős–Woods number), the latter has apparently been tweaked by the software to work (something we know to be true because when it gets there, it doesn't say "Redirected from"), but the first two remain redlinks as I type this, even though all three display as exactly the same en dash on the page, the same as if the character – were used in them (and we know from above the link works when that is used, and in fact that is the article rather than a redirect).
Additional missing redirects only peripherally related to the issue at hand in this discussion and not included in the list above: hyphen Erdös-Woods number, en dash Erdos–Woods number and Erdös-Woods number. Note that encouraging use of dashes in article names would often mean that several new redirects should also be created (yet, in most cases, will not be done by the person creating or moving the article). Gene Nygaard 13:39, 8 October 2006 (UTC)
Here is an additional problem related to the failure to make the situation clear, and a failure within this MoS project page to maintain a clear distinction to the naming-conventions role which has been passed here, and other uses. We can easily end up with copy-and-paste clone articles (which can then diverge from each other), something which has already happened at Bose–Einstein condensate (page history) and Bose-Einstein condensate (page history). Gene Nygaard 13:56, 8 October 2006 (UTC)
I feel we ought to keep ease for the reader as a top consideration, which would mean preferring hyphens (which exist on keyboards) to en-dashes (which generally don't). The name should be something the reader can easily type into the search box and find. Nareek 15:20, 8 October 2006 (UTC)
Just make the hyphen version a redirect to the en dash version. — Omegatron 16:16, 8 October 2006 (UTC)
As you can see, that doesn't get done. And it is often not "a" redirect that is needed, but many redirects. People who see an en-dash version are likely to write it with &#150; or other things that don't work in links, or use ‒ instead of –, which doesn't work, or use − instead of –, which also doesn't work, as well as using the hyphen/minus (-) instead of the en dash –. That's much less of a problem if we have a rule to use the hyphens in the article names, and dashes only in redirects. People using ‒ or − and getting a redlink are more likely to think of turning it blue by using a hyphen than they are to discover that – is the character they really want, rather than one of the others that is nearly identical to it.
Encouraging use of dashes in article names will result in more inadvertent creation of duplicate articles (oblivious to the existence of the other) than continuing to recommend hyphens in article names will. Gene Nygaard 17:31, 8 October 2006 (UTC)
This isn't any different than any other naming convention. Many have special characters. Just make it very clear that redirects are necessary. — Omegatron 11:59, 14 October 2006 (UTC)
All those different variations will exist regardless of which one the policy tells us to use as the pagename. That's why the policy also says to put in the redirects. But if the search box can't find one of those names when people type in a different one, isn't that a flaw in the search box rather than a flaw in the naming convention? —David Eppstein 16:36, 8 October 2006 (UTC)
Yep. — Omegatron 11:59, 14 October 2006 (UTC)
The different variations will exist; but it is more broken, more of a serious problem, for links using the characters we do have on our keyboards not to work, than it is for characters we do not have on our keyboards not to work.
Furthermore, we need to work with what we have. We want to make our information accessible, now. If you want to claim that new features should be added to our software, go right ahead, but that isn't particularly relevant to what we have now. Gene Nygaard 17:31, 8 October 2006 (UTC)
I don't know about yours, but the en-dash is definitely a character on my keyboard: option-minus. —David Eppstein 17:46, 8 October 2006 (UTC)
Even that isn't exactly "on" your keyboard, and is a feature unfamiliar to many users with computers like yours—but as you already know, the computers which have an "option" key to even make that possible are a minority. Gene Nygaard 18:25, 8 October 2006 (UTC)
Seems to me like a mediawiki problem. If the average user isn't going to know the difference between four or more different symbols that all look near-identical, why not just define them to be the same, like has already been done with the capitalization of the first letter? We'd need a way to solve conflicts that the initial change would cause, naturally, but in the end, I think we'd have a far more user-friendly system. Where there's an actual difference in meaning between two or more, we can use a disambiguation of some kind. -FunnyMan 01:49, 14 October 2006 (UTC)
You mean "Why doesn't someone finish the {{DISPLAYTITLE|}} magic word and set rules for when it is appropriate?"
Probably, yes. Like one of the editors above I use a Mac and, since they are all easy to type, I am moderately scrupulous/pedantic about using hyphens, en rules and em rules as I see fit at a given moment in time. However, while article titles should certainly be typographically correct in their canononical and display forms (the main ugliness is the near-universal use of
'
when what is meant is
), it seems to be to be pretty barmy that a-1, a–1 and a—1 could all be distinct articles. Come to that I would certainly also like to see automatic case-insensitive redirects. —Ian Spackman 12:20, 14 October 2006 (UTC)
THIS WEB:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2007:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2006:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu