Jump to content

Wikipedia talk:Manual of Style

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Facu-el Millo (talk | contribs) at 22:47, 29 March 2020 (→Use of commas). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style articles
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate.
Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
Note icon
For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

Style discussions elsewhere

Add a link to new discussions at top of list and indicate what kind of discussion it is (move request, RfC, open discussion, deletion discussion, etc.). Follow the links to participate, if interested. Move to Concluded when decided and summarize conclusion. Please keep this section at the top of the page.

Current

(newest on top)

Concluded

Extended content

RfC: Use of Large Quotes in article space, and the Cquote template

The Cquote template is used in many articles to set off quotes with large quote marks. The MOS says not to use it in articles and the template also contains that instruction.

Thus, rule and practice are not in good alignment. How should we fix this (if we should)? Should the quote marks be removed from those articles that use it by modifying {{Cquote}}? Or should the MOS be changed?

-- DES (talk)DESiegel Contribs 00:01, 29 December 2019 (UTC) and Herostratus (talk) 14:26, 29 December 2019 (UTC)[reply]

Additional background material

This is {{Quote}}:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Sit amet porttitor eget dolor morbi. Scelerisque mauris pellentesque pulvinar pellentesque habitant morbi tristique senectus.

And this is {{Cquote}}:

DES (talk)DESiegel Contribs 00:01, 29 December 2019 (UTC) and Herostratus (talk) 14:39, 29 December 2019 (UTC)[reply]

Specific proposals

DES (talk)DESiegel Contribs 00:01, 29 December 2019 (UTC) and Herostratus (talk) 14:26, 29 December 2019 (UTC)[reply]

  • Proposal 2: Change the MOS to match the usage.
    • Proposal 2A: Remove the proscriptive clauses from the MOS etc. and replace them with nothing -- neither encourage, nor discourage, use of {{Cquote}}; just don't mention it. (This entails removing "(and especially avoid decorative quotation marks in normal use, such as those provided by the {{cquote}} template)" from the third sentence of WP:BLOCKQUOTE, and "also" from the fourth sentence. And remove similar proscriptive language from the documentation of {{Cquote}} and any other appropriate language.)
    • Proposal 2B: Remove the proscriptive clauses from the MOS etc. and replace them with explicit allowance of {{Cquote}}. This entails editing the beginning of WP:BLOCKQUOTE to something like along these lines:

Format a long quote (more than about 40 words or a few hundred characters, or consisting of more than one paragraph, regardless of length) as a block quotation, indented on both sides. Block quotations can be enclosed in {{Quote}} (which just indents) or {{Cquote}} (which adds large quotation marks). Do not include text quotation marks at the beginning and end of blockquoted text. Block quotations using a colored background are discouraged.

And making appropriate edits to the {{Cquote}} documentation and elsewhere as appropriate.

Herostratus (talk) 10:25, 29 December 2019 (UTC)[reply]

