Wikipedia talk:Manual of Style/Archive 147
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 140 | ← | Archive 145 | Archive 146 | Archive 147 | Archive 148 | Archive 149 | Archive 150 |
Help requested
There is a requested move in progress proposing moving the names of some Royal Navy ship types to lower case titles. If you understand what constitutes a proper noun, and the Wikipedia guidelines on capitalisation, please wade in. The discussion is being mainly conducted at Talk:Motor Gun Boat. Thanks. Shem (talk) 21:00, 21 October 2013 (UTC)
Proposal: Standardized notation for titling articles whose terms differ among the national varieties
In an international encyclopedia like Wikipedia, it is inevitable that some article titles will have to use language that is only correct in a subset of the various national varieties of a language and is not correct in all of them. This will force Wikipedia to show case by case a limited amount of favoritism to one national variety or another; and while this is unavoidable and therefore perfectly acceptable, it should be recognized as favoritism.
It is often found that the first line of the introductory paragraph of an article reintroduces the title term in bold; and in cases where national varieties differ on the term for the title subject, I propose that we adopt a standard notation that shows as little further favoritism as possible to the national variety used for the title. I propose that the standard notation be: TermA or TermB.
Some articles have taken to mentioning by name the regions which use a national variety different from that used in the title. I recently edited the article for cesium fluoride to this proposed standard; previously, it had read: caesium fluoride (or cesium fluoride in North America). The problem here is that the article calls out North America by name even while it uses the term "or" to denote the existence of multiple possibilities. This implies heavily that the there are multiple possibilities in North America; and by extension that the title term "caesium fluoride" is correct everywhere, whereas the national variety "cesium fluoride" is rather a mere colloquialism used by North Americans in place of the standard term. In reality most North Americans aware of the existence of cesium are unaware of the existence of any spellings of the word with an 'a;' and the academics who might know otherwise nevertheless use "cesium fluoride" and not the British spelling.
In any case, the topic "cesium fluoride" is not really improved by noting where people use which of its names (thus I support my first proposed standard), but should Wikipedia find that it is helpful to readers to know where people use which name, then I would propose that the standard notation for national variations be: TermA (TermB in RegionB). By leaving off the word "or," there is preserved the sense that in RegionB, TermB is the only correct variation; in most cases, this will be both more neutral and more factually correct. In a situation where a spelling popular in one national variety of a language is truly considered by the people of that national variety to be less correct than the variety used in the title, then inclusion of the subordinating "or" is appropriate; but this was not the case for cesium fluoride, nor I'm sure would it be true for the majority of the variation favoritisms shown by necessity on Wikipedia.
130.132.173.179 (talk) 05:49, 24 October 2013 (UTC)
- I think a form such as caesium fluoride (or cesium fluoride in North America) implies that North America is the exception to the standard that is accepted everywhere else, perhaps suggesting that North America is subjugated to the rest of the world. A more neutral representation would be Term A (in British English) or Term B (in American English) or XYZ-1 (mainly in North America) or XYZ-2 (mainly in the UK). Aside from the order in which the alternate terms are presented, these forms do not imply that any particular term is the "norm" and others are regional "exceptions". —sroc 💬 13:21, 24 October 2013 (UTC)
- Is it not the exception to the standard used elsewhere? There are far more varieties of English than British and American English you know. However, I would suspect that most non-American English-speakers (who vastly outnumber those in America) use the "British" form. There's no reason to parenthesise the American form (using "or" is fine, although it doesn't need a link to the MoS), but I think it's perfectly acceptable to specify that it is the American form. Stating that "caesium" is the British English form would be inaccurate, since it's doubtless also the form used in many other varieties of English. Stating that "cesium" is the American English form is entirely accurate. -- Necrothesp (talk) 13:38, 24 October 2013 (UTC)
- The "vastly outnumber" part is only if you count second-language speakers. Actually Americans make up more than 60% of first-language English speakers, worldwide. Now I have nothing against second-language speakers, but there's an enormous range of how much they use the language and how well they speak it, so it's hard to know how to count them. --Trovatore (talk) 19:50, 25 October 2013 (UTC)
- Let's remember that English is an official language of India, which has a much larger population than the USA. But the issue is not counting up the numbers of first- or second-language speakers (which is actually impossible to determine), but the distribution of the usage of the form around the world. I really do not believe that 60% of people who speak English speak "American English"! They speak a huge variety of forms of English. Do a majority of people who use the word spell it "cesium"? I very much doubt it. It is therefore perfectly acceptable to state that this is an American spelling. It is. Fact. -- Necrothesp (talk) 20:22, 25 October 2013 (UTC)
- It might be an official language in Inda, but that's a formality. Only a very small fraction of people grow up speaking it in the home.
- It is in no way acceptable to assume that Commonwealth English is the default and American English is a variant. ENGVAR says that they are on an equal basis.
- Now, as to c(a)esium specifically, the situation is slightly clouded by the fact that the Commonwealth spelling is also the IUPAC one, which I don't personally give much weight, but unfortunately other editors do. In chemistry articles specifically, the settled convention is to follow IUPAC for spellings (of element names at least). --Trovatore (talk) 20:54, 25 October 2013 (UTC)
- Are we not counting second-language speakers? Anyway, you'll note that I took care in my examples to include British English and American English versions in different orders in different examples to avoid bias. But I take the point that there are certainly other variants of English, but I suppose Term A (in British English, Australian English, New Zealand English and Indian English) or Term B (in American English) would become both unwieldy and incomplete. I still don't like the idea of singling out American English as an exception, but not sure how better to represent this. —sroc 💬 09:00, 26 October 2013 (UTC)
- I should imagine that most Indian people who are aware of the existence of caesium do speak English (since most educated Indians do - English being an official language is far more than a formality) and spell it "caesium". Nobody has suggested that Commonwealth English should be the default on Wikipedia. I'm not sure where you've got that from. But the fact that "cesium" is a spelling peculiar to North America and most of the rest of the English-speaking world (whether they speak English as a first language or second language) spell it "caesium" is a simple fact. We are usually in the business of recording facts. I have no idea why this should be an exception. If the American spelling was the world standard and the British spelling was peculiar to Britain I would support specifying this too. There's no nationalism involved here on my part, I assure you. -- Necrothesp (talk) 14:32, 26 October 2013 (UTC)
- There are basically two varieties of English spelling, Commonwealth and American (sometimes "North American"). On Wikipedia they have equal status. You don't get to promote Commonwealth higher by counting countries.
- In the specific case of chemical elements, in chemistry articles specifically, we follow IUPAC spelling — I don't necessarily like that but it's pretty well settled. So for caesium fluoride, yes, fine. Don't try to generalize it to colo(u)r! --Trovatore (talk) 19:46, 26 October 2013 (UTC)
- Nobody is! We are not talking about the article title in any case or even about in which variety of English the article should be written. That is fully defined in WP:ENGVAR and as far as I can see nobody is arguing with that. Certainly not me. We are talking about whether it should be specified that one version is specific to one country. This is very commonly done in thousands of articles and I don't see why there should be an exception here. -- Necrothesp (talk) 10:41, 28 October 2013 (UTC)
- Let's remember that English is an official language of India, which has a much larger population than the USA. But the issue is not counting up the numbers of first- or second-language speakers (which is actually impossible to determine), but the distribution of the usage of the form around the world. I really do not believe that 60% of people who speak English speak "American English"! They speak a huge variety of forms of English. Do a majority of people who use the word spell it "cesium"? I very much doubt it. It is therefore perfectly acceptable to state that this is an American spelling. It is. Fact. -- Necrothesp (talk) 20:22, 25 October 2013 (UTC)
- The "vastly outnumber" part is only if you count second-language speakers. Actually Americans make up more than 60% of first-language English speakers, worldwide. Now I have nothing against second-language speakers, but there's an enormous range of how much they use the language and how well they speak it, so it's hard to know how to count them. --Trovatore (talk) 19:50, 25 October 2013 (UTC)
- Is it not the exception to the standard used elsewhere? There are far more varieties of English than British and American English you know. However, I would suspect that most non-American English-speakers (who vastly outnumber those in America) use the "British" form. There's no reason to parenthesise the American form (using "or" is fine, although it doesn't need a link to the MoS), but I think it's perfectly acceptable to specify that it is the American form. Stating that "caesium" is the British English form would be inaccurate, since it's doubtless also the form used in many other varieties of English. Stating that "cesium" is the American English form is entirely accurate. -- Necrothesp (talk) 13:38, 24 October 2013 (UTC)
- Isn't this what we have {{redirects}} for? The initial author(s) gets to select which variety of English the article — and title! — conforms to, and any variant spellings are handled with redirects. Right? So why are we having this discussion? ~ J. Johnson (JJ) (talk) 21:57, 26 October 2013 (UTC)
- No, it isn't. This discussion is about referring to the subject of the article in the lead (and reflecting the various regional variations), not the actual title of the article. —sroc 💬 23:44, 26 October 2013 (UTC)
- Look, this is all well-settled stuff. See WP:ENGVAR. Any serious change to that would need a very wide discussion. The bottom line is, this particular article fits in the chemistry exception, and therefore we say caesium. --Trovatore (talk) 00:43, 27 October 2013 (UTC)
- So you are not concerned about the actual title itself. Is your concern in including variant spellings (including those of possibly regional significance)? Or supposed favoritism in how regions are identified? The simple answer to that is to leave off the region (locale). Sometimes caesium is spelled cesium — does it really matter where? ~ J. Johnson (JJ) (talk) 22:07, 27 October 2013 (UTC)
- Putting aside the example of caesium/cesium, there are cases where it is useful and informative to indicate where particular spelling variants are used. For example, see knit cap, which is variously known as bobcap (British English), stocking cap or watch cap (American English), beanie ("much of the English-speaking world"), touque (Canada), amongst other names. Then again, there's aluminium which simply begins: "Aluminium (or aluminum)…" without indicating where each spelling is used. —sroc 💬 00:47, 28 October 2013 (UTC)
- Although it probably would do if there wasn't a substantial section on etymology further down the article. -- Necrothesp (talk) 10:43, 28 October 2013 (UTC)
- Putting aside the example of caesium/cesium, there are cases where it is useful and informative to indicate where particular spelling variants are used. For example, see knit cap, which is variously known as bobcap (British English), stocking cap or watch cap (American English), beanie ("much of the English-speaking world"), touque (Canada), amongst other names. Then again, there's aluminium which simply begins: "Aluminium (or aluminum)…" without indicating where each spelling is used. —sroc 💬 00:47, 28 October 2013 (UTC)
- No, it isn't. This discussion is about referring to the subject of the article in the lead (and reflecting the various regional variations), not the actual title of the article. —sroc 💬 23:44, 26 October 2013 (UTC)
Look, none of this is about who uses what word where. It is also not about the fact that first titles will use whichever regional variant comes first. It is only about subject introductions that follow the title and which retitle the subject using the names of other regions. It is about whether names other than the title one ought to be labelled by region, and if so, it is about how the labeling should be tailored to the specific conditions encountered. Because quite apart from whether or not anyone thinks it's peculiar that Americans or Brits or Atlanteans spell anything any which way, there is the established certainty that you cannot call anything peculiar in an encyclopedia without breaking neutrality. Neither can you imply that a greater number of regional variants, total speakers, or native speakers makes one term more "standard" or more "universal" than another. It is indeed effectively nationalistic if you are setting any one thing as standard when there are multiple, equally unyielding paradigms reigning in multiple places, no matter how small or insignificant one paradigm may consider another to be, and no matter how solid you may consider your reasoning for establishing one or the other as correct.
Hence, my original suggestions: one, leave off the labeling; or two, stop applying the word "or," or any of its variants, in cases where the paradigm not represented in the title does not itself use the title term. Maybe caesium is the proper spelling even in America because of the standard set by IUPAC; and if so, that specific case's resolution is entirely irrelevant to the general notion that "or" should not be used when it implies the existence of options that don't exist.
Here's a better example of what I mean. I typed in the word "pants" in the search bar. In my country, that means trousers. Accordingly, I was redirected to the page for "trousers" where I was informed of this: "Trousers are an item of clothing worn from the waist to the ankles, covering both legs separately (rather than with cloth extending across both legs as in skirts and dresses). They are also called pants in the United States and some other countries."
I have absolutely nothing at all against the word "trousers," nor against its use as the title of the article; but my lack of antipathy toward the word "trousers" does not change the fact that it is still factually inaccurate to say that trousers are "also" called pants in the US. In the US, trousers are only called pants. It is far more factually accurate to say that "Trousers are called pants in the United States and some other countries," without applying frivolously the word "also" in a way that could be misinterpreted as an establishment of the universal standard-ness of the word "trousers" (Misinterpretation of the word "also" would, of course, require unfamiliarity with the distinctions between British and American culture; which is to say, it would require one to be the only kind of person who would actually need to look up what trousers/pants are in the first place.) — Preceding unsigned comment added by 130.132.173.179 (talk) 05:25, 30 October 2013 (UTC)
Translations
Over at String Quartet No. 14 (Schubert) we have an issue about translation. The article quotes (in its entirety) a translation of a German poem on which the quartet is based. The translation is quite free, and is, in fact, the translation that I have seen around. But an editor, quite justifiably, felt a literal translation would be better, which he did himself.
In my youth, many years ago, I remember reading a guideline about translations, but, for the life of me, I can't find it. Are original translations considered original research? Are they preferable to published translations which take freedoms? Do original translations (if allowed at all) have to be attributed to the translator? Ravpapa (talk) 04:36, 28 October 2013 (UTC)
- If a translation is substantial then it is considered a derivative work and is considered to have its own new copyright. It's one of the reasons publishers come up with new translations of Dante and Dostoevsky, etc. Each translation into English has its own copyright period and protections, even when based on a work in the public domain. An "Original Research" translation is less in the public domain than one from the distant past. A translation shouldn't be assumed to be in the public domain, even if the source is. ____ E L A Q U E A T E 08:59, 28 October 2013 (UTC)
WP:TIES applying to non-English-speaking nation?
There is currently a debate over at Talk:Case Closed#Requested move about whether WP:TIES applies to an article name on a topic that has strong ties to a particular non-English-speaking nation. In this case, a work was released under one English title in Japan, but used a completely different English title when it was released in the US, Canada, and the UK. 24.149.119.20 (talk) 10:58, 28 October 2013 (UTC)
- As it stands, WP:TIES explicitly only applies when "a topic that has strong ties to a particular English-speaking nation", so it doesn't support tying the article to the Japanese title. Many of the commenters in the RM appear to have recognised this. But NB, I wouldn't read WP:TIES as giving support to the US/Canada/UK title, either, since the game's ties to those nations does not seem stronger than its ties to Japan or other nations. -sche (talk) 19:00, 29 October 2013 (UTC)
- "a work was released under one English title in Japan": no, no, no, it was not. This is common marketing in Japan, to throw an "English title" somewhere on the packaging. This is not even remotely like releasing it "under one English title in Japan", especially since the game >>>wasn't released there in English under that title<<<. Curly Turkey (gobble) 11:33, 4 November 2013 (UTC)
Format for computer and video game titles
Wikipedia:Manual of Style#Names and titles says "Quotation marks should be used for the following names and titles:" and included in the list is "Computer and video games (but not other software)". However Wikipedia:Manual of Style/Text formatting#Names and titles says italic type should be used for "Computer and video games (but not other software)". Can anyone explain what seems to be a conflict, or propose how we should fix it? Thanks, SchreiberBike talk 05:22, 27 October 2013 (UTC)
- I propose removing "Computer and video games (but not other software)" from the Quotation marks section. The same text is already in the Italics section. SchreiberBike talk 17:06, 29 October 2013 (UTC)
- If there's no objection, I'll make the change proposed above in a few days. Thank you. SchreiberBike talk 21:39, 1 November 2013 (UTC)
- Italics is standard we use for VG titles at WP:VG, so no objection here. --MASEM (t) 22:07, 1 November 2013 (UTC)
- If there's no objection, I'll make the change proposed above in a few days. Thank you. SchreiberBike talk 21:39, 1 November 2013 (UTC)
- Change made per above.SchreiberBike talk 18:23, 4 November 2013 (UTC)
Query on the use of small caps
See Joan Pujol Garcia and Eddie Chapman.
In both of these articles small caps are used to denote their codenames. This seems somewhat jarring; is there a reason for it that I am unaware of? pablo 12:52, 29 October 2013 (UTC)
- My impression is that small caps is typographical convention for codenames, I've seen it in non-fiction books in the past but I can't cite a specific one. CombatWombat42 (talk) 14:54, 30 October 2013 (UTC)
- Whose convention though? Certainly not Wikipedia's as far as I can see, and not part of any style book I am aware of. (And these html-generated small caps are not pretty!) pablo 16:20, 30 October 2013 (UTC)
- WP:MOSCAPS is very clear; the small caps should be removed. Peter coxhead (talk) 17:43, 30 October 2013 (UTC)
- WP:MOSCAPS is not at all clear, it dosn't mention codenames at all. CombatWombat42 (talk) 17:49, 30 October 2013 (UTC)
- Since it does not mention them as an exception, the general rule “avoid writing with all capitals, including small caps. Reduce them to one of the other title cases or normal case, as appropriate” applies.—Emil J. 18:06, 30 October 2013 (UTC)
- That is true. I am of the opinion that an exception should be added, should we start that discussion? Here? A new section? CombatWombat42 (talk) 18:11, 30 October 2013 (UTC)
- Since it does not mention them as an exception, the general rule “avoid writing with all capitals, including small caps. Reduce them to one of the other title cases or normal case, as appropriate” applies.—Emil J. 18:06, 30 October 2013 (UTC)
- WP:MOSCAPS is not at all clear, it dosn't mention codenames at all. CombatWombat42 (talk) 17:49, 30 October 2013 (UTC)
- I suspect it is the convention of those orginsations that use codenames(CIA, NSA, MI5), we are certanly under no obligation to follow their convention, and I doubt they would release their conventions in any case, but to me I actualy like the small caps, it makes it clear it is a codename. CombatWombat42 (talk) 17:49, 30 October 2013 (UTC)
- I can only repeat that as the MOS stands, it is clear that code names should not be in small caps in Wikipedia. You can of course start an RfC to try to get the MOS changed, but the chances of this succeeding strike me as exceedingly small. Peter coxhead (talk) 18:26, 30 October 2013 (UTC)
- Even if we could determine that the TLAs (Three Letter Acronyms) used small caps for codenames, there would still be no reason that we should do it. I have seen no evidence that any published (unclassified) style guide uses small caps for codenames, and the MOS does seem clear to me. — Preceding unsigned comment added by Arthur Rubin (talk • contribs) 17:35, 1 November 2013 (UTC)
- I think they are unnecessarily forceful and that we should stick to our MOS. What makes it clear that they are codenames is stating that they are codenames :) --Stfg (talk) 18:17, 1 November 2013 (UTC)
- I don’t see the value in using small caps here. Sure, it makes the name stand out—but why? And I’m pretty sure that the words “given the codename …” makes it clear that it’s a codename, so there’s no need for formatting to make it stand out. One might say it looks neat, but unless I’m missing something, it’s wholly unnecessary. —Frungi (talk) 21:35, 2 November 2013 (UTC)
- support standard Wikipedia MOS, no need for a special exemption. -- TRPoD aka The Red Pen of Doom 14:35, 3 November 2013 (UTC)
- I can only repeat that as the MOS stands, it is clear that code names should not be in small caps in Wikipedia. You can of course start an RfC to try to get the MOS changed, but the chances of this succeeding strike me as exceedingly small. Peter coxhead (talk) 18:26, 30 October 2013 (UTC)
- WP:MOSCAPS is very clear; the small caps should be removed. Peter coxhead (talk) 17:43, 30 October 2013 (UTC)
I've started a discussion here as this is a military history question, it should be amended there, not on the main MOS. CombatWombat42 (talk) 18:40, 4 November 2013 (UTC)
Abuse of WP:TIES
WP:TIE WP:TIES stated "An article on a topic that has strong ties to a particular English-speaking nation[...]" So, what is an "English-speaking nation"? This comes up when I was dealing with the decade-old article name case, as the latest RM relies on this clause, despite the subject-matter is such non-English material as anime (Case Closed, if you ask). The OP and the supporters of the RM justified the OP's use of TIE on the following:
- English is used extensively in Japan and most people know the meanings of many loan words, e.g. "début" and "water".
- Actually WP:TIES apply to any Article with strong ties to a language of a nation, not just official language (English Language in this case). To say, there are many polyglots around the world, particularly the English Language and the Chinese Language.
- I can see how it might be a little bit of a stretch for articles about Japanese works, but Japanese culture does make use of English in an official capacity and IMHO it is a very important part of that culture. Without going in to too much depth English is seen as kind of cool and a bit exotic[...]
Personally I don't accept these justifications; you pick 100 random Wikipedians and more than half (and certainly even more) would say Japan is not an English-speaking nation. The lack of definition of that term, however, opens the door to abuse. Hence, I think it should be stated explicitly that policy is only available for ENGVAR and nothing else, and state what is an "English-speaking nation" in the meaning of this guideline.--Samuel di Curtisi di Salvadori 19:44, 3 November 2013 (UTC)
What is the relevance of this? The quote from your opening line is not in WP:TIE. If it was but has changed, what does it matter what it meant rather than what it says now? —sroc 💬 22:37, 3 November 2013 (UTC)- Ah, I think you meant WP:TIES ("Strong national ties to a topic"), not WP:TIE ("Translation"). Oops. I hope you don't mind that I've corrected the heading and link in your original post so others don't follow in my folly. —sroc 💬 22:42, 3 November 2013 (UTC)
- I don't think I care to give a once-and-for-all characterization of what an "English-speaking nation" is, but I do strongly agree that we should not count Japan.
- Now, assuming for the sake of argument that Japan were included, I don't think it's clear what direction that cuts for ENGVAR purposes. It's between American English and Commonwealth English; there is no Japanese English that's relevant to the discussion. But Japan has strong influences from both. --Trovatore (talk) 22:50, 3 November 2013 (UTC)
- Well... there is Engrish... which might be considered an ENGVAR, if you totally ignored the intent and twisted that policy sideways. Blueboar (talk) 23:03, 3 November 2013 (UTC)
- The issue has nothing to do with TIES. If Detective Conan doesn't appear as the title of any English translations of the work (a cute English subtitle is not a "translation of the work" by any stretch of the imagination), then it not only shouldn't, but can't be used as the title of the article. If there's no redirect from Detective Conan, then one should be made. Curly Turkey (gobble) 11:28, 4 November 2013 (UTC)
- It is made, long made--but it is not the venue to discuss an RM here, especially on a small-scale saga that's over 9 years old. I was writing here to ask for some clarification of this guideline.--Samuel di Curtisi di Salvadori 11:41, 4 November 2013 (UTC)
If my $0.02 means anything, Japan is most certainly not an "English-speaking nation", no matter how much I feel they have basic concepts down far better than any "native English speaker" I've met so far. Fortunately, names are supposed to be divorced from language squabbles, no matter how hard people try to ignore that.
In regards to Conan, "DETECTIVE CONAN" is most certainly an official translation, even if it's still an alternative title in the face of 名探偵コナン; per things like Attack on Titan, we generally use these "official readings" when referring to the original work. Thing is, article titles (and really, articles themselves) are usually based on localizations specifically made for English-speaking countries above all else. Not much more to it, really. Despatche (talk) 00:53, 5 November 2013 (UTC)
Collapsible galleries concerning content of difficult nature in medicine
I have a suggestion concerning collapsible galleries of images which by some may be deemed as very graphic or which retract from the average users ability to read an article, especially medical articles which can be considered rough by a large group of non medical professionals. WP:NOTCENSORED states:
Controversial images should follow the principle of 'least astonishment': we should choose images that respect the conventional expectations of readers for a given topic as much as is possible without sacrificing the quality of the article.
This I interpret as stating that images that convey the subject matter in a way that is comprehensible without disgusting the curious user is the best choice. This in no way means that these images always can explain all aspects of the article. So as not to scare off the regular reader pages such as Anencephaly may profit from a collapsible image gallery, such as:
Disclaimer: Graphic images |
---|
|
This removes risk of censorship while at the same time keeping the possibility for vulnerable users to avoid seeing the images, while being able to take part of the textual information. This may apply to quite a few medical articles.
Common practice at most European and American medical schools is to have ethical discussions and to offer counseling for students before entering difficult subjects such as anatomy and pathology. A naïve user stumbling upon these subjects does not have the support given to many medical and dentist etc. students, and as such may be deterred from Wikipedia after seeing these images. CFCF (talk) 23:04, 6 November 2013 (UTC)References after punctuation
What's with this guideline? It makes no sense when compared to things like logical quotation, and it certainly makes no sense within itself; the exceptions are completely arbitrary, especially because these dashes can be used in many of the same contexts as commas at least. I've even been told that references before punctuation hurts the base line somehow... but it's going to be hurt either way; just take a look at any complicated sentence that has multiple sourced (not "multiple-sourced") statements. Clearly, there is a need for "logical punctuation"? I can't be the only one who thinks this. Despatche (talk) 05:45, 4 November 2013 (UTC)
- There is an important difference between
".
(required sometimes in LQ but forbidden in the normal US punctuation style) and[1].
Since the raised reference link can be longer (e.g.[note 1].
), the ugly baseline blank span before the full stop can be much longer. Peter coxhead (talk) 11:09, 4 November 2013 (UTC)
- I concur with Peter coxhead. The baseline is not disrupted within the sentence by a footnote after the terminal punctuation (e.g.,
like this.[note 1] As opposed to this[note 2][clarification needed].
). —sroc 💬 22:20, 4 November 2013 (UTC)
- I concur with Peter coxhead. The baseline is not disrupted within the sentence by a footnote after the terminal punctuation (e.g.,
- Yes it is! This is insane, there is absolutely no difference between those two examples there. The important thing is that the punctuation has nothing to do with the reference, which is the exact same logic behind LQ. That basic logic is going to beat some perceived "ugliness" that is still going to be there no matter how you handle it. What we have now is nonsensically arbitrary and completely inconsistent, and I'm suddenly very curious as to how LQ has gotten anywhere with anyone. Despatche (talk) 00:38, 5 November 2013 (UTC)
- "the punctuation has nothing to do with the reference": That's silly; the punctuation has everything to do with a well-formed sentence. The reference refers to the content of the sentence, not the form (unless it's a quotation). Curly Turkey (gobble) 01:30, 5 November 2013 (UTC)
- There is a difference between these examples:
- like this.[note 1]) — the full stop is neatly next to the final word.
- As opposed to this[note 2][clarification needed].) — the full stop is divorced from the final word.
- The first example is easier to read, hence it is preferred.
- With regard to your point
"the punctuation has nothing to do with the reference"
, consider these examples:- This is a fact.[1]
- This is a fact[1].
- It is a nonsense to argue whether the reference supports the sentence with or without punctuation, as the reference supports the fact however it is written.
- The Earth orbits the Sun[2] and the Moon orbits the Earth.
- The Earth orbits the Sun and the Moon orbits the Earth.[2]
- In this case, the reference supports the fact that the Earth orbits the Sun but not that the Moon orbits the Earth, so the footnote needs to appear after the relevant text to make this distinction clear.
- The Earth orbits the Sun and the Moon orbits the Earth[3].
- In this case, the reference supports the fact that the Moon orbits the Earth but not that the Earth orbits the Sun. Putting the superscript before the punctuation doesn't serve to make this distinction clearer, so more would need to be done (e.g., by stating in the footnote what it actually supports or by providing an additional footnote for the other claim) — see WP:INTEGRITY. —sroc 💬 01:18, 5 November 2013 (UTC)
- I'd also add that the situation by white space is worsened when we talk commas and not periods. --MASEM (t) 01:24, 5 November 2013 (UTC)
- Surely the point is also that LQ is common in the real world and the proposed footnoting style is not. We have a real-world justification for endorsing LQ (even if maybe not for requiring it, but that's another matter) but do not for the proposed punctuation style for footnoting, regardless of whether the current style "makes no sense" to individual editors when contrasted with the principles underlying LQ (which is a debatable argument anyway). N-HH talk/edits 09:44, 5 November 2013 (UTC)
- I'd also add that the situation by white space is worsened when we talk commas and not periods. --MASEM (t) 01:24, 5 November 2013 (UTC)
- Yes it is! This is insane, there is absolutely no difference between those two examples there. The important thing is that the punctuation has nothing to do with the reference, which is the exact same logic behind LQ. That basic logic is going to beat some perceived "ugliness" that is still going to be there no matter how you handle it. What we have now is nonsensically arbitrary and completely inconsistent, and I'm suddenly very curious as to how LQ has gotten anywhere with anyone. Despatche (talk) 00:38, 5 November 2013 (UTC)
Has this guideline changed recently? I am seeing Yobot moving many citations in front of full stops. Strange that this has not been picked up at WP:FAR. I've been adding citations after punctuation for many years believing this is the correct method. Nimbus (Cumulus nimbus floats by) 17:13, 7 November 2013 (UTC)
- Might be my eyes as it seems to be working correctly but the edit summary is very misleading (References before punctuation), it seems to be moving citations in both directions. Nimbus (Cumulus nimbus floats by) 17:53, 7 November 2013 (UTC)
- Today it did this one, and I can't for the life of me see anything there other than the removal of a redundant space at the end of a paragraph. That kind of edit is highly annoying, because of its effect on watch lists. --19:09, 7 November 2013 (UTC)~
- Nope, can't see what it did there either!! True, the bots do light up the watchlist annoyingly and because I don't trust them after the dates and numbers saga I check them all. I assume this bot has gained approval to carry out mass changes in accordance with a guideline, not a policy? The edit summary is definitely misleading, watching it closely. Nimbus (Cumulus nimbus floats by) 22:02, 7 November 2013 (UTC)
RFC: Should it be "optional" as to whether a second comma after a date/place should be included?
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This RFC concerns policy from WP:MOSNUM (MOS:DATEFORMAT and MOS:BADDATEFORMAT), MOS:COMMA, and WP:NCPLACE:
My proposal is that instead of being mandated or not being mandated, MOS should be changed to make it optional as to whether a comma should be included after a date or a place: April 14–16, 2011 tornado outbreak or April 14–16, 2011, tornado outbreak; Rochester, New York metropolitan area or Rochester, New York, metropolitan area. If passed, a second part of this proposal would mandate that all pages within a certain Project be the same. This means that the comma would be optional on the "national" standpoint, but one version would be mandated by a discussion from a "local" Project standpoint (all pages within any Project either with the comma or without the comma). This allows members of a project to decide themselves on what to do and prevents ridiculously long site-wide discussions such as this. United States Man (talk) 19:45, 25 October 2013 (UTC)
- Note: I realized after several editors had already commented that I had left out the important part that this should only apply to titles and not sentences within an article, which should have the second comma. I was alerted to this after User:sroc's comment in a below section. United States Man (talk) 15:29, 26 October 2013 (UTC)
Second Note: Another issue that I did not think about was the use of the date or place as an adjective: July 12, 2007 Baghdad airstrike or Graniteville, South Carolina train crash. Per reasons above, I propose that this also be made optional. United States Man (talk) 16:58, 26 October 2013 (UTC)
- I failed to realize the connection between my correction and what I had already said. I mistakenly corrected something that was already correct and I will thus strike out the above comment. United States Man (talk) 17:16, 27 October 2013 (UTC)
This would be an ideal situation if the RfC is passed:
- General rule: include a comma after the year in m–d–y dates (e.g., On November 24, 1971, Cooper hijacked a Boeing 727 aircraft.)
- General rule: include a comma after the state/country (e.g., The plane took off from Portland, Oregon, and was headed east.)
- Exception: use as an adjective (especially in a date or place) is optional in article titles only, according to Project preference (e.g., July 12, 2007 Baghdad airstrike / July 12, 2007, Baghdad airstrike or Graniteville, South Carolina train crash / Graniteville, South Carolina, train crash)
— Preceding unsigned comment added by United States Man (talk • contribs) 13:15, Today (UTC+11)
Support
- Support, especially when a date/place is used as an adjective, as it is with the tornado and Rochester examples. For authority, see Garner's Modern American Usage, pp.225-226. Here are some excerpts:
- "Stylists who use [the Month Day, Year] phrasing [as an adjective] typically omit the comma after the year, and justifably so: in the midst of an adjective phrase (i.e., the date), it impedes the flow of the writing too much."
- "The idea of the comma after the year, as it has commonly been taught, is that the year is in apposition, so the second comma is required....The more plausible argument - supporting the absence of the comma after the year - has two parts. First, the comma is really just separating the two numerals, so if a second comma isn't syntactically required, then it doesn't belong....Second, the comma after the date marks a nonexistent pause: when a full date is used adjectivally, a knowledgeable speaker of the phrase marches toward the noun instead of pausing after the year."
- "It makes little sense to punctuate a forward-looking adjective with a pause at the end of it."
- "Most usage books that call uniformly for a comma after the year in a full date, by the way, don't address the question raised just above. They show the comma without illustrating what happens when the date functions as an adjective. In other words, they illustrate the easy cases, not the more difficult ones."
- We should not mandate an awkward second comma where it is not syntactically required, especially when omitting it is already WP practice, and when omitting it is recommended by a major style guide such as Garner. Dohn joe (talk) 21:01, 25 October 2013 (UTC)
- The authority you cite specifically relates to dates in m–d–y format, so this only addresses half of the proposal. As to using placenames as adjectives, Garner says this:
- "The practice of using as adjectives place names having two or more words is generally to be resisted. But it is increasingly common. Although California home and Austin jury are perfectly acceptable, Sacramento, California home and Austin, Texas jury are not. To make matters worse, some writers place a second comma after the state. Thus, using a city plus the state as an adjective disrupts the flow of the sentence [example omitted]. Such constructions contribute to NOUN PLAGUE, lessen readability and bother literate readers."
- Thus, place names with commas should not be used as adjectives; rather such titles should be rephrased to avoid the awkward construction, not adopt a faulty style. —sroc 💬 23:35, 26 October 2013 (UTC)
- Yes, and even about dates, Garner says
- "Modern writers have taken to making adjectives out of dates, just as they do out of place names—e.g. 'His 1998 book contract ...' ... Although occasionally using dates adjectivally is a space-saver, the device should not be overworked: it gives prose a breezy look.
"And the practice is particularly clumsy when the day as well as the month is given—e.g.: '... its July 12, 2001 privilege order.'"
- "Modern writers have taken to making adjectives out of dates, just as they do out of place names—e.g. 'His 1998 book contract ...' ... Although occasionally using dates adjectivally is a space-saver, the device should not be overworked: it gives prose a breezy look.
- (my emphasis). And note that Garner explicitly acknowledges that his position on the comma differs from that of most style guides. --Stfg (talk) 09:00, 27 October 2013 (UTC)
- Well, no - Garner says that most guides don't address the date-as-adjective situation. He also says that most stylists who do use that construction omit the second comma. Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- Yes, and even about dates, Garner says
- The authority you cite specifically relates to dates in m–d–y format, so this only addresses half of the proposal. As to using placenames as adjectives, Garner says this:
- Dohn joe: Omitting the second comma is not recommended by any style guide I'm aware of. In fact, using an adjectival form where you could use two commas is recommended against in every major style guide where I've seen it mentioned, particularly Garner's. —Frungi (talk) 07:46, 1 November 2013 (UTC)
- Support Largely per Dohn joe. These commas can be disruptive and rarely help with any actual clarity issues. I'd almost prefer to proscribe them altogether, but if I think really hard, I can almost conceive of a case where it might be desirable to include them. Might as well let it be a local decision. --BDD (talk) 01:45, 26 October 2013 (UTC)
- BDD: Do you still support applying this to placenames used as adjectives despite the extract from Garner quoted above? —sroc 💬 23:41, 26 October 2013 (UTC)
*Support, for reasons listed from Garner's above. "National" varieties of English shouldn't matter as much as clarity and readability in the English language Wikipedia. Reify-tech (talk) 11:46, 26 October 2013 (UTC)
Reify-tech: Do you still support applying this to placenames used as adjectives despite the extract from Garner quoted above? —sroc 💬 23:41, 26 October 2013 (UTC)(Reversed position; see below)
- Support—optional, and I agree with sroc that individual projects should not read this as a sign that they are free to straightjacket their editors into one or the other. Within-article consistency is the most important issue. Although I think this is not an issue on which the MOS should mandate a single style, my personal preference is not to punctuate unless it makes it easier for the reader. Tony (talk) 12:38, 26 October 2013 (UTC)
- I note the excuse often given is that a particular title format needs to be adopted for "title stability" because "it's always done that way" even if it goes against the style guides. (See this list of pertinent examples.) I suspect this may be what United States Man is trying to address, allowing such users to rely on this to say: "Ah, but this exemption allows us to ignore the general rule!" in order to shout down those that insist on using style consistently in titles as with article bodies. —sroc 💬 23:22, 26 October 2013 (UTC)
- Wikiprojects should follow the centralised style guide unless there's a strong reason not to (and not personal prefs). Where there's an issue, it should be raised on this page first to allow the community to debate the matter. Tony (talk) 09:10, 27 October 2013 (UTC)
- I note the excuse often given is that a particular title format needs to be adopted for "title stability" because "it's always done that way" even if it goes against the style guides. (See this list of pertinent examples.) I suspect this may be what United States Man is trying to address, allowing such users to rely on this to say: "Ah, but this exemption allows us to ignore the general rule!" in order to shout down those that insist on using style consistently in titles as with article bodies. —sroc 💬 23:22, 26 October 2013 (UTC)
- Support There is no reason to require the second comma, and in my experience it is usually omitted (I wonder if it is more common in the US). As Garner says, the first comma is just separating the two numbers, so there is no syntactic need for a second one. Neljack (talk) 11:38, 1 November 2013 (UTC)
- Support per Dohn joe. SlimVirgin (talk) 18:19, 4 November 2013 (UTC)
Oppose
- Strongly oppose: Firstly, the proposal is not restricted to the uses of places or dates as adjectives, despite the examples given. As such, the omission of the final comma in expressions such as he died on July 14, 2013 in Austin, Texas with his wife by his side is simply wrong and against the style guides. Secondly, style issues may vary according to national varieties (e.g., British English vs American English) but the use of commas in this way does not vary by "local" usage and should not be determined by individual projects in ways that contradict other projects, as this merely promotes inconsistency and confusion. —sroc 💬 08:36, 26 October 2013 (UTC)
- Also:
"This allows members of a project to decide themselves on what to do and prevents ridiculously long site-wide discussions such as this."
This argument ignores the likely outcome that "members of a project" will have "ridiculously long" arguments over which form to adopt. Much better to have a standard, Wikipedia-wide policy and avoid factional breakaway style policies. —sroc 💬 08:45, 26 October 2013 (UTC)- I amended the proposal to make it only apply to titles (which I mistakenly left out before), so that the use of the comma in sentences (which I agree with) is still mandated. Also, apply some common sense to your statement about the style issues and inconsistency. How many people in the world do you think are going to notice that. As long as all similar pages are the same, there should be no problem. United States Man (talk) 15:29, 26 October 2013 (UTC)
- Thanks for the important clarification; I'm not quite so strongly opposed now. I'm not sure I follow your "common sense" comment though, as I don't think that exempting titles really avoids arguments over proper usage; if anything, a clear style guide would avoid arguments on individual projects. It also seems that if we have one rule for proper usage in sentences but explicitly say that the rule does not apply to titles, then it tends to favour the converse construction for titles (e.g., use September 11, 2001 attacks in the title but September 11, 2001, attacks in the text), which only promotes inconsistency. —sroc 💬 16:12, 26 October 2013 (UTC)
- As I said, that will not be noticeable be many people, and most of those will probably not put it together. It is obvious that many people do not like the second comma in the titles, so relegating it to a Project discussion will (probably and hopefully) limit it to just one discussion. If anyone else pops up, that discussion could easily be "squashed." But, if it is kept at a site-wide standpoint, the same discussions (which, from that level, are not as easy to dismiss) will just keep coming and never rest. United States Man (talk) 16:44, 26 October 2013 (UTC)
- Again, I don't follow your logic that having differing policies for article titles vs running prose and then allowing individual projects to have their own individual style policies will avoid arguments. If anything, it will just mean every project will have its own little arguments without a clear overall guideline to refer to. In any case, having an overall guideline is never a guarantee that arguments will not flourish, as evidenced by the recent discussions over Rochester despite having guidelines in the MOS guidelines you mentioned — after all, consensus can change and renewed discussion may be needed from time to time, but it will be better informed and more productive if such conversations are had in a central place related to WP-wide style rather than individual micro-discussions on 1000s of different projects. —sroc 💬 23:01, 26 October 2013 (UTC)
- As I said, that will not be noticeable be many people, and most of those will probably not put it together. It is obvious that many people do not like the second comma in the titles, so relegating it to a Project discussion will (probably and hopefully) limit it to just one discussion. If anyone else pops up, that discussion could easily be "squashed." But, if it is kept at a site-wide standpoint, the same discussions (which, from that level, are not as easy to dismiss) will just keep coming and never rest. United States Man (talk) 16:44, 26 October 2013 (UTC)
- Thanks for the important clarification; I'm not quite so strongly opposed now. I'm not sure I follow your "common sense" comment though, as I don't think that exempting titles really avoids arguments over proper usage; if anything, a clear style guide would avoid arguments on individual projects. It also seems that if we have one rule for proper usage in sentences but explicitly say that the rule does not apply to titles, then it tends to favour the converse construction for titles (e.g., use September 11, 2001 attacks in the title but September 11, 2001, attacks in the text), which only promotes inconsistency. —sroc 💬 16:12, 26 October 2013 (UTC)
- I amended the proposal to make it only apply to titles (which I mistakenly left out before), so that the use of the comma in sentences (which I agree with) is still mandated. Also, apply some common sense to your statement about the style issues and inconsistency. How many people in the world do you think are going to notice that. As long as all similar pages are the same, there should be no problem. United States Man (talk) 15:29, 26 October 2013 (UTC)
- Strongly oppose; I see no reason to treat article titles differently than running prose. Powers T 19:07, 26 October 2013 (UTC)
- Strongest possible oppose (a) That "ridiculously long site-wide discussion" took ages and never reached consensus, and now you're dragging us through that stuff yet again? We flogged this to death. How many bites of the cherry do you want? I feel badly put upon by this, and consider this RFC to be serious disruption. We have better things to do than argue about commas every other month. (b) Has everyone who took part in that discussion been notified of this one? Certainly not, since I wasn't. It would be going behind their backs if you fail to do so. (c) The proposal is not properly thought through: the examples in your main proposal are all cases of "the use of the date or place as an adjective", so why the afterthought in the second note? What other forms of title do you envisage, apart from those employing that adjectival use? (d) The normal approach of WP:STYLEVAR is consistency on a per article basis, not on a per project basis. That idea just threatens multiple project-wide debates about this subject, with instruction creep the end result. --Stfg (talk) 19:39, 26 October 2013 (UTC)
(e) Garner, who is being quoted as the authority for this, admits that he differs from most other style guides on this point, states "The practice of using as adjectives place names having two or more words is generally to be resisted", and calls the adjectival use of the mdy construction, even without the trailing comma, as "particularly clumsy". Yet these are what we are being asked to tolerate. (Item (e) added by --Stfg (talk) 15:24, 27 October 2013 (UTC))
- As I just noted above, Garner actually says explicitly that most stylists that use the adjectival construction omit the second comma. He goes on to say that most guides do not offer guidance about it. Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- I removed the second note after realizing what I had done (you are the only one who commented on it so it won't affect the discussion). To address your (b) comment, I had not got around to notifying anyone yet. I was planning on doing it and will still do it (after all, these last about a month). And to address (d), as I have tried to explain above to sroc, I have personally seen that after members of a project have reached a consensus, they will be quick to dismiss any new arguments (unless they are different and well thought out) and prevent endless discussions that keep popping up. I have observed that site-wide discussion such as this keep going forever and (especially in this case) never end. United States Man (talk) 02:10, 27 October 2013 (UTC)
- Please restore note 2 and then, if you wish to, strike it. You have orphaned my comment, and although nobody else mentioned it, they may have considered it. You are giving us a moving target. Your reply to (d) doesn't address my points. Please don't delay in notifying previous participants. Any delaying may distort things. Please explain why raising this RFC so soon after the previous one is not tendentious and disruptive. I am considering taking this to ANI, you know. --Stfg (talk) 10:03, 27 October 2013 (UTC)
- Please tell me just exactly how you can take this to ANI because I started an RFC. The last time I checked, any editor is free to do that any time he/she feels. You say it is "tendentious and disruptive." That is entirely your opinion and if you didn't like this RFC, then you didn't have to comment here. United States Man (talk) 17:16, 27 October 2013 (UTC)
- "if you didn't like this RFC, then you didn't have to comment here" -- that's exactly the problem: the expectation is that the opposition will tire; we either have to give in or spend yet more time. That is why it's disruptive. It's tendentious because we are being dragged back to issues we discussed massively very recently. There's nothing new here at all. ANI is not only to beat up on editors, and I haven't done so. What I've done is here. --Stfg (talk) 18:16, 27 October 2013 (UTC)
- Please tell me just exactly how you can take this to ANI because I started an RFC. The last time I checked, any editor is free to do that any time he/she feels. You say it is "tendentious and disruptive." That is entirely your opinion and if you didn't like this RFC, then you didn't have to comment here. United States Man (talk) 17:16, 27 October 2013 (UTC)
- Please restore note 2 and then, if you wish to, strike it. You have orphaned my comment, and although nobody else mentioned it, they may have considered it. You are giving us a moving target. Your reply to (d) doesn't address my points. Please don't delay in notifying previous participants. Any delaying may distort things. Please explain why raising this RFC so soon after the previous one is not tendentious and disruptive. I am considering taking this to ANI, you know. --Stfg (talk) 10:03, 27 October 2013 (UTC)
- Oppose: I'd plead for this differentiation – in all instances. (from a practical standpoint, if you compartmentalize the issue into individual projects, I'd presume the situation is bound to get even worse) – ὁ οἶστρος (talk) 12:54, 27 October 2013 (UTC)
- Oppose. I stand by my previous comment, this being essentially part of the previous proposal. It looks awkward with the comma, and wrong without the comma. I'd rather we look awkward than wrong. — Arthur Rubin (talk) 15:23, 27 October 2013 (UTC)
- What's your justification for calling the one-comma construction "wrong"? Garner doesn't think so.... Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- Garner doesn't like the construction, with or without a second comma. I don't see how his commentary helps to support this. — Arthur Rubin (talk) 04:55, 28 October 2013 (UTC)
- Garner is the only style guide that makes an exception. As you know, Chicago Manual of Style states that this construction should be avoided as "a second comma may be deemed obligatory" and many other style guides require the second comma and make no exception for adjectives. So there's your justification for calling the one-comma construction "wrong". —sroc 💬 10:58, 28 October 2013 (UTC)
- What's your justification for calling the one-comma construction "wrong"? Garner doesn't think so.... Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- Oppose because these commas are needed. They are needed for clarity, and that's why they are required by standard rules of punctuation. --Orlady (talk) 19:26, 27 October 2013 (UTC)
- Please see above - Garner does not require that second comma, and rather eloquently argues against it both grammatically and syntactically, don't you think? Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- See above — Garner is one source at odds with others. —sroc 💬 10:58, 28 October 2013 (UTC)
- Please see above - Garner does not require that second comma, and rather eloquently argues against it both grammatically and syntactically, don't you think? Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- Oppose: adjectives comprised by "Location, State" or "Date, Year" are not ideal, but introducing a grammatical error by omitting the comma just makes everything worse. As Orlady said, it's standard rules of punctuation. HandsomeFella (talk) 20:10, 27 October 2013 (UTC)
- Please see above - it's not an error. Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- See above — Garner is one source at odds with others. —sroc 💬 10:58, 28 October 2013 (UTC)
- Please see above - it's not an error. Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- Oppose: I don't see the need for changing the existing policy. Chris Troutman (talk) 20:15, 27 October 2013 (UTC)
- Oppose: if the correctly-punctuated result looks awkward, then rephrase. As I’ve remarked at WT:MOSNUM#Comma after the year in MDY format where the date is an adjective, I don’t think adjectival uses deserve exception. I’m not generally opposed to projects’ using a ‘house style’ for the nomenclature specific to their areas of interest, but I draw the line at allowing local deviations from general principles, especially considering the large number of articles that fall within the purview of multiple projects.—Odysseus1479 00:23, 28 October 2013 (UTC)
- Please see above - the one-comma construction is not incorrectly punctuated. Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- See above — Garner is one source at odds with others. —sroc 💬 10:58, 28 October 2013 (UTC)
- Please see above - the one-comma construction is not incorrectly punctuated. Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- Oppose. First of all, there is already a discussion about at least one aspect of this, which is located here. It hasn't really been resolved, to the extent that that's even possible, and I don't see how having this (almost) same discussion all over again is going to be productive. Furthermore, WP:USPLACE already says "When a place name continues past the state name, as in City, State, metropolitan area, a comma is normally included before and after the state name (see MOS:COMMA)." Are we going to change that, too? I foresee a beast of a discussion. Second, if we are going to have this discussion again, I'd like to point out that the article title "Rochester, New York metropolitan area" is particularly terrible because, based on the way other Wikipedia articles are titled, it suggests that "Rochester" is a place within the "New York metropolitan area". Obviously it isn't, but how are random readers from other countries supposed to know that? This is why we should properly use commas, to keep people from being confused. Moreover, if people think it's too awkward to use so many commas, the titles can always be rephrased, to maybe "Rochester metropolitan area (New York)" or something else like that. Third, I think it's a terrible idea to allow various local consensuses of different wikiprojects to create their own rules about when people should and shouldn't use commas. It's hard enough to figure out what the grammar and style rules are here if you aren't familiar with them without having to consult myriad other wikiproject pages, and furthermore, I think especially with article titles at least some level of internal consistency is desirable. AgnosticAphid talk 17:12, 28 October 2013 (UTC)
- Oppose (after reconsidering the issue) Although the construction with more commas can be awkward at times, it is often needed for clarity, which is more important than the secondary goal of smooth readability. Perhaps the MoS should recommend recasting a sentence if it is awkward, and give an example. Also, the optional use of semicolons with commas in lists (WP:SEMICOLON) should be cross-referenced. Reify-tech (talk) 18:50, 28 October 2013 (UTC)
- Note that MOS:COMMA already states: "Modern practice is against excessive use of commas; there are usually ways to simplify a sentence so that fewer are needed." Even so, I would be in favour of including a comment or revising this statement along the lines: "It may be particularly desirable to re-phrase article titles to avoid the need for additional commas after place names or dates." —sroc 💬 22:55, 28 October 2013 (UTC)
- Strong oppose: I don't know if this is the general consensus, but to me at least, consistency between articles and their own titles is important. Also, I could have sworn it was a rule that titles are written as they would be in running text, barring technical restrictions or parenthetical disambiguation—that is, if you'd use a comma in a sentence, you use it in the title, and if you don't, you don't. —Frungi (talk) 07:39, 1 November 2013 (UTC)
- Oppose – Am I wrong in my impression that essentially all grammar and style guides indicate that these commas are needed to make the grammar correct? Are we proposing to re-invent grammar rules, or is there some set of sources in support of this approach? Dicklyon (talk) 03:22, 4 November 2013 (UTC)
- Well, yes - wrong on both counts. As Garner says, (and as I have pointed out repeatedly, here and elsewhere), "Stylists who use [the Month Day, Year] phrasing [as an adjective] typically omit the comma after the year." Others have noted the split in guidance as well. The Punctuation Guide, an online resource, says that "When a date is used as an adjective, some authorities omit the comma following the year, yet others require it." Also see the Franklin Covey Style Guide, 5th ed., p.256: "Both versions are "correct." Both are acceptable because the presence or absence after [the year] does not affect clarity." This is purely an issue of style, not grammar. We are not reinventing grammar rules any more than Garner or Franklin Covey are. One can prefer one way or the other stylistically, but either is just fine grammatically. Dohn joe (talk) 17:57, 4 November 2013 (UTC)
- I think my "essentially all" is still a fair characterization. Dicklyon (talk) 05:35, 7 November 2013 (UTC)
Other suggestions
- I would support the MOS stating a preference... Oppose making that preference mandatory. Blueboar (talk) 13:29, 26 October 2013 (UTC)
- I would prefer recommending that such adjectival forms be avoided, especially as article titles. Agree that the MOS should not mandate a single style though, in particular if the usage reflects the style in reliable sources. older ≠ wiser 13:57, 26 October 2013 (UTC)
- I agree with Bkonrad on this, at least in titles; the only situations in which I'd suggest that PLACENAME, PLACENAME be in a title is either when that's the entire name of the article, e.g. Monowi, Nebraska, or when it's at the end of the name, e.g. History of Charleston, South Carolina. We entirely avoid the issue in this manner. No comment on the rest of the discussion. Nyttend (talk) 02:37, 27 October 2013 (UTC)
- Are you suggesting that the MOS should recommend that article titles involving dates/place names as adjectives (relating to events, for example) be modified thusly: Baghdad airstrike of July 12, 2007; Train crash at Graniteville, South Carolina? I would support that. —sroc 💬 04:40, 27 October 2013 (UTC)
- So would I, especially since Garner himself calls the July 12, 2007 Baghdad airstrike construction "clumsy". --Stfg (talk) 09:03, 27 October 2013 (UTC)
- Sroc, yes. IMO Baghdad airstrike of July 12, 2007 is a far superior title for the purposes of searching (e.g., the progressive drop-down of the internal search). And unless there is some other notable train crash at a different Graniteville, Graniteville train crash is sufficient. older ≠ wiser 11:41, 27 October 2013 (UTC)
- I am through with starting RFCs, so if someone else wants to start one (preferably after we see where this one goes) I would support that as well. Although, the only downside is that it is longer and WP:SEVERE would have dozens of pages named "Tornado outbreak of ..." which can get old after awhile. United States Man (talk) 17:16, 27 October 2013 (UTC)
- Sroc, yes. IMO Baghdad airstrike of July 12, 2007 is a far superior title for the purposes of searching (e.g., the progressive drop-down of the internal search). And unless there is some other notable train crash at a different Graniteville, Graniteville train crash is sufficient. older ≠ wiser 11:41, 27 October 2013 (UTC)
- So would I, especially since Garner himself calls the July 12, 2007 Baghdad airstrike construction "clumsy". --Stfg (talk) 09:03, 27 October 2013 (UTC)
- Are you suggesting that the MOS should recommend that article titles involving dates/place names as adjectives (relating to events, for example) be modified thusly: Baghdad airstrike of July 12, 2007; Train crash at Graniteville, South Carolina? I would support that. —sroc 💬 04:40, 27 October 2013 (UTC)
- Regardless of the ultimate decision, I think consistency is important. We shouldn’t use the comma in some places and not in others. If it’s decided to have no comma after a disambiguating adjectival place name or year in article titles, we should have no such comma project-wide, in titles or in running text. Same if it’s decided to require a comma. Make a style/grammar decision and stick to it consistently.
That said, I’ll have to side with every major usage guide alongside several others here in discouraging the compound adjectival use entirely. This means we should never use Graniteville, South Carolina[,] train crash, but Graniteville train crash or train crash in Graniteville, South Carolina. —Frungi (talk) 21:56, 27 October 2013 (UTC) - I would not necessarily be against a recommendation against using the form. But not because using one comma in an adjectival construction is wrong. Dohn joe (talk) 04:28, 28 October 2013 (UTC)
- Alternative proposal. Looking for common ground.... From my reading of the !supports and !opposes, some people have reservations about treating titles differently from text, some have noted the difference between adjectival use and non-adjectival use, and some have expressed concerns about letting Projects make their own style decisions that may be inconsistent with broader MOS guidance. I think that I may have found a solution that will satisfy most of the participants in this discussion.
My proposal basically keeps current guidance on final comma usage, with three exceptions - 1) when the place name/date is followed by other punctuation (this improves the the current "except at the end of a sentence" exception, which does not take into account place names/dates followed by a colon or closed parentheses, etc.); 2) when the place name/date is used by itself (as in a title or list - this should address the "title vs. text" concern; and 3) when the place name/date is used as an adjective. We then explicitly state that the adjectival use can be unwieldy, and recommend against using it.
This proposal puts the MOS in line with major style guides in recommending avoiding the adjectival construction. It also lets us follow Garner in dropping the second comma when it is not required for syntax. (And for those who say that Garner is only "one" guide, it is one of the four major style guides in the English language, along with Chicago, AP, and Fowler's, and the only one that explicitly addresses whether the adjectival use is proper, so we are perfectly justified in following its advice. Chicago says that the second comma "may be deemed obligatory", but does not offer guidance itself on if it is or isn't actually required.) There are no exceptions in this proposal for Project-by-Project decisions, and no justifications for treating titles inconsistently with article text. I realize that this proposal will not satisfy the die-hard "two commas at all costs" crowd, but I hope that it satisfies the people with the concerns I laid out above. Anyhow, here it is:
- In geographical references that include multiple divisions (e.g., city, state/province, country), a comma separates each element and follows the last element. Dates in month–day–year format also require a comma after the day and after the year. A comma after the last element is not required when the place name or date a) is followed by other punctuation; b) appears by itself (as in a title or list); or c) is used as an adjective. Compound place names and dates can be unwieldy when used as adjectives, so such constructions should be avoided when a better alternative exists.
Incorrect: On November 24, 1971 Cooper hijacked a Boeing 727 aircraft that had taken off from Portland, Oregon and was destined for Seattle, Washington. Correct: On November 24, 1971, Cooper hijacked a Boeing 727 aircraft that had taken off from Portland, Oregon, and was destined for Seattle, Washington. Unwieldy: The April 7, 2011 trial of John Smith brought a capacity crowd to the Toledo, Ohio courtroom. One better way: On April 7, 2011, the trial of John Smith brought a capacity crowd to the courtroom in Toledo, Ohio.
- I think you're extrapolating: the fact that the other three that you call "major" don't cover the adjectival case separately doesn't mean that their authors have overlooked it. What is clear is that Garner deprecates the adjectival usage. So why insist on using it? --Stfg (talk) 22:14, 1 November 2013 (UTC)
- I'm not proposing that we insist on using the adjective construction; in fact, I'm proposing that we recommend against it. That's Plan A. If people use it anyway, however, then I propose we follow Garner and advise against the final comma. That's Plan B. I agree that Garner and the rest deprecate the adjective construction. But it's equally clear that Garner establishes a solid grammatical and stylistic footing for not needing the final comma. Essentially Garner does exactly what I propose here: recommend against the form in general, but in the event that it is used, recommend against the final comma. Dohn joe (talk) 22:31, 1 November 2013 (UTC)
- I think you're extrapolating: the fact that the other three that you call "major" don't cover the adjectival case separately doesn't mean that their authors have overlooked it. What is clear is that Garner deprecates the adjectival usage. So why insist on using it? --Stfg (talk) 22:14, 1 November 2013 (UTC)
- I would not support making an exception for adjectival use, but support the other suggestions you have proposed. We can validly follow Chicago which says to avoid such constructions (for which there is a general consensus) without being definitive as to whether the comma should or shouldn't be there if we do (over which there is strong disagreement). I suggest it be re-framed as follows:
- In geographical references that include multiple divisions (e.g., city, state/province, country), a comma separates each element and follows the last element. Dates in month–day–year format also require a comma after the day and after the year. In either case, a comma is not required after the last element when the place name or date appears by itself (as in a title or list) or is followed by other punctuation (such as a full stop, dash, parenthesis, etc.).
Incorrect: On November 24, 1971 Cooper hijacked a Boeing 727 aircraft that had taken off from Portland, Oregon and was destined for Seattle, Washington. Correct: On November 24, 1971, Cooper hijacked a Boeing 727 aircraft that had taken off from Portland, Oregon, and was destined for Seattle, Washington.
- Compound place names and dates in month–day–year format can be unwieldy when used as adjectives, so such constructions should be avoided whenever possible.
Avoid: The April 7, 2011 trial of John Smith brought a capacity crowd to the Toledo, Ohio courtroom. Better alternative: On April 7, 2011, the trial of John Smith brought a capacity crowd to the courtroom in Toledo, Ohio.
- That's good. And if you like, to make it clear that it's not only the one-comma version we're deprecating, if you like, it could also say:
Also avoid: The April 7, 2011, trial of John Smith brought a capacity crowd to the Toledo, Ohio courtroom.
- What I like about this is that we avoid the idiocy of choosing which deprecated option we prefer (which we're probably never going to agree on anyway). --Stfg (talk) 23:30, 2 November 2013 (UTC)
- I assume you mean this (adding the comma after "Ohio" as well):
- What I like about this is that we avoid the idiocy of choosing which deprecated option we prefer (which we're probably never going to agree on anyway). --Stfg (talk) 23:30, 2 November 2013 (UTC)
Avoid: The April 7, 2011, trial of John Smith brought a capacity crowd to the Toledo, Ohio, courtroom.
- I also think it's fine to list both options as "Avoid" (rather than "Also avoid"), but I agree that it's a good idea to include examples of both variations to avoid. —sroc 💬 09:58, 3 November 2013 (UTC)
- I think we're approaching a proposal that all factions can agree on. Should we start a new RfC with this proposal clearly stated for a new !vote? —sroc 💬 10:07, 3 November 2013 (UTC)
- I agree that we've made a lot of progress, and I like using both variations as examples of constructions to avoid. My reservation is that even though we counsel people to avoid using compound dates and place names as adjectives, we won't be giving any guidance for when they do so anyway. Again - the Plan B situation. I'd still like to find a way to include that guidance. If someone can find a way to do it with a stronger emphasis on avoiding it than my original version, I'd be happy to see that. Otherwise, I can't quite sign off on the latest suggestion. Any thoughts? Dohn joe (talk) 02:55, 4 November 2013 (UTC)
- Well I'm afraid we're simply not all going to agree on what guidance to provide. —sroc 💬 03:34, 4 November 2013 (UTC)
- I agree that we've made a lot of progress, and I like using both variations as examples of constructions to avoid. My reservation is that even though we counsel people to avoid using compound dates and place names as adjectives, we won't be giving any guidance for when they do so anyway. Again - the Plan B situation. I'd still like to find a way to include that guidance. If someone can find a way to do it with a stronger emphasis on avoiding it than my original version, I'd be happy to see that. Otherwise, I can't quite sign off on the latest suggestion. Any thoughts? Dohn joe (talk) 02:55, 4 November 2013 (UTC)
What about the following compromise, which acknowledges the dispute without taking sides?
- In geographical references that include multiple divisions (e.g., city, state/province, country), a comma separates each element and follows the last element. Dates in month–day–year format also require a comma after the day and after the year. In either case, a comma is not required after the last element when the place name or date appears by itself (as in a title or list) or is followed by other punctuation (such as a full stop, dash, parenthesis, etc.).
Incorrect: On November 24, 1971 Cooper hijacked an aircraft that had taken off from Portland, Oregon and was destined for Seattle, Washington. Correct: On November 24, 1971, Cooper hijacked an aircraft that had taken off from Portland, Oregon, and was destined for Seattle, Washington.
- Wherever possible, avoid using compound place names or dates in month–day–year format as adjectives, as such uses can seem unwieldy and may raise disputes whether the final comma is appropriate in this context.
Avoid: The April 7, 2011 trial of John Smith brought a capacity crowd to the Toledo, Ohio courtroom. Avoid: The April 7, 2011, trial of John Smith brought a capacity crowd to the Toledo, Ohio, courtroom. Better alternative: On April 7, 2011, the trial of John Smith brought a capacity crowd to the courtroom in Toledo, Ohio.
—sroc 💬 03:46, 4 November 2013 (UTC)
- I can live with that. I might collapse the "Avoid" examples into one, though:
Avoid: The April 7, 2011[,] trial of John Smith brought a capacity crowd to the Toledo, Ohio[,] courtroom. Better alternative: On April 7, 2011, the trial of John Smith brought a capacity crowd to the courtroom in Toledo, Ohio.
- So can I, it's excellent. And I think I can live with User:Dohn joe's collapsed version too (if you're OK with it, sroc?) --Stfg (talk) 18:42, 4 November 2013 (UTC)
- Sure, assuming the use of square brackets to indicate optional material is an understood convention, I'd be happy with that. —sroc 💬 22:06, 4 November 2013 (UTC)
It's been a couple of days now. What's the procedure? Do we wait it out till the 30 days are up and then start another one, or is there another way? --Stfg (talk) 22:04, 6 November 2013 (UTC)
- I would go ahead and request this one to be closed and start a new one with the new proposals. United States Man (talk) 22:31, 6 November 2013 (UTC)
- @United States Man: Would you like to simply withdraw this RFC? There appears to be a strong consensus opposing it and the initial supporter, Dohn joe, whom the other supporters endorsed, now supports the new proposal, so it does not seem like this one needs formal closure.
- In the meantime, I have created a new RFC below. —sroc 💬 08:16, 7 November 2013 (UTC)
Discussion
The need for a comma after dates in month–day–year format and geographical references with multiple subordinate levels had been discussed on numerous occasions[1][2][3] with the consensus being that the final element in each case is taken to be treated as parenthetical and, hence, requires a comma following (unless at the end of a sentence or perhaps superseded by other punctuation). Are we seriously considering abandoning this, despite what the style guides say?
I could understand if the proposal was to exempt the comma when appearing as an adjective (e.g., a London, England townhouse), although I would not support it and would prefer rephrasing to avoid such cases. However, that is not what has been suggested, and I am concerned that some others may be voting on the misapprehension that the proposal only applies to adjectival cases based on the examples given in the original post. —sroc 💬 15:23, 26 October 2013 (UTC)
- sroc, a better example? I'd advise writers never to use that item "a London, England townhouse" (rather, "a townhouse in London, England", or unless London, Ontario is in the air, "a London townhouse"). Tony (talk) 09:12, 27 October 2013 (UTC)
- Yes, a London, Ontario townhouse is a much better example — nice one! I agree that it is better to re-cast as a townhouse in London, Ontario, which is what I do for precisely this reason. —sroc 💬 10:27, 27 October 2013 (UTC)
Taken to ANI
I have lodged a request to have this RFC brought to a quick end at WP:ANI#Disruptive RFC. Please note that the request is just to close this, not for any kind of action against any editor. --Stfg (talk) 18:07, 27 October 2013 (UTC)
- I don't know why there was no followup post here, but this request fell into the archives with no action being taken. —Frungi (talk) 07:13, 1 November 2013 (UTC)
Terminal punctuation
The page currently says:
"Periods (also called "full stops"), question marks, and exclamation marks are terminal punctuation, the only punctuation marks used to end sentences in English."
This is incorrect. In dialog, a sentence may end with a dash to indicate that it was interrupted or broken off short. Granted, this will be rare in encyclopedic prose except perhaps in quotations. DES (talk) 21:29, 7 November 2013 (UTC)
- Not to mention ellipsis… --Pete (talk) 09:17, 9 November 2013 (UTC)
- But neither of those end a complete sentence, which is clearly the point the quoted excerpt is making. Please, there's enough pedantry on this page as it is ... N-HH talk/edits 11:35, 9 November 2013 (UTC)
- Agree with previous. And I can't see how a dash completes a sentence, or an ellipsis at the end of a sentence doesn't finish with a single period, as follows: "blah blah. ... The next point is that ...". Tony (talk) 11:42, 9 November 2013 (UTC)
- So no emoticons? Just kidding ;) Kaldari (talk) 07:11, 10 November 2013 (UTC)
- Or simply an unpunctuated line break Frungi (talk) 00:04, 11 November 2013 (UTC)
- So no emoticons? Just kidding ;) Kaldari (talk) 07:11, 10 November 2013 (UTC)
- Agree with previous. And I can't see how a dash completes a sentence, or an ellipsis at the end of a sentence doesn't finish with a single period, as follows: "blah blah. ... The next point is that ...". Tony (talk) 11:42, 9 November 2013 (UTC)
- But neither of those end a complete sentence, which is clearly the point the quoted excerpt is making. Please, there's enough pedantry on this page as it is ... N-HH talk/edits 11:35, 9 November 2013 (UTC)
Another point about "strong national ties"
If an article's subject has strong national ties to Britain or the US, the article uses the applicable variety of usage. I was therefore surprised to see, on the home page just now, a British spelling in an article about an American-produced series of movies. However, I then realized that these movies are primarily set in Britain; and in addition the main continuing characters are British, are played by British actors, and were created originally by a British author. So there's a good case for British usage being more appropriate.
What I'm wondering is whether there are any specific, explcit guidelines in the MOS as to how to decide whether, in a case like this, (1) the US tie is stronger, (2) the UK tie is stronger, or (3) neither tie is strong enough to mandate the use of the applicable variety of English and therefore the original author's choice should stand. And if not, whether there should be.
If there is no explicit guideline, I am not proposing one, nor am I proposing that there should not be one. I'm just raising the issue. --174.88.132.197 (talk) 04:38, 11 November 2013 (UTC)
- This is the kind of issue that is hard to write guidelines for, so we shouldn't. In the specific case, I think you could expect many outraged British editors if articles relating to Sherlock Holmes were not considered to have a strong national tie to Britain! Peter coxhead (talk) 11:00, 11 November 2013 (UTC)
Paris' or Paris's
MOS:POSS is irritatingly vague on what to use for possessives of words ending in the "s" sound. The BBC and the Guardian seem to favour "Paris's", and it looks better to me as well as passing the sound test. Are there style guides which recommend the "Paris'" form? I propose slightly tightening our recommendations on examples like this. What do others think? --John (talk) 14:39, 27 October 2013 (UTC)
- I was taught the "s-apostrophe" form was correct and I largely believe that the trailing s is redundant, but others may disagree. -- Ohc ¡digame!¿que pasa? 14:46, 27 October 2013 (UTC)
- The trouble is that many different editors will have been taught different "rules" about this. It seems to me that the "sound test" would be an effective way of deciding; where we pronounce the s we should write it (as in this example), and where we do not, we should not, as in Jesus' parables. If we accept Paris' walls, would we also accept France' capital? I think not. --John (talk) 14:54, 27 October 2013 (UTC)
- Without making a call on the overall discussion, I would point out this is an apples vs. oranges comparison. Your example using France is not in the S-apostrophe-S form, and that is what the difference of opinion revolves around. Resolute 16:46, 27 October 2013 (UTC)
- It's the same sound, hence the comparison. --John (talk) 18:45, 27 October 2013 (UTC)
- Without making a call on the overall discussion, I would point out this is an apples vs. oranges comparison. Your example using France is not in the S-apostrophe-S form, and that is what the difference of opinion revolves around. Resolute 16:46, 27 October 2013 (UTC)
- On the US side of the pond, the National Geographic also agrees with me. --John (talk) 14:57, 27 October 2013 (UTC)
- And finally (for now!) this is an interesting article with some references to how other style guides deal with the problem. --John (talk) 15:00, 27 October 2013 (UTC)
- The trouble is that many different editors will have been taught different "rules" about this. It seems to me that the "sound test" would be an effective way of deciding; where we pronounce the s we should write it (as in this example), and where we do not, we should not, as in Jesus' parables. If we accept Paris' walls, would we also accept France' capital? I think not. --John (talk) 14:54, 27 October 2013 (UTC)
- Both are correct (somewhere); it's just a matter of location and taste. I'm sure I can find tons of examples for "Paris'" use in major publications (perhaps even the majority of them) as well. Most of Wikipedia's articles use the " Paris' " form since probably its origins... that's not an argument 'for', but the fact that this complaint is the first I've seen of its kind says a lot. THEPROMENADER 15:08, 27 October 2013 (UTC)
- I agree with John here. The sound test is generally the best guide, imo. --Stfg (talk) 15:11, 27 October 2013 (UTC)
- Two suggestions:
- Avoid wherever possible; in the examples given above, prefer "the Judgement of Paris", "the walls of Paris", "the parables of Jesus", "the capital of France"
- Where unavoidable, allow free choice; see St James' Park, St. James's Park and St James's Palace for real-world examples of such diversity. Justlettersandnumbers (talk) 19:51, 27 October 2013 (UTC)
- Two suggestions:
I agree that pronunciation is what should govern the choice but, as John said, there are many different ‘rules’ for that. They usually take addition of the final S to be the default, however, the most commonly recommended exceptions being polysyllables and biblical or classical names. FWIW I would write Paris’s.—Odysseus1479 00:40, 28 October 2013 (UTC)
- Back in the days when I used to read style guides, the rule was that proper names always take 's, everything else s'. So it would be "Paris's", but plaster of paris' Ravpapa (talk) 04:44, 28 October 2013 (UTC)
- Yes, I agree with the pronunciation test. I would write "Paris's", as that's what I'd say. -- Necrothesp (talk) 10:39, 28 October 2013 (UTC)
- I've read to omit the possessive S if the following word begins with an S. So, Paris's walls would be fine, but Paris's sights would not. Otherwise, I personally would always use an S after the apostrophe. —Frungi (talk) 07:18, 1 November 2013 (UTC)
- That's one I've never heard before. Where did you read that? Dicklyon (talk) 03:26, 4 November 2013 (UTC)
- Really? I’m not sure off the top of my head where I’ve read it, but I could have sworn I had. But I know there are guides that allow if not encourage such an exception. And I now realize that I didn’t specify in my earlier comment, but I specifically meant words that end with an S, in case anyone interpreted it more broadly than I intended. —Frungi (talk) 04:07, 5 November 2013 (UTC)
- I remain skeptical. Let us know if you find a source that talks about the next word starting with an "s". I've never seen that. Dicklyon (talk) 03:00, 11 November 2013 (UTC)
- The Oxford Guide to Style (and, I presume, its other incarnations) has:
- I remain skeptical. Let us know if you find a source that talks about the next word starting with an "s". I've never seen that. Dicklyon (talk) 03:00, 11 November 2013 (UTC)
- Really? I’m not sure off the top of my head where I’ve read it, but I could have sworn I had. But I know there are guides that allow if not encourage such an exception. And I now realize that I didn’t specify in my earlier comment, but I specifically meant words that end with an S, in case anyone interpreted it more broadly than I intended. —Frungi (talk) 04:07, 5 November 2013 (UTC)
- That's one I've never heard before. Where did you read that? Dicklyon (talk) 03:26, 4 November 2013 (UTC)
- "Euphony is the main concern, with the final choice affected by the number of syllables and the letters starting the next word. Consider the following:
- the hiss's sibilance . . .the catharsis's effects . . ."
- US English is more likely to support such genitive possessives . . . with British English tending to transpose the words and insert of . . .
- Use an apostrophe alone after singular nouns ending in an s or z sound and combined with sake:
- for goodness' sake . . ."
- The classic rule, still included in Strunk & White's The Elements of Style, is that the possessive of a singular always takes 's ("Charles's books") but a plural ending in s takes s' ("the cars' fenders"). I still follow this rule. I can't think offhand of a singular common noun ending in s for an example, but i would still follow this rule when I think of one. I agree that rewording to avoid a possessive is often better DES (talk) 22:20, 1 November 2013 (UTC)
- Yeah. It's simpler too for people to learn—a unitary formula. Same after "x", BTW. And the 's is particularly helpful when the possessive adds another syllable phonologically, as it does in the case of Paris's. Tony (talk) 03:30, 4 November 2013 (UTC)
- Yes, the hippopotamus's teeth but three zebras' stripes. Unfortunately, there's no consensus on the pronunciation. I know someone who laughs at me and my education for pronouncing the possessive of, say, "Hayes" with two syllables. 05:49, 5 November 2013 (UTC) — Preceding unsigned comment added by JerryFriedman (talk • contribs)
- Yeah. It's simpler too for people to learn—a unitary formula. Same after "x", BTW. And the 's is particularly helpful when the possessive adds another syllable phonologically, as it does in the case of Paris's. Tony (talk) 03:30, 4 November 2013 (UTC)
Request comments regarding discussion based on the gender part of MOS:IDENTITY
Hi, We're having a discussion at Template talk:MOS-TW#Suggest "names" → "nouns" and we could use the help of editors who are familiar with the following sentence from MOS:IDENTITY.
- Any person whose gender might be questioned should be referred to by the pronouns, possessive adjectives, and gendered nouns (for example "man/woman", "waiter/waitress", "chairman/chairwoman") that reflect that person's latest expressed gender self-identification.
Thanks. --Bob K31416 (talk) 03:22, 15 November 2013 (UTC)
Manual of style?
This may be a silly question, but doesn't this page violate its own rule, namely Use "sentence case", not "title case"? It should be WP:Manual of style, not WP:Manual of Style. — Amakuru (talk) 12:33, 13 November 2013 (UTC)
- I think the implication is that "Manual of Style" is treated as a proper name; it is called the "Manual of Style" but is in fact not really a manual and does not deal mainly with style (at least not in the normal sense of the word). --Boson (talk) 16:22, 13 November 2013 (UTC)
- In sentences, you capitalize proper names, typically. If you consider Manual of Style to be a proper name, then you would capitalize it in sentences. For example, "The Manual of Style is in fact about style in the normal sense of the word." So entitling this article as Manual of Style is sentence case. See sentence case. ErikHaugen (talk | contribs) 05:41, 15 November 2013 (UTC)
Templates
I'm sure I'm not the only one who finds it annoying when an article is plastered with templates such as [according to whom?], [when?], [who?], [vague] etc. It's ugly, it looks like graffiti, and it suggests that the poster is more interested in criticizing than fixing whatever the problem is. I'm sure they have their place, maybe the editor lacks expertise in the subject matter, but perhaps something can be put into the MOS encouraging people to actually fix whatever the problem is rather than "scribbling" on the article like a teacher marking an essay? MaxBrowne (talk) 07:21, 15 November 2013 (UTC)
- It is, of course, better to fix the problem but it's not always possible (you might not have the source at hand). Jimp 07:49, 15 November 2013 (UTC)
- My suggestion is that this be spelled out clearly in the MOS, making it an actual wikipedia policy to use such templates sparingly. MaxBrowne (talk) 08:10, 15 November 2013 (UTC)
- Strongly disagree I could not disagree more with this view. It is our duty to readers to flag up to them how likely it is that the article is accurate. These templates are the main way of doing so. The alternative is to simply remove all unsourced material, I suppose. Would you prefer this? Peter coxhead (talk) 09:25, 15 November 2013 (UTC)
- In my experience most of the policy pages that discuss flagging with templates also encourage editors to consider fixing the problem instead of flagging it. I doubt editors would oppose suggesting fixing the problem as a possibility, but I would oppose any suggestion that editors should be obligated to do so or any movement towards telling editors "don't flag problems because it makes articles look messy". That said, if an article has extensive problems then it may be best to tag sections or the article itself rather than particular sentences...that can backfire though as editors may then turn around and ask for clarification as to which areas of the article are of specific concern. In any event, if an article has problems then they should be flagged. If the problems don't exist then the templates can be removed (presumably with an explanatory edit summary). DonIago (talk) 14:31, 15 November 2013 (UTC)
- I agree with Peter and DonIago: WP is a work in progress, and tags, both sectional and inline, are a way to ask other editors to help with identified issues. Yes, there are sometimes problems with drive-by tagging, but the tags I've seen have been helpful more often than not. Besides, the scope of the MOS is style, not procedure. --Stfg (talk) 14:42, 15 November 2013 (UTC)
- Yup... It is a truism that writers never like it when editors mark up their work ... but it is part of the publishing process. Blueboar (talk) 15:39, 15 November 2013 (UTC)
- If a writer doesn't want his articles tagged with those tags then it is incumbent upon the writer to avoid using weasel words and vague prose. I don't see why any author would get upset over such tagging anyway. The tags are there to help a work in progress. Ohlendorf77 (talk) 19:34, 15 November 2013 (UTC)
- Yup... It is a truism that writers never like it when editors mark up their work ... but it is part of the publishing process. Blueboar (talk) 15:39, 15 November 2013 (UTC)
- My suggestion is that this be spelled out clearly in the MOS, making it an actual wikipedia policy to use such templates sparingly. MaxBrowne (talk) 08:10, 15 November 2013 (UTC)
Use of word 'none'
I find in many Wikipedia English entries that 'none' is treated as plural, eg 'none of these are present'. Apologies if I haven't found guidance which does exist on the proper use of 'none' but if it doesn't exist, should it be added to the style guide here? 82.23.253.61 (talk) 15:15, 15 November 2013 (UTC)Paul. 15 November 2013, 15:15 GMT82.23.253.61 (talk) 15:15, 15 November 2013 (UTC)
- On the basis that "none .. are" is fine as English usage, especially in some contexts, and that we should avoid bloating the MoS any further or making it even more prescriptive, I'd be inclined to leave the MoS quiet on the issue (AFAICT you're right that it is not currently covered) and not worry about it too much when the question comes up in text either. N-HH talk/edits 15:38, 15 November 2013 (UTC)
- Yet another attempt to turn what should be a broad and somewhat flexible style guide into a narrow and inflexible grammar rule book. A style guide does not need to spell out every rule of grammar that exists (especially since the rules of English grammar are often inconsistent when put into practice). If you think the word "none" is used incorrectly in an article, the solution is to edit the article and fix it. You don't need permission from the style guide to do this. Blueboar (talk) 15:59, 15 November 2013 (UTC)
- In any case, this is one of those schoolma'am myths that bring a taste of cod liver oil to the mouth just to think of it. Here is Fowler: "none. 1. It is a mistake to suppose that the pronoun is sing. only & must at all costs be followed by sing. verbs &c.; the OED explicitly states that pl. construction is commoner." And here is Bernstein: "Miss Thistlebottom undoubtedly told you in grammar school that none always takes a singular verb. She was wrong ...". --Stfg (talk) 16:33, 15 November 2013 (UTC)
- I could have sworn there was guidance on this, but if there is I can’t find it. What I think I remember reading somewhere on here was that either use, singular or plural, is acceptable. This is also in grammar guides and dictionaries. —Frungi (talk) 20:28, 15 November 2013 (UTC)
- Right, both are acceptable. To my ear, none is sounds slightly higher falutin, and therefore probably better for an encyclopedia. But no need to burden the MoS with it. --Trovatore (talk) 20:34, 15 November 2013 (UTC)
- Sometimes there isn't an option, though. "They are asking for water, but none is available". "They are asking for grapes, but none are available". (But I agree, not for MOS). --Stfg (talk) 23:08, 15 November 2013 (UTC)
- First poster here again. I only asked a question, remember! I can see that you're right various authorities do say it's ok to use none with a plural verb and I take the point that a style guide doesn't spell out all rules of English usage. Still, given that its origin is a contraction of 'not one' it always jars on my ears to hear the equivalent of "They are asking for grapes and not one are available". Like when people say "social media is...." Just saying; I still accept the conclusion here. — Preceding unsigned comment added by 82.23.253.61 (talk) 07:00, 16 November 2013 (UTC)
- Maybe it'd help to think of it as "not one", so "not a single one", so "not singular"? It's as much a quantity as "some", "most" or "all". But it only exists in our minds, when we think about counting. Not a plural we can observe, like "birds" or "rocks". Something like zero, in that regard. We can't know there are zero grapes, unless we measure against a notion of some grapes. Since the quantity can't exist on its own, it can't be singular. "Not one are available" sure does sound awful, which is why we have "none" at all.
- First poster here again. I only asked a question, remember! I can see that you're right various authorities do say it's ok to use none with a plural verb and I take the point that a style guide doesn't spell out all rules of English usage. Still, given that its origin is a contraction of 'not one' it always jars on my ears to hear the equivalent of "They are asking for grapes and not one are available". Like when people say "social media is...." Just saying; I still accept the conclusion here. — Preceding unsigned comment added by 82.23.253.61 (talk) 07:00, 16 November 2013 (UTC)
- Sometimes there isn't an option, though. "They are asking for water, but none is available". "They are asking for grapes, but none are available". (But I agree, not for MOS). --Stfg (talk) 23:08, 15 November 2013 (UTC)
- Right, both are acceptable. To my ear, none is sounds slightly higher falutin, and therefore probably better for an encyclopedia. But no need to burden the MoS with it. --Trovatore (talk) 20:34, 15 November 2013 (UTC)
- As for "social media", you have to think of it as a two-word noun, not a noun with an adjective. Well, you don't have to, but it makes it easier. InedibleHulk (talk) 21:07, 18 November 2013 (UTC)
Ranges of hypenated page numbers
When a document uses hyphens within page numbers, what is the approved character to use for the hyphen? Does that answer remain the same for a range of page numbers? E.g., when do you em and en dashes for p=A–1 and pp=A–1—A–3? Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:24, 12 November 2013 (UTC)
- There's no clear guidance at MOS:HYPHEN or MOS:DASH, but perhaps this is the most relevant:
- If negative values are involved, an en dash might be confusing. Use words instead.
- −10 to 10, not −10–10
- If negative values are involved, an en dash might be confusing. Use words instead.
- I think a non-breaking hyphen (
‑
) with a spaced en dash would be clear: A‑1 – A‑3. —sroc 💬 23:38, 12 November 2013 (UTC)- I say that "use words instead" is the best choice. --174.88.132.197 (talk) 16:16, 13 November 2013 (UTC)
- Generally, in prose, yes, but this might be odd in footnotes where dashes are universally used to indicate ranges, which I gather is the context here? I agree that using words is clearer, though, of course. —sroc 💬 22:18, 13 November 2013 (UTC)
- I say that "use words instead" is the best choice. --174.88.132.197 (talk) 16:16, 13 November 2013 (UTC)
- I think you answered your own question—the document uses hyphens within page numbers, not dashes. And I agree that using dashes for the range would be confusing, so: A-1 to A-3, not A-1–A-3. —Frungi (talk) 21:53, 13 November 2013 (UTC)
- "[N]o clear guidance ..."?? Try MOS:ENDASH, where the very first example is a page range: pp. 211–19. And the vast number of edits done over the years replacing hyphens and em-dashes in page number ranges with en-dashes suggests a standard usage. ~ J. Johnson (JJ) (talk) 23:29, 13 November 2013 (UTC)
- @J. Johnson: He meant no clear guidance on hyphenated page numbers. Page 211 has no hyphen within the number. Page A-1 does. —Frungi (talk) 23:36, 13 November 2013 (UTC)
- Yes, thanks, that is what I meant. —sroc 💬 23:43, 13 November 2013 (UTC)
- Ah, yes, and thanks for pointing that out. (My eyes were getting blurry last night.) Hyphens as integral part of the page number, not as a range. Is there likely to be any problem just leaving out such useless hyphens (as Blueboard suggests, below)? ~ J. Johnson (JJ) (talk) 21:03, 14 November 2013 (UTC)
- Using words ("A-1 to A-3") does resolve the confusion. Another option would be to make a simple editorial decision to avoid the hyphenated page numbers entirely and present the range as "A1–A3". The reader will understand what is being referred to. Blueboar (talk) 15:48, 14 November 2013 (UTC)
- I think that "A1–A3" is a good solution. Peter coxhead (talk) 21:08, 14 November 2013 (UTC)
- (edit conflict)This is a neat shortcut, but the page numbers are then not true to the source. What if, as some publications do, the page numbers are in the format of [chapter number]–[page number], such as "2–15"? I suppose that is a hypothetical until an actual example comes along, but it would be nice to be consistent with examples such as A–1. —sroc 💬 22:24, 14 November 2013 (UTC)
- That was my initial take when I read the original question, which posits a hyphen separating an alpha portion from a numeric portion. Recently, though, I noticed a citation on the Jane Fonda article that cited a rules manual used at Annapolis and refered to page 5-1. Had this been pages 5-1 through 5-3 instead, simply removing the hyphens would be misleading. My preference would be something like
sec. 5, pp. 1–3.
, but that's not a standard format here (maybe use thechapter=
parameter of the{{Cite book}}
template?) so I would probably have gone with something likepp. 5-1 – 5-3
if I had needed to use such a cite. Fat&Happy (talk) 22:18, 14 November 2013 (UTC)- Thanks, that's exactly the point I wanted to make, and a workable solution. —sroc 💬 22:24, 14 November 2013 (UTC)
- This gives rise to the problem, though, if you wanted to cite the seventh page in that chapter, i.e., p. 5–7, is this sufficiently distinguishable from a range from page 5 to page 7, i.e., pp. 5–7? —sroc 💬 22:31, 14 November 2013 (UTC)
- It's probably sufficient for a reader actually verifying the reference. It's a problem when some know-it-all comes along – as I almost did several months ago when I first saw the Fonda cite above – and reflexively changes p. 5-7 to pp. 5–7. The only thing that stopped me was that in the case, the second number was lower than the first, raising a question as to what the actual pages were. (Off topic, but a similar anomaly can occur with Roman numerals and page ten – p. xi., or even p. v. is fine, but p. x. sort of looks like someone is indicating "unknown".) Fat&Happy (talk) 23:42, 14 November 2013 (UTC)
- I comment in the source could clarify ambiguities for "know-it-all" editors, but that wouldn't help the casual reader — at least, until they actually consult the source. The problem with applying these rules consistently is assuming that everyone else is doing the same. When people have their own page number conventions or are sloppy with hyphens and dashes, it leads to confusion! —sroc 💬 01:01, 15 November 2013 (UTC)
- If you want to keep bots and pedants away from your correct "p. 5-7", one option is to put the page number in the
|at=
parameter, e.g.at = p. 5-7
. If I were inserting this page number, I would also add a <!-- comment --> to the effect that this is page 7 of section 5, not pages 5–7. – Jonesey95 (talk) 16:29, 17 November 2013 (UTC)
- If you want to keep bots and pedants away from your correct "p. 5-7", one option is to put the page number in the
- I comment in the source could clarify ambiguities for "know-it-all" editors, but that wouldn't help the casual reader — at least, until they actually consult the source. The problem with applying these rules consistently is assuming that everyone else is doing the same. When people have their own page number conventions or are sloppy with hyphens and dashes, it leads to confusion! —sroc 💬 01:01, 15 November 2013 (UTC)
- It's probably sufficient for a reader actually verifying the reference. It's a problem when some know-it-all comes along – as I almost did several months ago when I first saw the Fonda cite above – and reflexively changes p. 5-7 to pp. 5–7. The only thing that stopped me was that in the case, the second number was lower than the first, raising a question as to what the actual pages were. (Off topic, but a similar anomaly can occur with Roman numerals and page ten – p. xi., or even p. v. is fine, but p. x. sort of looks like someone is indicating "unknown".) Fat&Happy (talk) 23:42, 14 November 2013 (UTC)
- That was my initial take when I read the original question, which posits a hyphen separating an alpha portion from a numeric portion. Recently, though, I noticed a citation on the Jane Fonda article that cited a rules manual used at Annapolis and refered to page 5-1. Had this been pages 5-1 through 5-3 instead, simply removing the hyphens would be misleading. My preference would be something like
- Using words ("A-1 to A-3") does resolve the confusion. Another option would be to make a simple editorial decision to avoid the hyphenated page numbers entirely and present the range as "A1–A3". The reader will understand what is being referred to. Blueboar (talk) 15:48, 14 November 2013 (UTC)
- @J. Johnson: He meant no clear guidance on hyphenated page numbers. Page 211 has no hyphen within the number. Page A-1 does. —Frungi (talk) 23:36, 13 November 2013 (UTC)
- So the answer to my rhetorical question is: yes, there is a possible problem in removing hyphens from page numbers compounded with a numbered chapter (e.g., 5-7). This was not obvious in the initial example ("A-1") because the letter (typical for appendices) is distinct from the numbered page.
- The obvious solution would be to use different character for delimiting chapter/page. (E.g.: pp. 5.1-5.7.) This taking a liberty with the original source, but perhaps this could be an accepted convention, on par with the way publishers often modify the capitalization of titles. ~ J. Johnson (JJ) (talk) 21:18, 16 November 2013 (UTC)
Referring to a person by a noun
I thought we have guidance, but I cannot find it, on whether or not we should refer to specific people by noun phrases.
For example:
- " Chaplin became a cultural phenomenon. Shops were stocked with Chaplin merchandise, he was featured in cartoons and comic strips, and several songs were written about the comedian."
rather than
- "Chaplin became a cultural phenomenon. Shops were stocked with Chaplin merchandise, he was featured in cartoons and comic strips, and several songs were written about him.
Is there such guidance or am I imagining? -- TRPoD aka The Red Pen of Doom 20:12, 1 November 2013 (UTC)
- I haven't seen any and would be surprised if it exists. The first example above is old-fashioned and really unnecessary. "him" is perfectly clear, seeing as nobody else is mentioned in the sentence. (See Elegant variation). pablo 09:45, 5 November 2013 (UTC) edited 11:17, 5 November 2013 (UTC)
- Worse, I think the first example causes a brief stumble as the reader asks himself whether "the comedian" is a different person than "Chaplin". This is especially true in longer sentences and with esoteric nouns – a style that, in the past, was thought to add some color and variety. —[AlanM1(talk)]— 19:52, 18 November 2013 (UTC)
- It may be a problem to use a single term in that way to characterize someone. In the example, using "the comedian" may be too limiting. For example, here's a scene from his movie City Lights.[4] As I recall, this scene is after he helps a blind woman regain her eyesight. She had only known him when she was blind and hadn't seen him afterwards, until this scene. --Bob K31416 (talk) 20:16, 18 November 2013 (UTC)
- Worse, I think the first example causes a brief stumble as the reader asks himself whether "the comedian" is a different person than "Chaplin". This is especially true in longer sentences and with esoteric nouns – a style that, in the past, was thought to add some color and variety. —[AlanM1(talk)]— 19:52, 18 November 2013 (UTC)