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

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)

I'd like more feedback on my new idea, so here is some actual wording that might be used to implement my suggestion above. It would replace the three numbered items in the en dash section. At this time I'm not proposing that we actually adopt this; I just want to know what people think. (Tony, that means I want to know what you like and dislike about this idea, not just that there's no consensus for this. Of course there isn't yet.)

1. To stand for to or through in ranges (pp. 211–19, 64–75%, the 1939–45 war). Ranges expressed using prepositions (from 450 to 500 people or between 450 and 500 people) should not use dashes (not from 450–500 people or between 450–500 people). Number ranges must be spelled out if they involve a negative value or might be misconstrued as a subtraction (−10 to 10, not −10–10). If either endpoint of the range contains a space, insert spaces on either side of the en dash (5 January 1919 – 21 January 1919, 10 W – 100 kW). Otherwise, do not insert spaces.
2. To stand for to, and, or versus between independent elements (male–female ratio, 4–3 win, Lincoln–Douglas debate, diode–transistor logic, Seifert–van Kampen theorem). An en dash is not used for a hyphenated name (Lennard-Jones potential, named after John Lennard-Jones) or an element that lacks lexical independence (the prefix Sino- in Sino-Japanese trade). In this role, en dashes are never spaced.
3. In lists, to separate distinct information within points—for example, in articles about music albums, en dashes are used between track titles and durations, and between musicians and their instruments. These en dashes are always spaced.
4. As a stylistic alternative to em dashes (see below).

Thoughts? Ozob (talk) 03:07, 23 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)

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)

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)

I'm not convinced that the MoS needs a statement of purpose beyond "this is a style guide for Wikipedia articles". Everyone knows or ought to know what a style guide is and what it does. Once we establish that this page is a style guide, and that this page is about Wikipedia articles, what else is there left to say? Philcha commented above that my proposed text didn't seem to justify why we should reading the MoS. I agree, it doesn't; it says what it is, and if the reader doesn't understand why it's important, I don't think anything else we say will make a difference. Ozob (talk) 12:16, 20 March 2010 (UTC)

Dank--Love the essay.

Art--Thanks. You have established that this is a real problem (though, as Ohms law mentions, not necessarily a very big one) and not an imaginary one. I feel that any change we make to the lead should be aimed at convincing people like that that the MoS is worth their time and energy. I think that the best way to do that would be to focus on its practical effects, such as readability and professionalism.

Ozob--That is what the MoS does now. It says "this is a style guide" with a Wikilink to style guide. I too believe that it's pretty okay as-is, but if we could smooth out a few rough edges with one or two well-turned lines, then why not? Darkfrog24 (talk) 12:33, 20 March 2010 (UTC)

The problem is that we can't even agree amongst ourselves what "style guide" means, let alone what the purpose of the MOS is.
— V = IR (Talk • Contribs) 05:29, 21 March 2010 (UTC)

Actually I thought we were getting pretty close. To get things moving, I've boldly added something along the lines we've been discussing. PL290 (talk) 08:47, 21 March 2010 (UTC)

Tony's already trimmed it to next to nothing, but if we're going to do this at all, we should come out and say what the actual benefit of a manual of style is. "Improves readability," "fosters a professional appearance and mindset," are two of the things that this MoS gives us. The sort of person who'd ask, "Why should I follow that MoS?" is the sort of person who'd be unimpressed with "Consistency." Darkfrog24 (talk) 11:56, 21 March 2010 (UTC)

Yes, exactly!
— V = IR (Talk • Contribs) 12:05, 21 March 2010 (UTC)

• There are plenty of complaints about the size and complexity of the MoS. The previous lead, and a few of the proposals here to a lesser extent, gave these complaints oxygen. What we need is a clear, direct, brief lead. I have no issue with the careful addition of a small amount of text that justifies the MoS, but let's keep in mind that a strong MoS doesn't need to explicitly justify itself; it just is. The box at the top says it all, don't you think? It's too big already. I say get straight into it without ado. Tony (talk) 12:38, 21 March 2010 (UTC)

It's worth working at till we get it right. A statement of purpose, more than merely justifying a document's existence, can help to reduce bloat and complexity by focusing attention on what is and is not appropriate content. PL290 (talk) 13:11, 21 March 2010 (UTC)

• The advantage of Ozob's minimalist offering above is that it neatly side-steps accusations of ideological non-neutrality—accusations that are easy to level at any style guide. I quote below Pullum's list of possible justifications for style guides, of which the MoS might be accused if it is to stick its neck out at the opening and declare what it aims to do in no uncertain terms. The list is from page 7 of his journal article "Ideology, power and linguistic theory"; A. di M. and Hoary have the link to the source of the pdf file; I can't find it at the moment. (Pullum says not to take his off-the-cuff labels too seriously; I've numbered the points and highlighted the labels.)

1. Nostalgia. Justificatory basis: The past glory of some vanished golden age, an imagined linguistic utopia in which people spoke correctly. To avoid: Change — decay and deterioration, either linguistic or social.
2. Classicism. Justificatory basis: The standing of other higher-prestige languages such as Latin. To avoid: Adoption of an inferior form of human language.
3. Authoritarianism. Justificatory basis: Subordination to the established authority of high-prestige masters of the language. To avoid: Social disgrace from using low-grade English.
4. Aestheticism. Justificatory basis: Beauty and aesthetic responses. To avoid: Ugliness and awkwardness.
5. Coherentism. Justificatory basis: Consistency and order of patterning. To avoid: Chaos, randomness, disorder.
6. Logicism. Justificatory basis: Logic in the strict sense. To avoid: Irrationality.
7. Commonsensism. Justificatory basis: Common sense. To avoid: Silliness.
8. Functionalism. Justificatory basis: Efficiency of the communicative function. To avoid: Ambiguity, misunderstanding, redundancy, etc.
9. Asceticism. Justificatory basis: Discipline and self-control. To avoid: Laziness and sloppiness.

BTW, this is the writer who refers to "Strunk and White’s toxic little compendium of bad grammatical advice, The Elements of Style,..." (same page). Hehehe!

My point, again, is that we do not want to expose the MoS to nit-picking by those who might object to whatever is announced about intentions/aims/ideals at the top. Better not to indulge in such announcement in the first place. Tony (talk) 13:51, 21 March 2010 (UTC)

Pullum's article (which I warmly recommend) is here. -- Hoary (talk) 14:26, 21 March 2010 (UTC)

Then we should MFD all of the MOS pages, and prevent their recreation (a course of action which I wouldn't be entirely opposed to...). That ship has sailed though. Trying to hide from such criticism by avoiding defining what the MOS is is hardly effective, let alone beneficial. The fact is that our current manual of style is subject to the "ideological non-neutrality" regardless of this issue, so I dispute "The advantage of Ozob's minimalist offering above".
— V = IR (Talk • Contribs) 14:42, 21 March 2010 (UTC)

I haven't looked at Pullum's article, but from Tony's summary above, I question what point exactly is being made if we are to consider that (5) and (8) exhibit "ideological non-neutrality" or something of which the MoS might be "accused". Anyone in favour of chaos, randomness, disorder, ambiguity, misunderstanding, or redundancy presumably rejects the notion of a house style guide in the first place, let alone the notion of a global community working together to communicate information. Let alone the notion of an encyclopedia. Side-stepping the issue does not make it go away. PL290 (talk) 15:44, 21 March 2010 (UTC)

I don't think the sort of person whom Art LP has pointed out as our target audience on this matter would be much impressed with Pullum. If we speak at all about the purpose of the MoS, it should be briefly and plainly, focusing on what real benefit the MoS brings to the readers and editors. "Consistency" would just bring the reply, "That just means that they're telling us what to do for no real reason," unless we point out how the MoS can improve readability. Darkfrog24 (talk) 15:57, 21 March 2010 (UTC)

Yes, but they're not the only people in the audience. Point taken that the statement should endeavour to bring those people on board, but there's no conflict between that the other aims being discussed. Let's produce a statement that meets all our aims. PL290 (talk) 18:38, 21 March 2010 (UTC)

Being bold, I've just changed the word "style" in the lead ("...consistent pattern of style and formatting"), which I believe is wishy-washy and circular, to "English usage". I've also fixed some grammar and added the word "please".

Does anyone else have anything more to say about why an MOS is important? Or should we consider the section closed? --RoyGoldsmith (talk) 01:31, 24 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)

  Agreed with many of you that this is a little awkward and workarounds are better when they're available. When they're not available, now I'm agreed with Tony and Ohm's Law, I'd prefer to avoid hyphenating this at all, if that's acceptable to SHIPS and MILHIST editors. - Dank (push to talk) 16:04, 20 March 2010 (UTC)

  It is definitely agreeable (at least to me), the template in question: {{Sclass}} is even set up to do just that. Instead of {{Sclass|Queen Elizabeth|battleship}} which produces Queen Elizabeth-class battleship, use {{sclass|Queen Elizabeth|battleship|6}} which produces -MBK₀₀₄ 23:59, 20 March 2010 (UTC)

