Wikipedia talk:Manual of Style

Use of # in table headers

Some editors are replacing # in table heads with "No." or other equivalents, claiming that MOS:HASH absolutely prohibits use of # in any article in any context. It currently says "Avoid using the # symbol".

Regardless, it is still heavily used. For instance, a rough estimate is that about 40% of the TV show episode lists use # in a table header. E.g., eight out of 20 shows in Lists of British television series episodes, starting with "A" use the # :

• List of Absolutely Fabulous episodes
• List of After You've Gone episodes
• List of Da Ali G Show episodes
• List of 'Allo 'Allo! episodes
• List of An Idiot Abroad episodes
• List of As Time Goes By episodes
• List of Auf Wiedersehen, Pet episodes
• List of The Avengers episodes

(I chose British shows here, as it is sometimes claimed that # isn't understood outside the US. As a non-American, I can say that is not true. But # meaning "pounds", that is weird; "number" is fine.)

Also many current popular shows, such as List of Game of Thrones episodes, List of Modern Family episodes.

I cannot find any explanation or justification of this part of MOS. The Talk archives are voluminous and hard to search. However, I found [1] which seems to be when this guideline was proposed. There were plenty of exceptions mentioned. I do not know how that ended up as simply "avoid", nevertheless, I do not think a hardline prohibition is supported by the discussion there. So I think that this should be revised to specifically allow use of # in tables, where it saves space and is quite clear, and retain the admonition against use in prose. Barsoomian (talk) 10:56, 26 February 2012 (UTC)

List of An Idiot Abroad episodes also uses the numero sign, which MOS:HASH specifically says not to use, so it clearly does not comply. List of Auf Wiedersehen, Pet episodes does not use "#", it uses "Episode", so, out of the first 20 articles one is very wrong and 13, not 12, do not use "#". There's a relevant discussion, now archived, here, where it was mentioned by multiple editors that "#" is ambiguous. --AussieLegend (talk) 11:08, 26 February 2012 (UTC)

I see along rambling discussion that did not end in consensus on anything. The ambiguity mentioned is what is being counted, the meaning of # or No. as "number" is not ambiguous. Otherwise, that did not seem to be about this specific point. And many of the prominent episode lists cited in that discussion then still use # in their headers, eg. List of Star Trek: The Next Generation episodes. So it doesn't seem to have been put into practice by anyone, except perhaps you. I am asking for the policy to take account that many editors do not agree with this prohibition and revise it to something more sensible. Barsoomian (talk) 11:24, 26 February 2012 (UTC)

You're correct that no consensus was reached, which is why some articles still use it. However, your claim that "it doesn't seem to have been put into practice by anyone, except perhaps you" is far from correct. In fact the discussion was started by an editor who disagreed with "Season #" and "Series #" headings that were being used by many editors, including me. It wasn't until after that discussion concluded that I became aware of MOS:HASH, when an article I regularly edited was changed by another editor citing it. Since then I've seen many articles changed by many editors citing MOS:HASH. Your actions here obviously motivated by your opposition to "#" being changed to "No." at List of The Almighty Johnsons episodes and, despite a request, you still haven't explained why you think "#" is better than "No." --11:46, 26 February 2012 (UTC)

I never noticed any such request. I don't see any reason to prefer "No." in this case. Obviously, from the examples I cited, I am not the only person who thinks that "#" is a valid and obvious symbol to use for this purpose. You haven't given any cogent reason not to do so. That "many articles [were] changed by many editors citing MOS:HASH." is a circular argument, and why I opened the discussion here, to question this appeal to authority (and would I be right in suspecting that you were one of the architects of this rule you enjoy laying down so much?) Barsoomian (talk) 15:02, 26 February 2012 (UTC)

The request was clear on my talk page.[2] You responded to the content directly after it,[3] and even copied it to Talk:List of The Almighty Johnsons episodes. I didn't ask you if there was any reason to prefer "No.", I asked "Why do you prefer "#" over "No." given the obvious preference for the latter in the MoS?", something you still haven't answered. The argument for "No." is in MOS:HASH, which says to avoid it, and comments in the discussion that I linked to explain that it is ambiguous, especially when one column is headed with "№" and the other is headed by "#", such as in List of An Idiot Abroad episodes, as the two mean the same thing. You may prefer #, and others may too, but your own investigation showed there are more articles that don't, so they don't support your opinion. I still fail to see why you prefer "#". --AussieLegend (talk) 15:30, 26 February 2012 (UTC)

The question I am asking here (since you closed discussion of your Talk page, how can you continue that here?) is: Why prefer "No.", the abbreviation of a Latin phrase, over a single symbol "#" that is one character long and unambiguous? Actually, I don't care what you prefer. I do care that you want to forbid anyone from preferring otherwise, for no reason except that "it's in the MoS". Doing some archaeology, I found that at 14 September 2009 the wording was:

Number signs
Avoid use of the # symbol (known as the number sign, hash sign or pound sign) when referring to numbers or rankings. Instead use the word "number" to preserve formality. For example:Incorrect: Her album reached #1 in the UK album charts Correct: Her album reached number 1 in the UK album charts
Similarly, avoid using № or "No." (the numero signs).

This was entered with the comment "Punctuation: Agreed in Talk that # and No. should not be used". The changes, without any consensus, since then to "simplify" this have created the impression that "No." is the ONLY abbreviation that should be used. But the insistence on substitution of "No." for "#" is not supported by this guideline, the original discussion actually deprecated ALL abbreviations. It seems obvious that this policy applied to prose, not formats where abbreviations were appropriate, such as multi-column tables. There was no distinction made between abbreviations. As I have documented, the # and № are both very commonly used in tables in Wikipedia now. I see no reason to deprecate this. It is a quite normal and clear usage and has been for decades. So I advocate a reversion to the original sense, with clarification as to the scope, something like:

Number signs
In prose, avoid use of the # symbol (known as the number sign, hash sign or pound sign), № or "No." (the numero signs) when referring to numbers or rankings. Instead use the word "number" to preserve formality. For example:Incorrect: Her album reached #1 in the UK album charts Correct: Her album reached number 1 in the UK album charts.
In tables and lists short forms may be used, if the meaning is clear.

Barsoomian (talk) 16:49, 26 February 2012 (UTC)

That I closed the discussion on my talk page is irrelevant. In the more than 14 hours between when I asked that question and when I closed the discussion after you started making snide comments and told another editor to "but out", you edited my user page on 3 different occasions. There was plenty of time to respond, and you still could at Talk:List of The Almighty Johnsons episodes, where you copied the content, and yet you're still avoiding providing an answer. Anyway, to the relevant topic here, you should have done a bit more than scrape the surface in your archaeology exploits. The content that you claim was there until 14 September 2009, was actually first added on that date,[4] during a discussion now archived at Wikipedia talk:Manual of Style/Archive 110## in British English. Subsequent discussion resulted in a change to what is pretty much the present format on 24 September 2009.[5] I don't see any justification in removing use of "No.". What was stated in the 2009 discussion is still valid and, in any case, you've gotten around MOS:HASH at List of The Almighty Johnsons episodes by changing "No." to "Ep.".[6] --AussieLegend (talk) 17:58, 26 February 2012 (UTC)

I haven't "avoided an answer" I answered above. Why prefer "No.", the abbreviation of a Latin phrase, over a single symbol "#" that is one character long and unambiguous? Is it being in the form of a rhetorical question confusing? I'm sorry. But clearly it doesn't matter what I say, you revert regardless, and templating anyone who dares to disagree. You are the one who has avoided answering any of my points. I resent your forcing your interpretation of an arbitrary rule, an interpretation which has never been discussed, explained or given consensus. None of the links you cite do that; yes I did read them. One person commented that he thought # might be confusing, another went ahead ahead and made it so. Now, without any wider consensus or discussion, you are using this as a licence to arbitrarily change articles, templating anyone who disagrees with absurd assertions that using the numbersign in a table is "unusual, inappropriate or difficult to understand", all of which are untrue (it is used now in thousands of major articles, such as List of Star Trek: The Next Generation episodes, as a random example, without anyone suffering "confusion"). In any case, I brought the discussion here to get comments from editors who might consider it on the merits rather than defending an entrenched position. Barsoomian (talk) 18:37, 26 February 2012 (UTC)

Just a reminder that, whether "#" or "No." is used, they should be rendered as {{Abbr|#|Number}} or {{Abbr|No.|Number}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:14, 26 February 2012 (UTC)

Interesting. But every time I try to use "#" I am reverted, so it's not an option now. Barsoomian (talk) 15:02, 26 February 2012 (UTC)

That's highly dubious "abbr fetishism" (and I say that as someone who's 10x more semantic HTML fetishistic than almost anyone else on the system. :-) For one thing, it wouldn't be done except for the first time in the same article, and we don't use {{abbr}} / <abbr> markup for symbols, only for abbreviations (in fact, doing so is an abuse of that HTML element). The "#" symbol is, by definition, a symbol not an abbreviation. Even "No." is questionable. It's actually an ASCII rendering of the numero symbol, U+2116 № numero sign (HTML: №), which is a symbol albeit one obviously derived from abbreviation of Latin: numero, 'number', in the same way that the trademark symbol ™ is a symbol, not simply an abbreviation of "trademark". There are many cases of this, including "&", which is a distorted abbreviaton of Latin: et, 'and', and so on. An argument can be made for "No." since it's been kind of "desymboled", but I think that's a hairspliting exercise, as there is no one who knows English who doesn't recognized "No.", which is widely used around the world even outside of English, even in Cyrillic (as the actual numero symbol), despite Cyrillic not having an "N" glyph. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 08:18, 28 February 2012 (UTC)

Agreed. I've already seen Jan, Feb etc. (in tables including all months in order, no less, where if you can't figure out what Jan mean you likely can't figure out how to use a computer either), FFS. What's next, DNA, LSD or TNT, where actually fewer people know the substance by its full name than by the initials? Duh. ― A. di M.​  13:08, 28 February 2012 (UTC)

This overuse of abbr needs to be addressed at MOS:ABBR; it's essentially the exact same concept as overlinking of things like today and sun and elbow. Actually, it's not "essentially" the same thing, it is the same, since it is a form of linking, to a pop-up tooltip instead of an article. We don't link if it blindingly obvious. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 16:00, 28 February 2012 (UTC)

Is there any good reason to avoid # which doesn't apply to No. as well? (I find the idea that the former is unfamiliar to non-Americans ridiculous – and I've never been to America; plus, even the 0.1% of people who haven't encountered it before would likely be able to figure it out from the context without breaking a sweat.) ― A. di M.​  18:51, 26 February 2012 (UTC)

This is one of those MOS points I don't entirely support myself. It derives from the fact that most published style guides say to use "No." or the U+2116 № numero symbol (which MOS says not to use, for no known reason; it should explicitly state why if it's going to continue to do so). The "#" symbol is overwhelmingly used as standard in many cases, from sports statistics to music and movie sales, in the vast majority of both general and specialist reliable sources. I do agree that in general prose both "#" and "No." should be avoided. There's no reason to abbreviate. In a table or repetitive list, which does provide a reason to abbreviate, I'm fine with recommending "No." generally vs. "#" as a default, but the half-assed wording we have pretends there are no exceptions. I recently (after a reliably sourced proposal that garnered no opposition) added comics as a codified exception (WikiProjects' MOS-hating editwarriors take note: The issue was raised because the comics project was advising something different than MOS. Sound familiar? Instead of launching a tendentious, canvassing, poll-stacking, histrionic war, someone just asked about it and recommended a change, and a week later it was fixed because compelling reasons were presented to fix it. People don't have to fly off the handle to get specialist preferences worked into MOS when they don't violate WP:ASTONISH (if they do, too bad, get over it and move on); calm reason usually works.) — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 08:18, 28 February 2012 (UTC)

Are there many old fonts still widely used which don't support the U+2116 № character? If there are, that's a good reason to avoid it. (BTW, how about Nº (capital N plus masculine ordinal sign º)? It ought to look the same or very similar to U+2116 № but it ought to be supported by pretty much all fonts.) ― A. di M.​  12:54, 28 February 2012 (UTC)

№ is in any Unicode font, but not if you're restricted to 8-bit Windows ANSI. If you can't use the actual character, better to use just "No." rather than trying to simulate it. But # is in every font from 7-bit ASCII up. Interestingly, № is on the editing "Insert symbol" list, despite its apparent prohibition. And as a brief reconnoiter found, it is widely used in articles here, though the equally banned # is more common. Barsoomian (talk) 13:21, 28 February 2012 (UTC)

I don't understand what you mean by 'If you can't use the actual character, better to use just "No." rather than trying to simulate it.', since the character string "No." is a simulation of №. Who uses 8-bit ANSI? Any restriction that would affect that Unicode glyph would affect huge numbers of them all over the system, effectively making the issue moot. We do not optimize for obsolete operating systems. We can't, or we cannot do what we need to do to make a proper encyclopedia. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:55, 28 February 2012 (UTC)

Well this is a bit of a digression, but the № symbol is just a representation of "No." an abbreviation for the Latin numero. They're equivalent, not simulations. Similar to the origin of the & as Latin "et", except that we don't use the "et" form at all any more in English. The "simulation" I was advising against was using " Nº", which looks similar but purely accidentally. Anyway, if you want to advocate removing the restriction on № (also widely ignored) then please do so, preferably in a separate topic, as the case is a bit different. Barsoomian (talk) 15:31, 3 March 2012 (UTC)

• Support Barsoomian's wording change. There's no reason to favor "No." over "#" in tables and lists (indeed, "#" is by far favored in both sporting and media contexts), and no reason to actively promote "No." (or, of course, #) in prose, except where such use is overwhelming (as # is in comics, in constructions like "The Amazing Spiderman #247"). — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:09, 3 March 2012 (UTC)

• Oppose Barsoomian's wording. It is moderate and subtle, but still does not reflect the fact that "#" has noticeable support only in the US. In The Canadian Style (current edition, 1997) it gets a limited acceptance similar to Barsoomian's proposal (p. 29). But even in the major US guide CMOS it is barely mentioned. (And never shown or used in CMOS, in referencing examples or any other context so far as I can see after a diligent search; same for the hugely influential APA Manual, with its meticulous and numerous tabular examples.) In the Gregg Reference Manual (my favourite US guide for its detail and subtlety) "No." is preferred (or no marker at all), in almost all circumstances. Most mentions there of "#" are proscriptive (don't use it addresses, for example: see 316c). At 455c there is a small concession: "The symbol # may be used on business forms and in technical material." And these two examples are later given: "use 50# paper for the job" (543d); "reorder #4659 and #4691" (543e). British guides (New Hart's and the others in that stable) have no place for "#", except perhaps as one in a series of note markers where numbers are not used. Cambridge Guide to English Usage at the article "hash" identifies "#" as American, and allows that it is "handy in mathematical tables and computer codes". In fact, I notice a predominance of acceptance among those with a solid mathematical or computing background, like SMcCandlish and A di M (no offence meant to either!). In conclusion, nowhere do we find a ringing endorsement of "#" for any use. I stand firmly against its incorporation in Wikipedia style, and I would not countenance its acceptance without solid endorsement in a properly conducted RFC. Many who edit here are international or "Americanised" in their outlook, or technically oriented as I have observed. The rest of the world does not use or accept "#" for indicating numbers.

Noetica^Tea? 01:58, 3 March 2012 (UTC)

I am neither American nor Americanised. I'm from the "rest of the world" (specifically Australia, and now Hong Kong). We don't need a "ringing endorsement" of its use, we need a good reason to proscribe using a common symbol, in every Latin character set, and plainly marked on every keyboard (UK or US). Currently I have found it being used in roughly 40% of articles listing UK TV episodes, for instance. That would not have been tolerated for a minute if it was not well understood by British readers and editors. The sporadic and random attempts by zealous editors to stamp it out, wielding the MOS:HASH as a blunt instrument, are met with incomprehension and annoyance as, for instance, tight header text is wrapped to two lines, as a side effect, while there is no gain in readability. It's an observable fact that it has entered common usage here (that is Wikipedia, all varieties of English), at least in the table layout s that I suggest it specifically be allowed for editors to have the choice to use it when appropriate. Barsoomian (talk) 08:42, 3 March 2012 (UTC)

For the record, I'm neither a mathematician nor a computer scientist. (I was taught about # by my father when I was about 7 years old. I have taken a few maths and comp sci courses in university since then, but it's not like we routinely talked about album charts or sports rankings or TV series in them, anyway. What I guess the CGEU is talking about has very little to do with the use of # as a synonym of №, which is what's being discussed here.) ― A. di M.​  17:29, 3 March 2012 (UTC)

• Oppose proposed change. Many contributors might be from the restricted areas of academic/professional life outside the US in which the hash is widely used, but we should be providing an encyclopaedia that suits the reader, not the editors. Although recognition of the hash in UK is undoubtedly much wider than it was a few years ago, it is still perceived as an Americanism. Kevin McE (talk) 07:33, 3 March 2012 (UTC)

I find the statement that the hash is used in "restricted areas of academic/professional life" a highly dubious assertion. Its origin being recognised as an "Americanism" doesn't mean it isn't recognised. It is currently used by many editors in articles on British subjects; surely edited and read by many British readers without causing consternation. I am sure that none of those who oppose this use find it personally confusing; they are acting on behalf of a hypothetical person who I doubt really exists any more, at least in the readers of Wikipedia. A column of figures with a symbol at a the head is pretty much self evident. Barsoomian (talk)

Yeah, this is starting to look more and more like WP:IDONTLIKEIT, based on ca. 1970s assumptions about usage. Simply repeating the assertion that "#" is a weird Americanism that no one else understands doesn't make it true or even vaguely plausible given the evidence against this. And it's important to note that the proposal is actually two proposals: 1) stop favoring one abbreviation over the other, and 2) explicitly favor the full word "number" over any abbreviation in running prose (there's really no excuse for using an abbreviation there unless it's in a special context in which such a usage is near-universal). MOS is not bound to the Chicago Manual of Style, though we use it among other sources and other considerations in formulating what to do here. It's a noticeably conservative work, and often does not reflect current usage (and I don't mean texting-speak and street slang). If nearly half of British TV series articles use "#" (this would be after various people have tried to enforce MOS by cleaning up articles that do so, mind you), this is strong evidence that the prohibition against "#" is broadly perceived as obstructionist nonsense and is being WP:IAR'ed by a very large number of editors, in a programmatic, consistent way (i.e., it doesn't reflect consensus any longer if it ever did). It's also broadly used in sports articles. I've seen it in snooker tournament articles despite their being mostly Commonwealth-edited and Commonwealth-read. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 09:37, 3 March 2012 (UTC)