Survey

  • As proposer, I support proposal 1 , converting all uses of {{cquote}} into MOS-compliant blockquotes without needing to edit thousands of articles. The MOS on this issue has had consensus for years, the need is to bring articles into compliance. DES (talk)DESiegel Contribs 00:04, 29 December 2019 (UTC)[reply]
  • Support proposal 1C. I think it's going to cause confusion for the typical editor when one expects the template to render a decorative block quote but it doesn't, so I would rather the template trigger the visual cue that it is not to be used in the article namespace. The benefit of it doing that outweighs the cost of running the bot to replace it in the article namespace. I prefer proposal 3 over 2 because it continues to display the content to minimize the impact of accidental use on the readability of the article. But I would support using proposal 1 until that replacement process is complete, so the immediate compliance can be had right away without obtrusive error messages. --Bsherr (talk) 04:56, 29 December 2019 (UTC)[reply]
  • Support proposal 1C as per Bsherr. A one time run on ~16000 articles is not a massive replacement, and makes things clear for editors. Galobtter (pingó mió) 06:07, 29 December 2019 (UTC)[reply]
    Oppose 2: if quotation marks are needed around a quotation, they do not need to be the massive, decorative (and IMO ugly) quotes of {{cquote}}. Consistency in presentation (i.e. using blockquote for all quotes) makes things clear for readers. Also per the overemphasis arguments below. Galobtter (pingó mió) 17:12, 30 December 2019 (UTC)[reply]
  • Support Proposal 2. 2A and 2B are fine, for my part I support 2B. Here're my reasons:
    1. Change the documentation on merits of reader experience: Quotation marks are the universal signal to English speakers that the material contained between them is a direct quotation. {{Quote}} uses only indentation, familiar to readers of serious texts but not everyone.
    2. Change the documentation on grounds of staff gruntlement: like it or not, a lot of editors seem to continue to want to present quotations using {{Cquote}}. In spite of the MOS's flat-out prohibition, and occasional outbreaks of people "fixing" these "errors", we have about 17,000 articles that use {{Cquote}} to present quotations -- 10% of articles, as opposed to 85% for {{Quote}} (the other 5% is {{Quote box}}), in spite of the fact that it's explicitly prohibited, and also people keep deleting it because "the rule says so". Generally, rules here are supposed to codify common practice, within reason. Micromanaging editors by imposing an order to stop using a tool they find useful and superior as they write and present material -- that is, the actual work of the project -- for insufficient reason is not a good way to grow and nurture a group of volunteers.
    3. Change the documentation on ground of upholding Wikipedia process. The admonitions not to use {{Cquote}} in articles was put into the MOS in 2007 by an editor on his own initiative, after an extremely short discussion ([Quotation marks around block quotes (ie: cquote template) here]) which if anything told him not to. Nobody noticed, or cared enough to roll it back, or whatever; it happens. So that editor "got away" with making this new rule. As you all know, once a rule is put in place (however it's done), it's very hard to get the supermajority necessary to remove it -- it's a weakness of the Wikipedia that if you can sneak something it and get away with it for a while then you have the whip hand. So we're stuck with this editors personal rule, which he (and others) continue to enforce on grounds of "fixing format to follow the rule". It stinks, it stinks to high heaven. Exploiting our constitutional weaknesses is not usually looked on kindly and is not how rules in the Wikipedia are supposed to be made. I don't want to reward or valorize this sort of thing and I hope you don't either.
    4. Change the documentation on merits of the aesthetics: There's no need to present the reader with a wall of text. Section breaks help some, and images break up the layout, but sometimes you don't have these in your toolbox. {{Cquote}} (and it sidebar version {{Rquote}} can help with this.
Herostratus (talk) 15:39, 29 December 2019 (UTC)[reply]
Quote marks are not "the universal signal" of quotation, or block quotation could not exist, yet it is the dominant style across all English-language publishing for large quotations. A "lot" of editors do not want to use the decorative template. The vast majority of our block quotations are done with {{Quote}}. Most uses of {{Cquote}} are old, pre-dating any cleanup attempts, while conversion of them to {{Quote}} goes unreverted in over 99.5% of cases (I've done this experimentally with hundreds of instances), and only a vanishingly small percentage of our editors personally go around inserting this decorative template instead of {{Quote}}. So, the rule does codify common practice even by Herostratus's own numbers (only 10% of usage is {{Cquote}}, shrinking all the time). And see WP:CONSENSUS: a guideline in place since 2007 and followed almost all of the time except by people who don't read the guideline (and who virtually never object when their inappropriate choice is gnomed to comply with MoS) and by a tiny handful of "resisters" (see WP:BATTLEGROUND) self-evidently has consensus. A few people being loud about their dislike of it here is insufficient to overturn it. WP:CCC doesn't mean "a rule is invalid if 10 people don't like it." There would have to be a massive showing of a change of consensus.  — SMcCandlish ☏ ¢ 😼  06:27, 30 January 2020 (UTC)[reply]
  • Support 1A The current Cquote is used normally to ovr-emphasise a cherry-picked quotation. This proposal will have the effect of educing it to a more appropriate display. for an encyclopedia These of the current cquote is editorializing--appropriate to newspapers and magazines, where editorializing is expected.. It hanse real use in an encyclopedia , at least not in mainspace. DGG ( talk ) 07:38, 30 December 2019 (UTC)[reply]
  • Support 1A as the least obtrusive of the solutions. Oppose any variant of 2 as setting up another long nightmare of multiple styles that don't add any value to our articles but waste a lot of editor time converting them back and forth or setting up policies to prevent them getting converted back and forth. —David Eppstein (talk) 07:50, 30 December 2019 (UTC)[reply]
  • Support 1A—quick and unobtrusive way to bring articles into MOS compliance, to be replaced by 1C after all uses of the box in mainspace are gone, to help editors who are adding quoteboxes pick the right template per Bsherr. Oppose any variant of 2 because these quote marks do nothing to add to encyclopedic value and just clutter the page, while overemphasizing certain points of view. Quotes (even quoteboxes, IMO) have their place on Wikipedia but we have to be careful to keep them to their place lest we endanger NPOV. buidhe 10:05, 30 December 2019 (UTC)[reply]
  • Support Proposal 2 per the good reasons listed by Herostratus. Quotation marks are not decoration; they are punctuation. Changing the punctuation of thousands of articles in a broad-brush way without inspecting the effect on their meaning would be outrageous. As the supposed rule never had consensus in the first place and it is widely ignored, it should be voided per WP:NOTLAW and WP:CREEP. Andrew🐉(talk) 10:36, 30 December 2019 (UTC)[reply]
    • They are not punctuation in that context (or, rather, are redundant punctuation mis-serving as decoration). Block quotations (with or without giant quotation marks) are block-indented; this is what sets them off as quotations. WP did not invent this style; it is what is used in around 99.9999% of professionally produced publications. (Even newspapers and magazines do not do this decorative stuff with block quotations, they do it with pull quotes, which is not what this template is being misused for on Wikipedia.) Just auto-converting this template's output to that of {{Quote}} will not have any negative effect at all, except possibly in bonehead cases, where someone has ignored even the documentation of the template and attempted to do something with the template that wasn't contemplated by its designers. That'll be a handful of cases to repair manually.  — SMcCandlish ☏ ¢ 😼  06:27, 30 January 2020 (UTC)[reply]
  • Strongly Oppose any of proposal 2–A or B: MoS is just fine. GenQuest "Talk to Me" 14:46, 30 December 2019 (UTC)[reply]
  • Support proposal 1A: Kill the C-Quote in articles. It's distracting, ugly, and serves no purpose which is not already handled by the much more professional looking {{Blockquote}}. GenQuest "Talk to Me" 14:46, 30 December 2019 (UTC)[reply]
  • Support 1A, Oppose both 2A and 2B - Ealdgyth - Talk 17:51, 30 December 2019 (UTC)[reply]
  • Support proposal 1A, agree with what GenQuest and other have said. MB 18:19, 30 December 2019 (UTC)[reply]
  • Support prop 1 I would prefer 1B and deprecate its use entirely, but I would not oppose 1A either which seems to be most popular. — Wug·a·po·des​ 19:58, 31 December 2019 (UTC)[reply]
  • Support 1C per MOS.--Srleffler (talk) 22:40, 31 December 2019 (UTC)[reply]
  • Support 1A/1C. This is a fantastically small aberration in consistent usage we can easily remove with very little fuss, so let's do it. (I'd say that {{cquote}} should ultimately be dumped entirely so it can't inadvertently be used anymore anyhow, but that's neither here nor there.) Der Wohltemperierte Fuchs talk 23:16, 31 December 2019 (UTC)[reply]
  • Support proposal 2 for the reasons described by Herostratus. The entire point of cquote is to draw attention to the quote and the large quotation marks help with that. Otherwise, we may as well just keep quotations in regular body text. --Coolcaesar (talk) 16:38, 1 January 2020 (UTC)[reply]
    You're quite right that the purpose of cquote is to draw attention to the quote. The template is designed for pull quotes. The problem is that editors often ignorantly use the template for block quotations. That is not what the template is for, and block quotations generally should not be highlighted in that way. This incorrect usage dominates the use of cquote in articles; cases where cquote would actually be appropriate are rare.--Srleffler (talk) 19:52, 1 January 2020 (UTC)[reply]
    It was not designed for, and was never used for, pull quotes. We don't use pull quotes here, basically never. At some point in the template's history, somebody just wrote into the documentation that it was for pull quotes. Probably just the whim of a single misguided editor, so basically near to vandalism (I haven't checked, but it's hard to imagine any kind of serious discussion ending in the idea that pull quotes should be supported, since we don't use them and shouldn't.) Herostratus (talk) 23:58, 1 January 2020 (UTC)[reply]
    Balderdash. Its style is borrowed completely from pull quotes as used in various magazines, and in my sporadic cleanup sprees, I have found it used both for actual pull quotes (which repeat material, in showy form, already found embedded in the regular prose) and fake pull quotes, in the sense of not being found already in the main text but serving the same encyclopedically inappropriate purpose of drawing undue attention to a particular party's statement.  — SMcCandlish ☏ ¢ 😼  07:49, 2 January 2020 (UTC)[reply]
    @Coolcaesar: The "reasons described by Herostratus" are demonstrably wrong.  — SMcCandlish ☏ ¢ 😼  08:18, 2 January 2020 (UTC)[reply]
  • 1A, then 1C after all extant uses are corrected, per Buidhe's reasoning. The in-mainspace behavior change proposed for {{cquote}} should also be done with the other "decorative quote" templates (borders, boxes, centring, sidebars, etc.), though we should fork one to {{Document excerpt}} for a sidebar containing a document excerpt (i.e., something that is serving the same function as an image, but is presenting wiki-formatted text from a document rather than a facsimile of it). This is a well-accepted use of quotation sidebar templates. I would simply take the features from the extant quote sidebar templates and combine them into a single template (with output and parameter names consistent with the majority of the other quote templates – one of them is markedly divergent and should be deprecated), and document it as only for use with document excerpts.
    Strongly opposed to any variant of proposal 2, which is just 'shopping to try to get a different result than what MOS:BQ says, and is not responsive to an RfC about how MOS:BQ should be implemented. Its premise is false as are Herostratus's rationales in support of it, as I'll lay out in the discussion section below. MoS implements a single standard for a reason (since 2006 if not earlier). The fact that we didn't actually get around to implementing it because of a technological hindrance to doing so (and 1A will fix that) has simply led to "monkey see, monkey do" additional uses of {{cquote}} and other decorative quote templates, because editors mostly do not read the style guide or the template docs, they copy-paste what they find in one article into another and fill it in with different content. It does not indicate a consensus against what MoS says, just an implementation drag. So remove that drag.  — SMcCandlish ☏ ¢ 😼  01:39, 2 January 2020 (UTC); revised 12:48, 2 January 2020 (UTC)[reply]

    To be clear: oppose 2*, and 1B; 1B in particular is ridiculous and was just inserted as a FUD move. 2* amount to "IAR means 'a rule I don't like doesn't apply to my articles, just because WP:IDONTLIKEIT.'" But we all know that's not what IAR means. This is not an RfC to change what MoS says – that would require a very strong new WP:CCC consensus against its current wording, which is obviously not going to happen. The RfC is just about fixing the problem that a template deployed a long time ago has caused a mess too difficult to clean up manually, but which is very easily rectified by simply changing the template output with a namespace switch, instead of manually changing the template call in thousands of instances.  — SMcCandlish ☏ ¢ 😼  01:50, 6 February 2020 (UTC)[reply]

  • 1A is my first choice, and 1C is my second choice. Also, I like User:Buidhe's idea of doing 1A now and 1C later (possibly much later). WhatamIdoing (talk) 06:11, 2 January 2020 (UTC)[reply]
  • Oppose all proposals here. This template resembles a pull quote, which as described in that article is a design element like an image rather than being part of the running text. We use images relevant to the article and section to break up the wall of text, and pull quotes should be acceptable in the same way when the section is about a specific quote rather than something that is represented in graphical manner. Uses of {{cquote}} may need review for cases where <blockquote> or {{rquote}} is more appropriate, but IMO neither a total ban (proposal 1) nor a blanket approval (proposal 2) is appropriate. Anomie⚔ 12:50, 2 January 2020 (UTC)[reply]
    @Anomie: That's really off-topic. Pull quotes (an unencyclopedic style found mostly in magazines) are no longer sanctioned for use in Wikipedia articles (per two RfCs or other such discussions several years ago; one to deprecate them, and one to stop even suggesting they could sometimes be used). Whether something "resembles" a pull quote is neither here nor there (except this: the fact that the purpose of a pull quote is to psychologically manipulate the reader into continuing to read, and with a particular idea or emotion in their head, means that pull quotes or anything masquerading as them are a WP:NPOV problem, by definition). Whether you think MOS:BQ should or shouldn't call for only <blockquote> (or its {{Quote}} wrapper) is also basically irrelevant to this thread; it does, and it has since at least 2006. This RfC isn't about changing the guideline, it's about how best to technologically implement it. If you want to change it, that's a very different kind of RfC.  — SMcCandlish ☏ ¢ 😼  16:09, 2 January 2020 (UTC)[reply]
    @SMcCandlish: Err, proposal 2 is explicitly about changing the guideline. I find the rest of your dismissal as similarly incorrect, but I'm not going to waste time arguing with you about it. Anomie⚔ 18:02, 2 January 2020 (UTC)[reply]
    "Proposal 2" was tacked on after the RfC opened, as an "anti-RfC", and has virtually no support. What you just wrote is a dismissal (i.e., an empty, handwaving refusal to engage); what I wrote is a point by point rebuttal of your OP, which is in no way dispelled by ignoring it. The point of it wasn't even to argue with you but to get you to reconsider what you've posted (whether you want to talk about it or not).  — SMcCandlish ☏ ¢ 😼  18:24, 2 January 2020 (UTC)[reply]
  • Support 1A. These big quote marks do not match other elements of our house style for articles. Sandstein 16:21, 2 January 2020 (UTC)[reply]
  • 1A now and actually not 1b or 1c. Just silently pass through the parameters. --Izno (talk) 16:42, 2 January 2020 (UTC)[reply]
    Just to clarify, just silently pass through the parameters until such time as a bot can replace the templates in mainspace, at which time I prefer the 1B approach (and not 1C still, as I would prefer not to render anything correctly whatsoever, so as to avoid tempting innocent or otherwise users into using the template anyway). --Izno (talk) 21:45, 2 January 2020 (UTC)[reply]
  • Support 1A There is no need for the large quotation marks as flourishes; they merely take up space and interfere with nearby images. Much simpler than forcing fixes in its uses. As punctuation quotation marks are needed to set off a quotation within running text, but when the quotation is already set off in an indented paragraph they are not mandatory. Reywas92Talk 21:21, 2 January 2020 (UTC)[reply]
  • Support 1A per existing consensus not to use {{cquote}} in article space. Strong oppose 1B and 1C which would cause a massive and immediate influx of confusion and complaints from editors, and also would be damaging to our readers' experience. If we did have an error message of some sorts—which I am opposed to—then I would strongly advise that it should mention that {{quote}} is the template to use in place, so that people who came across the error message would know how to fix it. Also, whilst we should be getting rid of pull quotes, lengthy quotes and other misuses of quotes where we see them, I oppose editors going through usages of {{cquote}} and changing them to {{quote}} en masse, as it would not be an improvement if 1A was adopted, it causes unnecessary disruption and it would do damage if consensus ever changed in favour of {{cquote}}'s current version. — Bilorv (talk) 18:56, 4 January 2020 (UTC)[reply]
  • Support 2A. I would amend the MOS to allow the use of {{cquote}} the way I prefer to use it, for quotations used epigraphically (see two sections in 2017 Los Angeles Measure S and this section of Disappearance of Tiffany Whitton for examples. But only that ... the quotes are a distraction when used with inline blockquotes. Also I totally second Herostratus. Daniel Case (talk) 23:32, 5 January 2020 (UTC)[reply]
  • Oppose 2A and 2B – Support 1A – best to continue to work toward phasing out the big decorative quote marks. Dicklyon (talk) 02:37, 6 January 2020 (UTC)[reply]
  • Support 1A and Oppose others There is already consensus to deprecate. 1B and 1C have a deficit for readers (as opposed to editors). I acknowledge the concern that 1A may cause confusion to some editors but believe that the deficit of the options (1B % 1C) outweighs this IMO but it does not mean that potential editor issues might be otherwise addressed. There probably needs to be something in big flashing letters at the documentation. A bot run (or two or three) to convert occurrences. An edit summary for the bot run that has big letters - preferable flashing. Later runs could even add hidden comments. Eventually the message will get through. Regards, Cinderella157 (talk) 07:19, 6 January 2020 (UTC)[reply]
  • Pleased to see this issue being addressed/revisited because, to my mind, the large quote marks add undue emphasis to the quoted content when in fact any sort of block quote treatment is based purely on word count. Support 1A, if it's the most committed measure, and Oppose others. Not wanting to distract from this point, but it's reminded me that there is still an option to include quote marks (that is, "Fat-quotes") at Template:Quote box, which would seem inconsistent with moves to phase out decorative quote marks, per Dicklyon above. JG66 (talk) 09:10, 6 January 2020 (UTC)[reply]
  • Support 2A or 2B as per User:Herostratus. The speech marks look better and make much more sense. Wikipedia should move with the times. (WP:5P5) TBH anything works as long as it's one or the other... >>BEANS X2t 17:01, 6 January 2020 (UTC)[reply]
    "Look better" is just WP:ILIKEIT; it's meaningless as an argument in an RfC. The rest of what you said doesn't track, either. If putting giant quotation marks around block quotations "ma[d]e much more sense" than block indentation, then why would all major English-language (and most non-English) style guides direct writers to use block indentation? Your argument is basically a form of WP:OR, or rather just outright defiance of all reliable sources on writing. And "WP should move with the times" doesn't make any sense; there is zero evidence of any kind – presented here or anywhere else anyone has cited – suggesting that there is a trend in publishing away from the block-indentation of block quotes and toward using giant quotation marks around them. What we do know, contrariwise, is that the style is common in magazines for pull quotes (which are not the same thing as block quotes, but are an attention-getting, i.e. a PoV-pushing, stratagem), and that the style is also used as the default markup for thread quotations in a few web-board software packages (WP:NOT#FORUM, and we don't care what forum software is doing, except maybe inasmuch as it may inform what the devs decided to do with talk page threading, and look what a dismal failure those efforts have been, with en.Wikipedia and many other WMF projects explicitly rejecting WMF's pet talk-threading projects as unworkable and basically "un-wiki").  — SMcCandlish ☏ ¢ 😼  15:22, 14 January 2020 (UTC)[reply]
  • Support proposal 2, with a slight preference for 2A. The distinction between block quotes and pull quotes is a completely pointless one, which hundreds of editors clearly don't follow. Why shouldn't anyone put quote marks around a direct quote? The MOS prohibition seems misguided to me. Let people use cquote if they want. Modest Genius talk 15:12, 13 January 2020 (UTC)[reply]
    For the same reason that virtually every style guide on earth says not to put quotation marks around block quotations. You're making a WP:IDONTKNOWIT pseudo-argument. Just because you're unfamiliar with English writing norms doesn't mean our guidelines should go against those norms.  — SMcCandlish ☏ ¢ 😼  15:22, 14 January 2020 (UTC)[reply]
    I notice you didn't actually provide a reason, just accused me of being "unfamiliar with English writing norms". I'm not. Modest Genius talk 16:58, 21 January 2020 (UTC)[reply]
    The admonition not to put quotes around block quotations refers to quotes in the text -- that is, of the same size, font, and color as the text. That is, don't do this:

    "Quote marks don't belong here"

    — Pinckney Pruddle
Which is really quite different what we're talking about here with {{cquote}}. Herostratus (talk) 06:19, 27 January 2020 (UTC)[reply]
  • Support 1A. These quotes completely unbalance an article. Much better to just convert them into something not quite so jarring. -- Necrothesp (talk) 15:16, 13 January 2020 (UTC)[reply]
  • Support 2 The symbols make it clear that these are quotes. Blocks of text are occasionally use for other purposes. Doc James (talk · contribs · email) 20:07, 20 January 2020 (UTC)[reply]
    Except not. Block quotations are done as indented blocks without quotation marks in almost all other publications. And quotation marks are used for far more (quotation-unrelated) purposes than indented blocks are (most often titles of minor works; and "scare-quoting" of things like nicknames; and many words-as-words cases, especially where italics are already being used for something else like foreign phrases; and various other things.)  — SMcCandlish ☏ ¢ 😼  06:27, 30 January 2020 (UTC)[reply]
  • Support 2 per Herostratus. An illustrative pullquote is no less encyclopedic than an illustrative image. (Heck, I've seen articles pass FAC with pullquotes in them.) Guidelines should follow practice, not the other way around. It seems that the issue here is not so much that consensus changed as that it never existed; in any event, consensus is best judged by the actual practice of the editing community, not by talkpage discussions that only a tiny fraction of editors will even be aware of. And as Herostratus has ably demonstrated, the current text of the guideline is (and seemingly always has been) out of step with the actual working consensus of working Wikipedians. Allowing a 14-year-old non-consensus to dictate current practice would be simply bizarre. (Also, 14 years ago we had a much less hidebound concept of guidelines, so having an ill-considered "rule" buried in the MOS wouldn't have struck most of us as a big deal if we had noticed it at all.) -- Visviva (talk) 07:07, 27 January 2020 (UTC)[reply]
    You don't seem to be following the discussion. This is not about "an illustrative pullquote", it's about using pull-quote stylization for things that are block quotes, not pull quotes. And "per Herostratus" at this late a date isn't a very meaningful comment if you do not address the refutations of Herostratus's arguments. And he did not demonstrate any such thing as "out of step with the actual working consensus"; his own numbers show an overwhelming majority implementation of {{Quote}} over {{Cquote}} (and he didn't even account for major decline in use of {{Cquote}}, i.e. increased compliance with using {{Quote}} over time).  — SMcCandlish ☏ ¢ 😼  06:27, 30 January 2020 (UTC)[reply]
    "Not agreeing with you" and "not following the discussion" are two separate things. Nobody's argument has been refuted; it's basically a question of personal preference, how important using just one format is to one, to what degree layout should be determined by individual editors and what degree by top-down fiat, and so forth (and the answer to that is "somewhere between 0% and 100%, with the exact number fluid depending on circumstances", so it's a question of arguing over where the line goes here). These aren't the kind of things that can be decisively proved one way or the other.
Sure, only 10% of block quotes use {{Cquote}} -- that's still some many thousands (don't have the exact figures right at hand), which isn't so bad considering that, after all, you (on your own dime) put in in admonitions in the MOS that it's flat-out not allowed to to be used....
"Decrease in use", if true, is surely partly because you and people of similar Procrustean mind go around deleting uses of {{Cquote}} to match your own aesthetic preference. Yes, doing that will cause usage to drop, but so? Herostratus (talk) 16:50, 1 February 2020 (UTC)[reply]
Ah, thank you for making it clear that this is just a "lash out at people who don't want to join me in waging war against our style guide" nonsense. If your message can't refrain from focusing on contributor instead of content, and trying to imply that people who actually bother to follow the style guidelines are somehow a problem, then there's no point in entertaining you further, per WP:DONTFEED. (Perhaps more the point, I would be real money that the vast majority of recent additions of cquote in mainspace are by you and by a few other editors with a long-term habit of trying to "lobby" against guideline material that doesn't suit your tastes. So, see also WP:KETTLE and WP:FAITACCOMPLI.) If you don't understand that use of your pet template dropping to 10%, and dropping further all the time, when it used to probably be around 35% or so, is a clear indication of a consensus against its use, then I'm not sure anyone's going to be able to get through to you.  — SMcCandlish ☏ ¢ 😼  23:13, 4 February 2020 (UTC)[reply]
  • Support 2B per Herostratus (and others). Second choice 2A. Oppose 1 which is unduly autocratic and against longstanding (de facto) consensus. Bring back Daz Sampson (talk) 13:34, 1 February 2020 (UTC)[reply]
  • Support Proposal 1 (any implementation). Pull quotations have been deprecated by RFC. Consequentially, all instances of {{Cquote}} are either pull quotes that we need to get rid off or block quotations using the wrong tempalte. I oppose Proposal 2 based on DESiegel's comment below: decorative quotation marks make a quotation leap off the page, giving it undue attention. Indentation helps readability, decorative quotation marks don't, and are just a distaction. – Finnusertop (talk ⋅ contribs) 23:30, 2 February 2020 (UTC)[reply]
  • Support Proposal 1. Changing the MOS because some editors won't follow consensus guidelines seems like the tail wagging the dog. --Tenebrae (talk) 23:19, 4 February 2020 (UTC)[reply]
  • Support 1A as first choice. I like the idea of eventually moving to 1C once we've removed all mainspace instances, but I would support it as a second choice and 1B as a third choice. I oppose both 2A and 2B; while I agree that someone did a nice job making that template, it's clearly undue weight for anything inside it, and therefore inappropriate for any mainspace page. CThomas3 (talk) 00:14, 5 February 2020 (UTC)[reply]
  • Support 1A and strongly oppose all versions of 2. As per Tenebrae, to do otherwise is just to changing the MOS because some editors won't follow consensus guidelines, and sets a bad precedent. Peter coxhead (talk) 09:57, 5 February 2020 (UTC)[reply]
  • Deprecate all pull quotes WP is not a newspaper, in the sense that we are an information site and not a work that needs to unnecessarily dramatise our content. Yes, quotation markes are needed as punctuation, but they do not need to be super-sized. Pull quotes exactly super-sizes the punctuation and are decorative. They serve to give subjective emphasis often to the detriment of purposeful and other useful information. They are often deliberately used to give undue emphasis or otherwise sensationalise selected content in much the way as soapboxing, and I do not consider such to be encyclopaedic purpose. As such, their use ought not to be allowed, let alone condoned. Just because many editors like them, and because these editors have inserted them into 17,000 articles is neither here nor there. -- Ohc ¡digame! 10:51, 5 February 2020 (UTC)[reply]
  • Support 1A. Oversized quote marks are inappropriate for an encyclopedia as they have the odour of the yellow press and blogsites. Would accept 1B or 1C as alternatives. · · · Peter Southwood (talk): 11:42, 5 February 2020 (UTC)[reply]
  • Depricate in main-space but do not change existing uses. This can be done by bot-replacing all uses of {{cquote|...}} with {{cquote|2020RfCexempt=yes<!-- Notice to editors: Consider replacing cquote with quote-->|...}} then changing the behavior of {{cquote}} to throw up a big ugly warning if it is used in mainspace (or draft: space for that matter) without |2020RfCexempt=yes. As for option 1B or 1C, I'm not picky. I would also be okay with replacing the prominent blue curley-quotes with more subtle ones when 2020RfCexempt is set to yes. davidwr/(talk)/(contribs) 16:10, 5 February 2020 (UTC)[reply]
    There's no such thing as date-based "grandfathering" exceptions from Wikipedia guidelines or policies. All our articles are in state of perpetual flux, even WP:FAs; they are not works we published once upon a time and keep in a fixed state. See WP:CONTENTAGE, WP:OLDARTICLE; this is a classic "argument to avoid" on Wikipedia. The last time someone tried to impose something like this (via a WP:SUPERVOTE while closing an RfC they actively said they didn't like the outcome of), it had no effect whatsoever; the community consistently applied the rule change across all articles, regardless of age, through a serious of RMs over the course of the following year or so. Anyway, this wouldn't work. The main reason we still have any new cases of {{cquote}} in mainspace (aside from a few usual suspects adding it out of "guidelines I don't like don't apply to my articles" defiance) is editors (who mostly don't read MoS except to look up something specific) just copying what they see in one article and pasting it into another then swapping in their content. If instances of that template remain in mainspace they'll continue to "spawn" new instances over time, inevitably. Analogy: imagine what would happen if we allowed personal attacks against biography subjects to remain in ~10% of our articles instead of doing our best to eliminate all of them. The solution is to remove it from mainspace, or prevent it doing anything unusual in mainspace; cure it or become immune to it.  — SMcCandlish ☏ ¢ 😼  16:45, 5 February 2020 (UTC)[reply]
    Actually, date-based grandfathering happens in Wikipedia - even this year's new WP:Partial blocks mechanism specifially allows editing restirctions to be enforced into partial blocks, provided that those editing restrictions did not exist as of 09:37, 11 January 2020 (UTC). If memory serves, there were some "grandfather clauses" in place with when the Draft: namespace became live and when Draft:-namespace related speedy deletion criterias went live. However, I will admit my memory is not 100% reliable. davidwr/(talk)/(contribs) 17:50, 5 February 2020 (UTC)[reply]
    Nah. User restrictions have nothing to do with whether a particular sliver of mainspace content is subject to the same policies as the rest of the content (which it is). Nor do CSD time-windows; those are about restraining administrative over-enthusiasm for deletionism; they don't pertain in any way at all to whether our content can be magically excempt from the WP:P&G that apply to all the rest of it. Same goes for things like time-limited WP:AC/DS things (1RR at a page for a month); that's also about restraining people and their behavior, not about applicability of content rules to content.  — SMcCandlish ☏ ¢ 😼  01:39, 6 February 2020 (UTC)[reply]
    @SMcCandlish: and others who may have missed the html comment above: I have no problem with human editors replacing {{cquote}} with {{quote}} on a page-by-page basis. In fact, I would recommend that cquotes be "looked at and considered for changing" on sight. However, I expect editors to ask themselves "is the change an improvement in this particular case?" I just don't want a mindless bot doing it because there will be occasional cases where it might be appropriate and a bot can't use judgement. davidwr/(talk)/(contribs) 18:01, 5 February 2020 (UTC)[reply]
    I understand the feeling, but the problem is we're all volunteers here. If it were practical to do all this manually – even with WP:AWB – it would have been done years ago already. I know from experience how tedious it is. Let's say, for the sake of argument, that in 1% of cases there's some mystically unique reason that {{cquote}} is being used reasonably at a particular article (and that's being very generous). The drain on editorial productivity to manually put those back after a bot run is 99 × less than than the human cost of manually getting rid of the rest of them. It's actually worse, because some kind of excuse to maybe use {{cquote}} at some article doesn't require that it be used; that is, the already-inflated 1% are all entirely optional. As I noted in my own !vote, we likely do need a variant template specifically for document excerpts (e.g. a sidebar of a passage from a historical document, serving the same purpose as an image but being marked-up text instead of a scan/photo). However, that wouldn't be based on {{cquote}} anyway, but on another variant, probably {{rquote}} (a large proportion of the surviving uses of that template in mainspace are in that vein already, so we should probably convert those that are not to {{quote}}, then rename rquote to something like {{document excerpt}} and rewrite its documentation).  — SMcCandlish ☏ ¢ 😼  01:39, 6 February 2020 (UTC)[reply]
  • Strongly oppose 1B. I don't have a strong opinion about whether the cquotes should remain or not but there is no justification for replacing a very large number of fully functioning template instances in mainspace with an error message on what is (in at least a large part) a matter of style and aesthetics. 1C does not have the same issues because it does not remove information from articles. Thryduulf (talk) 16:26, 5 February 2020 (UTC)[reply]
    Yeah, 1B would never fly and I argued strongly against including it; it's a red herring and FUD.  — SMcCandlish ☏ ¢ 😼  16:45, 5 February 2020 (UTC)[reply]
    Documentation for pull quotes mandates that these only be used to repeat content already in the article. That being the case, substituting the template with an error message ought not to result in any loss of information. -- Ohc ¡digame! 17:43, 5 February 2020 (UTC)[reply]
    Yeah, but then we deprecated pull quotes, period, via RfC quite some time ago, because it's an unencyclopedic style from magazine writing (the entire purpose of it is emotionally manipulating the reader). Someone already linked that RfC in this discussion somewhere.  — SMcCandlish ☏ ¢ 😼  01:39, 6 February 2020 (UTC)[reply]
  • Support 2A this is one of those needless conformity problems that crop up from time to time. There is no reason, and certainly no rational justification, to intentionally break thousands of pages just because usage doesn't match the MOS. The MOS is a best practices document, it is not policy. The premise that this RfC is founded upon is therefore invalid and the entire RfC based on a misconception. If there are specific worries about NPOV on specific articles, then those can be addresses on the article talk pages, where any other NPOV issue is discussed. That is a very poor reason to ban or break a popular template. Eggishorn (talk) (contrib) 16:50, 5 February 2020 (UTC)[reply]
    You don't seem to read the RfC options; only the silly 1B would break anything. That option was inserted despite the RfC drafting stage making it very clear it has no chance and would just serve as a scare tactic. It's disheartening to see that is actually having that effect.  — SMcCandlish ☏ ¢ 😼  01:39, 6 February 2020 (UTC)[reply]
    To be honest, I'm weary of having my character assasinated here, my motives misconstrued, and my competence deprecated. This's not how we are supposed to communicate here, so please stop. It actually doesn't put your arguments in a good light to go on like that anyway. Herostratus (talk) 02:35, 6 February 2020 (UTC)[reply]
    Hmm. But it was made clear this option had no chance; I was not the only one to say so clearly. I warned that it was basically a straw man/boogeyman that would confuse people and cloud the issue, and we now see that it is having that effect. That doesn't say anything about your character, motives, or competence, only about the presence of a pseudo-option that shouldn't be in there. Unfortunately one editor supported it, and several accepted it as an alternative to their main choice, so it's too late to strike it.  — SMcCandlish ☏ ¢ 😼  05:58, 12 February 2020 (UTC)[reply]
  • Support 1A Use standard and simple quotation format. Flourishes or decorative styling do not fit with overall Wikipedia standards. It's just noise. The only reason to have these is the kind of ornamentation proscribed by WP:DECOR and WP:IMAGERELEVANCE. Doing it with text doesn't make it less superfluous. Agree with SMcCandlish that this quickly gets into POV pushing territory and pull quotes. Choosing which quote to put in blockquotes already invites some engineering of what the reader's eyes are drawn to on the page, no need to invite even more of it. Also, we should let the browser format <blockquote> rather than make up a format. Just a side note, SMcClandish you are into WP:BLUDGEON territory as far as I have seen others called out for it. Your point is made... —DIYeditor (talk) 17:02, 6 February 2020 (UTC)[reply]
  • Half support 1A (!). Yes to killing cquote, whoever it was above who wrote The current Cquote is used normally to ovr-emphasise a cherry-picked quotation. got it in one. But I don't understand the implications of hacking template:rquote: how important to the page design to have a floating quote box? Would it be better to convert rquote to template:quote box? I don't know but there is a risk of collateral damage if is converted blindly to template:quote. --Red King (talk) 18:08, 6 February 2020 (UTC)[reply]
  • Support 1A as there is no need to make people unlearn a template they use. Gnomish editors can convert cquote to quote, and AWB can include it as a standard correct, but there should be no hurry to turn this to an error message. If the effect of cquote is needed for some reason (eg for this discussion, better subst it now). Graeme Bartlett (talk) 01:01, 7 February 2020 (UTC)[reply]
  • Support 1A or simply redirect. All the best: Rich Farmbrough (the apparently calm and reasonable) 12:44, 9 February 2020 (UTC).[reply]
  • Support 1A and go further and would wish to discourage in the first place the practice of pulling a sentence or two out of an article and highlighting it in superlarge text. Anyone who has worked on a newspaper knows how easy it is to change the meaning of a story with the headline, and the selection of the extract to be highlighted can easily be OR. Or often appears arbitrary and random, done just to put ANY OLD WORDS in larger font just to break up the page. I have also seen examples where highlighted quote is replicated in the article, and edited out one such just recently. Removing the superlarge quotation marks would be a small step toward my dream. MapReader (talk) 06:44, 12 February 2020 (UTC)[reply]
  • Support 1A or functionally similar redirect. Having - supporting and understanding - multiple options that are nearly identical in form and function with only trivial differences is not a good use of our limited volunteer time. ElKevbo (talk) 21:22, 13 February 2020 (UTC)[reply]
  • Unarchived after requesting closure at WP:ANRFC. Cunard (talk) 08:38, 9 March 2020 (UTC)[reply]

Threaded discussions

Threaded discussion re merits of the proposals

  • I should note the policy basis for these proposals. Any quote marked off as cquote or rquote does is inherently given significantly greater attention, and distracts from the article as a whole. In almost all cases, that will give such a quote Undue Weight, thereby violating WP:NPOV. In theory such a template could be used only in the few cases where a quote deserves very heavy weight. There are a few such cases. But that hasn't happened in the past, and I don't think it would happen in the future. So I think the tool of cquote must be removed from article space, not just to comply with the MOS, but to avoid NPOV violations. Editors who disagree with that view will no doubt not support any of the proposals I have made, and will prefer the current situation, or perhaps some different proposal. DES (talk)DESiegel Contribs 07:41, 29 December 2019 (UTC)[reply]
  • I Will will mention, for the record, that I strongly oppose both 2A and 2B, and would rather that the current situation be retained than that those be implemented. I note that there is no mention of the NPOV issue or how these proposals would, as it seems to me, only make that worse. DES (talk)DESiegel Contribs 14:54, 29 December 2019 (UTC)[reply]

So, something you hear is that {{Cquote}} ought be removed because it is used for POV purposes, to overemphasize some point. This is reasonable but not really a strong argument in my opinion, because:

  1. I haven't seen that. Probably happens, but I haven't seen evidence of {{Cquote}} used for toxic POV purposes with a greater frequency than plain block quoting.
  2. If it's a problem, it's mostly block quoting itself that's the problem. A {{Quote}}d quotation is (let's say) 3/4 as prominent as a {{Cquote}}d quotation. Most of the emphasis is is calling out the quote as a blockquote, the large quotation marks only add a bit of extra emphasis. And the 2016 RfC didn't show support for banning block quoting altogether.
  3. Anything can be used for POV purposes. The main source of POV is article text. Categorization is commonly used for spin... going around putting people in Category:Catholic American writers when they never went to church as an adult, to valorize Catholicism; you see this all the time, and rolled back all the time. For U.S. Grant, an editor has to choose between a picture of his birthplace (promotes Ohio) or where he lived (promotes Missouri). The solution is not to ban text or categories or images, but to fix specific problems when they arise.
  4. I mean, after all, emphasizing certain things is what we do. Right? I'm writing about Pinckney Pruddle, I choose to write a long section on his political career and a short section on his sporting career, emphasizing the latter and de-emphasizing the former because I think that's the best service to the reader. Is this wrong? If I blockquote Franklin Roosevelt's "We have nothing to fear..." quote rather than something else he said, is this wrong?

Herostratus (talk) 11:07, 30 December 2019 (UTC)[reply]

If you "haven't seen" PoV-pushing uses of it, then a) you are not looking, even a little bit, and b) you cannot be in a position to evaluate those uses. "I have never seen an elephant. But I bet it is just like a squid." No, it's not block-quoting itself that is the problem, it's using colorful, decorative gimcrackery to practically force the reader's eye to something an editor wants to unduly emphasize. The style was borrowed directly from magazine-style pull quotes, the sole purpose of which is to catch readers' attention and cajole them into reading more out of an emotional response to the unduly highlighted material.  — SMcCandlish ☏ ¢ 😼  07:56, 2 January 2020 (UTC)[reply]

