Wikipedia talk:Manual of Style

See also
Wikipedia talk:Writing better articles
Wikipedia talk:Article titles
Wikipedia talk:Quotations
Wikipedia talk:Manual of Style (dates and numbers)
Wikipedia talk:Manual of Style/quotation and punctuation

Contradiction regarding inline citations

This discussion has been transferred to Wikipedia talk:Footnotes as per #Warring editors on WP:FN

A historical vs. an historical

Is "an historical" an acceptable usage, or should we regard it as incorrect? The most comprehensive survey of the subject I found was this page, which finds that most American style guides consider the h in 'historical' to be a consonant and thus calls for an 'a'. That page also mentions that The Times style guide calls for 'an' before 'historic', although I note that in actual practice, Times writers use both about equally: a historic; an historic. The BBC seems to overwhelmingly favor "a historic" over "an historic": a historic; an historic. Furthermore, the Oxford English Dictionary, under its entry for historic gives "A historian. Obs." for definition B.1 and "ellipt. A historic work, picture, subject, etc." for definition B.2. So I don't think this is a case of Commonwealth vs. American English (unless you 'appen to be Cockney). Given that, may we formally state that "an historical" is an error in the MoS?--Father Goose (talk) 22:05, 3 March 2010 (UTC)

• An historical = fingernails on a blackboard. –Whitehorse1 22:09, 3 March 2010 (UTC)

It's my understanding that "an historic" was used in the U.S. for a long time, but now it's considered old-fashioned and unnecessary. The American Heritage Dictionary, however, says that "an" is "still acceptable in formal writing." According to the same source, though, Chicago and the AP Style Book prefer "a." My take on the matter is that if it's old fashioned but not incorrect then Wikipedia shouldn't ban it. Darkfrog24 (talk) 23:26, 3 March 2010 (UTC)

• Of course it's correct. They use it routinely at the BBC. Ohconfucius ^¡digame! 12:39, 6 March 2010 (UTC)
  • My understanding is that the usage is applied when the initial "h" sound is dropped ("an hour", and in the English of some regions in the UK, "an hotel", "an history"). Tony (talk) 13:34, 6 March 2010 (UTC)
    • It's my understanding that an accented initial "h" sound obviates the "n" on the indefinite article, while an unaccented initial "h" sound does not: "a history", "an historian", "an historical novel". If I see "a" in front of an h-word, it's unpronounceable unless I accent the first syllable, as in "a historian" ( ≥ fingernails on a blackboard, conservatively). --Pi zero (talk) 20:01, 6 March 2010 (UTC)

That's right. You say "an" if you don't pronounce the "h"; otherwise you shouldn't. British people tend not to pronounce the "h" if the first syllable isn't strssed, so they tend to say "an (h)istorical", for example. Americans who copy this (many do) are wrong if they pronounce the "h" at the beginning of a word with an unstressed syllable, which we usually do, causing the "chalkboard fingernails" reaction. Wikipedia shouldn't care, though because it's written, not spoken, and both ways are correct. Chrisrus (talk) 20:31, 6 March 2010 (UTC)

In the dialect of English I speak natively (and quite fluently, thank you), an unaccented initial h isn't altogether unpronounced (unless perhaps one is speaking rapidly), it's just too weak to obviate the n on the article. I could imagine awkwardly inserting a glottal stop between the n-less article and the unaccented initial h, but in my dialect that's the sort of thing that one would only resort to if artificially taught, like never ending a sentence with a preposition. I think I've heard it done, but it puts me in mind of over-corrected usages like "with Bill and I".

If there really are dialects of English in which it's natively incorrect to use n with unaccented initial h (rather than being artificially taught so), then it certainly isn't one of the relatively few linguistic differences that breaks somewhat neatly along nominal American/British lines. --Pi zero (talk) 03:47, 8 March 2010 (UTC)

FWIW, Google Scholar gives 1,820,000 hits for "a historical" and 1,100,000 for "an historical"; Google Books gives 36,500 for "a historical" and 30,500 for "an historical"; Google gives 9,750,000 for "A historical" -wikipedia -wiki (6,230,000 in the US, 612,000 in the UK) and 4,920,000 for "An historical" -wikipedia -wiki (2,200,000 in the US, 325,000 in the UK). ― A._di_M. (formerly Army1987) 15:30, 8 March 2010 (UTC)

In general I do not think Google is a good source for correct English. It is just as likely to report back common mistakes as common correct usage. ("It's" vs. "its," anyone?) However, I agree that Wikipedia should not ban "an historical" just because lots of us prefer the more modern form. Darkfrog24 (talk) 03:16, 9 March 2010 (UTC)

Here is a perfect example. —David Levy 03:27, 9 March 2010 (UTC)

...I don't get it. "Deserts" with one s like in "deserve" is the correct spelling (though I admit I got knocked for a loop for a minute there). There are twice as many hits for "just desserts" as "just deserts" but these include actual dessert web sites with play-on-words names. Darkfrog24 (talk) 04:00, 9 March 2010 (UTC)

Also it confuses Google with Google Scholar, which shows academic papers that are said to be more carefully edited. Even Google is often a good source compared to the most common alternative: "But X just isn't correct English!" "Yes it is!" "No it isn't!" "Yes it is!" ... Art LaPella (talk) 14:36, 9 March 2010 (UTC)

Ah, but the correctness approach has the virtue of allowing us to consult reputable style guides. We get "Chicago says so!" "But Cambridge doesn't!" more than we get "YII"/"NII," and we get "Chicago says so!" "So does Cambridge!" even more than that. Darkfrog24 (talk) 05:45, 10 March 2010 (UTC)

OK, does that mean we can settle the spaced dash debate, for instance, by simply listing style guides supporting each opinion, and debating which guides are more reputable? Art LaPella (talk) 06:36, 10 March 2010 (UTC)

They could certainly give it a try. It doesn't work all the time, but it's certainly better than arguing about which mistake is the most popular. Darkfrog24 (talk) 11:59, 10 March 2010 (UTC)

Which presumes that in the Manual of Style's subculture, "mistakes" are defined by style guides, not by God and not by the Emperor's new clothes. This talk page would be a lot shorter if there were a clearcut consensus on that point. Art LaPella (talk) 17:09, 10 March 2010 (UTC)

My point is that Google treats "just deserts" as a misspelling and suggests "just desserts" (the actual misspelling). —David Levy 15:58, 9 March 2010 (UTC)

Thank you, Levy. I see your point now. Darkfrog24 (talk) 05:45, 10 March 2010 (UTC)

If anything, that would show that it is "a historical" which is more likely to be a typo, since it has a larger relative frequency in the web than in scholar articles and in books, and it's the latter which are more likely to reflect what is actually normal in the writers' dialects. That said, frequencies within a factor of 2 of each other on both Google Scholar and Google Books seems clear evidence that both are much more common than can be dismissed as mistakes. ― A._di_M. (formerly Army1987) 15:14, 9 March 2010 (UTC)

I don't find that commonness alone can do it, but commonness isn't alone here. Safe to say we do not have sufficient grounds to ban "an historical"? Darkfrog24 (talk) 05:45, 10 March 2010 (UTC)

RfC: Disjunctive en dashes should be unspaced

At present, the Manual of Style includes the following:

Disjunctive en dashes are unspaced, except when there is a space within either one or both of the items (the New York – Sydney flight; the New Zealand – South Africa grand final; June 3, 1888 – August 18, 1940, but June–August 1940). Exceptions are occasionally made where the item involves a spaced surname (Seifert–van Kampen theorem).

I propose that this be replaced by:

Disjunctive en dashes are unspaced (Antiqua–Fraktur dispute, the New York–Sydney flight, 1776–1788, June 3, 1888–August 18, 1940, Seifert–van Kampen theorem, Gell-Mann–Nishijima formula).

We've had extensive discussion of this over the past year or so. The relevant discussions are:

• Wikipedia_talk:Manual_of_Style/Archive_108#Dash spacing in categories
• Wikipedia_talk:Manual_of_Style/Archive_109#Dash spacing question
• Wikipedia_talk:Manual_of_Style/Archive_110#Question for en-dash experts
• Wikipedia_talk:Manual_of_Style/Archive_112#Spaces in endash
• Wikipedia_talk:Manual_of_Style/Archive_113#Endash in tables: spacing

especially Archive 112's Spaces in endash. An older but relevant discussion is at Wikipedia_talk:Manual_of_Style/Archive_82. I summarize the arguments for unspaced disjunctive en dashes as follows:

• Unspaced disjunctive en dashes are preferred by many style guides, including APA, ACS, Oxford, CMOS, MHRA, Hart, EU Style Guide, and Bringhurst. Fewer style guides prefer spaced disjunctive en dashes.
• Unspaced disjunctive en dashes are used by many publishers, including Springer-Verlag, Elsevier, Informa, Oxford University Press, Cambridge University Press, Annual Reviews, and Nature Publishing Group. While publishers are inconsistent about spacing and the use of en dashes instead of hyphens, unspaced disjunctive en dashes are acceptable everywhere and preferred in certain disciplines (such as mathematics: Seifert–van Kampen theorem, not Seifert – van Kampen theorem).
• Spaced disjunctive en dashes can be confused with spaced interruptive en dashes: In They flew New York – Burbank – New York – Los Angeles had been the original plan, but bad weather forced them to reroute, it is unclear whether the original route was New York to Burbank to New York, or whether the original route was New York to Burbank. Put another way, it is unclear whether it is the second or the third en dash which is interruptive. This ambiguity is avoided with unspaced disjunctive en dashes.
• Sentences containing two or more disjunctive en dashes are more beautiful if all dashes are unspaced or all dashes are spaced. However, there is consensus that if the disjunctive en dash separates single word items (such as years without months or days), then the en dash should be unspaced. Therefore the only consistent and aesthetic rule is for all disjunctive en dashes to be unspaced.
• Tables whose items have disjunctive en dashes are more beautiful if all dashes are unspaced or all dashes are spaced. As in the previous bullet, spacing all en dashes is against consensus.

In Spaces in endash, we discussed at length the possibility of confusion. My conclusion was that there is no way to always avoid confusion: A determined editor can always construct a sentence that is impossible to parse. Bringhurst, I think, says it well:

A sentence such as The office will be closed 25 December – 3 January is a linguistic and typographic trap. When it stands all alone in a schedule or list, 25 December – 3 January will be clear, but in running prose it is better both editorially and typographically to omit the dash and insert an honest proposition: 25 December to 3 January.

Most ambiguous constructions are ambiguous whether the dashes are spaced or not. While we should discourage ambiguity, it is not a reason to prefer spaced to unspaced en dashes or vice versa except in the case I noted above. Bringhurst, in the paragraph immediately preceding the one I quoted, instructs us, Use close set en dashes or three-to-em dashes between digits to indicate a range and gives as examples 3–6 November, 4:30–5:00 pm, 25–30 mm. In this he agrees with the rule I have proposed above.

Our previous discussion was heated, so I would like to remind everyone to remain calm. I am confident that we can reach consensus this time. Ozob (talk) 05:15, 5 March 2010 (UTC)

• Support as author. Ozob (talk) 05:15, 5 March 2010 (UTC)

• Support. The current requirement for spaced endashes has never had real consensus. The requirement was put in without discussion, it wasn't noticed or enforced for quite some time, and when it began to be enforced in examples like "Seifert–van Kampen theorem" it became immediately clear that it was strongly opposed. The Manual of Style should suggest a style that agrees with that of high-quality academic publishers: it should not insist on a style that disagrees with these high-quality sources. Eubulides (talk) 05:53, 5 March 2010 (UTC)
• Support. This seems to me to be the most self-consistent, as well as the most consistent with the published literature. And it's also simpler to follow than what we seem to have been doing up to now, which is something more like "unspaced, except when the disjuncts contain spaces, except except when they are personal names or when it would be inconsistent with nearby disjuncts..." —David Eppstein (talk) 05:58, 5 March 2010 (UTC)
• Strong oppose. This is flogging a dead horse. For all of the reasons given in previous incarnations of this attempt to change the MoS, the status quo should remain as it has for nearly nearly three years—ever since the Manual properly treated hyphens and dashes. There are quite enough sources out there to support WP's mandating spaced en dashes when the items themselves contain one or more spaces. It is easy to remember, and is universally practised in the opening dates in our biographical articles, just to cite one example. Allowing the innermost elements to be squashed when editors just feel like doing it that way creates ambiguity and, frankly, ungainlines (3 November 1910–12 January 1913). It is not intuitive. "Disjunctive en dashes are acceptable everywhere"—that is simply untrue. And by analogy, the majority of house styles use Caps in Their Headings and Subheadings; WP's use of normal case in headings has never been questioned simply because some people use title case in hard copy and elsewhere on the Internet.

  Oh, and producing contortions to bolster a case won't go anywhere. Any editor will tell you that this is the way to write it: They flew New York – Burbank – New York; Los Angeles had been the original plan, but bad weather forced them to reroute.Tony (talk) 11:44, 5 March 2010 (UTC)

• Support. I notice that Tony correctly uses the unspaced em-dash for parenthetical phrases, but he cannot deny that the spaced en-dash is also used for this purpose in many English language texts. A reader coming along a spaced en-dash in English, without a solid knowledge of typography or the subject in question, would not know at the the first occurrence if the en-dash is disjunctive or parenthetical: such a reader would have to scan the rest of the sentence to make sense of a single word group, which is surely bad practice. We cannot enforce the unspaced em-dash for emphasized parenthetical phrases against the trends in the English language, and so we should allow the unspaced en-dash in disjunctive situations such as "Germany–South Korea relations" as opposed to "North Korea has diplomatic relations with Germany – South Korea relations are awaiting the signing of a peace treaty." Physchim62 (talk) 12:55, 5 March 2010 (UTC)

Tony often uses spaced en dashes as interrupters – having been persuaded by Noetica of their virtue – although he retains a slight preference for (unspaced) em dashes in that role. Again, a contortion has been invented to try to bolster a case. Dashes should not be used where they are at all likely to cause confusion or visual awkwardness: "North Korea has diplomatic relations with Germany; South Korea relations are awaiting the signing of a peace treaty." The "South Korea relations" bit desperately needs to be reworded, anyway. Tony (talk) 08:19, 8 March 2010 (UTC)

• Comment If this RFC is to have any weight, this discussion needs to be advertised more widely. En dashes are used in many articles, particularly in biographies (where I almost always see a spaced en dash between the dates of birth and death), and in FAs/FLs, where compliance for the MOS is a criterion for promotion. Dabomb87 (talk) 13:44, 5 March 2010 (UTC)
  • I just now put in a note at the village pump. Other suggestions for places to advertise are welcome. Eubulides (talk) 16:58, 5 March 2010 (UTC)
    • Template:Cent, WT:FLC also come to mind. Dabomb87 (talk) 00:06, 6 March 2010 (UTC)
      • You see it in biographies because that was specified in WP:DATE, not for any other reason. That was a specific usage in addition to the rule under discussion here. It should be changed, too. Gene Nygaard (talk) 16:55, 6 March 2010 (UTC)