How many years is “a few years”? We most definitely only use billion to mean 10⁹ even in British articles, although it used to mean 10¹² in Britain until the 1970s. ― A. di M.​  10:08, 3 March 2012 (UTC)

Oppose proposed change. I agree that the British view the use of the "#" key for numbers and more especially for pounds as an Americanism. In the UK, pounds are denoted either by "£" or by "lbs". It should also be noted that when computers were restricted to a 96 character set, there were various national character sets - the UK and the US sets were identical except that the UK had the symbol "£" instead of the symbol "#". Martinvl (talk) 09:50, 3 March 2012 (UTC)

No one is proposing to use # for pounds. And no one accessing a computer this century is restricted to 96 characters. Really, I will defend to the death the spelling of aluminium or colour, but # is pretty much universally understood now and is not an obvious flag of an American writer. But it's not formal use, it's an abbreviation, like &, and used in similar contexts.Barsoomian (talk) 10:03, 3 March 2012 (UTC)

(edit conflict)Nobody is proposing to use # for pounds! And that thing about 7-bit character encodings dates back several decades. ― A. di M.​  10:08, 3 March 2012 (UTC)

(edit conflict)x2! Ditto all that. Even Americans haven't regularly used "#" to mean "pounds" since my grandma was a teenager, as far as I can tell. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 14:45, 3 March 2012 (UTC)