On Herostatus's "Proposal 2": This RfC is about how to implement the extant wording of MOS:BQ (the "use <blockquote>...</blockquote> or a template wrapper for it" core meaning of which has not changed since 2006) through templates. The counter-proposal is a forum-shopping attempt to relitigate, to try to say that MOS:BQ is "the wrong version" – 14 years late. So it is not actually responsive to the RfC question, but is just a bunch of FUD. And its premise is just false. It's not the case that lots of editors prefer {{cquote}}, it's just that after consensus arose to use <blockquote>...</blockquote> / {{quote}} consistently and to discourage (later to just disallow) pull quotes, we failed to actually implement the removal of {{cquote}} from mainspace, which in turn led to "monkey see, monkey do" spread of it to new articles as editors copy-pasted the first quote template they encountered to another article and just changed the content inside it, without reading template documentation or MoS.

Other, hyperbolic claims by Herostratus in support of the idea are also bogus. "Quotation marks are the universal signal to English speakers that the material contained between them is a direct quotation" is just false on its face, twice over: Quotation marks are not used around block quotations in any major style guide. Ever. And quotation marks are used for a variety of other purposes that have nothing to do with quotations, such as titles of minor works, and "scare-quoting" dubious phrases. There is no "lot of editors" who prefer to use cquote; there's a tiny handful of editors who've ever spoken up with a preference for using it, and a larger number of editors who just willy-nilly reuse whatever templates they run across in other articles. Combined, they're still a small minority. All told, the total number of mainspace uses of {{quote}} dwarf by those of {{cquote}} (by about a 5:1 ratio and climbing), even before you factor in raw <blockquote> usage. Finally, it is not possible to "sneak" something into the most-watchlisted guideline on the entire system. Even a minor tweak to MoS is examined by multiple people. MOS:BQ is the result of multiple discussions over many years, not just one, and has been refined further since then with even more discussion (e.g., to remove grudging acceptance of pull quotes).

There's also the WP:Fallacy of the revelation of policy at work here. "So-and-so editor wrote this and added it" isn't a rationale against anything, since everything on WP was written and added by someone. MOS:BQ has stood the test of years – over a decade – and this is intrinsic evidence of its consensus, which need not be unanimous (see WP:IMPLICITCONSENSUS). Consensus can change but on this is hasn't, and it won't. Use of cquote in mainspace has declined, not risen. More than once, I've randomly picked about 100 articles and converted all their uses of cquote to quote (or to an inline quotation, when the template was wrongly used for a very short quote), with less than a 1% revert rate. What do you think Herostratus's revert rate would be if he changed 100 articles to use cquote instead of quote? Besides, MoS has said to use <blockquote> for block quotations since at least 2006.

And none of this is news; I'll quote Mzajac from December 2006: "It is chronically misused: the MOS calls for HTML <blockquote> elements. Proponents say this template [Cquote] is only for special call-out quotes [i.e. pull quotes], but that is just BS: everyone knows it has been placed for thousands of in-line long quotations. Novelty typographical treatments like this make the encyclopedia look like a bad joke. Replace it with template:Bquote [i.e. what today is Template:Quote], which is 100% compatible, and provides semantic, accessible output." What changed a few years ago was we realized that MOS:BQ said to just use <blockquote>...</blockquote> while {{Quote}} was directly equivalent but not mentioned, so we added it as an obviously acceptable replacement. Waaay back in 2007, and based on WT:MOS discussions, accessibility discussions, TfDs, and numerous other threads, I added to MoS that {{Cquote}} should not be used (since it is not equivalent to <blockquote>, and many concerns had even then been raised about its misuse in mainspace). In the intervening years, various people tried to editwar it back into MoS as permissible and did not get consensus for this. Along the way, we explicitly deprecated pull quotes, and then when they all seemed to be gone, removed mention of them about a year later (though we may need to put it back in; I've run into at least two pull quotes in recent editing). We also built MOS:ICONS, and over time it has evolved to discourage not just little pointless decorative images, but misusing Unicode, dingbat fonts, CSS tricks, emoji, etc., to achieve the same decorative effects without strictly using images – and that obviously includes (and was specifically intended to include) things like giant-quote-mark decoration. (I would know what the intent was, since I wrote much of that guideline material, as well.) Efforts by Herostratus to portray any of this as some kind of conspiratorial coup are simply nonsense. The only "bullshit" that "stinks to high heaven", to turn Herostratus's words back onto him, is his failure to see that MOS:BQ is the product of at least 14 years of consensus formation.

TfD has been deleting MoS-noncompliant quote templates for over a decade. See, e.g., WP:Templates for discussion/Log/2009 October 8#Template:", the deletion – on MOS:BQ grounds – of a template that did the same thing as what is now {{Quote}} but put quotation marks around it. The only reason {{Cquote}} survived TfD a few months before that was respondents' confusion about its legit uses in project and user namespaces versus its misuse in mainspace (back then, the idea of having a template do different output on a per-namespace basis was novel and would not have occurred to most editors.) See also WP:Templates for discussion/Log/2014 October 11 for a whole raft of deletions and mergers of quotation templates; note especially deletion of {{Quotation1}} because it used table markup instead of <blockquote> (i.e. because it was contradictory to MOS:BQ). Then see WP:Templates for deletion/Log/2006 August 25#Template:Selective quotation, deleted on the basis that it "causes harm to the appearance of articles that is much greater than any benefit it might provide .... with a very large and intrusive inline marker." That's exactly what {{Cquote}} does, except with four intrusive markers (two at start, two at end). Next, see WP:Templates for discussion/Log/2014 October 20, another entire page of quotation template deletions and mergers. At WP:Templates for discussion/Log/2014 November 29, {{bq}} was merged to {{Quote}}. (Though {{Quotation}} was not at that time, it was later, after some parameters were made compatible.) This is just a sampling of the relevant TfD discussions. In short, the entire and quite long history of these things on WP is continually toward fewer templates, with more consistent output, more compliance with MoS, and fewer dubious formatting options (many unencyclopedic output formats were dropped in the course of these mergers). And TfD has explicitly deferred to MoS as where we decide how block quotations will be formatted in Wikipedia articles [2].