• Weak support; the proposed alternative is superior, but I would prefer a guideline which permitted articles to use either method consistently. Christopher Parham (talk) 13:52, 5 March 2010 (UTC)
• Support, but I don't think ranges should be included in disjunctive dashes. For example, the EU style guide recommends unspaced disjunctive dashes (§2.19), but draws a distinction for ranges (§3.15), and I'm nearly sure I've seen the same usage before outside Wikipedia. I'd also support a proposal such as Christopher Parham's, so that it doesn't cause existing articles to stop conforming. ― A._di_M. (formerly Army1987) 15:47, 5 March 2010 (UTC)
• Support per nom.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 5, 2010; 17:22 (UTC)
• Support, in general. I've never really seen any satisfactory explaination why "Chicago–New York flight" should be punctuated any differently than, say, "Chicago–Philadelphia flight". They are equivalent constructs and should be punctuated the same way. I also don't particularly think there's a potential for confusion on date ranges, as the reader would have to ignore the context of the complete sentence, and I don't believe that constitutes a compelling reason to use spaces. That said, I can see making an exception for (non-year-only) date ranges, purely as a practical matter, due to the prevalance of the existing spacing in biographical articles. oknazevad (talk) 21:17, 5 March 2010 (UTC)
• Oppose per Jimbo's "we make the internet not suck" -- in my opinion this change will cause more harm than good and will contribute to the internet "sucking". keep the status quo and stop changing all the articles in advance of this decision. User:Pedant (talk) 00:25, 6 March 2010 (UTC)

  Why do you believe that this change will cause more harm than good? Ozob (talk) 17:32, 6 March 2010 (UTC)

  Right, why? ― A._di_M. (formerly Army1987) 20:22, 6 March 2010 (UTC)

• Weak oppose. I don't feel very strongly about it, and there are aspects of the current MOSDASH that I'm not crazy about, but it's consistent, it works, and I don't think this is an improvement. Visually I think there's a reasonable case to be made that "Los Angeles – Chicago" is intuitive to a reader. Unless we can argue that "Los Angeles–Chicago" is actually better, and not just equally good, I see no reason to change the status quo. The change would have a very broad impact and would absorb a lot of resources and needs to be well justified to succeed. The arguments presented don't convince me we have a problem that needs to be addressed. As a couple of people say above, sentences can be constructed to show the weaknesses in any system. If I could be convinced that a problem exists that needs correction I would change my vote, but the case seems to be one of stylistic preference, without an independently convincing reason to change our house style. Mike Christie (talk) 00:27, 6 March 2010 (UTC)
• Oppose I could see an exception maybe being made for individual articles that overwhelmingly use unspaced en dashes in their names, but on the whole I don't see a real good reason to change what has been a relatively stable guideline. I've made changes to articles with regard to this section of MOSDASH; several editors have inquired about this change and have usually agreed that it makes sense to space the dashes. Dabomb87 (talk) 00:36, 6 March 2010 (UTC)

  Could you explain why you believe that it makes sense to space the dashes? I'm not aware of any good reasons to do so. Ozob (talk) 15:54, 7 March 2010 (UTC)

• Oppose This proposal violates Technical Writing 101: Thou shalt not cause needless confusion for the intended readership—not even for a second. The parenthetical exception in the current guideline, (the New York – Sydney flight; the New Zealand – South Africa grand final), has long served us quite well and is sorely needed so readers’ minds don’t suffer a two-second-long *!?!*-interrupt and their eyes have to rescan to properly understand the construct. This construction is particularly confusing: 31 December 1910–11 January 1972 since it makes it exceedingly easy for many readers’ eyes to think it is a one-year range until their eyes stumble and trip over the rest of the construct. Fine typography and punctuation practices are all about allowing the eye to flow as quickly as possible without interruption. Such attention to detail is a small part of Jimbo’s “We make the Internet not suck.” Greg L (talk) 00:43, 6 March 2010 (UTC)

  I agree that it's possible to create confusing constructions, but I don't think that spacing those en dashes is any less confusing: If all en dashes are spaced, then 31 December 1910 – 11 January 1972 has the same problem! Inside parentheses or in an infobox, I don't think an unspaced en dash is confusing. In prose, I think the right solution is to say from 31 December 1910 to 11 January 1972. As Bringhurst says, anything else is a trap. Ozob (talk) 18:00, 6 March 2010 (UTC)

  Sometimes spaced dashes are confusing, because they look like interruptive ones. To minimize confusion, the guideline should say "The spacing should be decided on a case-by-case basis", give some examples in which an unspaced dash is used because it'd be confusing if spaced, an example of the converse, and suggest to use prepositions when both ways would look bad. ― A._di_M. (formerly Army1987) 20:22, 6 March 2010 (UTC)

• Oppose. Keep the current wording! There's no need to introduce awkward connections such as "New Jersey–London flight" (is it a new flight from Jersey to London?) and "13 December 1913–14 February 1950" (is the 1913–14 supposed to indicate a two-year period from 1913 to 1914?) Ugly stuff. Binksternet (talk) 01:14, 6 March 2010 (UTC)

  It only removes the ambiguity if the reader knows this convention, and I think it is rare enough that most readers won't. ― A._di_M. (formerly Army1987) 20:22, 6 March 2010 (UTC)

• Oppose: I've nothing to add to what Mike Christie and others say above, and fully endorse their reasoning. Brianboulton (talk) 01:19, 6 March 2010 (UTC)
• Permit both. There are reasonable arguments for both spaced and nonspaced disjunctive dashes; I see no reason why Wikipedia should impose either on its editors. Ucucha 01:36, 6 March 2010 (UTC)
  • Me too. —Tamfang (talk) 00:14, 8 March 2010 (UTC)
• Oppose: Such a sweeping change should require a compelling reason. Hawkeye7 (talk) 01:40, 6 March 2010 (UTC)

  Why do you believe the reasons I provided above are uncompelling? I think the simplicity and consistency of my proposal is alone a strong recommendation. There are also the recommendations of many style guides and common publishing practice in my favor. The argument for keeping the current guideline seems very weak to me; is it simply inertia? Ozob (talk) 15:57, 7 March 2010 (UTC)

• Support. As noted the current wording was made essentially in the "dead of night" with little or no discussion. It was pretty much unnoticed at the time and didn't become an issue until unwise attempts were made to enforce it in places where it is clearly not applicable. (The prominent examples were scientific usage.) The spaced endash usage doesn't conform to majority practice outside of Wikipedia and it is absolutely unacceptable in some contexts, a problem that unspaced endashes don't have in any context. The proposed instruction is also simpler than what the MOS has currently. Arguments that the sky will fall if Wikipedia conforms to majority usage in this case are unconvincing. Quale (talk) 04:21, 6 March 2010 (UTC)
• Oppose: The sooner this RfC is snowed under, the less time it will ultimately waste. WFCforLife (talk) 06:22, 6 March 2010 (UTC)

  What are your objections to the proposal? Ozob (talk) 16:01, 7 March 2010 (UTC)

• Strong support: Almost all major style guides recommend unspaced en-dashes. CRGreathouse (t | c) 07:20, 6 March 2010 (UTC)
• Oppose because I am very unhappy with both options. The present version is bad because it is inconsistent with traditional typography in many cases and sometimes just doesn't look right. The proposed new version is bad for the reasons given by Greg L. In my opinion the switch from one bad rule to another bad rule is the worst possible outcome. Hans Adler 08:07, 6 March 2010 (UTC)

  What would you propose, instead? ― A._di_M. (formerly Army1987) 20:22, 6 March 2010 (UTC)

  Good question. Unfortunately I can't think of a better solution. If we give it free altogether there will be too much inconsistency, especially in article titles. There are situations where it's confusing to space, and others where it's confusing not to space. This doesn't have much to do with questions such as whether the dash is disjunctive or signifies a range or whatever, although it's probably statistically related. Any simple rule will produce confusing results in some instances. A very clever simple rule could minimise the confusing instances, but it would take a lot of research to find such a rule. Hans Adler 15:08, 9 March 2010 (UTC)

• Support: The new version seems to be preferable in general, but I did spend an extra second or two trying to parse "June 3, 1888–August 18, 1940". On the other hand the new rule has the advantage of simplicity, whereas the existing rule has the exception clause and exceptions to the exceptions. To me it seems to be better to have a rule that is easy to understand and follow than one that tries to specify what to do in every exceptional case. For the "June 3, 1888–August 18, 1940" example, my advice would be to rewrite it as "1888–1940" and avoid the whole issue.--RDBury (talk) 08:10, 6 March 2010 (UTC)

I just realized that the date range example would be used in many biography articles so maybe rephrasing it isn't an option. Maybe adding a common sense exception for cases like this would be best.--RDBury (talk) 08:18, 6 March 2010 (UTC)

There is an elegant solution for avoiding this particular issue entirely. Compare:

Albert Einstein ([...] 14 March 1879–18 April 1955) [1]

Albert Einstein (* 14. März 1879 in Ulm, Deutschland; † 18. April 1955 in Princeton, USA) [2]

Hans Adler 09:28, 6 March 2010 (UTC)

Using a cross to signify death (of a Jew, no less) is about as inelegant as it gets. Powers ^T 14:38, 6 March 2010 (UTC)

*blush* Excellent point. I think I was once aware of that problem, but now I simply forgot, and Einstein was simply the first person who came to my mind for an example. So we would probably have to find a different symbol, and the fact that the German Wikipedia is still using † suggests that that's a hard problem. :( Hans Adler 17:41, 6 March 2010 (UTC)

• I'm sure Hans didn't mean to be insensitive! The real problem is that using an asterisk for birth and a dagger (not a Christian cross) for death is well recognized by German speakers, but almost unknown among English speakers (unless those English speaker happen to speak German as well). English Wikipedia simply could not adopt the German system, however handy it might be. Physchim62 (talk) 18:57, 6 March 2010 (UTC)

I agree. Are birthdays so important to be in the first sentence? Couldn't one just write "Albert Einstein (1879–1955)"? The full dates are shown in the infobox, as well as in the "Early life and education" and "Death" sections respectively. An exception when the day of the year is somehow significant (e.g. 17 March for St Patrick can be made, but that's going to be very rare. ― A._di_M. (formerly Army1987) 20:22, 6 March 2010 (UTC)

Well, not all biographical articles have such sections, let alone an infobox. —Tamfang (talk) 00:14, 8 March 2010 (UTC)

• Oppose per WP:RETAIN. It's nice to know that the dashes have been written about and that there are various schools which do things the same or differently. I don't think that should be the issue. The biggest issue to my mind is ensuring consistency. The guideline has remained stable for a very long time, and the 'problems' elaborated above (and I'm not sure they are all problems anyway) do not seem to me to be good enough reason to break with WP:RETAIN. Ohconfucius ^¡digame! 08:55, 6 March 2010 (UTC)

  Allowing both formats, as some have suggested, wouldn't "break" any existing article. ― A._di_M. (formerly Army1987) 20:22, 6 March 2010 (UTC)

• Alternative The proposal is illogical. The purpose of putting a dash in in the first place is to tie words together. Therefore they are closer together than they are to other words. I suggest rephrasing wherever possible to avoid having dashes at all. Peter jackson (talk) 11:47, 6 March 2010 (UTC)
• Support a change (as the originator of this entire debate several moons ago). The revised wording at least agrees with the conventions of nearly every major style manual, including the Oxford Manual of Style, the Chicago Manual of Style, the APA Style Guide, the American Chemical Society style manual, and New Hart's Rules. Our own manual of style should not include mandates that are absolutely at odds with the best practices of major style manuals and publication houses. However, I would be eager to see one of the older proposals resurrected from Wikipedia talk:Manual of Style/Archive 112#Spaces in endash which at least allows for some editorial judgment in deciding what alternative to use. As Hans has noted, in many cases the style mandated by the present version just doesn't look right. If I had to formulate a hard rule about it, I would say that disjunctive en dashes are always unspaced, except in the case of parenthetical date ranges. Sławomir Biały (talk) 12:23, 6 March 2010 (UTC)
• Oppose. No compelling need to change; the current methodology makes context clear and reduces confusion greatly. Powers ^T 14:38, 6 March 2010 (UTC)
• Strong Oppose. One example for rationale would be I know which of 29 December 1918–19 January 1920 vs 29 December 1918 – 19 January 1920 reads through clearer first time. Anybody else think this is becoming a bit perennial? Rambo's Revenge (talk) 17:11, 6 March 2010 (UTC)

  I hope this isn't becoming perennial. To my knowledge this is only the second time that this has been put forward, and the first time, in the thread Spaces in endash I referenced above, I don't think we got a wide enough discussion. We are finally having that now, thank goodness!

  Regarding the date, I disagree with you. But you knew that. Ozob (talk) 16:04, 7 March 2010 (UTC)

• Strongly support. The "Seifert–van Kampen theorem" example is especially compelling, as well as the need for a zillion more redirects at Seifert - van Kampen theorem and Seifert – van Kampen theorem, Seifert-van Kampen theorem, Seifert–van Kampen theorem, and Seifert – van Kampen theorem. There is an article at Seifert–van Kampen theorem, and the redirect called for in our existing rules (I think it is found at one of the naming conventions pages) at Seifert-van Kampen theorem already exists. For that matter, there should not be redlinks at Seifert-Van Kampen theorem and Seifert–Van Kampen theorem nor the ones with "Theorem" such as Seifert–van Kampen Theorem (I'm not going to list all the permutations here). Furthermore, the extra spaces are ugly and unnecessary in all cases. The dates examples in existing articles discussed above are in general not from the rule under discussion here, but from a more specific instruction at WP:DATE. The problem that there should be a non-breaking space at the left side of a spaced en dash (something already prescribed at the Manual of Style page, at least twice), but there in general will not be (WP:DATE specified that "En dashes are preceded by a non-breaking space per WP:DASH" but that is rarely found in those introductory dates in biographies now), is another complication we don't need. Gene Nygaard (talk) 17:21, 6 March 2010 (UTC)

I had too many redlinks originally, but the Seifert - van Kampen theorem one is especially important. People will see that the hyphen/dash/whatever is spaced, but they won't necessarily know which of all the possibilities it is, and the one they have on their keyboard is "-"; don't expect anybody to know how to enter any other specific dash into the "Go" box, for example. If there hadn't been page moves in the Seifert-Van Kampen theorem article, most of those redirects would not exist now. For most similar articles, it is likely there will be a lot more redlinks. Gene Nygaard (talk) 17:29, 6 March 2010 (UTC)

• Oppose in regard dates, generally support in other cases (extending spaced surnames to spaced proper names). One bizarre example involved the relationship between concepts A–B and C–D; a sensible approach would be to call it the "A-B – C–D relationship". — Arthur Rubin (talk) 18:03, 6 March 2010 (UTC)

• You'd try to avoid using the range dash in any such construction. A–B to C–D. Tony (talk) 03:22, 7 March 2010 (UTC)

• Oppose. When and why did they replace the old York–Sydney flight with a new one? Strad (talk) 20:23, 6 March 2010 (UTC)
• Comment Both spaced and unspaced dashes can cause ambiguity and confusion on occasion. I think writers should be encouraged to use the word to or to recast the phrase when this is an issue. I think 29 December 1918 to 19 January 1920 is clearer than either 29 December 1918–19 January 1920 or 29 December 1918 – 19 January 1920. Michael Glass (talk) 21:44, 6 March 2010 (UTC)
• Oppose – Neither solution is perfect, but I believe the current guidance is better, especially for ranges and routes. In any case, I prefer unspaced em-dashes for interruption. If more people used them, a great part of the problem would disappear. Waltham, The Duke of 22:58, 6 March 2010 (UTC)
• Oppose. Thank you, Ozob, for providing links to some previous discussions about this issue. I wish to encourage all participants in this discussion to spend time in reviewing those discussions before commenting in this one.

From the section Wikipedia_talk:Manual_of_Style/Archive_112#Spaces in endash (subsection Wikipedia talk:Manual of Style/Archive 112#Too hasty, started by User:HWV258), I repeat the following information e-mailed by User:Noetica to User:Tony1, who "edited [it] for wikiformatting" and who posted it at 06:17, 19 December 2009 (UTC).

[Reformatted by Ozob (talk) 03:17, 8 March 2010 (UTC)]

These sources may be of some value:

A) Butcher's Copy-editing (4th edition 2006). This classic work is one of the most respected British guides. See the relevant page online (pp. 151–53). My commentary follows, drawing on salient points:

1. Spaced en dashes (as opposed to spaced or unspaced em dashes) are now "most often used" for so-called parenthetical dashes.
2. En dashes are also quite properly used to mean "and" or "to", in which case they are normally unspaced.
3. On p. 152: "However, spaced en rules [en dashes] may be used between groups of numbers and words to avoid implying a closer relationship between the words or numbers next to the en rule than between each of these and the rest of its group." Three quite decisive examples follow, along with a caution that in no way detracts from the basic principle. A search for "en rule" in this work at Googlebooks confirms its robustness. See for example p. 131 and p. 246, where both the principle and the obvious caution are reiterated.

B) The Cambridge guide to English usage (Pam Peters, 2004). On p. 140: "A spaced en dash/rule is used when the words or numbers to be separated have internal spaces.