You could also consider "Battleship in the Queen Elizabeth class". Maurreen (talk) 05:36, 21 March 2010 (UTC)

Absolutely. Btw, the reason the sources aren't helping us out a lot here is that many of them would write this as "the Queen Elizabeths". That's tempting, but we've avoided this for the most part on Wikipedia, and I think it's because it just doesn't sound like good English; you don't write "the Endeavors" if what you mean is "all the space vehicles similar in some way to the Endeavor". If there's not a word for that class of vehicle, then we generally make one up (the Space Shuttles). - Dank (push to talk) 14:05, 21 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)

I support your edit to WP:MOS ... and God/gods bless you! - Dank (push to talk) 15:05, 20 March 2010 (UTC)

Ha ha, thank you. I've just told someone off on another page for invoking God, but I'll accept the blessing. :) SlimVirgin ^{TALK contribs} 16:19, 20 March 2010 (UTC)

That is an appropriate and clear summation of events. Is a similar update going to happen at WP:FACR as WP:ALT is current noted in the attribute on images. Regards, SunCreator (talk) 17:20, 20 March 2010 (UTC)

I've posted at WT:FAC here, which is busier than WT:FACR, but I'll post a link to the latter too. SlimVirgin ^{TALK contribs} 18:01, 20 March 2010 (UTC)

I've boldly made a few changes too. I reorganized the material so that it was in a more logical order (in my view!). The biggest change has been to change "editors are encouraged to" to stating that images should have alt-text (of some sort or another) because of what happens otherwise on screen-readers. This is partly because the formulation ("editors are encouraged to") appears out of step with the general style/tone of the MOS page, and partly because my reading is that that there is general agreement that we want to assist those who use screen-readers and agree that specifying some sort of alt-text attribute is necessary for this. What we aren't clear about, yet, is what the content of the alt-text attribute should be. For the content part, I think the emphasis on editorial judgment and the range of possible choices (caption/reference to text/short description/|link etc) is a good description of our current state of knowledge, and gives editors appropriate scope to choose any of the options given. --Slp1 (talk) 17:32, 20 March 2010 (UTC)

Your changes look good to me. By the way, I should add for anyone who wasn't involved that it was Slp1 who obtained the information from Jared Smith that I think is going to set us on the right road eventually, so kudos to her for putting in that extra work. SlimVirgin ^{TALK contribs} 17:59, 20 March 2010 (UTC)

My only real question to this is, what's up with the |alt=|link= stuff? Why are we making the MOS dictate the use of a bunch of pointless null parameters? If you don't use a parameter within a template or a link, it should just be unused rather then entered with a null value.
— V = IR (Talk • Contribs) 05:25, 21 March 2010 (UTC)

I think it is like this because of how the Wiki software deals with image links. See the bottom of this section which contains something of an explanation of the issue.[5] --Slp1 (talk) 14:13, 21 March 2010 (UTC)

Did everyone miss Eubulides' reply at the very end of that discussion? He's essentially saying the same thing as I am, here.
— V = IR (Talk • Contribs) 14:33, 21 March 2010 (UTC)

As far as I can see, he's responding about a question about reading the captions, not how to make the screen reader skip the image altogether, which is the goal of the code |alt=|link= But I'm no techie so I may be getting this wrong.Slp1 (talk) 14:39, 21 March 2010 (UTC)

Maybe there is a technical issue right now, but recommending the use of null parameters is just bad. if the use of |alt=|link= is really a requirement, then that needs somewhat urgent development attention.
— V = IR (Talk • Contribs) 05:44, 22 March 2010 (UTC)

Removed a small para in Engvar

Under "Strong national ties", a paragraph I'd never noticed was doing no particular service to readers' understanding:

This avoids articles being written in a variety that is inappropriate for the great majority of its readers. For example, Australians reading the article Australian Defence Force or Americans reading American Civil War should not stumble over spellings or constructions not used in their own variety of English.

The grammar of the opening is clumsy; the paragraph repeats examples that are listed above it; it makes a questionable assumption that only Australian readers matter in Australia-related articles, etc., that, for example, "the great majority" of readers of articles related to South Africa are those who speak South African English (says who?), and that English-speakers "stumble" over the minor differences in spelling and lexis between the varieties.

The section is quite long enough without this additional paragraph; was it there as a defensive justification of our highly successful engvar guideline? Why was it added? If anything, it provides ways of criticising the guideline more than explaining or justifying it. I've removed it. Tony (talk) 12:54, 21 March 2010 (UTC)

Good. PL290 (talk) 13:10, 21 March 2010 (UTC)

I know that this will go over like a lead balloon, but we should just dump the whole ENGVAR thang. I'm firmly of the opinion that it does more harm then good. (oh ya, this is a decent change though.)
— V = IR (Talk • Contribs) 13:43, 21 March 2010 (UTC)

What harm does it do? ― A._di_M. (formerly Army1987) 20:48, 21 March 2010 (UTC)

It currently makes the Main Page say "France win the 2010 Six Nations Championship" for instance. It would go over like a granite balloon (lighter than lead) if you proposed an alternative. No guideline at all, and presumably a lot more arguments about U.S.-centrism? U.S. English only? What? Art LaPella (talk) 22:07, 21 March 2010 (UTC)

We need to either 1. pick just one variety of English for the whole English Wikipedia or 2. have some system for deciding which articles are written in which variety. If someone can come up with a better idea than ENGVAR, we should certainly hear it out, but I've yet to see one. ENGVAR isn't perfect, but we can reasonably assume that there are fewer fights with it than if we had no policy at all, and it shows respect to the diversity of the English language and English language usage among Wikipedia editors.

...how is it that ENGVAR mandates that the main page say "France win the 2010 Six Nations Championship"? I'm afraid I don't follow you there. Darkfrog24 (talk) 22:54, 21 March 2010 (UTC)