Finally, there is no aesthetic problem with block quotation, or with a work mostly consisting of text. Our block quotation style is the same as that used by all major publishers, for centuries. And most books that are not written for children consist primarily of text, including other encyclopedias. Under no excuses should we violate WP:UNDUE to draw especial attention to some party's wording just to tweak the layout. WP:NOT#WEBHOST; you can use your own website to engage in whatever webpage design ideas strike your fancy. The last time someone tried to do that with quotation templates in mainspace, it was promptly nuked at WP:TFD [3].
 — SMcCandlish ☏ ¢ 😼  09:53, 2 January 2020 (UTC)[reply]

  • I find the comments by SMcCandlish above quite persuasive. Indeed they put the ideas i had in mind more clearly than i had fomulated them, no doubt based on that editor's long and extensive MOS work. I still do not find the arguments of Herostratus at all persuasive. The suggestion that most editors who have used {{cquote}} in mainspace have done so because they read the MOS and disagreed, or even looked throguh the available quotation templates and chose cquote as the best for that article is at best without supporting evidence. Many, perhaps most, editors work by seeing tools and techniques used in one or a few other articles, and imitating what seems to work. People assume that anythign sued in mainspace is approved and appropriate. This is often incorrect, which is why WP:OTHERSTUFFEXISTS is usually not a persuasive argument in AfD and similar discussions. This is, I think, what SMcCandlish means by "Monkey see, monkey do" editing. And there is nothing wrong with it, as a first approximation. But when another editor points out things that do not comply with the MOS, or better yet edits to bring an article into MOS compliance, the response should not usually be to revert, unless ther is a good argument why a particular article is an exception. Nor should one try to change the MOS just out of personal preference. I still have not seen any response that I consider persuasive to the argument that large quote marks lend themselves to cherry0picking and unduse weight to a particular quotation. DES (talk)DESiegel Contribs 16:23, 2 January 2020 (UTC)[reply]
    To clarify, virtually all of us learn WP by the same imitative process; I know I did. Finding and absorbing the P&G and /doc material is a very slow process, and also absorbing corrections and hints from other editors is a major part of the process. I was also virulently opposed to some of what MoS said when I first started editing (and I still disagree with about 50 things), but figured out after a while that its value is in its stability and its function of setting a/some/any rule where the absence of one leads to chaos and conflict; it's not what the specific rules are in most cases (except where there's a very strong reason to prefer one option over another, e.g. for MOS:ACCESS reasons). Anyway, we've seen the monkey-see-monkey-do effect in action, in sweeping and bad ways, before. The insistence of one wikiproject on capitalizing the common names of species of one type of organism led inevitably to a perception that capitalizing species vernacular names was "just the Wikipedia style", and imitative application of it to any/all other organism, until the attempt to capitalize "Mountain Lion" and a few other such things finally broke the camel's back and led to a lower-casing shift that took another 4+ years to resolve and clean up in the mainspace, after intense levels of constant conflict about it (pretty much the worst WP:DRAMA I've ever seen). Similarly, the ability in the 2000s to have dates auto-format (for logged-in users) to match their preferred date order, if the date was linked and it was a complete date, led to people wikilinking every single date they came across, complete or not, until the community couldn't stand it anymore and had this functionality repealed; that also took years of drama and drudgery to resolve (and was the proximal cause of MoS being put under WP:AC/DS). People just obsessively lose their shit over MOS/AT matters, too intensely and too often.  — SMcCandlish ☏ ¢ 😼  17:22, 2 January 2020 (UTC)[reply]
  • I want to call attention to the discussion at Talk:Factorial#quote vs cquote. In this edit on Factorial, I changed an instance of quote to cquote. Herostratus reverted that change, and a talk page discussion was stated. Another editor reinstated my change after some discussion, and Herostratus reverted again. After further discussion, during which there was pretty clear consensus for my change (as I read the discussion, but check it out), yet another editor reinstated the change, which has remained stable since then. At the same time that I made the edit to Factorial I made similar changes to 9 other articles, and to another group of ten a couple of days later. All were chosen from the first page of the what-links-here list of {{cquote}} (after limiting to mainspace trasclusions). I believe that Herostratus reverted two other articles, and that no one else objected or reverted any of the changes. A micro-sample of what working editors feel is worth reverting, as one data point in judging current consensus on the issue. DES (talk)DESiegel Contribs 16:37, 2 January 2020 (UTC)[reply]
    That should have read "I changed an instance of cquote to quote", as the linked edit plainly shows. My editing error here. DES (talk)DESiegel Contribs 17:45, 2 January 2020 (UTC)[reply]
    Yeah, my I-got-reverted rate of under 1% when converting Cquote to Quote wouldn't've been possible if {{Cquote}} were an actual preference of many editors, nor if my edit-summary citations to MOS:BQ as my rationale were citations of a bogus guideline that consensus didn't really accept.  — SMcCandlish ☏ ¢ 😼  17:22, 2 January 2020 (UTC)[reply]
  • In the survey, Daniel Case writes of using quoted "epigraphically" and that the current cquote behavior is appropriate for such use. But it is my view that this kind of use, where a quote stands at the head of a section and serves as a sort of theme for the section, is itself thoroughly unencyclopedic. Such an epigraph often stands at the head of a chapter or multi-chapter section in a novel, and sometimes in a work of non-fiction. Such a quote may also stand at the start of an essay. But there it is expressing the opinion that the quote usefully summarizes or sets the tone for the longer work that follows. In a Wikipedia article, such an epigraphic use of a quote nessicarily conveys to the reader a similar opinion in Wikipedia's voice, and so is inappropriate however it is formatted. It is a particularly egregious case of undue weight, and only shows how apt cquote is in tempting editors into such violations. DES (talk)DESiegel Contribs 14:23, 10 January 2020 (UTC)[reply]
I was away for the weekend and missed getting notified re this. I think, DES, that you have a rather limited view of how epigraphs are, or can be, used. While I'll allow that some editors would doubtless use them to express opinions or steer the reader to a preferred conclusion, that problem is scarcely unique to the epigraphic use of this template, and when it occurs we have many, many, policies and tools to deal with that.

I see an epigraphic quote as simply putting a section's focus out front, be it the lack of centrality hitherto experienced in Los Angeles or the fateful way Ms. Whitton was living, to refer to my two examples. Daniel Case (talk) 01:02, 13 January 2020 (UTC)[reply]

Threaded discussion re techical aspects of implementation, and meta-discussion of the RfC itself

The examples for proposal 3 are now working. DES (talk)DESiegel Contribs 00:52, 29 December 2019 (UTC)[reply]
The original proposal 3 has been renumbered to 1C, but I object to the editing of my existing commetns, and have reverted the changes to them. I will not further edit the comments of others, as per WP:TPO. DES (talk)DESiegel Contribs 17:25, 29 December 2019 (UTC)[reply]
@Deacon Vorbis: DES (talk)DESiegel Contribs 00:53, 29 December 2019 (UTC)[reply]
Pinging User:Bsherr, User:Galobtter, User:DESiegel: In all instances (including your comments under your signatures, I edited the text to match the changed numbering system. This, "1" became "1A", "2" became "1B", and "3" became "1C". Begging your pardon, and done only in the interests of clarity.
Given permission to add proposals, I judged that 1,2,3,4,5 numbering system was inferior to a 1,2 system with 1A, 1B, and 1C and 2A and 2B as subsidiary values. It's hard enough getting a decision in a binary question, and impossible on a 5-proposal one. 5-proposal ones are fine for RfC in the manner of "What are people's thoughts on this, so we can move forward with further discussion". But we had one of those in 2016 and actually many such discussions over the last decade-plus. It's time to put paid to this ten-year running sore and a binary question's the way to do it.
A 1,2,3,4,5 system is only going to end up with roughly 10-30% of "votes" given to each proposal. People voting for 1, 2, and 3 are going to be counted differently. With this system, votes for 1A, 1B, and 1C can all be ascribed to "1", and Bob's your uncle; which specific technique (A, B, or C) to use can be then adjudicated on plurality, or strength of argument, or something.
I'm prepared to "lose". That's the Wikipedia way. We all win when the feeling of the community is engaged with a good quorum and the result is an actual decision backed by community consensus. I can't even care that much anymore on the merits; I'm worn down; but I'm still standing because I refuse to be bullied and see my colleagues bullied and harassed and worn down based on bullshit like this. But either way, let's just end this twelve-year nightmare. Herostratus (talk) 15:59, 29 December 2019 (UTC)[reply]
Of course I am happy to oblige the edit to my comment. I am a bit disappointed that we are combining the policy and implementation questions, however. I am inclined to agree with "2B" on the policy question, but if the result is no change to policy, I prefer "1C". But I'm not confident an all-in-one RfC will account for such nuances. --Bsherr (talk) 19:50, 29 December 2019 (UTC)[reply]
Indeed, the more I think about this, the more I want to ask that the RfC as written be aborted in favor of deciding the policy question ("1" or "2") first. Is there any objection to that? --Bsherr (talk) 19:54, 29 December 2019 (UTC)[reply]
Me too. So far this is shaping up to be like what the she for ships discussion might have been if English had seven genders to choose from. EEng 21:57, 29 December 2019 (UTC)[reply]
Right... well, the RfC was published, and there were some issues, so we fixed it quick while in flight. It's better now; 1A,B,C are all just "1" and same for 2A,B. It's not like seven genders, it's more like "Vote for She or It for ships, period. If you vote for She, you may optionally also specify whether amphibious vehicles should be She or Xe, whether ships that are called boats (e.g. submarines) should be She or Ze, and whether former ships that have transitioned to a sunken state should be She or Ve." Anyway, it's here now, it's better than it was, and it's live and it's WP:CENT, so... I dunno. Anyway, only User:DESiegel could do this. Herostratus (talk) 02:07, 30 December 2019 (UTC)[reply]
And I would object to Bsherr and EEng's idea, even if this were not already CENTed. It would be an illegitimate bait-and-switch to train-wreck a simple and straightforward RfC (about how to implement a guideline in some particular detail), by sticking in a "down with the guideline" noise proposal and screwing around with the proposal numbering multiple times, and yadda yadda, then try to claim that the guideline itself was somehow in question just because the RfC was derailed. Fourteen years of guideline stability isn't erased with a quick WP:GAMING stroke, sorry.  — SMcCandlish ☏ ¢ 😼  18:44, 2 January 2020 (UTC)[reply]

Meta-notice: Since discussion has turned increasingly to WP:UNDUE questions, I've notified both WT:NPOV, and WP:NPOVN of this discussion. And since it has been dragging on without a clear consensus for some time, and could affect a large number of articles, I've also notified WP:VPPOL.  — SMcCandlish ☏ ¢ 😼  23:56, 4 February 2020 (UTC)[reply]

Template mechanics

(edit conflict) Sorry in advance for all the dumb questions, but template code tends to be a bit unreadable for me if I didn't write it myself . Looking at the test cases for #1, they seem to use the most basic parameters of {{cquote}}. If there are so many uses out in the wild, do any of them use the weirder formatting parameters that aren't supported by {{quote}}? What's the intended behavior for these? (Just saw the pointer to discussion in the edit conflict, will go see if any of that discussion answers my questions). –Deacon Vorbis (carbon • videos) 01:00, 29 December 2019 (UTC)[reply]

  • My intent was to use and allow for all the parameter supported by {{cquote}} which have rough equivalents in {{quote }}. Thje parameter specifically intended for formatting the large quote marks, or positioning the quote in non-standard ways, such as bgcolor, float, width, quotealign, wide, and qcolor are intentionally ignored and will have no effect in mainspace. In userspace (indeed everywhere but mainspace) they will continue to function e3xactly as before DES (talk)DESiegel Contribs 01:08, 29 December 2019 (UTC)[reply]
  • Deacon Vorbis There are far too many existing article-space invocations of cquote to determine what parameters have been used in them. DES (talk)DESiegel Contribs 01:11, 29 December 2019 (UTC)[reply]
    Re There are far too many existing article-space invocations of cquote..., please see the Template Data monthly report, which tells you exactly how many articles use each parameter, including unsupported parameters, as of the most recent monthly analysis. – Jonesey95 (talk) 01:30, 29 December 2019 (UTC)[reply]
    Thank you, Jonesey95 I didn't know about that. Based on that there seem to be no more than about 100 uses of any of the parameters I am ignoring in the modified version, a volume which would would be easy enough to modify individually one way or another. DES (talk)DESiegel Contribs 01:46, 29 December 2019 (UTC)[reply]
  • Some above are suggesting that a bot be created to directly convert cquote calls into quote calls, aftt an initial change in the template. That could be done. But because of the difference in parameters, i think the logic would be a bit more complex than some might assume, making that more trouble and perhaps take longer. But it could surely be done. DES (talk)DESiegel Contribs 07:45, 29 December 2019 (UTC)[reply]
    Especially if some of us pre-normalize some oddities manually. Since I already have an occasional habit of clearing out 100+ cquotes at a time, I'll sign up for some of it. Doing it manually helps find other problems, too, like the quote templates used for non-quotations, mixed styles in the same article, genuine pull quotes, tiny quotations that belong inline being done as block quotes, copyright-violating piles of excessive quotation, off-topic quotes, encyclopedically inappropriate quotes, citations put into the quoted material instead of in the lead-in sentence to the quote or in the sourcing parameters, etc., etc. It's just really tedious to repair it all by hand.  — SMcCandlish ☏ ¢ 😼  16:53, 5 February 2020 (UTC)[reply]

I don't really see the complexity. It's hardly unusual for an organization's current membership to differ from its original one. Anyway, take a look away Member states of the Commonwealth of Nations. Countries pop in and out of that one all the time. Largoplazo (talk) 22:11, 5 February 2020 (UTC)[reply]

CURLY and ELLIPSIS

Nine months ago an editor suggested to discuss MOS:CURLY here, and I forgot to do this. Summary of technical issues:

  • Should titles within references really still be modified in 2019, ignoring the original title?
  • Is a rationale to avoid ordinary Unicode for some IE oddity in 2016 still relevant?
  • Was there ever a good reason to replace <q>…</q> in favour of US-ASCII approximations?

As US-ASCII fan supporting an older guideline for technical articles I'm curious what folks think about it as of 2020, Unicode is no "black magic" anymore. –84.46.52.252 (talk) 13:04, 11 February 2020 (UTC)[reply]

Are you saying there are cases where the original title of a reference is ignored? Hard to imagine. Dicklyon (talk) 04:04, 12 February 2020 (UTC)[reply]
Bad DEnglish on my side, original curly char.s within references are replaced by US-ASCII, i.e., left and right quotation marks:
single ‘(&lsquo;+&rsquo;)’ and double “(&ldquo;+&rdquo;)” (background). –84.46.52.187 (talk) 18:36, 12 February 2020 (UTC)[reply]
Right; quote marks are rendered in WP style. So your questions were misleading. Maybe you can rephrase if you want to make a case for changing WP style. Similarly for MOS:ELLIPSIS, which you imply never had any good reason; I don't know, I wasn't there. Dicklyon (talk) 03:59, 13 February 2020 (UTC)[reply]
Only curly × quotations, for the 3rd bullet, e.g., A said, quoting B, <q>Can I quote you saying <q>foobar</q>?</q> rendered in green as
A said, quoting B, Can I quote you saying foobar?
Ecample for the 1st bullet, an original title=Our take on ‘foobar’-gate is not the same as title=Our take on 'foobar'-gate, who still needs the latter for what? –84.46.52.187 (talk) 06:39, 13 February 2020 (UTC)[reply]
I wish I could understand your point. Dicklyon (talk) 07:24, 13 February 2020 (UTC)[reply]
Taking those points in order: Yes, follow MOS:CURLY as long as MOS:CURLY is still there, because "the original title" (or quoted material with it's own internal quotation) using curly quotes is simply irrelevant. We regularly normalize (per MOS:CONFORM, MOS:TITLES) to WP style for quotation marks, case normalization, even italics around major works embedded in titles of quote-marked minor works, etc., in titles (both in running prose and in citations), and in block quotations, when doing so doesn't change their meaning but does make them more consistent, easier to parse, or better from some technical standpoint. On the "Why MOS:CURLY at all today?" question, I raise this myself about every 5 years or so to see whether there is still consensus that we need to advise against curly quotes. There were actually multiple reasons for it, but "that old browser" seemed to be the main one. I don't advocate either way on it, but we should still periodically ask the question, yet err on the safe side. On the &hellip; question: Yes, replace it, because "…" is awful. It's damned near unreadable at all in many fonts, and for many of us with poor eyesight even when wearing glasses, it's almost unreadable in any font. The idea that an ellipsis "is" a single precomposed character and "is not" three periods (full points) in a row is a modern fiction of Unicode nerds, based loosely on the expediency practice of some old-school typesetters who did in fact use single-block pieces of movable type for it, but were usually not going so far as to say that anything else was wrong. But beyond this, it is and always has been three regular dots. (I'm not sure how frequently people using [La]TeX also replace the three dots with a single char., but I doubt it's anything like a majority (despite huge overlap between that crowd and Unicode nerds; the ones who are not are mostly academics with way more important stuff to do that futz around with near-invisible typographic tweaking). Still, we mustn't go to the opposite extreme; the spaced . . . style is actually fairly commonly attested in off-site publishing, but is grotesque and pointless. PS: I have no idea why you're calling ... "US-ASCII". The same character is found on most keyboards, and is also part of Unicode. If you're trying to imply it's an Americanism, it's not.  — SMcCandlish ☏ ¢ 😼  21:26, 13 February 2020 (UTC)[reply]
That's actually something of a reverse RAS syndrome; ASCII when expanded is American Standard Code for Information Interchange (italics mine). But it is probably someone trying to downcast Americans as if we weren't the superior nationality. ;) And apparently the IANA prefers referring to the encoding as US-ASCII per ASCII. --Izno (talk) 21:45, 13 February 2020 (UTC)[reply]
IANA is the servant of the IETF, RFC 20 exists, and UTF-8 is the only relevant extension of US-ASCII. Speaking as a non-US Windows-user and "inventor" of UTF-4,[4] or in other words, Latin-1 is out (no Euro), and windows-1252 is "proprietary" (simplified, not really). –84.46.52.151 (talk) 06:06, 20 February 2020 (UTC)[reply]
Good to find someone who at least understands the problem, it's 2020, and even NetScape 2.02 in 2002 could do &hellip;, but not hex. &#x…, only decimal &#… or named entities. And I'm only interested in CURLY here—now answered as dunno, let's wait for 2025—and <q>-elements (aka tags), replacing the latter by US-ASCII should be vandalism. Ellipsis aren't relevant, I don't recall a case where I used that in the article namespace, and if there's only a guideline against it, IAR is a policy, –84.46.52.151 (talk) 06:06, 20 February 2020 (UTC)[reply]

A big reason to exclude curly quotes is the difficulty of typing them on a normal keyboard. If anything, the increasing use of mobile phones and smaller laptops with fewer keys, typing has gotten harder, not easier. So curly quotes should still be excluded. Jc3s5h (talk) 15:41, 20 February 2020 (UTC)[reply]

^.^b, &ldquo; etc. is clumsy, but not worse than n+m dash, no-break hyphen, no-break space, &#x2009; thin sp, or middot. –84.46.52.151 (talk) 18:04, 20 February 2020 (UTC)[reply]

Capitalization of "Vol." and "No."

I raised this before, several years ago, and we did not come to a consensus conclusion about it. It appears to me that "mandatory" capitalization of these is no longer the norm in English usage, if it ever was. "No." tends to be capitalized more, because this looks like the usual rendering of the precomposed numero symbol, №. However, it is not that symbol. It is simply an abbreviation, and we do not capitalize other abbreviated latinisms like "e.g." and fl., even when also derived in English by mimicry of symbols (as was viz.). There are some mostly academic exceptions for aconyms (such as QED, and academic degrees), but this isn't an acronym. "Vol." is capitalized when used in a proper name, usually the subtitle of a book or other work. Both are typically (probably not always) capitalized in codified citation styles. Aside from such cases, it seems unreasonable to tell our editors to always write them "Vol." and "No." in running text, and seems to contradict MOS:CAPS (don't use capitals unless reliable sources are near-totally consistent in doing so for that particular case). And editors generally don't do it, especially in contexts like sport and music chart rankings, which probably account for most uses of "[n|N]o." outside of citations.

I thus suggest that we change the advice (about not using "#") to say to use number and plural numbers, or the abbreviations no. and nos., which may be capitalized in citation styles that require them in upper case. Similarly, change the further-down sentence about using "Vol." and "No." when referring to works, to now show these abbreviations in lower case, and also note that they can be upper-cased in citation styles that demand it. Actually, this can be a footnote which is referenced twice, instead of repeated twice in MoS's main wording flow.  — SMcCandlish ☏ ¢ 😼  20:53, 13 February 2020 (UTC)[reply]

That makes sense. Unnecessary caps are just distracting, and many sources and styles have gone to lowercase on these. Dicklyon (talk) 04:36, 15 February 2020 (UTC)[reply]
  • I'd welcome that sort of a change – no. and vol. rather than the capitalised versions. I pretty much only work on music articles, and the over-cap aspect of, say, album title, country/ies, chart compiler(s) and instances of "No." all appearing in a single sentence, or even multiple sentences, is every bit as bad as the overlinkng aspect (MOS:SEAOFBLUE) that we try to avoid. I know you're only referring to running text, but I can't understand the need to make a distinction: citations use "ed." and "p.", so why not "vol." and "no." there too. (Rhetorical question, that; thinking aloud.) JG66 (talk) 15:10, 19 February 2020 (UTC)[reply]

Series

A series in British English is any sequence of episodic television where the episodes are scheduled at regular intervals. This can be proven by looking in literally any dictionary. It is unnecessary to define the term at this page. It is a term that every English speaker understands to mean a television show that appears episodically. This page states that "series" means the entire show in North America but not in England. That is untrue. In England the word may have a broader meaning for both the entire show and each season, but the way this page presents the word is incorrect. DrKay (talk) 10:41, 15 February 2020 (UTC)[reply]

Amend the "Titles" section to: "Use italics for the titles of works (such as books, films, television series (but not seasons), named exhibitions, computer games, music albums, and paintings). The titles of articles, chapters, songs, episodes, seasons or multi-episode storylines within series, research papers and other short works instead take double quotation marks."

Replace the footnote in the "names and titles" section with: For television series, use italics for the main title of the show as a whole and quotation marks for the titles of seasons, multi-episode storylines and episodes: "Miracle Day" comprises the entire fourth series (season) of Torchwood. When a season name is used as a subtitle attached to the main title of the show (as is common on stand-alone DVD releases), use italics for the entire string: Torchwood: Miracle Day was released on DVD in November 2011. DrKay (talk) 11:00, 15 February 2020 (UTC)[reply]

The OED, which you referenced in an edit summary, muddles this, but it does come out confirming that "series" is ambiguous in British English, and that it, not "season", is the term used.
  • First, under the entry for series, we encounter both uses in one example: "1924 / Art News 24 May 6/1 / There is to be given by the agency of the radio broadcasting stations a series of art lectures... In this first series it is proposed to discuss the great works..of the various countries and periods."
  • Second, under the entry for season, we find, surprisingly, no mention of the use of that term in relation to television under the main definition, which by itself would contraindicate its use for that purpose in British English. But it does appears as a 2007 draft addition: "Broadcasting (chiefly North American). A single series of a television or radio programme." [italics in the original]
It appears that "series" is not only a British term for what North Americans call a "season", but the term. So the ambiguity of the term, along with the non-use by British English speakers of "season" in its place, isn't a pedantic detail unworthy of clarification on this page. Largoplazo (talk) 11:37, 15 February 2020 (UTC)[reply]
I realize that British people are stupid, but I can assure you they do understand the meaning of the word "season" in relation to television: iNews says "The Split season 2 ", Metro says "The Greatest Dancer" season 2 ... Sex Education: Season 2 ... The Umbrella Academy: Season 2, etc.", The Express says "Doctor Who season 12", The Sun says "Victoria season 4", Vogue UK says "The Handmaid's Tale season 3 ... Killing Eve is back for its second season ...etc. Claiming they don't use the term is inane. DrKay (talk) 12:16, 15 February 2020 (UTC)[reply]
That doesn't alter the fact that when the word "series" is used, it's ambiguous for speakers of British English. Since the text at hand is discussing both things that the term refers to, it's necessary to be clear about which of those things we're using it to refer to, to keep the distinction clear. Largoplazo (talk) 12:39, 15 February 2020 (UTC)[reply]
My amendments do that. The amended version is clearer for a British English speaker because the current version makes an assumption about British English that's incorrect. DrKay (talk) 12:47, 15 February 2020 (UTC)[reply]
No, they don’t. As above, whilst many speakers of British English today understand use of the American word “season” in relation to successive batches of television programmes screened in succession followed by a break, British English usage is still to refer to such as “series”, with the overall programme being a “serial”. The word “season” is definitely minority usage here. Thus, for example, if you check the BBC website regarding one of its recent widely acclaimed serials “Line of Duty”, you will find that is billed as “Series One”, “Series Two”... etc., which is the way this programme would be referred to in casual conversation amongst British English speakers. This is distinctly different usage to American English and your edits to remove the distinction from the MoS are therefore not reasonable. MapReader (talk) 12:55, 15 February 2020 (UTC)[reply]
Utter rot. I'm British and that distinction is absolutely and totally wrong. DrKay (talk) 13:01, 15 February 2020 (UTC)[reply]
Did you trouble yourself with checking the BBC website, or any other RS, before posting here, or are we simply being subjected to a stream of OR? MapReader (talk) 13:34, 15 February 2020 (UTC)[reply]
Did you trouble yourself to look at the 5 sources I listed above, the OED which I mentioned in an edit summary, or any dictionary as I stated in the opening comment, or am I simply being subjected to a stream of abuse? DrKay (talk) 13:55, 15 February 2020 (UTC)[reply]
In Britain, designations like "Series One" and "Series Two" can be found and there is no distinction between this and U.S. usage? So you are implying that "Series One" and "Series Two" are U.S. usage. Well, I'm from the U.S., and I can tell you unequivocally that that is not U.S. usage. Not even as an alternative to calling the "Season 1" and "Season 2". So your assertion that the distinction "is absolutely and totally wrong" is absolutely and totally wrong. Largoplazo (talk) 17:47, 15 February 2020 (UTC)[reply]
Stop lying about me please. Putting words in my mouth that were never there isn't going to work when people can see what I wrote for themselves. DrKay (talk) 19:06, 15 February 2020 (UTC)[reply]
Come on now, I believe you are an admin so you can do better than this; you should be trying to wind down any personal aspect to this discussion, not ramping it up. You made a series (lol) of bold edits to the MoS, which is fair enough, but once you are reverted the onus is on you to put forward a specific proposed change and to seek other editors’ opinions. Although I do see that you concede a broader UK use of the word ‘series’ in your original post, my personal view is that the difference between British and US usage goes wider than that, with ‘series’ used in British where ‘season’ would be used in American, and often also ‘serial’ for ‘series’. If you look at MoS:TV you’ll see that it is written along these lines, at least as far as season/series is concerned. If you wish to change the WP stance on this, you’ll need to support your case with solid citations as per usage (not simply drawn from a dictionary) and make sure that any proposed change doesn’t introduce a conflict between the MoS and MOSTV (or of course changes both in parallel. Indeed MOSTV:talk might be the best place to take your proposal in the first instance) MapReader (talk) 19:26, 15 February 2020 (UTC)[reply]
You are a liar. I've already done all that. I've provided sources. I've suggested two options/compromises. You've provided no sources and offered no compromises, but OK, here's some more: Radio Times says "Lucifer season 4", The Guardian says "fourth season of Killing Eve", British Telecom says "Castle Rock season 2 ... The second season of ... Don’t miss new seasons of", The Telegraph says "Game of Thrones season 8". You can't get more quintessentially British sources. The claim that British people don't understand the meaning of "season" is easily proven to be false. DrKay (talk) 19:30, 15 February 2020 (UTC)[reply]
I have to say that your readiness to resort to personal abuse is unbecoming, particularly if you are indeed an admin. I don’t recall saying that there aren’t instances of American usage seeping into Britain (especially in relation to an actual US series like Lucifer); this kind of thing happens all the time, in both directions. I suggest that there remains nevertheless a significant difference in core terminology between the two Engvars. Anyhow, my suggestion would be that you have a think about what specific changes you intend to propose to the MoS and/or MOSTV, and start a new discussion, once you have settled on a single proposal, with reasons/evidence. If you post it here I suggest alerting editors in the TV wikiproject as to the proposal also. MapReader (talk) 19:41, 15 February 2020 (UTC)[reply]
I've already suggested specific changes twice. Your apparent incapacity to see that is obviously either stupidity or deliberate duplicity. I suspect it is the latter because no-one could be that stupid. DrKay (talk) 19:50, 15 February 2020 (UTC)[reply]

At the very least the footnote needs to be shortened to: "Series title italicized" is using series to mean the entire show as a whole. If a season or any other multi-episode storyline has its own title, it is a sub-work that uses quotation marks for its title: "Miracle Day" comprises the entire fourth series (season) of Torchwood. However, when a season name is used as a subtitle attached to the main title of the show (as is common on stand-alone DVD releases), use italics for the entire string: Torchwood: Miracle Day was released on DVD in November 2011. Otherwise, it's confusing. DrKay (talk) 12:58, 15 February 2020 (UTC)[reply]

It appears we simply need to make a distinction between the full collection of episodes, which are apparently referred to as series in US English and serial in UK English, and anything less than that (season [US]/series [UK], story arc, individual episode) with its own title. Only full collections use italics; anything less uses quotation marks. We don’t need to redefine the terms here, just succinctly state this in an unambiguous way. It's unfortunate there isn't a single unambiguous term for the full collection of episodes, but perhaps we can more fully explain the difference in a footnote if we need to. CThomas3 (talk) 19:48, 15 February 2020 (UTC)[reply]

What about "program(me)"? Or is that also ambiguous in its scope? "Show"? Just spitballing here. oknazevad (talk) 20:06, 15 February 2020 (UTC)[reply]
Thank you, oknazevad, for the suggestion. I was thinking that might work also, but we may run into problems with single-broadcast TV program(me)s that are not part of series/serials, in that these aren’t italicized either. But perhaps we just need something like "multi-episodic program(me)". CThomas3 (talk) 06:06, 16 February 2020 (UTC)[reply]
You do realise that the current page defines a serial as "a season ... or any other multi-episode storyline ... a sub-work". And yet, we have MapReader insisting that this definition remains in, while at the same time claiming (without evidence) that a serial is all episodes from all seasons of a programme. It's an obvious discrepancy that my suggested text avoids. I would also point out that this definition of serial has been in the guideline for less than 24 hours, having only been introduced 15 hours ago (and removed by me 2 hours later and then reintroduced 25 minutes after that). DrKay (talk) 21:15, 15 February 2020 (UTC)[reply]
Greetings DrKay. I do see that the current footnote is problematic, which is why I am suggesting we return to addressing the point the MOS is trying to make, and that is what to italicize and what to put in quotations rather than arguing over the definition of series and serial. If we can agree on some other term or concise phrase that means “the full collection of episodes in a program”, then we can avoid any ambiguity in series/serial entirely, as anything less than the full complement of episodes (with apparently an exception for a subtitle) is quoted rather than italicized. CThomas3 (talk) 06:21, 16 February 2020 (UTC)[reply]
A couple of quick points: serial could accurately be used to describe the whole programme (either British or American) in certain cases (i.e. if its narrative is ongoing throughout), but is rarely used as such - certainly not the British equivalent of the American 'series'. British usage is to use series for both one broadcast run and the entire programme - and by usage I mean in shows that are British produced; UK media is perfectly used to describing American production seasons as such, as some of the sources above show. A prominent exception is the 'classic' era of Doctor Who, whose high episode counts and the fact that each broadcast run was made up of distinct serials (multi-episode stories) lead to it using the 'season' terminology, borne out by production documents and innumerable sources. If distinction between series (single run of episodes) and series (entire life of a programme) is necessary, alternative terminology such as "production", "programme" can mitigate ambiguity. The guidelines need to have certain flexibilities for particular cases - there's no one-size-fits-all terminology. U-Mos (talk) 20:36, 16 February 2020 (UTC)[reply]
I think DrKay's objection and observations are actually correct, in a WP:TRUTH] sense, but the problem is we have a non-trivial number of non-American editors who are downright insistent that "season" is [North] American and "series" is British/Commonwealth [except Canada] and that they are directly synonymous but from conflicting dialects, with an implication of no flexibility on the matter. They want to use "series", "show", or "program" in North American English and "programme" or "show" in British/Commonwealth English (I think some Australians prefer "program" now). There have been way too many arguments about these, even if it's largely based on opinion/preference and insufficient data (i.e., is a mixture of PoV and OR). I'm not really sure how to get past that, other that by either going along with this harmless quasi-fiction/half-truth, or burying it completely and saying to use one set of terminology (it's easy to prove that "season" is universally understood in this sense, since at least the early 2000s, so it would actually comport with WP:COMMONALITY. It would just irritate a number of people for no certain gain. No brains are melting if we pretend it's not okay to use "season" to refer to British shows, and probably no brains are melting if we use "series" in reference to a British (or NZ, or Indian, etc.) show to mean what US and Canadian people call "season". (While "series" could have a broader meaning even to some British readers, if we do use it consistently enough just to mean "season", they know what we mean, in the same way they know that "citation" as used by WP means "cited reference" not "award" or "speeding ticket"). So, do we really want to try to change the presently stable situation? I don't care if a footnote gets copyedited.  — SMcCandlish ☏ ¢ 😼  13:47, 19 February 2020 (UTC)[reply]
You don’t have to spend long on the BBC website, or any other UK media site, to see that ‘series’ is regularly used to mean what the Americans mean by ‘season’. Suggesting this is OR/POV/quasi-fiction is a tad offensive, don’t you think? That American terminology is often understood is a different thing from implying global acceptance; the same argument could be advanced for many terms within British English, which are often widely understood in Australia, Canada, New Zealand, India and South Africa, if not always within the US. MapReader (talk) 14:53, 19 February 2020 (UTC)[reply]
What part of:
"Series title italicized" is using series to mean the entire show as a whole. A season (also called a series in British English) with its own title uses quotation marks for that title, as a sub-work.
or
"Series title italicized" is using series to mean the entire show as a whole. If a season (also called a series in British English) or any other multi-episode storyline has its own title, it is a sub-work that uses quotation marks for its title: "Miracle Day" comprises the entire fourth series (season) of Torchwood. However, when a season name is used as a subtitle attached to the main title of the show (as is common on stand-alone DVD releases), use italics for the entire string: Torchwood: Miracle Day was released on DVD in November 2011.
do you find objectionable? DrKay (talk) 18:15, 19 February 2020 (UTC)[reply]

Being clear on spaced en dashes once and for all

This comes up periodically and the wording at MOS:DASH shifts a bit this way then a bit that. In a previous well-attended discussion (still on this page as of this writing, I think), we concluded that page numbers with hyphens in them should be given as ranges in the form "5-1 – 5-3". We've previously decided that (I think in similarly numeric context) that if one or both things on either side of the conjoining en dash contains its own space or hypen, we use a spaced en-dash between the two items. Another time we decided, more broadly, to do this if the material on either side contained spaces or dashes. These sections did not agree. I fixed that a few days ago ("space, hyphen, or dash" in both places now), and no one's head exploded. However, because this was not entirely clear and consistent, we have a lot of case of "foo-bar—baz quux" and "Ay Bee–CeeDee", when we should probably have spaced en dashes in there.

I just ran across Good cop/Bad cop, and this needs to move per MOS:DASH and MOS:SLASH to use an en dash. It appears to need to go to Good cop – bad cop (with redirs from Good cop–bad cop, Good cop-bad cop, etc.). I don't want to go propose this move if we're not actually certain this is what is want; maybe someone is certain it should really be Good cop–bad cop], despite the spaces. If so, then we need some really clear rationale for when to use a spaced en dash and when not to in these constructions. That is, if we're going to have WP:CREEP that calls for oh-so-special variances, in an already complicated section, they have to be justifiable concisely and memorably and with enough buy-in that people will accept and follow them. I'm skeptical that is possible, so I advocate just doing spaced en dash any time one or both sides of the "equation" are complex by way of spaces or internal punctuation. Last I remember a long discussion about this in such broad terms, several years ago, there was not unanimity on it, so let's try to figure it out this time.  — SMcCandlish ☏ ¢ 😼  14:02, 19 February 2020 (UTC)[reply]