1 July 1991 – 2 June 1992"

This is essentially the same provisions as in source A (along with additional ones of interest), but more prescriptive. And there is NO restriction to dates; and there is NO provision for any alternative practice.

C) Texas State University's editorial style guide link. This is one of several academic sources online that prefer the general style given in sources above, though perhaps implicitly: "The event runs October 10–15. 6 a.m. – 9 a.m. (include a space before and after the hyphen or en dash in ranges of times)." This is one of several American sources in accord with the other sources cited.

D) The Cambridge guide to Australian English usage (Pam Peters, 2nd edition 2007). See pp. 155–56: Same wording as in source B.

E) Style manual: for authors, editors and printers (Wiley, 6th edition 2006). Probably the major Australian style guide; widely followed, especially by government publications: essentially the same ruling as above. For its prominence in Australia see Style_manual#Australia.

F) The Australian editing handbook (Elizabeth Flann and Beryl Hill, 2004). Same ruling as in source E and others.

There are others that I can't chase right now!

Finally, a nice example of practice from "established publishers". Spot the four ways of doing date ranges, in one table.}}

From the same section Wikipedia_talk:Manual_of_Style/Archive_112#Spaces in endash (subsection Wikipedia talk:Manual of Style/Archive 112#Butcher's advice, started by User:A. di M.), I quote the following boldface text from a post by Noetica at 12:02, 21 December 2009 (UTC).

[Original boldface removed by Ozob (talk) 03:17, 8 March 2010 (UTC)]

Wikipedia is unique. It confronts weighty problems of pan-anglophone, collaborative, dynamic online publishing that never intrude on the serene world of academic journals. The web is not paper, and very few Wikipedia contributors are professional editors; very many are not even experienced writers. No appeal to New Hart's, Chicago, Butcher's, or Elsevier practice is final. We have to fashion guidelines ourselves, for an entirely new situation. We must respect precedents, yes; but many precedents are vague, rashly conceived, or scarcely applicable in new contexts. We at MOS must above all respect the special needs of Wikipedia editors, if we are ultimately to serve the readership. That means no hasty or half-considered changes, which yield nothing but chaos and dismay.

Please see also the surrounding context.

I am repeating information in response to what appears to be a repeated proposal. -- Wavelength (talk) 01:07, 7 March 2010 (UTC)

• It's not a repeated proposal, and the previous duplication and highlighting of a large chunk of one side of the already-cited discussion is an abuse of this discussion thread. There are far more authoritative style guides who favor unspaced endashes (APA, ACS, Oxford, CMOS, MHRA, Hart, EU Style Guide, and Bringhurst) than who favor spaced ones (Australian, mostly). The boldfaced claim that "Wikipedia is unique" is pure hot air: this minor layout issue is completely independent of whether material is printed or on the web. Eubulides (talk) 01:27, 7 March 2010 (UTC)

• The convict stain, is it? Tony (talk) 01:35, 7 March 2010 (UTC)

• No, I'd rather WP:AGF. If this whole debate comes down to Australian English vs. the rest of the world, and I didn't say it does, then population would be important. Art LaPella (talk) 02:57, 7 March 2010 (UTC)

• Regarding "...is completely independent of whether material is printed or on the web": remember that printed pages can't be resized. The fact that the width of the WP reader's screen can't be anticipated must be considered when constructing these guidelines.  HWV258.  06:18, 7 March 2010 (UTC)

I do not think that spacing of en dashes depends at all on whether we are in print or in electrons. This aspect of good design is independent of medium. If you do not think so, please explain why. Myself, I think it is as justifiable as the sometimes-made claim that electronic publications should always use hyphens; that is, I think it is ridiculous, and I know from experience that everyone who frequents the MoS agrees. But somehow, it's acceptable to vaguely invoke the differences between the web and print if it can be insinuated that these differences support one's side!

Also, the colored quote box was obnoxious enough the first time. I am about to remove it and the needless boldface. Ozob (talk) 03:15, 8 March 2010 (UTC)

Obnoxious because it disagrees with your line, possibly? Tony (talk) 04:14, 8 March 2010 (UTC)

Obnoxious because it distracts. Notice that discussion here has nearly stopped since it appeared. I am hoping that the discussion revives now that the quote box is gone. Ozob (talk) 11:38, 8 March 2010 (UTC)

I'm not sure I'd count sources B) and D) as two; anyway, the context shown is insufficient to show whether what it says is supposed to apply only to ranges or also to pairs of nouns modifying another noun. ― A._di_M. (formerly Army1987) 13:37, 8 March 2010 (UTC)

Eubulides, I repeated those two blocks of information as a convenience to readers. Even if I had simply referred to specific places in previous subdiscussions, there is a possibility that some people would have had difficulty in locating the passages in such a long, sprawling discussion.

Google found 40 pages with the exact wording "Wikipedia is unique". One of those pages is http://strategy.wikimedia.org/wiki/Wikimedia_Foundation/Feb_2010_Letter_to_the_Board_v1/en. Another one is http://www.guardian.co.uk/commentisfree/2008/jun/22/wikipedia.internet. You can follow the links that Google found, for you to see some ways in which Wikipedia is said to be unique.

Please do not refer to Noetica's words as "pure hot air". Please have more respect for experts. As one Wikipedian has said, "we can ill afford to lose such a resource."

-- Wavelength (talk) 21:00, 8 March 2010 (UTC)

It was completely inappropriate to copy that long slug of anti-change argument here. I could have responded in kind by copying an even long slug of pro-change argument, but that would have been just as bad. People who want to read the old arguments can do so, and you can refer them to the arguments, but it's wrong to blast a long copy of the stuff here. I'm afraid that even experts sometimes give opinions that are pure hot air: all that comment was saying, basically, is that Noetica likes spaces around en dashes and doesn't care that most style guides disagree. Eubulides (talk) 21:22, 8 March 2010 (UTC)

• Oppose. As per others. Something like 29 December 1918–19 January 1920 looks ridiculous.  HWV258.  05:12, 7 March 2010 (UTC)
• Oppose. I don't have much to add that Tony and others haven't already written, but this change would create confusing in some cases and eliminate confusion in no cases. Net negative for the reader. --Andy Walsh (talk) 05:10, 8 March 2010 (UTC)

RfC: Disjunctive en dashes should be unspaced: Another proposal