ENGVAR allows British English, and arguably prefers British English when discussing Europeans (who study British English in school, I'm told) playing a British game. If "France win ..." (which of course sounds like a typo to Americans) isn't British English, then that will be a surprise to WP:In the news regulars, where that issue comes up regularly with each non-American sports announcement, and is considered a long-settled issue. Art LaPella (talk) 23:27, 21 March 2010 (UTC)

I imagine at some point there will be a technical solution so that the page rendering determines if the reader requires British-English or American-English and the article will have some sort of option. Google determines your language setting already. So it's quite possible. Regards, SunCreator ^(talk) 23:13, 21 March 2010 (UTC)

Picking just one variety would really be worse then the current situation. It'd drive some people away, if nothing else. More importantly though, since Wikipedia encompasses a worldwide audience, picking just one variety would stifle the continuing development of the language itself.
— V = IR (Talk • Contribs) 05:42, 22 March 2010 (UTC)

The main page is bound to mix varieties of English. One article will say "France win the Championship", another will say "France wins the title". If both articles happen to be featured that day, both versions of that construction end up on the Main Page. I don't see a problem here: it is a very minor issue, IMO; in fact, it might even be a good thing since it makes the Main Page neutral as regards language. In actual articles, ENGVAR is the best we can do, I suspect: we cannot impose one style of English on any group of editors so we have to compromise. Software that automatically rewrites pages according to your locality would be helpful but 1) it would take control away from real people, 2) it would need to be very intelligent in design, 3) quoting from one version in any talkpage might be a problem for users of the other version. Regarding #2: the software would have to allow for bad grammar and allow for a mix of styles; any bad grammar might throw it and a mix of styles might also throw it etc. Can't see how we can ditch ENGVAR for a while, yet --Jubilee♫clipman 23:42, 21 March 2010 (UTC)

It would only apply to articles. I envisage a user setting either in preferences(if your logged in)/browser setting/IP(if your not) that is set to either British or American. And that the articles says "France {{LanguageVar|british="win the Championship"|american="wins the title"}}". Same with words in sentence {{LanguageVar|british="colour"|american="color"}} etc. Regards, SunCreator ^(talk) 00:02, 22 March 2010 (UTC)

You mean you have to use a template for every occurance??? Or have I misunderstood? --Jubilee♫clipman 00:04, 22 March 2010 (UTC)

Not for common stuff. So my bad example of colour/color could be automatic and not a tempalte, but advanced stuff where grammar is involved like France Win/Wins then yes you'd add it specifically with a template. Regards, SunCreator ^(talk) 00:10, 22 March 2010 (UTC)

Suggestion

My complete rewrite suggestion for ENGVAR would be something like:

There are many varieties of spelling in the English language, and Wikipedia intentionally does not favor (nor does it favour) any particular system over another. Articles should be written to be internally consistent, so regardless of what form of spelling is used be sure to use it throughout the article (The accepted style of punctuation is covered in the punctuation section, above.) Articles should not be edited specifically in order to change spelling, and edit warring over spelling choices is considered to be disruptive; editors should feel free to adjust and correct spelling where needed, however.

Strong national ties to a topic

Certain topics naturally lend themselves to specific national varieties of English. Those topics which are clearly tied to certain varieties of English should be written in, or changed to, the variety of English most appropriate. Therefore, the spelling within American Civil War should always be American English, while the spelling within Parliament of the United Kingdom should always be British English.

Opportunities for commonality

(Essentially unchanged)

That's sorter, and slightly more permissive, while keeping the basic stricture against edit warring over spelling (which I can't imagine anyone wanting to refute).

The problem with the current ENGVAR, for me, has actually always revolved around RETAIN. Everyone offers it as a means of avoiding conflict, but in practice I've noticed it used more as a club, to "win", rather then something which actually helps. I realize that the current version of ENGVAR is derived from ArbCom cases, and other serious conflicts which have arisen over spelling. I don't think that we should loose that knowledge, which represent hard won gains from attempts to resolve such conflicts. The problem is, the current "solution" simply isn't a solution at all, as it causes its own conflicts by its very nature.

The other big issue that I see is that our current ENGVAR works to slow the ongoing development of the language itself, at least within our little corner of the world here on Wikipedia. Wikipedia acts as a worldwide platform for the development of the written word. Given the prominence of the website, the fact that we've chosen to forcibly segregate the varieties of English works at odds towards the ability for us to seek out ways to both bring together, and even potentially create new, varieties of English. Segregation is never the answer to these sorts of problems.

Closer to home, ENGVAR (specifically RETAIN) strikes me as the antithesis of attempts to foster a collegial atmosphere, which is a position set out in the Five Pillars. I think that it's a perfectly legitimate argument to say that RETAIN fails to meet the goals of the fifth pillar ("Wikipedia does not have firm rules."), and actually works at cross purposes towards supporting the fourth pillar ("Wikipedians should interact in a respectful and civil manner.").

I'm not really sure why I'm bothering to put so much into this right now, since it'll never change, but that's my suggestion and those are my arguments.
— V = IR (Talk • Contribs) 05:37, 22 March 2010 (UTC)

Ohm, it is absolutely not Wikipedia's job to push artificial changes in the English language. What you describe as "ongoing development" is far more likely in practice to be what a bunch of Wikipedia editors decide that they like more than standard English. Language-wise, Wikipedia should go with the flow but not redirect the river.

Your suggestions aren't bad, but they could be streamlined:

There are many varieties of English, and Wikipedia does not favor (or favour) any particular variation over the others. Articles should always be internally consistent, so each article should use just one form of English throughout. Never edit an article solely to change the spelling from one form of correct English to another (center to centre or vice versa). Edit warring over spelling choices is considered to be disruptive. When deciding which form of English to use in an article, consider the article's topic. Those topics that are clearly tied to certain varieties of English should be written in or changed to that variety of English. Therefore, the spelling within American Civil War should always be American English, while the spelling within Parliament of the United Kingdom should always be British English. When the article topic has no clear connection to any variety of English over the others, [insert solution here].

We do need to add something for what to do about topic-neutral articles like orange (color) etc. There was a big ruckus about one of the colors a while back. Otherwise, people will reach and reach until they find some way to connect any topic to any variety of English. Darkfrog24 (talk) 13:00, 22 March 2010 (UTC)

It's not Wikipedia's job to get in the way of such development either, which is my main point. Wikipedia is artificially preventing change, currently (through RETAIN, primarily). Besides, define "standard English". If there really were a standard, we wouldn't be having this discussion. Not that I'm surprised to hear this, since this sort of prescriptivist attitude is actually fairly prevelent (especially here on Wikipedia, unfortunately).

The thing is though, I like your streamlined version. I wrote mine off the cuff, so it could definately use some polish regardless. The main point that I'm trying to make is that "[insert solution here]" should simply be "do what comes naturally to you".

I get the feeling that the main concern, of those who support the current version of ENGVAR, is simply a worry that British English and other varieties will disappear from Wikipedia. While I can understand and sympathize with such concerns, its just not a persuasive argument, to me. I don't want any particular form to be lost (unless we really do collectively choose to lose it), but i think that trying to actively fight against that possibility does more harm then good. I guess that I don't have a really strong argument myself, but I stand by my basic position that the current solution does more harm then good.
— V = IR (Talk • Contribs) 14:32, 22 March 2010 (UTC)

"Never edit an article solely to change the spelling from one form of correct English to another" might seem to suggest that if an article is consistently written in BrE except that one of five occurrences of "centre" is spelled "center", I should not change it to "centre". While the second sentence shows that this is not the case, I'd prefer a clearer wording, if I could find one. ― A._di_M. (formerly Army1987) 13:21, 22 March 2010 (UTC)

Humm... I don't dismiss this sort of concern, but I don't see how that could be misread that way. That makes it hard to offer a suggested remedy. I'm not sure how much effort it's really worth to put into this either, since I really doubt that any significant change such as we're discussing here will be possible.
— V = IR (Talk • Contribs) 14:32, 22 March 2010 (UTC)

My 2 cents/pence.

1. Articles should not be edited specifically in order to change spelling: obviously, this refers to varieties (color/colour) but it reads as a prescription against copyediting articles to change "recieve" to "receive" or "teh" to "the", ect. [= "etc"...]. The second version of this is better, therefore.
2. Wikipedia intentionally does not favor (nor does it favour) any particular system over another: this already favo(u)rs one variety and relegates the other to a parenthetical aside. Wikipedia intentionally avoids promoting any particular system of English might work better.
3. Wikipedia acts as a worldwide platform for the development of the written word: no, it acts an encyclopedia. Period. Any development of language is incidental to all forms of communication unless the language itself is artificial or controlled e.g. Esperanto, Basic English, etc. Thus, no publication or group can be said to act as a worldwide platform for the development of the written word exept perhaps in the form of a report or study e.g. Evolutionary linguistics. (As an aside, the article Written language is terrible!)

