Wikipedia talk:Manual of Style

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Frequently asked questions (FAQ)
Wikipedia's Manual of Style contains some conventions that differ from those in some other, well-known style guides and from what is often taught in schools. Wikipedia's editors have discussed these conventions in great detail and have reached consensus that these conventions serve our purposes best. New contributors are advised to check the FAQ and the archives to see if their concern has already been discussed.

Information.svg To view an answer to a question, click the [show] link to the right of the question.

Why does the Manual of Style recommend straight (keyboard-style) instead of curly (typographic) quotation marks and apostrophes (i.e., the characters " and ', instead of , , , and )?
Users may only know how to type in straight quotes (such as " and ') when searching for text within a page or when editing. Not all Web browsers find curly quotes when users type straight quotes in search strings.
Why does the Manual of Style recommend logical quotation?
This system is preferred because Wikipedia, as an international and electronic encyclopedia, has specific needs better addressed by logical quotation than by the other styles, despite them being more frequent in externally published style guides. These include the distinct typesetters' style (often called American though not limited to the US), and the various British/Commonwealth styles, which are superficially similar to logical quotation but have some characteristics of typesetters' style. Logical quotation is more in keeping with the principle of minimal change to quotations, and is less prone to misquotation, ambiguity, and the introduction of errors in subsequent editing, than the alternatives. Logical quotation was adopted in 2005, and has been the subject of perennial debate that has not changed this consensus.
Why does the Manual of Style differentiate the hyphen (-), en dash (), em dash (), and minus sign ()?
Appropriate use of hyphens and dashes is as much a part of literate, easy-to-read writing as are correct spelling and capitalization. The "Insert" editing tools directly below the Wikipedia editing window provide immediate access to all these characters.
Why doesn't the Manual of Style always follow specialized practice?
Although Wikipedia contains some highly technical content, it is written for a general audience. While specialized publications in a field, such as academic journals, are excellent sources for facts, they are not always the best sources for or examples of how to present those facts to non-experts. When adopting style recommendations from external sources, the Manual of Style incorporates a substantial number of practices from technical standards and field-specific academic style guides; however, Wikipedia defaults to preferring general-audience sources on style, especially when a specialized preference may conflict with most readers' expectations, and when different disciplines use conflicting styles.
WikiProject Manual of Style
WikiProject iconThis page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.
 

Style discussions elsewhere[edit]

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[edit]

(newest on top)

Concluded[edit]

Extended content

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

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)

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)

Specific proposals[edit]

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

  • 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)

Survey[edit]

  • 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)
    • The original proposal 1 was renumbered as 1A. I nevertheless object to anyone rewriting a signed individual statement of mine, as Herostratus did here and below. WP:TPO is relevant here. DES (talk)DESiegel Contribs 15:58, 29 December 2019 (UTC)
  • 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)
    • Template documentation exists for a reason, and will explain the differential output.  — SMcCandlish ¢ 😼  07:49, 2 January 2020 (UTC)
  • 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)
    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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • Strongly Oppose any of proposal 2–A or B: MoS is just fine. GenQuest "Talk to Me" 14:46, 30 December 2019 (UTC)
  • 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)
  • Support 1A, Oppose both 2A and 2B - Ealdgyth - Talk 17:51, 30 December 2019 (UTC)
  • Support proposal 1A, agree with what GenQuest and other have said. MB 18:19, 30 December 2019 (UTC)
  • 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)
  • Support 1C per MOS.--Srleffler (talk) 22:40, 31 December 2019 (UTC)
  • 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)
  • 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)
    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)
    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)
    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)
    @Coolcaesar: The "reasons described by Herostratus" are demonstrably wrong.  — SMcCandlish ¢ 😼  08:18, 2 January 2020 (UTC)
  • 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 Template: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)
  • 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)
  • 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)
    @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)
    @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)
    "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)
  • Support 1A. These big quote marks do not match other elements of our house style for articles. Sandstein 16:21, 2 January 2020 (UTC)
  • 1A now and actually not 1b or 1c. Just silently pass through the parameters. --Izno (talk) 16:42, 2 January 2020 (UTC)
    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)
  • 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)
  • 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)
  • 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)
  • Oppose 2A and 2BSupport 1A – best to continue to work toward phasing out the big decorative quote marks. Dicklyon (talk) 02:37, 6 January 2020 (UTC)
  • 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)
  • 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)
  • 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)
    "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)
  • 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)
    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)
    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)
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)
  • 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)
  • 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)
  • 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)

Threaded discussions[edit]

Threaded discussion re merits of the proposals[edit]

  • 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)
  • 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)

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)

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)

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)

  • 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)
    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 lead to a lower-casing shift that took another 4+ years to resolve and clean up in the mainspace, after intense levels 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)
  • 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)
    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)
    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)
  • 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)
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)

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

  • There's currently a proposal 1A listed, but it looks identical to #1B, and the sandbox and such are red links. What's supposed to be here? –Deacon Vorbis (carbon • videos) 00:34, 29 December 2019 (UTC)
    Proposal 3 is a late suggestion. It is essentially a combination of 1A and 1B. I will have the sandbox template and test cases up and working shortly. DES (talk)DESiegel Contribs 00:37, 29 December 2019 (UTC)