Apparently, most people objecting object to 29 December 1918–19 January 1920, so, what about this (loosely based on Butcher's):

Spacing

Disjunctive en dashes are normally unspaced; but when there is a space within one or both of the items being separated, they may be spaced or unspaced, depending on which format is clearer: unspaced dashes can be unclear because they can seem to imply a relationship only between the words immediately adjacent to it, and spaced dashes can be unclear because they can confused with en dashes used in lieu of em dashes (see below). (For example, if the spaces in 500– 20 thousand are removed, it can appear to mean "from 500,000 down to 20,000", and if spaces are added in They flew New York–Burbank – New York–Los Angeles had been the original plan, but bad weather forced them to reroute, the sentence becomes ambiguous.) If neither format is satisfactory, use a preposition instead. Unspaced dashes are normally preferred with proper names (Seifert–van Kampen theorem), and spaced ones with ranges (29 December 1918– 19 January 1920). In article titles, whichever format is chosen, create a redirect from the corresponding title with the other format.

(I'd welcome any suggestions for better examples.)

• Support as proposer. ― A._di_M. (formerly Army1987) 13:37, 8 March 2010 (UTC)
• Oppose again. What, after everyone has visited, you put up another proposal? How long will it go on for? I'm afraid you've missed the bus on this one: people have clearly indicated above that there is no consensus for change. It is not appropriate to advertise an RfC and then—after many many visitors have had their say—to change the text or to add other options. Waiting to see whether one option gains consensus, then moving the goal posts when you find it doesn't gain support will not lead to a legitimate consensus for change. Otherwise, you could keep adding new options every week, and people would tire of it all, and you could claim that this small hard-core of supporters then generates a consensus.

  Now, if you want to remove any doubt, it would be better to say simply that en dashes as interrupters should not be used in the vicinity of disjunctive en dashes: it's that simple; but that is what any good editor would do instinctively, anyway. I've already pointed out above that those who are pushing for this change have invented contortions involving proximate en dashes in these two different roles. Each time, I have responded by replacing the interrupter with a semicolon; that is the superior choice. Tony (talk) 14:11, 8 March 2010 (UTC)

  I can't see what's so shocking with making a proposal which tries to address the criticism to the previous one; I have not even edited the existing one. And IMO writing "Chicago–Boston" and "Chicago–Los Angeles" in the same sentence is confusing even if there's no interruptive dash around, as the reader will wonder what the difference between the two is and I'd bet that less than 5% of them will be able to come up with the answer. ― A._di_M. (formerly Army1987) 15:19, 8 March 2010 (UTC)

  Tony, I can see that you are happy with the current text and would therefore like to close down further debate. But there is no consensus for the present text. Look above: There are currently thirteen variations on "support" and nineteen variations on "oppose". That is, about 40% of those who have expressed an opinion support the proposal, and about 60% do not, and furthermore some of those are weakly held opinions. That is a supermajority, not consensus. If you do not want to participate in forming a new consensus, then please leave the rest of us alone so that we can do so uninterrupted. Ozob (talk) 22:47, 8 March 2010 (UTC)

Agreed with A. di M. and Ozob. A new proposal is a valid and potentially productive step, not an end run. Darkfrog24 (talk) 03:11, 9 March 2010 (UTC)

• Oppose. We can avoid ambiguity by writing 500–20,000 or 500,000 down to 20,000, as the case may be. The flight example appears to have been artificially contrived. No dashes are needed in They flew from New York to Burbank; flying from New York to Los Angeles had been the original plan, but bad weather forced them to reroute, and there is no ambiguity. -- Wavelength (talk) 21:16, 8 March 2010 (UTC)

It appears that a spaced en dash is used by professonal mathematicians. See the following variations of the name of the theorem.

"Seifert – Van Kampen theorem" at http://maths.dur.ac.uk/~dma0vk/OldTeaching/TopologyIII/TopologyIII-Spring08/notes32.pdf (Durham University)

"Seifert — Van Kampen theorem" at Lee J.M. — Introduction to Topological Manifolds :: Электронная библиотека попечительского совета мехмата МГУ (Lomonosov Moscow State University)

"Seifert and Van Kampen theorem" at Knill: The Seifert and Van Kampen theorem via regular covering spaces. (Pacific Journal of Mathematics)

"Seifert–Van Kampen theorem" at http://www.mathi.uni-heidelberg.de/~stix/preprints/STIXSvK.Juli2005.pdf (University of Heidelberg)

"Seifert van Kampen Theorem" at C3.1a Topology and Groups | Mathematical Institute - University of Oxford (University of Oxford)

"Seifert/Van Kampen theorem" at http://math.mit.edu/~gracelyo/18904/projects.pdf (Massachusetts Institute of Technology)

"Seifert–van Kampen Theorem" at http://www.pdmi.ras.ru/~olegviro/topoman/e-ch9.pdf (St.Petersburg Department of V.A.Steklov Institute of Mathematics of the Russian Academy of Sciences)

"Seifert Van Kampen Theorem" at http://www.renyi.hu/~dezso/budsem/04spring/top1_04s.html (Hungarian Academy of Sciences)

"Seifert and Van Kampen Theorem" at http://elib.tu-darmstadt.de/tocs/186717830.pdf (Darmstadt University of Technology)

-- Wavelength (talk) 16:42, 10 March 2010 (UTC)

Nobody is saying that the spaced version is never used outside Wikipedia. All we're saying is that it's standard practice among high-quality published sources to use unspaced endash. The two examples you give of spaced endash are low quality (one guy's old lecture notes; and a web index in English prepared by a Russian publisher for a Russian book!). I can easily find similarly low quality sources for other incorrect spellings, such as "Seifert van-Kampen theorem"[3]. But low-quality sources like these prove nothing. Let's see what high-quality publishers do: publishers like Springer (Akhmedov & Park 2008, doi:10.1007/s00222-008-0118-x; Pawałowski 2008, doi:10.1007/s00208-008-0215-6) and Oxford (Hackstein 2008, doi:10.1093/imrn/rnn050; Akhmedov et al. 2008, doi:10.1112/jtopol/jtn004) are doing. And sure enough, they use unspaced endash. Wikipedia should be inspired by the best professional English-language publications in the field, not by unrefereed amateurs and weird indexes by foreign-language publishers. Eubulides (talk) 20:42, 10 March 2010 (UTC)

Suddenly there is pontificating on which book or publisher is of high quality, and which is of low. Plenty of so-called high-quality publications persist with title case in their titles and subtitles: that doesn't mean WP should suddenly adopt this practice. Tony (talk) 23:39, 10 March 2010 (UTC)

Some high-quality publishers use sentence case in titles, some title case; but none of them use spaced endash for this example. And nobody would seriously argue that Oxford and Springer are lower-quality academic publishers than unreviewed course notes or a hacked-up web-only index to a Russian-published Russian book. Eubulides (talk) 05:26, 11 March 2010 (UTC)

I agree that it is a weak feature of the current rule that it is out of sync with what seems to be a reasonably consistent standard for this theorem; and perhaps there are other examples from mathematics that could be cited. However, the original proposal would make too global a change. I might be persuaded that it would be a good idea to add exceptions for specific terms with established usage, or even for entire fields such as mathematics, if customary usage can be established to be different from our current rule. That would require a different discussion than this, and more evidence for multiple examples (not just this one theorem). Mike Christie (talk) 12:23, 11 March 2010 (UTC)

• Defer. This is a reasonable compromise proposal. There's nothing wrong with proposing a compromise. There is obviously no consensus for the current MoS, and there never has been a real consensus for it: a compromise like this is obviously appropriate for cases where consensus hasn't been reached. However, I agree that the previous RfC should be left to pass its course before starting on a compromise. Eubulides (talk) 21:22, 8 March 2010 (UTC)
• Comment. Contra Tony, the existing "consensus" seems not to be a consensus (it attracted far less discussion when it was inserted than these proposals had) and, on top of that, is clearly broken ("Seifert – van Kampen" is just incorrect, it is not formatted that way by any professional mathematician, and the rule needs weird exceptions to allow the standard formatting "Seifert–van Kampen"). But I am coming to feel that replacing Tony's beloved but broken rule by a different rule is not so much of an improvement. I am in very strong opposition to a situation that leaves the status quo ante as a rule, because it is broken. But this repeated proposal-rejection cycle doesn't seem to be making any progress towards making it less broken. —David Eppstein (talk) 21:41, 8 March 2010 (UTC)
• Oppose. This proposal is too ambiguous to be an effective guideline: Ambiguity leads to arguments; arguments lead to edit wars; edit wars lead to the Dark Side. The instructions of both the present text and my proposal above are unmistakable, and I think that virtue makes either of them more desirable (despite my disagreement with the present text's instructions). Ozob (talk) 22:43, 8 March 2010 (UTC)

  I wonder how comes that we manage to have no guideline about whether to use someone or somebody and the sky hasn't fallen. (No, that's not a purely rhetorical question. Why are some people care so much to some points of style but not to others?) ― A._di_M. (formerly Army1987) 15:35, 9 March 2010 (UTC)

• Comment: I think this proposal accurately explains a problem with the current verbiage, and balances two fundamentally incompatible usage conventions, but I'm not totally sold on the exact phrasing. Also, it's probably worth discussing whether (on a philosophical level) it's better to put up with some ugliness in furtherance of a simple guideline (as the MOS apparently does at present), or instead, to complicate the guideline in pursuit of better typography and layout. TheFeds 16:32, 9 March 2010 (UTC)
  • Simply deleting the Spacing bullet would result in an even simpler guideline and would balance the two conventions, but for some reason I thought that would not be very popular... ― A._di_M. (formerly Army1987) 17:11, 9 March 2010 (UTC)

RfC: Disjunctive en dashes should be unspaced: Distinguishing between different uses

Looking at the votes, it seems to me that most of the opposition is concerned about confusing constructions. I believe there may be a way to satisfy their concerns. Up until now, we have treated all disjunctive en dashes equally. My proposed solution is to distinguish between the different uses of disjunctive en dashes. In particular, I propose something like the following:

En dashes standing for to or through in ranges are unspaced if the two items contain no spaces (1919–1920) and are spaced if either of the two items contains a space (5 January 1919 – 21 January 1919, 100 – 110 kW June 2008 – Present). Disjunctive en dashes in other contexts are unspaced (New Zealand–South Africa grand final, Seifert–van Kampen theorem). In a table or list, if one item is spaced, then the others must be as well.

This alone does not eliminate all confusion. I believe that the only way to do that is to explicitly prohibit it. This prohibition is not about spacing, but since it's important to this debate I think I should propose specific language:

En dashes must not be used when they are ambiguous. For example, in New York–London flights began in 1968, it is unclear whether the flights are from New York to London or are from York to London. Instead, use New flights from York to London began in 1968 or Flights from New York to London began in 1968.

What would everyone think of this? Ozob (talk) 23:14, 10 March 2010 (UTC)

• It's complicated and confusing. The current system is simple: one rule, which is that if there is one space or more within the elements, space the dash as well (given the more recently inserted optional exception for the mathematics lobby in "Seiffert–van Kampen"). The kW example is wrong: the elements are 100 and 110; kW applies to both, just as the month applies to both in 13–16 January. Tony (talk) 02:46, 11 March 2010 (UTC)

  The current system is more confusing, because it makes a strange optional exception for spaced surnames. Nowhere else is there a distinction between spaced surnames and anything else. But the section on en dashes already distinguishes three different uses of disjunctive en dashes. We all agree that these are different uses: None of us would argue that Newark – New York is a range or that 1 October – 14 October means 1 October versus 14 October. Since the distinction between ranges and non-ranges is already necessary, I don't see why it's so much more effort to space them differently.

  You are right about the kW example. At the moment I can't think of a replacement that shows off the case I want: One of the items has no spaces, the other does, and the dash represents a range. In such a case I believe that the dash should be spaced. If I think of an example I'll put it in. Ozob (talk) 03:12, 11 March 2010 (UTC)

  2 million – infinity? June 2008 – present? Iron Age – Renaissance? Art LaPella (talk) 03:40, 11 March 2010 (UTC)

  But again, let's be careful about using an en dash in any context. What is wrong with "to" in these examples? In a table, sure, it's better, or where there's a succession of time ranges in the running prose. But if just an isolated expample, I'd be inclined not to use punctuation. Tony (talk) 04:27, 11 March 2010 (UTC)

  Me too. Also, June 2008 – Present is exactly the kind of example I was looking for. I've added it to my proposal above. Ozob (talk) 11:53, 11 March 2010 (UTC)

Ambiguity is present no matter what system is used. For example, the sentence "New Mexico–South America flights began in 1968." is ambiguous regardless of whether that en dash is spaced or unspaced. So I suggest using this route in the example instead: that way the example is independent of whether one prefers spaces around such en dashes. Also, I suggest changing the kW example to something like "10 W – 200 kW". I also agree with Tony's suggestion to mention that the en dashes are more appropriate for tables and the like. Eubulides (talk) 06:00, 11 March 2010 (UTC)

You suggested "New Mexico–South America flights". What, the new flights from Mexico to South America? This is an ideal example of why jamming innermost elements should not be done. Tony (talk)

It appears that the previous comment missed the point of the example. That example is ambiguous regardless of whether the dash is spaced. "New Mexico – South America flights" is just as ambiguous as "New Mexico–South America flights". Both examples can be plausibly misinterpreted as talking about new flights from Mexico to South America. Eubulides (talk) 06:15, 11 March 2010 (UTC)

It is exactly the same situation as New York–London flights began in 1968 in my example above; writing New York – London doesn't make it any better. I propose above that we prohibit this kind of bad writing. Ozob (talk) 11:57, 11 March 2010 (UTC)

No, because if spaces are required around the en dashes if and only if a disjunct contains spaces, then New York – London flights does not make sense as meaning "new flights from York to London". To get the ambiguity in that case, one needs a space in a disjunct other than the space following the "New". (I freely admit that all of these examples are bad writing, regardless of spacing.) Eubulides (talk) 07:01, 16 March 2010 (UTC)

By the way, the example is ambiguous even without the en dash. New Mexico to South America flights began in 1968 suffers from exactly the same double meaning. Ozob (talk) 12:05, 11 March 2010 (UTC)

True. Should this point be worked into the proposal? Perhaps not, if it'd make things too complicated, but I thought I'd ask... Eubulides (talk) 07:01, 16 March 2010 (UTC)

June 2008 – Present should have a lowercase p; except for that, it seems OK to me. ― A._di_M. (formerly Army1987) 12:43, 11 March 2010 (UTC)

At the moment, "present" is proscribed in date ranges--see WP:OTHERDATE. PL290 (talk) 13:01, 11 March 2010 (UTC)

Dead horse. Tony (talk) 13:19, 11 March 2010 (UTC)

If it's a dead horse, why is it buried in MoS, and who's flogging it? I'd be quite happy to see it removed. While it remains, it has a bearing on the way this thread develops. PL290 (talk) 13:30, 11 March 2010 (UTC)

Dead horses don't tell tales—I've deleted it. PL290 (talk) 14:16, 11 March 2010 (UTC)

Ozob, have you had time to read through the above comments and update the proposal accordingly? Eubulides (talk) 07:01, 16 March 2010 (UTC)

Well, here is what I'm thinking. There are right now three numbered points in the en dash section. I think there should be four. The first would be about en dashes expressing a range, and it would have basically the same text as the first bullet of the current point one, plus a rule that says that ranges containing spaces should have spaced en dashes. The second numbered point would cover and, or, to, and versus; it would combine the second and third bullet under the current point one, and it would have a rule saying that such en dashes are always unspaced. The third numbered point would cover lists and the fourth, interruptive en dashes—these would stay the same. The separate spacing section would be removed. How does that sound to everyone? Ozob (talk) 00:23, 19 March 2010 (UTC)

There is no consensus for this change. Tony (talk) 00:31, 19 March 2010 (UTC)

That's right. Consensus would have to be developed through discussion. How do you feel about this idea? Ozob (talk) 02:27, 19 March 2010 (UTC)

RfC: Spaced disjunctive en dashes should be restricted to date ranges

Following on from the discussion above (and with a new header to clarify discussion), I wonder if there is any case where we should use spaced disjunctive en dashes apart from the case of birth and death dates or similar simple date ranges. To take the example of a range of values for a physical quantity above, I would say that 10 W – 200 kW should be replaced by from 10 W to 200 kW or the range 10 W to 200 kW, depending on the context. The rational for restricting the use of spaced en dashes is that they have another common use in English – to introduce parenthetical phrases – and it is not our business to say that they should be replaced by parentheses (or, sometimes, semicolons) when this usage is widespread. We are not the defenders of the purity of English punctuation, especially when such supposed purity comes at the detriment of readability. Physchim62 (talk) 13:08, 11 March 2010 (UTC)

I don't think there should be any difference between dates and anything else; from 10 W to 200 kW is typically better in prose but 10 W – 200 kW may be useful in lists, tables, parentheses and the like, and the same applies to from 1 January to 31 July v 1 January – 31 July. ― A._di_M. (formerly Army1987) 14:38, 11 March 2010 (UTC)

The difference is that we have large numbers of spaced disjunctive en dashes (within parentheses) in the lead sections of biographies which are not problematic. Pretty much all the other occurrences of spaced disjunctive en dashes are problematic to some extent, depending on your point of view on the issue, although I agree that tabular material is another reasonable exception. Physchim62 (talk) 14:58, 11 March 2010 (UTC)

I don't want to second-guess an article's editors on whether an en dash is appropriate or not. Maybe 10 W – 100 kW is a good idea in context; we shouldn't sit on our thrones here and command them otherwise. We might want to recommend otherwise, but that's difficult to do because people in a typographical dispute often treat the MoS as absolute; they wield our words as weapons, whether or not we want that. So I think we really ought to have a rule that allows for en dashes in almost any situation.

I'm a pretty big fan of the rule I proposed above (distinguishing ranges from other disjunctive en dashes). I think I'd like to see it in the MoS. Ozob (talk) 16:32, 13 March 2010 (UTC)

Capitalization and internal parenthesis

Feedback appreciated I nominated Hats Off to (Roy) Harper to be moved to Hats Off To (Roy) Harper due to my understanding of the following:

WP:CAPS: "...unless they begin or end a title or subtitle"

Wikipedia:MUSTARD#Capitalization "Titles that include parentheses should be capitalized as though both the part inside and outside the parentheses are separate titles (e.g., "(Don't Fear) The Reaper")"

This implied to me that since "to" is before the parenthesis within the title, it should be capitalized, even though it is usually not capitalized in proper English names. I had several other Wikipedians respond saying that I was misreading the style(s) and upon further reflection, I think they might be right. Does anyone else have two cents to add to these rare occasions? —Justin (koavf)❤T☮C☺M☯ 08:08, 6 March 2010 (UTC)

Addendum A similar conversation is going on here where I feel I am on more sure footing about (The Same Thing Happens with) The Birds and the Bees → (The Same Thing Happens With) The Birds and the Bees, (Do the) Mashed Potatoes → (Do The) Mashed Potatoes, and (The System of) Dr. Tarr and Professor Fether → (The System Of) Dr. Tarr and Professor Fether. Please let me know if there is something I am missing there as well, or if I am correct in asserting that these pages should be moved. Thanks. —Justin (koavf)❤T☮C☺M☯ 08:08, 6 March 2010 (UTC)

"both the part inside and outside" is ungrammatical. I assume it means "both the part inside and the part outside". In the example you cite, the part outside is "Hats Off to Harper", so lc is correct.

In the 2nd case, what you say fits the wording of the quote. I'm inclined to think the quote is wrong. My inclination is to say instead that the part outside the brckets should be capitalized as it would be if the bracketed material weren't there, while the material inside should be capitalized as if the brackets weren't there. Peter jackson (talk) 12:13, 6 March 2010 (UTC)

Concur with Jackson. Alone, the proper title case is "Hats Off to Harper," so with the parentheses, it would be "Hats Off to (Roy) Harper." Darkfrog24 (talk) 13:11, 6 March 2010 (UTC)

Also agree, and some of these titles could be used as examples in the documentation. --A Knight Who Says Ni (talk) 14:45, 6 March 2010 (UTC)

I agree with Jackson and Darkfrog24. ― A._di_M. (formerly Army1987) 15:23, 6 March 2010 (UTC)

I have modified the text in WP:MUSTARD to reflect what should be obvious. =) Powers ^T 20:49, 6 March 2010 (UTC)

I agree with Jackson and Darkfrog. Tony (talk) 03:24, 7 March 2010 (UTC)

Interestingly (but irrelevant to this discussion), on the back cover of the album it's misspelled as HATS OF TO (ROY) HARPER with one F, but it's spelled correctly both on the CD itself and on the booklet. The other typo on that track list, "Bron-Y-Aur Stomp", is consistently spelled thus everywhere (but the same song is called "Bron-Yr-Aur Stomp" on 2003 albums). ― A._di_M. (formerly Army1987) 21:50, 8 March 2010 (UTC)

New MUSTARD wording

• Comment Do you realize this does not clarify the original meaning, but directly contradicts it? Earlier, the example that was given was "(Don't Fear) The Reaper", but with the present wording, the proper title would be "(Don't Fear) the Reaper". My points are two-fold: 1.) I do not think this is the appropriate standard to have (i.e. I prefer it the way it was before) and 2.) this new standard is not a clarification of the old rule but a new one that is contrary to it in many cases. If the consensus is to use this wording, that's fine and well I suppose, but I think I should point out how it is not a more precise version of the same guideline, but an entirely new one that results in different titles (affecting scores and possibly hundreds of articles.) —Justin (koavf)❤T☮C☺M☯ 03:40, 11 March 2010 (UTC)