My concern is not that BrE will be disappeared by AmE but rather, as Ohms law et al., that all varieties are valid and have their place. Commonality is better across the board, IMO; however, is there a common word for colo(u)r...? Bit of a sticky one that! (FWIW, orange (color) probably ought to be at orange since every other use of the word (including the name of the fruit) probably stems from this meaning ultimately. The dab should be Orange (disambiguation). That's a side issue though, of course!) --Jubilee♫clipman 16:31, 22 March 2010 (UTC)

Actually is the colour which is named after the fruit, not the other way round.[6] The colour used to be called "yellowish red" or the equivalent thereof in the English of the time, and I've even read some speculation that Newton might have promoted the use of orange as a homage to William of Orange (will provide a ref for this when I'm back home)(see below). Anyway, that's irrelevant to which is the primary meaning today, and [7][8] ― A._di_M. (formerly Army1987) 17:17, 22 March 2010 (UTC)

Hm. Something new every day! Thanks for that info. It is a side issue though, indeed --Jubilee♫clipman 19:20, 22 March 2010 (UTC)

It's in Cosmical Imagery by John D. Barrow, footnote 11 to part 4. My attempt to a back-translation from the Italian translation: "There's a thesis according to which orange was added by Newton between red and green in memory of one of his protectors, William III, Duke of Orange, who had died two years before the publication of Opticks. The term was not in common use to describe the colour. Orange is also a city in the South of France. Elsewhere, Newton refers to this colour as "citrus", or "yellowish-red", when he describes its formation by the interference fringes in "Newton's rings". The inclusion of orange in the spectrum may also have had the aim of bestowing a particular credit to the political cause associated with William of Orange." ― A._di_M. (formerly Army1987) 20:38, 22 March 2010 (UTC)

FYI: the spelling differences which cause the spelling of colo(u*)r to change, are directly attributable to our buddy Noah Webster. Since he was American, the spelling differences tend to be characterized as an American-izm, but I've always sided with the opinion that the intent was for the spelling revision to be universal (which is supported by Webster's own statements). The point though is that Webster's spelling revision is an excellent example of why ENGVAR type rules are a bad deal for English. The language has always been permissive on these sorts of issues. We have no central authority, we easily create brand new words for new ideas (where, from what I understand, other languages tend to favor reusing words I don't really know, since I've never been able to actually learn any other languages, damnit!), and worst of all we take on loan-words from other languages all the time! For example, is "Wierd" actually wrong? Really, why should it be incorrect? Why couldn't the "i before e" rule actually be a rule? I mean, if we collectively decided; if we actually decided to say that Weird should be spelled "Wierd", then it just would be. (Incidentally, I just looked, and we actually have an article at English spelling reform)

I'm getting all long-winded here, but what I've been getting to is this: Wikipedia already works this way normally. We say "anyone can edit", and we specifically allow anyone to have access to the edit function (most of the time...). The only place that this currently isn't true is when it comes to varieties of English, where we've set this system up to where the first editor to actually make any choice "wins", and everyone else has to play by that persons rules. RETAIN is an anachronism on Wikipedia, which is why it bugs me.

You're right though, in that the language within this particular proposal is a bit inadequate. If there's actual support for a change here, then I'll very gladly work on tightening it up into something that could actually go into policy. I'm just not going to expend the effort on something that isn't going to go any where. I'm somewhat surprised that this discussion has developed this much, and having a bit of fun actually talking about this in a collegial manner, but... is it really going anywhere?
— V = IR (Talk • Contribs) 21:15, 22 March 2010 (UTC)

Suggestion 2: trim WP:RETAIN

Personally I think WP:ENGVAR is basically fine. We're not going to get agreement to impose one universal variety (unless, of course, we choose my variety!) and to do so wouldn't achieve anything worthwhile; this is life's rich tapestry in our global community. But I do agree WP:RETAIN is problematic, and does get used as a club to "win" for the wrong reasons. I think that simply by making more than the basic statement, it creates more problems than it solves. I propose we delete all except for the first sentence:

Retaining the existing variety

If an article has evolved using predominantly one variety, the whole article should conform to that variety, unless there are reasons for changing it based on strong national ties to the topic. In the early stages of writing an article, the variety chosen by the first major contributor to the article should be used. Where an article that is not a stub shows no signs of which variety it is written in, the first person to make an edit that disambiguates the variety is equivalent to the first major contributor.

PL290 (talk) 08:05, 22 March 2010 (UTC)

• There is nothing wrong with the current section, which has worked superbly well. Remove the "Retain" subsection or the point about the variety chosen by the first major contributor, and we'll have edit wars breaking out. The guideline must continue to provide automatic solutions where editors might disagree on this matter. Tony (talk) 08:56, 22 March 2010 (UTC)

  Agreed. We've got to have something there. In the sciences, they say that a good theory is the theory that holds together long enough to get the research team a better theory. WP:RETAIN will do until something better comes along. Darkfrog24 (talk) 13:02, 22 March 2010 (UTC)

  I'd argue the "worked superbly well" characterization. As a matter of fact, I did argue exactly that; and I see that PL290 has as well. That being said, I do agree that we should keep what we have until something actually better comes along. I'm certainly not seeking chainge for it's own sake. I like the basic idea here though, in that tweaking or "streamlining" RETAIN could be beneficial.
  — V = IR (Talk • Contribs) 14:37, 22 March 2010 (UTC)

• I'd like a provision added to "retain" that an article can change varieties if there is a very clear agreement - with some sort of supermajority in a formal vote - among the contributing editors to do so. Some articles get stuck in a variety from a stub, despite what the rules say. It is in fact rather difficult for most editors to write in the variety that is not their own, as User:Awadewit often complains. I notice, btw, that RETAIN only seems enforced for US or UK English. If someone started an article on a colour or chemical compound in Indian English, it would be unlikely that others would (or could) follow. Johnbod (talk) 15:03, 22 March 2010 (UTC)

  I've actually seen people argue, seemingly with a straight face, that there was no such thing as "Indian English". This is a whole other aspect of the harm that RETAIN inadvertently causes. It fosters a battlefield, capture the flag style, attitude among some. That's what leads to some thinking that there is an AmEng vs. BrEng competition going on.
  — V = IR (Talk • Contribs) 15:29, 22 March 2010 (UTC)

  I agree. Dialects are not the issue to be resolved here, otherwise we get into Scottish English, Jamaican English, etc... The two main varieties of English really are BrE and AmE, AFAIK --Jubilee♫clipman 16:48, 22 March 2010 (UTC)

  There is an Indian English, but it's not a native English variety; nowadays, there are many fewer people for whom English is the primary languange in India than (say) in Singapore. As far as the formal written language (whose regional variations are much smaller than those of colloquial speech) is concerned, to a good approximation there are an American English variety and a Commonwealth English variety, but that's not an exact picture: for example, in Canada terms in some fields are typically spelt the US way and in other fields the UK way, and there are differences e.g. in legal vocabulary between England and Scotland. Nevertheless it is quite possible that a middle-sized or long article is simultaneously both "valid" New Zealand English and "valid" Irish English, for example.

  Anyway, if I came to article and see that it happens to be written consistently in BrE except that one of four occurences of "colour" is spelt "color", I just change that one; I don't recall anyone ever complaining for that. The passage with strikethrough above, taken literally, would instead incourage me to dig through the article history and check which way it was originally written, which I think it's a thing most people would rather not bother to do. But maybe we can let WP:UCS allow that in cases when there are no edit wars, and keeping the text being discussed for cases when edit wars do arise. ― A._di_M. (formerly Army1987) 20:35, 22 March 2010 (UTC)

  The trouble is, while you're right that most people won't be bothered, it only takes one. Since that person has policy "on their side", there's really nothing to be done about it if someone does that. I've seen it actually happen too, and I'm here to tell you that it's really demoralizing. There's one prominent article, which I have a ton of interest and knowledge about, which has been captured this way, forced into what I feel is an unnatural dialect. The person responsible even got the article approved as a "featured article" as well (*Rolls eyes*). Like I said, it only takes one person to gum up the works.
  — V = IR (Talk • Contribs) 21:23, 22 March 2010 (UTC)