I'm 90% sure in the big giant dash RFC all those years ago consensus was not to space endashed when there was spaces on either side, so New York–Los Angeles flight, not New York – Los Angeles flight. Indeed, I distinctly remember that being the main example debated because people claimed that not putting in the spaces would make it easy to misread as a new flight between York and LA, which was shot down as confusion being unlikely and clear from context, and there's no reason to punctuate New York–Los Angeles flight any differently than say Chicago–Dallas flight. So there already is established consensus not to use spaced endashes when the elements have spaces. It seems that in the years since there's been some erroneous drift away from that, but it needs to be re-instituted. oknazevad (talk) 14:19, 19 February 2020 (UTC)[reply]
I don’t believe these two edits are correct: [5] [6]. That is, pro-establishment–anti-intellectual alliance and Seeliger–Donker-Voet scheme should just contain an en dash, not a spaced en dash. The analogy with page numbers does not seem valid, since these are not page numbers. More generally, where does the instruction The en dash in a compound is always unspaced, except when either or both elements of the range include at least one space, hyphen, or en-dash; in such cases, {{snd}} between them will provide the proper formatting. come from? (Note that this contradicts the adjacent example Seifert–van Kampen as well as the instruction Do not use spaces around the en dash in any of the compounds above..) I can’t say I’ve ever seen professional English writing use spaced en dashes like this. Hftf (talk) 12:45, 27 March 2020 (UTC)[reply]