Unless the woring has changed since you posted the above comment, you seem to have misunderstood it. It says the part outside brackets should be capitalized as if the part inside weren't there. In the case you mention, the part outside is "The Reaper", capitalized so. Peter jackson (talk) 11:04, 11 March 2010 (UTC)

Brilliant Once again, I have misunderstood. That's embarrassing. —Justin (koavf)❤T☮C☺M☯ 05:39, 12 March 2010 (UTC)

"grammatical form"

What is "grammatical form"?174.3.110.108 (talk) 08:16, 10 March 2010 (UTC)

What is the context? Maurreen (talk) 20:57, 11 March 2010 (UTC)

Shortcut

When I edit an article, if I use the shortcut wp:retain, it highlights in red and says the article doesn't exist. If there a wp problem or am I doing something wrong? --MartinezMD (talk) 15:15, 10 March 2010 (UTC)

Capitalization matters for wikilinks. WP:RETAIN vs. wp:retain. Shortcuts are pretty much all in all-caps. --Cybercobra (talk) 15:16, 10 March 2010 (UTC)

Thank you.--MartinezMD (talk) 15:21, 10 March 2010 (UTC)

Bots making improper page moves claiming MoS in support

I don't appreciate bots running around moving Pseudo-Anosov map to Pseudo–Anosov map here with the claim that it is based on the MoS, with an edit summary "Bot: Moving page per WP:ENDASH". Unless somebody here wants to explain the contribution of Dr. Pseudo to this concept?

The worst part is, this improper move has stood for over nine months. How many others like it have there been? Gene Nygaard (talk) 20:51, 11 March 2010 (UTC)

If you mean others closely resembling it, I checked the bot's contributions, and it was apparently an isolated error among hundreds of proper moves. If you mean other errors of all kinds from all sources, well, I'm glad you caught that one, and I moved it back. Art LaPella (talk) 22:13, 11 March 2010 (UTC)

Glad to hear it was an isolated problem. It wasn't a bot that made this move, but could you fix Anti–Fengtian War, too? Gene Nygaard (talk) 22:52, 11 March 2010 (UTC)

 Done —David Eppstein (talk) 23:11, 11 March 2010 (UTC)

Saint–Venant's theorem is another one.

I suspect that it is an apprenticeship for aspiring stub-sorters, that they first need to put in some time slapping useless templates onto redirect pages, giving them a history so that we peons cannot fix improper moves such as these. Gene Nygaard (talk) 01:05, 12 March 2010 (UTC)

Also done. It does seem that the software should be able to recognize moves like that as innocuous and let non-admins do them. Oh well. —David Eppstein (talk) 02:42, 12 March 2010 (UTC)

• Well and good. Looks like Dr Pseudo has gone, and with a name like that, it's probably a good thing. En dashes wrongly standing in for hyphens are worse than the other way around, to my eyes. Tony (talk) 05:11, 12 March 2010 (UTC)

• There are literally millions of these sorts of redirects (hyphen to endash title), the last time that I looked. Doing those sorts of moves was really in vogue, for some strange reason, a few years ago. I'd be completely onboard if someone decided to try to reverse all of these, so that the names use regular hyphens. Dealing with endashes in article titles is a pain in the ass, generally.
  — V = IR (Talk • Contribs) 19:24, 12 March 2010 (UTC)
  • Does that mean you want to move articles like Michelson–Morley experiment, for example, back to the redirect Michelson-Morley experiment? If so, I hope that means changing WP:ENDASH to match. The only thing worse than obscure written rules is obscure unwritten rules. Art LaPella (talk) 21:05, 12 March 2010 (UTC)
    • I wouldn't mind if the actual URLs have hyphens instead of en-dashes, but I don't want the displayed page title to show a hyphen that should properly be an en-dash. So if {{DISPLAYTITLE}} would be allowed to work in this case, I'd be happy. But I don't think it does currently work, due to the "provided the selected title normalises to the same title" language in mw:Manual:$wgAllowDisplayTitle. Does anyone have any idea what would need to be done to allow title normalization to transform en-dashes to hyphens? Because I think that's what would need to happen to do things that way. —David Eppstein (talk) 21:45, 12 March 2010 (UTC)
      • humm... I should make it clear that I don't really advocate doing anything in particular here. I realize now that my statement above tends to indicate the exact opposite, but really I seem to have simply overstated my case. The just of it is that I feel solidarity with Gene (and David?) in that these hyphen to en dash page titles are just annoying all around. It kind of bugs me that people started moving them all to their more technically correct title simply because it's nearly impossible to create new articles that use en dashes (and the vast majority of newer editors creating pages won't even know to try). The reason that I think this is an issue is because it makes it nearly impossible for Wikipedia to maintain any consistency, since almost any new article using a hyphen will be "wrong" automatically. Anyway, there are more important things to worry about (such as.. *ahem* the thread immediately below, perhaps?)
        — V = IR (Talk • Contribs) 01:03, 13 March 2010 (UTC)
        • People are always free to make the page with a hyphen initially; someone else can take care of moving it. In the math project at least, the move will usually happen within a day once the new page is categorized. So everything does stay consistent, apart from very newly created articles. That seems reasonable enough to me: new users can do whatever seems natural, and some more experienced user will help bring it into consistency with the rest of the project. — Carl (CBM · talk) 16:47, 13 March 2010 (UTC)
          • It would seem more elegant to me if all these articles were named with a hyphen and used {{DISPLAYTITLE}} to appear with an en dash. Wikilinks to such articles could be given en dashes automatically by a bot. That avoids all of this trouble, I think. Ozob (talk) 17:31, 13 March 2010 (UTC)
            • Agreed. (now, can someone please address the thread below?)
              — V = IR (Talk • Contribs) 17:34, 13 March 2010 (UTC)
              • That's way too complicated and unnecessary; redirects handle this just fine. However, let me address CBM's point that "people are always free to make the page with a hyphen originally; someone else can take care of moving it". Tat is, of course, quite true. However, that ISN'T WHERE THE PROBLEM ARISES. The problem arises when people create article names with the dashes originally, and fail to create the necessary redirects from the hyphen version. That happens frequently; no matter what the naming conventions pages or the MoS say about needing to create hyphen/dash redirects and needing to create redirects to article names without diacritics, that simply isn't done in a great many cases. Furthermore, while the en-dash pushers here will run around making sure that articles using hyphens get moved to dashes, none of them ever seem to take care of the flip side of this coin. Gene Nygaard (talk) 16:22, 14 March 2010 (UTC)
              • Here are a few examples from just a quick check of one category:

                Bragg-Gray cavity theory

                Leggett-Garg inequality

                Runge-Gross theorem

              • Those should not be red—but they are. Gene Nygaard (talk) 16:38, 14 March 2010 (UTC)
                • Those should not be red, although all 3 would be easy to find if you looked for them using a hyphen. Assuming there are more than just 3 such articles, I can't think of a good way to find them all short of using a bot. So is this an occasion for Wikipedia:Bot requests? Art LaPella (talk) 19:16, 14 March 2010 (UTC)
                  • Seems like it; I did a quick database query and it looks like there are about 14,000 of them. If you are wondering how we have that many, about 9800 involve year ranges (1899-1900 FA Cup) and exactly 2100 have the word "relations" in them (United Kingdom - Kyrgyzstan relations). — Carl (CBM · talk) 19:28, 14 March 2010 (UTC)
                • Easy to find if you look for them using a hyphen? For these, maybe, if you are talking about using the "Go" box on the Wikipedia page, and look far enough down to see what you are looking for in the search results and click on it. But in any case, that's of no avail whatsoever when you run into the redlink on the page at Time-dependent density functional theory—on a "Main article" link, no less; you'll just think Wikipedia lacks that article. Gene Nygaard (talk) 19:41, 14 March 2010 (UTC)
                  • • I have to admit I assumed there was already a bot that looked for these. Because it's such an easy bot task, and there are always people looking for easy bot tasks. — Carl (CBM · talk) 19:44, 14 March 2010 (UTC)

Re Ozob: It seems to me that you are saying that instead of this situation:

A-B redirects to A–B. Links to either one work, and searching for either one works.

we would have this situation:

A–B redirects to A-B. Links to either one work, and searching for either one works, but we have to make sure that there is a displaytitle template on A-B at all times. Also, any time we have a table or other list that includes names of articles, this list needs to detect the displaytitle template so that the table will show A–B instead of A-B. This includes the lists of good articles and featured articles, peer review, deletion discussions, and all sorts of other places where we display article titles.

That doesn't seem like an improvement to me. It's easier to let people mark which titles should have an en dash by simply moving the article to the name with the en dash. Otherwise, how would we ever distinguish automatically between titles like well-ordering theorem and titles like "Wells–Ordering theorem" by two mathematicians named Wells and Ordering? 18:13, 13 March 2010 (UTC)

Yes, when you put it that way, it does seem more complicated. I suppose that in order to make this proposal work, one would really need an additional feature: If one makes an unpiped wikilink to A-B, then it is automatically displayed as A–B. Of course, that might be undesirable, since you wouldn't get precisely what you wrote. So maybe this isn't such a good idea after all. Ozob (talk) 20:28, 13 March 2010 (UTC)

"People are always free to make the page with a hyphen initially"—I could not disagree more. It's like saying that people are always free to write crappy prose. They will, but please do not encourage breaches of the style guide here. Tony (talk) 00:23, 14 March 2010 (UTC)

Just so new contributors don't get the idea that they can't contribute until they understand how and when to encode an en dash. We'd lose 99% of our new contributions. Art LaPella (talk) 01:46, 14 March 2010 (UTC)

I think it's a standard principle: if you don't know exactly what to do, just do something reasonable, and someone else will change it if it needs to be changed. This applies to stylistic concerns, reference formatting, etc. There's no requirement that editors need to read instruction manuals before editing articles. Of course if I had to rename 15 articles by the same editor I would contact them, but an article here or there by a new editor is easy enough to fix. — Carl (CBM · talk) 01:58, 14 March 2010 (UTC)

It's not like crappy prose, Tony. And it should definitely be encouraged; you and the en-dash crew will still see that the articles are moved; going the other direction, when someone creates an article with dashes you won't bother to make sure that the necessary redirects are created. Thus we end up much better off when the articles are originally created with hyphens. Gene Nygaard (talk) 18:50, 14 March 2010 (UTC)

• Bot request at Wikipedia:Bot_requests#Bot_to_create_redirects_from_hyphens_to_dashes. Ucucha 18:53, 18 March 2010 (UTC)

Images and third level headings

I'm certain that there used to be advice/recommendations somewhere about the interaction between images and third level or greater headings. It was good advice, and without it there are now people actively looking to make changes to do the "wrong thing". So, what ever happened to that advice?
— V = IR (Talk • Contribs) 19:19, 12 March 2010 (UTC)

You may need to be more specific for anyone to answer. I know there is advice somewhere about how images can make the [edit] links bounce around in some browsers. Is that what you are thinking about? — Carl (CBM · talk) 18:44, 13 March 2010 (UTC)

Ah, that makes sense, sorry. I wasn't talking about the [Edit] links directly, no. That was a part of what I remember though, I think. The main thing that I remember is that there used to be advice someplace about the placement of images around third level or (greater, or lesser? higher value) headers. The actual issue is that if you place an image immediately below a third, fourth, fifth, or sixth level header, that it causes the header to sort from "break away", or "float away", from the following body text. Since there's no horizontal rule to headers beyond the h2 level, having a header immediately above the image creates that floating appearance if the image is on the left, and we all know how it'll mess up the [Edit] links on the right.

I remember talking with someone about this a while back, and the work-around was simply to place the image immediately above the h3 header. It's still within the (h2, at least) section that the image belongs in, but that fixes the layout issue. Of course, if there's enough text in the section the other solution is to simply move the image down slightly, but even then I tend to think that putting the image immediately above the header looks cleaner.

Currently, MOS:IMAGE only includes the second bullet point that covers this at all, which says that "images must come after the header". I didn't realize that (it had changed?), so I was a bit surprised at being reverted with a claim that the MOS instructed the opposite. (and then some fool posted something on the talk page saying that we were edit warring, but I just ignored whoever that was, and luckily so did Miesianiacal). Seeing it may make it easier to understand, so take a look at the last few edits on March 11 to Elizabeth II, mostly in the Elizabeth II#Reign section.
— V = IR (Talk • Contribs) 21:52, 13 March 2010 (UTC)

Ohms law, I believe this is what you are looking for (taken from the 09:26, 18 September 2009 (UTC) version of the MOS): "Do not place left-aligned images directly below a subsection-level heading (=== or lower), as this sometimes disconnects the heading from the text that follows it. This can often be avoided by shifting left-aligned images down a paragraph or two." The consensus to remove this advice was formed here; there were also discussions about this at an FAC and in my talk page archives, IIRC. Dabomb87 (talk) 00:34, 14 March 2010 (UTC)

That's it, thanks! Off I go to do some reading...
— V = IR (Talk • Contribs) 03:45, 14 March 2010 (UTC)

I might add that, if I recall correctly, the guidance against placing an image before the heading of the section in which it is supposed to appear stems from accessibility concerns. A screen reader would see the image before the section title, a potentially confusing situation. Waltham, The Duke of 03:44, 14 March 2010 (UTC)

Right, I understand that, but remember that we're talking about third level and above headings here. Generally, having such an image "appear before the section" isn't really an issue there, since everything should be part of the h2 section anyway, if you see what I'm saying.
— V = IR (Talk • Contribs) 03:48, 14 March 2010 (UTC)

I think I do see what you are saying. However, I am not sure I agree with the assumption you seem to be making about the general tendency of readers to read entire sections. I have often read in an article only the lead, the table of contents and a sub-section or two which happened to have an interesting title. Waltham, The Duke of 05:30, 14 March 2010 (UTC)

I agree with that, since I often do the same. Generally though, second level headers are the sections that people go to. Third level and (god forbid) higher subsections tend to generally be too specific to provide enough context that they are of interest all on their own. That's the main reason that a horizontal rule is not a component of h3 or greater headings, in most layouts (not just on Wikipedia, either)
— V = IR (Talk • Contribs) 05:36, 14 March 2010 (UTC)

• OK, after having read the archives that User:Dabomb87 posted above, I have a couple of observations. This was a long standing point in the MOS for a decent reason; namely, that it really is visually distracting to most to have an image appear immediately below any heading which does not use a horizontal rule. However, I'm not going to argue that the point be reinstated (Others can do that, if they care enough), but I am going to ask that we do something to allow us as editors to address the problem when it is a problem. This all started because the MOS was apparently not allowing editors to do the Right Thing™, but instead of actually fixing anything we've simply shifted the problem from one extreme to another. So, I'd like to propose that the second bullet be modified in some manner. My suggestion, to start things off, would be something like: Images should be inside the major section they belong to (after the level 2 heading containing the content that the image belongs with).. That's less strident, which should make the point less of a battleground sort of issue for some, but most importantly it preserves the ability for editors to intelligently layout articles, as we've been discussing throughout all of this. Note that I've also removed the bit that said "and after any links to other articles," because I've noticed that the text from links, such as those created by {{See also}} and it's ilk, suffer from the same sort of flotation problems that headings do, if the layout isn't done correctly. Thoughts?
  — V = IR (Talk • Contribs) 04:32, 14 March 2010 (UTC)

  So, is this WP:SILENCE, apathy, or are people distracted by other issues at the moment?
  — V = IR (Talk • Contribs) 02:02, 15 March 2010 (UTC)

  In my case, it's total unfamiliarity with the issue. Art LaPella (talk) 05:25, 15 March 2010 (UTC)

  Yeah, you lost me on that one. Dabomb87 (talk) 23:53, 17 March 2010 (UTC)

  OK, I'm perfectly willing to attempt to explain further. The original language, stating "Do not place left-aligned images directly below a subsection-level heading" was problematic for the reasons that SlimVirgin and others criticized it for, but it still contained a kernel of good advice. The problem is that headers below level 2 ("== These ==", or <h2> in HTML) do not contain a horizontal rule beneath the heading in any skin that I am aware of (they definitely don't in monobook or vector, which probably covers upwards of 99% of readers/users). That being the case, images around level 3 and below headings tend to cause issues because they make the heading appear to "float" disconnected from the body text (this is especially true of left-aligned images), and they also cause "the bunching problem" to occur more readily (the HR with level 2 headers seems to push things around some, so there are a few fewer bunching issues with them).

  The kernel of good advice in the original text was fairly simple, that you need to do something with images around 3rd level or lower headings. Now, usually level 3 or lower headings are used do differentiate text that is covering a distinct subset of information that is closely related to the primary topic that the level 2 header is discussing. That being the case, if the associated images are somewhere within the section defined by the level 2 heading then the image will still be associated with the topic. The main point that the second bullet deals with is to keep all images within the section that discusses the topic that the image represents, so the goal here is to allow editors to place the images anywhere in the second level section, but avoid placing them immediately below level 3 headings. the usual method, that I'm aware of, in dealing with this is to either move the image down a paragraph or to move the image to be located immediately above the level 3 heading. either way, the "hanging header" issue, and many "bunching issues", are resolved while the image is still in the primary section which it represents. Is that a little bit better of an explaination?
  — V = IR (Talk • Contribs) 02:36, 18 March 2010 (UTC)

