Pmanderson (talk | contribs) |
|||
Line 741: | Line 741: | ||
:::::[[AP Stylebook]] and [[NYTM]] both use a hyphen in African-American, and I have never (until now) seen it with an en-dash. - Dan [[User:Dank55|Dank55]] ([[User talk:Dank55|talk]])([[Special:Contributions/Dank55|mistakes]]) 14:43, 1 July 2008 (UTC) |
:::::[[AP Stylebook]] and [[NYTM]] both use a hyphen in African-American, and I have never (until now) seen it with an en-dash. - Dan [[User:Dank55|Dank55]] ([[User talk:Dank55|talk]])([[Special:Contributions/Dank55|mistakes]]) 14:43, 1 July 2008 (UTC) |
||
*Noetica needs to be horse-whipped, then. [[User:Tony1|<font color="darkgreen">'''TONY'''</font >]] [[User talk:Tony1|<font color="darkgreen">(talk)</font >]] 18:14, 1 July 2008 (UTC) |
|||
== Straight and typographers quotes == |
== Straight and typographers quotes == |
Revision as of 18:14, 1 July 2008
En dash or em dash in tables?
I'm finding it unclear whether ndashes (–) or mdashes (—) should be used in tables to mark "empty cells". For some reason I remember reading it somewhere, perhaps in an old version of the MOS, that mdashes should be used. This is also what a lot of WP:FLs use (though this may in part be because I always say they should be used in my WP:FLC reviews). A recent discussion at WT:FLC#hyphens in blank squares: why not en dashes? brought this issue up, and I just wanted to get a firm answer from the caretakers of MOS. Once this has been confirmed, could a line please be added to WP:DASH. Thanks! Matthewedwards (talk · contribs · count · email) 05:08, 8 June 2008 (UTC)
- I would propose one em dash since it's "fuller" than the en dash. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 16:51, 9 June 2008 (UTC)
- In any event, using two dashes, be them en or em dashes, is probably not an option. A single character ought to be used. Waltham, The Duke of 20:50, 9 June 2008 (UTC)
- I agree with His Grace. And it's a matter of balancing the too small and the too large. To me, the en dash is just right: big enough to be unambiguous; not so big as to draw attention to itself, away from the substantive information in other squares. TONY (talk) 02:30, 10 June 2008 (UTC)
- I also agree that only one should be used, rather than two. WP:HYPHEN states not to do --, so it would be odd to advocate –– or ——. Whether – or — is used, I don't mind. My only concern is consistency, and many lists use a dash to identify "N/A" information. Matthewedwards (talk · contribs · count · email) 02:40, 10 June 2008 (UTC)
- I prefer em-dashes, but in the grand scheme of things I don't think it's that big of a deal. The important thing is that we're consistent. Drewcifer (talk) 09:51, 11 June 2008 (UTC)
- Why? Why does it matter? We have dozens of ways of making tables; why does this one variation matter any more than the variation between all dashes and "N/A"? Septentrionalis PMAnderson 18:37, 11 June 2008 (UTC)
- If you're going to ask that, you might as well ask "What's the point of the MOS at all?". There are many many different ways of doing anything, and the MOS is here to standardise it. There is already a section on WP:HYPHEN and WP:DASH which explain which and how they should be used in prose, this will just explain which and how they will be used in tables. Matthewedwards (talk • contribs • email) 18:59, 11 June 2008 (UTC)
- What's the point of the MOS at all? To provide advice where useful, reasons for the various positions that literate English can take, and rules where there is project-wide consensus. Most of this page does not satisfy any of those criteria, but that's its fourth value: to show what a guideline page should not be. Septentrionalis PMAnderson 19:13, 11 June 2008 (UTC)
- If you're going to ask that, you might as well ask "What's the point of the MOS at all?". There are many many different ways of doing anything, and the MOS is here to standardise it. There is already a section on WP:HYPHEN and WP:DASH which explain which and how they should be used in prose, this will just explain which and how they will be used in tables. Matthewedwards (talk • contribs • email) 18:59, 11 June 2008 (UTC)
- Why? Why does it matter? We have dozens of ways of making tables; why does this one variation matter any more than the variation between all dashes and "N/A"? Septentrionalis PMAnderson 18:37, 11 June 2008 (UTC)
- I prefer em-dashes, but in the grand scheme of things I don't think it's that big of a deal. The important thing is that we're consistent. Drewcifer (talk) 09:51, 11 June 2008 (UTC)
- I also agree that only one should be used, rather than two. WP:HYPHEN states not to do --, so it would be odd to advocate –– or ——. Whether – or — is used, I don't mind. My only concern is consistency, and many lists use a dash to identify "N/A" information. Matthewedwards (talk · contribs · count · email) 02:40, 10 June 2008 (UTC)
- I agree with His Grace. And it's a matter of balancing the too small and the too large. To me, the en dash is just right: big enough to be unambiguous; not so big as to draw attention to itself, away from the substantive information in other squares. TONY (talk) 02:30, 10 June 2008 (UTC)
- In any event, using two dashes, be them en or em dashes, is probably not an option. A single character ought to be used. Waltham, The Duke of 20:50, 9 June 2008 (UTC)
- Yes, Anderson, we all know your contrarian views on MOS. Thank you for restating them again in case we'd forgotten them. IMO, en dashes should be the standard; ems are just too large and unnecessary draw attention from the substantive information in the table. TONY (talk) 02:17, 12 June 2008 (UTC)
- Yes, I have just stated three functions this page could have, which would be actually useful to the Wikipedian community at large. Would you care to explain at length why you disagree with them? Septentrionalis PMAnderson 02:52, 12 June 2008 (UTC)
- All unhelpful comments to the contrary aside: back to the matter at hand. It appears there is no clear consensus on the en-dash vs. em-dash thing, but that there is some agreement on the fact that there should only be one dash, and that it should indeed be a dash (as opposed to a blank cell or N/A). So can we agree at least that far? As far as the en vs em thing, can we just leave that part up to the user? Or should we make a hard and fast rule anyways, with the slight advantage above going to em-dashes? (3-1 in favor of it) Drewcifer (talk) 07:35, 18 June 2008 (UTC)
- Heh, it was on my to-do list for today to come here, reboot this thread and find out what the next step is in regards to getting something finalised and mentioned on the MOS page. I was beaten to it..! -- Matthewedwards (talk • contribs • email) 08:33, 18 June 2008 (UTC)
- Drewcifer's view finds me perfectly agreeable. We could try to make a decision here, but if it doesn't happen, something very likely (by the way, I prefer en dashes, so the score is now 3–2), a simple suggestion to avoid hyphens, double characters, and N/As would work. This is mostly a matter of appearance, after all, as the character will not affect any text. Waltham, The Duke of 18:27, 19 June 2008 (UTC)
- Could somebody check 13.33 of this Chicago Manual of Style page; its called "Empty cells". (Subscription required) indopug (talk) 01:06, 21 June 2008 (UTC)
- (←) Good idea, indopug. To quote the Chicago Manual of Style:
"If a column head does not apply to one of the entries in the stub, the cell should either be left blank or be filled in by an em dash or three unspaced ellipsis dots. If a distinction is needed between “not applicable” and “no data available,” a blank cell may be used for the former and an em dash or ellipsis dots for “no data” (see table 13.8). This distinction must be made clear in a note or elsewhere. (Alternatively, the abbreviations n.a. and n.d. may be used, with definitions given in a note.) A zero means literally that the quantity in a cell is zero (see table 13.3)."
- We've agreed against the empty cell, and I doubt three unspaced ellipsis are the way to go. So does that somewhat settle it in favor of the em-dash? Drewcifer (talk) 07:40, 22 June 2008 (UTC)
- CMOS alone? Why is that the only external reference? It's a very faulty publication, even if it's good in patches. I do wish they followed their own advice in the publication itself, but there are numerous anomalies, only pages' distance from the so-called rules. CMOS is for hard copy. Here, my feeling is that en dashes, not em dashes, are about the right size. Anderson will push his usual "anything goes" line (you wonder why we bother having a style manual), but I trust that will be ignored here in favour of basic consistency. TONY (talk) 08:47, 22 June 2008 (UTC)
- So far this is the only 3rd party source we have to go by. I checked my MLA manual, and it doesn't mention it. Drewcifer (talk) 08:50, 22 June 2008 (UTC)
- I have no manuals to go and look at but the CMOS is used prolifically, and so I ask let's follow their example. Matthewedwards (talk • contribs • email) 07:07, 23 June 2008 (UTC)
- So far this is the only 3rd party source we have to go by. I checked my MLA manual, and it doesn't mention it. Drewcifer (talk) 08:50, 22 June 2008 (UTC)
- CMOS alone? Why is that the only external reference? It's a very faulty publication, even if it's good in patches. I do wish they followed their own advice in the publication itself, but there are numerous anomalies, only pages' distance from the so-called rules. CMOS is for hard copy. Here, my feeling is that en dashes, not em dashes, are about the right size. Anderson will push his usual "anything goes" line (you wonder why we bother having a style manual), but I trust that will be ignored here in favour of basic consistency. TONY (talk) 08:47, 22 June 2008 (UTC)
- And I find that en dash are too small on monitors. While I do have a strong preference for em dashes because of their "fuller" look, I really don't see the harm in allowing users to choose between either, as long as they are being used consistently within an article, and that they are always centered. I would also like to see that users make sure that the significance of em/en dashes is in the table is clear. I would recommend something like the next table, but that might be too stringent. Headbomb {ταλκ – WP Physics: PotW} 13:32, 23 June 2008 (UTC)
Dash | Code | Meaning |
---|---|---|
- | - | Hyphen are not to be used to indicate anything in a table. |
− | − | Minus sign should only be used in the same way a plus sign (+) would. |
–?– | –?;&nash | Unknown/No data |
— | &emdash; | Not applicable |
Headbomb: So you suggest we do the PManderson thing and allow a choice between en and em dashes? I suppose on this occasion I could be swung around to agree, reluctantly. (Never let it be said that I'm inflexible!) And although your system of symbols in the table are logical and nicely worked out, I think they're too elaborate for this context. TONY (talk) 13:37, 23 June 2008 (UTC)
- Well like I said, I'm personally against en dashes as they are not visible enough in a table, and I will never use them unless there's a consensus that em dashes are evil. I would much rather have em dashes all across than a mix of en dashes and em dashes, but if we can't find consensus on this, then MoS shouldn't favor either. The table thing isn't meant as much more than a way to present things on the MoS. I'm a fan of tables, as they allow things to be summed up very neatly. See Common mathematical symbols for another example of the "summarization power" of tables. With em dashes, of course :P. Headbomb {ταλκ – WP Physics: PotW} 14:38, 23 June 2008 (UTC)
As I have said above, I am rather open on this one, mostly because it does not affect proper text. Unless some major advantage or disadvantage in either option transpires, I say we go with the "use either an en dash or an em dash, centred, and consistently within an article" principle. Although I find em dashes rather long for this use, it might actually depend on the width of a table's columns which one would look better. This is largely a formatting issue, so I advocate flexibility. Waltham, The Duke of 03:56, 25 June 2008 (UTC)
Paragraphs in block quotations
WP:MOSQUOTE recommends using <p>...</p> paragraph tags around each paragraph in a block quotation. An easier workaround is to nest a single div, then wikitext respects the line breaks correctly. So the example becomes:
<blockquote><div> And bring us a lot of horilka, but not of that fancy kind with raisins, or with any other such things—bring us horilka of the purest kind, give us that demon drink that makes us merry, playful and wild! —Nikolai Gogol, Taras Bulba </div></blockquote>
Result:
And bring us a lot of horilka, but not of that fancy kind with raisins, or with any other such things—bring us horilka of the purest kind, give us that demon drink that makes us merry, playful and wild!
—Michael Z. 2008-06-12 04:33 z
Language differences proposal
I have never stated a topic like this before, so I thought it might be best to start here. I believe that the minute differences in language and spelling between UK and US English can be reconciled using a translation system that is similar to the process that has been developed for the Chinese WIkipedia. Under their translation system, users have a choice of selecting either one of the following as their "viewing language" on Wikipedia:
- Traditional Chinese
- Traditional Chinese with Taiwan-specific vocabularies
- Traditional Chinese with Hong Kong/Macao-specific vocabularies
- Simplified Chinese
- Simplified Chinese with Mainland China-specific vocabularies
- Simplified Chinese with Singapore/Malaysia-specific vocabularies
I believe that this system has the potential to, in addition to bridge the difference in language, localize the encyclopedia for users in the wide and diverse Anglophone world. With this system in place, we can disregard the rules in regards to "-ize" or "-ise" or "-or" [as in behavior] or "-our" [as in labour].
So, I would like to put this out as a feeler, and see if anyone is interested in pursuing this further. Arbiteroftruth (talk) 06:27, 19 June 2008 (UTC)
- I'm not aware that anyone has written such "translation" software either inside or outside of Wikipedia. I'd love to have some kind of tool like this, but I'm dubious. There are plenty of British TV programs (sorry, programmes) in which the language still sounds foreign to me, despite years of effort to pick up the language. - Dan Dank55 (talk)(mistakes) 11:53, 19 June 2008 (UTC)
- And that's the point of my proposal. We can completely localize Wikipedia for all English users, so British articles will look American to our American users. Someone will need to contact the Chinese Wikipedia on their translation softwares though. I know they exist, but I don't know how it works on a deep level. I do, however, know how it roughly functions.
- Their translation software functions through a set of keywords, and whenever they see those keywords, they will convert them from Traditional to Simplified, or vice versa. However, these conversions, due to the intricate nature of Traditional and Simplified Chinese, don't always work properly, so a template was established that allows a conversion to occur on a per-article basis. I believe with this, we can "separate" our Wikipedia into two major languages: US English and UK/Commonwealth English, without actually forking the project (foolish to do so, I would say), and have both of the "editions" to be readily accessed. Arbiteroftruth (talk) 13:40, 19 June 2008 (UTC)
- Sounds like a can of worms to me, technically and in terms of the politics. I kind of like the melting pot we have of accepting and editing in each other's variety, enabled by the within-article-consistency rule, which works beautifully. The differences between our varieties, let's face it, are superficial—much less of a deal than between those Chinese dialects listed above. And there's the business of proper nouns, quotations and references. Oh, what a mess it would be. TONY (talk) 13:57, 19 June 2008 (UTC)
- Their translation software functions through a set of keywords, and whenever they see those keywords, they will convert them from Traditional to Simplified, or vice versa. However, these conversions, due to the intricate nature of Traditional and Simplified Chinese, don't always work properly, so a template was established that allows a conversion to occur on a per-article basis. I believe with this, we can "separate" our Wikipedia into two major languages: US English and UK/Commonwealth English, without actually forking the project (foolish to do so, I would say), and have both of the "editions" to be readily accessed. Arbiteroftruth (talk) 13:40, 19 June 2008 (UTC)
[after numerous edit conflicts] Would it require us to mark it up? e.g. "The {{color}}s of the rainbow are..." Who would determine the mapping? e.g. who decides whether UK "elevator" must map to US "lift"? And how do you decide when US lift means UK elevator, and when it just means lift. Surely there are situations where a two similarly spelled UK words map to a single US word, or vice verse; how would such mappings be handled? How would quotations be handled? Would it fix article titles too? Hesperian 14:02, 19 June 2008 (UTC)
- Ditto Tony: I like the local colour given by the variants: it's not as if it ever causes problems in comprehensibity, and it doesn't hurt us to be reminded that there's more than one way to skin a cat almost-instinct 14:07, 19 June 2008 (UTC)
I see Wikipedia, and more generally the internet, as a force that will eventually re-unify the English language, after a long natural process. In my opinion that's a good thing, not something to be prevented using technical means. The Chinese situation is special for two reasons: The traditional/simplified split hasn't grown organically but exists for political reasons. And as far as I know the Chinese writing system is used as a kind of interlingua between several mutually unintelligible languages. In that respect it's probably a bit like having a single Wikipedia for Spanish, Catalan and Portuguese (except that the Catalans would certainly be opposed to such a proposal). --Hans Adler (talk) 14:31, 19 June 2008 (UTC)
- I doubt the translation could be complete, and a partial translation would be unpleasant. Consider "the red-colored woolen jumper" where colored was translated because the software could handle it, but jumper was not because the translator didn't know if it meant a sweater or a skydiver. --Gerry Ashton (talk) 14:34, 19 June 2008 (UTC)
- Hans Adler, I partially agree. English has been and is subject to both centrifugal and centripetal forces. The Internet is just the most dramatic source of the increase in the centripetal in that balance—an increase that had been growing more gradually since the introduction of telegraphy, telephony and the rest of the ITC structure that has emerged over the past 150 years. But English is and will continue to be subject to centrifugal forces among non-native speakers around the world, who have a right to their own brand of the language. It will essentially become more and more a binary structure: the standard native ancestral English of the eight or so countries that might be classified as such; and a wealth of fragmented non-native local varieties, rich in their own ways. TONY (talk) 16:18, 19 June 2008 (UTC)
I want to make a response to the aforementioned questions here.
Regardless of whether English will be reunified in the future, we are dealing with the present. At this point in time, there are variations between different forms of English. Now, as far as server-side translation goes, it can be cumbersome, which is why I believe the per-article translation solution (in Chinese Wikipedia, they do this through a template) is a solution that fits our situation better for region-specific words. For words such as "colo[u]r", the server-side solution will be a better fit. This combination of solutions will do the trick. Now obviously, the problems with Chinese Wikipedia is much bigger than ours (theirs deal with readability, ours deals with the more minute matters that will not render a page unreadable), but I wanted to propose this to see where we can go with it. I think localization, while not an urgent matter, will make English Wikipedia much more special, and can serve to eliminate some of the rules that goes with styles and grammar (we can dispose with those regarding region-specific spellings) if this is implemented. Arbiteroftruth (talk) 17:20, 19 June 2008 (UTC)
Now, to give a sense of how the per-article translation thing can work, I will show you how those editors over at the Chinese Wikipedia deal with this.
They have this template that manually translates specific words within an article, which is the solution we can implement in our case. For example, let's say we are dealing with Harry Potter and the Sorcerer's Stone (film). The English title is different. So, we do it as follows:
---
{{noteTA (the title name for the Chinese Wikipedia translation template)
|T (for page title)=en-us (for US English): Harry Potter and the Sorcerer's Stone (film); en-com (for Commonwealth English): Harry Potter and the Philosopher's Stone (film)
|1 (for word 1)=en-us: Harry Potter and the Sorcerer's Stone; en-com: Harry Potter and the Philosopher's Stone
}}
---
So this is how it could work. It doesn't require too much markups. One template takes care of all words mentioned on that very page. No fuss. Arbiteroftruth (talk) 17:31, 19 June 2008 (UTC)
- I wouldn't call this "no fuss", especially if the main purpose is to hide from clueless Americans the fact that there are people out there who speak and write a different variant of English. Or to have a technical solution that allows us to serve the Great Fire of London as the "Great Fire of London, England" to all those who need this explanation (so they don't book a ticket to nearby London, Ontario to see how much is left of the Roman city walls) without bothering the Brits with this nonsense. We are not a company who try to make money off a perfectly polished product; Wikipedia can afford this kind of rough edges. And one of the strengths of Wikipedia is that it's relatively immune to feature creep. --Hans Adler (talk) 17:50, 19 June 2008 (UTC)
- Hear, hear. This is, to use an expression I've seen several times lately, a solution in want of a problem. Sure, there are some debates here and there, but the language issue is not causing any significant disruption (excluding this page :-D). The implementation of this proposal would significantly complicate page syntax, confuse editors (most of whom edit across the linguistic board), and engage server and editor resources for little practical gain (all articles are, or at least should be, legible to all readers right now, and the feature would probably only be available to registered users). Basically, it's more trouble than it's worth. I see no reason to compartmentalise the different language variants—with unforeseeable results on the quality of prose—and there are more important things to use our resources on anyway. Waltham, The Duke of 20:48, 19 June 2008 (UTC)
- If I may offer a slight correction, Your Grace, this is an unworkable solution in want of a problem. Hesperian 01:43, 20 June 2008 (UTC)
- Hear, hear. This is, to use an expression I've seen several times lately, a solution in want of a problem. Sure, there are some debates here and there, but the language issue is not causing any significant disruption (excluding this page :-D). The implementation of this proposal would significantly complicate page syntax, confuse editors (most of whom edit across the linguistic board), and engage server and editor resources for little practical gain (all articles are, or at least should be, legible to all readers right now, and the feature would probably only be available to registered users). Basically, it's more trouble than it's worth. I see no reason to compartmentalise the different language variants—with unforeseeable results on the quality of prose—and there are more important things to use our resources on anyway. Waltham, The Duke of 20:48, 19 June 2008 (UTC)
The problem with this idea is that it isn't ambitious enough. We should be internationalising all vocabulary and grammar. For example, instead of writing
- great idea
, we would write
- {{adjective-noun-pair|{{great}}|{{idea}}}}
This would expand to great idea for English speakers, but the {{adjective-noun-pair}} template would know to put the adjective after the noun for French speakers, and the other templates would expand to French words for them, so for them this markup would yield
- idée excellente
(Of course, we couldn't actually call those templates adjective-noun-pair, great and idea; we would have to come up with language neutral terms.) If enough effort was put into templatizing the grammar and vocabulary of every language and language variant in the world, then we could abandon this ridiculous idea of having a Wikipedia in each language, and write a single Wikipedia that could be read in the language of choice. The efficiency gains would be enormous, the only, very minor, downside being that only a handful of savant linguists would be able to contribute. Hesperian 02:11, 20 June 2008 (UTC)
- P.S. Yes, I am being sarcastic, and yes, I already know that I know nothing about French. Hesperian 02:11, 20 June 2008 (UTC)
- It might be of interest to you that this relic of French, namely nouns preceding adjectives, is an integral part of blazon, the jargon in which coats of arms are recorded. The strange writing style and obscure terminology ensure an exotic result that barely reminds one of English. :-) Waltham, The Duke of 04:17, 20 June 2008 (UTC)
- The inverted word order doesn't necessarily come from French: it's what we call "marked" grammar. "The light fantastic" is an example. English grammar is binary in that many constructions are either marked or unmarked. Unmarked is the default.
- Concerning the proposal: I think it's doomed to failure. Let me make a point that the differences between the writing (and speaking) styles of individuals (subtle grammatical features and other choices) are typically greater than those between the so-called varieties of English. As the song says, "You say neether, and I say nyther". We are indeed lucky that the varieties are so trivial in their differences. It's remarkable. TONY (talk) 04:27, 20 June 2008 (UTC)
- The example I am giving is from French. In any case, what you say is interesting. Perhaps there could be such a thing as convergent evolution in linguistics? Few optimum forms? Waltham, The Duke of 06:53, 21 June 2008 (UTC)
- Convergent evolution? Has His Grace been reading Geoffrey Miller's book by any chance? TONY (talk) 08:12, 21 June 2008 (UTC)
- Not yet. (Bloody exams...) But I watch a lot of documentaries. :-) Waltham, The Duke of 05:04, 22 June 2008 (UTC)
- Good luck, Duke. From the link Tony offers: "The theory makes many testable predictions". I'm not a psychologist, but I love popularized evolutionary psychology for exactly that reason: it comes off as a lot of handwaving at first, but then you realize that if various statements were wrong, they'd be easy to disprove, and they're damned hard to disprove. There's a lesson somewhere in there for WP:MOS, which I'll discuss down at #Stability. - Dan Dank55 (talk)(mistakes) 19:17, 22 June 2008 (UTC)
- (nods) Scientists should never underestimate the power and importance of common sense. Waltham, The Duke of 05:26, 23 June 2008 (UTC)
- Good luck, Duke. From the link Tony offers: "The theory makes many testable predictions". I'm not a psychologist, but I love popularized evolutionary psychology for exactly that reason: it comes off as a lot of handwaving at first, but then you realize that if various statements were wrong, they'd be easy to disprove, and they're damned hard to disprove. There's a lesson somewhere in there for WP:MOS, which I'll discuss down at #Stability. - Dan Dank55 (talk)(mistakes) 19:17, 22 June 2008 (UTC)
- Not yet. (Bloody exams...) But I watch a lot of documentaries. :-) Waltham, The Duke of 05:04, 22 June 2008 (UTC)
- Convergent evolution? Has His Grace been reading Geoffrey Miller's book by any chance? TONY (talk) 08:12, 21 June 2008 (UTC)
- The example I am giving is from French. In any case, what you say is interesting. Perhaps there could be such a thing as convergent evolution in linguistics? Few optimum forms? Waltham, The Duke of 06:53, 21 June 2008 (UTC)
- It might be of interest to you that this relic of French, namely nouns preceding adjectives, is an integral part of blazon, the jargon in which coats of arms are recorded. The strange writing style and obscure terminology ensure an exotic result that barely reminds one of English. :-) Waltham, The Duke of 04:17, 20 June 2008 (UTC)
Ellipses
So why exactly is "first text...another text" forbidden? No reason is given; nor is any citation given for any of this. Septentrionalis PMAnderson 20:25, 20 June 2008 (UTC)
- This is a possibility, although we don't follow it exactly as it requests spaces between each period: Editing Quotations. Three ellipsis points (periods with a single space before, between, and after each period) indicate material has been omitted within a sentence or at the end of a sentence. (CMS 2003, 459). --Laser brain (talk) 20:34, 20 June 2008 (UTC)
- This is sufficient reason not to deprecate "first text . . . another text"; thank you. Septentrionalis PMAnderson 21:23, 20 June 2008 (UTC)
- Well, bear in mind that's a print convention. I'm sure the CMS didn't have wikis in mind. The likelihood of me or anyone typing all those non-breaking spaces while writing an article is about zero. --Laser brain (talk) 21:36, 20 June 2008 (UTC)
- That may be, although a sufficiently determined editor will type anything; I typed those. But at present we deprecate "first text . . . another text"; why do so? (why bother, if nobody will use it?) And above all, why forbid the opposite? A rational style guide would either say nothing, or present the case for and against each; we do neither. Septentrionalis PMAnderson 21:42, 20 June 2008 (UTC)
- If we're talking about the ellipsis used in the sense of a dash, rather than omission, which is the sense I get from "first text...another text", then it's the same issue as with dashes. Publishers have used special characters for a long time; we're now in the age where people read and write much more democratically; people tend to type what they see on their QWERTY keyboards. This guarantees 3 things: 1. Older readers and writers (guilty) and readers and writers who have more of an academic bent or are using books for sources tend to expect dashes rather than "..." (although I kind of like the "...", always have); 2. Each year, you see more and more typographical characters being replaced by keyboard characters; and 3. There is often little standardization in the way keyboard characters are substituted for typographic characters, since it's a bottom-up phenomenon. Some people always put spaces around "..." when used in the sense of a dash, some people never do. I don't mind revisiting orthography issues every year, but I sure don't want to revisit them every week. - Dan Dank55 (talk)(mistakes) 21:43, 20 June 2008 (UTC)
- That may be, although a sufficiently determined editor will type anything; I typed those. But at present we deprecate "first text . . . another text"; why do so? (why bother, if nobody will use it?) And above all, why forbid the opposite? A rational style guide would either say nothing, or present the case for and against each; we do neither. Septentrionalis PMAnderson 21:42, 20 June 2008 (UTC)
- Well, bear in mind that's a print convention. I'm sure the CMS didn't have wikis in mind. The likelihood of me or anyone typing all those non-breaking spaces while writing an article is about zero. --Laser brain (talk) 21:36, 20 June 2008 (UTC)
- This is sufficient reason not to deprecate "first text . . . another text"; thank you. Septentrionalis PMAnderson 21:23, 20 June 2008 (UTC)
- I meant the sense of omission, especially since I foresee much hysteria at the thought of another variety of dash. But does it make a difference?
- The easiest way to avoid revisisting orthography is to say, once and for all, that there are many ways of punctuating English, most of them are questions of taste, and articles should decide among them by consensus on the individual article. Editors who felt that a given method was squashy or ornate would then be free to eschew it themselves, and persuade others to do so too. Let's do it. Septentrionalis PMAnderson 21:49, 20 June 2008 (UTC)
- Anderson would have us kow-tow to CMOS on every occasion. Why? It's not bad in some respects, but crap in others. It's for dead-tree text, not online text. It has a very conservative (petrified, some might say) editorial policy that resists change with the times. Get over it and move on. TONY (talk) 04:39, 21 June 2008 (UTC)
- I do wish Tony would take the novel approach of reading what I actually said. I don't think we should kowtow to CMOS; I think we should take the same approach as WP:NPOV: acknowledge all points of view, discuss them (in MOS, this would be mentioning their advantages and disadvantages) and let our editors decide on that basis. In particular, we should acknowledge and permit what any major style guide recommends, because some editors will use that style; just as we acknowledge and permit all national dialects. Septentrionalis PMAnderson 16:51, 21 June 2008 (UTC)
I was so hoping that Chicago would represent a consensus among publishers, journalists and academics that Wikipedia could bootstrap off of, but Tony is right. Chicago is a horse designed by a committee; sometimes Chicago recommends things that are just goofy, and sometimes it goes on forever in a way that is just burdensome and inappropriate for Wikipedia. No one should be required to memorize Chicago's capitalization rules, or even follow them. But the good news is that, so far, I'm happy with the match between Wikipedian practices and the two manuals US journalists use the most, The NY Times Manual of Style and Usage and AP Stylebook. - Dan Dank55 (talk)(mistakes) 17:08, 21 June 2008 (UTC)
Dispute tags
Someone—Anderson, I suspect, although I can't be bothered at this stage to investigate—has been littering MOS with dispute tags. He's just put another on the ellipsis section. Now, most of these tags refer to the talk page, but the relevant talk is stale and has been archived. We need to remove these dispute tags unless there's an ongoing dispute on the talk page. TONY (talk) 04:46, 21 June 2008 (UTC)
- I see that Tony has forgotten the point of the tag: That this, like the other reference to MOSNUM, should either say what MOSNUM says (it doesn't) or - preferably - be a single paragraph in summary style and a link to the relevant section on MOSNUM: Wikipedia:Manual_of_Style_(dates_and_numbers)#Numbers_as_figures_or_words. Septentrionalis PMAnderson 17:07, 21 June 2008 (UTC)
- Comments on which? Septentrionalis PMAnderson 17:47, 21 June 2008 (UTC)
- MOSNUM? Are we still referring to it thus? I thought it had been renamed to The MOS Page Which Must Not Be Named. :-D
- Seriously, though, I've heard that the situation there is quite bad, and since my idea about splitting the page has not even been commented on before its archiving, we might want to try something else, less drastic but equally effective. The situation must be tolerated no longer. Waltham, The Duke of 05:08, 22 June 2008 (UTC)
date autoformatting is optional
I'd like to remind users that for some time now, the autoformatting of dates has not been required.
There are four advantages in not linking dates:
- Inconsistent raw formatting within an article is obvious to editors and thus less likely to escape our attention. (The autoformatting mechanism conceals the inconsistencies from us, the very people who are most likely to enforce consistency, but the raw formats are displayed in bright blue to almost all readers, who are not registered and logged in. The rules for the choice of format in an article are in MOSNUM, here); they are easily summarised as (a) be consistent within an article; (b) take account of national ties to a topic; and (c) retain the existing format unless there's a good reason not to.
- There are fewer bright-blue splotches in the text, which makes it slightly easier to read and improves its appearance.
- The following issues concerning the dysfunctional aspects of the autoformatting mechanism do not arise:
- piped links to date elements (
[[20 June|20]]
,[[20 June]] [[1997 in South African sport|1997]]
) (several forms of piped links break the date formatting function); - links to date ranges in the same calendar month e.g. December 13–17 or the night of 30/31 May – the autoformatting mechanism will damage such dates (30/May 31);
- links to date elements on disambiguation pages;
- links to date elements in article and section headings; and
- links to date elements in quotations (unless the original text was wikilinked).
- piped links to date elements (
- As a minor advantage, edit windows are slightly easier to read and edit.
It may be that WikiMedia can be persuaded to invest resources in revamping the mechanism to avoid or mitigate these problems, but this is unlikely to occur in the short to medium terms. TONY (talk) 14:00, 21 June 2008 (UTC)
- I agree with all the points, and would have no problem seeing the auto-formatting go, but I am not very optimistic about the outcome of any new discussion on the subject, given the results (or lack thereof) of the previous ones, held not long ago and in equally, if not more, public places. Anyway, one thing should be as clear as the optionality of date links: consistency within articles. Either use auto-formatting on all dates, or use it on none, and the more popular solution under the status quo would seem to be the former, knowing how deeply ingrained the practice is in Wikipedians' minds. Unless the system changes, I cannot easily see any change of mentality. Waltham, The Duke of 16:49, 21 June 2008 (UTC)
- I agree on both points; if we had said to begin with that there are various means of presenting dates and different editors will use different ones, we would never have had autoformatting in the first place. Septentrionalis PMAnderson 16:53, 21 June 2008 (UTC)
- What is "more popular" is totally irrelevant; I'm pointing out something that I believe many editors do not realise. TONY (talk) 17:37, 21 June 2008 (UTC)
- Popularity is an inevitable aspect of a system based on consensus; the less popular will have a very hard time being consensus. But Tony's earthshaking announcement here will be read by the dozen of us - and most of us agree with it; I certainly do. Septentrionalis PMAnderson 17:46, 21 June 2008 (UTC)
Intuition
The word “counterintuitively” should be deleted from
- It's is the short form of it is or it has; counterintuitively, the possessive its has no apostrophe.
We don't need some party of editors declaring their intuition to be the intuition. As to my intuition, I would note that pronouns in general do not have apostrophes in their possessives:
- “his”, not “hi's”
- “her” and “hers”, not “her's”
- “your” “yours”, not “your's”
- “its” not “it's”
—SlamDiego←T 23:40, 21 June 2008 (UTC)
- The fewer 18-letter words in WP:MOS, the better. - Dan Dank55 (talk)(mistakes) 01:07, 22 June 2008 (UTC)
- Could the point be rephrased in such a way as not to appear to be making assumptions on what is and what is not intuitive? We're better off being objective about it, what we can say for close enough to certain it is a common mistake. JIMp talk·cont 18:18, 22 June 2008 (UTC)
- How about "the possessive its, just like the possessive his and hers, has no apostrophe"? - Dan Dank55 (talk)(mistakes) 18:50, 22 June 2008 (UTC)
- No need for "just", but a good idea. It may be clearer to use the substantive possessives. Septentrionalis PMAnderson 22:01, 22 June 2008 (UTC)
- How about "the possessive its, just like the possessive his and hers, has no apostrophe"? - Dan Dank55 (talk)(mistakes) 18:50, 22 June 2008 (UTC)
- Could the point be rephrased in such a way as not to appear to be making assumptions on what is and what is not intuitive? We're better off being objective about it, what we can say for close enough to certain it is a common mistake. JIMp talk·cont 18:18, 22 June 2008 (UTC)
- Changed my mind: "its" is an analogue with the predicative "his" and "hers" and "theirs", but the mistake is more likely to occur when it's attributive: not "the food is its", but "this is its food". So I think we have to lose the "like his and hers" phrase, since the attributive analogues are "his" and "heR". TONY (talk) 06:11, 23 June 2008 (UTC)
- I've seen it most often instead of "Its food is..." by confusion with sentence-initial It's, But wny bother to amend for detail? Both forms are possesives, and the analogy may still persuade somebody to comply with idiom. Few people capable of distinguishing attributes from predicates will make the blunder, so whom does more detail communicate with? Septentrionalis PMAnderson 17:04, 23 June 2008 (UTC)
I would definitely delete counterintuitively. My intuition was never that it should have an apostrophe. Why should it? Just because the two-words short form it's is pronounced the same way. Is it then also counterintuitive that there is written without apostrophe? One of the first things I realized when I started learning English was that there are many ways in which one pronunciation might be spelled. BTW, that sucks about this language ;-) Anyway, my point is that for me, personally, it was never the intuition and I am quite proud that it wasn't. If you have this intuition it only shows that you do not see the strikingly difference in those terms (semantically and grammatically). So, when we use counterintuitively in the MOS, we do not only impose on others what a common-sense intuition would be, which I find already a little bit insulting. Moreover, we exhibit that our intuition with respect to understanding this language is under-developed. Tomeasytalk 17:27, 23 June 2008 (UTC)
- Indeed. Seeing such phrasing makes me wonder about the intelligence of the intended readership. It is not flattering for Wikipedia. :-) Waltham, The Duke of 07:27, 24 June 2008 (UTC)
Stability
Looking through the history for the main page I was astonished to discover how many edits—eg. over thirty in the last fortnight—are made to MoS. Its absurd that such a key set of WP guidelines be so unstable. Most editors have a hard enough time as it is keeping tabs on the various WP rules and guidelines—this endless chopping and changing is absurd. Do you expect every editor to check MoS every couple of days or so? I'll repeat that word: absurd. Yes things need to be discussed, but the frequency with which the main page is edited is, IMO, unacceptable, and makes a mockery of the concept of MoS. I write this in the full expectation that opposing parties will exploit replying to this as an opportunity continue to score points. That's fine—but stop letting it spill over onto the guidelines. Frankly, I think the page is verging on needing protecting almost-instinct 00:17, 22 June 2008 (UTC)
- My suggestion is to make a big push to get everyone to slug it out, and then leave it alone for a while. Tony thinks it won't work, and he's right about most things, but if so, that's really a shame. - Dan Dank55 (talk)(mistakes) 01:04, 22 June 2008 (UTC)
Considering the number of reverts, I'd say that simply counting edits is wrong, at least (or, some might say, especially) in the Manual of Style. If you will check the style updates, once a month, you will see that the actual changes are relatively few, and you can monitor them through said updates. Waltham, The Duke of 05:29, 22 June 2008 (UTC)
- Precisely: His Grace, as often, hits the nail on the head. Many day-to-day edits are reverted or subsumed in subsequent edits. It's surprising how little actually does change. That's my experience not only in perusing monthly diffs at MOS main page, but most other style-guide and policy pages. TONY (talk) 09:07, 22 June 2008 (UTC)
- More accurately, it is stable because most editors know nothing about it, or have more sense than to care what it says; those who do care arrive individually, and are successfully reverted by the handful who have assumed ownership of the page, contrary to policy. Septentrionalis PMAnderson 21:59, 22 June 2008 (UTC)
I see the consensus is that I'm wrong so I withdraw my comments ;-)
But seriously its difficult for new editors to come to terms with the MoS—it seems so huge at first—and we worry about getting shot down for going outside the guidelines ... it just can feel like the ground is shifting beneath our feet ... almost-instinct 13:06, 22 June 2008 (UTC)
- I do not think you are wrong. There are two issues:
- Edit frequency
- Rate of change of policy
- If edit frequency is low, then it is easy to conclude that policy is stable. If edit frequency is high, more effort is required to see what has changed. The effort involved in checking the net effect of rapid changes at wp:mosnum recently was one reason (amongst many) why I stopped being involved in a major debate. Lightmouse (talk) 14:15, 22 June 2008 (UTC)
- Reply to Almost-Instinct: I take your objection seriously, AI, and you come across on your userpage as intelligent and thoughtful, but I'm not qualified to respond to it because I'm North American, and so my instincts will be sufficiently off from yours that we will misunderstand each other in some ways. You say that you don't want to bring any articles through the GA/FA process. Certainly it can be daunting, but what you get back from having a lot of good writers look over your stuff can be more than worth the hassle. Can you give me an example of some of your work that you feel is made more difficult by either WP:MOS or by requirements at WP:GAN or WP:FAC? - Dan Dank55 (talk)(mistakes) 14:38, 22 June 2008 (UTC)
- Reply to Lightmouse: after I did the categorization work of "general style guidelines" vs "style/editing/policy guidelines" vs "specific guidelines", I decided to sit back for a while and watch. Everything I've seen makes me think I got it right. The thing that makes WP:MOSNUM so frustrating for a lot of us is that a lot of it concerns very targeted information, targeted to a specific set of articles and editors, but it's mixed in together with material that draws a very wide audience, things needed in most articles, such as how to deal with dates. I think the Duke was exactly right when he suggested we should pull some of this material apart; I wouldn't mind transferring the well-tread material to WP:MOS. It's the two different sets of editors rubbing elbows that causes the friction, which is why I didn't put WP:MOSNUM in CAT:GEN; it seems to function more as a "specific" guideline to me. Other than WP:LAYOUT (which I think I'm about to take out of CAT:GEN), and WP:MOS, the other 19 pages in CAT:GEN tend to be very collegial and stable, and also widely useful. I think WP:MOS and WP:LAYOUT could become more collegial and stable after a few issues are worked out. - Dan Dank55 (talk)(mistakes) 14:53, 22 June 2008 (UTC)
Stability and WP:CONSENSUS
Okay, let's tackle the issue of stability. The folks at WP:CONSENSUS and WP:VPP know very well what "consensus" means, and I'm going to go point them to this conversation, so if this is wrong, I'll get an earful in a hurry. Let's take the latest addition to WP:MOS, from User:Betswiki (a new editor, or at least a new account, so I'll go leave a message on their talk page, and please don't BITE):
An ellipsis (plural ellipses) is the omission of material from quoted text or some other omission, perhaps the absence of the end of a sentence, deliberately left out by the author, often used in the representation of conversation in print. The ellipsis is represented by ellipsis points, a series of dots (three dots within a sentence, four dots at the end of a sentence). In traditional publishing the dots are separated by spaces and are separated from the surrounding text by spaces.
Not that bad, but not quite right, which makes it a good example for my point. There's an infobox at the top of every guideline and policy page that says, "Before editing this page, please make sure that your revision reflects consensus." So I have to curb my impulse to yank the edit just because I don't like it. I'm also not allowed to yank it on the grounds that the editor may not have followed that policy when they edited; that doesn't give anyone a "right" to revert. But there are lots of reasons to believe that most of this edit doesn't represent consensus and should be reverted. The first is precedence: new users get pointed to WP:MOS, it's the most commonly visited style guideline page, and its recommendations are argued constantly at WP:FAC. WP:SILENCE counts reading something and not taking action as indicative of consensus, and I don't see any history in the WT:MOS archives of argumentation over any of the things discussed in the new edit, so the previous text (before the last few days) represents at least the approximate consensus of thousands of people. That means that it doesn't matter if someone has a new clever argument, or knows that Chicago does it differently; that's not sufficient to change the page. WP:BRD does permit people to "act first, answer questions later", even on a guideline page, but anyone who has a habit of making changes without having their reasons handy is in line for a trip to WP:ANI for violation of "6. Attempting to ... impose one's own view of 'standards to apply' rather than those of the community" from WP:POINT. On a guideline page, your argument needs to be, not why you personally think it was an improvement, but why you believe that everything you've read on Wikipedia tells you that you changed it from something that didn't have consensus to something that did. (See WP:Village_pump_(policy)/Archive_44#Using a policy page as a scratchpad to develop a proposal for Kim's discussion and links.)
If WP:MOS doesn't reflect consensus, that's easy to show. Regulars at WP:FAC and WP:GAN can search their memory of what people said when the issue came up. If the issue can be identified by keywords, the last database dump of en.wikipedia or page-specific Google searches would pull up evidence of disgruntlement if it exists. If there's no disgruntlement, then it has consensus. Anyone can start a new discussion on this talk page, and that discussion might lead to a new consensus, but three guys and a lot of handwaving can't overturn the apparent consensus of thousands of people. Three guys arguing about what they've seen at WP:FAC, WP:GAN, the WT:MOS archives, etc, can be persuasive, in my view, as long as they're being honest and accurate, of course.
So: is there anything in the new edit concerning ellipses that people believe already has consensus? - Dan Dank55 (talk)(mistakes) 20:04, 22 June 2008 (UTC)
- Oh come on now; thousands of people have read and approved "An ellipsis (plural ellipses) is a series of three dots. It marks the omission of material from quoted text." Yeah, right. Is there any evidence that any user has ever noticed this bland truism, much less considered the alternatives? Septentrionalis PMAnderson 21:50, 22 June 2008 (UTC)
As for the matter at issue, I italicise the parts which seem to me mere statements of fact:
- An ellipsis (plural ellipses) is the omission of material from quoted text or some other omission, perhaps the absence of the end of a sentence, deliberately left out by the author, [and] often used in the representation of conversation in print. The ellipsis is represented by ellipsis points, a series of dots (three dots within a sentence, four dots at the end of a sentence). In traditional publishing the dots are separated by spaces and are separated from the surrounding text by spaces.
I do not claim any of the text is the best possible phrasing; but it shares that with the text it replaced and with the rest of the section.
The last sentence is vague on dating; for certain values of "traditional" I believe both claims made are true. But do we need a history of typography here? Septentrionalis PMAnderson 22:11, 22 June 2008 (UTC)
- >Is there any evidence that any user has ever noticed
- Not knowing the finer points of WP:SILENCE is exactly why I invited the folks from WP:CONSENSUS and WP:VPP. WP:MOS was viewed 68,000 times in May; isn't that at least a suggestion that at least a hundred people read about ellipses? WT:MOS has around 120 archives, including rare comments about ellipses, and comments about things on either side of that section of WP:MOS; did everyone skip that part? People preparing articles for WP:GAN are strongly encouraged, and at WP:FAC are required, to read WP:MOS; are they all faking it? - Dan Dank55 (talk)(mistakes) 23:33, 22 June 2008 (UTC)
- I think that editors, in general, do not learn MOS by referencing it. They learn by being corrected. I know I didn't learn most things from Chicago Manual or from my corporate MOS because I was curious or just thought to look something up. I learned it because I got marked-up text back from my editor. My point is that you shouldn't take page views as an indication of how many people are actually learning things from the MOS. --Laser brain (talk) 03:42, 23 June 2008 (UTC)
- Indeed, much of the Manual is learnt indirectly, not least because:
- It's too large to learn by heart unless one is very interested
- Parts of it are simply hard to understand for some people, no matter how much they are explained
- Many people are simply too bored to look (and that also applies on policy and how-to pages and all other documentation)
- A great (possibly the greatest) part of the Manual is not really necessary to an editor due to specialisation; however, straying out of the usual field is rather difficult to predict
- Etc., etc.
- In all things there are those people who understand them better and can comfortably explain them to others; it is often a matter of how something is presented to one. Waltham, The Duke of 05:23, 23 June 2008 (UTC)
- Indeed, much of the Manual is learnt indirectly, not least because:
Experience shows that relatively few FA nominations are reviewed for MOS issues; on the other hand, most of those that are are reviewed with mechanical incompetence. Experience also shows that this often genuinely comes as a surprise, and justifiably so, to the nominator; the "rules" that are enforced are rarely sound English; sometimes they are mere recommendations here, often they ought to be, and quite often they ought not to be even recommendations, since the article is in sound English, or one of the variations which can be sound English. Septentrionalis PMAnderson 12:48, 23 June 2008 (UTC) ←What a total surprise that Anderson should take this opportunity to trumpet his anti-MOS agenda again. TONY (talk) 14:07, 23 June 2008 (UTC)
- WP:CONSENSUS doesn't care whether people have read a page or not, only what their position is, as evidenced by what they do or say. If they do things that WP:MOS says and don't express any other preference, that's silent consensus. - Dan Dank55 (talk)(mistakes) 02:08, 24 June 2008 (UTC)
- And how about the normal case, when half of them don't do them? I omit the poor chivvied FA nominators. Septentrionalis PMAnderson 01:17, 25 June 2008 (UTC)
Opening sentence in lists
I'm not sure if this is more relevant at Wikipedia talk:Lead section, but I think this page gets more activity... Most lists open with "This is a list of <Repeat the article title>", or "This is a complete list of <repeat the article title>", or "comprehensive" or any other similar words. A discussion was started a while ago at Wikipedia talk:Featured list candidates/Archive 3#Straight repetitions of the title in the opening sentence regarding this, as WP:FLC is obviously the place where this sort of thing is seen frequently. Regarding FLs, if a list is featured, then it should already be complete and comprehensive, and shouldn't need stating as such. But it's also not a very good way of engaging the reader to the article. We know it's a list of cats (or whatever) from the title. Articles don't begin this way. Today's Main Page article Blue Iguana doesn't begin with "This is an article about Blue Iguanas. The Blue Iguana is a critically endangered species of lizard". Can we please state a "ban" on WP:MOS from introducing list articles in this way? Matthewedwards (talk • contribs • email) 07:14, 23 June 2008 (UTC)
- It's a ridiculous habit, and it's disappointing that FL reviewers haven't been cracking down on it. (Usually, it's a contravention of Cr. 2.) I think it's difficult to legislate against; what about inserting something explicit into the FL criteria, in terms of "should be avoided unless there is a good reason"? TONY (talk) 07:23, 23 June 2008 (UTC)
- Well, it's not just a problem at FL. It's mostly all lists. Of course things filter down, so if a FL does it a "start-class list" will copy, but then if you try to fix it you come up against a wall. If WP:LS#Establish context or WP:LS#Bold title mentioned something, it could be linked to in edit summaries when being fixed and referred to in FLCs. Matthewedwards (talk • contribs • email) 07:33, 23 June 2008 (UTC)
- That works! Matthewedwards (talk • contribs • email) 07:55, 23 June 2008 (UTC)
- Theoretical note: I agree with the concerns of the honourable colleagues, but I think we should concede that, while articles should never be self-referential, in lists this is more forgiveable. It is in the nature of these pages: as lists are more "artificial" collections of information than articles, which are basically prose, and various notes and explanations are often given about the organisation and inclusion criteria of the data, self-referencing is, in many occasions, unavoidable. Waltham, The Duke of 07:58, 23 June 2008 (UTC)
- Theoretical note: It is really boring to read a long "List of ..." article title and then to have to read it again immediately, on the line below. This is just where the lead should be describing the context of the list, not irritating the reader by senseless repetition. TONY (talk) 08:11, 23 June 2008 (UTC)
- That was a practical note. :-) And not necessarily one incompatible with what I said. There are different forms of self-referencing. See List of largest United Kingdom settlements by population for a heavily self-referencing list; even the first sentence is rather excusable, as it introduces further analysis of the population figures. Waltham, The Duke of 08:44, 23 June 2008 (UTC)
- I take issue with His Grace: the first sentence is tedious. See my fix, to prove the point that straight repetitions of "List of ..." titles are a way of turning off potential readers. TONY (talk) 09:01, 23 June 2008 (UTC)
- I see that Tony disagrees with the general prescription that titles of articles shall be repeated in bold; he should defend this wish for stylistic inconsistency at WT:LEAD. Septentrionalis PMAnderson 13:37, 23 June 2008 (UTC)
- Titles of articles should be repeated in bold. The exceptions listed at Wikipedia:Lead_section#Bold_title are inappropriate. If article originator concludes that the topic of an article has no commonly accepted name, then either they are not looking hard enough or they are structuring an article for which the topic is not well thought out. As for the title being simply descriptive, that is subjective and not a viable guideline. In short, if the title of the article does not work well being repeated in bold in the first sentence, then someting is wrong with the title or the topic. That is why the title in bold rule was created - to force article originators to think before creating an article name or topic. THe exceptions to Wikipedia:Lead_section#Bold_title are merely a lazy way to get around thinking before creating an article name or topic. Bebestbe (talk) 15:19, 23 June 2008 (UTC)
←Anderson, it's the topic, isn't it, not the title. In any case, at FLC there's general consensus, including the two directors, that this has turned into a lazy way for authors to open their "list" articles. The practice is particularly problematic given the length of many "list" titles. Have a look for yourself, except that reviewers (mostly others apart from me) have been insisting on a recasting in nominations; easier to find in the list of existing FLs. TONY (talk) 13:59, 23 June 2008 (UTC)
- It may not be laziness, but a lack of knowledge of what to do. I usually write as the first sentence something like "List aaaaaaaaaaaaaaaaaaaa is a compilation of xxxxxxxxxxx.", where xxxxxxxxxxx explains the list contents using words other than contained in the name of the list. This uses the name of the article/list at the very beginning of the first sentence (like all Wikipedia articles should) and offers more information than provided by the name of the list. Please feel free to post this technique as a suggestion in the List MoS. Bebestbe (talk) 15:07, 23 June 2008 (UTC)
- No, it's almost always better not to repeat verbatim the title wording. Take it straight on to give the reader new information. See my link above. TONY (talk) 15:51, 23 June 2008 (UTC)
- I regret to say, Tony, that I do not approve of your change to the lead in the slightest. Yes, the first sentence repeats the title, but the title is the subject of the page, and that subject should always be introduced in the article, and more specifically in the first sentence. Blue Iguana may not start with "This is an article about Blue Iguanas", but this is because articles should not refer to themselves, which is practically never true for lists; the article still has "Blue Iguana" in the first sentence, most prominent in its bold typeface. I should agree with a change not saying "this is a list of..." as long as it still introduces the subject, but your edit simply removed the introduction. The list as it stands now makes no sense without the title, a situation which should be avoided in all mainspace pages; the title is not any more integral a part of the prose than headings are. Waltham, The Duke of 21:51, 23 June 2008 (UTC)
- Tony has a partial point: we need not repeat the title exactly in stating the subject of the article, when (as here) it is more complex than Blue Iguana; for example, in biographical articles we often use the full name, or the native form, as opposed to the common English form in the title. But we should state the subject of the article in its first, or topic, sentence. This list didn't state its subject particularly clearly or concisely, and I hope Tony is merely reacting to that flaw. This version may be an improvement. Septentrionalis PMAnderson 16:06, 24 June 2008 (UTC)
- I regret to say, Tony, that I do not approve of your change to the lead in the slightest. Yes, the first sentence repeats the title, but the title is the subject of the page, and that subject should always be introduced in the article, and more specifically in the first sentence. Blue Iguana may not start with "This is an article about Blue Iguanas", but this is because articles should not refer to themselves, which is practically never true for lists; the article still has "Blue Iguana" in the first sentence, most prominent in its bold typeface. I should agree with a change not saying "this is a list of..." as long as it still introduces the subject, but your edit simply removed the introduction. The list as it stands now makes no sense without the title, a situation which should be avoided in all mainspace pages; the title is not any more integral a part of the prose than headings are. Waltham, The Duke of 21:51, 23 June 2008 (UTC)
- No, it's almost always better not to repeat verbatim the title wording. Take it straight on to give the reader new information. See my link above. TONY (talk) 15:51, 23 June 2008 (UTC)
- See THIS recent discussion at FLC talk: the Directors and other reviewers are certainly keen to put a stop to the practice of straight repeating the usually long title of a list at the top of the lead. If this can't be done neatly using bolding, that's fine: MOSLEAD gives ways out. TONY (talk) 16:48, 24 June 2008 (UTC)
- Anything with capitalized Directors should be abolished; it surely fails other tests of WP:PRO, and is contrary to WP:NOT#Bureaucracy. As for the matter at issue, we agree both in theory and in practice that repetition is not required. Septentrionalis PMAnderson 19:31, 24 June 2008 (UTC)
← I am glad to see that the two of you have finally reached a solution on the article (and one which I also agree with, by the way). Following the history was interesting, but also worrying, at least in the start; I was this close to starting counting reverts. Please be careful from now on. I suggest using talk pages more; you don't need to "discuss" through edit summaries. Waltham, The Duke of 22:39, 24 June 2008 (UTC)
En dashes in page names
Why was the following removed as "nonsense"?
When naming an article, a hyphen is not used as a substitute for an en dash that properly belongs in the title, for example in Eye–hand span. However, editors should provide a redirect page to such an article, using a hyphen in place of the en dash (e.g., Eye-hand span), to allow the name to be typed easily when searching Wikipedia. See also Wikipedia:Naming conventions (precision). The associated talk page name should match the page name exactly.
Matthewedwards (talk • contribs • email) 07:36, 23 June 2008 (UTC)
- Well, I think the better question would be why it was ever included to begin with. : - ) Using en and em dashes in page titles ruins everyday page linking and needlessly creates redirects. A standard hyphen is surely sufficient, and balances the need for a dash with the need to be able to link to a page easily (most keyboards don't have an en dash key). Is there any reason for the MoS to prescribe that en dashes be used? --MZMcBride (talk) 07:46, 23 June 2008 (UTC)
- Only if the title is acutally an en dash. Matthewedwards (talk • contribs • email) 07:53, 23 June 2008 (UTC)
- Certainly. But that's a rare case. Mexican-American War does not require the use of an en dash, and nothing is lost by using a standard hyphen. It's certainly easier to link Mexican-American War than it is to link Mexican–American War or Mexican—American War.
I went crawling through the page history and isolated the diff that changed this rule from being merely a suggestion to being the law of the land. (See here.) There doesn't appear to be any consensus or discussion behind the move, and as such, I propose changing the language back to being a suggestion, rather than being a requirement. Thoughts? --MZMcBride (talk) 08:02, 23 June 2008 (UTC)
- Certainly. But that's a rare case. Mexican-American War does not require the use of an en dash, and nothing is lost by using a standard hyphen. It's certainly easier to link Mexican-American War than it is to link Mexican–American War or Mexican—American War.
- Only if the title is acutally an en dash. Matthewedwards (talk • contribs • email) 07:53, 23 June 2008 (UTC)
- [multiple edit conflicts]v Where were you two when this gained clear consensus, ages ago? McBride, do not make substantial changes to MOS without raising them here first. I haven't heard of the inclusion of em dashes in article titles (can't imagine why that would occur), but en dashes have a quite different meaning to hyphens; the main text in such articles needs to follow the MOS guideline, so why should the title of the article clash with this? Who wants internal inconsistency (may as well use British spelling in the title and US spelling in the opening sentence)? The need for redirects is there anyway, whether en dashes or the erroneous hyphens are used; redirects are just a fact of life in an efficiently run site. And no, "Mexican–American War" certainly does require an en dash, despite the renegade reversions of the change back to hyphen that I've heard about. That issue is going to have to be dealt with sooner or later. Now, if you're really foxed about how to produce an en dash on your keyboard, see this. I'll pipe the link in the MOS section now (it's unpiped to the whole dash article at the moment). TONY (talk) 08:06, 23 June 2008 (UTC)
- PS Why are you presenting erroneous red links in an attempt to bolster your position? An em dash is totally wrong in that context. TONY (talk) 08:08, 23 June 2008 (UTC)
- (even more edit conflicts) I am afraid that the honourable colleague focuses exclusively upon the technical side of the matter, and in so doing forgets the work-arounds which have been devised in order to address an equally, if more, important issue: accuracy. This is an encyclopaedia, ladies and gentlemen, and it is of paramount importance to say things as they are. En dashes improve legibility and often show fine differences in meaning or indicate important technical details. Discontinuing their usage while it creates no disruption (What's wrong with redirects? And why can't links use en dashes?) is at least counter-productive. (PS: Em dashes are wrong in pretty much all contexts in titles; I have yet to see an exception, even though I guess there must be one somewhere.) Waltham, The Duke of 08:10, 23 June 2008 (UTC)
(ec) Look, the linking thing is a red herring; there's no problem with using a redirect as a link. Similarly for navigation--just type the name with the hyphen into the search box and you'll get to the right place. So the only question is, which form do we want to see at the top of the page? In the case of Mexican–American War I have no strong feelings, but I suppose there's some utility to the endash to make it clear that it wasn't (or at least not especially) a war about Mexican-Americans, but rather between Mexicans and Americans. Similarly the Michelson−Morely experiment wasn't performed by a single physicist named Michelson-Morely. --Trovatore (talk) 08:12, 23 June 2008 (UTC)
The issue is that people should be able to type the title without the use of redirects. And now that people have taken to using automated tools to attempt to change thousands of page titles, this becomes a larger issue quite quickly. Tony: I see no consensus (as I tried to demonstrate with that diff) to make the MoS require en dashes. In fact, for years, it was merely optional – a suggestion, really. And the claim that the need for redirects is there anyway is a bit silly. I doubt many people are searching using en dashes, eh? So I really don't understand why the bit about page titles can't go back to being a suggestion rather than a mandate. --MZMcBride (talk) 08:18, 23 June 2008 (UTC)
- The use of en dashes has been well established on WP for some time. Go take a look at the FAC room. If you really don't understand the important difference in meaning, the improvement in the reader's comprehension of the relevant compound items (even if they don't quite understand the formal set of rules), and the improved visual appearance, I'm very willing to give you free private lessons. It's really not hard, and serious WPian writers/editors (particularly those preparing featured content) seem to have no problem in grasping the concept and the keystrokes. More broadly, most good styleguides (for hard-copy text) insist on the use of en dashes; on-screen, where the display is often rather small, hyphens are often difficult to discern when not merely joining two words, but signifying apposition or opposition between them, as in the title of the unfortunate war, and in ranges. TONY (talk) 08:27, 23 June 2008 (UTC)
- Apart from the other things that I have mentioned above, Mr McBride seems to ignore the speed with which events unfold on Wikipedia. Two years can make the place largely unrecognisable; the whole site has reached this point in seven. I daresay that we are driving fast (although not necessarily fast enough) towards professionalism in many aspects of article-writing, and that many of the old guidelines have had to be modified along the way to conform to our changing demands for quality. Inline citations used to be an unknown concept, and look at them now; is it hard to believe that this can also happen with dashes? Waltham, The Duke of 08:36, 23 June 2008 (UTC)
- The difference there was that inline citations were a good idea. This change made no sense to begin with, and has no consensus support anywhere. Look, I really don't care what sort of dash you use in articles. However, until you convince computer manufacturers to put the en dash on conventional keyboards, this does not belong in article titles. It's ludicrous to create a situation where our readers can't physically access thousands of articles without the assistance of redirects due to the concern of a tiny handful of users about the proper length of a line. It badly interferes with the usability of project for its readers for absolutely no good reason. People generally overlook these issues because they generally don't matter, but this is one thing that you're going to actually need to establish a consensus to do if you don't want every move to be vigorously opposed. I dare you - take this to the village pump or any communal discussion space that isn't solely frequently by the MOS fanatics and see if this proposal lasts five minutes. There was no consensus when this was put in place, there's no consensus here, and there's sure as hell no consensus on the broader project for this. Rebecca (talk) 10:54, 23 June 2008 (UTC)
- Right. Consensus is only what Rebecca from Adelaide thinks. The fact that you "don't care what sort of dash" is used in articles kind of excludes you from the discussion, doesn't it? En and em dashes are on keyboards, and genius is not required to use them. Do you want a private lesson in it? I'll willing give you one. But no one else on WP requires that. What kind of keyboard do you have that makes it incomprehensible? TONY (talk) 11:20, 23 June 2008 (UTC)
- No, consensus is demonstrated support among a decent sized group of people, rather than the support of a very vocal group of three people with not insignificant opposition. And no, you don't get to exclude me from the conversation because I'm not going to get rabidly worked up about the length of a line except where some buffoon tries to force the project to use a character that isn't on keyboards in article titles instead of a perfectly usable one that is. I think the fact that you suggest a lesson is needed to find out how in hades one uses one of these precious extra-special lines is telling: the fact it isn't actually marked on the keyboard suggests that the vast majority of our readers ain't getting it either. Rebecca (talk) 11:55, 23 June 2008 (UTC)
- Right. Consensus is only what Rebecca from Adelaide thinks. The fact that you "don't care what sort of dash" is used in articles kind of excludes you from the discussion, doesn't it? En and em dashes are on keyboards, and genius is not required to use them. Do you want a private lesson in it? I'll willing give you one. But no one else on WP requires that. What kind of keyboard do you have that makes it incomprehensible? TONY (talk) 11:20, 23 June 2008 (UTC)
- The difference there was that inline citations were a good idea. This change made no sense to begin with, and has no consensus support anywhere. Look, I really don't care what sort of dash you use in articles. However, until you convince computer manufacturers to put the en dash on conventional keyboards, this does not belong in article titles. It's ludicrous to create a situation where our readers can't physically access thousands of articles without the assistance of redirects due to the concern of a tiny handful of users about the proper length of a line. It badly interferes with the usability of project for its readers for absolutely no good reason. People generally overlook these issues because they generally don't matter, but this is one thing that you're going to actually need to establish a consensus to do if you don't want every move to be vigorously opposed. I dare you - take this to the village pump or any communal discussion space that isn't solely frequently by the MOS fanatics and see if this proposal lasts five minutes. There was no consensus when this was put in place, there's no consensus here, and there's sure as hell no consensus on the broader project for this. Rebecca (talk) 10:54, 23 June 2008 (UTC)
- Apart from the other things that I have mentioned above, Mr McBride seems to ignore the speed with which events unfold on Wikipedia. Two years can make the place largely unrecognisable; the whole site has reached this point in seven. I daresay that we are driving fast (although not necessarily fast enough) towards professionalism in many aspects of article-writing, and that many of the old guidelines have had to be modified along the way to conform to our changing demands for quality. Inline citations used to be an unknown concept, and look at them now; is it hard to believe that this can also happen with dashes? Waltham, The Duke of 08:36, 23 June 2008 (UTC)
- Talking about consensus: Can we at least agree that, in the prose, the repeatedly cited Mexican–American War uses an en dash and not a hyphen when the correct type setting is applied? Trovatore has nicely pointed out that in this specific case the en dash is in deed required to produce the intended meaning. It would be a good starting point if Rebecca and McBride could make clear that we are not arguing about the necessity of the en dash for this example in the prose.
- Assuming agreement on the above point, I would then conclude that it is the correct type setting for the title of the article, if this was not an online encyclopedia. Remains the objection about functionality or usability of the Wikipedia. I agree that (almost!) nobody would type an en dash in a search window. Therefore, if we use the en dash in the title we must create a re-direct using a hyphen. OK, is there a way out of this compulsory re-direct? Can we use the hyphen in the article title—thereby introducing a typesetting mistake which is considered minor by many? The claim is that everybody would easily find the article even without re-direct. I hope I understood the argumentation correctly. Otherwise, corrections will be most welcome.
- Well, I disagree that a re-direct can thus be avoided. Why? Don't forget that some people use copy paste plus search box to search for new articles and the copy function will likely (if used on a good quality article) collect the America–Mexican War spelled with an en dash.
- For this case a solution is also necessary. I think it is clear from this argumentation that one re-direct is needed anyways. So, I think that the MoS should suggest to use the correct type setting also in the article and declares the creation of a re-direct as mandatory. Tomeasytalk 12:08, 23 June 2008 (UTC)
- As I said above, I have no particular concern either way which dash should be used in the text, or which would be used in a hypothetical non-online encyclopedia. My sole concern here is the functionality issues created by moving thousands of articles to titles that cannot be accessed by most people without redirects. It looks ugly as hell to consistently have to see the redirect warning on every single page a reader goes to with a dash in the title, and there's no good reason to have to do that.
- What I'm challenging here is the need for the compulsory redirect: we can have a technically very minor typesetting mistake that makes no difference to the functionality of the encyclopedia, at least until computer manufacturers decide to stick the en dash on their keyboards. I am not fussed at the prospect of having a redirect from the en-dash, but it would seem like a lot of work considering virtually no one is going to go to that title directly. Rebecca (talk) 12:31, 23 June 2008 (UTC)
- Forgive my technical ignorance, but is a redirect obvious to the visitor? I'd have thought it seamlessly led to the right destination. Isn't it the type of thing that the creator of an article (or someone who comes along after, or a bot) can do in ten seconds? I don't see the problem. And yes, Mexican–American War should be fixed so it has an en dash. Trovatore points out above the very reason the correct punctuation should be observed. TONY (talk) 12:51, 23 June 2008 (UTC)
- Yes. Whenever you've been redirected from a page, you have a notice in largeish font at the top of the page informing you of the page you've been redirected from. It's a helpful thing in the vast majority of cases, but it becomes a downright nuisance when it starts appearing on every single page with a dash in the title. It's one time when it would be really helpful for you folks to suck it up and say "okay, it's not 100% technically perfect, but it does interfere with the usability of the pages and there's no other alternative, so we'll let it slide." Rebecca (talk) 13:03, 23 June 2008 (UTC)
- (edit conflict) I congratulate Tony on his use of irony, in the classical sense; but of course redirects are obvious to the visitor; there's this tag, right under the title, saying (Redirected from Mexican–American War). As Tony knows, from the last time (or was it the time before?), some editors find this a visual defect. I don't care so much myself.
- Should we mandate this? Will we listened to? Does this reflect consensus? I find it at least suggestive that fewer than a hundred articles link to Mexican–American War, and over 1500 to Mexican-American War.
- I am not fully persuaded by Trovatore's semantic argument, although it is infinitely better than the WP:IDONTLIKEIT all too common on this page. The compounds in question are Mexican-American War and Mexican-American population, which latter is customarily abbreviated Mexican-Americans. These are compounds of the same type, and fundamentally of the same meaning: "From both sides of the boundary between Mexico and the United States". Septentrionalis PMAnderson 13:16, 23 June 2008 (UTC)
- Rebecca, I understand what you're saying. But the problem then arises that we have a hyphen in the title and thenceforth an en dash in the very same compound item throughou the main text. This was one of the most frustrating aspects of the don't-care regime until about a year ago when the proscription against en dashes in titles was, thank god, ended. And I think folks here should be most unwilling to allow a technological deficiency at WikiMedia (yes, another one) dictate a downward slide in our formatting standards. Let the redirect issue stand, I say, so that when we finally persuade WP and Wikimedia to overhaul their program, this will be dealt with. It's a small price to pay. Anderson, I'm not as well-read as you are, nor as versed in classical knowledge, so you can't expect me to understand what "classical irony" means. And ... um ... the grammar of your last clause needs a good look. TONY (talk) 13:27, 23 June 2008 (UTC)
- See, why is having a hyphen in the title and an en dash in the text going to be a problem? It's something that isn't going to be noticed by 99% of users, and those who do notice are generally going to know why it is the way it is. The problem here isn't with the Wikimedia software - it's just that it isn't (and can't be) designed to have forty thousand redirects from to make up for the fact that computer manufacturers don't put the en dash on their keyboards. It's a slight thing that for once I really wish you might consider overlooking, Tony. Rebecca (talk) 13:36, 23 June 2008 (UTC)
←Rebecca, by "computer manufacturers don't put the en dash on their keyboards", I presume you mean that they don't allocate this function to a single keystroke, as they do the hyphen. Do I see a show of support for not using the degree symbol just because it requires two fingers simultaneously, not one? Or parentheses? And while we're at it, no more superscript please; and those monstrous non-breaking spaces are out – they require SIX keystrokes. Really, we're all aspiring to a professional standard of writing and formatting, aren't we? TONY (talk) 13:44, 23 June 2008 (UTC)
- As far as I understand, it has been appreciated that in any case we need a re-direct, no matter whether the article is name with an en dash or a hyphen.
- So, comes the new objection that the re-direction message is ugly. Personally, I am not fuzzed about this message whenever it appears. I think it is even informative for the reader, as they may find out that who the compounded word is correctly type set, if they are interested in the re-direct message. If they aren't, then I do not see why they would bother about this message, but just read over it.
- What worries me a bit in this discussion is that some do not even acknowledge that it is for good that wikipedia discriminates hyphens and dashes. From my point of view, n terms of style, this is a simple pre-requisit of any high-quality reference. Tomeasytalk 13:44, 23 June 2008 (UTC)
- I think it is important to have correct punctuation in article titles. I find the small and grayish redirect message nearly imperceptible, but if people really find it annoying, perhaps someone can design a stylesheet that makes it even grayer and smaller, moves it somewhere else, or hides it outright. --Itub (talk) 14:52, 23 June 2008 (UTC)
- Or ask the developers to make hyphens in the search box go to en dashes automatically (without even a redirect), like initial lower-case letters currently go to capitals.--Kotniski (talk) 14:58, 23 June 2008 (UTC)
- On the principle that we should devote time to important things in preference to unimportant things, I'm not going to get worked up about this. No one is going to be shocked, shocked to see a hyphen where they were expecting an en-dash and vice versa; Wikipedia has bigger problems than this. There are good reasons both ways, and since people are doing more and more of their own publishing these days, the general trend is in the direction of hyphens, but we haven't arrived there yet. A few relevant facts:
- Or ask the developers to make hyphens in the search box go to en dashes automatically (without even a redirect), like initial lower-case letters currently go to capitals.--Kotniski (talk) 14:58, 23 June 2008 (UTC)
- I think it is important to have correct punctuation in article titles. I find the small and grayish redirect message nearly imperceptible, but if people really find it annoying, perhaps someone can design a stylesheet that makes it even grayer and smaller, moves it somewhere else, or hides it outright. --Itub (talk) 14:52, 23 June 2008 (UTC)
- AP Stylebook has given up on recommending that en-dashes ever be used to link two words; there's no mention of this use in the long sections on hyphens and en-dashes.
- Merriam-Webster’s Collegiate Dictionary, which is one of the most commonly-used dictionaries in the US, uses a hyphen in its own name in a place where current WP:MOS guidelines say to use an en-dash.
- Chicago does mention a variety of uses for en-dashes as links, but they give exactly one example below that supports our recommendation of en-dashes to link words (London–Paris train) and one that contradicts it (U.S.-Canadian relations), in a long list of other uses for the en-dash (principally, to connect numbers, and to connect with a phrase instead of a word):
Her college years, 1998–2002, were the happiest in her life. For documentation and indexing, see chapters 16–18. In Genesis 6:13–22 we find God’s instructions to Noah. Join us on Thursday, 11:30 a.m.–4:00 p.m., to celebrate the New Year. The London–Paris train leaves at two o’clock. I have blocked out December 2002–March 2003 to complete my manuscript. Her articles appeared in Postwar Journal (3 November 1945–4 February 1946). Green Bay beat Denver 31–24. The legislature voted 101–13 to adopt the resolution. Professor Plato’s survey (1999–) will cover the subject in the final volume. Jane Doe (1950–); or Jane Doe (b. 1950) the post–World War II years a hospital–nursing home connection a nursing home–home care policy a quasi-public–quasi-judicial body (or, better, a judicial body that is quasi-public and quasi-judicial) but non-English-speaking peoples a wheelchair-user-designed environment (or, better, an environment designed for wheelchair users) (Abbreviations for compounds are treated as single words, so a hyphen, not an en dash, is used in such phrases as “U.S.-Canadian relations.”) the University of Wisconsin–Madison the University of Wisconsin–Milwaukee
I suggest that we acknowledge that there's a large, pre-existing base of GAs and FAs that follow the long-standing WP:MOS guideline, that this guideline is and was based both on a nice simplicity (hyphen for "and", en-dash for "or" and "between"), and on a solid foundation of the way things were done in the publishing world for a long time, that this issue is not all that important, and that we revisit it from time to time as journalists move gradually in the direction of converting to hyphens. I'll be happy to discuss it in January, but I'm not going to discuss it every month. - Dan Dank55 (talk)(mistakes) 15:39, 23 June 2008 (UTC)
- Hah! I notice that <pre> completely mangled that, representing hyphens and en-dashes as being the same length. More evidence, if needed, that people are paying less and less attention. Let's try again. It's all en-dashes, except for:
- the post–World War II years
- a hospital–nursing home connection
- a nursing home–home care policy
- a quasi-public–quasi-judicial body (or, better, a judicial body that is quasi-public and quasi-judicial)
- but
- non-English-speaking peoples
- a wheelchair-user-designed environment (or, better, an environment designed for wheelchair users)
- (Abbreviations for compounds are treated as single words, so a hyphen, not an en dash, is used in such phrases as “U.S.-Canadian relations.”) - Dan Dank55 (talk)(mistakes) 15:46, 23 June 2008 (UTC)
- One more thing. This dash issue is brought up from time to time as evidence that the people that wrote the long-standing rules are out-of-touch rules fascists. Even though my personal position is somewhere in the middle, what I take away from the discussions I've read is exactly the opposite. Although things are gradually becoming simpler, rules for dashes have traditionally been very difficult. A variety of intelligent people talked about it and decided that, even though it's a little bit of an over-simplification, the rules could be simplified down to "hyphen, and, en-dash, or and between", and that would come very close to representing traditional publishing practice and be a hell of a lot easier to explain. Encyclopedic writing also is much better when it doesn't use a lot of extra words to represent a simple concept, and en-dashes are great for representing a simple concept in a simple way. The rules were designed for ease of use and to benefit a crisp encyclopedic style, and not for any other reason, that I can see. - Dan Dank55 (talk)(mistakes) 16:02, 23 June 2008 (UTC)
- There could be many worse recommendations, and if these were phrased and treated as recommendations, I could nearly agree with Dank's argument; for one thing, that would include acknowledgement that there are other legitimate methods of doing things. But look how WP:DASH is treated in FA reviews, and you will see demands for unthinking compliance with these rules, at least nine times out of ten. (That, of course, is in the minority of cases it is cited at all; whether mindless control of punctuation is worse than no review at all is a matter of taste, but we should aim for a middle ground.) Septentrionalis PMAnderson 16:14, 23 June 2008 (UTC)
- Many issues in MOS require a lot of explaining, and the challenge is just to do it as simply and briefly as possible. I can't imagine Capital letters tossed off in a sentences. TONY (talk) 16:06, 23 June 2008 (UTC)
- We could try for as clearly and accurately as possible, but there seems to be consensus against that...Septentrionalis PMAnderson 16:14, 23 June 2008 (UTC)
- One more thing. This dash issue is brought up from time to time as evidence that the people that wrote the long-standing rules are out-of-touch rules fascists. Even though my personal position is somewhere in the middle, what I take away from the discussions I've read is exactly the opposite. Although things are gradually becoming simpler, rules for dashes have traditionally been very difficult. A variety of intelligent people talked about it and decided that, even though it's a little bit of an over-simplification, the rules could be simplified down to "hyphen, and, en-dash, or and between", and that would come very close to representing traditional publishing practice and be a hell of a lot easier to explain. Encyclopedic writing also is much better when it doesn't use a lot of extra words to represent a simple concept, and en-dashes are great for representing a simple concept in a simple way. The rules were designed for ease of use and to benefit a crisp encyclopedic style, and not for any other reason, that I can see. - Dan Dank55 (talk)(mistakes) 16:02, 23 June 2008 (UTC)
Why are you all ignoring the fact that the naming conventions, which are policy, dictate that en-dashes are to be used in article names? And have done so for over a year? This conversation should be happening there. In any case, my argument has been iterated many times above: They look better, redirects are not even remotely a big deal, etc. There is no accessibility issue. Also Mexican-American war was moved to the hyphen version because of a technical restriction. Not because of any of the issues opposers on this page have brought up.--Dycedarg ж 17:16, 23 June 2008 (UTC)
- What technical restriction? If there is a technical restriction, we should document it.
- What WP:NC (which is the only naming convention to be policy) says is: For use of hyphens, dashes and hair spaces in page names, see Wikipedia:Manual of Style (dashes), which redirects here. If the policy is to be discussed, this is where to do it. Septentrionalis PMAnderson 17:22, 23 June 2008 (UTC)
- It says that, and when you look here it gives the instances in which en-dashes are to be used. Explicit statement on that page that that's what it means, when such is obvious, shouldn't be necessary. The technical restriction hasn't existed in over a year; what I was saying is that the specific example of Mexican-American War is moot because it was moved back for technical reasons, not because any consensus existed at the time that the current name was more correct.--Dycedarg ж 18:29, 23 June 2008 (UTC)
- Hmmm. so I assume that this clause in the naming conventions policy gives MOS policy status on the issue of dashes. TONY (talk) 17:28, 23 June 2008 (UTC)
- Not really, even for page names. WP:NC refers to its own subpages in the same manner, and they are, like this page, guidelines. Only assertions specifically made on that page are policy. Septentrionalis PMAnderson 17:34, 23 June 2008 (UTC)
I'm wholly in favour of using the correct en dash where it should be used by proper style in article titles. With redirects, there's no reason not to do it. —Nightstallion 21:25, 23 June 2008 (UTC)
- Using the correct en dash where it should be used by proper style in article titles verges on a tautology. Where is that? For example, is Merriam-Webster a good source for proper style in its own name? Nothing in NS's post answers that. Septentrionalis PMAnderson 21:35, 23 June 2008 (UTC)
- But it only verges because it ignores Rebecca's arguments. Septentrionalis PMAnderson 21:35, 23 June 2008 (UTC)
- From where I stand, as long as
- the usage of en dashes in text is not disputed, and
- there is no way to prove that more people will reach an article through the go button rather than through a link or a search page (especially in the cases of many lists, which have long names difficult to get right the first time),
- it is impossible to know that with using hyphens in the titles we shall have fewer redirects. As style in articles is steadily improving and a great percentage of links now makes provision for en dashes, moving articles back to hyphenated versions will either create redirects (avoiding which is the entire point of the discussion, although, for the record, I don't mind them at all) or force us to pipe-link where it is hardly necessary, making things realistically harder for editors (in contrast to the implications of having a line saying "redirect" below the title, which the honourable colleagues have failed to actually present to us).
- And all this is said without considering the advantages of accuracy and clarity that the usage of dashes offers. Ignoring them in order to gain something in terms of usability is an argument, even though I categorically disagree that not seeing redirects is such a gain; ignoring them only to end up with nearly as many redirects constitutes a pointless sacrifice resulting in net loss. Waltham, The Duke of 23:02, 23 June 2008 (UTC)
- As far as I understand Rebecca's argument, she's not objecting to the existence of redirects, but to readers arriving at the article through a redirect. This will happen when they type the simple hyphenated form and arrive at the endashed one. I write subject to correction, of course. Septentrionalis PMAnderson 00:14, 24 June 2008 (UTC)
- Certainly, that's what I meant. If my phrasing indicated otherwise, I apologise. Waltham, The Duke of 02:50, 24 June 2008 (UTC)
- Then I don't see why the creation of redirects from the endashed form to the hyphenated form matters; readers won't use them. That's what misled me. Septentrionalis PMAnderson 16:09, 24 June 2008 (UTC)
- I meant that if we were to use hyphenated titles instead of en-dashed ones, then the en-dashed links would have the readers use redirects almost as often as they would through the search box for en-dashed titles. Therefore, no real gain. Waltham, The Duke of 19:06, 24 June 2008 (UTC)
- I don't see arriving at an article via a redirect as a usability problem. The only usability problem I can envisage is that people will create redirects to the hyphenated titles, thus unknowingly creating double-redirects. But the days of having to fix these problems manually are long gone - this is easy fodder for a bot. Hesperian 00:25, 24 June 2008 (UTC)
- It's ugly, and it's unnecessary. Let's put it this way: we can have fifty thousand redirects that the ordinary reader is going to notice and think "eh, what happened there?" - or fifty thousand hyphens which about thirty people on the project find a stylistic gripe with. The issue doesn't arise with text; the reader doesn't notice it, and it's easy enough for the ordinary editor to cover it, but it's madness to force article titles to use a character that the vast majority of our readers have no idea how to actually enter. Rebecca (talk) 01:51, 24 June 2008 (UTC)
- How can you arbitrarily declare that more people are annoyed by redirect notices than care about whether or not dashes are used? Do you have some way of polling the general population of readers you haven't shared? I have never heard someone complain that redirect notices are ugly, nor seen a thread in the village pump asking the devs to make them prettier. Don't think village pump readers are too petty for something like that either, there was a massive thread about whether or not the little guy who appears next to usernames at the top of the page in monobook was racist. You don't know whether or not people would like dashes more, nor have you demonstrated that they dislike, or are confused by, redirect notices.--Dycedarg ж 02:01, 24 June 2008 (UTC)
- It's not a matter of "liking dashes". It's a matter of the vast majority of the population not knowing the difference; hell, before I came on Wikipedia, I'd never met anyone who knew the difference, let alone cared about it. Redirect notices are generally fine - they alert you to where you've been redirected from, and it does its job. It's just when you have to have one pop up every single time one accesses a page with a dash in the title that it becomes very annoying. As far as the vast majority of our readers are going to be concerned, they're going to be constantly getting irritating redirect notices that appear to have redirected from exactly the same title. While I get that there's something of a bias on this particular page towards people who are absolutely fascinated by things like the length of a dash, it's just bad practice to force the tens of thousands of commonly-accessed pages to use a character that the vast majority of our readers cannot type on their keyboards. Rebecca (talk) 02:11, 24 June 2008 (UTC)
- Every single time? Hardly. You have practically ignored my comment above; people might reach an article through a link or a search page as often as they do through a direct, successful request at the search box. And if en dashes are used in text, they are used in links, and if the article has been moved to the hyphenated version, the reader will have to pass through a redirect.
- Oops. That's what you were trying to avoid, right? Waltham, The Duke of 02:50, 24 June 2008 (UTC)
- Er, no. What I'm suggesting is simple, and what is still actually done in practice in most areas (witness the links to Mexican-American War cited above); keep the article title and the links to it at the one that people can actually type, and do whatever the hell you like with the rest of the text. It is of course true that there are other ways to access the article, but why is it so unreasonable that one should actually be able to access the article by normal means without the use of a redirect? I've yet to see a compelling reason to enforce this on the project besides WP:ILIKEIT - there's just no good reason why can't make a practical exception for article titles. Rebecca (talk) 02:56, 24 June 2008 (UTC)
- I think what people here would like to consider a compelling reason to enforce this on the project is "It is grammatically incorrect, and this is an encyclopaedia". Hesperian 03:19, 24 June 2008 (UTC)
- So, if I understand correctly, Rebecca has moved from "keep en dashes in the text" to "keep en dashes in the text except for links". And then we are forced to either compromise professional writing by creating massive inconsistency within articles, or we have to flood them with avoidable and meaningless pipe-links, complicating the edit window more than is warranted. Unless I am imagining these problems—and I have good reason to believe that I am not—they have probably flown right past the honourable colleague. The thing is, the further we pursue this discussion, the more insane and convoluted Rebecca's suggestions sound; this profound lack of simplicity and common sense is not the mark of a sound proposal.
- Neither is the fact that a simple style issue which might as well be fixable by a script asserts precedence over Wikipedia's mission as an encyclopaedia. Waltham, The Duke of 04:52, 24 June 2008 (UTC)
←Now that Rebecca has calmed down from her earlier hysteria (referring to me as a "buffoon", etc, and to many of my colleagues here as "people who are absolutely fascinated by things like the length of a dash"); and now that it's apparent people here don't go along with Anderson's characterisation of MOS as being ruled by a few obsessive zealots, let's examine the latest assertions. While considerably down the shock-horror scale, they are nonetheless on a par with what spin doctors for politicians come up with:
Redirect notices are generally fine – they alert you to where you've been redirected from, and it does its job. It's just when you have to have one pop up every single time one accesses a page with a dash in the title that it becomes very annoying.
It's as though half of the articles had an en dash or required one. Um ... no; it's a rather tiny proportion. If they really make your sides ache, your cache settings should prevent the display of the redirect where you need to access a page more than once in a session. Mine do.
to use a character that the vast majority of our readers cannot type on their keyboards
But ... they don't have to type it. Nor do readers have to write good prose; we have to.
... before I came on Wikipedia, I'd never met anyone who knew the difference, let alone cared about it
Yeah but no but yeah but. We're engaged here in what is effectively the business of publishing on a scale never seen before, not of writing substandard undergraduate essays. Publishing houses have to deal with these matters; ordinary readers don't, but will benefit even if they're unfamiliar with the finer points of the en-dash vs. hyphen issue. TONY (talk) 03:20, 24 June 2008 (UTC)
- I honestly don't see any consensus for having it be a requirement that page titles use en dashes instead of hyphens. It can be a suggestion, it can be part of the featured article guidelines, but it really shouldn't be mandatory (which is how it is being interpreted currently). What is the issue with keeping it optional? --MZMcBride (talk) 05:47, 24 June 2008 (UTC)
- Confusing inconsistency? Bad writing practice? We might have all sorts of mistakes in our articles, but the titles are more important, more prominent, and harder to change; these should be paid more attention. And what does, in any case, "optional" mean? A lease of time? Because if a format is better, then sooner or later it will be adopted. And we'll have an inconsistent mess all the way until then. We've had it so far; let us bring about some order now. Waltham, The Duke of 06:29, 24 June 2008 (UTC)
- Precisely. In my opinion, as far as style and precision is concerned, Wikipedia should not follow "do what others do" (i.e., WP:COMMON and similar things), but rather should try to follow the highest standards of typography, precision, etc. possible. —Nightstallion 13:24, 24 June 2008 (UTC)
- I agree. It's not as if anyone's going to be thrown off Wikipedia for breaching punctuation guidelines, but we can ensure that clear guidance is there for those who do care, and that we have a community document to appeal to if people start opposing or reverting stylistic improvements to articles. --Kotniski (talk) 16:27, 24 June 2008 (UTC)
- You are asking what this same "clear guideline" means, a couple sections below. The answer is: it doesn't mean much. Septentrionalis PMAnderson 20:03, 24 June 2008 (UTC)
- (German accent) The Manual of Style rarely means much to P. M. Anderson. I, Dr Sigmund Fraud, expert psychoanalyst, have concluded that Mr Anderson is experiencing intense suffering stemming from repressed memories connected to a traumatic incident involving the Manual, which prevents him from comprehending it or even wanting to attempt to understand it. I suggest a series of very expensive therapy sessions, which will mostly work by boosting Mr Anderson's morale and self-esteem, as well as in other ways I have yet to study, as my professional skills are rather dubious, really. :-D Waltham, The Duke of 22:27, 24 June 2008 (UTC)
Motion to close
The arguments in favour of retaining the guideline in question are overwhelming, as is the support towards it, even from people who do not frequent these noble halls of style. There are issues here of high-quality encyclopaedic writing, internal consistency, and usability, and unless there is a satisfactory reply to all these concerns, I am removing the "disputed" tag from the page on 27 June. I request that it should be retained until then, so that no objections can be raised on grounds of due-process violation, contempt of the community, hostile environment causing bias, etc. We want to be fair. :-) Waltham, The Duke of 19:06, 24 June 2008 (UTC)
- In a month or two we will have another complaintant. The solution is to word this as a recommendation rather than a prescription; but if we are going to treat this vague buncombe as a Higher Truth, which needs no justification or evidence but our lordly say-sos, I don't suppose that will happen. Septentrionalis PMAnderson 19:24, 24 June 2008 (UTC)
- If there is another complainer, they should be referred to this discussion. It is not so much how the guideline is worded here; rather, it is the context thereof that one must understand. In text, we do not force any editors to follow the Manual of Style—if someone wants to apply it, they do so; if they are unaware of it or prefer not to bother, they are free to ignore it. What they cannot do is revert edits that apply the Manual, so sooner or later its provisions will be applied on text. But the vehicle for this application will be the free will of editors.
- (Featured Articles are the exception here, but why? Because FA is a process, and if one wishes to participate, one has no choice but to follow the criteria of this process. If the most important thing for a person is to write hours as 07.00 AM, they can do so, but under two conditions: they should not revert edits changing it to 07:00 am, and they should not visit FA.)
- An exaggeration, fortunately. But that's not the problem; rather the problem is reviewers who post as though writing "07:00 am" were the only important thing. Septentrionalis PMAnderson 01:14, 25 June 2008 (UTC)
- For them it might be, but there is, thankfully, something called specialisation. Let them worry for the hard space (which is an improvement, by the way, so it is not a bad thing to have someone point it out in a FAC), and other editors will take care of the rest. FAC is such a good process exactly because there are people to comment on everything, offering a more spherical view of the article examined and its deficiencies. Waltham, The Duke of 03:43, 25 June 2008 (UTC)
- On the other hand, titles are not simply a way to write things; they represent the location of pages. This is above plain grammatical conventions, and is connected to the way Wikipedia's fundamental unit of information is organised, namely articles. Accuracy, brevity, consistency, and clarity are of paramount importance, and individual initiative is, and should be, minimal. This is why Naming Conventions is policy and the Manual of Style is a guideline. It's how things work around here. Waltham, The Duke of 22:03, 24 June 2008 (UTC)
- And which of "Accuracy, brevity, consistency, and clarity" are affected by the section at issue? Not brevity; endashes are longer, if minimally so. Septentrionalis PMAnderson 01:06, 25 June 2008 (UTC)
- I was speaking generally. I shall be more specific, then: en dashes offer more clarity, and the guideline not naming hyphens as an equally valid option offers consistency. Accuracy is also gained, as Wikipedia clearly uses en dashes, and should therefore use them properly, and not in a confusing and haphazard (and confusing in its haphazardness) fashion. Waltham, The Duke of 03:43, 25 June 2008 (UTC)
I really don't understand why this discussion is still going on. It is clearly a good thing to have a certain uniformness in our articles. There are a lot of other things that are more important, but I am not aware of any that would contradict this particular prescription. We could prescribe the opposite; but that would be worse. We could make more complicated rules; nobody seems to want that.
No articles are deleted for failure to follow the MOS. No editors are banned for obstinately ignoring the MOS prescriptions. It's even possible to be an extremely active editor in ndash-infested articles without ever writing an ndash, so long as you don't revert ndashes back to hyphens just for the sake of doing it. We have a choice between ever so ugly redirects appearing when we enter something into a WP search form, or when we follow a link from WP or Google. --Hans Adler (talk) 22:22, 24 June 2008 (UTC)
- Because of his Grace's admission above, which would be more accurately phrased "if editors are not willing to spend endless time changing every jot and tittle of an article to the preferences of the handful of dogmatists at MOS, they might as well not visit FA." That is one of Wikipedia's major problems; that there is no reward for actually writing excellent articles, because our reward system has been taken over by reviewers who do not discuss content, but who have unlimited demands on punctuation. Let these pages be written so they are recommendations at FA as well as elsewhere, and I will be content;if this page concedes that it is a handful of preferences and recommendations, which are neither necessary nor sufficient for a professional standard of prose, I will take this page off my watchlist. When FA actually discusses content intelligently, it is one of Wikipedia's best processes; let it do so more often. Septentrionalis PMAnderson 00:50, 25 June 2008 (UTC)
- I am surprised indeed that Mr Anderson should have so low an opinion of one of our most important processes. FA status does not exist for the sole purpose of rewarding hard work, and although I am not claiming that diligent editors should be content with a barnstar, the view that Featured Articles should be anything else than the best that Wikipedia has to offer to our readership—from all aspects—is sadly mistaken. This community is like every other society in that it allows for specialisation and delegation of work; even if there are some editors who can single-handedly bring stubs to FA status, this is not the rule. Every editor has strengths and weaknesses, and while some are good with sources, they might be awful writers—and vice versa. There is nothing wrong with contributors soliciting the aid of colleagues in order to ensure the elevation of articles to the class of our very finest content, and there are both the editors with the knowledge and interest to help and the means to find them. If nominators don't do so, then they might end up discussing punctuation more than content, but this at least means that the content is not so bad, or it should certainly take precedence.
- Even so, the quality classification system is being modified to make the class designations clearer, and put in place a site-wide project-based system for both B-class and A-class articles; if it works well, content concerns will have been mostly addressed before an article is listed as FAC. Waltham, The Duke of 03:31, 25 June 2008 (UTC)
- Is it is one of Wikipedia's best processes a low opinion? But FA varies unpredictably between too lax and too stringent, and many reviewers appear to stray into pinuctaion, not because nothing is wrong with the content, but because they don't know anything about the content. If this resulted in a comment and abstain, it would be mildly helpful; but all too often it is an oppose. Septentrionalis PMAnderson 14:53, 25 June 2008 (UTC)
- No, "there is no reward for actually writing excellent articles" is. Please re-read the first paragraph of my message above, especially the second and fifth sentence.
- FA is not infallible. From my limited experience with the process, the technical criteria do seem to be on the forefront; on the other hand, remember that they are easier to determine, and there are so many of them anyway: section length and balance, grammar and style, images (suitability, copyright, captions), reference and footnote consistency... In any case, I cannot say what should be done in the FAC process, but articles there have made a long trip and are more likely than not to have only minor content problems, or none at all. And I've mentioned the strengthening of A-class, haven't I? Waltham, The Duke of 20:07, 25 June 2008 (UTC)
- Hans: It's pretty simple, really. This is being discussed because someone is trying to use a bot to move thousands of pages under this "policy." (Nevermind the fact that this page isn't policy. ; - ) ) Rebecca, me, et al. are trying to stop is this page and in particular this piece from being enforced as the word of God. The goal is to ensure that people don't interpret this particular clause as a requirement, and instead as a suggestion that can be applied if the editors on a particular talk page agree or if the article is going through FAC or something. But the practice shouldn't be mass-implemented as it's annoying to editors to be redirected constantly. --MZMcBride (talk) 01:10, 25 June 2008 (UTC)
- Which bot? There are other ways of dealing with bots. Septentrionalis PMAnderson 01:15, 25 June 2008 (UTC)
- For the last time: The naming conventions are policy. If you don't like the statement "For use of hyphens, dashes and hair spaces in page names, see Wikipedia:Manual of Style (dashes)." than get it changed. Until then, my running of my bot is justified. No consensus has thus far been demonstrated that I shouldn't do so, except the objections of the two of you. The objections of two people are neither consensus nor an indication that consensus does not exist. If in 24 hours you can't get consensus here or elsewhere that I shouldn't be doing this, my bot will run. Period. You can't block an approved bot operating within the bounds of demonstrated consensus, and should you choose to do so I will take this elsewhere.--Dycedarg ж 02:10, 25 June 2008 (UTC)
- Wikipedia:Manual of Style (dashes) redirects to Wikipedia:Manual of Style#Dashes, which has a disputed tag in it, specifically in the en dash section. As I said on your talk page, making threats like this is plainly a bad idea. --MZMcBride (talk) 04:27, 25 June 2008 (UTC)
- I put that disputed tag there because I thought it better than Rebecca's brilliant idea of removing half the section. It shall be removed when this issue is addressed, and am quite confident that this will happen soon, as I cannot see you thinking of any argument other than "I don't like redirects". Although I do not approve of Dycedarg's tone here, he is right in that you have no case. Using en dashes in titles is a policy-endorsed and very much justified trend, in that it offers great benefits while keeping side-effects to a near-zero; it is also practically irreversible, in that full title hyphenation would be a massive setback for the project and the source of significant problems. The bot simply follows the times and speeds up the process, saving us human editors some unnecessary trouble—the style side of the matter covered, all technical aspects of the bot have been evaluated, resulting in its approval for operation. The bot in question is perfectly legitimate in every way, and the continued support towards it by people unrelated to the approval process demonstrates this aptly. Before repeating the same arguments, Mr McBride, I strongly suggest revising the above thread, where every single one of your points is refuted; perhaps you will then realise that stopping now will save us all time for doing something more constructive than arguing what is normally taken for granted. Good day. Waltham, The Duke of 06:20, 25 June 2008 (UTC)
- (left) But does Dycedarg understand that this section, vague though it is,
- Supports some hyphens: but a hyphen is used in Mon-Khmer languages, which marks no specific relationship, and in Sino-Japanese trade, in which Sino-, being a prefix, lacks lexical independence.
- And that we failed, the last time we discussed this, to decide exactly where the line should be drawn.
- This seems a most undesirable situation to address with a bot. Septentrionalis PMAnderson 13:20, 25 June 2008 (UTC)
- Ooh, thanks, Tony; you're so kind! Septentrionalis PMAnderson 14:18, 25 June 2008 (UTC)
But quite seriously, the present wording is the undefined term disjunctive with a list of examples. We concluded, last time we were asked, that we weren't sure exactly why Mon-Khmer was hyphenated, and we'd have to wait for Noetica to decide how far that example extends. Is this clarity, or is it mud? (But as long as the bot doesn't work faster than it can be watched, that may work in practice.) Septentrionalis PMAnderson 14:18, 25 June 2008 (UTC)
- I was just complaining to Waltham that examples in WP:DASH need improvement, but I think en-dashes should be required. There is a good reason why MS Word automatically corrects them. They are a sign of a good, academic writing and should be enforced. Renata (talk) 20:02, 25 June 2008 (UTC)
- (edit conflict) We have long drifted off-topic. As long as neither the policy status of the naming conventions nor the appropriateness and utility of en dashes in year ranges is disputed, nothing changes for the bot; all it does is to "convert" hyphens to en dashes in year ranges. If people want to discuss the particulars of the guideline on en dashes, very well; but it should be made clear that the bot may resume its operation undisturbed. Waltham, The Duke of 20:07, 25 June 2008 (UTC)
- Which bot is it?
- Are its operations to be confined to year-ranges? This is the first anybody's said so here, and it's not where this topic began. Septentrionalis PMAnderson 14:37, 26 June 2008 (UTC)
- The bot in question is DyceBot, and yes, its operations are to be confined to year-ranges. Nothing else has been discussed yet. Personally, I feel that we have a very long way to go until the moment when robots will be sophisticated enough to successfully edit text (if they ever will); it would require a tremendous degree of analysis and I should want to see extensive materials samples of its ability to do such a task before supporting it. Words have a meaning, which differs from case to case, as does dash usage, and unless one can understand the meaning of the words, one cannot make accurate evaluations as to whether a hyphen or en dash should be used in a title. This is not true for number ranges, however, as all of them need en dashes. It is a very sweeping rule. And given that there are hardly any numbers in titles connected by dashes that are not ranges requiring en dashes, it is only once in a while that a false positive will surface. That is a risk that we can take, if we can reach general consistency earlier and with less human resources expended in so tedious a task as moving pages. Waltham, The Duke of 01:00, 27 June 2008 (UTC)
- Then that should be less of a problem. Most date ranges will be in parenthetical disambiguation, which nobody will be expected to search for. Can it create redirects with hyphens where they don't now exist too? Septentrionalis PMAnderson 02:33, 27 June 2008 (UTC)
- The bot in question is DyceBot, and yes, its operations are to be confined to year-ranges. Nothing else has been discussed yet. Personally, I feel that we have a very long way to go until the moment when robots will be sophisticated enough to successfully edit text (if they ever will); it would require a tremendous degree of analysis and I should want to see extensive materials samples of its ability to do such a task before supporting it. Words have a meaning, which differs from case to case, as does dash usage, and unless one can understand the meaning of the words, one cannot make accurate evaluations as to whether a hyphen or en dash should be used in a title. This is not true for number ranges, however, as all of them need en dashes. It is a very sweeping rule. And given that there are hardly any numbers in titles connected by dashes that are not ranges requiring en dashes, it is only once in a while that a false positive will surface. That is a risk that we can take, if we can reach general consistency earlier and with less human resources expended in so tedious a task as moving pages. Waltham, The Duke of 01:00, 27 June 2008 (UTC)
- I have no idea, but I suppose not; redirects are created as a result of moves, and the bot mostly does that. I assume that, for articles created straight with the en-dash version, someone must create the redirects as well, if not at the same time then soon, realising that using the hyphen takes them to a search page.
- Meanwhile, I should like to express my disappointment at you for trying to circumvent the consensus here; failing to change the guideline in MoS, you are now trying to have the policy on article-naming changed. I believe this is exactly the kind of behaviour the term forum shopping has been coined to describe. Waltham, The Duke of 04:49, 27 June 2008 (UTC)
- I regret disappointing Your Grace; but in fact this is precisely what Dycedarg envisioned above; I think the old wording on WP:NC less than ideal, and I took it there, citing this discussion. We'll see what happens. Septentrionalis PMAnderson 20:13, 27 June 2008 (UTC)
- What? Whereon do you found this assertion? The man said: "If you don't like the statement 'For use of hyphens, dashes and hair spaces in page names, see Wikipedia:Manual of Style (dashes).' than get it changed." I should hardly refer to such a statement as a "vision", and it is highly misleading of you to do so. Waltham, The Duke of 00:12, 28 June 2008 (UTC)
- His Grace should be preparing for His exams, not tangling with Anderson. TONY (talk) 05:42, 28 June 2008 (UTC)
- I don't like it (as I said there, I doubt hair spaces belong in titles at all); I brought it up for discussion, and it is now different, although I don't see a great change in policy. I will be glad to discuss this with His Grace when exams are over, and I wish him fortune. Septentrionalis PMAnderson 20:02, 28 June 2008 (UTC)
- Too late. :-)
- Fresh motion for closure: if no well-founded objection is filed by the end of the current month, I am removing the disputed tag on 1 July. PMAnderson has taken the matter to the policy page, anyway. Waltham, The Duke of 20:01, 28 June 2008 (UTC)
- Does "too late" mean that His Grace has failed His exams, or just that the exam period is over? TONY (talk) 08:16, 29 June 2008 (UTC)
- Too late not to tangle with Anderson. :-) The exams are almost over, and the results are mixed. They would be much better if I were to be examined on Wikipedia-related matters, but nobody is that lucky. Waltham, The Duke of 05:23, 30 June 2008 (UTC)
I have removed the tag. This discussion is officially closed. Waltham, The Duke of 08:59, 1 July 2008 (UTC)
__FORCETOC
I didn't see anything about __FORCETOC__ in the article. I think it should be included because almost all Articles use FORCETOC — Preceding unsigned comment added by Condalence (talk • contribs)
- I wouldn't call 401 out of 2.4 million "almost all". If you use the "Random article" link, you can easily verify that more than half of our articles don't have a table of contents. --Hans Adler (talk) 10:56, 23 June 2008 (UTC)
- On the other hand, if we documented the possibility, it might be used more often. Whether this would serve any great purpose, since FORCETOC should only be used when the position provided by the software is unacceptable, is another question. Septentrionalis PMAnderson 12:51, 23 June 2008 (UTC)
Sorry, the reason I said "almost all" was because most articles I see have FORCETOC. Could I request it to be added? FORCETOC really does serve a great purpose for long articles. That way instead of scrolling someone can just simply click to a paragraph. I do that a lot. Thanks. --Condalence] 22:35, 23 June 2008 (UTC)
- As far as I know, whether an article has a table of contents or not depends on the number of sections. When it has only one section, for example, a table of content would be useless and look ridiculous. If you want one anyway, you can use FORCETOC. See Template:H:TOC variables. Many larger articles have TOC, which forces that the table of contents is in a certain position. This sometimes becomes necessary as a result of complicated layouts with many funny templates. But the vast majority of articles don't need any of the three templates (the third is NOTOC, which enforces that there is no table of contents.) Currently less than 1% of our articles use one of them, and the one that is used most frequently is NOTOC. If you have added FORCETOC to a lot of articles you should probably remove it. --Hans Adler (talk) 22:47, 23 June 2008 (UTC)
Proposal relating to Leading off first sentences with qualifiers
PROPOSAL: - OK, this has been bothering me. Lately I've been seeing a lot of scientific articles beginning with the format "In xxx, xxxxx is ..." as in "In computing, phishing is ..." An article I created recently was change to this format. What this is saying is that all information about the topic is limited to relating to the qualifier. Phishing only is used in computing and no where else. Subpersonality only is used in transpersonal psychology and no where else. If this were true, then the articles should be titled Phishing (computing) and Subpersonality (transpersonal psychology). However, it is not true that every sentence and every of bit of information in the Phishing article relates to computing. Every sentence in Subpersonality does not relate to transpersonal psychology and subpersonality certainly is not limited to the field of transpersonal psychology. Most telling, Wikipedia:Manual_of_Style#First_sentences states "If the topic of the article may be unfamiliar to some readers, establish a context." I agree with establishing context, but do not agree with establishing context by beginning the article with "In xxx,". The MoS example given results in qualifying trusted third party, entity, and the two parties to being cryptography elements. However, only "entity" is cryptography element. The two parties, e.g., Bob and Alice, are humans and certainly not only cryptography element. The example given in the MoS incorrectly approves limiting trusted third party, entity, and the two parties to cryptography. The Trusted third party article also addresses "outside cryptography". How can it do that if the article is limited to cryptography by the lead sentence to the article? If this "In xxxx,"-qualifier lead technique is acceptable, then the lead sentence to Trusted third party should read "In cryptography, a trusted third party (TTP) is ... ." In law, a trusted third party is ..." This makes the articles look more like disambiguous pages rather than an article. I proposed that Manual of Style should explicitly reject the use of "In xxx," as an acceptable way to provide context in the first sentence of an article. If you agree, disagree, or have a different observation/solution, please post below. Bebestbe (talk) 14:54, 23 June 2008 (UTC)
- We should certainly not prohibit the usage; consider, for example, Abelian group, which begins "In mathematics..." and the implication seen here is quite correct. How much caution is warranted? Septentrionalis PMAnderson 15:59, 23 June 2008 (UTC)
- I agree with the examples that were given here by both above contributors. I think that Bebestbe has made clear that the "In xxx,"-start of the lead can be a bad choice. However, we've also seen that it can be a good start. So, IMHO a strict prohibition is not appropriate, but you have my support in the specific cases that you've shown. Tomeasytalk 16:46, 23 June 2008 (UTC)
- The tradeoff here is speed for accuracy, and there's no way around that. Some things in the lead section will not be precise, and will only be qualified and explained later, because the lead section draws people in and summarizes. I wouldn't mind saying in the guideline that people should at least think twice before over-simplifying in the lead section, and I wouldn't mind a recommendation that over-simplification should be remedied as quickly as possible, preferably in the first section. - Dan Dank55 (talk)(mistakes) 17:24, 23 June 2008 (UTC)
- Precise context is nice, but it's far better to establish an imprecise context than none at all. The summary is necessarily imprecise, as Dank55 suggested - it only highlights the most important qualities and doesn't deal with exceptions. That said, the "in X" should denote the primary field associated with the term; if there is no such field, perhaps 2 or 3 should be listed. Dcoetzee 02:07, 24 June 2008 (UTC)
First sentences: OK to link to official website?
In contrast to the current* "First sentences" guideline, I find it extremely web-UNfriendly not to hyperlink the subject of a wikipedia page to its official website (if there is one). Web users intuitively want to be able to link to appropriately relevant information when they read a phrase. I understand and completely agree that IN GENERAL the subject of a Wikipedia page should not be hyperlinked to anything else--after all, the Wikipedia article is presumably the explanation of the subject--but in the case where the topic of the page is an organization (or product, or person) that has an OFFICIAL website, it seems both appropriate to link to it from the (bolded) subject of a Wikipedia page, and INappropriate NOT to hyperlink to it. Does this make sense (to anyone besides me)? Is there a way we can get this concept considered for official inclusion** in the guideline?
- [[1]]: "The first (and only the first) appearance of the title is in boldface, including its abbreviation in parentheses, if given. Equivalent names may follow, and may or may not be in boldface. Items in boldface are not linked...."
Thanks... philiptdotcom (talk) 01:02, 24 June 2008 (UTC)
- Even apart from current guidelines and policies, this one doesn't have a chance because the wiki culture is so completely opposed to letting people or organizations dominate the web page that's about them in any way. There is no chance this would get the broad consensus necessary. - Dan Dank55 (talk)(mistakes) 01:50, 24 June 2008 (UTC)
- On the more technical side, external links are discouraged in the entirety of the body of any given article; the only sections where they are supposed to be used are "(Foot)notes", "References", and "External links". The exception for the text in bold exists because it refers to internal links.
- On the more theoretical side, the official sites are usually biased, which is why they are rarely used as sources. Which brings me to the practical side...
- Unless the official site is used as a source, in which case it is to be found in the "References" section, it will be the first link in the "External links section". Just go to the bottom of the article and you'll find it. After all, you've come to Wikipedia for our view of the subject, not the subject's view of itself; further research opportunities are given after the article ends (we should not presume that we'd ever contain all the information you'd need, of course). If you are not satisfied by this configuration, I respectfully suggest referring to Google or one of its competitors. Waltham, The Duke of 03:06, 24 June 2008 (UTC)
- Thanks for the infopinions. I guess I haven't quite made the leap between "web mentality" and "wiki mentality." Although intuitively (and actually) "wiki" is a subset of the "web," evidently wiki culture is such a big thing (like amazon.com, in its own way) that it makes its own rules RE: web usability. Live and learn... Aloha, philiptdotcom (talk) 01:53, 25 June 2008 (UTC)
Query
- Edit mode toolbar
Insert: –(endash) —(emdash) ... ‘ “ ’ ” ° ″ ′ ≈ ≠ ≤ ≥ ± − (minus sign minutely larger than the hyphen) × ÷ ← → · § Sign your username: ~~~~ (on talk pages)
Am I right? Or have I misunderstood
- [—] ie. Emdash = The long dash in the edit mode is emdash and can also be obtained by typing &
mdash;
- There are other ways of entering an emdash directly from your keyboard, described at Dash. They aren't all listed in MoS because the method differs depending on your system. SandyGeorgia (Talk) 17:29, 24 June 2008 (UTC)
- Never spaced
- Usage: Wikipedia—one of the most popular web sites—has the information you need
- [–] ie. Endash = Also available in the edit toolbar or type &
ndash;
- Same for above; for example, both of these (en and emdash) can also be entered from Internet Explorer by using an alt keypad combo of 0150 or 0151. Depends on your browser; see Dash. SandyGeorgia (Talk) 17:29, 24 June 2008 (UTC)
- Mainly for disjunction
- Spaced or unspaced
- Usage: pp. 12–45
- Usage: non-violence (word), atti-tude (syllable)
Now the queries
- When to use spaces while using endash? (WP:MOS#Dashes is not clear to me)
- How to use the space? Whether the html entity &
nbsp;
or the spacebar space?
KnowledgeHegemonyPart2 (talk) 15:25, 24 June 2008 (UTC)
- Personally I space the en dash when it's used to separate parts of sentences (i.e. in the role which can also be performed by an unspaced em dash). Also in a few special cases like 1 January 1999 – 2 February 2004. Otherwise it generally shouldn't be spaced. I believe it's recommended to use a no-break space before the dash, but a spacebar (breaking) space after.
- Only if it actually breaks wrongly, which will rarely happen. Septentrionalis PMAnderson 16:57, 24 June 2008 (UTC)
- By the way, can anyone refer to a dictionary definition of "disjunction" which shows that it means what it's supposed to mean in the en-dash recommendation? It doesn't seem to fit any of the normal meanings of the word.--Kotniski (talk) 16:43, 24 June 2008 (UTC)
- Disjunction does not have to involve an OR; the OED's first, general, definition is The action of disjoining or condition of being disjoined; separation, disconnexion, disunion. Septentrionalis PMAnderson 18:00, 24 June 2008 (UTC)
- Meaning that we write "Mexican–American War" because wars tend to disunify, and "blood–brain barrier" because barriers tend to separate? But would we not equally be urged to write "Mexican–American Union" and "blood–brain coalescence", if such concepts existed, despite the lack of any implication of disconnexion?--Kotniski (talk) 18:55, 24 June 2008 (UTC)
- I think that's the intent: Mexico and the United States, bloodstream and brain, are two pairs of disjoint things. As I read the section, it might encourage hyphens in your second examples. But do remember that I oppose the section as vague nonsense, and this sort of thing is why the endash, a printer's invention, is re-uniting with the hyphen. Septentrionalis PMAnderson 19:19, 24 June 2008 (UTC)
- Personally I space the en dash when it's used to separate parts of sentences (i.e. in the role which can also be performed by an unspaced em dash). Also in a few special cases like 1 January 1999 – 2 February 2004. Otherwise it generally shouldn't be spaced. I believe it's recommended to use a no-break space before the dash, but a spacebar (breaking) space after.
- Sure: "blood–brain barrier", "Mexican–American War", "3–1 win". But as below, if there's a space within one or both of the items, the en dash needs to be spaced: "3 August 1980 – 15 September 1991", but "3–7 August". TONY (talk) 17:45, 24 June 2008 (UTC)
- Requirements for nbsp are discussed at WP:NBSP. When the surrounding elements have spaces (such as full dates), the endash is spaced. Example:
- 1950–1951 (unspaced endash because no spaces in surrounding elements)
- July 1950 – June 1951 (spaced endash because of spaces in surrounding elements)
- Also, any of the methods for entering the correct dash can be used interchangeably (there was a recent FAC where it was stated that an html endash must be used, and the nominator unnecessarily replaced all of the correct endashes with html endashes. This wasn't necessary; any input method can be used, as long as the correct dash results. SandyGeorgia (Talk) 17:33, 24 June 2008 (UTC)
- Well now I feel a bit more confident about dashes! Sandy ain't the FAC delegate for no reason. She knows a lot of stuff! KnowledgeHegemonyPart2 (talk) 17:47, 24 June 2008 (UTC)
Unnecessary pictures
Quick question: Where's the guideline that says "don't use pictures if they don't add anything to the article"? Thanks, Matthewedwards (talk • contribs • email) 16:01, 25 June 2008 (UTC)
- WP:OFFTOPIC. I doubt it says anything about images in particular, but does it have to? Septentrionalis PMAnderson 16:29, 25 June 2008 (UTC)
- It should be common sense. Images are visual cues for the reader that tell them their attention is needed. Why disrupt their reading for decorations? --Laser brain (talk) 17:42, 25 June 2008 (UTC)
- I should like to note that, while FA criteria may give an idea of what great articles should be like, they do not have guideline status. For future reference. Waltham, The Duke of 04:56, 27 June 2008 (UTC)
- This revision, of gold, silver and bronze pictures in the tables. They've been removed now, but something to reference when this thing occurs would be helpful, especially when not dealing with FAC/FLCs. Matthewedwards (talk • contribs • email) 20:12, 27 June 2008 (UTC)
- I don't know what Laser Brain will think, but those look like visual cues to the reader to me. If there is consensus they're clutter in these tables, fine; but it doesn't look like we need guidance for this matter of taste. Septentrionalis PMAnderson 21:51, 27 June 2008 (UTC)
- This revision, of gold, silver and bronze pictures in the tables. They've been removed now, but something to reference when this thing occurs would be helpful, especially when not dealing with FAC/FLCs. Matthewedwards (talk • contribs • email) 20:12, 27 June 2008 (UTC)
←I agree with Anderson that this is hard to pin down in a guideline. People, reviewers, can appeal to common sense and the disadvantages of visual clutter to persuade, yes? TONY (talk) 05:47, 28 June 2008 (UTC)
- Sometimes it's useful to have one or two "artistic" pictures relevant to the topic, which may not be as informational as others, simply to create an impression of quality. There is consensus on not including decorative fair-use images, since this risks falling afoul of fair use law. Dcoetzee 00:39, 30 June 2008 (UTC)
Block quotes: four lines or four sentences?
The following issue came up during the peer review of Golden Film. What is meant in the following phrase: "A long quote (more than four lines, or consisting of more than one paragraph, regardless of number of lines) is formatted as a block quotation, which Wikimedia's software will indent from both margins." More than four lines doesn't make sense, since this depends on your browser window size and display type. More than four sentences would make sense, since this is calculable by counting full stops and question marks. – Ilse@ 16:41, 26 June 2008 (UTC)
- Presumably what is intended is more than four lines of standard text (somewhere around 300 characters), but what do we want to say? Septentrionalis PMAnderson 02:11, 27 June 2008 (UTC)
- It's not well worded, is it. "(four or more lines, or a paragraph of any length)"? I suspect that the intention was not "five or more", which is the current indication; people often write "over 18 years old" to mean "at least 18 years old", and this may suffer from the same looseness. TONY (talk) 08:49, 27 June 2008 (UTC)
- The last time we talked about this, I was talking to myself, as I recall. I see 1.5- and 2-line block quotations in magazines all the time, though never in newspapers. I wouldn't mind a guideline that says something like this: "A general principle of layout is that a little white space is fine and a lot of white space is not. If there are blank lines nearby, then (repeat current guideline). If there are no blank lines nearby, then block quotations that are two lines or more in most browsers are fine, if you want to draw attention to the quotation." - Dan Dank55 (talk)(mistakes) 03:33, 30 June 2008 (UTC)
- It's not well worded, is it. "(four or more lines, or a paragraph of any length)"? I suspect that the intention was not "five or more", which is the current indication; people often write "over 18 years old" to mean "at least 18 years old", and this may suffer from the same looseness. TONY (talk) 08:49, 27 June 2008 (UTC)
No break dashes
Similar to how we use nbsp for say "22 miles", is there an nb-dash for "1992–present" so they appear on the same line? Matthewedwards (talk • contribs • email) 17:32, 26 June 2008 (UTC)
- A "prevent line-break" function? I doubt it. You're raising this because of frequent line-breaks of this type of expression in tables at FLC? I'm not surprised, but a solution may lie in getting tough on the management of column widths instead. PS, I think "22 miles" now doesn't need the hard-space. See Wikipedia:Manual_of_Style#Non-breaking_spaces, which was changed last month. TONY (talk) 08:52, 27 June 2008 (UTC)
- Partly for tables, but also for prose where the first year of a span is on one line and the second on another. Matthewedwards (talk • contribs • email) 20:08, 27 June 2008 (UTC)
If needed, there is {{nowrap}}. JIMp talk·cont 04:42, 30 June 2008 (UTC)
I've just come from the help desk after answering a question about infoboxes and nav boxes (you can see that here). Whilst I was able to find a MOS section on Info boxes, information about Nav boxes is rather limited and hard to find - it took several minutes of searching before I found the section Template:Navbox. Is there a guideline page about how and where to use such boxes as there is for the info box? If so, could you add the link to it to the MOS contents page? Also, could you please add to the information I gave at the Help Desk, as I fear that I may not have given enough information. Thanks! StephenBuxton (talk) 11:17, 28 June 2008 (UTC)
- I fear that there is not much to see here; both navboxes and succession boxes are relatively unregulated (with the former slightly better-off). The one basic guideline concerns the navboxes' position, and can be found here. You might also be interested in the comparative study of categories, lists, and navboxes. I don't think there is anything else about navboxes in the guidelines. Wait for a second opinion, though; I don't know the guidelines by heart. Waltham, The Duke of 10:50, 30 June 2008 (UTC)
k. d. lang
See Wikipedia talk:Manual of Style (capital letters)#Capitalisation. Whether or not to capitalize all proper nouns comes up from time to time. The current vote is 3-0 in favor of "k. d. lang" on the talk page. My understanding is that the only current exceptions to capitalizing a proper noun are for a few companies that have a trademark capitalizing the second letter, such as iPod. - Dan Dank55 (talk)(mistakes) 16:13, 28 June 2008 (UTC)
- My feeling is that kd is in the same boat as iPod, and that the exceptions should be widened. TONY (talk) 08:21, 29 June 2008 (UTC)
Names of articles in multiple languages and bolding in the lead section
Posted at Wikipedia talk:Manual of Style and Wikipedia talk:Lead section I have a question about bolding the name in the lead section of an article. At Kosovan Serb Assembly, I have put that name in bold as well as the two Serbian spellings of the name in its original language. Is this proper, or should only the English name be in bold? Please respond on my talk. —Justin (koavf)❤T☮C☺M☯ 00:21, 29 June 2008 (UTC)
Administrative divisions of a country
What are the procedures for referring to an administrative division of a country. Should we name the administrative division with a comma then the country or should we just put the name of the admministrative division? Is it Alabama, USA or just New York? Is it Alsace, France or just Alsace? Can you point me to whether there is a style guide for something like this? Pocopocopocopoco (talk) 03:41, 29 June 2008 (UTC)
- I believe that this is not as much a matter of style as it is a matter of context; if there is a strong national context in an article, then the country is usually redundant. And so on. This is mostly an editorial decision. That said, a certain consistency should exist within each article, as usual. Now, what could be regulated by the Manual of Style is something like this dilemma: [[Portland, Oregon]] versus [[Portland, Oregon|Portland]], [[Oregon]]. I don't think I've ever seen any relevant guideline, although the latter option seems to be preferred (so that the state may be included), and I've even seen a template creating it, {{city-state}}. Perhaps the existence of other, similar templates could indicate the trend for such cases; I shouldn't know. Maybe some one else here does. Waltham, The Duke of 04:00, 29 June 2008 (UTC)
- Yes, context, definitely, and hard to legislate on. But please, let's remember that we're not writing addresses on envelopes according to postal conventions: where a place is well-known to English-speakers, avoid the humdrum trotting out the ever larger concentric circles around a location. "Paris, France" is tedious. Alsace might need contextualising, though. TONY (talk) 08:20, 29 June 2008 (UTC)
- More to the point, unless there is some special reasion (a list of capitals, or being explicitly contrasted with Paris, Texas), it is redundant and unidiomatic.
- Yes, context, definitely, and hard to legislate on. But please, let's remember that we're not writing addresses on envelopes according to postal conventions: where a place is well-known to English-speakers, avoid the humdrum trotting out the ever larger concentric circles around a location. "Paris, France" is tedious. Alsace might need contextualising, though. TONY (talk) 08:20, 29 June 2008 (UTC)
- I find [[Portland, Oregon|Portland]], [[Oregon]] a useless tic; Portland, Oregon is the name of the article, and it links to Oregon if anybody wants to go there. Septentrionalis PMAnderson 21:57, 29 June 2008 (UTC)
Ambiguity regarding references to articles about people with initials in their name
I had inquired at Wikipedia:Village pump (policy)#Naming_.28and_referring_to.29_articles_about_people_with_initials_as_their_.22common.22_first_name as to a clarification about naming (and referring to) articles about people with initials in their name. The current Wikipedia convention is to use a full stop after each initial, correct? That seemed to be the consensus at the Pump, but it was suggested I bring it up here so the MOS can clarify the Wikipedia policy. Thoughts? — X96lee15 (talk) 02:10, 30 June 2008 (UTC)
- Yes. WP:NAME (or is it WP:Naming conventions (people)?) gives "H. G. Wells" as an example. And WP:NAME is policy; we grovel in its presence. - Dan Dank55 (talk)(mistakes) 02:58, 30 June 2008 (UTC)
- The simple problem is that we kneel before an example; there is no actual guideline regulating initials. Which is why we still have cases of unspaced initials. On the Village Pump discussion it has been mentioned that it is a matter of common usage whether to apply spaces or not between the initials; I consider it strictly a matter of punctuation, where house rules should apply. D.J. White is wrong because D.J. is not an acronym, and the cases where it should be allowed not to have spaces after full stops should be very limited indeed. Waltham, The Duke of 09:49, 30 June 2008 (UTC)
When one comes from two different countries, how do you spell it?
The politically correct term for describing people of mixed descent eludes me at the moment. In any case, I am unsure as to the precise hyphenation practices of compounds like African-American. I have not managed to find a relevant guideline in the Manual, and unless there is one which I have failed to locate, it seems to me that this is an omission which should be taken care of; especially considering that I have received intelligence according to which the articles concerning such terms are inconsistent in their spelling. Please advise. Waltham, The Duke of 10:26, 30 June 2008 (UTC)
- Hyphenation is customary; I am not surprised that the unfortunate manner in which WP:MOSDASH is used in reviews has led to hypercorrection. Septentrionalis PMAnderson 20:32, 30 June 2008 (UTC)
- Take a look at Hyphenated American Roger (talk) 12:42, 1 July 2008 (UTC)
- AP Stylebook and NYTM both use a hyphen in African-American, and I have never (until now) seen it with an en-dash. - Dan Dank55 (talk)(mistakes) 14:43, 1 July 2008 (UTC)
Straight and typographers quotes
- I’d like to propose a modification to MOS guideline. It makes sense to generally prefer straight quotes; for the reasons so stated on MOS. However, curly (typographers) quotes look much better than straight quotes; that’s why they’re also called “typographers’ quotes.” All professionally produced literature use them. I agree that they they should not routinely be used on Wikipedia, in large part because the Windows operating system makes it so cumbersome to employ them. Further, many volunteer editors to Wikipedia wouldn’t recognize the difference between an hyphen and an emdash so the wise thing to do is to just let them pound the ol’ " key. So it makes sense to permit the use of straight quotes on Wikipedia, especially in articles that are currently in a great state of flux (either revisions or expansion). So…
I would propose that MOS be updated with the additional caveat that when an article has reached a level of completeness and polish that it is undergoing little in the way of substantial rewrite or addition, that typographers’ quotes are permissible. This will keep Wikipedia easy to edit when articles are in a state of growth and flux, but will also put Wikipedia on the slow track towards looking more like a professional-grade publication. Greg L (talk) 02:20, 1 July 2008 (UTC)
- I'm not convinced readers would actually prefer that look, even though that's how the printed EB looks. Also, I would hope software could sort out the starting quotes from the end quotes, and if someone wants their quotes to look curly, perhaps they could install a .js script to make that happen. I'd rather not make it harder to edit. If we have anything like a "completed article" on Wikipedia, it's a Featured Article, and they get a lot of new edits, generally. - Dan Dank55 (talk)(mistakes) 14:35, 1 July 2008 (UTC)
Is a musical band referred to in the single or plural tense?
From Kaiser Chiefs discography: "Kaiser Chiefs are currently recording their third album". Is this correct, or should it be "Kaiser Chiefs is currently recording its third album". The band is one band, even though it is made up of more than one person, correct? Matthewedwards (talk • contribs • email) 07:17, 1 July 2008 (UTC)
- This probably depends on the articles choice of regional orthography. From the American and British English differences article;
- In BrE, collective nouns can take either singular (formal agreement) or plural (notional agreement) verb forms, according to whether the emphasis is, respectively, on the body as a whole or on the individual members whereas In AmE, collective nouns are usually singular in construction:Zebulin (talk) 07:47, 1 July 2008 (UTC)
Attempt to undermine MOS and Naming Conventions talk pages
On 25 June, Anderson raised some reason at the Naming conventions policy talk page for why the use of en dashes in article titles should be changed, without providing the folks there the proper context of the debate that has been closed here on this matter. A day and a half later, without a single comment on the matter by another editor, he launched in and changed the policy thus, in so doing introducing a conflict between the Naming conventions policy page and MOS, where before there was none.
These are underhand tactics that deserve to be rebutted, and SOON. The change introduces the possibility that an editor will argue that because some "reliable source" uses a hyphen in a compound item in a "page name", this is fine for WP's page names too, despite MOS's guidance on en dashes in both article titles and the main text. On a legalistic level, the new wording fails, because proof has to be shown of the use of a hyphen in a page name in that reliable source; what exactly are these "page names" in reliable sources? I though that was a particularly WPian term. Neverthess, Anderson's hasty change looks like an attempt to drive a wedge between two of WP's most important pages. We must not let this happen.
Now, I've reinstated the previous text, which just pointed to the section on dashes in MOS, pure and simple. I trust that Anderson is not going to reinforce his deception by bad behaviour in edit warring. He has to learn that, to start with, consensus is required on a talk page. TONY (talk) 15:00, 1 July 2008 (UTC)
- This is a lie; it passes the bounds of credible ignorance.
- In fact, I presented a proposal in full at that talk page, in this section, which includes a link to the discussion here; I stated that here, four days ago.
- On the substantive point at issue, this vast "stealth" change, alters
- For use of hyphens, dashes and hair spaces in page names, see Wikipedia:Manual of Style (dashes).
- to two lines:
- See also: Wikipedia:Manual of Style (dashes) and
- Use a hyphen or dash in a page name if reliable sources on the subject do.
- For use of hyphens, dashes and hair spaces in page names, see Wikipedia:Manual of Style (dashes).
- On the only substantive change here, the removal of hair spaces, Tony agrees with me; the remainder adopts the usual (although not invariable) format of WP:NC when referring to a guideline, and summarizes on the common basis of the long discussion of dashes here and of WP:NAME: usage, what the greatest number of English speakers would most easily recognize.
- In short, this is a tempest in a teapot. Septentrionalis PMAnderson 17:57, 1 July 2008 (UTC)
- No it's not, Anderson. It's called "deception". Worse, in fact, than your misleading edit summaries here, where you sneak in changes hoping no one will notice. No explanation ever on my last posting on that. Disappointed. TONY (talk) 18:03, 1 July 2008 (UTC)
- One of your latest edits says you are going to get some sleep; if you get eight hours you may see more clearly. Septentrionalis PMAnderson 18:09, 1 July 2008 (UTC)
- No it's not, Anderson. It's called "deception". Worse, in fact, than your misleading edit summaries here, where you sneak in changes hoping no one will notice. No explanation ever on my last posting on that. Disappointed. TONY (talk) 18:03, 1 July 2008 (UTC)