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)

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)

I lost track some time ago (I lost my connection while moving house). The issues seem to be resolved, though, so I vote to close and move on --Jubilee♫clipman 21:26, 26 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

I don't usually do this sort of thing, but I feel compelled to speak out against this particular solution. The use of null fields in Image links is simply not an acceptable solution, for several difference reasons. Most seriously, this solution is creating attribution issues (though the addition of link= parameters), and is causing disruptive confusion among editors (I see that one user recently TFD'ed a couple of templates based on this.

Don't get me wrong here, I'm not saying that we shouldn't do anything, but I am saying that this is the wrong solution. I'm betting that we need a technical solution here, so it's probably best to get someone from the Usability team on board, here (User:TheDJ springs immediately to mind). I hope we can work this out, but in the meantime I've pulled all of the text mandating use of "|link=|alt=", and pointed to here.
— V = IR (Talk • Contribs) 10:40, 26 March 2010 (UTC)

My understanding is that that's needed to stop screen readers from reading out the file name. SlimVirgin ^{TALK contribs} 16:12, 26 March 2010 (UTC)

Right, that came across from the content which was removed (if you read it deeply enough, and understood the basic issue). The problem is, using a null parameter has other side effects, especially with the link= parameter. From a technical point of view null parameters are always worrisome, so using them as a solution is immediately suspect anyway. Add to that the side effects that they have to rendering, and the change that the recommendations caused in some editor's behavior, and the costs are simply too high to be acceptable, in my opinion. Besides, saying "this image should not be read by a screen reader" is actually different from saying "The text description of this image is (nothing)".

I'm not at all saying that the idea was wrong here, and I want to clearly state that I think this should be pursued further. All that I'm really saying is that the first attempt at a solution was unsatisfactory, unfortunately.17:51, 26 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)

Now done - page is now at Wikipedia:Manual of Style (visual arts), aka WP:VAMOS. Johnbod (talk) 15:44, 26 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)

Thanks for your thoughts on this, everyone. Clearly, the preferred input method is an "editor's choice" issue rather than a MOS issue and editwars on the issue are clearly silly and disruptive. Cheers --Jubilee♫clipman 21:31, 26 March 2010 (UTC)

Not to dig this debate back up, but I was about to post something similar. I think that "editor's choice" is the correct way to go here as well, but it's tough because lots of editors run around with automated scripts which replace the HTML entities with Unicode versions. I personally can't tell the difference at all when this is done, and such edits often come with other minor and harmless replacements to make a blanket revert suboptimal as well. Would there be any support to somehow trying to instruct bot owners / script runners not to change these back and forth? SnowFire (talk) 22:41, 27 March 2010 (UTC)