As it looks like staying, and I can understand the reasons given, it may help to clarify one aspect: I think part of the problem is that it's easy to miss the significance of the first few words of the part struck out above, "In the early stages of writing an article". Those words are, I think, intended to identify a special case, i.e., the initial time when the article has precisely not yet evolved to any degree, and is perhaps small in size and may not yet contain any words like "color" or "colour". That fact can be quickly lost as the reader's focus switches to understanding the rules for identifying the first major contributor. In the cases I can think of where RETAIN has been wielded unfairly—which are admittedly few, and in those cases it came to nothing—that is exactly what seems to have happened: the article was well-established, having evolved over time into its current state, yet an ancient contributor was wheeled out and this clause cited. So it may help to rejig things to make this distinction clear. On a related note, the very first words, "If an article has evolved using predominantly one variety" are themselves problematic, since there's unlikely to be any "if" about it (nor should the MoS imply that evolving in any other way would be a normal state of affairs). PL290 (talk) 22:21, 22 March 2010 (UTC)

How about "Wikipedia does not have an official variety of English, but rather allows articles to be written in any valid variety, so long as each article is written in only one variety." Also, we should specifically mention, if only in passing, one variety of English that is neither British nor American. Darkfrog24 (talk) 00:28, 23 March 2010 (UTC)

• Having read the thread above, I feel it's necessary to point out the binary division that has been established in both engvar and the guidelines for date format: "the club" comprises the ancestral native-English-speaking countries, of which there are seven: the US, the UK, Canada, Australia, Ireland, New Zealand and South Africa. There are small proportions of native English-speakers within the populations of other countries, notably India, Liberia, Singapore, and HK, but they are not included. On the flipside, there are sizeable proportions of the populations within "the club" who are second-language speakers. Nevertheless, "the club" has been established on WP because editors from those countries are likely to get emotional about their own variety of English and/or date format. Editors from India, for example, usually don't give a toss about it, although wholesale changing of the spelling or date format in India-related articles probably wouldn't be welcomed by a lot of editors—nor the project as whole, which aims for stability, inter alia. Engvar and our date-format guidelines keep the peace very well and have been highly successful in largely ending the edit-wars that characterised the first few years of WP's existence. Tony (talk) 07:23, 23 March 2010 (UTC)

  I can agree to that sort of distinction, as long as nobody takes it to mean that "there is no Indian English", which I've seen occur, as I said above. The logic behind distinguishing "the club" makes intuitive sense to me, though. My only observation would be that Indian editors likely "don't give a toss about it" more due to the fact that Indians are generally more accepting of multiculturalism than most Westerners. We could learn a few things from India, and Indians.

  To be blunt though, I just don't buy into the idea that our current policies in this area have "kept the peace". I know that you have been heavily involved in at least the date formatting issue Tony, so it's perfectly reasonable for you to be taking this position. I'm not out to... I don't know, "out maneuver"(?) you on this, or anything like that. My only point is that we're not "keeping the peace". Over the last couple of years we've slowly created an atmosphere where any meaningful opposition to RETAIN, date-formats, or other similar issues has been shut out. That these issues reached ArbCom, essentially forcing the current language to exist in these areas of the MOS is, quite frankly, a disgrace. We should be better able to work with each other, rather then seeking out these sorts of "solutions".
  — V = IR (Talk • Contribs) 08:55, 23 March 2010 (UTC)

  It was date autoformatting that went to ArbCom, not the matter of which format should be used in which article; until early 2008, we had no guideline on that at all. Then one was developed at MOSNUM, based largely on engvar. BTW, DA was preventing logged-in editors from realising that there was an unholy mess of within-article inconsistency and inappropriate choices (e.g., dmy for NASA and even one of the 9/11 sibling articles, I discovered; I even switched one yesterday, for a US TV show—at least now we can see the faults that our readers see). Anyway, that issue is resolved. Do you perceive that engvar still causes trouble? Tony (talk) 09:41, 23 March 2010 (UTC)

  See though, this is exactly the problem with having ArbCom dragged into issues such as this. Of course you're correct that the actual case involved autoformatting. The reality though is that ArbCom decisions have far reaching impact, and so their "limited" decisions are hardly limited at all (something which even ArbCom has a tough time grasping, it seems). Their formatting decision is seen as a general prescription regarding date formatting, to most.

  The real problem here is that we need to understand that the MOS, and most policy in general, are seen as being useful for last resort appeals to authority, to most editors. For better or worse, the vast majority of editors simply ignore the MOS and policy, and do what comes naturally to them. Wikipedia was actually set up to encourage that sort of behavior, and despite the problems that it does cause it actually pays dividends. So, the problem that things such as adding RETAIN to ENGVAR cause is that we end up with situations where people blithely make contributions, in good faith that their actually helping, and end up being sideswiped by unusually forceful policy. I hope that it's apparent that I don't necessarily disagree with the principles behind these issues, it's simply the manner in which their being implemented which is problematic.
  — V = IR (Talk • Contribs) 10:08, 23 March 2010 (UTC) [Copied and continued on Ohms's talk page, since the dialogue seems to have strayed from WT:MOS's scope. Tony (talk) 11:02, 23 March 2010 (UTC)]

I am of the opinion that because people treat the MoS like a set of hard rules, we should take this into account whenever we add or remove anything from the MoS. On something that subtle, it's a lot more realistic to work with people's in-practice behavior than to try to get them to change. Darkfrog24 (talk) 12:31, 23 March 2010 (UTC)

I agree with your first point; your second point revolves around "realistic"; are you being defeatist? I certainly don't agree with such a strategy. Tony (talk) 13:18, 23 March 2010 (UTC)

It's only defeatist if we have a mission to change the view of the MoS as providing hard rules. We don't. I'd say that the MoS does have a mission to correct behaviors such as, say, capitalizing the names of the seasons. I certainly wouldn't tell the MoS to give up on that. But it is something that can be clearly characterized as desirable vs. undesirable and it isn't something so subtle as an attitude. Darkfrog24 (talk) 17:12, 23 March 2010 (UTC)

I agree that ENGVAR should only apply to native English varieties, but Tony's list seems weird to me... 8.2% of South Africans in 2001 (compared to 23.0% of Singaporeans in 2000 and 29.4% of Singaporeans in 2005) speak English at home, so how comes South Africa is in and Singapore is out? And why are Jamaica, Trinitad and Tobago, Guyana etc. out? English is the only official language there, and while local creoles might be more common in speech in informal settings, so is Scots in Scotland... We could say "ties to a particular natively English-speaking nation" even without listing those nations. ― A._di_M. (formerly Army1987) 15:52, 23 March 2010 (UTC)

I was going to say the same thing. The omission of Jamaica and Guyana jumped out at me, but I know quite a few people whose families come from those countries. But they are countries with small populations, so their impact on the worldwide English language is lessened.

I can excuse the Singapore omission a bit, because its a fairly small country, and only a portion of the populace is natively English-speaking, so the overall numbers of English speakers there is a small number of the worldwide total of English speakers. In contrast, the native English speakers in South Africa are roughly equal to the entire population of Singapore, English and non-English speaking. And thats not counting those who use it as a second language (as opposed to at home). oknazevad (talk) 17:56, 23 March 2010 (UTC)

Well, if you count the total number of native English speakers, the Philippines have about as many as New Zealand. Any such list of nations would require criteria at least partially arbitrary. ― A._di_M. (formerly Army1987) 08:37, 24 March 2010 (UTC)

Wikipedia:WikiProject Visual arts/Art Manual of Style

This has been in Category:Wikipedia style guideline proposals for some time now. It has been worked on by several people at Wikipedia:WikiProject Visual arts since it was begun in 2005 and is now pretty stable. I would like to add it to the "official" list, and will do so if no one objects. Of course improvements, suggestions or comments on specific points are welcome - please use the talk page there. Johnbod (talk) 13:50, 21 March 2010 (UTC)