The examples for proposal 3 are now working. DES (talk)DESiegel Contribs 00:52, 29 December 2019 (UTC)
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)
@Deacon Vorbis: DES (talk)DESiegel Contribs 00:53, 29 December 2019 (UTC)
  • See also recent discussion at Template talk:Cquote § Proposed changes re .7Bcquote.7D and subsections under that. DES (talk)DESiegel Contribs 00:55, 29 December 2019 (UTC)
  • Do I see correctly that there are only 9 transclusions in the article namespace right now? --Bsherr (talk) 03:51, 29 December 2019 (UTC)
    You do not, Bsherr. What links here showing only transclusions for article space, shows it used on over 16,000 articles (32 pages of 500 plus a partial page) counted just now. X!tools shows a transclusion count over 39,000, but I think that includes all namespaces. I have myself edited to remove it on more than 20 articles, just as examples. DES (talk)DESiegel Contribs 04:31, 29 December 2019 (UTC)
    The monthly report linked in the sub-section below shows Page count: 16069; Transclusion count: 24168 DES (talk)DESiegel Contribs 04:35, 29 December 2019 (UTC)
    Ah, I see my misstep. Thanks. --Bsherr (talk) 04:44, 29 December 2019 (UTC)
  • I could wish, Herostratus that you had just added proposals, not renumbered existing ones, to which Bsherr and Galobtter had already refereed to by number, not to mention myself. Wouldn't they have done as well as just 4 and 5? In any case I ask any eventual closer to note that those comments, if not later revised by their authors, refer to what is now listed as 1B and 1C. DES (talk)DESiegel Contribs 14:54, 29 December 2019 (UTC)
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)
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)
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)
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)
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)
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)
Template mechanics[edit]

(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 Face-sad.svg. 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)

  • 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)
  • 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)
    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)
    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)
  • 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)

Using "British" vs "English" to describe a person/company/work[edit]

I've run into a fair question from a relatively new user and though I understand the core complaint, I thought we had guidance on this.

The case is in point is for several articles related to video game studios in London or the England part of the UK (as opposed to Scotland, Wales, or Northern Ireland). Generally, in such cases, I have seen these called "British", but this user believes it should be called an "English" studio as to designate that it sits in England rather that anywhere in the UK.

There is a clear inconsistency on WP spot checking around: bios tend to use "English" where things like films, TV shows, companies, may likely use "British".

My question is if this is spelled out somewhere in the MOS explicitly, and if not, should we be more explicit about it? --Masem (t) 03:40, 2 January 2020 (UTC)

Hmm. Well, the ethno-cultural sense of a nation and nationality makes sense in a biographical context, and may also in various other contexts, such as cultural output. That will often be a factor in a TV show or film and maybe even a video game, but is not likely to matter when it comes to, say, calculator software, or manufacture of car parts. If we're consistently describing all things in/from Scotland as Scottish and all things in/from Wales as Welsh, even if there's no culture-related reason for it, then we should do the same with things in/from England with the designation English. But only a) if we're sure we want to be doing this with Scotland and Wales, and b) only for article subjects essentially confined to that jurisdiction (if a company has offices in England and Scotland, then call it British; if it's a product used all the time all over the UK (e.g. HP Sauce), then call it British even if the manufacturer's HQ is in England). That's my initial take on the matter. It's always been left to editorial discretion (and I can recall sporadic edit-warring about it at various topics), but if it's leading to a confusing level of inconsistency, or to protracted, cyclical editorial conflicts, then we might need to address it.  — SMcCandlish ¢ 😼  07:07, 2 January 2020 (UTC)
Masem, you are probably thinking of this essay which I have saved somewhere. Its a handy guide for *people* but not really applicable to companies, except where you may have some strong national ties in a similar way to people. I'm thinking in the food and drink area, or anything else thats region specific. Describing scotch producers as 'British' companies, while technically correct, would be wrong. But otherwise, just being located somewhere specific doesnt merit an 'English/Scottish/Welsh' label, unless there is a reason for that label. Functionally, UK companies are registered at companies house as a British company. But biographies of people will have a much easier time of identifying a national preference. Only in death does duty end (talk) 07:34, 2 January 2020 (UTC)
This makes sense, in that at least for companies, we are talking their place of registration, which can only be the UK, and I can see how that can then distinguish from people where the nationality is a different factor (wholly separate matter, I see the new RFC on infoboxes and nationality that is tied to this for people). --Masem (t) 15:28, 2 January 2020 (UTC)
The United Kingdom is a single sovereign country, and the registration of all UK companies is handled by Companies House[4]. However, due to the complex history and relationship between the UK's four constituent countries, there are three separate company registers maintained: one for companies in England and Wales which operate under English law, one for companies in Scotland which operate under Scottish law, and one for companies in Northern Ireland which operate under Northern Irish law. Whichever register a company appears in though, they are all ultimately British Companies in the international context, as the UK is the only sovereign country that contains them. -- DeFacto (talk). 10:20, 2 January 2020 (UTC)
That we use English, Scottish, Welsh, Northern Irish, Irish instead of the proper British for UK-related articles, simply annoys me to no end. This special treatment isn't given for articles related to other sovereign states. GoodDay (talk) 15:43, 2 January 2020 (UTC)
Well, most other sovereign states don't consistent of "constituent countries" with varying degrees of sovereignty rights retained. Even the "states" of the United States (and various other countries with "states" or cognates, like the estados of Mexico) do not mean state in the classic sense. The US states retain some limited rights of self-governance on various things, but they're really unlike, say, Scotland within the UK. The UK is just unusual, and in more than one relevant way. E.g., Northern Ireland is part of the UK, but is not part of [Great] Britain, so it's not British except in strained, extenuated senses, in about the same way Puerto Rico "is" American (though at least PR has its own flag, and isn't being claimed by another nation-state). But N.Irl. also isn't like Wales and Scotland nor even politically extinct Cornwall, in being a former nation and in various (especially cultural) respects still treated as one; it's simply territory occupied from another nation-state, and culturally more attuned to that one in many ways. Anyway, we have WP:POV and WP:ABOUTSELF issue, in that various "British" people don't identify as such but as something more specific, and may have deep-seated, even defining, socio-political rationales for it. It's not WP's job to tell them they're wrong. (Same goes for, say, a Scot who firmly self-identifies as British rather than Scottish.) I don't think consistency is going to be possible, so the question is probably what the default should be (just British, or the more specific terms?).  — SMcCandlish ¢ 😼  15:59, 2 January 2020 (UTC)
A little off-topic, but I actually think that's pretty much exactly incorrect as regards US states. US states don't have "some limited rights of self-governance"; they are the primary jurisdiction for most individual-on-individual issues. --Trovatore (talk) 20:11, 3 January 2020 (UTC)
I would have agreed with that in, say, 1940. The US federal government has turned into a behemoth in the interim, and overrules state law all over the place.  — SMcCandlish ¢ 😼  00:17, 6 January 2020 (UTC)
Note: Essentially the same issues were recently raised at Wikipedia talk:Manual of Style/Biography#Nationality of people from UK, and at Wikipedia talk:Nationality of people from the United Kingdom. I've directed both to this discussion in an effort to centralize, per WP:TALKFORK.  — SMcCandlish ¢ 😼  15:59, 2 January 2020 (UTC)
As I've posted. I'm annoyed by the special treatment for the UK-related articles. GoodDay (talk) 16:24, 2 January 2020 (UTC)
I would say the idea that it constitutes special treatment is mistaken, although I can see how it would appear like that. The relationships between personal identity, sovereign states and constituent sub-national entities are just more complicated in Europe than in most of the Anglophone world outside of the UK. Because this is the English-language Wikipedia, with coverage (and contributors) naturally skewed towards Anglophone countries, the UK stands out like a special case in this regard when compared to countries with a more settled and perhaps less knotty set of identities. If instead you compare us with continental European contexts you will see the same issues arising all over the place -- Catalans, Basques, Serbs, Croats (who never accepted being Yugoslavs), people who were born in Poland but are now Ukrainian, Greeks whose families lived in Turkey, and so on. The policies we adopt should reflect this reality, as indeed do the sources which we base our work on. FrankP (talk) 17:12, 2 January 2020 (UTC)
This situation is a bit complicated. My question is: Does the use of "English" in terms of location come across the same way to all other english-speaking regions? There is such a thing as Italian (language) and Italian (originate from Italy) same with Spanish, and French. There is Irish, and Scottish as well. Or is there a way to avoid using the word "English" in terms of geographic origin and instead use another sentence structure. For example "From England".Blue Pumpkin Pie Chat Contribs 17:41, 2 January 2020 (UTC)
I would say that to describe an organisation as English would tend to emphasise its Englishness more than to say it is based in England. One of the game studio articles mentioned by the OP begins "Rockstar London Limited is a British video game developer and a studio of Rockstar Games based in London, England". That seems to me to get it about right. FrankP (talk) 14:31, 3 January 2020 (UTC)
Though we don’t usually tell our readers that London is in England. EEng 16:03, 3 January 2020 (UTC)
To be fair, London is in Canada (Ontario, to be precise.) SportingFlyer T·C 14:14, 6 January 2020 (UTC)
  • Yes, we will just have to add this to the long list of things that annoy GoodDay. Some here may not be aware that there is or a has been a small but dedicated band of editors who go round changing British to Scottish whenever there is the slighest excuse, no doubt muttering lines from Braveheart as they go. Johnbod (talk) 20:02, 3 January 2020 (UTC)
