![]() | This is the
talk page of a
redirect that targets the page: • Wikipedia:Manual of Style Because this page is not frequently watched, present and future discussions, edit requests and requested moves should take place at: • Wikipedia talk:Manual of Style |
![]() |
Manual of Style ![]() ![]() | |||||||||
|
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)
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 ( U T C)
Or, to put the same question otherwise: is something wrong with that? -- Francis Schonken 00:27, 13 January 2007 (UTC)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.
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)
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)
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 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)
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)
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)
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)
So you use hyphens to combine words, such as copy-editing correct? Howard Cleeves 19:36, 11 April 2007 (UTC)
The guideline currently reads
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)
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."
— SMcCandlish [ talk] [ cont] ‹(-¿-)› 18:26, 12 May 2007 (UTC)
See Talk:Dash#font_differences. ∞ ΣɛÞ² ( τ| c) 13:44, 30 May 2007 (UTC)
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)
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)
"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)
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)
Noetica's comments
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.
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)
Proposal 1—the removal of spaced em dashes from the dash guidelines
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:
New:
The following dash styles are used in Wikipedia:
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)
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
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:
New:
For page names:
_____
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)
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)
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)
![]() | This is the
talk page of a
redirect that targets the page: • Wikipedia:Manual of Style Because this page is not frequently watched, present and future discussions, edit requests and requested moves should take place at: • Wikipedia talk:Manual of Style |
![]() |
Manual of Style ![]() ![]() | |||||||||
|
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)
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 ( U T C)
Or, to put the same question otherwise: is something wrong with that? -- Francis Schonken 00:27, 13 January 2007 (UTC)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.
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)
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)
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 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)
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)
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)
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)
So you use hyphens to combine words, such as copy-editing correct? Howard Cleeves 19:36, 11 April 2007 (UTC)
The guideline currently reads
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)
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."
— SMcCandlish [ talk] [ cont] ‹(-¿-)› 18:26, 12 May 2007 (UTC)
See Talk:Dash#font_differences. ∞ ΣɛÞ² ( τ| c) 13:44, 30 May 2007 (UTC)
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)
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)
"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)
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)
Noetica's comments
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.
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)
Proposal 1—the removal of spaced em dashes from the dash guidelines
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:
New:
The following dash styles are used in Wikipedia:
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)
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
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:
New:
For page names:
_____
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)
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)
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)