Ellipsis

Please change this page to recommend using … instead of .... The three periods is wrong. Despite what it says here, the … symbol is not too hard to read in squished fonts and it is easy to input (alt-semicolon) --198.103.172.9 (talk) 14:31, 22 March 2010 (UTC)

You must be a teen. The "…" character is nearly impossible for me to see. Why does it really matter, anyway? It's easier to simply enter three '.'s anyway.
— V = IR (Talk • Contribs) 14:39, 22 March 2010 (UTC)

And what advantages does "…" have over "..."? ― A._di_M. (formerly Army1987) 14:42, 22 March 2010 (UTC)

The same advantage that X has over >< and W has over VV and and O has over (). It's the right character. --198.103.172.9 (talk) 14:49, 22 March 2010 (UTC)

An ellipsis is three periods, so "..." are the correct characters for it. The "…" character is not standard on keyboards nor is it included in the list of symbols supplied by the wiki software when you edit a page (as far as I can tell). I had to copy it just now from the title of the section. How would I insert it without doing that? --Jubilee♫clipman 15:42, 22 March 2010 (UTC)

Quotes are double apostrophes and Ws are double Us, but we still use the right symbols for those. An ellipsis is typed by alt-semicolon. It's right on the home-row, and a lot easier to type than en and em-dashes or degree symbols, which Wikipedia does use. --198.103.172.9 (talk) 16:22, 22 March 2010 (UTC)

On my keyboard, it doesn't. Also, " and W are in ASCII, and they look very different than '' and VV in most fonts, unlike ... and …. ― A._di_M. (formerly Army1987) 17:03, 22 March 2010 (UTC)

Nope... I have tried alt-; alt_gr-; ctrl-; and ctrl-alt-; all to no avail. Maybe an American Keyboard thing?

A double apostrophe has a special meaning in wiki software; indeed, A. di M. had to nowiki it in the above... Technically, it should be UU and uu for W and w... but that is beside the point: the name is traditional and no one writes two u's or v's for a w. Same goes for X/x and ><. 0, o and O are different, of course, but no one writes () or Q or anything else for those except on MySpace and FaceBook. I, l and 1 are also to be differentiated for obvious reasons --Jubilee♫clipman 19:31, 22 March 2010 (UTC)

Doesn't this hold:

• ellipsis : three periods :: en-dash : hyphen-minus?

The analogy is a little imprecise because three periods are three characters. That aside, it seems like the logic should transfer. Melchoir (talk) 21:22, 22 March 2010 (UTC)

• Hm... dashes and hyphens are not the same thing. They are like O and 0 or l and 1. Dashes are notoriously hard to render: see below for my technical question --Jubilee♫clipman 22:00, 22 March 2010 (UTC)

That's part of my point: an ellipsis and three periods aren't "the same thing" either! See e.g. Fluid Web Typography p.45 "Although an ellipsis looks a lot like three periods, it is not the same thing, and periods should not be substituted." Melchoir (talk) 22:10, 22 March 2010 (UTC)

Since we still haven't figured out how to use our keyboards to input "…", my only options are: 1. to use … (which I have only just now discovered by reading that article you pointed to—an article having nothing to do with WP, I note); 2. to copy "…" from someone else's edit (as I did just now); 3. to use the three periods. I know which I'll be using and which the majority of editors will do using...

BTW, the keyboard inputting method uses not a semicolon but a period: [9]. In Windows, ctrl-alt-period generates the character in MS Works but not in WP edit windows (not in FireFox, anyway)... Strange.

Also, I note that FF renders the title of this section as .E2.80.A6 when I click it in the contents. Could that code be used somehow?

Finally, the Chicago Manual of Style Q&A says this: "For manuscripts, inserting an ellipsis character is a workable method, but it is not the preferred method. It is easy enough for a publisher to search for this unique character and replace it with the recommended three periods plus two nonbreaking spaces (. . .). But in addition to this extra step, there is also the potential for character-mapping problems (the ellipsis could appear as some other character) across software platforms—an added inconvenience. Moreover, the numeric entity for an ellipsis is not formally defined for standard HTML (and may not work with older browsers). So type three spaced dots, like this . . . or, at the end of a grammatical sentence, like this. . . . If you can, add two nonbreaking spaces to keep the three dots—or the last three of four—from breaking across a line." --Jubilee♫clipman 23:21, 22 March 2010 (UTC)

It is not true that the ellipsis always looks almost exactly like three periods. For instance, in Courier New, we have: … and .... The former is nearly illegible. We are not guaranteed our choice of font; we are not even guaranteed that users will be reading our text (instead of, say, using a screen reader). Three periods is more portable and at least sometimes more aesthetic. Ozob (talk) 23:49, 22 March 2010 (UTC)

Good call changing the title from the near-illegible ellipsis character! Your point about portability is similar to the point made in the Chicago Q&A: "...there is also the potential for character-mapping problems...". I agree with that --Jubilee♫clipman 00:03, 23 March 2010 (UTC)

From the reader's perspective (at least in standard Wikipedia fonts) there is absolutely no difference between three periods and an ellipsis character; they are indistinguishable. If it were not for the real technical problems that Ozob has demonstrated for us, I would fully support allowing both systems, to the point of considering converting three periods to an ellipsis character (or vice versa) to be a dummy edit. Should those technical problems ever cease to be an issue, that is what we should do. Darkfrog24 (talk) 00:11, 23 March 2010 (UTC)

I question much of the above, but I can't possibly respond to it all. :-) Let's keep this simple: is there a problem with the analogy? Melchoir (talk) 00:44, 23 March 2010 (UTC)

My original point was that hyphens are not dashes: AFAIK, we are not supposed to use hyphens for dashes—even for endashes. OK, periods and ellipses are not the same, either, but if even respected editors like those working for the Chicago MoS suggest using three periods (spaced, albeit, with non-breaking spaces, in their case) then why shouldn't we? --Jubilee♫clipman 04:56, 23 March 2010 (UTC)

You're aware that the analogy holds here too? The Chicago MoS also recommends that authors simulate dashes of various lengths with multiple hyphens.[10] Both guidelines are meant for a manuscript that will be further processed by an editor and a typesetter before reaching the end reader's eyes. Melchoir (talk) 07:28, 23 March 2010 (UTC)

• Please stay away from that frightful hellip thing. Three points, spaced both sides, or wherea punctuation mark precedes, no space on the left. Tony (talk) 03:58, 23 March 2010 (UTC)

I agree, though I tend never to have a space on the left. Another issue to address, perhaps. However, I think that the general rule is to avoid white space before punctuation marks, though I may be out of date on that --Jubilee♫clipman 04:56, 23 March 2010 (UTC)

I agree with Jubileeclipman: I am all for using three full-stops instead of the special character, but I am firmly against flanking the ellipsis with spaces everywhere. For one thing, I consider this a substitute for "[...]", which denotes omitted parts in quotations; for another, the ellipsis normally represents a trailing off of the voice at the end of a sentence, and therefore belongs to the preceding sentence. As I see it, using spaces on both sides implies an equal distance from the sentences separated by it, and that is only true in the former case (quotation gaps). It's the same principle that prohibits " ! ", really. Waltham, The Duke of 06:10, 23 March 2010 (UTC)

It looks like only Apple keyboards let you type an ellipsis with AltGR-semicolon. Windows seems to require some silly numerical code for all non-standard characters, even simple things like accented vowels or the Euro symbol. But special dashes are also hard to make with Windows, and Wikipedia is still picky about those, so I don't agree with the argument that the symbol is too hard to make. I also don't agree with the argument that it's hard to read in some fonts, because the same could be said of the dashes. If there is a problem with character mapping, that might be a real worry, but I don't understand why ellipsis wouldn't have a standard place in the character map while all of the other special symbols do. --198.103.172.9 (talk) 15:03, 23 March 2010 (UTC)