I don't think so; Mel Gibson is an Australian.--Jack Upland (talk) 21:39, 4 January 2020 (UTC)
I suppose (to be generous) you've never seen the film. His character William Wallace is Scottish; very much so. Johnbod (talk) 01:23, 5 January 2020 (UTC)
We really need to get rid of the nationalist "language territory staking" templates like "This article is written in Scottish English". I've said before that we probably only need Commonwealth English, US English, and Canadian English, since there are only three dialects with multiple reputably published style guides, and most of the Commonwealth uses the British ones. There's virtually no difference in an encyclopedic register between most variants of the Commonwealth English dialect continuum.  — SMcCandlish ¢ 😼  00:21, 6 January 2020 (UTC)
This is a red herring - I don't believe any editors have ever attempted to tag for "Scottish English". But Scottish editors have been very agressive, at least in the past, in changing "British" to "Scottish" in first lines and infoboxes, and setting-up Scottish categories for people - Category:British scientists has 38 sub-cats, while its sub Category:Scottish scientists has 34 (the Welsh have 19, and N Ireland only 10; 35 for English). User:Mais oui! was one of the most energetic and combative, but now retired "as of February 2018 due to bullying by rogue admin over many years", his user page says. To see how much actual "Scottish English" WP contains, this search is useful. Johnbod (talk) 13:52, 6 January 2020 (UTC)
Agreed. British English and American English cover the major differences.. As an Australian I would support that, even if it means saying "lorry" when I want to say "truck". At least I get to spell "colour" with a "u". Fragmenting into dozens of specific countries is just asking for nationalistic arguments that really aren't helpful.  Stepho  talk  10:25, 6 January 2020 (UTC)
Honestly, this is something that is difficult to coherently codify in MoS. A company that soley operates in England can be English or British. In general, for companies we should default to British unless the company or highly reliable sources say explictly otherwise. In regards, to people that is an entirely different situation in which it should be determined from page-to-page consensus. One example I have found is that article related to politians usually favour British over English/Welsh (although Scotland seems to favour Scottish, Northern Ireland is a bit more complicated, related pages: England, Wales, Scotland Northern Ireland). However articles related to actors favour "English/Welsh/Scottish/Northern Irish" over "British" (Examples: 1, 2, 3, 4, 5, 6, 7, 8. This has also been noted at Wikipedia talk:WikiProject Companies.  Spy-cicle💥  Talk? 21:32, 4 January 2020 (UTC)
  • There are almost no cases when it's problematic to describe someone as "British" when "English" would have been a possibility. It's not wrong, but nor is it a necessity. GoodDay will just have to resign themselves to this.
There are certainly problem areas on WP within the "British" scope. Ireland or Northern Ireland is an obvious one, and worse for some periods of history than others. Anglo-Irish is one which WP persists in getting wrong. Scottish much less so, rarely contentious on WP, as Scottish is accepted here as distinct. Cornish has been a problem in the past as WP doesn't recognise this as a distinct group. Wales is largely a problem of inaccuracy, and WP tends to keep describing subjects like Lloyd George or Julian Cope as "welsh" although neither are.
For companies, it's English, Scottish or Northern Irish. Wales comes under England. Andy Dingley (talk) 22:15, 4 January 2020 (UTC)
It is actually very simple. If something is good, positive and to be proud of it is British; if to the contrary, English. However in Scotland or Wales if it is good it is Scottish/Welsh, otherwise British. ;-) Martin of Sheffield (talk) 22:16, 4 January 2020 (UTC)
You're right it should be simple. I can offer a slight correction though: if it's bad, evil and imperialistic, it's English. If it's inventive, radical and original, it's Scottish Irish or Welsh, as appropriate. If it's undeniably good, but can't be sensibly assigned to any of the outlying nations, let's call it British. ;-) FrankP (talk) 00:35, 5 January 2020 (UTC)
If its tail is missing or it has four horns instead of two, then it's Manx. :-)  — SMcCandlish ¢ 😼  00:26, 6 January 2020 (UTC)
  • Truly there's nothing which WP won't edit-war over. On SS Nomadic, trying to put 1911 Belfast into Ireland. Andy Dingley (talk) 22:25, 4 January 2020 (UTC)
  • I don't really care which term is used. The union is entering its final phase, anyway, after which we'll be using "English", "Welsh", and "Scottish". Tony (talk) 02:39, 5 January 2020 (UTC)
  • When there's more than one perfectly reasonable option, just leave whichever one has been chosen. Dicklyon (talk) 23:51, 5 January 2020 (UTC)
  • I'd have to agree with the above. The situation with terminology of nationality in the UK/British Isles in general is complex and not something that aligns to simple solutions that may work for other countries. The UK gets a unique treatment because its political and historical context is unique, and like what Dicklyon said, there's no reason to change between British and English in situations where both or either are correct. That's the guidance at WP:ENGVAR (don't arbitrarily change between two functionally equivalent terms) and I think that works well here. If someone could be described as both English or British, and the article uses only one of those terms already, default to just keeping that, excepting in rare cases where a person may demonstrated NOT self-identify as one or the other (for example, some English nationalists may not self-identify as British, and it would be inappropriate to use such terms to describe them). However, for the vast majority of cases where one could use both terms, use either and stick to the initial choice. --Jayron32 15:01, 6 January 2020 (UTC)