I see that the change has been made, though it's not clear to me that consensus for the change was established here. I have not followed this discussion, but was attracted here by the wording of the replacement text. I want to nitpick it a bit on two points: (1) headings don't contain content; headings introduce sections which contain content, (2) dangling preposition (OK, up with which this is puttable—but it is a speed bump almost as severe as that introductory phrase). How about something like " Images should be inside the major section containing the content to which they relate (after that section's level 2 heading).? I'm sure that can be improved by someone who is a better writer than I. Wtmitchell (talk) (earlier Boracay Bill) 01:07, 18 March 2010 (UTC)

Well, I made the change a bit more then 24 hours ago. I wanted to give it a day to see if anyone would just revert it, which hasn't happened, but I'm willing to revert it myself if there's any real problem with it that we could discuss. Since the discussion here just petered out, I figured that the change would, at worst, kick this discussion back to life.

I actually do appreciate the nitpicks on the language, since I'm not real happy with it myself. One aspect to this is that I don't want to re-introduce the original language, which was removed earlier, though a back-door. I appreciate the criticisms that SlimVirgin and others leveled at it (links to that discussion are provided by Dabomb87's post above), but I'm hopeful that everyone can appreciate the counter criticism that I'm trying to highlight here, that simply removing the original language completely has unintended and unwanted side-effects.

Anyway, I rather like the proposed new wording. I'd say go ahead and add it yourself, or I can myself in a day or so. Thanks for the feedback!
— V = IR (Talk • Contribs) 02:20, 18 March 2010 (UTC)

Actually, how about this: Images should be inside the major section containing the content to which they relate (within the section defined by the most recent level 2 heading).
— V = IR (Talk • Contribs) 02:40, 18 March 2010 (UTC)

In the face of complete silence here , I've gone ahead and made the change.
— V = IR (Talk • Contribs) 10:30, 19 March 2010 (UTC)

Register

MoS section titles are being updated with {{MOSR-link}} to link to Wikipedia:Manual of Style/Register. This breaks links into the MoS, as the [R] is part of the section title and the brackets have to be encoded. Templates should not be used in section titles; see {{shortcut}} for a better example. ---— Gadget850 (Ed) ^talk 13:19, 13 March 2010 (UTC)

Agreed. People have been starting to go nuts with the wikitext in section titles, ever since the devs fixed them last year. It's one thing to use wikitext in section titles on talk pages, it's quite another to do so on the actual page. We can ease up on the "rule", but it's generally a bad idea to simply allow anyone to add whatever wikitext they want to section titles.
— V = IR (Talk • Contribs) 17:37, 13 March 2010 (UTC)

By the way, for those who may be interested, Ed's post above seems to have been prompted by this, from the Help desk.
— V = IR (Talk • Contribs) 17:42, 13 March 2010 (UTC)

The "R" link was inspired by Wikipedia talk:Manual of Style/Archive 113#Revisiting my concrete proposal, and its revision was inspired by Wikipedia talk:Manual of Style#Misplaced 'R'? (permanent link here, section 10). Unfortunately, Noetica is not here to comment on these unexpected complications in one feature of Noetica's proposal. -- Wavelength (talk) 18:07, 13 March 2010 (UTC)

I'm the one who posted the Help Desk item. My opinion is, first, that section titles in an article as often linked to as WP:MOS should be kept stable unless there is an actual reorganization. Second, that section titles should not contain square brackets, because of the difficulty in linking to them -- hence my Help Desk posting. And third, that the right way to provide the desired links was not to jam them into the section titles; instead, the style of the "Main article" template should have been followed. This is sufficiently obvious in my mind that if the article wasn't protected, I'd have gone ahead and changed it.

If there really is consensus that I'm wrong on the first and third points, could you at least change the square brackets to something usable in a normal wikilink? --208.76.104.133 (talk) 01:40, 14 March 2010 (UTC)

At this moment, I have only begun to study Template:Shortcut (mentioned above), and I do not understand the relevance of the "Main article" template, but if (and only if) you really understand what you are doing, then please do go ahead and make the necessary change(s), as I wait and watch hopefully, hoping that this new solution does not bring with it yet another unexpected problem.—Wavelength (talk) 03:56, 14 March 2010 (UTC)

[I am striking out "with it", which should have been "with itself" anyway. -- Wavelength (talk) 04:17, 14 March 2010 (UTC)]

I agree with 208.76.104.133, jamming it in the section-title is a poor plan. It's especially bad if it's done via a template, because that makes a fragile point of failure: changing the template instantly breaks every incoming link to everywhere it's used. If it's not really supposed to be part of section-title text (which it seems is the intent, given that it's not displayed there in the body, only in the TOC), then I don't see a reason to implement as a template on the section-title at all (cleaner to put within the section itself since that's where it renders)? As for the item itself, why are we making it not self-evident what it means, one-word instead of single letter, for example? I think the "Main article" comment means to use a phrase in a section hatnote rather than as a right-corner shortcut item. Especially on MOS pages, short links in the shortcut area are commonly used for...shortcuts. My first assumption was that "R" was a shortcut link for the section I was reading and only came to this discussion when it wasn't. DMacks (talk) 09:37, 16 March 2010 (UTC)

Wikipedia:WikiProject Cities/Guideline has been marked as part of the Manual of Style

Wikipedia:WikiProject Cities/Guideline (edit | talk | history | links | watch | logs) has recently been edited to mark it as part of the Manual of Style. This is an automated notice of the change (more information). -- VeblenBot (talk) 02:00, 14 March 2010 (UTC)

WP:Quotations

It's an essay at the moment, and there's a proposal on the talk page to promote it to guide-line status. It was linked at MOSQUOTE earlier today, although I removed that pending improvements. I've done an initial copy-edit, and have left several inline comments about organisation/repetition. IMO, it needs a few more examples. What do people think? Tony (talk) 00:34, 15 March 2010 (UTC)

Anyone really looking at things will be able to see that I added the link to the MOS, and it probably should be noted that I did so only after opposing the essay's promotion to either guideline or policy. My thinking was, the primary motivation behind the desire to promotion the page from an essay seems to be a desire to increase it's profile, which I don't have a problem with at all personally. I actually think that it would generally be a good idea to provide such links to relevant essays where it makes sense, in the same vein as the way that we seek to provide relevant links between articles. Copy editing the essay is a good idea for sure, although I'm not sure that should be a prerequisite, but I'll happily leave that up to y'all to decide.
— V = IR (Talk • Contribs) 02:00, 15 March 2010 (UTC)

No, this essay has been proposed for upgrade since it was first written. It started out as an essay, but the ultimate goal was to make it protocol. This is probably the 5 request to make it a protocol. Also, if it remains as an essay, it will not have any judical power and many quotes will be used inappropriately.174.3.107.176 (talk) 10:06, 15 March 2010 (UTC)

It was a good move; but can we wait just a little while for the page to be improved? I'm keen to hear the opinions of people here and at WT:FAC. Tony (talk) 03:17, 15 March 2010 (UTC)

That's fine by me! As I indicated on your talk page earlier, the limit to my level of interest in all of this was actually reached with the addition of may vote on it's talk page, and the link to the MOS. I was simply curious as to the rational for the links' subsequent removal, which you've since explained more then adequately (incidentally, I can tell that I'm getting tired by the increase in the verbosity of my responses. lol).
— V = IR (Talk • Contribs) 04:06, 15 March 2010 (UTC)

Need to avoid duplication with WP:PLAGIARISM, otherwise there will be inconsistencies. --Philcha (talk) 05:47, 15 March 2010 (UTC)

I'd be a bit concerned about this having guideline status, because it would mean yet another page to monitor for inconsistencies with the other guidelines and policies. Also, editors tend to take that kind of advice very literally, so we'd end up with quotations being removed for spurious reasons. Is there a clear need to raise it above the level of an essay? SlimVirgin ^{TALK contribs} 07:28, 15 March 2010 (UTC)

Yes there is.174.3.107.176 (talk) 10:06, 15 March 2010 (UTC)

I agree with those concerns, which is why I oppose the essay being promoted. I see that as a separate issue from linking to it from the MOS, thoguh. As an essay it does contain some decent advice, from at least one perspective, as is true with most essays. But... meh, if y'all would rather not have links, that's OK by me as well.
— V = IR (Talk • Contribs) 19:13, 15 March 2010 (UTC)

I don't see any need to promote this page to guideline status. While some of the advice is okay, most of it deals with questions of taste and style. Only the issues of attribution and verifiability need to be rules. The rest serves us better at the essay level. Darkfrog24 (talk) 21:59, 15 March 2010 (UTC)

Why is a MOS important?

Why is a style guide necessary and/or desirable for Wikipedia?

I noticed that this question isn't answered in the lead section. The linked style guide also doesn't answer it. Most newcomers might ask: why do we have to have a manual of style anyway? And WP:LEAD says that we should have an indication of the subject's notability in the lead section. Sometimes you get so caught up in the trees, you forget about the meaning of the forest.

I'm not suggesting that the whole Manual of Style should be scrapped. I am saying that the answer to this question should be included in the lead. --RoyGoldsmith (talk) 13:31, 15 March 2010 (UTC)

Well there's an irony! "Tell us what's notable about this subject in the lead" but the MOS doesn't tell us what's notable about the MOS in the lead! Perhaps: "A manual of style is necessary in order to help editors write and maintain articles that follow a consistant pattern, remain stable, are properly sourced, and are clear and precise in their language and layout; this in turn helps make the entire encyclopedia easier and more intuitive to use"? Probably far more to say, but a start? --Jubilee♫clipman 15:06, 15 March 2010 (UTC)

While that's useful, other issues should be resolved first, e.g.

• What is the central criteria for identifying and resolving issues? I suggest "for the benefits to readers", especially non-contributing readers.
• What are the objectives for a volunteer project? I suggest some parts of MOS impose at lot of work on editors but deliver negligible or invisible to readers.
• What is the main formats by which WP is delivered. I suggest that the great majority of pages are read from screens, mostly via the Web but perhaps some from CDs/DVDs such as WP:Edition 1.0. A body of principles called "Web readability", which is part of Web usability, has been developed since about 1997. --Philcha (talk) 15:20, 15 March 2010 (UTC)

Please: Ask what is the central criterion, not what is the central "criteria". Michael Hardy (talk) 16:22, 15 March 2010 (UTC)

I'm a bit surprised by the question, since everyone is accustomed to every magazine, newspaper, scholarly journal, and periodical publication of any kind adhering to a style manual. Michael Hardy (talk) 16:22, 15 March 2010 (UTC)

Michael Hardy,

• I chose criteria because at this stage we don't know whether singular plural - e.g. in RL I suggest there are trade-offs at the top level (unless you're a genetic reductionist).
• AFAIK it's agreed that WP needs a MOS, but I suggest WP needs to re-examine the current WP:MOS from the top down,and that we should not assume that "every magazine, newspaper, scholarly journal, and periodical publication of any kind" is a model for WP. --Philcha (talk) 20:46, 15 March 2010 (UTC)

I actually think that's a pretty good assumption. Every periodical means both the print and online versions. I'd add "encyclopedia" to that list, though. Darkfrog24 (talk) 22:10, 15 March 2010 (UTC)

• Bah, WP:LEAD and WP:N don't apply to the project namespace, just the main article space. :P EVula // talk // ☯ // 21:03, 15 March 2010 (UTC)
  • True. However, there is no indication of the need for this MOS in the lead: you have to scroll right past the huge list of contents before you even get close to finding an answer. I think that is the main concern. OTOH, the mainspace article, style guide, also failed (now corrected by Maurreen) to fully explain why style guidlines are actually necessary in its lead. I think those facts, taken together, are what the original questioner meant to bring to our attention --Jubilee♫clipman 21:38, 15 March 2010 (UTC)
    • There's no indication of the need of a need. Seriously, it's just the manual of style; why would it need to justify its own existence? That's not its purpose. We shouldn't be trying to apply mainspace restrictions to the project namespace; they're very different creatures. EVula // talk // ☯ // 19:01, 16 March 2010 (UTC)

• (hehe) Regardless of anything else, this is always an important question to answer as soon as possible, in some fashion, in any document. Especially for technical documentation. It's sort of strange, but "long'ish" articles with poor leads are relatively common on Wikipedia, even in articles with excellent content in their body. That's something which we should probably all work on.
  — V = IR (Talk • Contribs) 21:50, 15 March 2010 (UTC)

I have a question. Do we need to tell people why the MoS is important? Does it serve the MoS's purpose to do so? I certainly wouldn't object to adding a well-turned line or two, but I'm not convinced that it's necessary.

We should take into account that many of the editors using the MoS will not have used a style sheet before. Darkfrog24 (talk) 22:10, 15 March 2010 (UTC)

Oh hell, we all know we're here to show off how many pointless rules we've studied, right? Why do we need to explain our purpose? :) To me, the first priority is to bridge the gap between this subculture and the rest of Wikipedia. Art LaPella (talk) 04:14, 16 March 2010 (UTC)

AFAIK every article about Web readability and usability contradicts Darkfrog24 's "pretty good assumption" that "every periodical means both the print and online versions" (22:10, 15 March 2010). Web readability and usability articles emphasis that layout and even sentence and phrase have to be different for screens, because reading from a screen is about 20% slower, and more tiring - because screens are more grainy than printed output. --Philcha (talk) 23:21, 15 March 2010 (UTC)

My two cents: of course such an explanation isn't vital, as the MoS has existed for nearly nine years without one and the sky hasn't fallen. But that's no reason for not even trying to write one. (It doesn't have to be long and detailed; one paragraph would suffice. Jubileeclipman's and Philcha's comments look like a good start.) At least, no-one could possibly get the impression that these rules need to be followed for their own sake, which would be contrary to the fifth pillar. ― A._di_M. (formerly Army1987) 21:26, 16 March 2010 (UTC)

OK, ignoring the infinite regression conundrums above, how about this as an insertion to the first sentence?

The Manual of Style (often abbreviated MoS or MOS) is a style guide for Wikipedia[, encouraging uniformity and consistency in formatting and English usage for all] articles.

I believe that Jubilee's longer statement is better suited at the top of section 1, like this:

==General principles==

A manual of style is necessary in order to help editors write and maintain articles that follow a consistent pattern, remain stable and properly sourced, and are clear and precise in their language and layout. This, in turn, helps to make the entire encyclopedia easier and more intuitive to use.

===Internal consistency===

An overriding principle...

--RoyGoldsmith (talk) 12:56, 17 March 2010 (UTC)

That makes a lot of sense: a simple lead expanded on in section 1. Good --Jubilee♫clipman 14:45, 17 March 2010 (UTC)

That looks good to me (FWIW).
— V = IR (Talk • Contribs) 02:43, 18 March 2010 (UTC)

General statements about "a manual of style" would be better for a Wikipedia article about manuals of style. The lead should discuss this manual of style. How about this?

The purpose of the Wikipedia manual of style is to help editors write and maintain articles so that they remain stable and properly sourced, employ correct English, and deliver information in a clear and precise way. This makes the entire encyclopedia easier to use and more professional in appearance. Darkfrog24 (talk)

The lead does discuss this manual of style in RoyGoldsmith's suggested wording above. Every aspect of his suggestion looks good to me. PL290 (talk) 19:26, 18 March 2010 (UTC)

I question some parts of "A manual of style is necessary in order to help editors write and maintain articles that follow a consistent pattern, remain stable and properly sourced, and are clear and precise in their language and layout. This, in turn, helps to make the entire encyclopedia easier and more intuitive to use" as proposed by RoyGoldsmith (12:56, 17 March 2010) and Darkfrog24:

• A MOS can do nothing about "remain stable", which is WP:CONSENSUS, WP:DE, WP:REVERT, etc.
• Likewise MOS has nothing to with "properly sourced", which is the province of WP:V, etc. --Philcha (talk) 20:38, 18 March 2010 (UTC)

Actually, I proposed that text and it was straight off the top of my head [15:06, 15 March 2010 (UTC)]. You are correct, though, that those two items have little to do with the MoS and can be removed --Jubilee♫clipman 21:54, 18 March 2010 (UTC)

I don't think we should say "necessary" for maintaining good articles because it is possible to do it without a MoS. A MoS, however, does usually help, and it's perfectly true to say that such-and-such is the MoS's "purpose."

I don't think we should talk about uniformity or consistent patterns. Uniformity is not itself a virtue the way correct language and good structure are. It can improve readability, however, so it would be valid to talk about that.

The MoS does actually help articles remain stable in some ways: It establishes good form and that, at least in theory, is supposed to stand above otherwise warring editors' personal preferences on form.

Taking Philcha's comments into account, how about The purpose of the Wikipedia manual of style is to help Wikipedia editors write and maintain easily readable articles that employ correct language and deliver information in a clear and precise way. This makes the entire encyclopedia easier to use and more professional in appearance.' Darkfrog24 (talk) 21:47, 18 March 2010 (UTC)

That's much better. Good --Jubilee♫clipman 21:57, 18 March 2010 (UTC)

So that's why we say "six sentries" not "6 sentries", but "6th century" not "sixth century"! I always wondered about that ... Art LaPella (talk) 00:01, 19 March 2010 (UTC)

1. I don't like "correct" (title and sentence case are both "correct" for titles, but we made a call to use sentence case, thank heaven, even though title case is more common out there).
2. I wouldn't go into the stability issue; nor stray into "intuitive", "easier to use", "necessary", or "properly sourced". Let's not make claims that would take a whole talk page to justify.
3. Who wrote "in order to"? Just "to", thanks.
4. I'm not sure the current lead isn't fine. The MoS is far too long already—not in scope, but in terms of its wording, its superfluous examples, and the verbiage made necessary because of poor organisation.
5. The second paragraph needs to be binned: what on Earth is it doing there, right next to a list of links to all of the sibling pages?
6. If there has to be a change, let it be more like this:

The Manual of Style (often abbreviated MoS or MOS) is a style guide for encouraging consistency in style and formatting in Wikipedia articles. This main page contains basic principles. Subpages that set out topics in greater detail are linked in the menu to the right. If the Manual of Style does not specify a preferred usage, discuss the issue on the talk page.

Tony (talk) 00:28, 19 March 2010 (UTC)

I like Tony's paragraph. It's straightforward and easy-to-read. However, I'd prefer to shrink it even further:

The Manual of Style (often abbreviated MoS or MOS) is a style guide for Wikipedia articles. This main page contains basic principles. Subpages with greater detail are linked in the menu to the right. If the Manual of Style does not specify a preferred usage, discuss the issue on the talk page.

The more we can condense the MoS, the more likely editors are to read it! Ozob (talk) 02:25, 19 March 2010 (UTC)

OK. As near as I can tell, we now have two main flavors of proposals for the first paragraph of the lead section, each having two variations:

• The minimalist suggestions (Adding a new clause [here in square brackets] to the first, definition sentence).
  • By Tony: The Manual of Style (often abbreviated MoS or MOS) is a style guide for [encouraging consistency in style and formatting in] Wikipedia articles. This main page contains basic principles. Subpages that set out topics in greater detail are linked in the menu to the right.
  • By RoyGoldsmith: The Manual of Style (often abbreviated MoS or MOS) is a style guide for Wikipedia[, encouraging uniformity and consistency in formatting and English usage for all] articles. This main page contains basic principles. Subpages that set out topics in greater detail are linked in the menu to the right.
• The longer suggestions (Adding two new sentences [square brackets again], immediately following the first).
  • By Darkfrog24: The Manual of Style (often abbreviated MoS or MOS) is a style guide for Wikipedia articles. [Its purpose is to help Wikipedia editors write and maintain easily readable articles that employ correct language and deliver information in a clear and precise way. This makes the entire encyclopedia easier to use and more professional in appearance.] This main page contains basic principles. Subpages that set out topics in greater detail are linked in the menu to the right.
  • By Jubilee and Philcha, wording by RoyGoldsmith: The Manual of Style (often abbreviated MoS or MOS) is a style guide for Wikipedia articles. [Its purpose is to help editors write and maintain articles that follow a consistent pattern and are clear and precise in their language and layout. This, in turn, helps to make the entire encyclopedia easier and more intuitive to use.] This main page contains basic principles. Subpages that set out topics in greater detail are linked in the menu to the right.

Just to see where we are right now, can we have a preliminary consensus poll on only whether you favor (a) the minimalist approach, (b) adopting something like the longer suggestions, (c) doing nothing and leaving the article alone or (d) shrinking the lead down to one paragraph? We'll vote on which variation, if needed, at a later time. --RoyGoldsmith (talk) 03:36, 19 March 2010 (UTC)

• Favor (b). I would also move the last two sentences (beginning with "This main page...") to the bottom of the lead, just above the TOC. --RoyGoldsmith (talk) 03:36, 19 March 2010 (UTC)
• (b). Precise details can be discussed, but someting along the lines of "its purpose is to..." seems more useful than "encouraging...", IMO --Jubilee♫clipman 04:07, 19 March 2010 (UTC)

My comments about basic principles such as "reader first" have been misinterpreted - I'm a minimalist both about the "lead" and the content of WP:MOS.

Last time I was awake, RoyGoldsmith's and Darkfrog24's were the only version of "lead", and I rejects Darkfrog24 as a basic as it tried to stray topics that are none of WP:MOS's business, e.g. [[{WP:V]]. While I've been asleep, Tony's and Ozob's have been proposed. Since Ozob's currently has no explanation why we should bother reading MOS, IMO Tony's is the best at present. --Philcha (talk) 06:51, 19 March 2010 (UTC)

• (b), preferring RoyGoldsmith's wording over Darkfrog24's (e.g., "easily readable articles" and "correct language" are vague and off-topic, compared to "follow a consistent pattern and are clear and precise in their language and layout" which is itself precise and hits the mark. PL290 (talk) 08:20, 19 March 2010 (UTC)
• I don't know, I kind of prefer the (a) approach. I wouldn't mind terribly if the full paragraph change were made, though.
  — V = IR (Talk • Contribs) 10:27, 19 March 2010 (UTC)

It still hasn't been established to my satisfaction that we need to add anything to the lead. Of the people who've come to this talk page to ask questions, I don't recall that any ever asked why the MoS was here.

However, if we're going to do it, we should do it right. Consistency and uniformity are not virtues to the extent that correctness is. Incorrect English makes the English Wikipedia look stupid and unreliable and the MoS (with a few exceptions that we've discussed elsewhere) instructs users in correct English to the point where we can say that that is one of its core purposes. More generally, its purpose is to give Wikipedia a professional appearance by showing editors how to write in something like professional-quality English. Darkfrog24 (talk) 12:26, 19 March 2010 (UTC)

It's more a case of taking away from what appears to be a bloated lead. Tony (talk) 12:58, 19 March 2010 (UTC)

I may agree with "professional-quality English", and probably disagree with "professional appearance":

• I've seen comments elsewhere that WP's primary audience is "a bright 14-year old". That would imply English that's clear, concise and correct, but would reject any literary ambitions. I think suggest says, "clear, concise and correct" in the lead.
• If "professional appearance" is simply the same as "professional-quality English" in the sense of "clear, concise and correct", then "professional appearance" is redundant. If it means anything else, that should be explained, and possibly challenged. --Philcha (talk) 13:21, 19 March 2010 (UTC)

I do not mean the same things by "professional appearance" and "professional-quality English." The second is what's actually there. The first is the impression left in reader's minds. The value of a professional appearance is that it raises Wikipedia's credibility.

Professionalism, in this case, doesn't have much to do with literary or artistic aspirations. It's more writing as craft than writing as art. Darkfrog24 (talk) 20:07, 19 March 2010 (UTC)

I'm a minimalist too, in some respects, but this is different. Forget the newcomers—this discussion has shown that even the regulars don't agree what MoS is for. As User:Ohms law said above, "Regardless of anything else, this is always an important question to answer as soon as possible, in some fashion, in any document. Especially for technical documentation." Answering this basic question is important not just to the reader but to to the whole process of creating and maintaining the documentation. How can we ever hope to do that effectively if there's confusion at the most basic level about its purpose? Darkfrog24, if you will look at style guide, you will find it is concerned with uniformity, consistency and formatting. I don't think you'll find it mentions correct English, and I don't think teaching correct English should be the primary goal of MoS at all. PL290 (talk) 13:28, 19 March 2010 (UTC)

Yes, but we're talking about this style guide. Wikipedia has long accepted that uniformity is not always good. We employ more than one kind of English spelling, for example.

The MoS already instructs its readers in correct English. Gender neutrality is correct English. Proper punctuation is correct English. Not capitalizing the names of the seasons is correct English. I'm not saying that the MoS should be expanded into a full language course, but it functions relatively well as a list of pitfalls and problems to avoid. We should accept that instructing editors in correct forms is a big part of what it does. Darkfrog24 (talk) 20:07, 19 March 2010 (UTC)

Comment - we seem to be getting into the whole prescriptivism vs descriptivism thing here. The point, IMO, is not to lay down any grammatical or stylistic laws nor even to describe what "good English" is in a modern context. Our purpose is to explain how WP normally does things, and why, and to explain when and where to make exceptions to this norm. Hence, we do need to explain why the MoS is important, otherwise it looks like we are simply saying "do this or else". Certainly, the entire MoS needs to be overhauled to make this point clear, also, but that is another issue... --Jubilee♫clipman 16:07, 19 March 2010 (UTC)

Asking this question of Jubilee, PL290 and anyone else who wants to answer: Why do you believe that answering this question is important to maintaining the MoS? What do you think will happen differently if it is answered? What problems do you believe exist now that would be solved or mitigated by answering this question? Darkfrog24 (talk) 20:07, 19 March 2010 (UTC)

I think it might help explain your position when dealing with reactions like this one or even this one (although that isn't exactly the MOS), which I encounter frequently when trying to apply the Manual of Style to the rest of Wikipedia. Art LaPella (talk) 22:41, 19 March 2010 (UTC)

User:Dank/Essays#What style guidelines are supposed to be. - Dank (push to talk) 21:11, 19 March 2010 (UTC)

@ Dank, that's an intriguing thesis to you're essay. I'd love to read more that supports the underlying idea! I also agree with the points on how it relates to this discussion.

@ Darkfrog24: Personally, I think that this is aimed more at the users of the MOS, rather then the maintainers. If definitely guides maintenance and further development of the MOS though (or, at least, it should), so the two aspects are probably inextricably intertwined. It seems that PL290 and I are of similar minds on answering the "what problems this solves" question. For maintenance and development, especially in a collaborative development setting such as this, the opening of the document (should) serve as a statement of principle. That we can't easily agree on how it should be structured, let alone what it should say, really ought to serve as a clarion call to all of us that this needs to be worked out to the satisfaction of all. If we can't even agree on how to introduce the subject, is it any wonder that the MOS has a reputation as being the domain of a "Cabal" of assholes?

I don't want to oversell this issue though. As has already been stated, the MOS has gotten to it's current state with an unclear introduction, so it's not as though this is a huge deal. If you think about it though, it is a pretty big deal, and I stand by my position that it causes problems to leave things like they are.
— V = IR (Talk • Contribs) 03:35, 20 March 2010 (UTC)

Wikipedia:Manual of Style (exit lists)/Sandbox has been marked as part of the Manual of Style

Wikipedia:Manual of Style (exit lists)/Sandbox (edit | talk | history | links | watch | logs) has recently been edited to mark it as part of the Manual of Style. This is an automated notice of the change (more information). -- VeblenBot (talk) 02:00, 16 March 2010 (UTC)

Fixed... Imzadi1979 (talk) 02:04, 16 March 2010 (UTC)

Organizations vs. organisations

I'd like to point you all to this current CfD on the spelling of organizations vs. organisations which might well establish a precedence. To clarify my position, I'm in support of using whatever spelling is more widespread within a certain country, and to find a pragmatic solution for the countries where both spellings are just as widespread. IMHO, this is the only way to stay non-POV and to avoid renaming back and forth. Please join the discussion with your expertise, whatever position you might take on this. Thanks, — PanchoS (talk) 12:01, 16 March 2010 (UTC)

The Z is American English and the S is British English British English accepts either Z or S, but S is more popular. Because educational organizations, as a concept, do not have strong ties to either British or American English, each individual article should use the spelling system used by the first major contributor. It is all right if the articles do not match each other. Since the articles are about different countries, there should be little need for conformity anyway. Darkfrog24 (talk) 14:46, 16 March 2010 (UTC)

The discussion is about category names, but I would keep the existing spelling (unless -ise is used on a specifically America-related category) all the same. ― A._di_M. (formerly Army1987) 17:50, 16 March 2010 (UTC)

Agreeing with Darkfrog24. Unless there is an edit war or the talk page has the UK or US English banner, I'd be inclined not to worry too much. The same applies to -yse vs -yze, -or vs -our, -er vs -re, -ogue vs -og etc etc --Jubilee♫clipman 16:29, 16 March 2010 (UTC)

Agreed with Darkfrog and Jubilee. The claims in the above user's treatise are unfounded. There is no precedent being set - this is a simple matter where a new user to Wikipedia created "organizations" categories under head "organisations" categories which have existed for close on 5 years. I speedy renamed them to get them to conform - this is in line with speedy deletion criteria C2C: "A rename bringing a category into line with established naming conventions for that category tree". Nothing already in the category as "z" was changed - not even one - so both will continue to happily coexist as they have done for years. What this user is really unhappy about is unrelated changes I made to other work of his, and it essentially amounts to a case of WP:OWN. Sorry that this has wasted people's time. Orderinchaos 16:30, 16 March 2010 (UTC)

It doesn't matter which part of Oxbridge you're from, if you embrace WP:COMMONALITY. The content in Category:Educational organizations should be pushed down to the lower-tier subcats. Most of what is categorized there would be better under Category:Schools, Category:Educational associations, or Category:Student societies. User:LeadSongDog come howl 18:45, 16 March 2010 (UTC)

You won't find any disagreement with me on that - it does seem a rather bizarre category hierarchy. Orderinchaos 22:01, 16 March 2010 (UTC)

Table headers

M5 Motorway
Region	km	Northbound exits (B Carriageway)	Junction	Southbound exits (A Carriageway)
West Midlands	0.0	The North West, Wolverhampton, Birmingham (North & East), Walsall M6	M6, J8	Start of motorway
	4.4	West Bromwich, Birmingham (North West) A41	J1	West Bromwich, Birmingham (North West) A41
	Rows omitted from table
	254.2	Exeter A379 Sidmouth, Exmouth (A3052) A376 Exeter services	J30 Services	Exeter A379 Sidmouth, Exmouth A376 Exeter services
		Start of motorway	J31	Bodmin, Okehampton A30
		Bodmin, Okehampton A30 Non-motorway traffic		Road becomes A38 from/to Plymouth and Torquay

I would like to get some input on the following from people who are familiar with MOS. (The relevant discussion is at WT:ELG). This would be placed on the article M5 motorway. I'd like to call your attention to the table header - a) do the colors violate any MOS or guideline of some sort? b) If no, is this still the best solution? --Rschen7754 03:22, 17 March 2010 (UTC)

Rschen doesn't mention that the colour conveys the status of the road (white on blue = motorway, yellow on green = primary route, black on white = non primary route). Colour is one of the main ways to identify the status of a road in the UK and it is foolish to ignore this. The colour coding system has been used in this way on these tables for years with no previous issues, though in reality to comply with the various guidelines, text would need to be added to the primary and non primary examples as this would not be conveyed by the existing text in the table cell itself. Something like (Primary) and (Non primary) would suffice in this case. Jeni ^(talk) 03:30, 17 March 2010 (UTC)

If it works for the article, then quite honestly I don't give a damn what the MOS or anything else says. From the explaination that Jeni just gave above, the answer from me is going to be "Yup, looks like a great solution to me".
— V = IR (Talk • Contribs) 04:25, 17 March 2010 (UTC)

The colours are indeed standard for the UK road system. See Road signs in the United Kingdom. It would seem odd to use any other colours! The suggested table above looks fine to me. If in doubt, WP:IAR; or, more specifically, WP:UCS... --Jubilee♫clipman 06:07, 17 March 2010 (UTC)

You might want to have look at the beautiful pictorial form exemplified by Sukhumvit Road or British Columbia Highway 7, originally developed for railways. See a small extract here:

Template:UKrail-headerTemplate:BS-table1Template:BSTemplate:BSTemplate:BS3Template:BS3Template:BS3Template:BS3Template:BSTemplate:BSTemplate:BS3Template:BS3

|} −Woodstone (talk) 14:30, 17 March 2010 (UTC)

With one reservation, I can't see any MOS problems. I've made two suggestions below: one to make the main header in bold type, so that it resembles even better UK road signs, the second to remove the black background from the second line of the header and replace it with italic type. I'm surprised that you don't include miles as well as kilometres for UK roads (possible breach of WP:UNITS), but I think this has already been covered by WT:ELG and miles will be included in the final version (MHO as a Brit is that they should be for UK roads). Physchim62 (talk) 14:11, 17 March 2010 (UTC)

M5 Motorway
Region	km	Northbound exits (B Carriageway)	Junction	Southbound exits (A Carriageway)
West Midlands	0.0	The North West, Wolverhampton, Birmingham (North & East), Walsall M6	M6, J8	Start of motorway
	4.4	West Bromwich, Birmingham (North West) A41	J1	West Bromwich, Birmingham (North West) A41

M5 Motorway
Region	km	Northbound exits (B Carriageway)	Junction	Southbound exits (A Carriageway)
West Midlands	0.0	The North West, Wolverhampton, Birmingham (North & East), Walsall M6	M6, J8	Start of motorway
	4.4	West Bromwich, Birmingham (North West) A41	J1	West Bromwich, Birmingham (North West) A41

The example posted here by Rschen wasn't an example of the recent consensus. Miles are to be included on the left hand side of km and the black header text will be going grey, its just that this hasn't been reflected in the majority of articles yet. Move the region col to the right hand side (though its starting to look like we aren't including it at all) and your proposal is practically perfect :) (Shown below as such, modified to mark the second line of the header as a header (!)) Jeni ^(talk) 14:23, 17 March 2010 (UTC)

M5 Motorway
miles	km	Northbound exits (B Carriageway)	Junction	Southbound exits (A Carriageway)	Region
0.0	0.0	The North West, Wolverhampton, Birmingham (North & East), Walsall M6	M6, J8	Start of motorway	West Midlands
2.7	4.4	West Bromwich, Birmingham (North West) A41	J1	West Bromwich, Birmingham (North West) A41

I hadn't noticed that it was in kilometers! That is a little odd, I agree. Both would be better. I also like the bolding and loss of the black. Mind you the other system used for US and Indian roads looks great, also. Can't decide! --Jubilee♫clipman 02:59, 18 March 2010 (UTC)

*confused* What are you attempting to decide, exactly?
— V = IR (Talk • Contribs) 03:10, 18 March 2010 (UTC)

Ah. Someone above suggest a different design but now I read more closely I see that the issue has been resolved (in the correct place). There's obviously nothing to decide—and there appears to be no real MOS issue, in fact. Sorry for the confusion! --Jubilee♫clipman 03:33, 18 March 2010 (UTC)

Colors are fine given adequate textual hints as to their significance (if any). Consider those who are color-blind, reading a B&W print-out, and/or completely unfamiliar with the system. Doesn′t need a whole mess of it, just a word or two linking to some page that explains the non-obvious. ―AoV² 08:38, 18 March 2010 (UTC)

Proposal for all templates which display coordinates in the title line.

It has been proposed by Stepheng3 that {{Infobox mountain}} use the {{coord}}'s {{{notes}}} parameter to display a link in the title line to a bottom note. See an example here. This discussion is at Template talk:Infobox mountain. It is proposed that this style be adopted by all templates which include coordinates. –droll [chat] 10:26, 17 March 2010 (UTC)

Hyphen question

Which would have an easier time passing FAC, "Queen-Elizabeth-class battleship" or "Queen Elizabeth-class battleship"? - Dank (push to talk) 19:26, 19 March 2010 (UTC)

Ignoring the multilevel trick question (MoS does not define WP:Featured_article_criteria; FA candidates do not "pass" or "fail"—so they say) and concentrating on the hyphens: myself, I put them all in (in this case to make the compound adjective). But I notice people don't always feel they can use more than one hyphen at a time. Not that it comes up that often, so it's difficult to assess the general position. Interested to know if someone rationally defends not fully hyphenating (but unsure that MoS should pronounce on this). PL290 (talk) 19:54, 19 March 2010 (UTC)

I can move the question to WT:FAC if you prefer. Yes, it's an actual conflict in an article headed for FAC, that's why I brought it up. - Dank (push to talk) 20:44, 19 March 2010 (UTC)

No, I didn't mean to imply I thought you should move the question elsewhere. I'll be interested to see what answers it gets. PL290 (talk) 21:16, 19 March 2010 (UTC)

The reason I believe that Queen Elizabeth-class battleship is appropriate is because there is not a hyphen between Queen and Elizabeth in the name of the ship. This issue is here because of a disagreement over this brought forward at this MILHIST A-Class review over the use of {{Sclass}} to link to Queen Elizabeth class battleship. -MBK₀₀₄ 21:49, 19 March 2010 (UTC)

I could go either way. In this case, "Queen Elizabeth" is already a compound unit. It's like not hyphenating "peanut butter sandwich." Maurreen (talk) 22:47, 19 March 2010 (UTC)

The way that I parse the "rules" of using hyphens in English, I'd say that "Queen Elizabeth-class battleship" is most correct. The construction "Queen Elizabeth" is easily recognizable as a proper noun, even if you don't immediately recognize it as a ship's name, simply because we capitalize proper nouns in English. I think that most readers and writers are uncomfortable modifying a proper noun, for pretty good reasons. The space in the name is just incidental, more or less, so it's not really something that should be modified into a hyphen. That's my take, at least.
— V = IR (Talk • Contribs) 03:46, 20 March 2010 (UTC)

Interesting distinction for proper nouns. Also I notice that the italics in MBK's Queen Elizabeth-class battleship visually isolate the first two words as one unit, which helps too if that is the intended rendering. PL290 (talk) 10:36, 20 March 2010 (UTC)

• "MoS does not define WP:Featured_article_criteria"—not exactly, but FAs must follow the MoS, which makes this rather academic. As PL290 says, people don't always like multi-hyphen usage; I count myself among them where it's avoidable. Here, I don't much like Ohms's "Elizabeth-class", jammed together in the middle. Some style guides give the option of an en dash to avoid the use of two hyphens: "Queen Elizabeth–class battleship"; this is an awkward practice, IMO, even if my favourite magazine, Scientific American, sometimes uses it. You want my considered opinion? Don't hyphenate it at all; this is the route that would be taken by most North American editors, and British/Australian usage is not entirely inflexible on the matter: "Queen Elizabeth class battleship". Tony (talk) 09:54, 20 March 2010 (UTC)

  Yes, that's not bad. In principle, dropping the hyphen introduces parsing ambiguity, but in a narrow context with few words like this it's reasonable to rely on the reader to make the correct interpretation (which is the only sensible one). The other approach, as ever, is recast to avoid the issue. (Regarding "FAs must follow the MoS", how many FAC comments have been ignored with the terse rebuff "MoS is not policy", going on to be promoted without that response being questioned? Perhaps not many, but I've certainly seen it happen.) PL290 (talk) 10:36, 20 March 2010 (UTC)

  Actually, I completely agree. If not using a hyphen is an option at all (and, it really should be), then just don't use one. You've gotta admit, "proper" hyphen usage is a pretty esoteric subject. I believe that it's fairly well established these days that you can drop a hyphen almost at will, if it's reasonably clear that there's no ambiguity introduced by doing so. I just avoid them whenever possible, at least.
  — V = IR (Talk • Contribs) 11:14, 20 March 2010 (UTC)

  I actually prefer one hyphen here: Queen Elizabeth-class battleship. The hyphen makes it easy to tell that Queen Elizabeth is modifying class. But as was already noted above, I don't think there should be a hyphen between Queen and Elizabeth. They're already a noun phrase; there's no need to change that noun phrase because it happens to have a hyphen after it. Ozob (talk) 11:53, 20 March 2010 (UTC)

Wikipedia:Manual of Style (road junction lists) has been marked as part of the Manual of Style

Wikipedia:Manual of Style (road junction lists) (edit | talk | history | links | watch | logs) has recently been edited to mark it as part of the Manual of Style. This is an automated notice of the change (more information). -- VeblenBot (talk) 02:00, 20 March 2010 (UTC)

Wikipedia:Manual of Style (exit lists) is no longer marked as part of the Manual of Style

Wikipedia:Manual of Style (exit lists) (edit | talk | history | links | watch | logs) has been edited so that it is no longer marked as part of the Manual of Style. This is an automated notice of the change (more information). -- VeblenBot (talk) 02:00, 20 March 2010 (UTC)

Wikipedia:Alternative text for images is no longer marked as part of the Manual of Style

Wikipedia:Alternative text for images (edit | talk | history | links | watch | logs) has been edited so that it is no longer marked as part of the Manual of Style. This is an automated notice of the change (more information). -- VeblenBot (talk) 02:00, 20 March 2010 (UTC)

Alt text

There's been a fair bit of upheaval in recent days at WP:ALT, resulting in the removal of its guideline status until we work out what it ought to advise. In brief, there were several objections about the length and style of alt text that was being recommended, so a few editors went off in search of expert advice, and one of those experts—Jared Smith of WebAIM—gave permission for his reply to be posted on talk; see here. He wrote that the guideline was fundamentally flawed and offered this article for suggestions. There are other views about alt text too, perhaps opposing, so several editors are now reading up about the issue to try to write a guideline that make sense and which observes industry standards, insofar as there are any. I've therefore changed the alt text section in the MoS to reflect the current state of affairs, [4] but this may change again as we develop an idea of what best practice is. For anyone wanting to see the whole discussion, it begins here. SlimVirgin ^{TALK contribs} 11:53, 20 March 2010 (UTC)