Ah, but the dashes we use are longer than hyphens; if there is a problem in distinguishing between them in some fonts, that doesn't mean they cannot be seen for what they are (dashes). This is not true about the ellipsis character, which is often smaller than the sequence of three full-stops. Waltham, The Duke of 15:23, 23 March 2010 (UTC)

Inputting en- and em-dashes

I am not sure if the above RfC is dead in the water, nor if this is even relevent to it, but I have another issue. What is the preferred method of inputting dashes? The wiki software includes them in the edit window toolbox under Insert but some editors insist on using the HTML markup — and – claiming these to be superior or even required for readability. If they are included in the software what is the deal with using the less friendly-looking (in edit windows) HTML and especially with insisting on their use? Thanks --Jubilee♫clipman 21:53, 22 March 2010 (UTC)

Let's put it to the test. Who here can, without looking at the edit screen, tell which of these is code and which is from the insert bar? EMDASH#1: — EMDASH#2: — ENDASH#1: – ENDASH#2: –

They look exactly the same to me. If we can reasonably expect that they'll both be perfectly legible (if not perfectly indistinguishable) in most fonts, then the MoS should show no preference for either technique because it will make no difference to Wikipedia's readers. Darkfrog24 (talk) 00:16, 23 March 2010 (UTC)

I copyeditted your post to place a space before the first endash, making them all have spaces there. Space or no space aside, I see no difference, either, in FireFox 3 under Windows Vista HP. Let's find out what other can see... --Jubilee♫clipman 00:24, 23 March 2010 (UTC)

One advantage of using the HTML markup (not that I'm particularly advocating it, or feel particularly strongly one way or the other) is that it's much easier to distinguish in the editor window. In the fixed-width font that's used there, hyphens and en and em dashes all tend to look very similar. Perhaps that is the "readability" issue that people are referring to? 86.165.22.165 (talk) 01:05, 23 March 2010 (UTC).

• Darkfrog, get another browser or choose another font. They look different to me. Even if they didn't look different, the awful clutter created by the gobbledy is just not worth it when the symbols are plain as day in display mode. I often edit, anyway, with display and edit modes beside each other. Perhaps you need a bigger screen, too. Tony (talk) 03:55, 23 March 2010 (UTC)

• What browser are you using? To specify further, I am using FF3.6, ie the very latest version. I tried in IE7, Safari and Chrome, also, and see no difference at all with those either. Which font have you chosen? It is the Sans Serif setting in Tools→Options...→Content: Fonts and Colours→Advanced... that changes it in FF (I never knew that till now). I have tried several dozen fonts and even changed the size to 28, but no font or size makes emdash 1 and 2 different nor endash 1 and 2 different: they remain resolutely identical whatever I do. Changing fonts in IE makes no odds either. Will try changing fonts in Safari and Chrome but I don't expect I will see much of a difference there if the major browsers don't show any difference. My screen is 20" at 16:10, screen res 1680*1050. Changing to 800*600 doesn't cause any subtle differences to display. Any further clarification on your configuration would help. Cheers --Jubilee♫clipman 04:43, 23 March 2010 (UTC)

• I presume you're referring to Windows versions? I use FF3.6 for the Mac. FF settings (I'd never looked) are Garamond 16 pt (I'll experiment now), but under "advanced", it has lots I don't understand, like "Proportional" (Serif was chosen), then sans-serif (Helvetica), and Monospace (Courier). All double Dutch to me. Tony (talk) 06:57, 23 March 2010 (UTC)

• Ah! I forgot about the actual computer type: IBM-compatibles (usually running a version of Windows) and Macs (Mac OS, of course) will give different results. Of course, Linux etc will give diferent results, too, but I assume those users will know about such things ;) I'll try Helvetica (I forgot that one!) and see what happens. Cheers --Jubilee♫clipman 07:07, 23 March 2010 (UTC)