There does seem however to be some useful advice I could pick up from the above:
  • Unless the nationality is a defining factor for the entity (to not describe Monty Python as British would be omitting a key detail of the group), try to avoid the nationality and instead establish the nationality via location. "X is a British game studio..." can be written as "X is a game studio based in London."
  • There probably should be something akin to DATERET for this - switching between British and English/Welsh/Scottish should not be done without consensus discussion. (Obviously, completely inappropriate labels should be fixed. An Amercian actor that moves to Scotland suddenly should not be labeled a "Scottish actor".)
  • Follow RSes if there's a question of which term to use, with a bit more weight given to non-British/English/Welsh/Scottish sources.
I don't know if we need to codify these but they seem consistent with the above. --Masem (t) 15:10, 6 January 2020 (UTC)
I think those are really good guidelines, but still the "don't fight over it" is the best guidance. The whole "is it a defining characteristic" is good guidance, but there are far too many editors for whom national/ethnic/racial identity is the most important thing one can say about a person, and will fight tooth-and-nail over the issue. The other point about rephrasing to avoid controversy ("John Doe is a British/English footballer" would be written as "John Doe is a footballer from the United Kingdom" or "John Doe is a footballer born in London") is probably the best advice where there is likely to be controversy. --Jayron32 18:46, 6 January 2020 (UTC)
I like the first of Masem's trio, and it's something we've concluded before. I remember an RfC or something more than a decade ago that went something like "Labeling the Beatles English rather than British dwells inappropriately on location", i.e. it mis-stresses "were an English band", not "were a band who happen to have been British and got started in Liverpool, established firmly in Hamburg, and [... more context here]". The "English" bit implies an English nationalism that doesn't exist within their music, fandom, and critical reception. An even better example might be the Pogues, a culturally Irish band who were nevertheless founded and mostly based in England; calling them English or Irish as a "nationality" matter would be misleading and confusing; their complex relationship to both countries should be covered in the lead paragraph with sufficient context, not over-simplified in either an infobox or the lead sentence with a misleading lack of specifics. I disagree with the second of Masem's points; in practice, all the *VAR guidelines have been problematic in leading to WP:OWN / WP:VESTED problems that interfere with exercise of the WP:EDITING policy. It's actually not really permissible under policy for a guideline to effectively forbid editing without prior permission of a page's watchlisters. At most, some slight discouragement of making such changes without establishing a consensus for them first might be okay, but ... Nah. It's just too often misinterpreted as "whoever got here first has the final say", no matter how many times we rejigger the *VAR guidelines' wording to discourage that misinterpretation. And we already have MOS:STYLERET as a general point that covers this kind of case, too. I agree with Masem's third point, but it's just how WP works (follow the sources, and don't cherry-pick biased ones), so we don't need to re-state it for one tiny style peccadillo. MoS is over-long already, so we should resist adding redundant points to it.  — SMcCandlish ¢ 😼  23:27, 8 January 2020 (UTC)
Point #2 is meant to stop stupid edit wars, which, while normally WP:EW should imply, may help with nationality debates and point editors to look at past consensus before making such changes. Case in point is that Father Ted has been constantly edited to try make it a "British-Irish" program, where in fact the show was entirely made by British writers and production, but was "set" in Ireland and had Irish actors. A similar facet goes to many films where there are a combination of different production companies on it that some take to mean that suddenly the film is a multi-national film because of that (eg I've seen ppl try to call Hot Fuzz a British-French film, only because one French production company is involved). I agree we don't need to create a new RET shortcut here, but I would think adding some advice to not just mechanically change the nationality of a work without checking past consensus is sorta needed. --Masem (t) 23:39, 8 January 2020 (UTC)
I could buy this, but I think it should be integrated into MOS:TV and MOS:FILM, since it's primarily a works issue, not an every-topic issue. When it comes up for bios, it's rarely problematic for long, and gets settled rather firmly on a case-by-case basis (e.g. for Joyce, as previously mentioned). The general principle to be clear in the text while avoiding over-simplified infobox parameters is probably more valuable as a broad instruction (and is more of "do edit" than a "don't" instruction). An example worth mentioning might be Lynette Horsburgh, who was born in England and lives there and works her day job there, but is the child of two Scots, calls herself Scottish, and plays international snooker, pool, and billiards professionally and as an amateur (in different disciplines) for Scotland, only. The lead is clear enough to establish context (and she is Scottish-English for encyclopedic purpose, while a film with 5% French involvement shouldn't be described as Franco-British); meanwhile, the body goes into the details of her connections to Scotland and England, and the infobox only has |sport-country=Scotland without getting into any nationality/citizenship stuff that really has nothing to do with the subject's notability, only her private life.  — SMcCandlish ¢ 😼  15:37, 14 January 2020 (UTC)
If anything, the advice at the top level could be something like "Please refer to the appropriate Wikiproject for advice of how to address nationality when discussing a person, work, entity, or other facet. Appropriate MOS include (list here). Editors should be aware that these guidance on reporting nationality have come from years of consensus-building, and editors are cautioned about changing the nationality against these guidance without achieving consensus first." or something to that degree. --Masem (t) 15:42, 14 January 2020 (UTC)

This 'unique' treatment for the UK bios, also effects the Year of X articles. In those articles, the terms English, Scottish, Welsh & Irish are used, instead of British. GoodDay (talk) 23:43, 8 January 2020 (UTC) For the sake of having something comparable to compare to, let's look at the Kingdom of the Netherlands, which consists of four constituent countries: Netherlands, Aruba, Curaçao, and Sint Maarten. Every person but the one listed at Category:Sint Maarten sportspeople stubs is identified in their respective articles as a Sint Maartener—and the one exception is identified as Curaçaoan. In contrast, a variety of treatments are applied to the people listed at Category:Aruban musicians, including "Aruban", "Dutch", and "Aruban-Dutch". Might it be, though, that the "Dutch" ones were from European families recently resident in Aruba, rather than from generations of Arubans? Largoplazo (talk) 00:05, 9 January 2020 (UTC)

To convey the most information most concisely, I'd lean toward using the most specific term (English, Welsh, Northern Irish, Scottish, and maybe even Cornish) when doing so is uncomplicated. All five have a language and ethnic identity associated with them that corresponds to political boundaries and for the first four their own legal systems (Wales now has a parliament and Welsh law is diverging over time even though it's part of England and Wales). A lot of Americans don't realize that Wales and Scotland are separate from England, because in the U.S. "England" and "Britain" are treated somewhat carelessly as synonyms, so I think being specific would be educational for a lot of readers. "British" is a good term to use when more than one constituent country is involved (whether due to moving or widespread presence or diversity of ethnicity vs. residence or referring to multiple entities from different constituent countries, or whatever), or the specific constituent country is unclear. (And obviously it would be good to explain the complications.) I've had some experience doing automated processing of how people write international addresses. In general, I accept the four constituent countries of the UK as top-level country names (even though under the hood I would normalize everything to something like London, England, UK or San Juan, Puerto Rico, United States) plus anything that has an ISO 3166-1 country code. (That the UK has a single ISO code is probably a quirk of customs law, which may change in the near future if Northern Ireland is moved outside the main UK customs territory.) To be consistent with that rule, that would mean using specific terms when talking about Arbua, Greenland, and Puerto Rico, but not California or Quebec or Catalonia or Assam. (California doesn't have its own ethnolinguistic group and companies there are usually incorporated in Delaware; Quebec and Catalonia and Assam have ethnolingustic and jurisdictional alignment, but Canada and Spain and India can't be completely divided up into such units like the UK can. Though I'd be open to using specific terms in prose for those cases as long as the sovereign country is also identified, since readers are not necessarily familiar with the first-level country subdivisions in every country in the world.) I'd also like to point out that "European" is now also being used as a broader ethnolinguistic, cultural, and legal identity, and for the encyclopedia is useful for entities that span more than one EU country. -- Beland (talk) 18:04, 9 January 2020 (UTC)
Well-reasoned as far as it goes, but this doesn't address the way-old consensus that doing things like writing "The Beatles were an English band that ..." unduly stresses "Englishness" in a way that doesn't align with WP:ABOUTSELF presentation or indepdent RS analysis of them and their work and impact and cultural associations, which lean "British" more than "English". Even despite Yank confusion, the musical wave of the Beatles and their contemporaries from the same general region was termed the "British invasion", not the "English" one. My own personal preference is to be specific (including also for Cornish, where firmly identifiable as such), but my American-supporter-of-Celtic-separatist-movements position hasn't anything to do with how to write an encyclopedia (except possibly a negative relationship to it!). :-)  — SMcCandlish ¢ 😼  15:44, 14 January 2020 (UTC)

MOS:TENSE dispute needs outside input.[edit]

There's a dispute ongoing here regarding whether or not a non-time-limited event should take the past or present tense (specifically, to describe the process as was or is. If someone with a better knowledge of the proper tense per WP:MOS could look at the article and enact the correct changes, that would be helpful. Currently, there are a mix of tenses as well, which is probably adding to some of the issues. Thanks all! --Jayron32 14:31, 16 January 2020 (UTC)

Surely the mix in tenses is deliberate, thus to illustrate when each should be used? Anyway, the rule of thumb I added (which was reverted pending this discussion) shouldn't be remotely disputable - it's merely an easy way to remember the rule that already exists. The only time we use the past tense is for things that have actually expired - we use the present tense for processes like knapping for instance even though fashioning stone tools went out of fashion several thousand years ago. If something has actually died (a person, a species, a pop band) then past tense is used. We also use it, per WP:FICTENSE, to refer specifically to the production runs of some creative works, even while using the present tense to refer to the work itself (which continues to exist after its creation). This isn't even a dispute - it's a tendentious editor with a fondness for petty drama making a bad edit, and then warring over it. Chris Cunningham (user:thumperward) (talk) 15:18, 16 January 2020 (UTC)
  • In cases like this (an article on an obsolete cloth making process), the question is: does anyone still use the process? Not just commercial manufacturers, but ANYONE. Even if it is limited to medieval enthusiasts, I doubt that fulling has completely disappeared as a craft. So I would lean towards using present tense in the lead (“Fulling is...”)... but follow up by noting that the process is now rare.
That said... context matters, even in grammar... when talking about the commercial fulling mills of the Middle Ages, it is appropriate to use past tense, since THEY are historical and no longer exist. Blueboar (talk) 15:44, 16 January 2020 (UTC)
There will always be someone doing it for YouTube or whatever. The point is that it is possible to do it. It is not possible to make the Beatles release another album or for Margaret Thatcher to dance a tango. And the simplest way I can find of telling the difference is, is there an end point after which things have ceased to be. With the caveat about e.g. TV shows, which is already covered in FICTENSE, I can't think of any circumstances where this produces the wrong result. Chris Cunningham (user:thumperward) (talk) 17:26, 16 January 2020 (UTC)
I don't think there's one solid answer and it depends on context of how the rest of the article is presented, using the test Blueboar proposes, and which to some degree is nearly impossible to prove the negative that noone uses the method any more.
If the topic is strictly about the process, it is probably best to talk of the process and steps in the present tense, but address how it has become disused in history in the past tense. Taking Fulling "Fulling is the process uses for cleaning of wool clothes. Fulling had been used through the 18th century, where it was replaced by more traditional cleaning methods (I don't know if this is the case, but get the idea). In fulling, the cloth is rinsed in..." This accounts that somewhere, someone may still do this, and unless we can say 100% no one does it, is a safer statement.
If the topic is about a product with multiple ways of making it and one process has been aged out to a point no one practically uses it, while the others are still commonly used, that's where I would discuss the process in past tense.
But, again, hard rules don't feel appropriate here. there's a couple different ways this can be done, but I would simply keep in mind that claiming a process is never used today is difficult. --Masem (t) 17:41, 16 January 2020 (UTC)
That's the thing; people die. Companies go defunct. Bands break up. But a process is not something that has a place in time. It exists outside time; it may have been more prevalent in the past, but it certainly is not something which could conceivably ever have an end. Once something like this has been invented; it just is there. The process is not a specific execution of that process, it is a set of instructions to follow to complete the process. That set of instructions does not stop being a set of instructions. The process exists even if no one is doing it right this second. --Jayron32 18:53, 16 January 2020 (UTC)
Well, Ancient_Egyptian_funerary_practices#Mummification describes a process that in principle could still be carried out, yet speaks in the past tense. I'm just raising this to cause trouble; without question the process of fulling is such and such, though it was used extensively during this or that period. EEng 21:07, 16 January 2020 (UTC)
The problem with the article is that it only deals with historic processes. From the Encyclopaedia Britannia:

Fulling

Also called felting or milling, fulling is a process that increases the thickness and compactness of wool by subjecting it to moisture, heat, friction, and pressure until shrinkage of 10 to 25 percent is achieved. Shrinkage occurs in both the warp and weft, producing a smooth, tightly finished fabric that may be so compact that it resembles felt.

Fulling as a process is very much current, even if it no longer needs vats of urine. Martin of Sheffield (talk) 21:21, 16 January 2020 (UTC)
I don't see how your response is relevant to what I said. EEng 21:32, 16 January 2020 (UTC)
There is nothing stopping whatever apocalyptic death cult springs up when the bombs finally start falling from reading up on whatever hard copy of Wikipedia they find in an abandoned school ruin and mummifying corpses again. On the other hand, this is never going to be able to bring Tutenkamen back to life. So only the latter is past tense. Chris Cunningham (user:thumperward) (talk) 21:30, 16 January 2020 (UTC)
But it's not. The section I linked describes those processes in the past tense. EEng 21:32, 16 January 2020 (UTC)
The nuance with mummification is our portrayal of it is tied to specific societies, events or persons, which as of AD 2020 have largely ceased to be. You can only embalm a particular person once, and the ancient Egyptians aren't coming back. We treat the entire subject as historical. We use the present tense for e.g. chariot even though chariots are pretty darned rare on the modern battlefield, but we can still use the past tense to describe how dead societies constructed them. Chris Cunningham (user:thumperward) (talk) 21:44, 16 January 2020 (UTC)
OK then. So somewhere between fulling and putting people's brains in jars there's a dividing line, but it's not clear where that line is. EEng 21:54, 16 January 2020 (UTC)
The article on "mummification in Ancient Egypt" was written in the past tense for the same reason that "fulling in the Industrial Revolution" would be. The articles about these processes as processes should use present tense. It's not about if anyone is doing it, it's about if the processes still exist, which they must if we've got an article on them. Primergrey (talk) 20:39, 19 January 2020 (UTC)
Bring the article up to date. Hand knitters and weavers continue to full woolens. Since wool cloth is still being woven commercially, it is still being fulled. Modern machines are used to do it. See "MILLA is the ideal solution for washing and fulling any type of wool fabric." StarryGrandma (talk) 21:40, 16 January 2020 (UTC)
And another Wikipedia example of a topic well-known to women but not to men that is poorly covered here. Why would any of you think fulling, even the hand methods, is obsolete? Have none of you worn wool pants? StarryGrandma (talk) 23:08, 16 January 2020 (UTC)

Is there any objection to restoring the rule of thumb which was removed here? It was merely meant as an easy test for the existing guideline, and it seems to work well for any example I can come up with. Chris Cunningham (user:thumperward) (talk) 08:07, 18 January 2020 (UTC)

Charts, graphs, timelines collapsed by default?[edit]

Wikipedia:Manual of Style#Scrolling lists and collapsible content currently states, "Collapsible templates should not conceal article content by default upon page loading. This includes reference lists, tables and lists of article content, image galleries, and image captions." Does this apply to templates rendering charts, graphs, timelines, etc.? I would think it would if it applies to image galleries. --Bsherr (talk) 21:41, 16 January 2020 (UTC)

There are exceptions listed in the next paragraph. See also related discussions such as Template talk:Ahnentafel#Transforming into the standardised navbox look and Template talk:Chart top/Requested Comments 1. DrKay (talk) 22:05, 16 January 2020 (UTC)
The exceptions discuss, in this order, tables, navboxes, and infoboxes, and thus not charts, graphs, timelines (unless one should be contained within an infobox), right? --Bsherr (talk) 00:28, 17 January 2020 (UTC)
What is your proposed change to the Manual of Style? DrKay (talk) 17:02, 17 January 2020 (UTC)
At the moment I'm just confirming an absence of an explicit guideline. But I am leaning toward proposing that charts, graphs, timelines, etc. be treated the same as tables. --Bsherr (talk) 17:15, 17 January 2020 (UTC)
Or at least the absence of a specific guideline on this page. Wikipedia:Manual of Style/Accessibility#Users with limited CSS or JavaScript support says all article content should be uncollapsed by default, which would seem to include these. --Bsherr (talk) 17:30, 17 January 2020 (UTC)
That section talks about technical issues and may be out-of-date. HiddenStructure for example wouldn't work on wikipedia for any user regardless of browser or operating system. I must confess how it relates to disability escapes me. DrKay (talk) 17:55, 17 January 2020 (UTC)
Indeed. Merits of the guideline and its purpose may warrant further discussion. Notwithstanding that, I'm more immediately concerned with whether there are any merits to distinguishing between content forms (tables vs. prose vs. files vs. charts). None are apparent to me, and it would allow for a clearer guideline if there were none. --Bsherr (talk) 20:01, 17 January 2020 (UTC)

Talkpages[edit]

This guideline reads: "The Manual of Style (MoS or MOS) is the style manual for all English Wikipedia articles."

It does not say that it is the style manual for all of the English Wikipedia. It specifically mentions articles. I might be missing something here and am hoping someone could edit the guideline to make it less vague.

Are talkpages considered Wikipedia articles?

89.200.15.69 (talk) 20:03, 17 January 2020 (UTC)

No, but I doubt the Manual of Style should apply to talkpages. Talkpages don't have a style that must be followed. No one can edit someone else's comments. El Millo (talk) 20:14, 17 January 2020 (UTC)
See Wikipedia:What is an article?. I've also added a link to this page on the word "articles" in the lede sentence. --Bsherr (talk) 20:32, 17 January 2020 (UTC)
This feels like a loaded question with some conflict behind it. WP:Accessibility, while a MOS page, does apply to talk pages (specifically WP:INDENTGAP and friends are the most common offenses). --Izno (talk) 20:35, 17 January 2020 (UTC)


Pls see WP:INTERSPERSE. For info on structure see WP:ADMINP--Moxy 🍁 20:37, 17 January 2020 (UTC)
FYI. In this case, IP is asking if the pronoues of the subject used per MOS:GENDERID apply to talk pages. Although the issue seems to be resolved now however. LakesideMinersCome Talk To Me! 13:34, 18 January 2020 (UTC)
No. The question is literally if talkpages are considered Wikipedia articles. It appears they are not articles, yet some parts of the MOS seem to apply to talkpages (e.g. WP:Accessibility). The intro might be kinda misleading because it clearly states that the MOS only applies to articles. Since there appear to be exceptions, it would not hurt to have a section that describes when the MOS applies to non-articles. I do not see how the question has been resolved. GibberFishing (talk) 19:26, 18 January 2020 (UTC)
GibberFishing, the BLP applies everywhere. I can assure you that as an admin I consider deadnaming to be a violation anywhere on the project. Drmies (talk) 22:32, 19 January 2020 (UTC)

MOS:COLON entry[edit]

MOS:SENTENCECAPS says, "When an independent clause ends with a dash or semicolon, the first letter of the following word should not be capitalized, even if it begins a new independent clause that could be a grammatically separate sentence: Cheese is a dairy product; bacon is not. The same usually applies after colons, although sometimes the word following a colon is capitalized, if that word effectively begins a new grammatical sentence, and especially if the colon serves to introduce more than one sentence. See WP:Manual of Style § Colons." Therefore, I propose to change:

In most cases a colon works best with a complete grammatical sentence before it.

to read

In most cases a colon works best with a complete grammatical sentence before it, starting with a capital letter. When the phrase following the colon is not a complete sentence, then the first letter is not capitalized unless that first word properly has the first letter capitalized, as used, e.g. "Ms. Jones" or "Jones".

Sincerely, HopsonRoad (talk) 18:25, 18 January 2020 (UTC)

Not your fault, but this brings up a longstanding peeve of mine, to wit, that MOS's job is to explain WP's house style -- specific stylistic choices WP makes among multiple legitimate styles in English writing -- and not to teach rules universal to all competent English writing (except in a limited number of cases where experience has shown that reinforcement is truly necessary). I believe the passage under discussion falls in the all-competent-writing class, and I think it should simply be removed. EEng 19:10, 18 January 2020 (UTC)
The semicolon clause does I think need to go (I don't know that I've seen anyone ever capitalize the word after a semicolon simply for it being the word after), but I have observed variance regarding colons. --Izno (talk) 19:21, 18 January 2020 (UTC)
OK, but does it meet the WP:MOSBLOAT test? EEng 20:50, 18 January 2020 (UTC)
Peeve or not, it is clearly written as the latter and you have some editing and arguing to do if ever you hope to shift it toward the former. MapReader (talk) 21:01, 18 January 2020 (UTC)
Thank you, everyone, for responding here. Whatever the consensus arrived at here, I feel that it should be coordinated with a discussion of how MOS:SENTENCECAPS should be made consistent. Sincerely, HopsonRoad (talk) 21:43, 18 January 2020 (UTC)
If by the former you mean to explain WP's house style and by the latter you mean to teach rules universal to all competent English writing, you're completely wrong. 95% of the time MOS sticks the former; only in a few places does it wander off course into the latter. As is my wont in such cases, I will now summon Attila the Hun to wax eloquent on the subject. EEng 22:03, 18 January 2020 (UTC)
I see two issues: unhelpful division of useful colon-specific advice into two guidelines (MOS:COLON in WP:MOS, and MOS:SENTENCECAPS in MOS:CAPS); and presence of unhelpful semicolon-related rambling at SENTENCECAPS. The short version is "merge selectively from SENTENCECAPS to COLON", more or less. In detail: I agree that the current colon-specific wording at COLON is confusingly over-simplified, so, I'm inclined to support something somewhat like the clarification proposed, because editors who do not read MoS or remember what it says about colons, nor think through what it means in relation to other parts of MoS [and wouldn't have to if we arranged it better], have a tendency to just do whatever they randomly feel like in colon usage (hell, I still keep running into non-English spacing style, as in "There are three versions : Windows, Mac, and Linux."). Such messes require fairly frequent cleanup (of a uniform kind), so there should be an obvious MoS line-item that backups up such gnoming and helps forestall the need for more of it. However, the proposed exact wording above is confusing two things (capitalization of material before and material after), as well as interrupting a longer passage and would thus cause a non sequitur.