I was highlighting why the symbol "#" is seldom used in the UK - there was a period when it just was not on our keyboards. Martinvl (talk) 08:55, 4 March 2012 (UTC)

Support new wording. It reflects actual usage in articles, and therefore more accurately describes the broad consensus of editors across Wikipedia. oknazevad (talk) 03:11, 4 March 2012 (UTC)

Links not in quotes but nearby

To link when a linkable term is within a quotation, I've been using an alternative method so as not to link within a quotation. Near the quotation, usually within a ref element supporting it, usually following a bibliographic citation in the ref element, I add something like "(Wikipedia has an article on the [[linked-to subject]].)". One editor removed one such instance but others have stayed in place, perhaps because they weren't noticed. If this method is useful, I suggest it be included in WP:MOS as a choice. Nick Levinson (talk) 17:06, 27 February 2012 (UTC)

Can you point to a specific example of each of the two formats? That would help. Thanks. Milkunderwood (talk) 17:41, 27 February 2012 (UTC)

I have to go home to find one or two, but the format is as given above, including the parentheses and linking brackets (you see the latter because I used nowiki markup). Only one format is being proposed; it is the alternative to linking within the quotation, which is not wanted. Does the format make sense now? Nick Levinson (talk) 17:56, 27 February 2012 (UTC)

I don't know why you are imposing such a restriction on yourself. So long as there is no reasonable doubt that the link is to the word as the speaker meant it, there is no editorialising of a quote simply by having some of it in blue on our screens: one might as well agrue that they didn't say the words in the font in which they appear on our screens. Kevin McE (talk) 18:10, 27 February 2012 (UTC)

See WT:MOSLINK#Links in quotations. ― A. di M.​  19:16, 27 February 2012 (UTC)

What an extraordinary restriction! If lifting a quote from today's newspaper (not one that is necessarily likely to appear in an encyclopaedic article, but it makes the point), on what possible grounds can it be wrong to put "[[Paul Scholes|Scholes]] and [[Ryan Giggs|Giggs]] are the best players [[Manchester United F.C.|this club]] has ever had"? Crazy! Kevin McE (talk) 19:59, 27 February 2012 (UTC)

It's one of the more controversial MOS points, and last I raised the issue myself, I thought we had consensus to stop trying to tell people not to link in quotations if it seemed helpful. This is probably the single most-ignored MOS rule. Some such links are annoying every-day-word links, some of them are POV-pushing or OR-synthesizing, but a very large number of them are necessary to make the article cohesive without being hair-pullingly redundant by including links to all the important terms immediately after the quotation that contains them. I have to confess that since I notice this restriction was put back in MOS, I have WP:IARed on this one with complete impunity and will continue to do so any time the result for article is better. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 06:56, 28 February 2012 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘We're losing the original issue. I accept the existing MOS provision against linking within quotations. I'm suggesting a method consistent with not linking within quotations. (I couldn't quickly find an example at home.) In short, the alternative method I propose is to link outside of the quotation, even if that means adding a nonquotational sentence just so a link can be provided. How does that sound? Nick Levinson (talk) 15:13, 28 February 2012 (UTC)
I did find an example, in the SCUM Manifesto article, in footnote 61: "Siegel, Deborah, Sisterhood, Interrupted, op. cit., p. 26 (referring to "the stances taken by the likes of Solanas and The Weathermen" (Wikipedia has an article on The Weathermen))". In this case, the link is piped from the Weather Underground article. The result is that the link is not inside the quotation. Nick Levinson (talk) 15:33, 28 February 2012 (UTC) (Corrected lack of paragraph break: 15:39, 28 February 2012 (UTC))

I understand. I and I think Kevin are suggesting this is grotesque. In the interim is seems like a good solution, but I for one don't think there's a solid consensus to retain such anti-link-in-quote restrictiveness, based on discussion that have taken place here within the last year or so. I'm too tired right this moment to go dig it out of the archives. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:49, 28 February 2012 (UTC)

How about “the stances taken by the likes of Solanas and The Weathermen [Weather Underground]”? (This is silly when the title of the linked article matches the text in the quotation exactly, but in that case the grounds to avoid linking from within the quote are less strong.) ― A. di M.​  09:58, 3 March 2012 (UTC)

The example confuses me. Do you mean that the original we are quoting said "the stances taken by the likes of Solanas and The Weathermen [Weather Underground]" or "the stances taken by the likes of Solanas and The Weathermen"? That is, are we just adding a link, or adding a [square-bracketed interpolation] with a link in it? If the latter, is it being added only for the purpose of linking, or would have we have added it as a clarification even if not linked? — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 14:41, 3 March 2012 (UTC)