It's not really that most scripts actively work at replacing the HTML entities, but most string handling routines within the languages actually convert them. That being the case, it would require most bot operators to develop an (error prone) routine to specifically convert back to the HTML entities. That's hardly something that we should recommend, and most will simply ignore any such "requirement" (and I wouldn't blame them, either).

Besides, people shouldn't be using "blanket reverts" anyway, with the exception of reverting obvious vandalism. Using the undo function against real edits is disruptive. If you want to revert someone else's edit, take the 10 seconds to change the text back yourself (and take the opportunity to copy edit, while you're at it).
— V = IR (Talk • Contribs) 23:59, 27 March 2010 (UTC)

More the point, though, why are these bots set to replace one perfectly acceptable entity with another? Why set a bot's script to replace "—" with "—" or "..." with "…" or "…", or whatever? What right do these bot owners have to make a bot that forces the use of one style over another style? --Jubilee♫clipman 00:08, 28 March 2010 (UTC)

There's no setting or anything, though. That's what I was trying to get at, above. The languages themselves automatically change the HTML entities to actual characters when the text is loaded as a string. This isn't about "rights", or even choices, it's just done because... well, because. HTML entities are a pure kludge anyway, so I don't quite get what the problem is regardless.
— V = IR (Talk • Contribs) 01:26, 28 March 2010 (UTC)

What is the point of running the bot then? Why run a bot that changes one perfectly acceptable entity to another perfectly acceptable entity? That's what I don't get... i.e. "it's just done because..." what? People design these things so they must at least define the code that causes this replacement when designing the bot even if there is no actual setting built in to change the bot on-the-fly afterwards. Presumeably the code could be changed to avoid making these changes. This isn't about the relative merits of unicode vs html vs whatever, it is about the rationale behind running the bots. OTOH, some people prefer html (witness other discussions on this page) and others prefer unicode: a bot that make blanket changes is worse, IMO, than an editor simply making a blind blanket reversion --Jubilee♫clipman 01:57, 28 March 2010 (UTC)

How about: "HTML entities are never intended to be seen"? When W3C, who created them, even recommends against retaining them; and every vendor and open source project in the world automatically converts them once their loaded into a string variable... if that doesn't inform at all, I don't really know what to tell ya. Does "Sorry, but you're outnumbered here" work? You're welcome to go try and shut down WP:BOT though, I guess. I don't see why this is an issue at all, however. If you prefer to enter them as HTML entities, I don't see anyone getting in your way. *shrug*
— V = IR (Talk • Contribs) 02:22, 28 March 2010 (UTC)

I had never even heard that W3C were advising against the use of HTML coding. That does explain why bots are being designed to replace HTML with unicode. However, this now seems to suggest that those people I described in my original question are wrong to insist on replacing unicode with HTML. Hence my confusion here! First, editors above say "its up to editors" now you say "no, HTML should be avoided"... You do see the contradiction here, no? --Jubilee♫clipman 02:37, 28 March 2010 (UTC)

I said nothing of the sort, please don't put words in my mouth. I suggest re-reading all of the above, since I very definitively advocated for the "editors choice" stance. You might also want to familiarize yourself with the specifics here, since "W3C were advising against the use of HTML coding", for example, is a severe mischaracterization of what I said above.
— V = IR (Talk • Contribs) 02:44, 28 March 2010 (UTC)

Sorry, I didn't mean to misinterpret you. I read "recommends against retaining them" as basically meaning "advises against their use". If it is "editor's choice", though, in what way am I "outnumbered"? If neither is incorrect, why deprecate the use of one in favour of another? I am even more confused now... --Jubilee♫clipman 03:03, 28 March 2010 (UTC)

Placing this down here because it'd look out of place in the thread just above, but to respond to Jubilee...

Besides, people shouldn't be using "blanket reverts" anyway, with the exception of reverting obvious vandalism. Using the undo function against real edits is disruptive. If you want to revert someone else's edit, take the 10 seconds to change the text back yourself.

Edit: On second thought I may have misread you here. When you wrote "you" did you mean "the generic you, some editor" or "You, SnowFire?" If you meant "You, SnowFire, then this is a complete misreading of my comments. I said that blanket reverts were suboptimal. If that wasn't clear enough, then what I meant was "I don't do them, and have never done them, despite the fact that there appears to be no improvement to the article and it's less readable to me." As a result, editor's choice is being overturned in favor of what the script-runner is using because I am not blanket reverting. If you meant "the generic editor," I agree and noted my agreement earlier.

I agree that some bots are automatically and senselessly converting it, and a prohibition would be hard to enforce. Nevertheless, I don't see what's wrong with, at the very least, a recommendation against changing the style. Or perhaps a recommendation that if HTML entities to Unicode are the only change, the edit shouldn't be made (edits like this don't seem to do anything but make irrelevant spacing changes and upend the dash format). SnowFire (talk) 05:53, 28 March 2010 (UTC)

You quoted Ohms law (V = IR) there, but I did make a similar point later as regards bots. However, now I reread all of the above, I suspect Ohms Law was using "you" to mean "one" i.e. "the generic you, some editor" as you put it. I fully agree that neither HTML nor unicode should be enforced without good reason. Nor should a bot be used to enforce the use of one rather than the other as appears to be happening in certain cases --Jubilee♫clipman 06:18, 28 March 2010 (UTC)

I don't think there are any bots converting to the plain symbols; rather, scripts, carefully managed. That is what I do with Greg U's excellent dash script. Please take it up with him. I think I've alerted him to this issue, on his talk page. I have to say that I don't mind the conversion one bit; but I'm willing to go with whatever consensus emerges. Tony (talk) 06:20, 28 March 2010 (UTC)

Ah... for "bots" read "scripts". Anyway, I'll ask Greg U to clarify the situation after I have watched the Australian GP...! Thanks for clarifying that much, though, Tony. Cheers --Jubilee♫clipman 06:25, 28 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)

MOS:NUM recommends "In tables, infoboxes, or within brackets, use a tilde (~) or use approx." (emphasis added) which sounds reasonable, because in such a context (IMO) spelling it out interrupts the flow more than the abbreviation, because it makes the parenthetical note take up more space. As for the second questions, I'd think both are fine, but I think the colon is usually spaced in these cases (but I could be wrong). ― ___A._di_M. (formerly Army1987) 10:05, 26 March 2010 (UTC)

On "approx.", personally I agree that it's preferable in a short, data-intensive parenthetical note, where I don't consider it informal even though it is elsewhere. On colons, my instinct is that they should not be spaced for ratios, and although I can't remember where/whether MoS pronounces on this, this article and this one seem to agree with me. However, in the case of "at a conversion rate of US$1:AU$1.10" I think the presence of more than digits makes the colon an unhelpful choice, and "to" would be preferable ("at a conversion rate of US$1 to AU$1.10". PL290 (talk) 10:31, 26 March 2010 (UTC)

I prefer spelling it out, too. But if you're in a table and you have a lot of ratios, you may want to use a colon. In that case I think a   between the terms and the colon looks good: US$1 : AU$1.10. For comparison's sake, here's an unspaced 4:3, a thin-spaced 4 : 3, and a regular-spaced 4 : 3. I like the thin-spaced one the best. Ozob (talk) 11:42, 26 March 2010 (UTC)

I agree that using a thin space is a good idea there, if you do choose to use a colon. With all of the surrounding text though, I think that the colon ought to be avoided, even in tables. Using an equal sign seems to be a better solution, to me: (at a conversion rate of US$1 = AU$1.10), possibly even using a thin space there as well: (at a conversion rate of US$1 = AU$1.10). (although, using HTML entities generally sucks. There's some discussion about that from earlier).
— V = IR (Talk • Contribs) 12:11, 26 March 2010 (UTC)

Thin space works much better than squash in Ozob's example. But the equal sign and spelling it out are best, I think. Tony (talk) 12:35, 26 March 2010 (UTC)

Wikipedia:Manual of Style (visual arts) has been marked as part of the Manual of Style

Wikipedia:Manual of Style (visual arts) (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, 27 March 2010 (UTC)

Consolidation?

Do we need all of these really specific MOS pages? There's the one immediately above, for example. I don't have an issue with it or what it says, but... why can't the few unique points that it makes be made here? It seems that there are several mini-MOS pages out there, all attempting to fork off their own little corner of the MOS. Would anyone really object to a good effort to consolidate many of these?
— V = IR (Talk • Contribs) 13:32, 27 March 2010 (UTC)

I sure wouldn't. I remember one of the frustrating things about being a Wikipedia newb was that whenever I was trying to look up rules, I'd find one page that would send me to another page that would send me to another page, sometimes five or six times. I know lots of our fellow denizens consider the MoS to be too big, but it is much, much easier to deal with one big, self-contained page than an unknowable number of small ones ...at least if the big page is well-organized, which this one is. If I could, I'd put all Wikipedia's rules, WP:V, WP:NPOV, WP:OR, all of them, on just two or three easy-to-find pages. Darkfrog24 (talk) 13:44, 27 March 2010 (UTC)

Yea, that's essentially where I'm coming from on this.

I don't want to appear to be dictating to others what they can work on, in terms of the MOS, of course. So, I plan on setting up a bunch of talk page notices and applying a bunch of merger tags. More importantly though, assuming that this effort generally moves forward, we should establish now that it is OK for individuals and projects to work on their own MOS sub-pages, but that they should also expect the page to be consolidated eventually.
— V = IR (Talk • Contribs) 13:54, 27 March 2010 (UTC)

WP desperately needs to rationalise its MoS subpages. MOSNUM and MoS main would be a good start (I tried six months ago, but it didn't receive the right support). We need WP:WikiProject MoS to take the lead and conduct audits, step by step, on all of the pages. Tony (talk) 14:16, 27 March 2010 (UTC)

Well, I just got started. Feel free to jump in and help out. I wonder if people are generally aware of just how many of these sub-pages we've allowed to build up? sheesh!
— V = IR (Talk • Contribs) 14:32, 27 March 2010 (UTC)

Terrible idea, there is no way WP:IMOS and WP:FLAG for example could be consolidated here with out creating a massive page that estentially replicates what we have already but just on one page Gnevin (talk) 15:31, 28 March 2010 (UTC)

Don't worry about this Gneven. The section you're interested in is at #Alt text.
— V = IR (Talk • Contribs) 16:53, 28 March 2010 (UTC)

No I'm interested in this section also Gnevin (talk) 18:20, 28 March 2010 (UTC)

Consolidation: Dubious

Organization and normalization is very helpful, but likely we will still want at least a couple different MOS pages to avoid one gargantuan page; example how to break them down, however, should be discussed. --MASEM (t) 14:43, 27 March 2010 (UTC)

No doubt. In my experience though, it's usually helpful to get everything together before breaking it up again, in cases such as this. For one thing it allows everyone to see what is actually duplicated information, and what is really unique. I'm certainly not going to attempt to make pronouncements about sub-pages though. If there is a sensible reason for something to stand apart then I'm all for leaving it apart.
— V = IR (Talk • Contribs) 14:53, 27 March 2010 (UTC)

Do you see getting "everything together before breaking it up again" as a regular cycle that we would have to go through annually, biennially or merely quintennially? Will there be weeks or months during which we have one massive merged document, full of duplications and conflicts that will slowly be eliminated, followed by days or weeks of fresh discussions on how it should be divided up this time? I fear that until the process was completed and the new pages established, we would have a manual that was rather less useful to the general editor than the existing one is. NebY (talk) 16:39, 27 March 2010 (UTC)

No, I don't. I don't share your fears, at all. Sorry.
— V = IR (Talk • Contribs) 19:55, 27 March 2010 (UTC)

Consolidation: Big mistake

Sorry, but I think this is a big mistake. There may be work needed on some of those established detail pages, but the basic structure is entirely sound, reflects best practice in documentation generally (as well as WP:Summary style), and should be left alone—one main, summary article, and a set of detailed ones it refers out to. PL290 (talk) 14:50, 27 March 2010 (UTC)

I think that we actually agree, in a way. I think that I see what you're getting at, but... can you be more specific in regards to your concerns?
— V = IR (Talk • Contribs) 14:55, 27 March 2010 (UTC)

(ec)I think it's starting the wrong end to say "Do we need all of these really specific MOS pages?" and talk about "consolidation". Things have evolved the way they have for a good reason. There is no general problem that needs a general solution like this, couched in terms that threaten to sweep away the very sensibly established hierarchical document structure. Just lots of little improvements that can be made to any one of the detail articles. Small steps in isolation; business as usual. (BTW, regarding "There's the one immediately above, for example. I don't have an issue with it or what it says, but... why can't the few unique points that it makes be made here?", Johnbod started a thread here before adding it, and there were no objections. I imagine it is destined to develop and grow, and I can't see that it represents a problem. I think he then moved the thread into its own talk page so you may have missed it.) PL290 (talk) 15:12, 27 March 2010 (UTC)

No, it's still above here [11]. Agree with the point - does the main MOS want to have the unique content of say Wikipedia:WikiProject Doctor Who/Manual of style added? Not that this on the main MOS template, which Visual arts now is. Johnbod (talk) 16:59, 27 March 2010 (UTC)

I very specifically made an attempt to avoid any "threats to sweep away" anything. Frankly, such accusations sting, considering the fact that I really did attempt to not threaten anything or anyone. Can we try to avoid the posturing and bickering that is often associated with discussions here and work towards coming to a solution that everyone can be happy with?
— V = IR (Talk • Contribs) 15:17, 27 March 2010 (UTC)

No one is accusing, posturing or bickering. Nothing personal, but the suggestion is a big mistake. PL290 (talk) 15:58, 27 March 2010 (UTC)

The problem is, I don't see any specific concerns here. "It's a big mistake" isn't exactly informative.
— V = IR (Talk • Contribs) 17:07, 27 March 2010 (UTC)

I think PL290 has been has been very informative, answering your original query "Would anyone really object to a good effort to consolidate many of these?" with a clear objection, "... a big mistake .... the basic structure is entirely sound, reflects best practice in documentation generally and should be left alone...." To dismiss this with "I don't see any specific concerns here" will not persuade us that your proposal is sound. NebY (talk) 19:05, 27 March 2010 (UTC)

Anyway, my second look at this: How is this page in summary style at all, right now? How would it be possible to make this use summary style? Going in the complete opposite direction is something that I can see as a possibility, but if that's really the way that we want to go then let's do that. The current half-and-half solution is not helping anything.
— V = IR (Talk • Contribs) 19:58, 27 March 2010 (UTC)

I think you're right: it is half-and-half at the moment. I've noticed that before. Detail is not only repeated in both places, but sometimes conflicts. To answer your question, "How would it be possible to make this use summary style?", I would suggest we work to identify, on an ongoing basis, those areas which are overburdened with detail here, and to gradually relocate that detail to the detail pages, replacing it here with a summary. I really think there's no one-size-fits-all or big bang solution here, just a gradual case-by-case process driven by a common understanding that that's the way we want to go (if there is indeed general agreement that it is the way we want to go—it has my vote, anyway). PL290 (talk) 20:16, 27 March 2010 (UTC)

The issue that I see is within my reply to Art, in the Summary style section below. Considering the close nature of most of the materiel within this (or any other) style guide, I just don't believe that it's possible to truly use a summary → detail framework here.

It seems to me that the issue we're discussing right now: how the current page(s) is(are) half summary and half detail, is a symptom of the disease, rather then being the disease itself. Since all of the ideas within the MOS are so closely related, it's extremely difficult, if not impossible, to properly summarize them.

On a slightly different note, I also think that I've managed to run way out ahead of many others, here. I've been simply reading, through both the documents and the talk pages, and thinking about this problem, for about a week now. Looking back now, and considering this thread and a couple below, I think that I probably sprung this on a few of you, rather unexpectedly. I have to admit that not receiving any immediate negative feedback (quite the opposite, actually) probably emboldened me a bit too much, as well. The last thing I want is to start another pointless fight, but after spending the last little while digging through archives I've probably become prepared for one... which may be trying to create one all on it's own. Hopefully we can be patient and collegial about all of this, and work towards a meaningful long term solution. I know that I'm plenty patient, so I'll be here to help do whatever it is we decide to do.
— V = IR (Talk • Contribs) 20:42, 27 March 2010 (UTC)

It's not as if we're starting from scratch: despite our "half-and-half" criticisms and its need of pruning and fixing in some areas, the MoS is essentially in that form already (summary style). I'm not seeing the issue with "close nature" that you cite. Let's put it to the test: is there a particular topic on a detail page that you identify as "extremely difficult, if not impossible, to properly summarize"? Without an example, it's difficult to assess whether "close nature" really exists as a barrier to adopting summary style more fully. PL290 (talk) 21:57, 27 March 2010 (UTC)

Well, let's see. For one type of example, take a good look at Wikipedia:Manual of Style#Capitalization vs. Wikipedia:Manual of Style (capital letters). Both state essentially the exact same thing, and I'm a bit at a loss as to how it could be summarized without changing the meaning (we could pretty much cut out all of the subsections here, but since all of the subsections describe specific exceptions or sub-rules, that wouldn't really work out well).

Wikipedia:Manual of Style#Acronyms and abbreviations represents a more "classic" issue, in that Wikipedia:Manual of Style (abbreviations) seems to require large portions of Wikipedia:Manual of Style#Article titles to be restated. Wikipedia:Manual of Style (abbreviations) also seems to be completely missing some points from the main page here, as well.
— V = IR (Talk • Contribs) 22:22, 27 March 2010 (UTC)

"Capitalize words when used as parts of a title, but not when used generically." There are always a labyrinth of exceptions, but a link to more details would make it clear that there's more to the story. Art LaPella (talk) 23:13, 27 March 2010 (UTC)

Your example of Wikipedia:Manual of Style#Capitalization vs. Wikipedia:Manual of Style (capital letters) is an excellent one for two reasons—see Summary style below where I've taken this up in more detail. PL290 (talk) 09:46, 28 March 2010 (UTC)

From my experience, most editors look to WP:MOS for Wikipedia guidelines. To put every possible guideline in this one article, no matter how neatly it were arranged, would be a difficult task, especially to maintain it. A long drawn-out discussion in one area (remember WP:MOSNUM date linking?) could make it virtually impossible to make simple and agreed-upon changes in other areas. If we were talking about mainspace articles, I don't think we would be suggesting, for example, that there be one article that includes all countries of the world. One of the main benefits of a wiki is that you can have several individual pages efficiently linked together, and I suggest we continue that. I propose a minor improvement to what we currently have. Have WP:MOS be the main repository for basic style guidelines, and have it link to other guidelines (ex: WP:LAYOUT) as it currently does, and expand those links over time so that WP:MOS effectively becomes the parent page that links to most (all?) other guidelines. If someone is then looking for a guideline, they go to WP:MOS and find what they are looking for, either directly on that page or in an easy-to-find wikilink to another page. Truthanado (talk) 00:38, 28 March 2010 (UTC)

Not every guideline is a style guide, though. More importantly, this directly hits on the issue which PL290, Art, and I have been discussing. We should pick one system and stick to it. If it's summary style with links to detail, then the whole page should follow. As I said below though, that doesn't seem practical, since that's not the manner in which we develop mainspace articles. That being the case, it's more realistic to have a few large documents then many small ones. Besides that, the "summary-index method" completely ignores the criticism where people have to click 2, 3, or more times in order to get to the information which they are actually looking for. I think that is valid criticism, myself.
— V = IR (Talk • Contribs) 01:17, 28 March 2010 (UTC)

Yes, summary style requires 2, 3, or more clicks to get to the information they may or may not be looking for. Remember the alternative is reading through the 155 kilobyte Manual of Style to find that information (admittedly you wouldn't have to read it all, but you know what I mean.) Art LaPella (talk) 04:31, 28 March 2010 (UTC)

That's just it, Art. The MoS is so well-organized that a person can skim through the table of contents and find the relevant information almost immediately. Skipping around from page to page to page takes much longer. Darkfrog24 (talk) 13:43, 28 March 2010 (UTC)

Well, I wouldn't say that it's "so well organized", but it's organized enough to make "bring up page, look for relevant section" a practical usage pattern. That really gets back to what I was saying earlier as well, that the content here is closely associated enough that it lends itself to a large page or three (instead of dozens). I mean, everything here is about style. There are many reference books available which use the same basic structure that we're using here as well, which is another important consideration (giving people what they expect tends to help which this sort of thing).
— V = IR (Talk • Contribs) 16:59, 28 March 2010 (UTC)

Consolidation: Visual arts

Your proposal suggests you have not seriously considered how much space what you call the "few unique points" would actually take up if consolidated. The "Text issues" section is almost entirely about specific art matters with material that is not duplicated anywhere else; that alone takes up 2 1/2 screens on my pc. Some of the other sections are more general, but consolidating the whole thing would either mean dropping stuff or taking up several screens-worth. There are over 20 such specialized MOS sub-pages, many longer than this one. The suggestion is a non-starter. Johnbod (talk) 15:02, 27 March 2010 (UTC)

(ec)Please don't make assumptions. I'm very much aware of how much space is, or at least may be, required. Do you have a specific concern though, or just a general objection to the whole idea?
— V = IR (Talk • Contribs) 15:06, 27 March 2010 (UTC)

Can you point to the "Text issues" section, please? There's no such section on the MOS page (which is where we are right now), as far as I can see. I assume that you're here from a specific sub-page?
— V = IR (Talk • Contribs) 15:14, 27 March 2010 (UTC)

I was of course using your example of Wikipedia:Manual of Style (visual arts). Johnbod (talk) 15:19, 27 March 2010 (UTC)

Ah, of course. Sorry. I haven't actually looked at that page (aside from a brief glance, earlier). The notification here, along with a minor incident elsewhere, are what started my thinking about all of this, is all. I didn't mean to single out the visual arts page as being particularly problematic, or anything like that. I'm more concerned about the actual forks of the main MOS rather then the subject specific guidelines (see the {{Mergeto}} that I've added this morning, for examples). Generally though, I do wonder if the subject specific guides couldn't fit in here, someplace. They're probably more likely to need a specific page then others are, but still...

For example, just as an off the cuff thought, what about retaining the truly unique points on "(visual styles)" and then using Transclusion to show that page within a section on the MOS? That way, the page itself is very specific to the subject while avoiding the need to repeat things already stated here.
— V = IR (Talk • Contribs) 15:37, 27 March 2010 (UTC)

Ah, so my "assumption", which you just criticised, was entirely correct! What section within the MOS, and how would that help anything? Johnbod (talk) 16:00, 27 March 2010 (UTC)

If by "my assumption" you're limiting your comments here to the visual arts page, then yea, sure. As I said, I wasn't specifically thinking about that page directly. This whole sub-thread of discussion seems to be predicated on a simple misunderstanding of the issue.
— V = IR (Talk • Contribs) 17:04, 27 March 2010 (UTC)

Well you chose that example, which I think is a good one for illustrating why this suggestion is not practical. So my comments also address the general issue. Johnbod (talk) 18:27, 27 March 2010 (UTC)

Consolidation: Policy

I wouldn't be opposed to limited consolidation, but I've seen a policy tagged for consolidation (we can't incorporate a policy into a guideline), and one page that recently had guideline status removed. So long as we were careful not to extend the MoS's remit, and not to downgrade or upgrade any consolidated page, I'd support the proposal. As things stand, there are too many pages for people reasonably to keep an eye on, yet they all have guideline status, often only because of their link to the MoS. SlimVirgin ^{TALK contribs} 16:57, 27 March 2010 (UTC)

Which page?
— V = IR (Talk • Contribs) 17:07, 27 March 2010 (UTC)

The policy page was the image use one, which you've fixed, and the page that's had guideline status removed is the alt text one. SlimVirgin ^{TALK contribs} 19:56, 27 March 2010 (UTC)

As you said, I pulled the merge proposal from the image use policy page already. Are you concerned with the alt text one as well?
— V = IR (Talk • Contribs) 20:11, 27 March 2010 (UTC)

Consolidation: Summary style

I like "summary style". I wish we used it. What we often have instead is an allegedly detailed page that often has little more information than the parent page. In those cases, consolidation would be preferable to what we have. The ideal would be a parent page that really summarizes the rest of the information, rather than restating most of it. There would be a much shorter introductory page, with links to all of the existing information in the detail pages. Art LaPella (talk) 17:25, 27 March 2010 (UTC)

Agree. So, far from consolidation of detail to the main page, it would be a question of, on a case-by-case basis, identifying what detail ought really to be relocated off it to a detail page. PL290 (talk) 17:34, 27 March 2010 (UTC)

Agree with that, somewhat. I think what we need to do is look at this page as, not MOSMAIN, but MOSGENERAL, that is, the material here should be general English usage, style and grammar that could easily turn up in any article, while the subpages should be limited to specialist topics. Some of the subpages on grammar seem, upon first glance, to go into excessive detail better suited for the article that covers the development of the usage. oknazevad (talk) 18:44, 27 March 2010 (UTC)

I agree. Who the Hell needs instruction about "Uncalibrated (bce) radiocarbon dates". The main page of the MOS should contain the stuff which affects (say) more than 50% of all articles, and which all (or most) editors will want to know. More specific things which nevertheless affect a substantial fraction (say 10%) of all articles, and which "general" readers will need to look up once in a while, can go in the MoS subpages; really esoteric stuff which only affects articles on a narrow range of topics and which most editors will never ever need to look up throughout their WP careers belongs to WikiProject subpages. ― ___A._di_M. (formerly Army1987) 11:39, 28 March 2010 (UTC)

Who decides these percentages. Is the WP:IMOS a 10% MOS, is it higher or lower? Gnevin (talk) 17:00, 29 March 2010 (UTC)

Well under 10%, because Ireland isn't 10% of the world by any measure, considering that I didn't find anything at IMOS about Irish-Americans, and that many articles aren't even limited to a specific country. But of course there would be doubtful cases. The idea presupposes that we would agree on easy cases (including Ireland in my opinion), and agree not to argue too much about doubtful cases. Art LaPella (talk) 17:31, 29 March 2010 (UTC)

I though we where talking about 10% of articles not the world but Irish articles would probably be closer to 1% but they would be more controversial than maybe 80% of other articles. Taking article like the IMOS out of the MOS name-space would damage its creditability Gnevin (talk) 17:40, 29 March 2010 (UTC)

I generally agree until you got to "... name-space would damage its creditability". It says "WikiProject subpages", so assuming links to those projects are in place, why does the namespace matter so much? Art LaPella (talk) 19:29, 29 March 2010 (UTC)

In agreement here. As I was saying earlier, the idea that position imparts any authority is incorrect on it's face.
— V = IR (Talk • Contribs) 21:01, 29 March 2010 (UTC)

I agree with the thinking here as well, in most cases. In the case of the MOS specifically, howver, the information is so closely tied together that we can't help but to restate many points. Any "Manual of Style" needs to be coherent, which means that it's generally better to keep it all together.
— V = IR (Talk • Contribs) 19:46, 27 March 2010 (UTC)

I would write my own summary if I thought it would be adopted. Examples of what I have in mind: "Article titles and section headings should be chosen carefully. For details, [link]. Religious terms are generally capitalized. For details, [link]. Some words should be hyphenated, and some should have dashes, of which there are two kinds. For details, [link]. Although there are many exceptions, single digits should often be replaced with words. For details, [link]. ..." Art LaPella (talk) 21:55, 27 March 2010 (UTC)

so, you're picturing something more like an index (within prose), rather then having any real detail here at all?
— V = IR (Talk • Contribs) 22:26, 27 March 2010 (UTC)

Hmm, we already have a Table of Contents. I'll try again: "Hyphens are used to distinguish between words, to link certain prefixes, and to link related terms in compound adjectives and adverbs ..." Those are already in subheadings, but not in the Table of Contents. In general, levels of summary should be roughly equally spaced – that is, one should be 8 times as long as the last one, and 7 times shorter than the next one; not 50 times followed by 1.3 times. Art LaPella (talk) 23:02, 27 March 2010 (UTC)

Right... I get it, I fairly certain, but the vocabulary is a bit lacking here... The problem that I see there is maintaining such a structure. There's a fairly well worn pattern here that people look to one page, primarily. I mean, that's the way we treat regular articles, so doing something different here would be tough for many to understand. Actually, I'd rather go in that direction then in the consolidation direction, but practically speaking, I just don't see it happening.
— V = IR (Talk • Contribs) 00:09, 28 March 2010 (UTC)

I don't understand "one page ... that's the way we treat regular articles". For instance, World War II links to many subarticles, such as World War II#Aftermath:

Main article: Aftermath of World War II

That's an example of the model I have in mind. Art LaPella (talk) 04:24, 28 March 2010 (UTC)

This seems like the model that I'd use. In most cases, I wouldn't delete/redirect the subpages, though, since having a venue for providing details is useful in itself. Croctotheface (talk) 08:06, 28 March 2010 (UTC)

User:Ohms law's example further up the page, Wikipedia:Manual of Style#Capitalization vs. Wikipedia:Manual of Style (capital letters), is an excellent one for two reasons. Firstly, it confirms the reality and extent of the duplication between the MoS and its sub-articles, meaning we must take that seriously and address it as part of this exercise. Secondly, and more interestingly, it shows we must look at the TOC here, not just an individual sub-article, to see at what level to create summaries. This TOC is vast and unwieldy (to all intents and purposes unusable at almost 3 full pages in length), and I believe the summarization should start right there. Chopping out all but the level 2s, this is the current TOC:

 1 General principles
 2 Article titles, headings, and sections
 3 Capital letters
 4 Acronyms and abbreviations
 5 Italics
 6 Non-breaking spaces
 7 Quotations
 8 Punctuation
 9 Geographical items
 10 Chronological items
 11 Numbers
 12 Units of measurement
 13 Common mathematical symbols
 14 Simple tabulation
 15 Grammar
 16 Images
 17 Bulleted and numbered lists
 18 Links
 19 Miscellaneous

That is more like a usable TOC. It's also more like the list of sections I think this document should limit itself to, without subsections. Just high-level concepts, with each of those sections itself identifying any applicable sub-concepts, summarizing and linking to them. (It seems to me that even some of these "high-level" entries are in fact too low-level to appear there; Capital letters is perhaps one of them, and could be grouped along with two or three other low-level items under some more general heading.) PL290 (talk) 09:46, 28 March 2010 (UTC)

Consolidation: Example

As a concrete example, I've created Wikipedia:Manual of Style/Clarity, which combines Wikipedia:Avoid neologisms, Wikipedia:Avoid peacock terms, Wikipedia:Avoid weasel words and Wikipedia:Explain jargon, and is transcluded onto the page here.
— V = IR (Talk • Contribs) 17:10, 27 March 2010 (UTC)

I am severely opposed to using transclusions for regular running prose. It makes it unnecessarily difficult to make changes, especially editing out minor errors such as typos and misspellings. I also think using the active page to demonstrate is a really bad idea. I'm going to revert that change.oknazevad (talk) 18:37, 27 March 2010 (UTC)

This I understand, because I generally have the exact same reservations and objections as you're expressing here. I've spoken out against using this exact same method myself, before. However... in this particular, limited use case, I think that it's worth thinking about. Using actual sub-pages which are transcluded onto the main MOS page makes significantly more sense to me then trying to maintain several completely separate pages which are only related by the understanding of readers.

Interestingly, you're reversion of the demo edit illustrates another huge benefit. The "editing out typos" criticism is simply misplaced, and contradicted by your own statement, since it's actually easier to maintain and edit the sub-page then it is to attempt to keep everything straight on either one huge page or many separate pages.
— V = IR (Talk • Contribs) 19:41, 27 March 2010 (UTC)

For a better (as in, less controversial) example. Since nobody was watching the page (less than 30, at least), and nobody had touched either the page or the talk page in over a year, I've converted Wikipedia:Manual of Style/Blazon to be a transcluded sub-page. I also took the opportunity to fix the style and language of the page itself, since it was terribly written (where it was actually written, rather then being forced into a bullet list style...). Again, I understand and sympathize with the general reasons not to use this pattern, but in this particular instance it makes sense, to me. There are things that can be done to make editing the specific sub-pages easier, by providing special links for example, if there is serious concerns about accessibility.
— V = IR (Talk • Contribs) 21:39, 27 March 2010 (UTC)

Merge request: WP:Clarity

I'm in sympathy with the general idea that some of the style guide pages could be consolidated, but I'm afraid this one is a bit over-ambitious: Wikipedia:Manual of Style/Clarity. The weasel and peacock guidelines have very little to do with Clarity, myself I think they're closer to being warning signs that an author's POV has compromised the neutrality of the writing. Some time back, I attempted to write a guideline that combined the two issues: User:DoomSandbox.

Also, you should be aware that some of us are of the opinion that the "weasel words" guideline has severe problems. See Wikipedia_talk:Avoid_weasel_words.

On the subject of tranclusive linking, I'm afraid I just don't see the point. It's an additional complication that doesn't really gain us enough to justify using it. -- Doom (talk) 23:24, 27 March 2010 (UTC)

Heya, Doom. I didn't think you were still active!

Regarding the /Clarity page, you're probably correct. I'm perfectly willing to admit that I had similar misgivings, myself. I've always wondered why the Peacock and Weasel word pages were separate, but that's a bit of a different subject (along with the concerns about Weasel wording itself). Still, you've gotta admit that jargon, neologisms, pecockery, and weasel word usage are fairly similar topics. My original thinking was to actually combine them in a completely new section, but the existing Clarity section kind of caught my eye for some reason. Anyway, the particulars aren't that important, to me. (By the way, I think that your combined summation in User:DoomSandbox is excellent, aside from some really minor quibbles)

In terms of transclusion... personally, I hate it in general, outside of template usage of course. However, if it's going to be used anywhere, I don't see a better place then here. One of the things that people complain about quite a bit here is the size of the page, which is what utilizing transclusion could help with. Still, I'm certainly willing to leave that idea behind, it's simply making sense to me, at the moment at least.
— V = IR (Talk • Contribs) 00:54, 28 March 2010 (UTC)

Is this the right place to register my objection to the proposal to merge WP:PEACOCK to any other page? PEACOCK needs to be on its own because it is often used to alert editors in general, or a particular editor, that some text has peacock problems. Linking to a section within a larger style guide is just not sufficiently helpful. Also, the peacock image is extremely helpful to quickly illustrate the point. See links to peacock from pages and links from user talk pages. Johnuniq (talk) 06:36, 28 March 2010 (UTC)

While I would see no problem with renaming WP:Clarity to something that more people feel accurately describes its content, I support the merge. Because this is a writing style issue (rather than punctuation or images or grammar), we should create a new section for such, perhaps between Grammar and Images.

I feel that Johnuniq's concern, maintaining WP:Peacock as a yellow card for flowery editors, could be addressed by making sure that WP:Peacock redirects to the MoS in such a way that the Peacock section is right at the author's eye level. That shouldn't be too hard to do. I would also have no objection to keeping the peacock image. Darkfrog24 (talk) 13:30, 28 March 2010 (UTC)

Just to pile on here a little bit, I don't see the authority of guidance, such as that given by Wikipedia:Avoid peacock terms, deriving from the fact that it's on it's own page at all. Its not authoritative due to any labels, it's location, or any sort of pronouncements. It is authoritative because it's good advice, pure and simple.

These discussions quite often seem to become sidetracked over questions of authority, similar to this. The arguments that someone or other is seeking to impinge the authority of some position or other is purely a red herring. What's worse, such thinking is preventing our policy documents from improving, as they should continuously be doing. The stagnation which has been developing within the Wikipedia namespace over the past couple of years is causing a large contingent of the community to (rightly) just ignore the whole mess. That's no way to keep a community going.
— V = IR (Talk • Contribs) 17:12, 28 March 2010 (UTC)

PS.: adding the picture to the page is easy enough. WP:SOFIXIT, anyone?
— V = IR (Talk • Contribs) 17:16, 28 March 2010 (UTC)indent

Proposal to downgrade the Image use POLICY to a style guideline

Resolved

Ohms has proposed to merge the WP:Image use policy into the MoS. In effect, this is a proposal to eliminate Wikipedia's primary (only?) policy specifically dealing with images, and to bloat the MoS with non-stylistic information, such as how to deal with non-free images and whether images of patients entering a medical facility unreasonably intrude on the patients' privacy (in the absence of their consent, of course).

Whatever the merits of the other merge proposals, I think this one should be removed from the list of considerations. A WP:POLICY is not a style guide. WhatamIdoing (talk) 17:50, 27 March 2010 (UTC)

Significant agreement. The policy is such because it gives incredibly important guidance on copyright rules and issues. I should not be merged. Period.oknazevad (talk) 18:30, 27 March 2010 (UTC)

• Done.
  — V = IR (Talk • Contribs) 19:48, 27 March 2010 (UTC)

Rationalising the MoS mess: Take II

Dear colleagues, as I've said above, thanks to Ohms for the Blazon experiment. However, we need a careful game-plan if we are to tackle the weeping, pustulating mess of style-guide pages in WP, for the sake of editors, readers, and the project as a whole.

In my view, these are the bare bones of a strategy:

1. Ask the developers about maximum page size: how big is too big for MOSMAIN? Would collapsible show/tell sections help users with slow connections or would the use of such devices make no difference to page loading/navigation?
2. Change the rule at Category style guide to establish a proper application process for candidate style guides (there seems to be a waterfall of them, out of anyone's control).
3. Develop a schedule for all style-guide pages to be copy-edited and audited for structure and content and relationship to other style-guide pages.
4. Get a team together to conduct the audit to a schedule, with a view to determining which style guides should be merged into which, including into MOSMAIN. The relationship between MOSNUM and MOSMAIN would be at the top of my list.

IMO, there are two reasons for rationalisation: ease of consultation by editors; second, proper, professional management and coordination.

I am keen to explore the idea of establishing a managing committee to oversee this huge, complex beast—both its auditing and rationalisation in the short- to medium term, and its management in the long term. I would even be willing to explore the possibility of electing such a committee, such is our dire need for reform. WP:BAG seems to have a tightly conceived committee process; so does WP:WikiProject Military History. Why are the style guides left to self-degrade?

No one seems to take WP:WikiProject Manual of Style seriously, so perhaps we need to make a start here. Tony (talk) 10:38, 28 March 2010 (UTC)

As for point 1, WP:SIZERULE seems reasonable. (Typically, "readable prose" is about half the size of wikicode in articles, but for WP:MOS– which doesn't have that many citation footnotes– it is more than that.[12]) FWIW, when I run out of credit in the SIM card in my Internet dongle, so that I have to fall back onto a dial-up connection, the browser typically fails to fully load this talk page about one third of the times.) AFAICT show/hide sections don't help, because they are fully loaded by the browser anyway and hidden by a Javascript. (With the dial-up connection, I can see all such sections expanded as the pages loads and only collapsing themselves after the page is fully loaded.) ― ___A._di_M. (formerly Army1987) 12:02, 28 March 2010 (UTC)

The following shouldn't be so hard to implement and doesn't require a huge planning effort:

• WP:MOS currently serves a dual role: It contains detailed advice on some things, and is the top entry point (level 0) for information that is located in more specific guidelines. Remove all the details and leave the motivation, explanations of the principles, and some typical examples for what the most important subpages recommend. Move all the details to new level 1 guidelines:
  • WP:Manual of Style (sections and titles).
  • WP:Manual of Style (formatting and punctuation).
  • WP:Manual of Style (grammar).
  • WP:Manual of Style (miscellanea).

(These will be in addition to existing level 1 guidelines such as WP:Manual of Style (capital letters), WP:Manual of Style (abbreviations), WP:Manual of Style (dates and numbers) etc.)

• Organise the more specific guidelines as a tree to keep the number of them that need to be discussed here relatively small. I.e. some guidelines will become level 2 guidelines and will only be mentioned at level 1 guidelines. (There may still be a complete overview on each MOS page, but it should be organised as a tree.)
• Each level 1 guideline contains its own summary as it appears on the main MOS page. This summary is transcluded.
• WP:WPMOS is dead, for an obvious reason: Its discussion page is hardly ever used because all discussion about the MOS happens here. This page has 1176 watchers; WP:MOS has 51. Once MOS has been restructured as above, there isn't much left to do on the present page and after a while the noise will go down considerably. At that point redirect WT:WPMOS here. Then all 1176 watchers will automatically be updated about the WPMOS discussions. Hans Adler 13:11, 28 March 2010 (UTC)

Here is a summary of WP:Manual of Style (abbreviations) as an example of what I have in mind: Template:Blockquotetop Abbreviations

Main page: WP:Manual of Style (abbreviations)

We used digital scanning (DS) technology produced by the British Broadcasting Corporation (BBC). We applied the technology while working for the World Union of Billiards. The required software was delivered electronically and fit on approximately two CD-ROMs. It was paid for by the World Union of Billiards.

Abbreviations are normally defined before their first use, are not used unnecessarily (fit on approx. two CD-ROMs), are not made up by Wikipedia editors (was paid for by the WUB), and form their plurals without an apostrophe (CD-ROM's). When to use periods (full stops) is a complex question, especially in the case of "U.S."/"US". Abbreviations of units of measures are discussed in a different guideline, see WP:Manual of Style (dates and numbers). Template:Blockquotebottom Hans Adler 13:49, 28 March 2010 (UTC)

Yes, that's my view, too. I wrote the current WP:MOS#Currencies as a summary of the corresponding section at WP:MOSNUM, for example. (But I think that three levels would normally be overkill; hopefully, two would suffice in almost all cases.) ― ___A._di_M. (formerly Army1987) 15:18, 28 March 2010 (UTC)

If you don't count the top level (the MOS itself, what I call level 0), then we agree. But I really think something like WP:Manual of Style (Latter Day Saints) or WP:Manual of Style (road junction lists) shouldn't be summarised and linked from the main MOS but only from one level lower, so they would have to be on level 2. Hans Adler 15:24, 28 March 2010 (UTC)

Personally, I'd keep such specialized info in WikiProjects' pages, the way WP:MUSTARD (which affects many more articles than those two combined) is. But ultimately that would not make much difference. ― ___A._di_M. (formerly Army1987) 15:38, 28 March 2010 (UTC)

All this will lead to is a MOS that is Jack_of_all_trades,_master_of_none. There are to many distinct issues that just can't be dealt with in 1 document. There may be a case of some MOS's overlapping with each other and merges there but a up merge into a centralised MOS or several MOS's just can't work Gnevin (talk) 15:42, 28 March 2010 (UTC)

Regarding MoS document structure, Hans Adler's approach accords entirely with my own. That includes this specific point about levels of document at which to summarize and link sub-levels. Regarding Tony's proposal, category control seems only sensible, given the centrality of MoS to WP; and I have no particular comment about the committee/planning/schedule idea, but I can quite see that that could well be the appropriate development unless we reach compelling agreement here about document structure. I think maximum page size is a red herring, and should not be relevant to our starting point. This summary-style approach lends itself naturally to a main page which does not approach any such maximum size. PL290 (talk) 16:27, 28 March 2010 (UTC)

I agree, and I'd love to take this sort of approach as well. The main issue that I see is that the current structure we are utilizing is inadequate for the task, which is why I posted the "Book" idea to kick around, below. As I hope is clear by now, I'm not particularly married to any one organizational concept, as long as the primary issue is addressed. Namely, the organizational failings for the current MOS structure.

I'm also not opposed to the "committee/planning/schedule idea", but I'm not particularly supportive of it either. If it helps then great, but if it's just going to get in the way... I don't really know the answer to that, but I'm willing to listen.

I do think that article size ought to be considered, but that it should be considered later on. Calling it a "red herring" seems like a bit of an overstatement, but it certainly shouldn't be a central consideration to the fundamental organizational decisions. There are means to deal with size issues that, while they do require some work, are manageable.
— V = IR (Talk • Contribs) 21:32, 28 March 2010 (UTC)

I think the trick here is to do the consolidation one level lower, i.e. with what I call the level 1 MOS subpages. We need a clear structure with only a few of them that bundle everything else. Anything detailed that is now in the MOS can gradually move to the level 1 subpages, and they can be cleaned up independently.

By the way, I mentioned transclusion above, but in my opinion that's a minor point. I was thinking of that because in the past we had problems with subpages and their summaries sometimes evolving in different directions until they contradicted each other. If we can identify/create an intelligent set of level 1 subpages with clearly defined, non-overlapping responsibilities, then each can be authoritative for what it covers. Beginning it with a short summary that can be transcluded by the main MOS page is merely a way of ensuring consistency by technical means, but once the MOS has a structure that everybody understands that may not be necessary any more. Hans Adler 22:16, 28 March 2010 (UTC)

• I also think a consolidation is long overdue. In fact, I find the current family so cumbersome and confusing that I find myself going around in circles literally trying to find the exact passage which interests me that I often leave unsatiated. I tend to think that this is infinitely closer to what most of us need from the manual of style. Ohconfucius ^¡digame! 02:03, 29 March 2010 (UTC)

The MOS as a tree

The above list is an overview over all pages of the form WP:Manual of Style (X) that are not redirects. If such a page is not actually an official part of MOS (typically because it was rejected or abandoned before inclusion), then I have still included it but put it in parentheses and italics. I have sorted the pages into the following five criteria: region & religion, subject areas, language, Wikipedia infrastructure, miscellanea. Hans Adler 16:53, 28 March 2010 (UTC)

There's a MoS for poker, but no MoS for card games in general? That's weird. ― ___A._di_M. (formerly Army1987) 18:44, 28 March 2010 (UTC)

Book

Here's a crazy thought: We should move the whole of the Manual of Style to become a book on Wikibooks.

I know that's likely impractical, but I at least wanted to throw the idea out there. I think that quite a bit of our current debate here revolves around the problem that we're artificially constrained right now. More realistically, we could ask for a namespace to be created specifically for the MOS. That would certainly have it's own utility.
— V = IR (Talk • Contribs) 17:34, 28 March 2010 (UTC)

What constraint? What utility? Will people be more likely to read something called a "book" than something that's already almost long enough to be a book? Art LaPella (talk) 18:06, 28 March 2010 (UTC)

You said it yourself: the MOS is alredy long enough to be a book. And yet, we've managed to force it into a few dozen pages. That's mostly what all of this is about, that we're trying to deal with cramming all of the content needed for a good MOS into an inadequate structure. It's a mess because it simply doesn't fit into the mold we're trying to force it into. (Besides, any manual of style is a reference work. Reference works are to be read as needed; their not intended for someone to sit down and take tem in cover to cover. Nobody would seriously talk about reading Wikipedia, World Book, or Britannica "cover to cover", after all.
— V = IR (Talk • Contribs) 21:08, 28 March 2010 (UTC)

You know, now that I really look, there's already a pseudo-namespace in use for the Manual of Style. They're all shortcuts, but the list is available through this search. All we really need to do is formalize that by moving all of the MOS pages to, for example: Manual of Style:Dates and numbers, or Manual of Style:Main page (for this page), etc... Getting an actual namespace added (along with an actual pseudo-namespace) would be nice, but it's not an absolute prerequisite to get started.
— V = IR (Talk • Contribs) 01:27, 29 March 2010 (UTC)

I don't quite follow you on this one, Ohms. 1. What do you believe are the shortcomings of the current format? 2. How do you think that turning the MoS into a Wikibook would solve these problems?

I can see how a regular paper book would be helpful (if there were some way that we could get it into everyone's hands). A person can pick up a real book and see right away how big and detailed it is and get a general feel for how much information it holds—the main shortcoming of our current pseudosystem of decentralized webpages. Darkfrog24 (talk) 02:37, 29 March 2010 (UTC)

What might actually make things easier to find is an index (not for a book, just for here as a subpage maybe). Johnbod (talk) 04:23, 29 March 2010 (UTC)

• Hans's tree: I like it, but I wonder how it can help. The hard-copy book idea is crazy! :-) Johnbod's INDEX idea is the best thing I've heard all year. If skilfully constructed, it could be the first port of call for editors, and would enable us to keep tabs on everything more efficiently. The hard yards are in auditing all of the pages, even if we develop a good index. I want to hear that my colleagues here are will to put the work into it. I am certainly willing to volunteer to audit and report back on a set of subpages, as well as to help construct an index. Tony (talk) 13:11, 29 March 2010 (UTC)

I'm ready to help with indexing, though I suppose we need to let everything else settle first. Keeping it up to date is likely to be the main problem. Johnbod (talk) 22:27, 29 March 2010 (UTC)

• • My tree was just meant as a structured inventory of the mess we have now. See below for my concrete proposal what to do with it. Hans Adler 17:42, 29 March 2010 (UTC)

Straw poll: shrink, grow, or neither

The above discussion has shown that there's quite a lot of interest in overhauling this MoS page. As to document structure, two fundamental approaches have been identified:

• Shrink: this main MoS page should continue to act as a springboard from which all style guide detail information is accessed, but the main page should contain far less detail itself.
• Grow: this main MoS page should expand to include all required style guide detail which is at present on sub-pages, and the sub-pages should be scrapped.

I would like to gauge opinion about which of these basic approaches we should adopt. I think it will be helpful if we try to locate any further substantive discussion in other sections outside the straw poll. Let's just consider this fundamental choice here. Please indicate your preference by signing under one of the three headings below (shrink, grow, or neither).

Straw poll: shrink, grow, or neither: Shrink

"This main MoS page should continue to act as a springboard from which all style guide detail information is accessed, but the main page should contain far less detail itself."

• There's little point in loading such a big page straight away. A summary page would be a much more helpful route to get to the right detail. This structure reflects best practices for documentation generally.PL290 (talk) 08:37, 29 March 2010 (UTC)
• As I have demonstrated in my draft for a section #Abbreviations, the main MOS page can shrink a lot and still contain all the information that is important and easy to explain. With a reasonable set of clearly defined subpages, all instructions that (1) are needed only in rare cases, (2) are hard to explain, or (3) are under active debate can be delegated to the relevant subpage.

The main MOS page should serve as a document that an editor can read completely in order to understand the general principles and the most important details, and as an index to the more detailed subpages that we can look up once a problem arises. Each subpage can then try to be complete and avoid sub-subpages as far as possible.

Where subpages do overlap (e.g. problems of text highlighting caused by the Saxon genitive could fall under typography or grammar), one of the subpages should take responsibility, and the other should link to it wherever it makes sense.

What we don't need is (1) a big MOS page that discusses arcane details at length just because they fall into the same broad category as some crucial information that needs discussion on the main MOS page, (2) excessive duplication between the MOS and its subpages, leading to inconsistencies, or (3) a big mess in which nobody knows whether to look for something on the main MOS page or on the more specific subpage. Hans Adler 12:52, 29 March 2010 (UTC)

• I think we can direct traffic to specific information more efficiently with multiple pages, like Wikipedia:Tutorial, than by including everything on one monstrous page. But either plan would be an improvement over subpages with little more information than the section they are intended to explain. Art LaPella (talk) 17:49, 29 March 2010 (UTC)

Straw poll: shrink, grow, or neither: Grow

"This main MoS page should expand to include all required style guide detail which is at present on sub-pages, and the sub-pages should be scrapped."

• Limited grow: There are too many subpages, and this makes finding rules frustrating. It is not at all friendly to new or inexperienced editors. All content related to punctuation, grammar, style, correct English, proper English (such as GNL) and general good writing practices should be included here at our current, newb-friendly level of detail.
  However, not all of the subpages are appropriate for inclusion in this MoS. Subpages that apply only to specific, easy-to-identify projects may serve the Wikipedia community better if they remain separate. We can reasonably expect that by the time a Wikipedia editor has enough experience to join a project, he or she already feels reasonably confident about Wikipedia's basic-article rules. AdM's "Does it affect more than 50% of our articles?" might be a good rule of thumb to follow. Darkfrog24 (talk) 12:20, 29 March 2010 (UTC)

Straw poll: shrink, grow, or neither: Neither

"This main MoS page should neither shrink by moving detail off it to its sub-pages, nor grow by moving all the detail here and scrapping the sub-pages."

• If "neither" can mean "both", then this is the way to go. I don't know what we're hoping to achieve through a straw poll. This hardly seems like an issue where we must pick one direction or another. Are we trying to polarize everyone into making an either/or choice? If so, why?
  Anyway, We can have fewer large pages, but still break the entirety of the Manual into separate, reasonably sized, pages. I like the index idea myself, as long as we can keep the amount of click through to a reasonable level.
  — V = IR (Talk • Contribs) 13:47, 29 March 2010 (UTC)

merge of Wikipedia:Alternative text for images

My opinion is that this should not be merged into MOS. Firstly, only a few people are interested in it. Secondly, there is still dispute over what it should say. Tuxedo junction (talk) 18:01, 29 March 2010 (UTC)

OK, a couple of questions for you. If only a few people are interested, then why does it need its own page? If there's dispute over what it should say, should it say anything at all? Assuming that it should, again, why couldn't what it should say be said alongside everything else which should be discussed regarding images?
— V = IR (Talk • Contribs) 21:14, 29 March 2010 (UTC)

My understanding is that the dispute has ground to a halt on Wikipedia talk:Alternative text for images with no resolution. This is a matter that must be decided upon, as it is U.S. law that alt text be used, as part of the disability statutes. But perhaps we are not ready yet to settle upon the exact parameters. Tuxedo junction (talk) 21:27, 29 March 2010 (UTC)

Its US law that alt text must be used?!? Says who? Does that mean that if I remove alt text from some article, the FBI will come barging through my door and arrest me?
— V = IR (Talk • Contribs) 21:54, 29 March 2010 (UTC)

Not according to Section 508 Amendment to the Rehabilitation Act of 1973. Is there more to the story? Art LaPella (talk) 22:28, 29 March 2010 (UTC)

Hey, cool, look at that: we actually have an article on section 508. Go figure! (I would like to mention that I'm all for the use of alt text, and other accessibility functions, where appropriate. Attempts to induce moral panic, and the introduction of pure hyperbole, do nothing but hurt actual progress in accessibility, however.)
— V = IR (Talk • Contribs) 23:09, 29 March 2010 (UTC)

Wikipedia:Manual of Style/Blazon has been marked as part of the Manual of Style

Wikipedia:Manual of Style/Blazon (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, 28 March 2010 (UTC)

Wikipedia:Manual of Style (dermatology-related articles) is no longer marked as part of the Manual of Style

Wikipedia:Manual of Style (dermatology-related articles) (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, 28 March 2010 (UTC)

Wikipedia:Blazon is no longer marked as part of the Manual of Style

Wikipedia:Blazon (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, 28 March 2010 (UTC)

What is Blazon doing here?

I've never seen a more inappropriate control of detail and relevance. Blazon (now bloated, I see) is of interest to a very narrow range of editors, and should be in a separate page/essay. Make room for integrating more important stuff, please. Tony (talk) 02:48, 28 March 2010 (UTC)

See #Consolidation: Example, above.
— V = IR (Talk • Contribs) 02:51, 28 March 2010 (UTC)

Has there been a discussion about the maximum desirable length of MoS main page? Me, I don't care: I have a good connection; but others may very well care. If there's to be a rationing of scope, why on earth is an esoteric topic such as blazon suddenly taking up lots of space, rather than more important stuff that is not here. We could just as well merge all 50 or 60 pages into this one. Tony (talk) 06:26, 28 March 2010 (UTC)

Blazons never used to be treated on this page. Then a small subsection crept in. Now we have a rather bloated, full description. Next, the styleguides for Dr Who and for road junction signs will be transcluded. I thank Ohms for greatly improving the page: good work. But can we please do this in an orderly way? Please see my section below: "Rationalisation Take II". Tony (talk) 10:17, 28 March 2010 (UTC)

Just considering the content of the section itself, I'd be all for deprecating the entire thing, marking the page as historical in the process (I'd move it back to be a separate page again, in the process). Please note that what I've done with it was purely technical, not any sort of endorcement of what the section says, or whether it should be included here.
— V = IR (Talk • Contribs) 16:50, 28 March 2010 (UTC)

OK, considering the lack of any additional feedback, I've moved the Blazon page back to it's original location and marked it as historical.
— V = IR (Talk • Contribs) 13:56, 29 March 2010 (UTC)

I wouldn't have marked it as historical. I believe, if I'm reading him right, that Tony's main objection was including the entirety of of the Blazon page here, with which I agree. That doesn't mean the separate page is completely irrelevant for its purpose, nor that a link (possibly with a very brief summary) doesn't belong here. oknazevad (talk) 14:15, 29 March 2010 (UTC)

If it's no good here, then it's no good at all. Aside from that, the page quite literally receives no views the majority of the time, and has no watchers. That's why I chose to use it as an example, since using it wouldn't be stepping on anyone's toes. But, if you want to try to show that it has support as a style guideline, then I'm certainly not going to stand in your way.
— V = IR (Talk • Contribs) 14:23, 29 March 2010 (UTC)

That's like saying WP:Manual of Style (biographies) or WP:Manual of Style (music) or WP:Manual of Style (mathematics) are of no use because they are not transcluded onto this page. Would you mark those as historical, also? Presumeably not. If the Blazon page is genuinely of no importance these days, then it can reasonably be marked as historical but that would still need consensus.

OTOH, should the subpage not be linked in the side box or where ever? Indeed, should not all the other subpages also be linked somehow from the mainpage? How do we actually find those pages to comment on them, otherwise, unless they are transcluded onto the main page (like Wikipedia:Manual of Style/Clarity claims to be, but isn't)? E.g. the following appear to be unlinked from anywhere other than other subpages and usertalk pages: Wikipedia:Manual of Style/(Japan-related articles)/Name order, Wikipedia:Manual of Style/List of talk page search boxes [what is that?!], Wikipedia:Manual of Style/(biographies)/Survey on Style-Prefixed Honorary Titles/Ratification [shouldn't that and its parent page both be talk page subpages?], etc. Admittedly, most of these are obscure artefacts (or apeear to be) and are (probably) genuinely historical; but still: how do those that care about such things even know to look for these subpages? --Jubilee♫clipman 23:18, 29 March 2010 (UTC)

Not to mention, the page is less than a year old and was, according to the edit history, created in response to a specific discussion at WT:WikiProject Heraldry and vexillology. I would think that dropping a note there might have been a good idea before declaring one of their project pages dead.oknazevad (talk) 01:22, 30 March 2010 (UTC)

Is this page auto-archived?

It's of humungous size: is the archiving working? If so, can the number of days since activity for a section be reduced? Tony (talk) 06:27, 28 March 2010 (UTC)

Yes but only threads older than ten days. I concur: the bot needs to archive either threads older than, say, 5 days or when the page size gets too big --Jubilee♫clipman 06:32, 28 March 2010 (UTC)

I've decreased the time-until-archival from ten days to seven as an initial step. If this solves the problem, good; if not, we can decrease it further. Ozob (talk) 13:41, 28 March 2010 (UTC)

Thanks, Ozob. Tony (talk) 13:12, 29 March 2010 (UTC)s

Italicise the possessive tag?

Colleagues, User:Merbabu has asked about this on my talk page, but I don't know the answer. The "Effects on nearby punctuation" doesn't seem to refer to this aspect. My feeling is that the 's should be italicised, just as we blue it in links. Here's a copy of his query. Your thoughts, please?

______

... does wikipedia have a convention for how to deal with apostrophe's with italic text?

• Abbey Road's first track...or Abbey Road's first track...

and as per above but with links:

• Abbey Road's first track or Abbey Road's first track

Personally, I prefer the latter of the two bullet points - ie, with the 's in italics but I've had this quoted to me explaining why 's should not be in italics - but I'm not convinced. Sorry if this is already in the MOS or somewhere else - if so, could you please point it out? many thanks

______

Tony (talk) 07:24, 28 March 2010 (UTC)

That's covered at Wikipedia:Manual of Style (titles)#Punctuation. The only problem with that is that, for readers with poor-quality fonts, italicized "tall" letters can clash into the apostrophe (example: f's), but there's Template:'s for that (example: f's). ― ___A._di_M. (formerly Army1987) 11:45, 28 March 2010 (UTC)

Rather an important point to be missing from MOSMAIN, don't you think? What should I advise Merbabo to do? Tony (talk) 11:53, 28 March 2010 (UTC)

I would suggest using {{'s}}. I've added an instruction to that effect to the MoS, but of course feel free to change this if you have an objection or an improvement. Ozob (talk) 13:52, 28 March 2010 (UTC)

We should just italicize the whole thing. Regardless of what may be technically "more correct", most people will naturally prefer to italicize the whole... construction (I don't want to use "word" there). Not that we should cater to the lowest common denominator as a matter of course, but purely from a practicality standpoint this isn't a fight worth taking on (besides, I've always disliked the "you shouldn't italicize the 's" convention. It's always struck me as somewhat artificial).
— V = IR (Talk • Contribs) 16:46, 28 March 2010 (UTC)

How would you then distinguish Jane's? Ozob (talk) 19:32, 28 March 2010 (UTC)

Indeed. If I saw a link Jack Daniel's, it'd look like it went to Jack Daniel's, to me. With Jack Daniel's, I'd know where the link goes right away. ― ___A._di_M. (formerly Army1987) 19:57, 28 March 2010 (UTC)

What's "artificial" with it? ― ___A._di_M. (formerly Army1987) 19:52, 28 March 2010 (UTC)

Exceptions are a dime a dozen, especially around Wikipedia. I don't see how that's relevant to the general question. Regardless, the word "artificial" doesn't adequately describe the feeling that I have, but it's the best that I could come up with on the fly. Is: "Not italicizing the 's seems pedantic" easier to understand?
— V = IR (Talk • Contribs) 21:02, 28 March 2010 (UTC)

OK, here is a linguistic explanation why not italicising the 's is strange: The apostrophe is just there to distinguish the genitive from the plural. (Many languages use accents for similar purposes, e.g. in French où vs. ou.) Other Germanic languages also indicate the genitive with an -s, but don't use an apostrophe. Historically the -s evolved out of -es [13], and I guess when people stopped speaking the e they felt they had to preserve the distinction between genitive and plural at least in writing, by hinting at the dropped e with the apostrophe.

Conclusion: The 's is as much part of the word as is a plural ending or the -ess in lioness. Since we would never write lioness or lions, it seems absurd to write lion's.

And now I am going to contradict myself: English has the unusual feature that you can say things like "the king of England's crown". This indicates that the 's is no longer a case ending but has become (or is in the process of becoming) something else. If you wanted to italicise England in this particular example, then clearly it would have to be "the king of England's crown". But such constructions are still not very frequent, and I believe the 's is still primarily thought of as the word's genitive ending.

Now "Abbey Road's" is a borderline case. Because the 's clearly belongs to "Abbey Road", not just to "Road", it is not a case ending in the normal sense. Therefore it seems logical not to italicise it. On the other hand, if the entire phrase to which it refers is italicised (as in the question), one can also make a logical case for italicising it. It depends on whether you interpret the 's as an ending or as a separate word that is merely written as if it was an ending. In reality it's something in between. Hans Adler 22:45, 28 March 2010 (UTC)

One argument for regarding the possessive as an enclitic construction rather than a genitive inflection (of the sort that other languages have) is the fact that it is added only once to conjunctions like "Jack and Jill". --Boson (talk) 06:11, 29 March 2010 (UTC)

Yes, but constructions such as "Jack and Jill's pail of water" are famously ambiguous without contextual information. Does it refer to just the pail of water, or to Jack and the pail of water belonging to Jill? Physchim62 (talk) 11:56, 29 March 2010 (UTC)

"The pail of water of Jill and Jack" has the same two meanings, anyway. ― ___A._di_M. (formerly Army1987) 12:01, 29 March 2010 (UTC)

Indeed, so you have to choose a different construction, such as "Jack with Jill's pail of water" or "Jack, Jill and their pail of water". Physchim62 (talk) 12:11, 29 March 2010 (UTC)

(edit conflict) Would you italicize "the" in the sentence "I read it in the Daily Mirror"? It seems to me that "the" is not much more nor much less "independent" than the "'s" in "Abbey Road's first track". ― ___A._di_M. (formerly Army1987) 12:01, 29 March 2010 (UTC)

We already deal with this particular question, albeit through a bit of synthesis, under the combined efforts of: Wikipedia:Manual of Style#Use of "The" mid-sentence, Wikipedia:Manual of Style (titles), and Wikipedia:Article titles. Unless the word "The" is unquestionably part of the actual title (such as in The New York Times (although, even then usage varies)), you shouldn't italicize it. In your example, the first case would be correct: "I read it in the Daily Mirror".
— V = IR (Talk • Contribs) 14:05, 29 March 2010 (UTC)

I agree with Ohms that exceptions are ten-a-penny/cent around here, but surely one piece of advice would be to try to rephrase the sentence to avoid the problem, by forming a possessive with "of" instead of the Germanic genitive with "'s". "The crown of the king of England" is unambiguous to a human reader, while the plural forms "the kings of England's crown" or "the king of England's crowns" seem barbaric to me. Hence, "the first track of Abbey Road", "the wreck of the Mary Rose", etc. Physchim62 (talk) 02:15, 29 March 2010 (UTC)

This is clearly not just a matter of italics. The same principles should apply for all forms of highlighting, including links and bolding. Let's see if we can agree about the general principle:

• An important step towards European unity was Spain's entry into the EEC in 1986. – no problem
• An important step towards European unity was Spain's entry into the EEC in 1986. – no problem
• Wow! She is the king of Spain's daughter! – discouraged (consider rephrasing)
• Wow! She is the king of Spain's daughter! – discouraged (consider rephrasing)
• No, she is not Italian, she is the king of Spain's daughter. – simply wrong
• No, she is not Italian, she is the king of Spain's daughter. – discouraged (consider rephrasing)

Of course as usual we should be consistent within any one article. I used both bold and italics because otherwise the difference is so hard to spot. Which is actually a reason not to spend too much effort on this particular question. Hans Adler 12:29, 29 March 2010 (UTC)

I am inclined to agree with Hans and with Ohms. Italicisation looks messy where it excludes a legitimate part of a word; this has no bearing on the advice not to let italicisation and bolding leak into subsequent punctuation or brackets. Tony (talk) 13:15, 29 March 2010 (UTC)

The original question was about words that are italicized for stylistic reasons, not for emphasis, so let's try some examples of that

• The Daily Mirror's political standpoint is centre-left. – discouraged, consider rephrasing
• The Daily Mirror's political standpoint is centre-left. – the title to be italicized is Daily Mirror, not Daily Mirror's
• The political standpoint of the Daily Mirror is centre-left. – best solution in most cases
• I read it in the Daily Mirror. – just wrong
• I read it in The Daily Mirror. – title is Daily Mirror
• I read it in the Daily Mirror. – no problem
• I read it in The Independent. – title is The Independent

Physchim62 (talk) 13:41, 29 March 2010 (UTC)

I would prefer not to discuss the issue of capitalised articles in titles here, as it seems to be completely unrelated. – We seem to disagree about what is your second point and my third point: In my opinion making the 's part of the highlighting in these cases is acceptable. It's a trade-off between highlighting an enclitic along with what it refers to, as if it was a grammatical case (not good) and the irritating optical effect of something of the form xyz's (also not good). But I wouldn't mind standardising here: While I believe your example two is not a priori wrong, I would agree with not allowing it in the MOS, in order to get uniformity and a simple rule for this very minor typographical matter. Hans Adler 14:07, 29 March 2010 (UTC)

I agree that discussing the use of articles within titles only serves to muddy the waters, here. I also support the point about there being a trade-off to consider here. "the irritating optical effect" is, unfortunately, real. As I said earlier, while there may be a more technically correct answer to this, a simple question of practicality comes into play as well. I also agree with the idea of not allowing it into the MOS, for the reasons stated.
— V = IR (Talk • Contribs) 14:13, 29 March 2010 (UTC)

I'm with Hans that this is probably a non-issue ultimately (due to the fact that the difference is usually very subtle and hard to spot). Furthermore, in the vast majority of cases, it is probably an editor's choice issue: no need to make up yet another "rule" that people may or may not ignore. Abbey Road's first track... vs Abbey Road's first track... - personally, I'd use the latter because helps differentiate between an apostrophe used in a grammatical/semantic role at that point in the sentence and one used as part of the title: Sgt. Pepper's first track.... Rephrasing is probably better in most cases, however, I agree: The first track of Sgt. Pepper['s].... The usage of the apostrophe in this special case is, anyway, problematic and the vast majority of sources seem to abbreviatiate that particular title without the apostrophe, which makes Sgt. Pepper's first track... equally correct... Basically, is it really that important? --Jubilee♫clipman 10:14, 30 March 2010 (UTC)

Wikipedia_talk:Tables#General_style_guideline.3F

This page was named Wikipedia:When to use tables until this month, and has been in Category:General style guidelines for almost two years now. Lately, the content seems to be changing every month and seems focused on how-to and editing rather than style, so I'd prefer to remove it from the general style guidelines, with no prejudice against adding the cat back in the future. - Dank (push to talk) 15:39, 28 March 2010 (UTC)

Someone could split it into an actual how-to and a style guide...
— V = IR (Talk • Contribs) 17:35, 28 March 2010 (UTC)

Actually, there was a single top-to-bottom rewrite of the guideline about a month ago, since it was hugely disorganized and out of date. The how-to you speak of is at Help:Tables. Wikipedia:Tables is meant to cover conventions of formatting and use.--Father Goose (talk) 23:17, 28 March 2010 (UTC)

Outline of a rational MOS structure

• Structure
  • titles and WP:TITLE
  • disambiguation pages
  • (glossaries)
  • quotations, citations and bibliographies – lists of works
  • infoboxes
  • what and when to link

• Language
  • grammar
  • punctuation
  • spelling
  • capital letters
  • pronunciation
  • abbreviations
  • trademarks
  • how to deal with foreign languages

• Formatting
  • text formatting
  • dates and numbers
  • icons
  • images
  • tables

• Special concerns – a list of minor subpages that have the same basic structure as the main MOS page and its three main subpages (but obviously not spread over sub-subpages)
  • by country or religion (currently 18 pages)
  • by topic area (currently 12 pages)

Comments

In the above proposal I have included some topics that are not currently in the MOS but that editors can reasonably expect to find in the MOS. They need not be incorporated in the MOS, but they need to be summarised in the relevant places in the same way as if they were part of the MOS.

The most important feature of the proposal is its simplicity: There are just three clearly defined subpages: Structure/Language/Formatting. Each will be summarised briefly on the main MOS page. (This summary might be an "In a nutshell" section in the subpage itself, which would then be transcluded to the main MOS page.) Plus a bunch of special pages that contain the fine print for various special topics such as Korea-related articles, biographies or articles about chemistry.

The special pages will be refactored into the same structure so that they have three main sections Structure/Language/Formatting (just like the main MOS page), whose subsections will be structured like the respective MOS subpages. We can create links for going back and forth, e.g. the section on capital letters on the Language subpage should have a collapsible box with links to all special concerns pages that also have such a section. These will in turn link back to the main capital letters section which they amend.

The proposal can be realised gradually, by creating one of the three subpages at a time and finally converting the special concerns pages. Hans Adler 13:28, 29 March 2010 (UTC)

This sounds like a plan, to me. Keep in mind that there are some good, well established navigational aids which we can rely on as well. Regular Navboxes and the sidebar style lists that we currently use can be very helpful in maintaining cohesion among multiple pages.
— V = IR (Talk • Contribs) 14:28, 29 March 2010 (UTC)

(ec)Seems reasonable, but I believe we'd still need a central location for easy access, whether the index mentioned/proposed above, or the "beginner's guide" that Tony put together a few months ago.oknazevad (talk) 14:29, 29 March 2010 (UTC)

See above ("Each will be summarised briefly on the main MOS page"). Under this proposal, this main MoS page will remain the central location for easy access. I agree with this approach. If an index is created, that should be as well, not instead. PL290 (talk) 15:52, 29 March 2010 (UTC)

Above someone linked to User:Tony1/Beginners' guide to the Manual of Style. I wasn't aware of that page, but it gives a good idea of what the main MOS page should look like in my opinion. I would structure it differently (four big sections, each with subsections), but that's a minor point. Hans Adler 17:47, 29 March 2010 (UTC)

I have created a quick draft of my vision of the refactored MOS. It consists of the main page and the first of its three principal subpages. I have put the content together very quickly, as it is not the point at all. The point of this exercise is a proof of concept: A usable MOS is feasible in this way. See User:Hans Adler/MOS. Hans Adler 19:39, 29 March 2010 (UTC)

Yes, this looks as if it will be an improvement. Art LaPella (talk) 21:06, 29 March 2010 (UTC)

Just as an in general FYI: I'm pretty busy for the next few days, but I have Thursday though monday off, so I planned to really help starting then. I'm right there with you on the suggested draft MOS. Personally, I'm more concerned with the sub-pages, primarily in reducing the number of them, but the main page should obviously come first... not quite sure where that leaves us, but there you go.
— V = IR (Talk • Contribs) 21:09, 29 March 2010 (UTC)

I think once we have sorted out the core of the MOS all those little satellites will take care of themselves. My plan involves going through them and putting them in the same order as the MOS itself. That process is no doubt going to lead to some consolidations, e.g. if people realise that the MOS satellites for various countries say basically the same things and can be merged. Hans Adler 22:33, 29 March 2010 (UTC)

I think this is going the right way. As you say, we need to ignore the content for now, but I think the structural approach is effective. On a detail, I'm not at all keen on the asterisks, for several reasons:

• In the TOC, their appearance is confusing; also, the fact that they're not themselves links undermines the expectation that subsequent ones are (even if it does then say so)
• In the summary, they don't make it obvious enough that there's a link to the detail section: I think that central fact must be made abundantly clear from first glance.
• Their use in more than one way is confusing. For instance:
  • Article titles and section headings* - asterisk provides a link to the corresponding detail section Article titles and section headings, whereas
  • Daughter articles. If a section is covered in greater detail in a "daughter" article, flag this by inserting {{main|Article name}} just under the section heading.* - asterisk might be expected to link to a detailed Daughter articles section, whereas it only links to the one-sentence WP:MOS#Main_article_link, "If the topic of a section is also covered in a dedicated article, then this should be marked by inserting {{main|Article name}} directly beneath the section heading."

The position of the asterisk of course helps to some extent, but I think that's too subtle.

For all these reasons, I'd prefer to scrap the asterisks and stick to wikilinking of pertinent words (adding such, where necessary to enable that). PL290 (talk) 08:42, 30 March 2010 (UTC)

Thanks for the excellent suggestion. I took the asterisks from Tony1's page, where they worked quite well, but I agree that there are some issues. For a busy page they are probably not suitable. I have implemented your first two points, since they are central to the demonstration. The last one is already outside the scope of the demonstration, as these links are just there to give a vague impression of what kind of content to expect in a final version. So I haven't done that yet. (Of course everybody is invited to edit the draft, but at some point we should start doing the real thing.) Hans Adler 09:37, 30 March 2010 (UTC)

The proposed new MOS structure visualised. Hans Adler 10:22, 30 March 2010 (UTC)

This approach, taken together with Tony's excellent "B's Guide to the MoS", is brilliant. I, too, would scrap the ******'s though: *they* just look silly**... *-) ... I like HA's boxed text, though: that looks very neat and professional; nagivation through that style also feels like much less of a challenge than it does in the usual sprawling mess of vaguely-structured-text into which these types of guideline tend to end up being converted over the years. The boxes compartmentalise the text and present it in logical small packets in a manner that section headings, alone, cannot, I feel, and suggest the "less is more" principle to any prospective editors. Many other reasons to accept this long-needed overhaul of the MoS but the preceeding comments have covered most of them and those that (undoubtedly) will follow are likely to cover the rest. Great work! --Jubilee♫clipman 09:34, 30 March 2010 (UTC)

Thanks! Hans Adler 09:39, 30 March 2010 (UTC)

Are people suggesting that the main MoS page be trimmed down? I got it down to about 40% of the current size in the Beginners' Guide, but it wasn't universally welcomed. The asterisks can easily be replaced by a work-link, but I was after a more compact, less cluttered way of linking than the current "Main page=" headlines. Where is WP:LINKING? I worry about the boundaries between format, language, etc. MOSNUM seems to fall between them. Tony (talk) 10:24, 30 March 2010 (UTC)

Well, you reduced it by using more concise wording, not by moving rarely-useful detail elsewhere. The result, while useful as a cheatsheet for someone who has already read the MOS but wants to quickly locate a particular piece of instruction he needs right now, is (IMO) way too terse as an introduction for someone who has never read a manual of style before. ― ___A._di_M. (formerly Army1987) 12:28, 30 March 2010 (UTC)

I'm with AdM on this point. Chances are, if you're on this page participating in conversations about italics with possessive tags and the proper placement of commas, then you've already trained yourself to pay attention to things like punctuation and formatting and you're pretty good at it. We need to put ourselves in the shoes of people who are either new to all this or not that good at it—and Wikipedia's MoS will have a higher proportion of those than say, the style sheets of most companies. This means that our MoS would do well to have 1. instructions phrased as instructions in complete sentences that say exactly what we mean, 2. examples for key pitfall areas, and, though a lot of you don't agree with me on this point, 3. a central location that doesn't require new Wikipedians to jump to six and seven different pages just to take a look at the basics. Darkfrog24 (talk) 13:26, 30 March 2010 (UTC)

I agree with these comments. In my opinion the brevity in the summaries for the main MOS page should be achieved by combining several positive examples into one, combining several important points together into a single sentence and forming paragraphs of such sentences, and leaving out everything that arises only rarely and some things that most readers take for granted anyway. (E.g.: "Normally, start every sentence with a capital letter.") And if something takes up too much room to explain properly, we can just say where to look it up. See #Abbreviations above for an example. Hans Adler 13:56, 30 March 2010 (UTC)

I agree with point 2, too, provided you mean real pitfalls and not imaginary ones (see WP:BEANS). ― ___A._di_M. (formerly Army1987) 15:51, 30 March 2010 (UTC)

Good point. The "pitfalls" need to highlight those that are actually happening and are relatively widespread rather than those of the "don't use salt instead of sugar in this recipe" type... --Jubilee♫clipman 16:29, 30 March 2010 (UTC)

Tony, I like your asterisks, but they are unusual and I guess they present a bit of an accessibility problem. I agree that the boundaries aren't entirely clear and I am not totally happy myself with the three subpages that I have proposed. I am sure they need some tweaking, and perhaps we will end up with two or four. But if the main MOS page remains as the main point of entry for all users, then everybody can see at a glance in which subpage a topic is covered and go there for details – if necessary. (Follow the interlanguage link to the French or German MOS equivalent, and I am sure you will be surprised by what you find. This proposal is much less radical.)

To prevent duplication and make everything totally transparent, in the case of a topic such as WP:LINKING that fits into several places, we can just put it on one subpage and mention it in a section "related topics" in the other. This will help people to find it even if they go directly to the wrong subpage.

A lot of people seem to like your MOS cheat sheet. I wouldn't be surprised if itself or a fork ended up as a semi-official part of the MOS in project space, perhaps as WP:Manual of Style (cheat sheet). If not I will propose linking it from a MOS sidebar, along with helpful essays. Hans Adler 13:56, 30 March 2010 (UTC)

I like the idea of a "cheat sheet". It would also serve new editors by giving them the most essential facts, if I am envisioning this correctly. Anyway, I too agree fully with DarkFrog re the confusion caused by multiple pages. One particular problem is "drift": the main page and the various subpages pages can end up saying subtly different—even contradictory—things. Avoiding and even fixing that problem would seem to be one major issue that would need to be addressed in any new system. Though I find it a pain in most cases (because I expect to be able to click the edit link at the top of the page and get on with editing rather than be confounded by a load of {'s and }'s...), transclution is probably the way forward, in this case, since it will avoid having to coordinate several pages. Other than that, perhaps a hidden "If you make changes here please be sure to make relevent changes in the main MoS, also, if necessary" and vice versa for the mainpage? Linking WP:Manual of Style (music), WP:Manual of Style (mathematics), etc, from a sidebar, or whatever, makes sense, as does refactoring them in like manner (though not all MoSes will necessarily fit into that plan, the music one for starters...) however these changes will need the consensus of numerous members of various WikiProjects. For the main MoS, though, I say go for it! --Jubilee♫clipman 16:13, 30 March 2010 (UTC)

Actually, Tony's page is more like a cheat sheet that tries to be complete.

I would like to start implementing my scheme right away with the first subpage, which I think is so clearly defined that its scope may not need revising. I think it's not such a big thing, as it consists of many incremental steps. Many of them will result in an improvement over the current chaos even if the process stalls at some point:

• Identify the pages that need merging.
• Leave a message on the talk page of each affected page, directing editors to join this discussion.
• After two days or so start the process for merging two of them.
• Continue until all are merged.
• Refactor the merged page so it starts with a summary fit for transclusion.
• Merge any relevant sections from the main MOS page into the new big subpage.
• Transclude the subpage into the main MOS page.

At that point we could stop and still have a tremendous improvement over the current situation. As I said, I would start right away, but unfortunately I will be (almost) without internet for the rest of the week and generally very busy in real life for the next two weeks. If someone wants to start it anyway, just make sure to stay relaxed. If there is any obstacle on the way (e.g. some page that doesn't want to be merged for whatever reason), just work around it for now. Hans Adler 16:40, 30 March 2010 (UTC)

What is the problem

1. Can someone clearly identity what the issue(s) are?
   1. Can you give some proper example not just the MOS is too big
2. What are are people trying to fix?
3. Are there any mocks up?

It seems to me that people who believe there is an issue are just rearranging the deck chairs on the the titanic Gnevin (talk) 18:54, 30 March 2010 (UTC)

Wikipedia:Manual of Style/Blazon is no longer marked as part of the Manual of Style

Wikipedia:Manual of Style/Blazon (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, 30 March 2010 (UTC)

Question about names

Not sure if this is the correct place to ask this but how should you refer to a person when their surname is shared by other people or by an organisation in the same article? Can you use their forename or do you have to use their full name every time? Thanks --86.171.97.248 (talk) 15:35, 30 March 2010 (UTC)

There's a sub-page on names. Here's the link to the relevant section: MoS:NAMES#Family_members_with_the_same_surname. It gives guidance about how to approach that question, including examples. PL290 (talk) 16:17, 30 March 2010 (UTC)

Thanks for the link. Would the same thing apply to organisations that share their founder's surname? The article I'm editing is McLaren (founded by Bruce McLaren). Is it correct to refer to him as "Bruce"?--86.171.97.248 (talk) 20:22, 30 March 2010 (UTC)

ENGVAR issue

Talk:Eastern Gray Squirrel#Spelling Revisited. Ucucha 19:50, 30 March 2010 (UTC)