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 84.46.52.151 (talk) at 18:06, 20 February 2020 (→CURLY and ELLIPSIS: + middot). 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]

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]

Possessives of linked items

Is it specified anywhere that possessives of linked items should be coded as [[x]]'s rather than [[x|x's]]?

I looked in various likely places and couldn't find anything. MOS:LINK#Style just says that a link "suffix" can't start with an apostrophe, while Help:Link#Wikilinks (internal links) gives an example possessive link, but it's really just incidental. MOS:POSS provides only unlinked examples. Maybe it's one of those things that seems to be common sense and it's how it's always done, so there's no need to specify it in the MOS, but when a newish user says they think it looks better with the apostrophe-s included in the link, it would be nice to be able to point to the MOS. MANdARAX • XAЯAbИAM 08:37, 20 January 2020 (UTC)[reply]

  • No, definitely not, because x's both looks better and makes more sense than x's.--Srleffler (talk) 02:19, 21 January 2020 (UTC)[reply]
  • Please see WT:Manual_of_Style/Linking/Archive_18#Saxon_genitive_and_piping. I cannot think of anything we less need a rule on and less need to spend time on. EEng 07:54, 21 January 2020 (UTC)[reply]
  • Why don't those two have the same output? Seems like we've made the initial coding slightly simpler, but made actual use harder. Seems rather stupid to me. --Khajidha (talk) 15:42, 23 January 2020 (UTC)[reply]
  • I don't know the technical reason, but I'm sure it's about the apostrophe having other roles in wikitext markup. I agree the more complicated coding looks better, and I would be surprised if anyone objected to making changes to that. If we do run into such objections (more recent than the 2015 blip that EEng linked), we can consider whether MOS should say it's preferred. Otherwise, leave it alone. Dicklyon (talk) 15:57, 23 January 2020 (UTC)[reply]
  • I concur with EEng that we don't need a rule about it. Whether to do it with or without the apostrophe-s (or just apostrophe for typical plural possessives) inside the colorized link content is really a matter of context. In most cases it won't make any difference, so do whatever you prefer. The simpler markup is always going to outnumber the complex version by a wide margin, simply because it is is simpler. Going around changing it without doing something more substantive in the same edit is likely to be interpreted as a WP:MEATBOT and MOS:RETAIN problem.  — SMcCandlish ☏ ¢ 😼  22:22, 28 January 2020 (UTC)[reply]

Examples

OK:

  • [[Christoph Graupner|Graupner]]'s [[cantata]]s are far more numerous than [[Johann Sebastian Bach|Bach]]'s