The original (according to Nick Levinson, I've not read it myself) says “the stances taken by the likes of Solanas and The Weathermen”; the square brackets ought to make clear that the insertion of [Weather Underground] is ours not theirs. As for the second question, we're linking anyway, so what's it matter what we would do if we weren't linking? ― A. di M.​  14:50, 3 March 2012 (UTC)

Are both methods acceptable?

The method using internal bracketing technically works, but my first impression is that it will confuse some readers and editors and lead to bad followup editing by drive-by editors. And in cases where what gets linked needs quotation marks because they're in the article title (I think there are cases of that), it will look to readers like a quotation from the source when it's not.

The added-sentence method solves that, but adds bulk. Editors might prefer a choice. Would that be okay?

Nick Levinson (talk) 17:15, 3 March 2012 (UTC)

Apparent contradiction in "Bulleted and numbered lists" section

Resolved: Wording clarified.

Someone recently added (I then deleted, and someone reverted back) the undiscussed:

• Use proper wiki-markup, not HTML line-break tags (<br />), to separate list items

immediately before the long-standing:

• Do not leave blank lines between items in a bulleted or numbered list unless there is a reason to do so, since this causes the Wiki software to interpret each item as beginning a new list.

The former appears to directly contradict the latter. If your intent is to separate list items with more space, the way to do this emphatically is with <br />; there isn't even a wiki-template wrapper for this ({{br}} does something else). The "proper wiki-markup" way to do this would intuitively seem to be to simply insert a blank line, between list items, but this is verboten by the latter point, because it forks the markup into two lists, thus wrecking the semantic HTML value of using list code to begin with. 06:51, 28 February 2012 (UTC)

If this was supposed to address things like:

  1) The first point<br />
  2) The second point<br />
  3) The third point

then yes, this is common among noobs who haven't learned #-list wikimarkup yet, but the wording added is too vague, and this isn't really an MOS issue, its a "Help:" namespace thing. We don't need MOS to tell editors "you don't have to use <i>...</i> to do italics" or "please don't use bare HTML table markup; see Help:Tables". Coding how-tos, and wikimarup tutorials aren't really MOS's job. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:38, 28 February 2012 (UTC)

Just to be clear, I intend to re-delete this, per WP:BOLLOCKS as unclear guidance no one can actually follow, unless someone with a clear vision of why it was added rewords it to not contradict the line that follows it. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:38, 28 February 2012 (UTC)

Going twice... — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 14:58, 1 March 2012 (UTC)

Replaced it with pointers to pages on list style and coding. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:02, 3 March 2012 (UTC)

Merge WP:FAUNA sections to MOS

Resolved: Done.

Wikipedia:Naming conventions (fauna)#Article text obviously has to merge here, to WP:Manual of Style#Animals, plants, and other organisms (and get addressed in WP:LEAD, too). It's definitely in the wrong venue right now, being 100% prose/lead style advice that has nothing to do with article naming. It's actually very important, but quite hard to find because it's in the wrong page. For once, it's something on this topic that isn't already inside MOS proper that actually does have a very clear consensus record, having been arrived at in a well-attended RfC with a clear outcome, at Wikipedia talk:WikiProject Biology/Archive 4#Consensus how scientific names are displayed in the lead of species articles listed under common names.

I intend to rapidly merge this (as in within 24 hours) so if you have an objection, raise it quick. This is such a no-brainer it suggests there should be some kind of "WP:CSM", "Criteria for speedy merging". ;-)

Normally I'd be WP:BOLD and just do it w/o posting here about it, but anything to do with animal names seems to send tempers through the roof (including mine sometimes - no pot/kettle here), so I'm erring on the side of caution. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:08, 28 February 2012 (UTC)

• May need more discussion It must be made clear that the merged material only applies to fauna articles (the text to be merged is only at the fauna naming page, and the archived discussion has at the start "Plants and fungi are listed at their scientific names so this particular discussion does not apply to them"). Overwhelmingly flora articles are at the scientific name, but a few are at the common name when the scientific name is normally in bold, which is not recommended for fauna articles in the text to be merged. There seems not to have been a consensus on how to handle flora articles at common names. Peter coxhead (talk) 15:14, 28 February 2012 (UTC)

Right, sorry I wasn't clear that I was going to account for this. The wording at the linked-to RfC made this clearer (and better - it isn't only about fauna articles, but rather about articles titled based on common name rather than scientific; this is more common with animal than plant articles, but not exclusive to either). Regardless, it has no business being at WP:FAUNA, which despite the shortcut name is and only is an article titles naming convention, so prose usage is out-of-scope. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:47, 28 February 2012 (UTC)

Actually there's a general lack of clarity over where to explain conventions for article titles and where to explain conventions for the same word or phrase used in running text. I think that stuff about running text has crept into pages ostensibly about titles for this reason. Perhaps title issues should be subsections of more general pages? Peter coxhead (talk) 17:55, 28 February 2012 (UTC)