Proper nouns

Hello, all,

I am hoping to find a couple of people who love the English language and all its quirks, who can explain whether and (most interestingly) why these phrases are correct:

  1. This change affects the German and English Wikipedias.
  2. This change affects German and English Wikipedia.

One of them sounds better to my ear than the other, but I don't know that the other is wrong. What do you think? Whatamidoing (WMF) (talk) 20:08, 20 February 2020 (UTC)[reply]

I am certainly not qualified to speak about the nuances of English grammar. But, just reading those two sentences, the second sentence reads to me as if Wikipedia is a plural of 'Wikipedium' which I know to be nonsense. Both sentences sound equally correct to my ear if they both end with the plural 'Wikipedias'.
—Trappist the monk (talk) 20:30, 20 February 2020 (UTC)[reply]
Would "This change affects both the German and the English Wikipedias" fit? Martin of Sheffield (talk) 21:02, 20 February 2020 (UTC)[reply]
Try: “This change affects both the English and German versions of Wikipedia” Blueboar (talk) 21:08, 20 February 2020 (UTC)[reply]
The first is correct, the normal formation of a plural in English being to add an -s. The second is mock Latin - a plural form in Latin was to end a word in -a where the singular form was -um. For example the word “agenda”, derived from Latin, is actually a plural meaning “items to be considered”, the singular form agendum being the correct form if there is only one item of business. Similarly, addendum-addenda (item/s to be added). The second version only ‘sounds’ right because there are still Latin words such as this in everyday use where the -a ending denotes a plural. However the -pedia in Wikipedia derives from the word “encyclopaedia” (using the American spelling which drops the middle ‘a’), originally from the Greek with the -paed- part referring to the education of children (cf. the related paediatrics and paedophilic). The plural of encyclopaedia is encyclopaedias and hence the plural of Wikipedia is Wikipedias. MapReader (talk) 21:49, 20 February 2020 (UTC)[reply]
(edit conflict) @MapReader: That's perfectly correct as far as it goes, but consider that "German" and "English" might be parts or versions of Wikipedia regarded as a single entity. @ALL: Please also note that if the German Wikipedia is considered one entity and the English Wikipedia another, it is better to repeat the definite article: "the German and the English Wikipedias" Martin of Sheffield (talk) 21:58, 20 February 2020 (UTC)[reply]
Your “as far as it goes” actually meaning “as a correct answer to the OP’s question” about English usage. But I don’t disagree with your further response. Probably, this discussion shouldn’t be here at all, as we are not really discussing the MoS. But the question was an interesting one and I couldn’t resist a reply. MapReader (talk) 22:10, 20 February 2020 (UTC)[reply]
As MapReader said, this has nothing to do with our MoS and so belongs at WP:RDL. ―Mandruss ☎ 00:28, 21 February 2020 (UTC)[reply]

Which difference between the sentences are we supposed to be considering? There are two: 1) the presence or absence of "the" before "German" and 2) the presence of absence of the plural ending "s" on "Wikipedia"? --Khajidha (talk) 13:49, 21 February 2020 (UTC)[reply]