It should probably be something more like the following (which has some additional clarity worked in): "In most cases, a colon works best with a complete grammatical sentence before it." [Then keep the extant "There are exceptional cases ..." material and examples.] "When what follows the colon is also a complete sentence, start it with a capital letter, but otherwise do not capitalize after a colon except where doing so is needed for another reason, usually for a proper name."

EEng's point is also good, that some of the semicolon-specific material is "how to write English at all" MoS-bloat, and shouldn't be in MoS since it's neither WP choosing between styles, nor MoS correcting a common mistake or settling a common dispute. That is, we don't have a frequent problem of things like "Cheese is a dairy product; Bacon is not." appearing in our articles. A rule against it at SENTENCECAPS isn't why we don't have such a semicolon problem, because semicolons-and-capitals usage norms are universal, while lack of clarity and advice-centralization about colons obviously is why we have common colon problems [no proctology jokes, please!], because there are multiple approaches to much of it even in English. We could further reduce the colon-specific WP:CREEP/rambling by covering when to capitalize after a colon at MOS:COLON only, then at MOS:SENTENCECAPS just say "(For capitalization after a colon, see WP:Manual of Style § Colons.)". PS (some side points): Even some creep/bloat at COLON could be reduced, such as by nuking the "permissible but awkward" example, which does not illustrate encyclopedic writing but confused "newbie blogger" writing (or perhaps "write like an obtuse Victorian" pretentiousness). And MOS:SEMICOLON might be compressible as well, though I didn't look into that. But, there is no deadline, and we need not try to address every quibble all at once. Next, I don't think there's any real dispute that MoS's purpose is (and only is) to lay out advice about how to write this encyclopedia and to help prevent common problems of injecting non-encyclopedic style, with a primary goal of consistent and professional-looking output for readers, and a secondary one of short-circuiting tiresome, circular editorial disputes over style trivia. MoS is definitely not intended as a "cover every imaginable style error, best-practice, norm, or variance" book like The Chicago Manual of Style or New Hart's Rules, and does not serve anything like a "how to write English well" remedial textbook purpose (someone who needs one isn't competent to work on en.Wikipedia). So, some cleanup like this is probably needed in other places (I would suspect mostly in the choice of poor examples that do not relate to or help guide encyclopedia writing, e.g. all the fiction-dialogue examples at MOS:LQ).
 — SMcCandlish ¢ 😼  10:25, 19 January 2020 (UTC)