• I don't think there's a "preferred" method, and I wasn't aware of any effect on rendering so it shouldn't be a style issue. But I think 86.165.22.165 has a point: using &ndash and the like does give clearer visibility in the code editor (hardly "awful clutter" when we're used to reading round citations and suchlike!). Since inexperienced editors often use hyphens, assuming them to be correct, I've come to the view that it's worth the effort of using &ndash for this reason, to make it crystal clear which kind of dash or hyphen lurks there. Even if not universally adopted, the practice brings its benefit in the cases where it is used. I remember there was a discussion a couple of months back (link anyone?) where it was concluded that editors should refrain from "tidying up" by replacing these html dashes with their "nice" equivalents, for this same reason of visibility in the code window. PL290 (talk) 08:14, 23 March 2010 (UTC)

  Meh... I understand your point here, but I lean towards the position that Tony holds, on this issue. The use of HTML entities in wikitext is just annoying. The thing is, I'd really like to insist on avoiding any firm rules here. People should be free to enter, or change; to, or from; the HTML entities and regular characters. There are good reasons to use either, at various points in time, and for various reasons. I understand that it can be a pain switching them back and forth, but there are many things that are like that. At some point we'll have better editorial tools to use, which will cause these sorts of issues to simply fall by the wayside. (By the way, if you use WikEd, characters such as en-dashes [ – ] show up with little super-scripted designators above them, so that you can distinguish them. WikEd is available as a Gadget, from your settings page, so there's no installation headaches to go through.)
  — V = IR (Talk • Contribs) 08:29, 23 March 2010 (UTC)

• WikEd sounds, well, wikkid. Must have a look. (Perhaps it can also be made to scrunge up html entities, giving them a different appearance, for those averse!) PL290 (talk) 09:01, 23 March 2010 (UTC)

  The only real issue with WikEd is that it can be a bit of a resource hog. I think that Cacycle is working on a standalone editor version of it though, which would be nice. Anyway, that's an outstanding idea about highlighting HTML entities, so I've suggested it on the talk page. Thanks for the excellent idea (why didn't I think of that?!),
  — V = IR (Talk • Contribs) 09:11, 23 March 2010 (UTC)

I go with Ohms on the clutter factor: it's not only annoying, but renders the edit-mode text much more difficult to read, especially when there's a raft of, say, year or page ranges, and especially for new editors and visitors. It's a seriously awkward html entity. &n; &m; and &h; would have been SO much more practical; developers from decades ago have a lot to answer for. Now, of practical significance is the dash script, which at the moment changes gobbledies to plain symbols: a relief for many folk, but you may wish to follow or participate in this thread. User:GregU, BTW, checks in irregularly. Tony (talk) 09:32, 23 March 2010 (UTC)

Punctuation question

Please tell me if you think this sentence is punctuated correctly:

Fastway are a British heavy metal band formed by guitarist, "Fast" Eddie Clarke, formerly of Motörhead, and bassist, Pete Way, formerly of UFO.

To me, the commas before "Fast" and "Pete" seem wrong. There has been no dispute about this particular sentence, and in itself it's no big deal, but I'm interested in people's thoughts because it is a punctuation style that I've noticed from time to time in various Wikipedia articles and it always jars. I'm wondering if it's just me. 86.165.22.165 (talk) 01:12, 23 March 2010 (UTC).

No, it isn't. Johnbod (talk) 01:14, 23 March 2010 (UTC)

No it isn't just you. It would be acceptable to delete both of those commas. Darkfrog24 (talk) 02:36, 23 March 2010 (UTC)

It's not merely acceptable; to me it would be preferable. Ozob (talk) 03:09, 23 March 2010 (UTC)

I agree: it's bumpy unless those commas are removed. Tony (talk) 03:52, 23 March 2010 (UTC)

It is preferable without them. Consider the two "asides" in the sentence: (1) "formerly of Motörhead," and (2) "formerly of UFO." If you were to remove them, the sentence would read:

Fastway [is] a British heavy metal band formed by guitarist "Fast" Eddie Clarke and bassist Pete Way.

You could also place the asides in parentheses for a similar result. Inserting the "asides" and setting them off with commas does not cause a requirement for the additional commas in question. Airborne84 (talk) 03:58, 23 March 2010 (UTC)

• Thank you all. 86.165.22.165 (talk) 05:12, 23 March 2010 (UTC).

  I know that I'm late to the party here, but I just wanted to mention: Wikipedia:Reference desk. The Language page is set up to discuss exactly this sort of question (Not that I mind that this was posted here, but I understand what you meant when you prefaced your question with "There has been no dispute about this particular sentence". The Reference desk is designed to be nice, neutral territory).

  Anyway, I also wanted to chime in with my colleges here, in support of preferring not to use the commas.
  — V = IR (Talk • Contribs) 08:16, 23 March 2010 (UTC)

"Wikipedia is not a dictionary"

Hi, I apologize if this isn't the correct place to post this, but it seems this is the best place I could find. My comment is about how quite a few articles in Wikipedia start out, I mean the phrasing of the very first sentence of some articles. Namely like for example this: "Unschooling refers to a range of educational philosophies and practices centered..."

What I wish to bring up is that, to me that looks as though one is talking about the word unschooling, as opposed to unschooling as such. It's not the main goal of an encyclopedia article to focus on the word or term in the article's title, but rather to focus on the article's topic. The topic is (usually) not any word or phrase, but, like I said, a topic. None the less, quite a few Wikipedia articles start out as though they're talking about the specific words in the article title. Like this were a dictionary.

The article about unschooling shouldn't focus on the word that the first sentence there very specifically does focus on as it is now. The first sentence should be something like: "Unschooling is a range of education philosophies and practices...." Anyone see what I mean? Do you reckon I have a point? And if so, is this here issue addressed in the writing manuals and so on, at all? My view is that, unless the article does actually talk about the word(s) in the title, not about the topic pointed to by the word(s) or name in the article title, each and every article that have "refers to" in the first sentence of the article should have those two words replaced simply by "is".

The unschooling article is just one of very many that have a first sentence like that. And it looks completely daft to me. Might as well have used such phrasing in, say, biographies. It would make about as much sense. How does this seem: "Barack Obama refers to the President of the USA.." It's daft. The article is about a man whose name happens to be Barach Obama. The article isn't about the words Barack Obama (at least in Wikipedia that won't normally be the case). Hope I've explained my view on this here sufficiently now. :-)

Please let me know if I've made some sense to you with all this, or if I'm simply totally mistaken. :-) Thanks in advance. -109.189.98.82 (talk) 04:25, 23 March 2010 (UTC)

I agree that "is" is usually preferable to "refers to", but a blanket ban seems dangerous because, like as not, examples will pop up where it's desirable. 86.165.22.165 (talk) 05:03, 23 March 2010 (UTC).

The problem is that editors are expected to use bold for the subject as soon as possible in the lead eg "Barack Hussein Obama II... is the 44th and current President of the United States." Many editors fail to realise that: a) they don't need to quote the title exactly (as with Barack Obama, above); b) they are leading into an article rather than defining the terms of reference; and c) that indirect phrasing, such as "x refers to y", can usually be avoided by using more direct phrasing such as "x is/was y". Hence, unschooling: "Unschooling refers to is a range of educational philosophies and practices centered..." --Jubilee♫clipman 05:28, 23 March 2010 (UTC)

Yes, "is" is better, and I agree it's unsuitable for a MoS spec. There's a rash of anon entries on this page; I urge these users to get an account and log in—it takes four minutes, including your prefs, and you're anonymity is guaranteed behind the username. I can outline the benefits to you and the project if you wish. Tony (talk) 06:47, 23 March 2010 (UTC) PS I restate my hatred of the insistence on bolding. Tony (talk) 06:49, 23 March 2010 (UTC)

I can see the argument for refers to (or something other than is) in this context. The verb to be is normally understood in a defining or identifying sense in the first sentence (as in a dictionary), and it may not be appropriate to equate "unschooling" with the (singular) range of philosophies or with all such philosophies collectively.--Boson (talk) 07:29, 23 March 2010 (UTC)

Agree with Boson. I also think the original poster has a point about the way some articles start out, but the wrong things are being singled out as the cause. It's not that the word "is" is always better (per Bosun, it could even intensify the "this is a definition" / dictionary effect), and it's not the bolding either, which I quite like and think of as akin to those nice old illustrations you used to get around the first (huge) letter of the first word of a chapter in old books. I think the issue just comes down to careful choice of words to suit the article. PL290 (talk) 08:46, 23 March 2010 (UTC)

Agreed.
— V = IR (Talk • Contribs) 09:06, 23 March 2010 (UTC)

There may be some specific issues with articles, but most people that write a lede are following the guidelines in WP:LEDE, which gives specific guidelines for the first paragraph and the first sentence. Nothing should override common sense, of course. Just pointing out where the "driver" for this issue is. Airborne84 (talk) 16:31, 23 March 2010 (UTC)

There's already a guideline about that at WP:UMD. ― A._di_M. (formerly Army1987) 16:41, 25 March 2010 (UTC)

MOS:COLLAPSE ambiguity, question about images

Scrolling lists and boxes that toggle text display between hide and show are acceptable for use, but should not be used in article prose. This includes reference lists, image galleries, and image captions; they especially should not be used to conceal 'spoiler' information (see Wikipedia:Spoiler)."

The second sentence is ambiguous because I'm not sure if "This includes" refers to "acceptable for use" or "should not be used". I assume the latter.

Why is there no guidance on collapsing images themselves? –xeno^talk 16:43, 24 March 2010 (UTC)

No guidance on individual images, because that would open the can-of-worms that is WP:NOTCENSORED! Or is that the problem, and you're trying to stop some madness related to that...? (ie, is someone trying to hide the image at penis or similar? or are you just asking in the abstract?)

I suggest we change the second sentence to:

"Scrolling/Collapsing sections should especially not be used to conceal: reference lists, images, image galleries, image captions, or "spoiler" information (see Wikipedia:Spoiler)."

Or something similar. -- Quiddity (talk) 19:20, 24 March 2010 (UTC)

MOS:COLLAPSE already has a MOS:ANDOR, so it might as well have another MOS:SLASH. Art LaPella (talk) 19:39, 24 March 2010 (UTC)

I just thought we previously had guidance on it. It is of course related to the various image-related disputes that occur from time to time: Rorschach images; those of the prophet Muhammad; and of course, those of very stretched rear orifices. –xeno^talk 19:42, 24 March 2010 (UTC)

"...should not be used in article prose. This includes reference lists, image galleries, and image captions..." Logically, this doesn't follow because lists, galleries, images etc are not prose. I assume, also, that collapsing is frowned upon in lists etc so the text would be better as: "...should not be used in article prose, reference lists, image galleries, or image captions; they especially should not be used to conceal 'spoiler' information (see Wikipedia:Spoiler)." --Jubilee♫clipman 21:02, 24 March 2010 (UTC)

Defining news organisations

Hi, I am trying to start a debate about defining what news organisations, as a reliable source, are good for and/or not good for. Please see Wikipedia_talk:Identifying_reliable_sources#News_Organisations_section ~ R.T.G 18:39, 25 March 2010 (UTC)

Possible contradiction and no mention of the use of colon in ratios.

Article currently states

Do not use unwarranted abbreviations

Avoid abbreviations when they might confuse the reader, interrupt the flow, or appear informal or lazy. For example, do not use approx. for approximate or approximately, except to reduce the width of an infobox or a table of data, or in a technical passage in which the term occurs many times.

Later it then gives the example

In country-specific articles, use the currency of the country, together with approximate conversions to U.S. dollars, euros, pounds, or a combination of these: for example, Since 2001 the grant has been 10,000,000 Swedish kronor (approx. US$1.4M, €1.0M, or £800k as of August 2009).

Approx. in that case doesn't seem to be used many times.

On a different matter there doesn't seem to be any guidance on the use of colons in a ratio. For example if I wanted to state (at a conversion rate of US$1:AU$1.10), is the colon okay or is an equal sign preferable or do I use to? Lambanog (talk) 04:17, 26 March 2010 (UTC)