Agreed it doesn't belong here, but it is interesting to me too, so I'll comment. The presence or absence of "the" seems to matter. The phrase the English and the German Wikipedia is ellipsis for the English Wikipedia and the German Wikipedia, i.e. two singular proper noun phrases joined by "and" to make a plural noun phrase, so I would say definitely singular "Wikipedia" with a capital. Without the second "the", it's ambiguous between the implausible reading "the English-and-German Wikipedia" (one Wikipedia in English and German) and the intended reading "the English and German wikipedias" (where no capital is needed in our usual aggressively de-capitalizing style). Peter coxhead (talk) 16:45, 21 February 2020 (UTC)[reply]
And you still missed what I was asking about. The examples were "This change affects THE German and English Wikipedias" (the capitalized for emphasis" and "This change affects German and English Wikipedia." Yes, a second the could be added before English, but that first the seems necessary. --Khajidha (talk) 18:39, 21 February 2020 (UTC)[reply]
If you insist on continuing the discussion, I suggest focusing on the question as asked. One formulation is clearly correct and the other not. MapReader (talk) 21:21, 21 February 2020 (UTC)[reply]
I'm trying to determine what the discussion is. There are two differences in the original sentences. Are we supposed to comment on the "the" or the "s"? Or both? Is one of them simply a typo? If so, which? I agree that the first is correct, but the original poster should be made aware that there are two problems with the second version. --Khajidha (talk) 21:47, 21 February 2020 (UTC)[reply]
Both differences, please, Khajidha, and feel free to suggest the ideal phrase, if you prefer something else. Whatamidoing (WMF) (talk) 21:27, 24 February 2020 (UTC)[reply]

American Indians - manual of style

Ran across an article using the out-of-date Indian to refer to the native people of America. Was wondering what the accepted terminology is today. I did a search of the Manual of Style archive and found a discussion, 12 years old, talking about "Native American" and "American Indian". Is there a preferred wikipedia nomenclature? I know Indian simply isn't appropriate anymore, but what should it be replaced with? StarHOG (Talk) 16:48, 21 February 2020 (UTC)[reply]

If we're specifically talking about Native Americans in the United States, then AFAICT existing practice would be to use more specific terminology wherever possible, and "Native American" where a general term is required. (See for example Category:Native American topics and subcategories.) "Indigenous" is the broader term and would be preferred for example if some of the peoples involved are in Canada. The best places to find past discussions appear to be the archives at Talk:Native Americans in the United States and WP:CFD. The members of WP:Indigenous might also be able to provide useful input. For general background, see Native American naming controversy. -- Visviva (talk) 17:23, 21 February 2020 (UTC)[reply]
Thank you so much! StarHOG (Talk) 13:42, 26 February 2020 (UTC)[reply]

Multiple sic

Has there been any discussion on the handling of a quote with multiple errors or antiquated spelling? For example, an old poem with variant spellings. Multiple sics is awkward and shaming. I handled this in the second quote at [7] with a prefatory note instead of three sics, not finding any guidance here. If there is a preferred method, it would be useful to include it at MOS:SIC. O3000 (talk) 17:25, 21 February 2020 (UTC)[reply]

I'd say a note before or after would be better than multiple sics. A note could also explain any really obscure words/spellings/idioms that might be present.--Khajidha (talk) 17:04, 22 February 2020 (UTC)[reply]
What you've done looks just fine. Martin of Sheffield (talk) 17:30, 22 February 2020 (UTC)[reply]
Putting a single "[sic]" at the end of an error-riddled quote is the traditional way of handling it. Rather than calling out each item (which wasn't the original intent of the disclaimer), it applies to the whole quote, advising the reader that the original read... thus. -Jason A. Quest (talk) 19:03, 24 February 2020 (UTC)[reply]
I actually tried that first and think it makes sense. Don't know if that style is well known. O3000 (talk) 19:07, 24 February 2020 (UTC)[reply]
It's not "error-riddled" though, it just uses an earlier form of spelling. Martin of Sheffield (talk) 10:10, 26 February 2020 (UTC)[reply]
  • Sic is for one or two isolated errors/oddities that warrant gentle flagging to save the reader puzzlement, but no special attention. If there's more than that then an explanatory note is best. EEng 17:43, 2 March 2020 (UTC)[reply]

Gender identity: inaccurate paraphrase of cited page

The page currently reads "Wikipedia:Manual of Style/Biography § Changed names calls for mentioning the former name of a transgender person if they were notable under that name."

But this is not an accurate account of what the linked page says: (emphasis added) "In the case of transgender and non-binary people, birth names should be included in the lead sentence only when the person was notable under that name." I attempted to add a similar clause here to clarify the scope of this guidance, and it was reverted. But it's an important distinction: I just encountered someone citing the phrasing here as justification for removing a trans person's former name from the entire article, as if that were WP policy. I'm not suggesting that any policy or guideline be changed, only that this page more accurately reflect the phrasing on the page it cites. -Jason A. Quest (talk) 18:57, 24 February 2020 (UTC)[reply]

That's because the section you cited only deals with the lead sentence for ALL name changes, it isn't designed to handle general content. The more general statement that the former names of a transgender person are not discussed if the person is not notable under those earlier names is the larger, more over-arching principle, and the information about the lead sentence is a part of that. After all, if the article isn't supposed to mention it anywhere, it of course can't mention it in the lead sentence. The reason why the link only mentions the lead sentence is that particular section of the MOS altogether only deals with lead sentences. It's style guidance, not policy on transgender people. The greater policy on transgender people informs that information, it is not secondary to it. --Jayron32 19:07, 24 February 2020 (UTC)[reply]
What you just said is not what this page says. This page merely affirms that a birth name should be given if the person was notable under it, not that it may not be mentioned anywhere in an article if they were not. That would have very different and profound implications. If what you said is an actual policy, I would very much like to know where it's stated. -Jason A. Quest (talk) 20:04, 24 February 2020 (UTC)[reply]
I think I see the source of the confusion. Wikipedia:Manual of Style#Gender identity makes it look like it's OK to deadname someone as long as it isn't the lead sentence. This is definitely NOT policy; this page (by the way) only deals with style issue (how to organize information in an article), it doesn't deal with content policy (what should go into an article). The information you seek is located at WP:BLPNAME, which covers names of all sorts and not just of transgender people. Relevant here is "When the name of a private individual has not been widely disseminated or has been intentionally concealed...it is often preferable to omit it, especially when doing so does not result in a significant loss of context." In this case, if the transgendered person was never publicly known at the time of their life when they had their prior name the default is to not include it. You'll note that WP:BLPNAME does not carve out any exceptions for where those are located. --Jayron32 20:35, 24 February 2020 (UTC)[reply]
BLPNAME doesn't cover transgender people [not "transgendered", please] who are no longer living. Furthermore, the part you quoted is specifically talking about "private" (non-notable) people (e.g. crime victims, whistleblowers, children), not someone who is the subject of an article themselves. If that presumption-of-privacy policy was meant to apply to birth names, the legal names of most Hollywood actors and the maiden names of countless married women, would be kept out of articles, which is rather obviously not what we do. What you're citing is not a policy on this question. You're doing what everyone else does, every time this comes up: trying to weave strands of policy written for other things into something that makes sense to you. And in the absence of a clear content policy, this page is constantly being cited as such; that's part of the reason I'd hoped to hold it to a higher standard of clarity. -Jason A. Quest (talk) 23:55, 24 February 2020 (UTC)[reply]
If the individuals were not notable under their birth names, then at that time they were private and non-notable. Secondly, the use of someone's pre-transition name for transgender individuals is often and frequently used as a way to delegitimize them as transgender individuals. Because of this, special consideration is given to these individuals under Wikipedia's "minimize harm" policy, as laid out in numerous policy pages. To claim this is the same as an actor using a stage name is disingenuous and a false equivalence. Please do not do so, and if you don't understand the nuance of the issues faced by transgender people, I highly recommend you stop editing in that area, lest you continue to create the problems you have been. --Jayron32 14:25, 25 February 2020 (UTC)[reply]

Tweak to requirements set out in 'Section headings'

Example of how headings wrapped in Wikitable markup breaks the contents section. Left Wikipedia App; Right Chrome.
Example of the confusing and useless mess of Wikimarkup shown when previewing edits made from section headings in a Wikitable.

As it stands MOS:HEADINGS is split between guidelines that must be followed for technical complications that can’t be overridden by local consensus or Wikipedia:Ignore all rules (necessary), and guidelines which should be followed in the interest of being consistent (recommended).

There’s one bullet point that I think should be moved from recommended to necessary; 

* Not wrap headings in markup, which may break their display and also cause additional accessibility issues.

The issues with placing headings in markup include:

  • Navigation issues in the Wikipedia app (Android), often section headers are placed in the markup for Wikitables as a sort of pseudo-header / table divide. However, the app can’t handle this, and will remove it as a means of navigation in the contents section. This issue isn’t present in browser navigation, which is perhaps due to the auto-collapsing of elements to conserve data in the app. I haven’t tested the iOS version of the app, so input here would be helpful. Regardless, it needlessly excludes a segment of readers from a useful feature.
  • Using [edit source] next to section headers wrapped markup results in a mess of Wikimarkup when previewing. Without the start of the markup, the previewer can’t adequately display the change as it will appear when published. For experienced editors this probably isn’t an issue, but for novice editors (who ironically often get told to use the preview feature before publishing changes) it’s a confusing and unnecessary barrier when contributing to Wikipedia.
  • My understanding is that badly placed headers can cause issues for readers using assistive technology (e.g. screen readers), because headers are used to ‘skip’ through pages to find relevant information, when headings aren’t where they are expected to be, or are used improperly this can result in accidentally skipping important information (e.g. table captions or keys) or make it difficult to locate desired content within a page.

The images to right attempt to demonstrate some of the above described issues. For reference, they are all taken from the page List of Marvel Cinematic Universe film actors.

I think there are enough issues of significant enough inconvenience that it should become a necessary guideline, but welcome input that is both positive and negative (so long as constructive rather than dismissive).

I guess this could be considered an early effort to see if there's any potential for consensus being reached to make a change.

Thank you, Editing with Eric (talk) 15:33, 2 March 2020 (UTC)[reply]

Paula Vennells

A user (Pigsonthewing) recently reverted an edit without consultation which treated of a quotation of less than 40 words as not needing indentation. I am perfectly fine with indentations for block quotations of 40 words or more to be so treated, but not for things underneath that.

I note that the Wikipedia Manual of Style concurs with me about block quotations (as does MLA and MHRA style guides which are authoritative in their way), therefore I am seeking a resolution that this page will not be an exception to that as this user seems to want to make it. Knucmo2 (talk) 23:05, 4 March 2020 (UTC)[reply]

This isn't a court of appeal, and MOS is supposed to be applied with common sense. One reason a short-ish quote might be set off in a block is to parallel other quotes. Work it out on the talk page. EEng 06:22, 5 March 2020 (UTC)[reply]

New Zealand – "the" North and South Island

I couldn't find anything in the MOS about this, so I decided to raise it here. Wikipedia's article on the North Island of New Zealand states – accurately, IMO – that: In prose, the two main islands of New Zealand are called the North Island and the South Island, with the definite article. It is also normal to use the preposition in rather than on, for example "Hamilton is in the North Island", "my mother lives in the North Island".[8] Maps, headings, tables and adjectival expressions use North Island without "the". The citation given is the Guardian and Observer Style Guide. (The article on New Zealand's South Island includes a similar statement.) There has been a small amount of debate about this on Talk:North Island. I'm bringing this up because of a cringeworthy (IMO) sentence in the "British English" article Citizens Advice: "New Zealand has over 80 Citizens Advice Bureau sites situated on both North Island and South Island." However, I can envisage an argument over British vs New Zealand English if I edit the latter sentence. Perhaps Wikipedia needs a clear MOS policy on this point? Muzilon (talk) 03:03, 6 March 2020 (UTC)[reply]

Tagging User:Gadfium and User:Martin Kealey here, ftr. Muzilon (talk) 05:15, 6 March 2020 (UTC)[reply]
I can only say that as a native speaker of British English, I find the absence of "the" odd, and I would have assumed it was perhaps a New Zealand usage. The preposition is another matter; either "in" or "on" seem ok to me. Peter coxhead (talk) 20:42, 6 March 2020 (UTC)[reply]
This discussion looks familiar. --Izno (talk) 00:02, 7 March 2020 (UTC)[reply]
The RfC referred to in that discussion only covers the preposition debate ("in/on"), not the definite-article question ("the"). By way of comparison, I think most New Zealanders would say they live in the North Island or in the South Island, but on Stewart Island (the third-largest island of NZ, which is much smaller than the North and South Islands). As for the definite article, I've only come across the omission of "the" among some speakers and writers of British (and perhaps also American) English. A search of Google Books turns up several scholarly sources about the use of the definite article in this case. Muzilon (talk) 01:36, 7 March 2020 (UTC)[reply]
I would personally suggest being bold and just changing it. As a native speaker of American English, I can tell you it looks strange without the definite articles to my eyes as well; we would typically use them exactly as you have stated New Zealanders would, unless perhaps North were a proper name itself. I see nothing wrong with in versus on, either. Americans would tend to talk about being in Hawaii (the state) and on Hawaii (the island), but no one would assume one or the other strictly based on choice of pronoun (they would use the big island to eliminate confusion). CThomas3 (talk) 07:15, 7 March 2020 (UTC)[reply]
"The North and South Islands" are (arguably) geographical designations or regions rather than proper names, unlike Stewart Island and White Island, which are proper names. FTR, a search turns up many WP articles using "on North Island" without the definite article. Muzilon (talk) 01:55, 9 March 2020 (UTC)[reply]
It looks like on Google Books that "the North Island" in reference to New Zealand is more common than "North Island" without the definite article. Google Books has broader coverage in the United States because our fair use doctrine is much broader than the fair dealing doctrine used in many other countries. --Coolcaesar (talk) 02:25, 9 March 2020 (UTC)[reply]
OK, I've somewhat boldly changed the sentence in the Citizens Advice article. To avoid the "in/on" controversy, I've just used the word "throughout", which I hope is acceptable in any variety of English! Muzilon (talk) 08:35, 11 March 2020 (UTC)[reply]

Prime symbols for feet and inches?

MOS:CURLY says we use prime and double prime for subdivisions of degrees. What about for feet and inches? Primes, or straight quote marks? Dicklyon (talk) 16:10, 9 March 2020 (UTC)[reply]

None of these. These marks are not well-enough known in countries that don't use Imperial or US customary measurements for people to recognize what they are. Jc3s5h (talk) 16:12, 9 March 2020 (UTC)[reply]
Right. See first row of the table at Wikipedia:Manual_of_Style/Dates_and_numbers#Specific_units. EEng 16:14, 9 March 2020 (UTC)[reply]

Eponymous

Seeking style advice/comments on the use of eponymous (as here). It strikes me as redundant (i.e., already differentiated by the label "town"), much as we don't have "New York is a city in the eponymous state of New York" or "The Gulf of Mexico borders the eponymous county of Mexico" or "The Bristol Channel takes its name from the eponymous city of Bristol." Thanks. Doremo (talk) 17:14, 9 March 2020 (UTC)[reply]

Non-breaking spaces with written out units

As a follow-up to topic-specific discussions at Talk:Hassium and User talk:DePiep#MOS and NBSP, it seems that the current MOS guideline on the usage of non-breaking spaces when separating numbers from written-out units (e.g. 5 kilometers (instead of 5 km); 118 elements) is open to interpretation. It advises to use non-breaking spaces when line breaks are awkward, which they seem to be in this case; however, implementing this would apparently require making heavy changes to lots of articles, as it is not strongly established as are the examples given in the MOS section.

I thus ask, should the same guideline for quantities and abbreviated units be followed for fully spelled-out units? Should non-breaking spaces be used only with abbreviations, or always with units and quantities? I would like to establish a more definite MOS guideline, in which one or the other is widely agreed upon as common practice. ComplexRational (talk) 00:46, 10 March 2020 (UTC)[reply]

  • I really, really wish people would stop jumping straight into a project-wide RfC before working with other editors to frame the questions to be posed. I urge you to withdraw this. And MOSNUM is probably the right place for this. (Main MOS vs subsidiary pages is a longstanding problem.) EEng 01:26, 10 March 2020 (UTC)[reply]
Where else would you suggest discussing this, seeing as its outcome is not specific to the articles for which this was discussed, and the question is pretty straightforward from these discussions? If it can be held elsewhere, I will withdraw; however, I don't think that place is MOSNUM because this issue pertains to MOS:NBSP, which is not its own MOS sub-page. I'm open to ideas. ComplexRational (talk) 02:02, 10 March 2020 (UTC)[reply]
I'd suggest discussing it right here (or at Talk:MOSNUM, but since ultimately it's an aesthetic, not technical, issue I guess here is fine.) There are plenty of people here who have thought a lot about formatting issues, and many have outside professional experience, and with their participation I suspect the issue can either be resolved or boiled down to a clearcut question. Open-ended RfCs like you've started, which pull random people from all over into an unstructured discussion, just end up a mess. EEng 03:28, 10 March 2020 (UTC)[reply]
Okay, I withdrew it as an RfC. Let's play it out as a regular discussion now; I apologize for being unaware of this potential complication. ComplexRational (talk) 09:53, 10 March 2020 (UTC)[reply]
Ping to prevent archiving. EEng 12:49, 27 March 2020 (UTC)[reply]

In traditional typography, typesetters would ensure that sentences didn't break onto another line at a point where the result was a new line starting with something that didn't make sense alone, or where the break would produce a semantic dissonance. So they would avoid lines starting with an abbreviation:

  • something something ... a distance of 15
    km

as well as lines that changed meaning when the next line was read:

  • something something ... a cost of $5
    million

In electronic document processing, when line length can change with screen resolution or window size, the non-breaking space was used to prevent those sort of breaks from happening. I don't believe there has ever been any rationale for placing a non-breaking space between numbers and normal recognisable English words, because those don't produce problems, other than in cases like the second example. There is really nothing wrong with seeing:

  • something something ... a distance of 15
    kilometres

and it is especially ludicrous to extend the fetish for non-breaking spaces in quantities to normal counted items. There is nothing wrong with reading:

  • something something ... a squad of 24
    football players

The examples at MOS:UNITNAMES reflect these simple principles, and I can't see what other interpretation could be made of the present guidance:

  • Use a non-breaking space ({{nbsp}} or &nbsp;) between a number and a unit symbol, or use {{nowrap}} ...
  • ... and a normal space is used between a number and a unit name.

If somebody wants to change those guidelines, then they really should be proposing what changes they want made and the reasons for them. --RexxS (talk) 19:07, 27 March 2020 (UTC)[reply]

Quotation marks around a foreign title

If a foreign title appears within the prose of an article, should we use quotation marks for English or the language of origin? For instance, should we refer to "La Marseillaise" or «La Marseillaise» ?

This matter is currently in flux at Giuseppe Tartini (edit | talk | history | protect | delete | links | watch | logs | views). —C.Fred (talk) 23:19, 12 March 2020 (UTC)[reply]

MOS:CURLY says Do not use accent marks, backticks (`text´), low-high („ “) or guillemet (« ») marks as quotation marks. Not a "should", or "except when...", just "do not". I change them wherever I find them. Schazjmd (talk) 23:24, 12 March 2020 (UTC)[reply]

podcasts

What is the proper format of the title of a podcast? Lfstevens (talk) 18:04, 16 March 2020 (UTC)[reply]

Lfstevens, An episode is a short work like a song or an episode of a television series, so it's in quotation marks: "Episode 19: The Truth Revealed!" but the publication is a long work like a book, magazine, television series, etc., so it's italicized, "Next week on Listen to This, we'll discover who did it!" ―Justin (koavf)❤T☮C☺M☯ 20:01, 16 March 2020 (UTC)[reply]
Thanks! Lfstevens (talk) 07:05, 17 March 2020 (UTC)[reply]

Exceptions to Wikipedia:Manual_of_Style#Brackets_and_parentheses

The text reads in part, "If sets of brackets are nested, use different types for adjacent levels of nesting; for two levels, it is customary to have square brackets appear within round brackets." Are there exceptions to this? E.g. Round parenthesis inside of round parenthesis: "He told me that his boss (the president (George Washington)) was dead".

@Deacon Vorbis: ―Justin (koavf)❤T☮C☺M☯ 20:00, 16 March 2020 (UTC)[reply]

(edit conflict) So, there's currently a dispute over switching to brackets instead of using nested parentheses (pinging the other party (Koavf)). The MOS seems to say to switch parens to brackets in this case, but looking through the talk page archives, I can't find a ton of discussion about this, but that could just be bad search-fu on my part. In any case, I'd suggest that we simply drop this. Seeing brackets where you don't expect them is much more jarring and confusing than a nested set of parens, and can be confused with editoral comments/changes. –Deacon Vorbis (carbon • videos) 20:03, 16 March 2020 (UTC) I typed up a new thread at the same time; moving my version here to consolidate. –Deacon Vorbis (carbon • videos) 20:05, 16 March 2020 (UTC)[reply]

Deacon Vorbis, But that is exactly where I'd expect them. ―Justin (koavf)❤T☮C☺M☯ 20:08, 16 March 2020 (UTC)[reply]
  • This "switch to square brackets" idea is nutso -- as already mentioned it looks like an editorial insertion. If a suspension or "parenthetical" is needed inside parens -- and there better be a damn good reason for this -- use dashes or recast the whole thing. I propose changing the current guideline...
    If sets of brackets are nested, use different types for adjacent levels of nesting; for two levels, it is customary to have square brackets appear within round brackets. This is often a sign of excessively convoluted expressions; it is often better to recast, linking the thoughts with commas, semicolons, colons, or dashes.
... to ...
The temptation to use brackets inside of brackets is often a sign of convoluted structure; use a pair of dashes instead, or recast to link concepts with commas, semicolons, or colons.
EEng 20:29, 16 March 2020 (UTC)[reply]
  • For someone who likes to moan about standard English rules in the MOS, I consider switching the kind of brackets to be standard English. :) In general, I would anticipate the internal brackets are not being used in the context of a quotation, and we don't provide editorial insertions elsewhere (in most cases). If I had a point to make, it's that you should never use parentheses in general when conveying parenthetical thoughts; either it's truly parenthetical in which case you probably shouldn't include it (c.f. WP:WEIGHT), or it's not actually parenthetical and the whole sentence(s) should be extracted from every pair of brackets, rounded or otherwise (some exceptions like units conversions may apply). So your suggested change does not go far enough. --Izno (talk) 21:08, 16 March 2020 (UTC)[reply]
    Before we go on, are you saying you like to moan about standard English rules in the MOS, or are you reminding me of my continual moaning about that (not that I'd take offense at such a reminder)? EEng 21:22, 16 March 2020 (UTC)[reply]
    You particularly (I assume no offense would be taken). --Izno (talk) 22:07, 16 March 2020 (UTC)[reply]
    I figured; it's just that grammatically your sentence says it's you. So then... You're right, I momentarily forgot to ride that hobbyhorse i.e. that MOS shouldn't try to teach standard rules of English that apply to any publication. But there's an exception: if for some reason we've found that a particular point is a chronic problem (especially if it keeps leading to dispute among editors) then sure, we should have a bulletpoint on it. However, I'm struggling to believe this falls in that category. So I'd like now to suggest that ideally we just drop the bullet, and failing that substitute my text above. EEng 01:15, 17 March 2020 (UTC)[reply]
  • Mathematical formulas and computer code *must* be an exception to this. In most mathematical and computer science contexts, differently shaped brackets imply different meanings. In mathematical formulas, nesting of parentheses can better be indicated by using different sizes of same-shaped parentheses. Another context where bracket shape has a special meaning is inside direct quotes, where [stuff in square brackets] usually means some kind of editorial interpolation that is not part of the quote. In any case I prefer EEng's suggestion of telling people not to use nested parens to the current idea of starting with telling people to use them and then only as an afterthought mentioning that they're a bad idea. —David Eppstein (talk) 22:54, 16 March 2020 (UTC)[reply]
    Correct on both counts. --Red King (talk) 23:54, 16 March 2020 (UTC)[reply]
    David Eppstein, Yes, but we aren't talking about actual math statements or code: the example above is standard English running text that so happens to be discussing math. Obviously, when using standard English typography symbols to construct a mathematical formula, you should use them how it is standard among mathematicians: no one is arguing otherwise. ―Justin (koavf)❤T☮C☺M☯ 19:35, 18 March 2020 (UTC)[reply]
  • EEng, Agreed that the text should discourage nested bracketing and that it is almost always better and more clear to rewrite but there will be occasional times when it's useful. ―Justin (koavf)❤T☮C☺M☯ 19:37, 18 March 2020 (UTC)[reply]
    See my post above beginning "I figured...". I think we should just drop the bullet entirely per the principle that MOS shouldn't teach general good writing, unless someone can satisfy the WP:MOSBLOAT test. EEng 20:00, 18 March 2020 (UTC)[reply]
Ping. Any objections to just removing the bullet? EEng 23:42, 25 March 2020 (UTC)[reply]

New RFC on linking to Wikidata

I want to support wikidata in article main. Viruscorona2020 (talk) 10:03, 18 March 2020 (UTC)[reply]

We have had multiple discussions on this. Won’t fly unless Wikidata changes some of its policies. Blueboar (talk) 12:29, 18 March 2020 (UTC)[reply]

Typographical symbols used for notes and accessibility

I have been editing several types of articles lately to make them more accessible, particularly by adding table captions and alt text but also by enforcing MOS:COLOR at places such as Tom Brady#NFL career statistics. If you look at the legend provided before I edited, it only used color (or color and emphasized text) to signify things like, "This statistic is an NFL record". Consequently, I added a series of symbols to act as an extra visual cue but Bagumba brought to my attention that the symbols I arbitrarily chose are fairly non-standard per Note (typography)#Numbering and symbols. I think for consistency as well as accessibility, we should outline a preference for the order: *, †, ‡, §, |, ¶, #, Δ, ◊, ↓, and ☞. It seems like MOS:PUNCT is the most relevant place for this. Thoughts? ―Justin (koavf)❤T☮C☺M☯ 02:02, 21 March 2020 (UTC)[reply]

Thanks for your efforts, Justin. I recommend looking at MOS:NOSYMBOLS; we found some time ago that screen readers like JAWS don't always read out all symbols, so I started creating templates that used images with alt text in place of symbols like † - see templates {{†}} alias {{dagger}} for an example, and the Category:Single-image insertion templates for a collection of them. In brief, symbols that you can type from your keyboard directly are safe to use for screen readers, otherwise the {{†}} and {{‡}} templates are good choices (especially as you can associate alt text like this {{dagger|alt=NFL record}} with them). --RexxS (talk) 03:34, 21 March 2020 (UTC)[reply]
RexxS, Nice. I get the reason why I see the templates as stand-ins for the raw symbol. Now that I know it's a best practice, I can use that. Do you have thoughts on the order of symbols I mentioned? ―Justin (koavf)❤T☮C☺M☯ 08:06, 21 March 2020 (UTC)[reply]
@Justin: I usually suggest the keyboard ones or the templated ones first (depending on the context), so either:
or:
would be my personal preferences. --RexxS (talk) 17:01, 21 March 2020 (UTC)[reply]
RexxS, It is definitely nice when they can be easily inserted with ASCII symbols but some easy-to-type templates like "{{dagger}}" are fairly painless as well.
Does anyone else have feedback to give on ordering these symbols, etc.? Is there are a better place to record this than the section at MOS:PUNCT? ―Justin (koavf)❤T☮C☺M☯ 21:28, 23 March 2020 (UTC)[reply]

The conventional order of these footnote symbols in English has a wide consensus for the first three symbols. The order is *, †, ‡. That is, 1. {{asterisk}}, 2. {{dagger}} 3. {{double-dagger}}. The Wikipedia entry (with sources) for Dagger (typography) states that the dagger ... "is a typographical symbol that usually indicates a footnote if an asterisk has already been used".[1] and that a double dagger "... usually marks a third footnote after the asterisk and dagger".[2]

For footnotes more than 3, there is less consensus – "beyond the ... double dagger, this order is not familiar to most readers, and never was".[3] However, the Chicago Manual of Style Online – requiring a subscription or 30-day free trial to access – provdes this:

Where symbols are used, the sequence is as follows:
  1. * (asterisk; but do not use if p values occur in the table; see 3.78)
  2. † (dagger)
  3. ‡ (double dagger)
  4. § (section mark)
  5. || (parallels)
  6. # (number sign, or pound)

Which is as good a guide as any. -- Ham105 (talk) 01:44, 24 March 2020 (UTC)[reply]

References

  1. ^ Eric Partridge (2004). You Have a Point There: A Guide to Punctuation and Its Allies. Routledge. p. 235. ISBN 978-0-203-37992-9.
  2. ^ Hoefler, Jonathan (4 June 2009). "House of Flying Reference Marks, or Quillon & Choil". Hoefler & Frere-Jones. Archived from the original on 5 February 2010. Retrieved 6 April 2010.
  3. ^ Robert Bringhurst (2005). The Elements of Typographic Style (version 3.1). Point Roberts, WA: Hartley and Marks. pp 68–69.

English variety for the European Union

Hi! I happen to watch WP:MOS (although for a different reason) and I saw the last edit of yours. Why do you say that version you removed was incorrect? It doesn’t seem to be particularly correct to me to include British English, given that the UK is longer appartement of the EU, and it certainly does not feel right to exclude Maltese English given that Malta is. I’m curious what your reasoning was; could you clarify that for me?—R8R (talk) 14:03, 20 March 2020 (UTC)[reply]

Certainly R8R (also Alexander 8620, Ahecht, and Jdforrester), and I have taken the liberty of copying this across from my talk page to the Manual of Style talk page.
The Wikipedia Manual of Style for all English Wikipedia articles "always has precedence should any contradiction arise" and "new content added to this page should directly address a persistently recurring style issue."
This is not about which countries are and are not members of the European Union. It's about edits which changed the (English) Wikipedia Manual of Style instructions on what variety of English to use in one of several examples given; the examples are given to show that strong ties to a particular variety of English are best respected. The example in question is asserting that British English (or Irish English) are the correct choices for the English Wikipedia in articles about institutions of the EU. The edits I reverted were changing that advice, to assert that English Wikipedia articles about the EU should be written in Maltese English.
Maltese English is "heavily influenced by Italian, not only in vocabulary (... pronouncing Franco-Latin loan words in English in an Italian style) but extending to phonology, with the English being heavily accented".
Of the 24 official languages of the EU, three (English, French and German) are "procedural" languages. "Strong ties" is not narrowly defined as formal membership of a political body; commonalities of geography, history, culture, populations, politics, etc all form "strong ties". Although the "varieties of English" we are discussing are an internal construct of Wikipedia and not something used or recognised by the EU, commonalities forming strong ties has meant that the "procedural" (per EU) "variety of English" (per Wikipedia) used by the EU is de facto British English. It was used by the EU and its predecessors before the UK was a member, and will continue to be used now the UK no longer is. Along with English, the 24 official languages of the EU include the Irish language and the Maltese language (but not "Irish English" nor "Maltese English").
In summary;
The UK leaving the EU is entirely irrelevant here,
It would not be sensible to require Maltese English be used in articles about institutions of the EU,
Were the edits to stand the example would be a poor one to illustrate the advice being given,
There is no "persistently recurring" style issue over using British or Maltese English needing to be addressed by altering the Manual of style.
I hope that makes sense, cheers! Captainllama (talk) 02:54, 21 March 2020 (UTC)[reply]
I agree and, further, the MoS states that where organisations use a particular variety of English, that variety should be used in WP articles relating to that organisation. Looking at the official EU website, AFAICS the English used is British throughout. I don't expect anyone is going to be editing all those webpages introducing whatever are the Maltese English variations, just because the UK has left the EU! Plus, of course, the UK retains "ties" with the EU despite its departure, by dint of its historical involvement. MapReader (talk) 08:39, 21 March 2020 (UTC)[reply]
​(Copied across from Captainllama's talk page to here where it will get fuller attention): Thank you for the explanation. It indeed makes sense that English will continue to be an important language in the European Union even now that the UK has left, and there is indeed no doubt that that variety used in continental Europe will predominantly be the one used in Britain. However, what I don't understand is the specific difference between Irish English and Maltese English; why is the former a proper variety to use for describing the EU alongside British English whereas the latter isn't?--R8R (talk) 10:22, 22 March 2020 (UTC)[reply]

Spaced slashes

A slash fan
A spaced Slash

Seeking comment on this change, which removes spaces for examples like the NY 31 east / NY 370 exit. Personally, I dislike the look of the NY 31 east/NY 370 exit and, even more so, say, the divided town of Carmen de Patagones/Viedma, which seems to imply that there is a town optionally called Carmen de Viedma. Thanks. Doremo (talk) 14:49, 22 March 2020 (UTC)[reply]

No particular opinion on the edit, but neither of your examples requires any slash at all. the NY 31 east (NY 370) exit and the divided town of Carmen de Patagones (Viedma) or the divided town of Carmen de Patagones (aka Viedma). ―Mandruss ☎ 15:03, 22 March 2020 (UTC)[reply]
The examples simply present the issue as an orthographic problem. There are usually ways to rephrase such examples, but forcing that as the solution would be the equivalent of forbidding slashes between open compounds, which is not desirable. Doremo (talk) 15:12, 22 March 2020 (UTC)[reply]
<ec>In those examples, as you write them, I don't see any need for a space before and after the slash (solidus). It looks unnecessarily fussy (imo) to include spaces, because, certainly in the NY 31 east [etc.] example, a reader is not too likely to be surprised, I suggest, by the details presented after the slash. That's what an MOS "rule" often fails to allow for: in some cases, having the spaces provides a bit of oxygen and aids in comprehension; in other examples, it seems forced and gratuitous – in that a reader might register the spaces more than they'd ever register the lack of spaces where they might be welcome. I could see user:Oknazevad's reasoning when they made the change. JG66 (talk) 15:21, 22 March 2020 (UTC)[reply]
For what it's worth, The Chicago Manual of Style presents the spaced slash as a discretionary option in such cases: "Where one or more of the terms separated by slashes is an open compound, a space before and after the slash can be helpful. ... World War I / First World War." Doremo (talk) 15:30, 22 March 2020 (UTC)[reply]
  • As the one who made the bold edit (but didn't really think it so critical as to start a discussion when I was reverted), I'll stand by what I said in my edit summary: the guideline should be consistent for slashes and dashes. And the dash guideline, based on the long RFC discussion that hashed out the dash, was that the spaces are unneeded as context and consistency with items without spaces render them unneeded. That such a claim that dashes should be spaced recently creeped back in (dispute being explicitly rejected in the RFC) before I removed it again was what led me to look at the slash guideline. (well, that and the use of spaced slashes in constructions like Peter Parker / Spider-Man the cast lists of superhero films, which I frankly thinks looks like trash.) So I argue for consistency between both forms of punctuation, as the spaces look needlessly disjointive in both. oknazevad (talk) 22:19, 25 March 2020 (UTC)[reply]

Redundancy Words

Hi, I remember seeing in the MOS a few years ago something about redundancy words (pleonasms) like "in order", words that aren't needed. Is there a guideline somewhere that says what to do regarding these, if not in the MOS? — Yours, Bᴇʀʀᴇʟʏ • Talk∕Contribs 17:49, 25 March 2020 (UTC)[reply]

Not sure what you're referring to, but MOS isn't supposed to try to teach points of general good English writing, unless a particular point has been a special problem for our editors. I'll take this opportunity, however, to direct you to WP:ASTONISHME. EEng 19:17, 25 March 2020 (UTC)[reply]
Are you referring to wordy and pretentious phrases like "would go on to" as a synonym for "did"? If so, I agree they should be chopped out entirely or replaced with a shorter alternative. Reyk YO! 19:13, 27 March 2020 (UTC)[reply]
God, I hate that would shit. There's a very, very narrow appropriate use case for it, but in the main it sounds stupid in the extreme [9] [10] [11] [12] [13] [14]. For that I could be convinced a rule might be needed. I feel an essay coming on. ("EEng would later go on to write an essay on the subject...") If someone wants to contribute especially awful examples, WT:Queen_Elizabeth_slipped_majestically_into_the_water would be a good place. EEng 19:25, 27 March 2020 (UTC)[reply]
Surely it would be "... later go on to write down an essay ..."? --RexxS (talk) 19:37, 27 March 2020 (UTC)[reply]
Here is an astonishing example that still makes my eyelid twitch to think about. There are a few cases where "would" might be acceptable:
  • Describing past habitual behaviour. For instance, "The elders of this tribe would often tell children stories of demons and evil spirits."
  • Temporarily skipping to the relative future during a narrative. For instance, "Until the age of 12 Dave Gablorsky lived next door to Derpina McBean, who would later be the first person on Mars. At sixteen, Gablorsky enrolled in the military" or some such.
But where I see all the time is in awful sports articles, where editors seem to think they're writing for a sports broadsheet and are being paid by the word. It's cringe-inducing. Reyk YO! 19:58, 27 March 2020 (UTC)[reply]

Use of commas

I guess I am looking for some clarification. I am referring to this section of the MOS (fourth bullet point down).

WP:MOS#Commas:
In geographical references that include multiple levels of subordinate divisions (e.g., city, state/province, country), a comma separates each element and follows the last element unless followed by other punctuation.
Correct: He set October 1, 2011, as the deadline for Chattanooga, Oklahoma, to meet his demands.
Incorrect: He set October 1, 2011, as the deadline for Chattanooga, Oklahoma to meet his demands.

So, my question. How are we supposed to handle article titles (not text within an article) where a geographic location is referenced? For example: 1993 Aurora, Colorado shooting ... and ... 2012 Aurora, Colorado shooting. (In one of those article titles, I placed the "extra" comma in; someone took it back out.) (And that has happened with other article titles, as well. Some keep the comma, some do not.) Some editors believe that the above section of MOS only applies to article text, and not to article titles. Some believe the contrary. As a result, we have inconsistency. What can/should be done? I always thought/assumed that this MOS policy extended to both text and titles. I cannot see why the policy would distinguish between the two (text versus title). Thoughts? Thanks. Joseph A. Spadaro (talk) 20:16, 29 March 2020 (UTC)[reply]

Those editors who believe it only applies to article text, do they have any argument why it shouldn't apply to article titles as well? El Millo (talk) 20:24, 29 March 2020 (UTC)[reply]
@Facu-el Millo: Well, to me, not a convincing one. You can check the Talk Page here, for some discussion on the topic: Talk:2012 Aurora, Colorado shooting ... the issue surfaces up repeatedly at that Talk Page. And, less so, here: Talk:1993 Aurora, Colorado shooting. This has happened, in my experience (over the years), with many other pages. But I cannot recall the specific article titles, off hand. Joseph A. Spadaro (talk) 21:03, 29 March 2020 (UTC)[reply]
And here is a direct quote from another editor, when I asked about this at the Wikipedia Help Desk: I think WP:MOS#Commas is about sentences in article text and doesn't apply to page names. Talk:2012 Aurora, Colorado shooting#Requested move earlier 5 March 2019 gave no support for two commas in 1993 Aurora, Colorado, shooting or 2012 Aurora, Colorado, shooting. I would also have opposed it. That's the opinion of one opponent (of the second comma). Joseph A. Spadaro (talk) 21:08, 29 March 2020 (UTC)[reply]
It's strange. Reading the first discussion on adding the "Colorado" to the title, I still don't see the need for it. The year and the "Aurora" are enough disambiguation. Later, the suggestion of moving it to "2012 shooting in Aurora, Colorado" seemed like a good compromise. If I were the closer, I would've either given it more time or decide for the move, given that most opposing votes were based on Netholic's flawed argument and false premises. The thing with "2012 Aurora, Colorado, shooting" with the extra comma is that apparently too many people dislike it, so it will be very difficult to obtain consensus. Maybe you could try opening another RM where people choose between these two options. If more people choose either option than oppose the move altogether, then at least there'll be consensus that the title needs to be changed. El Millo (talk) 22:47, 29 March 2020 (UTC)[reply]
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Manual_of_Style&oldid=948057476"