That does seem to be the general trend; cf. topical manuals of style (some labelled with {{style-guideline}} and named as part of MOS, some tagged with {{WikiProject style advice}} or nothing and named as part of the project; most of them contain short naming conventions as well, because it's really a subtopic of the style issue in most cases. I'd be generally supportive of the idea of moving all NC material to MOS pages when this can be done relatively seamlessly. (With, say, WP:NCP it probably couldn't be, because there are a lot of non-style concerns in it). At any rate, I think a wholesale change like that would be highly controversial and a proposal at WP:VPP to do it would probably fail, several times in a row. I suggest that a more likely approach would be to move all the non-title material to MOS pages, since it does belong in MOS and does not belong in NC pages, then note which of the topical NC's are left with hardly anything to do with naming that's actually topic-specific, and then merge those "stub guidelines" back into WP:AT. Six or so years ago, when I was first writing MOS:CUE (then, WP:WikiProject Cue sports/Spelling conventions), I tried to generate a stand-alone NC page for it too, before realizing there were approximately zero naming issues in that field that weren't either style issues I'd already covered, or general bio, organization, etc., issues already covered by WP:NC (now WP:AT) and the NC sub-guidelines. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:19, 29 February 2012 (UTC)

I'm not entirely sure what you mean above. If you mean that all discussion of conventions for naming organisms in running text should be in the body of the MOS, I think this is a bad idea. There are many complex issues in this field (e.g. differences between the codes of nomenclature in the use of connecting forms in ranks below species; how to handle the provisions of the ICNCP in regard to cultivars, Groups, grexes, trade designations; etc.). These don't belong in the main MOS; they are not of any concern to most editors. A few key issues (e.g. italics and only capitalize the genus name) should be in the main MOS; the rest should be in more specialized guidance. My point is that advice about the title of articles should be restricted to issues which are unique to titles (e.g. the preference for common names for animals but for scientific names for plants and fungi). All typographical issues relating to titles are the same as for running text, surely? So why separate the advice – it just leads to duplication and then disputes when there are differences (I hardly need to say this!!). Peter coxhead (talk) 09:55, 29 February 2012 (UTC)

Aye; the "geeky details" should be in subguideline pages and even (e.g. the hyphenation rules detailia of birds) at project pages. What I'm getting at is the naming conventions pages should not be trying to set prose style standards; it's utterly out-of-scope. If its helpful, they could briefly repeat some of the rules established in style guidelines. For example, I edited MOS:CAPS's section on organism names to mention parenthetically that bionomials are italicized where the page discussed how they are capitalized, because it would be "editor hateful" to mention only the caps rule there and force people to go looking at MOS:ITALICS for the italics half of the "how to format a binomial" question. But while MOS:CAPS now mentioned the italicization, it isn't the guideline that set that standard. WP:FAUNA is a naming convention page, and doesn't set style standards, even if it relies upon them internally in context and may cross-reference them for convenience, if you see what i mean. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 14:56, 1 March 2012 (UTC)

Wikipedia:Naming conventions (fauna)#Capitalisation of scientific names also has to merge here, for the same reasons, except a note that the title of an article that is the scientific name of the animal is in the form Homo sapiens not "Homo Sapiens". Nothing else in that section has anything at all to do with AT/NC issues. — Preceding unsigned comment added by SMcCandlish (talk • contribs)

I think you mean "Homo sapiens" emphasizing the lower-case "s". Art LaPella (talk) 03:08, 29 February 2012 (UTC)

I had some typos in there; now it says what it was supposed to. :-) — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 14:56, 1 March 2012 (UTC)

I would say, as I said above, that the note is rather that when the title of article is a scientific name it follows precisely the same conventions as for running text (both in capitalization and in italicization). Peter coxhead (talk) 09:55, 29 February 2012 (UTC)

Exactly. That even sounds like good wording to specifically use at the NC page after the MOSish stuff is merged here. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 14:46, 1 March 2012 (UTC)

Proceeding with the merges: Any more issues to raise? I'd like to get on this ASAP. This MOS/NC animal names cleanup has taken over a month already. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:49, 2 March 2012 (UTC)

Going twice... — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 23:56, 2 March 2012 (UTC)

Y Done – I've merged the stuff from WP:FAUNA that was not article-naming-specific into MOS pages, with cross-references. It ended up making more sense to merge this stuff to specific subpages like MOS:CAPS, MOS:ITALICS and MOS:LEAD rather than MOS:LIFE which is about capitalization. Ultimately it may make more sense to make MOS:LIFE be a page at WP:Manual of Style/Organisms and merge all this stuff to there, but at least the style stuff is now in style guidelines instead of lost in a naming convention page no one pays much attention to. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib.

Proposing MOS:GLOSS as an actual guideline

I propose that Wikipedia:Manual of Style/Glossaries have its proposal tag changed to {{MoS-guideline}}. Its advice is already being used as if it were "officially" a guideline. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 11:48, 29 February 2012 (UTC)

• Oppose Lots of good potential there, but still needs work. There is a current discussion highlighting problems with the Naming Conventions section at Talk:Glossary of botanical terms#Botany vs. botanical (irrelevant). --Tom Hulse (talk) 21:11, 2 March 2012 (UTC)

Except that it doesn't. MOS:GLOSS wouldn't affect any concern raised by anyone at that talk page. It doesn't say anything that contradicts that article's current name, Glossary of botanical terms, despite your claim in article talk to the contrary. Specifically, it says: "For a glossary list article that consists of a simple lead and a glossary, the form Glossary of subject terms is preferred, with redirects to it from [misc. plausible alternatives here]". It doesn't specify "subject in noun form"; that idea comes from WP:AT policy. If you have an issue with the idea that Glossary of botany terms is less ambiguous than Glossary of botanical terms, you'll need to that up at WT:AT to the extent anyone cares (I don't see anyone trying to move the article back to the "botany" version of the name), since AT is what recommends using the noun form for article names and redirecting to them from adjective forms and other modifications. MOS:GLOSS certainly said no such thing, and does not address this issue at all. Perhaps you'd like to review MOS:GLOSS again and reconsider your position? — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 09:19, 3 March 2012 (UTC)

Perhaps I misunderstood why you included it in that discussion, where you called it "a long-stable guideline proposal" as part of arguments justifying an aritcle move there. If you can clarify that (at my talk page?), I'll strike that part of my objection. To be more clear on "needs work": The article is far from stable. It had the under construction tag last month, and you have many, many undiscussed edits since then; even today you are still changing it. Here is the diff for the last month. For naming conventions, I don't think imposing rigid consistency, even if it's just requireing "terms" always helps improve Wikipedia. For instance Glossary of classical physics is much better without added "terms", but conversely Glossary of equestrian terms virtually requires "terms" to be added. I don't think a one-size-fits-all approach always works when the topics can be as unrelated as any two words in the English language. Also, the overall article reads awkwardly technical and overly verbose to my ear, although I am certainly not a glossary expert, so perhaps that is necessary. At least it might benefit from review by non-specialist, non-familiar editors. --Tom Hulse (talk) 13:09, 3 March 2012 (UTC)

I dropped you a line in user talk, especially about avoiding "one-size-fits-all". I'd like to address some of this here, since it's already public. By "stable" I don't mean "absolutely unchanging"; it's been tweaked in various ways lately, especially in response to technical changes in WP's deployment of the MediaWiki software (itself changed in the last year in ways that directly affect glossary coding), in Mediawiki:Common.css, and in the code of the members of Category:Glossary templates, as well as in response to issues raised by "live" glossaries. Transhumanist put an under-construction tag on it because he was cleaning up the wording in a marathon editing session, especially redundant bits, but changed very little about the underlying advice. That aspect of it has hardly altered in any important way in well over a year. Even as an official guideline, it couldn't "impose" anything; it's just trying to set a default, thus loose wording like "preferred" not "required". :-) I've been internalizing the more salient bits of the discussion at Talk:Glossary of botanical terms and thinking of how to revise the NC section to get at precisely what you're talking about without it sounding like "there is no convention, do whatever you like"; certain constructions make more sense than others, and it may take some time to sort that out. More detail at your user talk.

It is overly verbose, but I don't think any of it is intrinsically wrong in any sense at this point. Transhumanist was working on the verbosity problem, but has been busy lately. It is technical mainly because the MediaWiki parser has severe issues. The developers are actually working on (and supposedly nearing completion of) a from-the-ground-up replacement of the entire wikimarkup-to-HTML-output parser that should some day obviate half of that technicality, but the fact for now is that wikimarkup's handling of definition lists is very, very brittle and flaky. I think some of the more technical bits will fork off into a "Help:" namespace page, but it's not the only highly technical MOS page. The "geeky" factor wears off pretty quick. The template-defined glossary markup is so intuitive you end up internalizing it after coding only a few entries in a glossary. Way easier than things like wikimarkup tables. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 14:37, 3 March 2012 (UTC)

Small-capitals formatting

Various templates, most of which will surely be merged to {{smallcaps}}, are being used in article space to do things like "Mao Ze-dong" and "Leonardo di Caprio". I don't recall MOS addressing this, and it should, either pro or con. Sign me up for oppose: Wikipedia is not a business card, and encyclopedia prose is perfectly capable of explaining what is and isn't a subject's family name. Other uses illustrated in the template's documentation are also problematic, e.g. "Time magazine", which transgresses MOS:TRADEMARK. Similarly, "bce" copy-pastes as "bce", which is against both MOS:NUM and MOS:ABBR. I'm trying to think of any valid WP use for that style, templated or manual, in mainspace (I have used it myself on project pages, however). The "Unesco" case is weird, because some people actually favor following the goofy New York Times practice of rendering that as "Unesco" despite it being "UNESCO" in reality (NYT does thsi purely for typographic effect, not liking that some readers may misinterpret long acronyms as all-caps EMPHASIS; WP, last I looked, had not come to any consensus that this was a notable concern in our encyclopedia prose). — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 06:25, 5 March 2012 (UTC)

The one good use I can think of for small caps off the top of my head is in citing long banks of headlines in The New York Times, The Wall Street Journal and similar newspapers, especially in footnotes and Further reading/External links. In fact, I wish I'd used them more in some of my own articles based on such sources, e.g. Rhinelander Waldo and New York City mayoral election, 1917. Regular ALL CAPITALS are too big, and converting everything to lower case would diminish clarity and impact. ¶ As for the "goofy" New York Times practice, I'm pretty sure it's standard in British journalese for any abbreviation that can be pronounced as a word: Nato, Unicef, fifo, mirv, etc., and for a lot of unpronounceable abbreviations like mpg and rpg. —— Shakescene (talk) 12:22, 5 March 2012 (UTC)

As noted below by SMcCandlish but added here too for emphasis, all capitals should not be used in citing newspapers as per WP:ALLCAPS: "Reduce newspaper headlines and other titles from all caps to sentence case or title case". Peter coxhead (talk) 10:22, 6 March 2012 (UTC)

As noted in the {{smallcaps}} template documentation, the template should not be use in citation templates; else the rendered HTML markup will be included in the metadata. ---— Gadget850 (Ed) ^talk 12:45, 5 March 2012 (UTC)

WP:ALLCAPS says, "Change small caps to title case." Art LaPella (talk) 21:57, 5 March 2012 (UTC)

And note that this is an example of how even MOS regulars can't find MOS guidelines. Art LaPella (talk) 21:59, 5 March 2012 (UTC)

Heh. MOS:SMALLCAPS and WP:SMALLCAPS go there now too. Anyway, yeah, STYLE OF HEADLINES NOT EMULATED BY WIKIPEDIA. News at 11. So, the headlines in citations thing is doubly an invalid example. I'm wondering if there's any reason to not TfD this template, other than maybe modify it like {{xt}} to spit out a warning if you try to use it in mainspace. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 09:40, 6 March 2012 (UTC)

{{hard smallcaps}} preserves the caps when you cut and paste, and so would be more appropriate for things like BCE or NASA, biblical LORD (that has its own template, but there's also YHWH etc.), or linguistic-glossing abbreviations, complementing {{smallcaps}}. It needs to be modified to allow the vision-impaired to override it in their css, but it addresses some of the objections presented here against {{smallcaps}}. — kwami (talk) 21:26, 7 March 2012 (UTC)

I guess that LORD has to be accepted as a special case, and there may be others, but why should "BCE" or "NASA" be set in small capitals? {{Hard smallcaps}} addresses a technical issue with {{smallcaps}} but its existence can only increase the improper and un-necessary use of small caps in Wikipedia.

Returning to Gadget850's comment above, the {{smallcaps}} documentation may say that it shouldn't be used in citations, but the redirect {{aut}} is all over Wikipedia. Attempts to remove it have been met by quoting WP:CITEVAR which appears to give editors who have local consensus complete freedom to format citations however they wish. It seems pretty clear that WP:CITEVAR over-rides a note in template documentation. Peter coxhead (talk) 12:05, 8 March 2012 (UTC)

It is more a matter of see and do. I suspect that the majority of those using smallcap/aut do so because they saw it in use somewhere, and have never bothered to read the documentation. Having been a technical writer for many years, the first thing to realize is that documentation is quite often used after the fact. ---— Gadget850 (Ed) ^talk 13:00, 8 March 2012 (UTC)

Sure, I understand that. But some cases of the use of {tl|aut}} in particular are deliberate and are defended by WP:CITEVAR, which I don't think is right. I would like to see an additional bullet point added to MOS:ALLCAPS explicitly rejecting the use of small capitals for names. Peter coxhead (talk) 08:41, 9 March 2012 (UTC)

Agreed. The {{Aut}} redir to {{Smallcaps}} should be deleted. Anyway, you want to draft an addition to ALLCAPS? I think many of the uses suggested for it in the /doc of the Smallcaps template needs to be explicitly deprecated as well. PS: With regard to stuff like LORD, see Wikipedia talk:Manual of Style/Capital letters/Archive 4#smallcaps and LORD for previous discussion; a case can be made that Tetragrammaton-related stuff is an exception. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 14:06, 11 March 2012 (UTC)

Correcting case in quotes

MOSQUOTE isn't as clear as it might be about changing case in quotations. I have a situation in which part of a newspaper headline has been quoted. This particular newspaper capitalises the first letter of every word in the headline. The inconsistent use of caps is hard on the eye, and ideally I'd rather make the case consistent with the rest of the text. I'm trying to decide whether it's acceptable to change this — "Preserve the original text, spelling, and punctuation" would suggest that it isn't, but "Some text styling should be altered" indicates that it is. Any comments? Jakew (talk) 10:43, 6 March 2012 (UTC)

WP:ALLCAPS: Correct the case, for the same reason we don't COPY THE ALL-CAPS STYLE of newspaper headlines or try to Emulate Font Effects of titles on book covers. Titles (including headlines, which are just article titles) aren't quotations, they're metadata. PS: Titles of cited works, including article headlines, should be done in title case, not the sentence case we use for WP's internal headings. [Aside: I've seen some people in specific science fields insist on using sentence case in WP citations to journa artciles in their field, just because it's common in their field and they're used to it, but I've yet to see an actual system-wide consensus ever arise that this makes sense (it just confuses readers and leads to mix-'n-match styling in the refs section of every other article.) — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 11:12, 6 March 2012 (UTC)

PS: If you mean correcting the display of titles that appear inside quotations, I'd say still normalize them (keep in mind that handling of title formatting varies widely all over the place; e.g. a book title might be given in italics, boldface, underline or quotation marks, depending on the house style of whatever publication is writing about it. WP doesn't care.) Example: If we quote sloppy writing, e.g.:

• "In a People magazine interview, Johnny Depp was reported as saying 'I'm a big fan of the "Lord Of The Rings", and wish I could be in "The Hobbit", but I'll be too busy with "Pirates of the Caribbean V" all year.'^[5] Depp also..."

I would have no problem at all normalizing that mess to:

• "In a People magazine interview, Johnny Depp was reported as saying 'I'm a big fan of The Lord of the Rings, and wish I could be in The Hobbit, but I'll be too busy with Pirates of the Caribbean V all year.'^[5] Depp also...".

"Title", vs "hyper-title" capitalize-everything, vs. sentence case are just stylistic choices, like italics vs. bold. They're presentation versus content. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 11:34, 6 March 2012 (UTC)

Yes, I do mean text inside quotations. Thanks for your thoughts on the matter. I'm inclined to agree — certainly my first thought was to change the case. Jakew (talk) 13:06, 6 March 2012 (UTC)

It is unlikely that the newspaper headline would be a quotation: it is the name of the article. If my newspaper uses David Cameron's name in an article, and I refer to that article, using Cameron's name, that is not quoting the article. If I want to refer to an article called "Cameron and Cable in budget clash", the quote marks are because our MoS requires that as a way of marking such a title, not because it is a quote. Kevin McE (talk) 17:29, 6 March 2012 (UTC)

In this particular situation, another editor had quoted "Everyone's Favorite Baby Doctor" from the heading of this source, and had used that in a construction of the form 'described in the Los Angeles Times as "everyone's favorite baby doctor"'. Jakew (talk) 19:17, 6 March 2012 (UTC)

That's perfectly valid. It's still a quotable appellation, but it would not be capitalized when used as a quotation in that way, because we're quoting the words as as a statement, not as a title. I.e., they were only ever capitalized in the title because they were being used in a title, not because the L.A. Times writer went crazy and intended it to be some kind of proper noun phrase if ever used outside the context of the title. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 14:14, 11 March 2012 (UTC)

• I'd downcase newspaper titles from The New York Times et al. that cap all characters or initials, under the "Allowable typographical corrections" section. That's what I've encouraged The Signpost to do. Writers have always had to draw a boundary somewhere: for example, who would insist on the original font? Tony (talk) 09:15, 9 March 2012 (UTC)

• In the case of headlines, I would prefer to describe them as headlines rather than just quotes. First, headlines have to be short, so describing a headline as such warns the reader that subtleties may have been omitted. Second, the author named in the byline of a newspaper article often does not have control over the headline, so describing the headline as such prevents readers from attributing the exact wording to the author, but rather to the newspaper as a whole. Jc3s5h (talk) 15:08, 11 March 2012 (UTC)

additional very common use of hyphens

Another very common use of hyphens is found in object–verbal noun compounds, such as egg-beater and pizza-lover. In some cases this avoids ambiguity: "They stood near a group of alien lovers" implies that they stood near a group of lovers who were aliens; "they stood near a group of alien-lovers" clarifies that they stood near a group who loved aliens. We should probably have a subsection on this. — kwami (talk) 21:18, 7 March 2012 (UTC)

This seems akin to the second item of hyphen usages:

• A hyphen can help to disambiguate (little-celebrated paintings is not a reference to little paintings; a government-monitoring program is a program that monitors the government, whereas a government monitoring program is a government program that monitors something else).

Perhaps that can be expanded a little to include this example. Jojalozzo 21:28, 7 March 2012 (UTC)

A man-eating shark differs from a man eating shark.—Wavelength (talk) 21:33, 7 March 2012 (UTC)

Good example.

I think it's more than just 'other dabs'; IMO govt-monitoring program should be split off. Compound modifier and object–verb compounds are distinct constructions grammatically, and both are cases where some authors consistently hyphenate even when there's nothing to dab from. — kwami (talk) 22:09, 7 March 2012 (UTC)

I often consult the English compound article to decide if the Main Page should have a hyphen. Art LaPella (talk) 22:42, 7 March 2012 (UTC)

Yikes! That article showed compounds of numeral and noun and called the result an "adjective". I know "adjective" sometimes includes nouns in style guides, but that's pretty sloppy when we're distinguishing compounds made of nouns or verbs from ones actually made of adjectives. — kwami (talk) 00:26, 8 March 2012 (UTC)

Can quotation marks inside quotations within quotations be altered?

Resolved

According to Wikipedia:Manual of Style#Quotations within quotations:

When a quotation includes another quotation (and so on), start with double quote marks outermost, and, working inward, alternate single with double quote marks ("She accepted his statement that 'Voltaire never said "I disapprove of what you say, but I will defend to the death your right to say it."'", with three levels of quotation).

However, if we're quoting something written, that amounts to saying that quotation marks inside the quote can be changed from double quote marks to single quote marks or vice versa. Are such alterations actually allowed, without the need for indication? --Chealer (talk) 19:16, 8 March 2012 (UTC)

Please note that responses will be applied as an unjustified excuse for tendentiously abusing the close paraphrasing banner at Materialism. See also Wikipedia talk:Close paraphrasing#Reversion of change to milder problems template.Machine Elf ¹⁷³⁵ 19:42, 8 March 2012 (UTC)

I can't see that the question has anything to do with close paraphrasing. Peter coxhead (talk) 09:00, 9 March 2012 (UTC)

Neither do I, but then again quotation marks aren't called "space before ellipsis", (4 minutes later). However, those particular quotation marks, the outer ones, are of central importance to someone being harassed for close paraphrasing a cited direct verbatim quote.—Machine Elf ¹⁷³⁵ 13:06, 9 March 2012 (UTC)

The answer to the original question is surely "yes, in this case". There are no semantic implications whatsoever of the choice of single or double quotes to mark direct speech; it's merely a stylistic choice. (The same applies to changing all capitals or small capitals to title or sentence case, which is specifically required by MOS:ALLCAPS.) So changing one kind of quote mark for the other when they are used to mark direct speech is irrelevant. On the other hand, suppose the source uses different kinds of quote marks to make semantic points as in "None of his 'species' is currently accepted." Here the single quotes around "species" are a signal that the writer is saying something equivalent to "None of his so-called species is currently accepted." Here there would be a problem in changing single to double quotes, since these aren't normally used for this purpose. Peter coxhead (talk) 09:00, 9 March 2012 (UTC)

Peter, you keep asserting this single quotation marks are for scare quotes and double quotation marks are for quotations distinction, but I cannot find this documented anywhere in US or British style guides. I've lived in the UK and the US and Canada, and am very well-read, but cannot ever recall encountering this. What's your source? — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 23:55, 11 March 2012 (UTC)

You might not "normally" use double quotes in that case, but it isn't a rule that I've seen. The more important rule is that nested quotes should always alternate. That gives you a problem if you want to give the different styles of quotes a different significance. Some writers do, but they always end up having to break one rule or another in complex cases. And worse, the reader cannot know what code the writer is following (what "semantic point" he intends) unless he's footnoted what he's doing. So I always use a one style of quotes for all purposes: direct quotes, scare quotes, whatever; and the other style only for nested ones. Barsoomian (talk) 10:29, 9 March 2012 (UTC)

The key point is surely that if a reader of the original source could determine the meaning of the style of quote marks used, then any quotation of this source must preserve the same meaning. A reader of the original and a reader of the quotation must be able to make the same interpretation of the quote marks, otherwise it isn't a true quotation (effectively it's a quote out of context). How to solve this problem is another matter; it may be better to avoid a direct quote in such a case since Wikipedia doesn't use the same convention. Peter coxhead (talk) 11:48, 9 March 2012 (UTC)

My point is that the reader often has no idea that a special meaning intended by using one style of quote or the other. From my experience elsewhere, it's rare that the writer actually has a logical system, and scrupulously preserving the quoting style doesn't convey any meaning, other than to highlight the inconsistency of usage. Where the writer has stated that he does have a system, well of course you should try to preserve that. Barsoomian (talk) 12:39, 9 March 2012 (UTC)

It's correct that Wikipedia does not make this alleged "scare quotes" distinction. If the writer did have a stated system, it still wouldn't make sense to preserve it here, since our readers would not understand that system or even notice that it existed and that we were bowing to it. If such a weird case ever arose, it would be much better to explain what the person said in new prose rather than quote directly, I would say. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 23:55, 11 March 2012 (UTC)

Hi Peter, yes, this is similar to the situation for capitals. To clarify, we have a conflict of rules in this situation, and my question is which one should have an exception. For capitals, it is more or less clear that the rule on capitals wins, as Allowable typographical changes specifically excludes small capitals (although, shouldn't we change that to just (any) capitals?). I am asking what should prevail between Minimal change and Quotations within quotations, and if the latter wins, are indications of modification needed. Looking at the answers, I would say the latter wins. Does anyone oppose adding an explicit exception to Minimal changes for changing single quotes to double quotes and vice versa? --Chealer (talk) 16:32, 9 March 2012 (UTC)

I took that as a no. --Chealer (talk) 18:01, 11 March 2012 (UTC)

Works for me. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib.

Yes, when you quote something, you can change double-quotes within the quoted material to single ones. Similarly, you can capitalize the first letter of a sentence even if it is part of a direct quote and was not capitalized in the original. — Carl (CBM · talk) 14:43, 9 March 2012 (UTC)

A capitalization change should be "[D]one like this", however. It isn't merely typographic, but indicates the beginning of a sentence (or "[l]ack of one") that doesn't match the reality of the original quotation. It's semantically meaningful, sometimes crucial. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 23:55, 11 March 2012 (UTC)

It is perfectly standard to simply change the capitalization in quotes without that sort of square bracketing. This is section 13.16 of the Chicago manual, for example. The use of square brackets like that is usually limited to legal commentary and textual analysis (it was the "third option" for quotation styling in the old CMOS). Ordinary scholarly work is allowed to change the capitalization without any additional marks, as described in 13.7 there. — Carl (CBM · talk) 17:57, 13 March 2012 (UTC)

Recent addition: Comma usage uniformity

This text was recently inserted:

• Prior to a quotation embedded within a sentence, the use of a comma is optional but should be consistent within a Wikipedia article. Eve said "Adam ate the apple." Adam said, "Eve gave it to me."

I don't think this should be ensconced as a rule. Some writers might use the comma after a speech tag such as X said, but not in other instances, where the comma might be an unnecessary bump where "a quotation is embedded smoothly into the grammar of a sentence". Tony (talk) 09:24, 9 March 2012 (UTC)

This also ignores use of the colon to introduce a quote, as mentioned under Colons already. Barsoomian (talk) 10:14, 9 March 2012 (UTC)

• I think this edit is well-intentioned, but it is narrowly focused, hence misleading. I think the editor was trying to say:

  Comma usage conventions should be consistently followed throughout any given article. For example, if an article places commas after an introductory date in a sentence (e.g. In 1842, the French ..." ) that convention should be used in everywhere or nowhere within an article. Likewise for commas between the word "said" and a quote (e.g. Adam said, "Eve gave it to me.") and for any other comma usage convention.

I think this is not a bad policy, and is consistent with general "be uniform within an article" MOS rule. But I'm not sure it needs to be restated for comma usage, because the "be uniform within an article" is ubiquitous for all MOS guidance. There is no need to repeat "be uniform within an article" within every MOS section. --Noleander (talk) 12:03, 9 March 2012 (UTC)

• • Yes. When I first read MoS and a few of its subpages in late 2005, these incantations about keeping articles uniform, and not applying MoS to quotations, were scattered all over the place—it didn't make the page clearer, and lacked "hierarchical" logic. Now, the general principles are at least stated at the top, and Noleander's right, they shouldn't be restated locally. But sometimes flexibility within an article is required. For example, if I chose to write an article without commas after sentence-initial time phrases, I'd be uncomfortable at "In 2011 13 captives were released ...", so would favour inconsistency on one level. And a comma after a sentence-initial phrase can sometimes be bumpy if the sentence is short. By analogy, I used to allow inconsistency WRT the so-called Oxford comma, when I didn't really like adding yet more commas to technical text (there are plenty already). But I did use it to disambiguate: not "they had healthy dogs, fattened pigs and cows", but "they had healthy dogs, fattened pigs, and cows", where the cows weren't fattened ... bad example, but I can't think of anything better right now. I still retain flexibility as an editor of other people's text on this point. PS After two years of disagreement on the matter, someone here has finally persuaded me to use the O. comma all of the time in my own writing, on the basis of logic. Tony (talk) 12:41, 9 March 2012 (UTC)

You should reconsider. >;-) The Oxford or serial comma is only needed if amibiguity is likely to result; otherwise, it's just really annoying and people like me will delete it on sight. Heh. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:06, 12 March 2012 (UTC)

• While this small matter is being considered, could someone figure out if the edit to the examples by SMcCandlish should be undone? The point of the examples was simply to provide both punctuation styles, with and without a comma, in two brief sentences. Now, both examples are of the same style. And of course there is no need to make them consistent because they're in the same article, since they're merely examples of the two styles. Bob Enyart (talk) --

Then it needs to be redone as two clearly seprate examples with "or" between them; what you put in there was one example showing a mixture of styles, precisely what the addition was trying to forbid! Eve said "Adam ate the apple." or Eve said, "Adam ate the apple." but not Eve said "Adam ate the apple." Adam said, "Eve gave it to me.". Colon usage is completely distinct, being for introduction of long, complex quotations of full sentences that are just short of block-quotation length, and it shouldn't be used for short quotations as in Eve said: "Adam ate the apple." Also, I agree with Noleander's rewrite – this really isn't about commas in particular but consistency more generally – and with the idea that something like that, if such clarification is needed, should be in the general section on intra-article consistency, not re-inserted in every other MOS section. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:06, 12 March 2012 (UTC)

• • I see that this has been recently edited to express the usage as completely optional. Fine, but I'm inclined to say that it wasn't worth inserting in the first place, given that reducing the size and complexity of the MoS should be a priority. Will it really help editors? Tony (talk) 09:05, 13 March 2012 (UTC)

Spaced dashes

Can someone explain to me how Frederick Douglass–Susan B. Anthony Memorial Bridge is a superior title to Frederick Douglass – Susan B. Anthony Memorial Bridge? The latter is clearer and easier to read and parse. Powers ^T 20:37, 9 March 2012 (UTC)

I figured as much. Why did we ever get rid of spaced dashes? Powers ^T 23:03, 12 March 2012 (UTC)

• Comment. There's probably not a huge appetite for opening up this issue again, but I don't see either form as being superior or inferior to the other. I'm happy to use the form that most sources use when the endash is employed, which is the unspaced. Good Ol’factory ^(talk) 23:17, 12 March 2012 (UTC)

I'm "hungry" enough. I agree with LtPowers. It's weird and awkward to not space it in this case. We do space it in similar cases such as "February 26 – March 3, 2012". Where do explicitly say not to space a case like the bridge example? — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 02:31, 13 March 2012 (UTC)

IIRC, it used to be explicitly stated that we should space the dash in such instances. Then there was a huge discussion about it that resulted in that being taken out, the implication being that we are no longer recommending that usage, but defaulting to common usage in the specific case. That's roughly it, I believe—the general thrust was a movement away from the spaced endash in most circumstances. There was not enough give and take on the issue to make anything more explicit than that apart from the examples that are given, some of which I think could be interpreted to recommend no spaces in this case. Good Ol’factory ^(talk) 02:36, 13 March 2012 (UTC)

I have been interpreting the current version of WP:ENDASH to specify that "Frederick Douglass–Susan B. Anthony Memorial Bridge" should be unspaced. Specifically, it says: "An en dash is used for the names of two or more people in a compound. the Seifert–van Kampen theorem ... The en dash in all of the compounds above is unspaced." This differs from WP:ENDASH's date section, which says: "The en dash in a range is always unspaced, except when the endpoints of the range already include at least one space. 23 July 1790 – 1 December 1791, not 23 July 1790–1 December 1791". As usual, this is a comment on what the guideline says, not what it should say. Art LaPella (talk) 04:21, 13 March 2012 (UTC)

The decision was definitely to recommend no space in such constructions, much to the consternation of Tony and Noetica and a few others who preferred the spaced style, if I recall correctly. Obviously, with a hyphen, you'd want spaces; with the en dashes, some still do, but I think the compromise is fine, too. This is an area where typography and styles do vary a lot, so trying to go by "common usage" isn't going to get us anywhere useful. Some, like the city of Rochester page, just use unspaced hyphen! Some books do it our way, like this one and this one. I don't find any with spaced en dash, except this magazine with spaced en dash in title and spaced hyphen in the text! Dicklyon (talk) 05:22, 13 March 2012 (UTC)

It just seems to look cleaner and clearer with the spacing. Shouldn't we at least retain it as an option? Powers ^T 18:49, 13 March 2012 (UTC)

Long dash

In some bibliographies the name of an author for whom more than one work is listed is not repeated, but substituted by a long dash; see, e.g., MHRA Style Guide (2002), p. 54. This long dash is often longer than an ordinary em-dash. Does Wikipedia have any guidance, policy or other advice on this practice? I thought I saw something, but can't now find it. Here's an example, using an em-dash:

• Richard Morphet. E. Q. Nicholson, designer & painter. London: Cygnet Press, 1990.
• — In memory of E. Q. Nicholson: service taken by the Reverend Peter Elvy, Chelsea Old Church, London November 4th 1992, E.Q.'s birthday. [London? : the Nicholson Family?], 1992.

That dash appears to me too short for its job. Is there, or should there be, a better solution? Justlettersandnumbers (talk) 13:28, 11 March 2012 (UTC)

Some publications use "Ibid.".—Wavelength (talk) 15:07, 11 March 2012 (UTC)

But Wikipedia discourages "Ibid." Art LaPella (talk) 18:22, 11 March 2012 (UTC)

Which it needs to stop doing, since we have {{reflist|ref=...REFERENCES HERE}} these days and can keep the references in one place and re-order them with trivial ease. That would be far preferable to using long dashes. If you must use one, just doing two or more em-dashes in a row should suffice: —— In memory of E. Q. Nicholson... See if CMoS, Hart's, etc. say how to make one. Though, thinking back, aren't they several underscores in a row ( ____ In memory of E. Q. Nicholson...), not any form of dash? I'm pretty sure they are underscores... — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:13, 12 March 2012 (UTC)

The Chicago Manual of Style (13th edition: 1982), section 15.90 etc., uses a 3-em dash for a repeated name. Whether they had this glyph in the font or did it by kerning dashes is unstated. This ——— (three em dashes kerned minus .2 ems) is produced by a span: if this type of thing is desirable a template would probably be better that a span. Modal Jig (talk) 16:15, 12 March 2012 (UTC)

I don't think this is the ibid. situation anyway; this isn't a repetition of the same source, but citation of a different source by the same author. Justlettersandnumbers (talk) 18:35, 11 March 2012 (UTC)

Right, it's id. (idem), not ibid. (ibidem). — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:13, 12 March 2012 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Yes, that sounds much better. Thank you for the span suggestion, mj, though the kerning needs to be -.3 to close the gaps on my display; that will do fine as a one-off solution. I agree that a simple template would be much preferable if the thing were to be much used. Which leaves the question of whether or not it should be used. Is there any reason it shouldn't be? Justlettersandnumbers (talk) 16:32, 12 March 2012 (UTC)

Given that it generally isn't, the real question is why it should be, when id. and on later uses just id. work perfectly well and are much less mysterious. PS: I wouldn't cite Chicago 13th for anything at all; it's a generation and a half (or so) out of date. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 21:35, 12 March 2012 (UTC)

Overquoting and overuse of blockquotes

Would you guys add something about overquoting and overuse of blockquotes to WP:MOSQUOTE? You know, something about WP:QUOTEFARMS? At the Sophia Bush article, I have had to revert an editor who should actually be familiar with not only the way headings are supposed to be formatted, but also how blockquotes should be used. When I pointed him to WP:Manual of Style, citing proper use of headings and quotes, he told me that WP:MOSQUOTE says nothing about overuse.[7] I ask, "Why is that? And are you willing to change that?" 31.193.133.208 (talk) 06:49, 12 March 2012 (UTC)

• Support'! This is actually a growing problem. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 02:43, 13 March 2012 (UTC)

Caps question: Oregon Coast

Since the wikiproject Oregon was invited to comment, I figure we should also invited some more central guidance. Anyone want to comment on Talk:Oregon Coast#Requested move? Dicklyon (talk) 18:49, 12 March 2012 (UTC)

Should "alright" not be used on Wikipedia? Should it be replaced with "all right"?

Hopefully this is the right place to ask this question, but if not, please direct me to the right place. I noticed an edit come up on my watchlist where "alright" was changed to "all right" with AWB, and listed as "typo fixing". I think the reason for the edit stems from an entry on Wikipedia:Lists of common misspellings (I assume AWB is using that list, since it is linked from Wikipedia:AutoWikiBrowser/Projects). Is "alright" too informal to use in Wikipedia articles (I've seen sources that say it is non-standard, but in actual usage I think it is now very common)? If "alright" is too informal, is "all right" an appropriate replacement? I think to a lot of people the two mean different things, with "alright" meaning "acceptable", but "all right" meaning "entirely correct". When "alright" is used in articles, should it instead be corrected to something else, such as "acceptable" or "fine", or is "all right" actually the best replacement for "alright"? Calathan (talk) 17:39, 13 March 2012 (UTC)

I would say that both "alright" and "all right" are too informal for the encyclopedic tone that we are aiming for. I think that they might also be associated with excessively pedagogical text. I would replace them with some more formal synonym. — Carl (CBM · talk) 17:50, 13 March 2012 (UTC)