Not OK:

  • [[Christoph Graupner|Graupner's]] [[cantata]]s are far more numerous than [[Johann Sebastian Bach|Bach]]'s

OK:

  • [[List of cantatas by Christoph Graupner|Graupner's cantatas]] are far more numerous than [[Johann Sebastian Bach|Bach]]'s

Not OK:

  • [[List of cantatas by Christoph Graupner|Graupner's cantatas]] are far more numerous than [[Johann Sebastian Bach|Bach's]]

OK:

  • [[List of cantatas by Christoph Graupner|Graupner's cantatas]] are far more numerous than [[Bach cantata|Bach's]]

So, [[x|x's]] would generally be a no. Something that reads "x's" as a single link should only link to an article about "something that is associated with x" (and what that "something" is should be clear from the context) not to the article on "x". For clarity: I don't think a new rule is needed while it is no rocket science to see that for practical purposes this is covered by WP:EGG, and often also by WP:SEAOFBLUE. --Francis Schonken (talk) 13:39, 6 February 2020 (UTC)[reply]

More examples

OK:

Not OK:

OK:

Not OK:

As above, [[x|x's]] is generally a bad idea, and no new rule is needed to explain that. --Francis Schonken (talk) 13:59, 6 February 2020 (UTC)[reply]

Type of dash for ranges of hyphenated page numbers

When citng a range of hyphenated page numbers, as in {{cite book|title = IBM System/360 and System/370 I/O Interface Channel to Control Unit Original Equipment Manufacturers' Information|section = Data-Streaming Feature|pages = 3-4–3-7|edition = Tenth|date = February 1988|publisher = IBM|url = http://bitsavers.trailing-edge.com/pdf/ibm/370/channel/GA22-6974-9_360_370_IO_Interface_Channel_to_Control_Unit_OEM_Information_Feb88.pdf%7Cmode = cs2}}, what is the correct form of dash to use within a page number and what is the correct form of dash to separate the first and last page? Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:26, 23 January 2020 (UTC)[reply]

Don't do that. Do this: "pages 3-4 to 3-7".--Srleffler (talk) 19:59, 23 January 2020 (UTC)[reply]
Only IBM could create such a crazy dilemma. EEng 21:39, 23 January 2020 (UTC)[reply]
@Chatul: |pages=3-4&nbsp;– 3-7 (or |pages=3-4{{snd}} 3-7) is probably what you want (the output will be "pp. 3-4 – 3-7"), since it'll be consistent with what is expected in most citation styles, which do not use words like "to" in page ranges. This was already covered in more general terms at MOS:DASH: use a spaced en dash between complex terms that have hyphens in them.  — SMcCandlish ☏ ¢ 😼  21:35, 28 January 2020 (UTC)[reply]
I agree, some form of spaced en-dash looks like the right solution for this to me. —David Eppstein (talk) 21:48, 28 January 2020 (UTC)[reply]
Thanks; I've updated MOS:DASH to reflect this. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:21, 31 January 2020 (UTC)[reply]
I think an unspaced en dash would be just as good, as in "pp. 3-4–3-7". Dicklyon (talk) 06:10, 9 February 2020 (UTC)[reply]

Problematic new syntax for em dash

Is it new? I'm starting to see this syntax cropping up, especially in infoboxes:

August{{--}}November

This renders as August—November, which is wrong. What should intuitively render as an EN dash for ranges (August–November) is showing as an EM dash.

I'm delighted to see, finally, a simpler way for people using Windows keyboards to insert a dash; it approximates the simple system on LaTeX. editors are using this syntax for ranges, with egregious results.

Can anyone shed light on this? Tony (talk) 09:04, 28 January 2020 (UTC)[reply]

Template {{--}} was created in 2006 (and moved to template {{Em dash}} in 2015, turning the old name into a redirect). isaacl (talk) 11:49, 28 January 2020 (UTC)[reply]
The confusing part, to LaTeX users, is that in LaTeX two hyphens (--) creates an en dash, but here it creates an em dash. (In LaTeX, three hyphens create an em dash.) But with such an old template I doubt that trying to change it to be more consistent would be a good idea. —David Eppstein (talk) 21:51, 28 January 2020 (UTC)[reply]
It's nice that the template redir exists, but it's just being used incorrectly here, output the wrong dash character for the use illustrated above. It's using "--" to make an em dash because that's been a typewritten-manuscript convention for over a century; the LaTeX alteration of the convention is kind of an aberration and isn't going to be familiar to people who are not regular users of LaTeX. Anyway, date ranges (like other ranges) call for an en dash, while {{--}} produces an em dash. The en dash character is available in the "Insert" and "Wiki markup" tool sets in the toolbar below the editing window, and can also be entered with &ndash;, and can be entered with {{en dash}}. You can also use any of a number of character-picker tools for Windows, including the built-in Character Map (I've long used PopChar for MacOS, and am told it also exists for Windows). Or just memorize the Windows-specific code (or put a note with the code above your monitor).  — SMcCandlish ☏ ¢ 😼  22:17, 28 January 2020 (UTC)[reply]
If you're using MacOS, why do you need PopChar? Just type option-hyphen or option-shift-hyphen. —David Eppstein (talk) 00:04, 29 January 2020 (UTC)[reply]
I do, but PopChar is great for all sorts of other things like æ, ¡, å, etc., and not everyone would remember opt-hyphen, so they may like to know PopChar exists. It's not freeware, but as shareware goes it's something definitely worth paying for. I've been using that thang for so long it seems like part of the OS itself to me.  — SMcCandlish ☏ ¢ 😼  03:54, 30 January 2020 (UTC)[reply]
Personally, I think it's crazy that we didn't make Template:-- go to en dash and Template:--- to em dash, like in TeX. But that's where we are. I blame Bill Gates, who unlike Don Knuth and Steve Jobs didn't know anything about typography. Dicklyon (talk) 06:12, 9 February 2020 (UTC)[reply]
For what it's worth, only 168 pages link to {{--}}, including a mere 85 in article space, 1 categories, 6 modules, 3 talk, 2 template talk, 39 user (of which 34 are subpages of Grover cleveland, 5 user talk, 14 Wikipedia, and 5 Wikipedia talk. So, should it be desirable to make the change, that's the level of effort that would be involved in fixing up the existing pages referencing it (either checking to see whether an en dash is really what's called for, in which case there would be nothing to do, or an em dash, in which case it could be replaced with {{emdash}}). Largoplazo (talk) 14:17, 9 February 2020 (UTC)[reply]

Verb tense for defunct business unit / brand

Input requested: Should a defunct business unit/brand at a company that still exists be referred to in the present or past tense? In particular, a publisher discontinued one of its imprints (staff terminated/reassigned, no further publications): should the lede read "___ is a discontinued imprint..." or "___ was an imprint..."? See Talk:Vertigo Comics. -Jason A. Quest (talk) 17:22, 30 January 2020 (UTC)[reply]

I thought I'd find consistency with auto articles, but:
Oldsmobile stood alone as a company for a while, so you could argue that facts and circumstances say it should get was, but that's not the case with Plymouth. This does feel like the kind of thing we should get consistency with. Should it be across all brand articles, or should there be separate guidelines for, say, publishing vs. the auto industry? —C.Fred (talk) 20:42, 30 January 2020 (UTC)[reply]
I don't see why there should be different standards for different industries. IMHO, when a company or business unit closes, or when a trademark or brand is no longer being used in the marketplace, it no longer exists in any meaningful sense (i.e. "in the hearts and minds of its fans" doesn't count). The Olds 88 still exists, but the business unit that made it doesn't; that seems like an intuitive, common sense standard to me. It's also how defunct publishing imprints (e.g. Epic Comics, Belmont Books, Epic Soundtrax) seem to be typically handled, but... there is disagreement. -Jason A. Quest (talk) 21:08, 30 January 2020 (UTC)[reply]

I'm not really convinced we need a rule here, but if we did have one, I would lean towards using the present tense as long as any individual items of the brand remain. I think the case for present tense in brands that are still instantiated is at least as strong, and probably stronger, than for long-ended TV shows, and present tense seems to be established there. --Trovatore (talk) 21:12, 30 January 2020 (UTC)[reply]
I always to to do it based on events are past, and non-events are present. The creation of a brand and trademark are events. One that I never was quite sure about is first, as if someone or some company is first, they are always first, but often enough people seem to prefer past. Brand names are not events. I don't know about the rules regarding reuse of a trademark after the original holder closes. Gah4 (talk) 01:15, 31 January 2020 (UTC)[reply]
Also, in the four examples above, the parent company is still operating, and should still claim the trademark. Also, a trademark might be sold to another company when the owner shuts down. Gah4 (talk) 01:18, 31 January 2020 (UTC)[reply]
Especially with brands, that's most of the time trademark, and trademarks do not go away - you can lose them from lack of enforcement or you can wholly say you are abandoning it. (For example, it does appear GM dropped Oldsmobile [4] as a trademark). So for brands, I would normally presume that even if a company said they are done with that brand it should still be considered present tense unless it is clear from something like trademark abandonment that the brand is dead.
Companies that are default should always be past tense.
Tangible objects are a bit trickier. If the object is still out there, not necessarily available as first sale but can be obtained by a member of the public (like the Scion above), that should be present tense but acknowledging the discontinuation/etc. Only if it is known that realistically all produced versions of the object no longer exist outside of museums, etc., and thus not acquirable by the public, then it should be past tense. --Masem (t) 01:26, 31 January 2020 (UTC)[reply]
Just to clarify: trademark protection can just go away by lack of use with no intent to resume usage, without an explicit declaration. The most obvious case would be a company shutting down without selling its assets off, but active companies have abandoned trademarks too. However this doesn't really change any of the analysis regarding verb tense; even if there is no protection for it, the trademark as a brand continues to exist. isaacl (talk) 22:37, 1 February 2020 (UTC)[reply]
  • I would say all of these examples are actually correct. Consider what would happen if we reversed them:
  • Accuracy is the first and overriding concern, consistency between articles is just gravy. Reyk YO! 01:35, 31 January 2020 (UTC)[reply]
    • The issue is "was a defunct" is an awkward construction with an improper sense of time. It implies that it was defunct but no longer is so. And Plymouth is no longer around, which is the problem with using the present tense, as it gives an incorrect status.
    • It seems the difficulty here is that we're conflating two related but distinct things, brands and business units (whether divisions or subsidiaries). In the Oldsmobile example, Oldsmobile wasn't just a brand of GM, but a distinct operating division, a structure GM still has for its four remaining divisions (albeit the divisions are less independent in operations as they were in decades past). So to use the past tense for Oldsmobile is legitimate because it was more than just the brand used on the car but the division of GM that produced it, a division that was shut down and disbanded. Indeed, not using the past tense could give a false impression that the division still exists. The fact that objects (cars) branded with the division's name still exist doesn't change the fact that the division itself does not. Same with Plymouth, which is seen with the misunderstanding here. oknazevad (talk) 02:06, 31 January 2020 (UTC)[reply]
      Well, there's Oldsmobile the division (and former independent company, I guess, though I hadn't known that before), and there's Oldsmobile the brand. I haven't checked which one the Oldsmobile article is primarily about. If it's primarily about the division, then I'd say past tense is fine. If it's primarily about the brand, then I think it should be present tense, as long as there are still Olds cars out there somewhere. --Trovatore (talk) 02:38, 31 January 2020 (UTC)[reply]
I first got into this regarding computers, which got: The PDP-10 is a mainframe computer family manufactured by Digital Equipment Corporation from 1966 into the 1980s. added to MOS:TENSE which was done while I was sitting next to a running PDP-10. In the case of computers, the name usually names a set of computers, defined by a written document. Even if no instances of hardware exist, the documentation that actually defines them exists, and is usually publicly available. In the case of cars, the master plans might not be available, but service manuals are, and likely define the name well enough. For the ones above, I would choose:
WP:NPOV (is there a negative connotation to defunct?)
(mixed tense)
(mixed tense)
(mixed tense)
By separating the name from the production, appropriate tense applies to each. Gah4 (talk) 02:55, 31 January 2020 (UTC)[reply]
Gah4, I think that's pretty good. My only quibble is that the Scion example is not "mixed tense"; "discontinued" is a participle; that is, an adjective; strictly speaking it has no "tense". But that's a side point and doesn't affect the recommendation itself, which I agree with. --Trovatore (talk) 18:36, 31 January 2020 (UTC)[reply]
Just because something that's gone could hypothetically be brought back, doesn't mean we need to accommodate that possibility. I mean, Kirk Douglas' corpse is in fairly good condition, and could be frozen and revived maybe someday, right? But for now, he's dead, which is why his article was immediately changed to past tense. If something that's gone somehow comes back... well, it's a wiki: we can change it then. :) -Jason A. Quest (talk) 03:58, 7 February 2020 (UTC)[reply]

While agreeing that there is no particular need for a rule here, I'd like to suggest the following points in favor of using the simple past tense wherever possible:

  • Brevity: The problem of how to communicate that something is no longer current is one that language-users solved countless millennia ago. "Is a discontinued brand," like "is a defunct newspaper" or "is a former settlement," is pleonastic when "was" does the job just fine. Our readers' attention is a limited resource and we shouldn't squander it with needless words.
  • Clarity: By the same token, "is a [former] X" is frequently bewildering. I had to re-read the first sentence of Ford Model T several times: "The Ford Model T . . . is an automobile produced by Ford Motor Company from October 1, 1908, to May 26, 1927." Perhaps no reader would come away with the impression that the Model T is still in production. But it's still an awfully disorienting way to start an article about a car that's been obsolete for nearly a century.
  • Maintainability: As in the case of the Model T, the "is a [discontinued]" language sounds weirder as time goes by. A rule like the one suggested above, to switch from "is a discontinued" to "was" only when the last known exemplar has been destroyed, would only heighten this problem and create extra work for future editors. We can be reasonably confident that there are going to be Model Ts around for some time to come, and if the last one is destroyed it will be probably get some attention in the press. But with more obscure products it may be difficult or impossible to be sure. (Or to take the example of a newspaper or publisher's imprint, it shouldn't matter whether a single exemplar is buried in an archive somewhere.)
  • Weight: The past is immeasurably vaster than the present and growing all the time. Using the present tense when the context doesn't strictly require it gives undue weight to current events, contrary to our encyclopedic mission.

In sum, I don't think it's a great idea to reinvent the wheel when it comes to expressing the fact that something is no longer current, when the past tense exists for exactly this purpose. To the extent there's tension between an article covering (present) exemplars versus (past) production, a positive-sum solution might be to avoid the copula entirely, and start such articles with something like "The Model T automobile . . . was produced by Ford Motor Company from [date] to [date]." Portions of the article dealing with surviving exemplars as such could still use the present tense, without any appearance of conflict. -- Visviva (talk) 21:48, 31 January 2020 (UTC)[reply]

As above, I got into this discussion regarding computers. A computer architecture is defined in its documentation, which might exist even if no hardware is ever built. It also normally survives, even if all hardware is gone. As for newspapers, even if all the paper copies are destroyed, there are usually microfilm copies around. As to the Model T example, the general rule is that past events are past tense, where the beginning and ending of production are events. And no complaints if anyone wants to rewrite the Scion sentence above. Gah4 (talk) 00:24, 1 February 2020 (UTC)[reply]

Finessing the issue by dropping the copula is not always without merit. I think something like that was used once at Whitechapel murders, where a respected editor was, I thought rather bizarrely, insisting on the present tense, as though the women were being eternally slain.
But in this case I'm not sure it's a good tradeoff to avoid mentioning the Model T being a car in the first sentence. --Trovatore (talk) 20:06, 1 February 2020 (UTC)[reply]
I generally concur with Visviva. As others suggest, though, there's a bit of "it depends" in there. "Former" is especially often misused by people do not think through their sentences: "is a former American newspaper editor ..." – hmmm, so, she renounced her citizenship?  — SMcCandlish ☏ ¢ 😼  17:00, 5 February 2020 (UTC)[reply]
While she may not have renounced her citizenship, maker her a "former American", where "former" is an adjective modifying the noun "American", in the construct "former American newspaper editor" the word "American" is an adjective indicating origin, while "former" is an adjective indicating (relative) age, and in English age comes before origin in a construct with multiple adjectives. See here. So even though it seems illlgical, it is standard English. oknazevad (talk) 03:14, 7 February 2020 (UTC)[reply]
Thoughts on the above:
  • I don't think we're going to change the rule for persons. Present tense for living persons, past tense for the ones who are not so much living as the other thing, is established, and it would be really disruptive to change it. Stanton's example is easily fixed with "is an American former newspaper editor" though my real preference would be to quit using nationality routinely in the first sentence of bios, except maybe bios for which it's extra relevant.
  • I was concerned that Visviva's style didn't inform us that the Model T was a car, but actually I missed it — the suggested sentence was the Model T automobile was produced, which does address that concern. It still doesn't tell us whether it was a car make or brand or company, though.
  • If we adopt this no-copula finesse for defunct cars and comic-book imprints, are we going to do the same thing for I Love Lucy? I do find it a little weird that TV shows are defined in the present tense, no matter how long they've been out of production. There's nothing really logically wrong with it, but it's just not how I find it natural to speak. I don't insist on inter-subject consistency that much, so a possible answer is "that's just how the conventions have evolved in different subject areas of Wikipedia", but I guess I'd like the past-tense supporters to address that point explicitly. --Trovatore (talk) 21:16, 6 February 2020 (UTC)[reply]
  • I think it's common for fictional universes and the things in them to be referred to in the present tense, or at least in the same tense they would be referred to if the book/movie/play/TV show/whatever was brand-new. We say "The two main characters in I Love Lucy are married to each other." We also say "The television show I Love Lucy was a first-run program in the 1950s." On the other hand, we also say "The television show I Love Lucy is available on DVD through major retailers." Confused? Me too. As for businesses, a defunct brand is still defunct, a defunct car company used to produce things but doesn't any more. I don't think we need to force people to choose one or the other across Wikipedia, as long as what is written is accurate and it's not awkward in context. davidwr/(talk)/(contribs) 22:07, 6 February 2020 (UTC)[reply]
  • So first, I agree that we don't need to enforce full 'pedia-wide consistency. However, this discussion arose at the behest of an editor who would like to use past tense consistently for defunct comic-book imprints, and the comparison arose with cars. If we're going that way, I'd like to explore TV shows, where there is a clear convention that is different from what you may think it is.
    Our article on I Love Lucy begins
I'm not sure whether there's a rule for "lost" TV shows, but in general TV shows are defined in present tense in the first sentence of the article. This seems to be a strongly established convention, to the point that changing it would be disruptive.
So I guess I'd like to know, if we were to agree with the original editor on comic-book imprints, what would it imply about TV shows? I don't really like the TV-show convention; I think it comes across as a bit weird. But I also don't think it's worth trying to overrule the editors who work on TV-show articles.
I don't really mind if different subject areas have different conventions, as long as they're defensible and not hugely jarring. But I would like the past-tense proponents in this discussion to say what they think about how, if at all, their reasoning would apply to TV shows. --Trovatore (talk) 22:26, 6 February 2020 (UTC)[reply]
I'm not sure about anybody else, but I see a clear distinction between a creative work that continues to exist even after the active production ends and a defunct company or division of one. I Love Lucy is still around, but Desilu, the studio that made it, is not. So I Love Lucy is a TV series, but Desilu was a television studio. Brands are a bit of a fuzzy case, because in many ways a brand is a trading name for a company, even if the company is differently named, . oknazevad (talk) 03:14, 7 February 2020 (UTC)[reply]
It seems to me that Oldsmobile-the-kind-of-car is "still around" at least to the same extent Lucy is, even if Oldsmobile-the-division-of-GM is not. --Trovatore (talk) 03:26, 7 February 2020 (UTC)[reply]
[Apologies for saying almost the exact same thing, but I'm too lazy to rewrite after an edit conflict.] I see a fairly clear distinction between a piece of media (e.g. Rudolph the Red-Nosed Reindeer) which still exists (and in most cases will continue to exist), and a defunct entity (e.g. Rankin/Bass Productions) which clearly does not exist in any corporeal, legal, or organizational sense. I can show you an old TV program; I can't show you any manifestation (e.g. office, staff, business activity) of the dissolved entity that made it. Likewise with a physical product and the no-longer-extant entity that made it. One is, the other was. It's dead, Jim. -Jason A. Quest (talk) 03:36, 7 February 2020 (UTC)[reply]
I agree for business entities. I think brands/marques/imprints are not like entities. Oldsmobile-the-company is no more; Oldsmobile-the-brand is still around. Not sure you were saying anything different; just clarifying my position. --Trovatore (talk) 06:38, 7 February 2020 (UTC)[reply]
And I guess that's where I differ. I don't consider the brand still around, even if objects built under the brand still exist. A brand tells me who made something, and if the maker no longer exists, then the past tense is proper. There may be a car that is an Oldsmobile sitting in your driveway, but the present tense there is a property of the car, not the brand. Oldsmobile no longer exists, and the past tense is appropriate for them. oknazevad (talk) 10:28, 7 February 2020 (UTC)[reply]
Hmm, no, I don't agree. The brand is the kind of car/whatever. If there's even one car of that kind, then the kind still exists. --Trovatore (talk) 17:25, 7 February 2020 (UTC)[reply]

It occurs to me that I may not have fully explained myself, given that Rudolf the Red-Nosed Reindeer was brought up. I see that as very different from I Love Lucy. That's because Lucy was a series, not an individual work. You can show me an episode of Lucy. If I have the patience for it, you can even show me all the episodes. But that's not the same thing as Lucy the show. The show is, so to speak, a kind of episode, much as Oldsmobile is a kind of car.
My natural inclination is to describe Lucy in the past tense, but I think present tense is defensible. However the same considerations that would yield present tense for Lucy apply with at least the same force to Oldsmobile-the-brand. --Trovatore (talk) 21:04, 7 February 2020 (UTC)[reply]

How to denote a signatory to a treaty who subsequently withdrew from it?

The United Kingdom has left the European Union however it is a signatory to several important treaties of the European Union from which it has subsequently withdrawn. So the question arises: how do we show in articles a country that has signed and ratified a major international treaty but later has withdrawn from the treaty that it helped to not only ratify but draft. The United Kingdom helped draft and ratify the Single European Act of 1986, The Maastricht treaty of 1991, the Amsterdam Treaty of 1997, the Nice Treaty of 2001 and finally the 2007 treaty of Lisbon. These articles need editing to reflect this appropriately. (MOTORAL1987 (talk) 17:56, 2 February 2020 (UTC))[reply]

MOTORAL1987's original idea (which I hoped they would describe here) is to strike out the country that has disavowed the treaty, like this:
The idea seems in some respects quite a good one. Simply to delete the disavowing state would be very Nineteen Eighty Four, it would meddle unacceptably with the historical record. Striking out the state shows that something is not quite right but it means that explanatory text is needed: my own concern is that it could mislead readers into thinking that the state signed but did not ratify, as per the USA and the Kyoto Protocol. Brexit is not the only example: Canada and the United States walked away from the Kyoto treaty. I believe that this is a site-wide issue and shouldn't be left to ad-hoc solutions. Discussion is needed. --Red King (talk) 17:51, 4 February 2020 (UTC)[reply]
I don't understand the issue. A list that follows "The treaty was originally signed by:" never changes. A list that follows "The following countries are currently signatories to the treaty:" does change as signatories come aboard or depart. When Steve Jobs died, we didn't put a line through his name in every article discussing his accomplishments and titles. Largoplazo (talk) 17:58, 4 February 2020 (UTC)[reply]
Agreed with Largoplazo. And misusing strike-through this way looks like vandalism, an error, or a draft article one has stumbled upon.  — SMcCandlish ☏ ¢ 😼 
I didn't like it either and reverted it with the advice that it would need consensus at the MOS level rather than the particular article where it arose. I decided not to prejudice the discussion by getting my objection in first.
I wonder if Largoplazo has hit on the solution by accident: while we most definitely should not censor the historical reality and thus the list of signatories/ratifiers must stand as it happened, there could also be a list of current participants (collapsible!). --Red King (talk) 20:49, 5 February 2020 (UTC)[reply]
There should be some clear distinction. Strikethrough doesn't seem like a great idea, especially by itself -- it's unclear and likely to create various issues with accessibility (see MOS:ACCESS#Text). Making two separate lists sounds like a recipe for Headache Supreme. But in a detailed list with a tabular layout, e.g. the Featured List at List of parties to the Comprehensive Nuclear-Test-Ban Treaty, it should be fairly straightforward to add a note of some kind. It looks like many of the EU treaties have such a list already. The first possibility that pops into mind is to add a note under the ratification date. If that won't create a clear enough visual distinction, perhaps one of the templates at Template:Table cell templates/doc could additionally be used or adapted. If it makes sense in a particular case, perhaps there could even be a separate column for "current status" or the like. But those seem like decisions that could reasonably be made at the article/topic level based on the characteristics of each list. -- Visviva (talk) 21:29, 5 February 2020 (UTC)[reply]
I agree. It was the proposal to use strike-through as an indicator of disavowal that I felt needed to be escalated to an MOS discussion. I think MOTORAL1987 has their answer: there is a strong consensus against the method proposed and the issue should be handled in the body text. I think that closes the topic. --Red King (talk) 22:29, 5 February 2020 (UTC)[reply]
I think the <s> element is the correct element (now--it was deprecated until a couple years ago) to indicate this case. I'm not sure I'm a fan of that, and even if I were, I think I would prefer to see something other than strikeout (perhaps using WP:TemplateStyles in a template). --Izno (talk) 22:48, 5 February 2020 (UTC)[reply]
  • This is an absolutely terrible idea, as many have said. Something like:

-is needed. Johnbod (talk) 02:40, 6 February 2020 (UTC)[reply]

I support Johnbod's proposed solution. Cullen328 Let's discuss it 02:43, 6 February 2020 (UTC)[reply]
Agree with Johnbod, (withdrew 2020) or (withdrawn) are appropriate, striking is definitely not. —DIYeditor (talk) 02:44, 6 February 2020 (UTC)[reply]
Yes, good idea, infinitely preferable to yet another list. --Red King (talk) 10:43, 6 February 2020 (UTC)[reply]
Absolutely. All the best: Rich Farmbrough (the apparently calm and reasonable) 14:11, 9 February 2020 (UTC).[reply]

WP:ALBUM wants to add a topic-specific guideline

Sorry if I'm just too ignorant here but I don't see any formal process for adding a topic-specific section and searching the archives didn't help. What is the formal process to turn Wikipedia:WikiProject Albums/Album article style advice into a part of the MoS? ―Justin (koavf)❤T☮C☺M☯ 23:09, 2 February 2020 (UTC)[reply]

WP:PROPOSAL. {{Proposal}}, and an {{RfC}} when the time comes, probably at WP:VPPRO, "advertised" to WP:VPPOL (or vice versa), and to here, WP:CENT, and where ever else seems relevant. I would strongly suggest some editing passes prior to that. WP:Policy writing is hard, and it's rare for wikiprojects to get the guideline tone correct, the focus narrowed to things that actually need to be explicit rules, without various WP:CREEP chaff, and the actual rule material 100% compatible with existing WP:P&G pages, plus the wording tightened against WP:GAMING by wiki-lawyers. It's been years since the community elevated a WP:PROJPAGE essay to a guideline, so getting it as right as possible before-hand is important.  — SMcCandlish ☏ ¢ 😼  17:15, 5 February 2020 (UTC)[reply]
SMcCandlish, Very helpful, thanks. Did you take a look at this page? If not, would you be willing to give it a first pass to see if it has any outstanding problems from your perspective? Thanks. ―Justin (koavf)❤T☮C☺M☯ 10:41, 13 February 2020 (UTC)[reply]
Yes, but already have one of these overhauls in progress at the rugby union wikiproject. Spread a little thin. :-)  — SMcCandlish ☏ ¢ 😼  13:10, 13 February 2020 (UTC)[reply]

Film subtitles not separated by colon?

Star Trek Into Darkness and Star Trek Beyond really bother me; there is of course no colon in the logo, but it is obvious from the formatting that Into Darkness and Beyond are subtitles. I'm pretty sure when this and similar questions have been asked before the answer was that it was based on the format used on the poster billing block, and yes Star Trek: First Contact does have the same logo format but includes a colon in the billing block. But is that really a good reason to use this really awkward formatting? Moreover, if we are interpreting it as being an intentional move on the filmmakers' part not to format the title on the billing block with a colon (the former film is about a "trek into darkness" and the latter a "trek beyond [something]"), then shouldn't we be following rules for prepositions in headcaps rather than treating the "I" as the first word in a subtitle? Hijiri 88 (聖やや) 14:17, 9 February 2020 (UTC)[reply]

Both of those pages have had contentious article name change discussions which you should review before considering changing them or the advocating for the MOS to change. --Izno (talk) 02:04, 10 February 2020 (UTC)[reply]
Oh, I have no intention of RMing in the immediate future or even necessarily ever; I'm just asking some questions. Hijiri 88 (聖やや) 23:56, 10 February 2020 (UTC)[reply]
We defer to the people who actually create works of art (even commercial films are works of art) in terms of their intentional titling choices (where practical) instead of imposing pedantic rules that are being intentionally flouted by the creators. It's their work to title, not ours. oknazevad (talk) 06:47, 10 February 2020 (UTC)[reply]
@Oknazevad: What about Talk:My Darling Is a Foreigner#Title? As a translator in Japan I can say with confidence that most Japanese artists can safely be assumed not to have intent when it comes to "titling their works in English", since the English lettering that appears on the covers, but MDiaF is something of an exception given that the author's native English-speaking husband was by necessity almost certainly consulted on various aspects of the work, and if the title formatting was anachronistic in the way a lot of such works in Japan are, he would have noticed.
Anyway, is it fair to assume intent one way or the other lacking a reliable source that says as much? A billing block lacking a colon is hardly a reliable source for the claim that the filmmakers intended to disregard normal titling conventions, and that interpretation would appear to be contradicted by the much more visible film logo that makes it look like a subtitle.
Hijiri 88 (聖やや) 23:56, 10 February 2020 (UTC)[reply]
Of course, we wouldn't draw our own conclusions about intent, as that would be a form of WP:OR, but given an interview or other reliable reporting which clearly states it, there's no good reason not to respect the intent of the creators. In the case of Star Trek Into Darkness, the play on words has been stated as intentional by the director and is not a technical issue with regards to the title as part of the article URL, so there is no reason not to use that styling. And poster billing blocks are actually very regulated by contracts that govern them (for US films it's the title officially registered with the MPAA) so although capitalization cannot be determined from that alone because they're always written in all caps, punctuation can be and the omission of the colon for STID in that overrides the styling of the logo. And to follow creator intent does not violate NPOV as some have claimed; indeed, not doing such is pushing a POV of hostility to creators of commercial works that has no place in this encyclopedia. oknazevad (talk) 04:25, 11 February 2020 (UTC)[reply]
Maybe so, but we don't know why they registered a particular title with the MPAA or whether there were bizarre reasons not to include the colon. It has since come to my intention that the producers made the argument publicly that Star Trek Into Darkness was a deliberate pun, but if we assume that the poster billing block is "word of god", then shouldn't we move Star Trek: Nemesis to the official title used on the billing block?
It seems to me like films in a particular series that were released after Wikipedia became the juggernaut it is today adhere strictly to poster blocking to appease the large swath of Wikipedia editors who only edit articles on contemporary Hollywood blockbusters and can't agree on anything, while films in the same series whose poster titles are formatted the same way but were released before c2005 are made to conform to Wikipedia's normal style guidelines. (Yeah, I'm sure official sources could be found that say "Star Trek Nemesis" was a deliberate pun...)
Hijiri 88 (聖やや) 01:37, 12 February 2020 (UTC)[reply]
See this note: Wikipedia:Manual_of_Style/Titles#cite_note-5 WanderingWanda (talk) 09:00, 10 February 2020 (UTC)[reply]
Huh. I can hardly be blamed for assuming I wouldn't find a specific answer to one of my questions inscribed in the guideline itself. Thanks! :D Hijiri 88 (聖やや) 23:56, 10 February 2020 (UTC)[reply]
Well, wouldn't that make Star Trek Nemesis the enemy of the franchise?
It was! —SmokeyJoe (talk) 13:09, 12 February 2020 (UTC)[reply]
  • Yep. Some of these titles are intentionally without a colon. We generally know this is the case when we can find sources that say so. The one title I'm aware of where we're doing the wrong thing simply to mimic the logo is Spider-Man: Far From Home with a capitalized "From". The RM about that incorrectly supposed that because journalism sources virtually always capitalize "From" in any title [they nearly universally follow the four-letter rule, while WP and other non-news publishers usually use a five-letter prepositions rule, except high-academic sources mostly don't capitalize even long prepositions like "toward"] that WP was somehow also required to. It's cherry-picking to only consider sources that have a predetermined house rule to use "From", with no relevance to that film in particular. [sigh] I don't buy the billing-block argument (by itself), because that's simply WP:OFFICIALNAME. We have to consider what sources are doing, whether the sources have an innate house-style bias against what WP would do, what the billing-block legalese says, what academic (e.g. film journal) material does, what the official website is doing, whether the title card and the poster and DVD cover agree, what the press materials use, whether even entertainment journalism is consistent on it, and if so whether that's consistent with other journalism and with non-journalism sources, and etc. Considering it all, it is usually pretty easy to come to a conclusion on whether something is a subtitle. Even when we've done that, there is no reason to vary from what MoS would do capitalization-wise, unless other sources that don't have the four-letter rule are also capitalizing it. Thus Star Trek Into Darkness, because the title is both serving as a phrase about a dangerous space journey and also serving as a title and subtitle, so the the extent it's the latter (i.e., is Star Trek: Into Darkness without the colon), "Into" would be capitalized anyway. Not so with the Spider-Man movie. But, going and trying to RM that one again is time poorly spent. It probably will not work yet, and it will just be a lot of venting about trivia. After a bunch of film journals have covered the movie, and are not writing "From", then we have proof of division on the matter in the sources thus for following MOS:CAPS rule no. 1: not capitalize when sources aren't almost entirely consistent in doing so.  — SMcCandlish ☏ ¢ 😼  21:44, 13 February 2020 (UTC)[reply]
I support going soft on the 4-letter to 5 letter preposition rule, because it smells of being an artificial distinction. Sticking to artificial distinctions hurts one's credibility.
Support recognizing justifications based on double meanings, even if shallow and unclear. Support allowing custom capitalizations based on half-baked arguments that the capitalization affects the meaning.
MOS:CAPS rule no. 1: "not capitalize when sources aren't almost entirely consistent in doing so" implies: "do capitalize when sources are almost entirely consistent in doing so". --SmokeyJoe (talk) 04:15, 14 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,[5] 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]

Center-aligned captions

Some of the folks at WP:Wikiproject Military history have been using centering markup on captions in their articles (which looks very odd to me, and complicates the source). A discussion at Wikipedia_talk:WikiProject_Military_history#Centered_captions concluded as "inconclusive" as to whether this idiosyncratic markup used only in that project was consistent with WP style. Can we discuss that here? Should MOS say something about adding formatting tags that override normal style as set in the selected skin? Dicklyon (talk) 04:02, 12 February 2020 (UTC)[reply]

It definitely should, but I would leave this alone for a month or so, to avoid "style debate fatigue" on the part of the editorship. Then RfC it here, with notice at WP:VPPOL, WT:MOSACCESS, WT:MOSIMAGE, Help_talk:Image, WT:Image, WT:IMAGEPOL, and anywhere else relevant, as a general matter. That was probably bound to come out as "no consensus" over there, because it was incorrectly pitched as a MILHIST-specific question (to MILHIST, as if seeking to have a territorial finger-pointing session), when it doesn't have anything to do with any particular wikiproject or subject. I've seen the same kind of centering done in occasionally in many other topics, and it is not consistently or even commonly done in that topic, so it's simply editorial idiosyncrasy. I see it as basically a WP:NOTWEBHOST issue, in a sense: WP doesn't exist for people to experiment with website design, or to override what the software and our consensus-built stylesheets are doing just so one can project one's own subjective vision of "the best" layout choices.  — SMcCandlish ☏ ¢ 😼  21:04, 13 February 2020 (UTC)[reply]
It's annoying that it's basically one editor's preferred style, and in the discussion at the project, the project members just say they don't mind. He did this on dozens of articles in Feb. 2013, with misleading edit summaries as if someone had decided that centering was correct and normal was an error; here are some of the diffs with edit summaries:
But it can wait. Dicklyon (talk) 04:35, 15 February 2020 (UTC)[reply]
MOS:CAPTION couldn't be clearer: "The text of captions should not be specially formatted, except in ways that would apply if it occurred in the main text (e.g., italics for the Latin name of a species)", and I don't see anyone centering bits of prose. – Finnusertop (talk ⋅ contribs) 18:32, 17 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]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia_talk:Manual_of_Style&oldid=941788793"