SMcCandlish's proposal hits the nail on the head for me, both at MOS:COLON and at MOS:SENTENCECAPS. Thanks! Cheers, HopsonRoad (talk) 14:53, 19 January 2020 (UTC)

 Done As discussed, above. HopsonRoad (talk) 15:27, 27 January 2020 (UTC)

Dates of birth and death in text[edit]

I have forgotten and can't find the relevant MOS section: could someone let me know if this is incorrect at Tourette syndrome (should dates be removed)?

The condition was named by Jean-Martin Charcot (1825–1893) on behalf of his resident, Georges Gilles de la Tourette (1857–1904), a French neurologist, who published an account of nine patients with Tourette's in 1885.

Thanks in advance, SandyGeorgia (Talk) 13:40, 19 January 2020 (UTC)

I am doubtful that such a thing appears in the MOS. I'd remove it because it's clutter in context. --Izno (talk) 14:58, 19 January 2020 (UTC)
Speaking more generally (not for the case at hand), I'd say it depends on the circumstances. If the subjects of the dates have their own articles and the dates are available there, then the information is probably usually superfluous and can be removed. On the other hand, providing such dates may offer useful contextualization in other cases. If the subjects of the dates do not have their own articles, then offering the dates in running text is more valuable because the information is not readily available at a link. The fact that the information is parenthetical makes it easy for readers to skip over the dates if they are not interested in the detail. I think judicious choices on a case-by-case basis are the best solution rather than a blanket rule. Doremo (talk) 15:12, 19 January 2020 (UTC)
Since the 1885 date when the account was published provides context, I decided to remove the clutter. Thanks! SandyGeorgia (Talk) 15:15, 19 January 2020 (UTC)

Possessives of linked items[edit]

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)

  • No, definitely not, because x's both looks better and makes more sense than x's.--Srleffler (talk) 02:19, 21 January 2020 (UTC)
  • 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)
  • 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)
  • 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)

Type of dash for ranges of hyphenated page numbers[edit]

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%7C mode = 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)

Don't do that. Do this: "pages 3-4 to 3-7".--Srleffler (talk) 19:59, 23 January 2020 (UTC)
Only IBM could create such a crazy dilemma. EEng 21:39, 23 January 2020 (UTC)

Center-aligned image captions[edit]

Hello. There is a discussion over at Milhist concerning MOS:CAPTIONS which may be of interest to watchers of this page. Ed [talk] [majestic titan] 22:47, 23 January 2020 (UTC)

Problematic new syntax for em dash[edit]

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)

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)