Jump to content

Wikipedia talk:Manual of Style: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Please do not refactor the proposal that has already been made, and has already been answered to.
(One intermediate revision by the same user not shown)
Line 717: Line 717:
:[[User:Mitch Ames|Mitch Ames]] ([[User talk:Mitch Ames|talk]]) 07:11, 11 September 2016 (UTC)
:[[User:Mitch Ames|Mitch Ames]] ([[User talk:Mitch Ames|talk]]) 07:11, 11 September 2016 (UTC)


<br />
'''Version 2: comments'''
Greetings! First of all, please do not refactor the proposal that has already been made, and has already been answered to. I noticed '''seven''' instances where the original proposal was modified even though the discussion was already going on.[https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AManual_of_Style&type=revision&diff=737666843&oldid=737662809][https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&diff=next&oldid=737967677][https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AManual_of_Style&type=revision&diff=738825039&oldid=738824833][https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&diff=next&oldid=738825039][https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&diff=next&oldid=738825300][https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&diff=next&oldid=738825393][https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&diff=next&oldid=738825763]

Second, although not an RfC, I '''oppose''' because adding wikilinks to quotes is something that intervenes the original statement of the author; the destination article might present ideas that are totally different from the ideas that the author was talking about, or in the worst cases might present [[WP:OR|original research]]. For example, an inventor of something back in the year '''X''' might mistakenly be linked to already altered conceptions of the same thing in the future — in the year '''Y''', let's say. Moreover, when it comes to piped links, the original say of the author could be linked to something totally different, and the risk just increases. For this reason, we already have the current guideline which says: "...''avoid linking from within quotes, which may'' [...] ''violate the principle of leaving quotations unchanged, and mislead or confuse the reader''..." Last, if the object we want to wikilink in the quote doesn't exist in the rest of ther article, is it really worth of wikilinking in the first place?

The opening post of this discussion thread stated: {{quote|Despite being called into question time and again,{{dummy ref|1}}{{dummy ref|2}}{{dummy ref|3}}{{dummy ref|4}}{{dummy ref|5}}{{dummy ref|6}}{{dummy ref|7}} the above rule remains essentially the same as when it was added}}

But doesn't this imply quite strongly that even though introduced '''seven times''', the proposal hasn't gained any support?

I also wonder the statement that "''it doesn't even look like the rule'' [...] ''has ever since been firmly supported, established or enforced.''" Where is this commentary based on? I have always removed links from the quotations and moved them outside the quotation if possible, just like my many co-editors have done.
Last but not least, when it comes to this "''Paris, Texas''" example, we already have policies dealing with such cases, such as [[WP:LINKSTYLE]] (direct link <nowiki>[[Riverside, California]]</nowiki>, or piped link <nowiki>[[Riverside, California|Riverside]]</nowiki>), and [[WP:SPECIFICLINK]] (''...Always link to the article on the most specific topic appropriate to the context from which you link...''") This is a good demostration why the discussion should be taken to [[Wikipedia talk:Manual of Style/Linking]] instead of here. Indeed, WP:MOS only has '''one single sentence''' when it comes to linking; [[WP:MOSLINK]] has a whole page discussing with the different nuances and specific cases. For example, I am interested in the linking guidelines, but I haven't watchlisted [[WP:MOS]] personally as it covers a whole deal of other things but hardly linking. I bet many other editors neither do.

Cheers! [[User:Jayaguru-Shishya|Jayaguru-Shishya]] ([[User talk:Jayaguru-Shishya|talk]]) 20:50, 11 September 2016 (UTC)

===Version 2: comments===
*"If such a subject is mentioned somewhere else in the article, however, then link those instead of the one inside the quote (see also Wikipedia:Manual of Style/Linking § Repeated links). And even if not, consider adding or moving a mention of the subject to the surrounding encyclopedic passage.."<p>What is "such a subject"? What does "those" refer back to? And even if not ''what''? Even without addressing those points, a better opening might be: "However, if such a subject is mentioned elsewhere in the article, link those ..."
*"If such a subject is mentioned somewhere else in the article, however, then link those instead of the one inside the quote (see also Wikipedia:Manual of Style/Linking § Repeated links). And even if not, consider adding or moving a mention of the subject to the surrounding encyclopedic passage.."<p>What is "such a subject"? What does "those" refer back to? And even if not ''what''? Even without addressing those points, a better opening might be: "However, if such a subject is mentioned elsewhere in the article, link those ..."
*Is "most importantly" necessary? ("Never" is already intensive.) "Remotely semantically" is a little clumsy, and what does "semantically" add here? Either remove altogether or replace with "at all ambiguous? [[User:Tony1|<font color="darkgreen">'''Tony'''</font >]] [[User talk:Tony1|<font color="darkgreen">(talk) </font >]] 07:39, 11 September 2016 (UTC)
*Is "most importantly" necessary? ("Never" is already intensive.) "Remotely semantically" is a little clumsy, and what does "semantically" add here? Either remove altogether or replace with "at all ambiguous? [[User:Tony1|<font color="darkgreen">'''Tony'''</font >]] [[User talk:Tony1|<font color="darkgreen">(talk) </font >]] 07:39, 11 September 2016 (UTC)

Revision as of 20:53, 11 September 2016

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

MOSBIO proposal needs more participation

Seeking more participation for my proposal at Wikipedia talk:Manual of Style/Biographies#A slight expansion of MOS:JR.

The proposal has been quiet for 10 days, stalemated around a relatively minor detail. To wit: After considering the recent changes to MOS:JR, which established a default of no comma in John Doe Jr., which of the following surname-first forms should be preferred: Doe, John Jr. or Doe, John, Jr.?

Your participation is needed. If you !vote, please first read all of the discussion, including that in the "Extended discussion" subsection. ―Mandruss  17:40, 28 May 2016 (UTC)[reply]

Restored this from archive since the proposal is still quiet after 39 days. Using Template:Do not archive until to prevent re-archive for 90 days, but that can removed if and when the proposal archives without resolution. It would be a shame to fail to make the main improvement, which has consensus, because of the stalemate on this minor issue. ―Mandruss  07:46, 25 June 2016 (UTC)[reply]

RfC: What (if anything) to do about quotations, and the quotation templates?

Statement of the issues

There's no "Survey" section in this RfC and no up/down vote on an action item. That can come later. There's a lot to chew on here, so let's just have a threaded discussion(s). Maybe we can generate an action item(s) to "vote" on further down the road.

It's a complicated question covering a decade of use of some half-dozen templates which are transcluded over some half a million articles, with documentation in several places. So I apologize in advance for the length of the material.

The basic questions of this RfC

The basic question is "How should quotes be handled in articles" A legitimate answer, of course, is "exactly as they have been". (We are referring in this RfC to typical quotes from a general source, not specialized situations handled by specialized templates such as {{Quote hadith}} etc.)

So some more detailed questions that arise from this might be:

  • Is it OK to continue to have three different templates used for general quotes, or not? Why or why not?
  • The WP:MOS specifies to use {{Quote}} for quotes, and doesn't mention {{Quote box}} one way or the other, but {{Quote box}} itself says to not use it for regular quotes -- yet {{Quote box}} is used for quotes far more often than {{Quote}}; ought this situation be addressed, or not, and if so how?
  • {{Cquote}} is used a fair amount for quotations, even though this MOS strictly forbids this; ought this situation be addressed, or not, and if so how?
  • This MOS by inference supports pull quotes ("the {{pull quote}}... template, which [is] reserved for pull quotes"). Should this MOS discourage or even forbid pull quotes, or is it OK like this?

And there are probably lots of other questions. Possible solutions are many, including

  • Doing nothing, leave the present situation as is.
  • Functionally deleting two of {{Quote}} / {{Quote box}} / {{Cquote}} (by just making two of them a redirect to the remaining one? or whatever would be the best way technically to achieve this function).
  • Changing the documentation to overtly permit use of all three (or: some two) templates for quotes at editors' discretion.
  • Designing a new template which is better than any of the existing ones and deprecating the old ones.
  • Writing a new protocol which carves out separate uses for {{quote}} and {{quote box}} and/or {{cquote}}.

And certainly there are many other good ideas to be had. That's the purpose of this RfC, to think about these and various other possibilities, and maybe we can find some that seem worthy of being presented as action items, down the road. Herostratus (talk) 20:56, 20 August 2016 (UTC)[reply]

Reference: examples of the three templates commonly used for generic quotes

Below is {{Quote}}, the MOS officially sanctioned template, which formats quotations with only indentation:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

— Anonymous, Sad Sack Goes to College

Below is {{Quote box}}, which is supposed to be for pull quotes, but is not specifically forbidden in the MOS for normal quotes, and is sometimes used for normal quotes. It adds a box around the quotation:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Anonymous, Jr., My First Book of Complete Nonsense

Below is {{Cquote}} (which is actually a redirect to {{Pull quote}}), and which is specifically forbidden for normal quotes by the MOS, but is sometimes used for normal quotes. It adds large pastel quote marks around the quotation:

They're basically identical otherwise (each also has a scheme for short quotes spanning just part of the page width; they take a parameter for this, while {{Cquote}} also has a variation template, {{Rquote}}). Note that all of these may present a bit differently in more complicated layouts, such as when among many images.

Herostratus (talk) 20:56, 20 August 2016 (UTC)[reply]

While the above examples illustrate the default use of these templates, they can also be used to make sidebars (as shown below). A large number of uses of these templates are such, which can present issues that do not occur with default-mode inline use of the templates. Disputes over these templates at articles are often about this type of usage, not the default inline use.
Left, right, and center
A big title here

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Anonymous III, Big Book of Quotes
 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:16, 22 August 2016 (UTC)[reply]

Reference: additional material

A "pull quote" is a layout device used by magazines: a piece of text is "pulled" from the article and repeated in a box or a large or color font. This to break up the page layout and attract the eye to the material. We aren't a magazine and we don't use pull quotes -- almost never, and most editors appear to agree that they are appropriate very rarely or never for an encyclopedia article. {{Quote box}} and {{Cquote}} are (supposedly) just for pull quotes, but they are very very rarely if ever actually used for that.

Here's usage numbers:

  • {{Quote}}, {{Blockquote}}, and raw <blockquote>...</blockquote> (which are basically identical) are used in about 119,000 articles.
  • {{Cquote}} is used in about 18,000 articles. {{Rquote}} adds 1,400 more.
  • {{Quote box}} (and {{Quotebox}}) are used in about 8,000 articles.

Refs for "Quote" usage:[1][2][3][4][5]. [6][7][8][9][10]. Refs for "Cquote" usage:[11][12][13][14][15][16][17][18]. Refs for "Quote box" usage:[19][20][21][22].

The main operative section of this MOS is WP:BLOCKQUOTE (WP:MOS#Block quotations), most specifically the second and fourth sentences which read:

Block quotations can be enclosed in the {{quote}} template, or between a pair of <blockquote>...</blockquote> HTML tags... Do not enclose block quotations in quotation marks (and especially avoid decorative quotation marks in normal use, such as those provided by the {{pull quote}} a.k.a. {{cquote}} template, which are reserved for pull quotes).

Herostratus (talk) 20:56, 20 August 2016 (UTC) [revised, 21:21, 21 August 2016‎ (UTC), with data from SMcCandlish][reply]

Here are more specific usage numbers, in case anyone wants to "check our work", comparing the transclusion counts (which can be misleading by themselves) from an external tool, followed by insource:/regex/i code search results showing actual total page counts, and article counts more specifically:
Usage statistics in more detail

Fair warning: most of these search links are quite slow, and they're hard on the server.

  • {{Quote}}, the prescribed template, has 85,609 transclusions [23], in 48,234 pages [24], including 40,201 articles [25] at that name. Its {{Blockquote}} alias adds 3,476 pages [26] and 2,143 articles [27]. Redirects of merged templates add many more: {{Quotation}} adds 14,395 pages [28] and 8,480 articles [29], and {{"}} adds 304 pages & 111 articles [30]. The total is around 60,500 paged plus several hundred more from other aliases, and about 51,000 articles plus a few hundred more from aliases.
  • Raw <blockquote>...</blockquote> markup – functionally equivalent to {{Quote}} in most cases – is used in 169,349 pages [31], of which 67,157 are articles [32]. It is the most common block quotation formatting in our articles, though any of its instances that have no custom CSS can be immediately replaced with {{Quote}}.
  • {{Quote box}} has an amazing 540,985 transclusions [33], but in "only" 89,066 pages [34], of which a mere 7,466 are articles [35]. Another 485 articles are added by its {{Quotebox}} alias [36], plus a few dozen more from other redirects, for a total of about 8,000 articles. The bulk of the usage is multiple transclusions on talk pages.
  • {{Pull quote}} (despite being the favorite of those who advocate for a decorative style) has only 36,934 total transclusions [37], of which 35,081 are of its {{Cquote}}} alias [38]. The latter appears in 33,818 pages [39], including 17,269 articles [40], plus 555 pages using its "canonical" name {{Pull quote}} [41], of which 251 are in articles [42], and 608 more pages [43] and 415 more articles [44] from the {{Centered pull quote}} alias, and about 100 more pages and 50 more articles from other redirects. The totals are approximately 35,000 pages and 18,000 articles.
  • The {{Reduced pull quote}} variant has 1,760 transclusions [45] in 101 pages [46] and 69 articles [47] at that name. Of the total 1,760 transclusions, its long-standing shortcut {{Rquote}} accounts for 1,672 [48], and adds 1,664 pages to the page count [49], and 1,306 articles [50], with very few more from other redirects. The totals are about 1,800 pages, 1,400 articles at most.
  • The rare {{Quote frame}} has 227 transclusions [51], and only 42 are in articles [52].

The page and article counts have a small margin of error, due to minor redirects being ignored, possibly other templates transcluding one of these templates, and references to the template in code markup, e.g. in template documentation, but overall they are a solid overview of the deployment of these templates.

Several of these templates, along with bare <blockquote>, are incorrectly being used as block-indentation markup for non-quotations, a violation of the HTML specs. Instances of such misuse should be replaced with {{Block indent}}.

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:16, 22 August 2016 (UTC)[reply]

General threaded discussion

(If you have a specific proposal (which might perhaps be an action item in a later RfC), you might want to consider stating it in a separate section below, so it can be discussed separately? Or not... just a suggestion.) Herostratus (talk) 20:56, 20 August 2016 (UTC)[reply]

  • Certainly there is a problem here, but it seems to me that it is not so much with the MOS or the templates (which appear to be in agreement -- although strengthening and clarifying restrictions on {{Quote box}} and {{pull quote}} would be helpful), nor with general practice (which, if we could include <blockquote>...</blockquote> in the counts would, I expect, be mostly consistent with MOS) -- rather this is a simple case of editor error. If this is correct, the solution involves not guideline or template development, but just work -- some wikignome martyr would have to review every instance of templated "luxury" quotes and reformat correctly, where appropriate. Clearly I am against a mix of styles for the display of vanilla quotes... but I don't think that fuctional deletion via redirect is the correct path to uniformity, as this would bulldoze legitimate uses of (what should be) the rarer "luxury" templates and potentially somewhat alter their current sense. A case-in-point would be William Shakespeare#London and theatrical career which has (I think) correctly used <blockquote>...</blockquote> and {{Box quote}} right next to each other. Phil wink (talk) 23:01, 20 August 2016 (UTC)[reply]
Well, 578,101 27,500 transclusions is an awful lot of editor errors.
My personal opinion is, {{quote}} is a poor template on the merits. It is very important that readers quickly comprehend when we are switching to a quote. {{quote}} lets them down and slows them down. It is insufficiently different from regular text to signal the switch to a quote.
That's my opinion. Maybe I'm wrong. But its an opinion shared by a lot of editors, I guess. I believe this a better explanation than error for half a million transclusions use in about 20% of cases even though it is expressly forbidden. I don't think our editors are that error-prone. I myself certainly don't use {{quote}}, on purpose, for the simple reason that to my mind it's not of sufficiently professional quality for the information design I want to achieve in the articles I am creating or building. I usually use {{cquote}}, most people use {{quote box}} I guess. And that's fine by the way. We don't need a bed of Procrustes approach to our editors. If we absolutely must have one template, I guess {{quote box}} would be the best choice, though. I don't think {{quote}} should be it. Herostratus (talk) 01:27, 21 August 2016 (UTC)[reply]
  • Answering the four RfC questions in order, with detailed rationales:
    1. No, it is not OK to have multiple templates (in mainspace) for quotation pesentation. The decorative ones are several kinds of policy problem.
      • The decorative ones were kept, narrowly, at TfD (and few templates have been TfDed this many times – the community has long had serious concerns about them), only with the understanding that they would be reserved for non-mainspace use, or for rare instances of pull quotes in mainspace.
      • But, as I predicted, they have been rampantly abused to violate multiple policies – chiefly WP:NPOV (especially WP:UNDUE), but also WP:NOR and WP:NOT, as detailed below – to bludgeon readers with particular individuals' or organizations' statements, and to insert quotes that are irrelevant and non-encyclopedic, and to lazily slap quotes into articles at random locations as design "filler" without any regard at all for whether they make any sense in the contexts into which they've been jammed (or for the fact that much WP:REUSE will simply lose them).
      • Case study 1: Just the other day, I fixed all three of these problems at once in a single article, the first one I picked to do quote template cleanup on (and one which someone had pointed to as what they thought of as good use of the templates!). See edit history of Thorpe affair from this edit onward, or see all the cleanup in one diff here, including some other copyedits. User talk:SMcCandlish#Quote box [53] gives a detailed analysis of why all three quote templates in that article were "reader-hateful". They are not unusual in any way, but directly reprsentative of the three broad types of quote template abuse on Wikipedia: PoV-pushing, context-free decoration, and indiscriminate trivia-mongering.
    2. MoS and template docs are only read in detail by gnomes; most editors just copy what they see in older articles. This has lead to memetic propagation of a terrible style idea from WP's olden times faster than gnomes can clean it up. We thus need a technical solution.
      • MoS gives a specific template for block quotations, explains what a pull quote is and why we almost never use them, and says not to use pul-quote templates like Pull quote (which some refer to by its redirect "{{Cquote}}" as if to disguise the fact that they're misusing a pull-quote template) for block quotes. The other templates' documentation indicates they're pull-quote templates, too, so every single time someone is using them for non-pullquotes, they're either copy-catting old articles the template abuse has not been cleaned up in yet, or they're intentionally ignoring documentation, guidelines, and policies to force their design sense on Wikipedia.
      • I know for a fact that it's most often copy-catting; I've asked people why they inserted a decorative quote template, and they've told me it's because they saw it in another article and thought it was WP's official style! It's a memetic virus, pure and simple, just like capitalization of common names of species was in 2008 (which we're still cleaning up in August 2016).
      • Defense of decorative quotes in an article is almost invariably a WP:OTHERCRAPEXISTS affair; people usually literally cannot think of any other rationale but "I saw it at [Article X], and that's an FA, so it must be the right way to do it", not understanding that the FA dates to before we had rules about this stuff and hasn't been fixed yet. Another favorite is the "WP:OWN policy doesn't exist" game: "I wrote almost all of this article, so it should be decorated if I wanted it that way." Mainly, though, it's just that most editors do not actually read MoS, or any more template docs than they have to figure out some parameters.
    3. The solution is to install a namespace switch in the decorative templates that changes their output to that of the standard {{Quote}} template if they are used in mainspace, then for editors to adjust their placement and contextualization over time, where necessary. It really doesn't matter if we have three or a dozen decorative quote templates as long as none of them work in articles.
      • Keeping them functional outside of mainspace would still permit the "screaming with decorations" effect of these templates in wikiproject pages, etc., where we don't care.
      • I proposed this obvious solution over two years ago, but TfD said "let's wait and see if that's really necessary". The result of that delay has been a tsunami of tacky picture frames and giant quotation marks shoving PoV-pushing, confusing, and pointless quotes in readers' faces.
      • The idea that there's a consensus to decorate quotations is demonstrably false. See stats above. The MoS rule has been around for years. No exceptions have been made to WP:NPOV policy, etc., for quotations. No one objects when those templates' scopes are repeatedly narrowed, and when half a dozen variations of them are merged right out of existence. When they are TfDed, hardly anyone defends them (usually the same handful, and usually for entirely unclear rationales).
      • Case study 2: I spent several days converting decorative quotes to standard {{Quote}} templates in 100 articles, and not once was I reverted or challenged on it. Basically, no one cares except about half a dozen "décor defenders" (you can find them also in the WT:MOSICONS archives as the lonely advocates of plastering pages with flag icons all over the place, etc.). Editors just copy-paste and customize the templates they see in other articles.
      • As with another large mess of this sort – the capitalization and linking of dates that we cleaned up in the early 2010s – this will probably require bot cleanup (see below).
      • To the extent that some editors think the default style isn't quite enough visual distinction, see #Slight display adjustments for how to address that.
    4. MoS should simply deprecate pull quotes. Less that 1% of the uses of the pull-quote templates are for actual pull quotes, and in every single case of one that I've found, it can be safely removed and will improve the article in its passage into the WikiAfterlife.
      • Pull quotes are a heavy-handed "teaser" news style. We have a Wikipedia is not news policy, with numerous implications, including that WP does not serve the purposes of a news publication, is not written in the same register as one, does not follow journalism style guides, has completely different reader expectations of it, and has no use for attention-seeking mechanisms to try to entice readers into zooming to particular sections, much less "walking away with a key message" that some editor wants to drill into their brain with a huge, decorated quotation.
      • These templates are a serious WP:CCPOL problem, and this is much more than a trivial style matter. We have tried pull quotes and they've failed dismally, both by doing nothing useful here themselves, and (much worse) by the templates for them being massively abused in article after article as excuses to violate neutrality policy (among others, like WP:NOR's prohibitions against steering/leading/manipulating the readers into drawing particular conclusions, and against over-reliance on primary source material, etc.). This has to end, and it should have ended years ago. (This "screaming for attention" quotations matter, by the way, is a great illustration of why "MoS is just a bunch of style nitpicks we don't need" is a wrongheaded viewpoint. Many aspects of MoS, from MOS:WTW to MOS:ACCESS to MOS:IDENTITY, are important content guidelines with deep connections to Wikipedia policy and mission, and aren't just "style" advice.)
    Recommended cleanup path: All instances of the noncompliant templates in mainspace should first be replaced, via bot, with a specific template redirect for each template e.g. {{Quote-Cquote}}, etc., to isolate these cases. The code can then be temporarily forked, making these redirects into copies of the templates. The original decorative templates, now expunged from transclusion in mainspace all get fitted with namespace detectors, such that their non-mainspace deployment is unaffected, but use in mainspace outputs {{Quote}} code or even a visible error message. The disused ones can also be merged into {{Quote box}}. In mainspace, the templates with compatible parameters can just be redirected to {{Quote}}; the one or two that do not will have to be replaced with template wrappers that call it and convert the parameters. Then we can finally have a bot replace them with calls to the main template by adjusting the parameters. All that would remain (and would already be underway in the interim) is working the former "sidebar" quotes into the content where they belong, and removing redundant or unencyclopedic ones.
     — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:03, 21 August 2016 (UTC) Updated 06:44, 21 August 2016 (UTC)[reply]

OK, here're my answers:

  • Sure, it's OK to have more than one quote template. (The question of whether the three existing quote templates are all OK (I think they are) is a different question). People are way too much into micromanaging other editors sometimes. Trust the editor to do the right thing, given reasonable restrictions. Reasonable levels of empowerment is how you build a successful volunteer organization. If the editors do the wrong thing, educate them. We are not the Army where everything not mandatory is forbidden and can't thrive with that mindset. I have just described one large and important objective benefit of allowing editors some leeway here. (there are others). Look a lot of this comes down to opinion. I invite editors to show me the objective benefit of allowing just a single template and you will win me over, but not before.
  • Change the documentation of {{Quote box}} documentation to bring it in line with practice. People use it for quotes (for the good and sufficient reason that's a it's better than {{quote}} at letting the reader know that she's entering a quotation). Rules should describe practice. The current situation is dysfunctional, and going on a crusade against (what is certainly at least arguably) good layout and good information design, in order to make practice fit an ancient rule, is probably not the best answer.
  • Change the documentation of {{Cquote}} and one sentence in this MOS to bring it in line with practice, same argument as above.
  • Should not encourage pull quotes. Best would be to just not mention them at all, I think. They're very rare. Here is an example: Philippe I, Duke of Orléans #Homosexuality. I wouldn't do that, but it doesn't make me claw the draperies either. I not particularly bossy or certain that I'm the world's genius of information design or page layout, so I wouldn't be inclined to tell that editor "I order you to remove that". Just remove mention of pull quotes, everywhere, per WP:BEANS. Herostratus (talk) 22:01, 22 August 2016 (UTC)[reply]
    • @Herostratus: Asserting all these templates are fine when gross abuses of them are rampant, without addressing any of the reasons why they're problematic from a policy perspective, is basically a non-argument, though. Why would we change the documentation and MoS itself when the numbers show most editors comply, there's no consensus to undo MOS:BQ, none of the policy and other issues have been addressed, and there's a proposal on the table to adjust the default style mildly to obviate most if not all desire to use decorative quotation boxes that go so far they cause NPoV problems? There's very little (in the nature of discrete rules, rather than sometimes verbosity within one) that isn't there for a reason. WP:TFD's primary function (probably 75% of its activity) is getting rid of redundant templates (the rest mostly being deletion of unused or one-use templates), so we have an entire XfD standing against the idea of "Sure, it's OK to have more than one quote template", absent a really clearly justifiable reason to have more than one (e.g. for a specific technical need, that cannot be addressed with a parameter option) and without them causing more trouble than they're worth. It's also a speedy deletion criterion to delete templates that misrepresent policy. WP:POLICY includes guidelines, so a "defy MOS:BQ" template is a speedy deletion candidate; even if it were not, it would still be a regular deletion candidate, because the way to change policies and guidelines is not WP:FAITACCOMPLI defiance until the opposition is worn down. That's just tendentiousness. I don't think you're being tendentious; your proposed solution seems to be offered in good faith, but is simply not addressing anything in the debate at all other than the "I wanna decorate" urge that some editors have, which is a WP:NOT matter, really. Agreed WP doesn't need pull quotes, but we discourage them because people insert them willy-nilly if we don't.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:00, 1 September 2016 (UTC)[reply]
  1. One core template should suffice for simple blockquotes, because HTML only has one way of marking up a blockquote. Whether the community decides on one visual presentation or hundreds, the output follows the same pattern: a <blockquote> element containing the quoted text and maybe a <cite>. If different presentations are desired, just use parameters and maybe wrapper templates to adjust the class (or in a pinch, style) attribute. Maintenance is easier, skins can tweak the appearance, and user CSS can override as needed. {{Quote}} would need some changes to serve as such a core template, but the changes wouldn't be difficult.
  2. {{Quote box}} for blockquotes is an accessibility error. This puts a blockquote inside a <div>, making it impossible for some users to tell that it's quoted text, and should be addressed if only for that reason. One possibility: {{Quote box}} could be rewritten as a wrapper, something like {{Quote|class=float-box|…}}, provided the code support for that is in place. The few cases where {{Quote box}} is used for a pull quote can be replaced with, say, {{Pull quote|class=float-box|…}}.
  3. Ditto for {{Cquote}}. Code copy-and-pasted from {{Cquote}} is responsible for every blockquote I've ever seen rendered as a <table> on a wiki. I've started to imagine the "C" stands for something unpleasant and fast-spreading.
  4. Headings do the job of pull quotes better. In loosely structured or inverted-pyramid writing, like blog posts and news articles, pull quotes are a nice visual break in a long page. Wikipedia articles already get visual breaks from headings, with added benefits for organization and accessibility. So while pull quotes may be fine for a WP:Essay, etc., they are largely decorative in a Wikipedia article.

Sorry to duck the prickly question of which presentation options to prefer or keep, but if semantics and accessibility are fixed first, the presentation issues should be easier to approach. Matt Fitzpatrick (talk) 11:26, 6 September 2016 (UTC)[reply]

Proposals

Pastel line on the left

An editor, User:Waldir, just recently at Template_talk:Quote#Styling suggested that {{quote}} have a pastel line on the left, like this:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed ultricies nisi eu lectus egestas scelerisque. Etiam vitae ante vel lorem efficitur fermentum at quis nisi. Nulla et augue eget arcu scelerisque malesuada. Maecenas porta vestibulum libero eget varius. Donec lacus magna, fermentum vel ante vitae, malesuada posuere magna. Aenean scelerisque in neque ut semper. Donec eleifend tortor justo, ut ullamcorper tortor dictum at.

on the grounds that it makes quotes more readily identifiable, and since (he says) many stylesheets are doing this now it might be recognizable to many readers. He might be right. Perhaps an updated quote box like this would combine the best of the three templates now being used. (There might be technical issues though.) Herostratus (talk) 21:08, 20 August 2016 (UTC)[reply]

  • Because {{Quote}} is (mostly) fuctionally equivalent to <blockquote>...</blockquote> -- if greater consistency is desired in generic quotations -- adopting a pastel line for {{Quote}} would necessitate either 1) applying the same formatting to <blockquote>...</blockquote> or 2) systematically repackaging all generic blockquotes with {{Quote}}. Phil wink (talk) 23:11, 20 August 2016 (UTC)[reply]
  • Already rejected: This was proposed a year or two ago in a Village Pump RfC and shot down. It looks far too much like our cleanup/dispute templates, and there was a clear sense that it's some random blog style, and already a dated one at that, and not appropriate here. Others also felt it was heavy-handed and visually disruptive in general, serving to draw WP:UNDUE emphasis to quoted material, when what WP wants to do is minimize the amount and impact of quotations (see WP:OVERQUOTE and WP:NPOV). Another problem with it is that it will not improve, only worsen, the problem of block quotations being "squeezed" between left and right images, by further reducing the horizontal space available. In such a layout, it will look like a broken partial border for the right side of the lefthand image.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:08, 21 August 2016 (UTC)[reply]

    PS: This style was also made available as an option in one of the templates, and no one used it. I would think it's been removed by now. If not, should be, as dead code.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:05, 3 September 2016 (UTC)[reply]

    • Oh. BTW One thing I've never understood is our documeentation "Hey, we have {{quote}}, but using the raw HTML is fine too". What's the advantage? I can see the disadvantage, one being just the situation described -- we can't globally alter quotes done in raw HTML, or even know how many there are. Sure I get that the software supports HTML and some people are going to use it whatever we say, but why do we actively recommended it? Anybody know? Herostratus (talk) 01:12, 21 August 2016 (UTC)[reply]
      • Not sure how that relates to this "pastel line" thing, but the reason that's in there is that some editors historically have objected to "forcing" (LOL) people to use wrapper templates for HTML elements, even when we have good reason to prefer that people use them (e.g. application of CSS classes), so we tended to always also mention the raw HTML behind the template. I would just as soon we did not and deprecated using the raw HTML.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:25, 21 August 2016 (UTC)[reply]
      • Well, maybe it's worth trying again, maybe the objectors have gone away. If not, we could offer a pointer down into the "Notes" section where we say "or you can also use raw HTML" in small text, that way not being so recommendy about it. Herostratus (talk) 21:26, 21 August 2016 (UTC)[reply]
  • This pastel bar thing is absolutely ghastly. EEng 17:32, 23 August 2016 (UTC)[reply]

Slight display adjustments

We should do what most style guides that address the matter recommend: Slightly reduce the font size (e.g. to 95%) to make a lengthy quotation better set-off from the surrounding text, as well as indenting it the way we already do. This would also offset the incidental emphasis effect that putting it its own block (paragraph) and indenting it has. The purpose of block quotations is not the SCREAM AT THE READER but simply to indicate "this is an extended quotation". Given the nature of the medium, we might also consider a very faint background color (e.g. a very light grey) that does not impact readability (see the colors section of MOS:ACCESS). This would help to still distinguish the quotation block in browser/display/layout situations where the content is squeeze so much the indentation is unclear or even eliminated. This would cost us no additional horizontal space at all, unlike the vertical bar proposal above.

The fact that so many people do not understand what block quotations are for, and mistakenly believe that the purpose of them is to greatly emphasize material, is the #1 reason that multiple templates have proliferated all over Wikipedia drawing enormous amounts of visual attention to quotations (against WP:NPOV in general, WP:UNDUE in particular, WP:NOR because leads/steers the reader's interpretation of the material, WP:SOAPBOX, MOS:BQ, etc.). It's time to put this to bed, just like we've put to bed date linking, and about 20 kinds of Rampant Over-Capitalization, and italicization of quotations, and use of boldface as emphasis in article text, and a many, many other things that were formerly common on Wikipedia.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:25, 21 August 2016 (UTC)[reply]

This seems quite reasonable (the first paragraph). We do want some kind of increased emphasis without over-doing it, so we're both on the same page here. Herostratus (talk) 01:33, 21 August 2016 (UTC)[reply]
I couldn't agree more. Graham (talk) 02:17, 21 August 2016 (UTC)[reply]
My personal opinion is that we already have a template for increased emphasis without overdoing it: {{cquote}}. Without using a 95% font or a faint background, it signals to the reader that he is entering a quotation with the English universal symbol this: quotation marks. They're large, but they're faint, so the overall effect is subdued, at the same time making for an attractive layout.
However,  there's the political angle to consider. At least one editor hates {{cquote}} with a dark and burning fury and will never slacken in the battle against it, and there are other editors who also consider it overly twee. So whatever works reasonably well that can get passed is what we are looking for here. Herostratus (talk) 22:14, 21 August 2016 (UTC)[reply]
I am against any reduced font size. I have my screen set to the smallest font size I can reasonably read. Many other readers wil have the same set-up. (And please do not offer me advice on custom css that will fix this for me, it's the general accessibility issue that I am interested in.)
All the best: Rich Farmbrough, 19:12, 26 August 2016 (UTC).[reply]
@Rich Farmbrough: Noted. Perhaps just a faint background would do it. Some other styles involve a font-face change, but we'd have to at least also retain the indentation, since the CSS font trick will coincide with some user's custom CSS here or their browser-side font choices, making, e.g., serif-formatted quotations indistinguishable from the rest of the prose if they use serif for all of it.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:03, 1 September 2016 (UTC)[reply]
I also can not easily see reduced font sizes. Font size is an accessibility issue,which over-rides most all other format concerns. The great majority of users are just readers, without accounts to use preference settings. We organize WP primarily for our readers, not just for us DGG ( talk ) 14:24, 6 September 2016 (UTC)[reply]
Test of background shading

Here's a sandbox (Template:Quote/sandbox) test of slight shading of the background (easily adjustable; I made it visible without being dramatic, nor so faint it was hard to tell it was there, on my monitor anyway.)

Fake heading

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

A. U. Thor, Some Publication, 2016
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.


It works perfectly fine when "sandwiched":
Fake heading

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

A. U. Thor, Some Publication, 2016

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.


So, it seems to me that this would address the need to make block quotations stand out a little more from regular text without introducing POV and accessibility concerns.
 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  06:40, 11 September 2016 (UTC)[reply]

Much ado about not much

The minutiae of what is/is not acceptable to the "commuity" when formatting quotes in articles is hardly the burning issue that some editors imagine it to be, but it has the capacity to be used as a warmongering device on countless talkpages, so it would be good to come to an agreed conclusion and codify this into the MoS. My standpoint is that of a content editor who understands the value of quotes in terms both of content and presentation. Briefly:

  • I agree that in-text quotations would be improved by a reduction in the text size (perhaps to 90% rather than 95%) which, combined with indenting should distinguish them from the text
  • I remember Cquotes being very popular ten-plus years ago when I first edited, but they seem terribly ugly, dated and unencyclopaedic now. I haven't encountered them on peer review or FAC for a long while—I don't think they are used much now, at least in quality articles, and I suggest that this format could be withdrawn without too much loss.
  • Quote boxes I see as as an alternative to images. We generally accept images when they illustrate an aspect of the text, without seeing them as placing undue emphasis on that aspect of the text. We also use images as an aid to readability, by breaking up slabs of text and by careful positioning. In some topics, particularly those of recent history, copyright law makes it hard to find relevant images, in which case carefully composed quote boxes can often be a useful substitute, provided their content is selected carefully. The argument that they distort readers' understanding by drawing the eye away from the context is an assumption for which I haven't seen any convincing evidence; in any event, this aspect can be dealt with on an article-by-article basis. In short, I would like MoS to recognise that in some cases the quote box provides a useful presentational tool—this has been widely accepted informally for some years now—and I don't think this should be overturned at the behest of the Savonarolas amongst us. Brianboulton (talk) 15:21, 22 August 2016 (UTC)[reply]
While this discussion does interest me, I'm not going to pretend that I've read even 5 per cent of the text dedicated to it above … Brianboulton's comments on Cquotes and Quote boxes summarise the situation perfectly, as far as I'm concerned, as someone who writes articles. Cquotes are unencyclopaedic and, I suggest, draw far too much emphasis to the quote. Boxed quotes/quote boxes are very useful and informative, not to mention popular with many GA and FA writers. The point about using them to break up slabs of text, particularly given the paucity of free images, is an important one. JG66 (talk) 15:52, 22 August 2016 (UTC)[reply]
Echoing the above on breaking up what can seem for readers as dense walls of text. I'm unswayed by the opinion of one editor that they are "PoV-pushing, context-free decoration, and indiscriminate trivia-mongering": if that is the case on individual articles, then those individual articles should be re-worked. But to get rid of using the entire format because they are sometimes misused is doing our readers a disservice. – SchroCat (talk) 20:39, 22 August 2016 (UTC)[reply]
  • I haven't read more than 5% either, but my thinking is:
The caption should lead the reader into the article. For example, in History of the Peerage, a caption for Image:William I of England.jpg might say 'William of Normandy overthrew the Anglo-Saxon monarchs, bringing a new style of government.' Then the reader gets curious about that new form of government and reads text to learn what it is.
There's no reason a well-chosen quote (not necessarily repeating something in the article text proper) highlighted in some way (whether boxed, shaded, big-quoted, whatever -- I'll leave that to others) shouldn't be allowed to serve the same purpose, though of course only in situations well away from any possibility of POV. I'm probably going to regret pointing this out, but I think this works well at Memorial_Hall_(Harvard_University)#Conception_and_construction. (Those weird shaded rectangles didn't used to be there -- yuck!) EEng 20:49, 22 August 2016 (UTC) Edited to use boxed quote instead of bigquotes -- weird shaded rectangles no longer there. EEng 02:56, 3 September 2016 (UTC)[reply]
EEng 20:49, 22 August 2016 (UTC)[reply]
You are right on the shaded rectangles – horrible! I would also add to the list of things to avoid the use of the over-size quote marks. I've never seen a proper pull quote on WP (as in the correct definition of an excerpt of article text repeated as a stand alone quote), and the sooner the go, the better. The use of quote boxes, on the other hand, carefully and correctly used (as with an image to sit alongside a relevant piece of text, that enhances not just the readability of the text, but also the reader's understanding of a topic) has a lot to be said for it. – SchroCat (talk) 16:46, 23 August 2016 (UTC)[reply]
I used the bigquote template back when I added those quotes because I got lost in the vast selection of quote templates, and back then the shaded rectangles weren't there -- someone's changed something in the template. Anyway, I've redone it with a shaded quote box. EEng 17:35, 23 August 2016 (UTC)[reply]
If you want to see the only example of pull quotes that I've ever come across, SchroCat, take a look at Philippe I, Duke of Orléans #Homosexuality. Ironically, it doesn't use a quote template, but a customised table acting as a container! --RexxS (talk) 20:29, 23 August 2016 (UTC)[reply]
  • FYI: On the mobile frontend, {{quote}} and <blockquote>...</blockquote> set off quotations not only with indentation but also with oversize quotation marks - exactly like {{cquote}}, but black instead of blue. Abuse of <blockquote>...</blockquote> for indentation is thus immediately visible on mobile and really looks ridiculous. It also actually increases the font size, which I think is a very strange design choice - the indentation already reduces the available horizontal space, and increasing the font size further compounds this. I have no idea why the decision was made to imitate a deprecated template, but I've become accustomed to it (and it has the virtue of making quotations marked up by semantic abuse of the leading colon trivial to spot). At any rate, people discussing {{quote}} vs {{cquote}} seem unaware that they look almost the same on mobile.
Additionally {{quote box}} is not shoved off to the side like an image, but is put in the centre of the page... funnily enough, exactly as images are. My main objection to {{quote box}} is that it's a lazy way of getting a quotation in: the quotation appears totally devoid of context or motivation. Stylistically such isolated quotations are a train wreck. If there's no way to integrate such a quotation into the article text, it probably doesn't belong there. From what I understand the term to mean, they are not technically pull quotes - in fact, I don't believe I've ever seen a true pull quote on Wikipedia, and I would immediately remove one if I did because it's a journalistic style totally inappropriate for an encyclopedia. Hairy Dude (talk) 03:24, 23 August 2016 (UTC)[reply]
I beg to differ: if used properly and responsibly, quote boxes are not some "lazy way of getting a quotation in". They can provide a very good means for displaying certain types of quoted text, a letter, say, or a poem, or a piece of text which while not central to the direct narrative, provides a useful illustrative comment. Such boxes are not isolated if they adjoin the text to which they relate – the same rule applies to images. And you shouldn't rule out the presentational advantages of quote boxes, in terms of making blocks of text look more appealing to the reader – my years as a magazine editor taught me the importance of presentation, in particular the turn-off potential of walls of uninterrupted text. I agree that quote boxes should be used sparingly and with care, particularly when other options are available, but to withdraw altogether this useful tool would be an unnecessary mistake. Brianboulton (talk) 10:00, 23 August 2016 (UTC)[reply]
What some people think reading an article should feel like to the reader - "it was tedious to write, it should be tedious to read" — Preceding unsigned comment added by EEng (talkcontribs)
Very well said. The problem we're up against, Bb, is the some editors think that anything betraying any kind of care for the reader's pleasure or interest in reading the article is "unencyclopedic" (a vague term encompassing anything the speaker hasn't run into before). Savonarolas is right! EEng 14:54, 23 August 2016 (UTC)[reply]
Yes, I agree. I don't think there is one right answer to the question "what is the best quote template". It a matter of taste, opinion, one's personal concept of page design, and what is needed for that page environment (many images, no images, etc.) My inclination is to trust the editor, and correct-and-educate when the editor goes too far into the weeds (whether it's too long a quote, too many images, sections too long, etc. etc.) Crowdsourcing page design works! Herostratus (talk) 15:06, 23 August 2016 (UTC)[reply]
Wisely summarised. We should resist all tendency to over-regulate when common sense can easily be applied. Brianboulton (talk) 19:04, 24 August 2016 (UTC)[reply]
I agree with the points made by Brianboulton, but would add: Quote boxes, certainly at the FA level, are not used for no purpose, and not merely to break up text. They serve to illustrate points to the reader, selected by savvy writers. A quote box with a random quote would probably face scrutiny at FAC, with suggestions the nominator not miss the opportunity presented by a quote box to highlight text more likely to be read by the reader than were it to be buried in a paragraph somewhere.-- an alternative to images (talk) 04:32, 26 August 2016 (UTC)[reply]
I highly support Brianboulton's and Wehwalt's position above. Briefly, we should
  1. Reduce the text-size in block quotes to about 90%.
  2. Change the documentation for Quote box to reflect it's use as illustrative text – similar to how images are used.
  3. Deprecate the use of Cquote; it should be replaced with either Quote or Quotebox, depending on use.
LK (talk) 23:35, 27 August 2016 (UTC)[reply]

It appears to me that Brianboulton's points are primarily made just to justify keeping the way he sensationalized bits of stuff in the Thorpe affair article, one that SMcCandlish uses to illustrate the main problem with these fancy boxes: they give the editor a soapbox to display a POV. In this case, it does not look like they "serve to illustrate points to the reader, selected by savvy writers." Dicklyon (talk) 15:10, 28 August 2016 (UTC)[reply]

  • Your judgement on that point is as ill-advised as your sub-standard edits to the article. Perhaps if you are unable to comment without pretending to read someone's mind, it would be best not to comment at all. - SchroCat (talk) 17:16, 28 August 2016 (UTC)[reply]
    • I don't understand your objection to my point. If you look at Thorpe affair, it's clear that Brianboulton decorated it with sensational quotes that are not discussed or contextualized in the text; if you look at the edit history, it's clear that he defends those strongly (with your help). His points here appear to be designed to support that. Is that observation too much of a stretch? What does that have to do with you reverting my edits there, calling them sub-standard? I'm sorry if my phrasing sounded too much like reading someone's mind, but your retort was much worse. This stuff is real. Dicklyon (talk) 05:27, 30 August 2016 (UTC)[reply]
OK, sounds like this particular case is a fair difference of opinion. About 2% of the article text is in the quotes... at least one of the images is decorative ("The village of Talybont, North Wales, where Scott lived in 1971"... really?) more than the quotes. Without the quotes and the "village of Talybont" image, though, you have quite an arid wall of text facing the reader. Do you see this as a problem, or not? Would the use of {{Quote}} (no borders, no background color) improve the page? Or made a lot of difference to your objection? Or are you maybe arguing for quashing quotations generally? (Which is a legitimate position, but not likely to be passed.) Herostratus (talk) 17:18, 31 August 2016 (UTC)[reply]
I note Dicklyon's comments above. I won't answer them here, because this discussion should not be about the use or misuse of quote boxes on any one article, but about the issue in principle: to what extent if any, the community wishes formally to approve of a usage of quote boxes that, while not currently supported by the letter of MoS, has become widely adopted in many articles. It shouldn't be about the use or misuse of quote boxes on any one article, about which opinions may differ. So, Dick, please put aside for a moment your obsessions with the Thorpe affair (that "excellent article" as you call it) and concentrate on the general point. Or at least, show you are not obsessed by commenting on the use of these boxes in some of the many other articles that use them in much the way I have done. Brianboulton (talk) 22:27, 1 September 2016 (UTC)[reply]
  • I essentially agree that they are mainly used for improper emphasis. They're a common trick of polemical or promotional articles. We normally have no need for this sort of emphasis, and making it easily available is an undue temptation. There are a few legitimate uses, but this is hard to control. Far better to remove all temptations to editorializing. As for reduced size, it's an accessibility issue. Since they're part of the main text, the ordinary reader without using preferences must be able to see all material even with diminished vision. WP is an encyclopedia meant for use by readers, and considerations of use and NPOV are more important that looking like conventional publications. DGG ( talk ) 14:24, 6 September 2016 (UTC)[reply]

Permit Template:Quote box for regular quotes

As was noted at the start of this thread, {{Quote box}} is widely used for regular quotes throughout Wikipedia, including on a great many FAs and GAs. However, Template:Quote box suggests that {{Quote box}} should not be used for this purpose. Thus we have a disconnect between a regulation and reality. Reading through the discussions above, it appears that there is some significant support for bringing about a change that officially permits {{Quote box}} for regular quotes, so can we get more support for this course of action? It would only require a very quick alteration to Template:Quote box and would solve a lot of problems. Midnightblueowl (talk) 09:18, 31 August 2016 (UTC)[reply]

Survey
  • Support as per comments. Midnightblueowl (talk) 09:18, 31 August 2016 (UTC)[reply]
  • Support. I don't think we can get a decision out of this RfC, but I'm starting to think that a regular upvote-downvote RfC on overtly allowing {{Quote box}} as alternative to {{quote}} might be worthwhile. I can see two sources of opposition though: 1) those who don't like {{Quote box}}, and 2) those with maybe no opinion on that but who feel we should have just one active quote template. (One counter would be, horse is out of the barn lets now change the rule to describe practice.) For my part, I would like {{Cquote}} also allowed, but that might not garner as much support? and would complicate an RfC. Herostratus (talk) 16:47, 31 August 2016 (UTC)[reply]
    Note: An editor has expressed a concern that Herostratus (talkcontribs) has been canvassed to this discussion. (diff)
  • Strong Support but according to Brianboulton's viewpoint as above. Quoteboxes should not be used as an alternative to {{Quote}} for regular in-text quotes. Instead, {{Quote box}} (and {{Cquote}}) should be reserved for illustrative text, and used in a way similar to illustrations and photos (which complement the text of the article). LK (talk) 23:33, 31 August 2016 (UTC)[reply]
  • Procedural matter@Midnightblueowl: I hope it wasn't your intention to selectively notify participants in the above discussion of this proposal, was it? Because there seems to be a correlation when looking at the four people you notified ([54] [55] [56] [57]) and WP:CANVASS clearly states that it is impermissible to send notifications based on the user's known opinions. On what basis were these notifications delivered? Graham (talk) 23:37, 31 August 2016 (UTC)[reply]
    • I tried to keep the wording that I sent to those four individuals as neutral as possible. However, I can see the concern here and as a means of correcting it I'm happy to inform everyone who has posted in the above discussion about the new support/oppose sub-section. Everyone who has previously posted in this discussion has now received the same message. That should hopefully deal with any concerns that people have about a particular bias in selection. I just wanted to get participation rolling here, to avoid this sub-section languishing in neglect. Midnightblueowl (talk) 10:16, 1 September 2016 (UTC)[reply]
      • Notifying everyone would certainly help at this stage. But you still haven't explained on what basis those four individuals were selected. Was it completely at random – and the opinions that they hold are just a complete coincidence? Graham (talk) 17:43, 1 September 2016 (UTC) I forgot to ping Midnightblueowl. Graham (talk) 18:25, 1 September 2016 (UTC)[reply]
Pinging Midnightblueowl in case my question slipped under the radar. Graham (talk) 06:42, 3 September 2016 (UTC)[reply]
  • Support Summoned by bot. I would also like to know why these particular people were invited, but I have confidence it was all done in good faith. I think that this should be allowed, partly because it is fairly common, and partly because it just looks better. Tamwin (talk) 04:58, 1 September 2016 (UTC)[reply]
  • Oppose, and procedurally object to hijacking the RfC in a misleading manner. The RfC already asked specific questions, and this !voting section goes off in left field to propose favoritism toward one particular template, when the RfC already makes it clear that it is a distant minority usage in mainspace. It's also already being proposed to adjust the style of the default quotation template to find a compromise between the stable and mostly complied-with MoS consensus for non-decorative quotation formatting, and reasonable concerns that the current default style is a bit too plain. This !voting section serves as an anti-RfC disrupting ongoing attempts to hammer out a consensus solution, by short-circuiting the discussion, whatever the intent for this move might have been.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  10:38, 1 September 2016 (UTC)[reply]

    An earlier comment by EEng vividly highlights exactly why these decorative quote templates are by their very nature serious PoV problems. He states that the intent of their use is to "draw the reader in and spark interest". Doing that to one particular party's quoted viewpoint is a blatant policy violation (WP:UNDUE), and the main reason MOS:BQ has for years said to avoid pull quotes and this sort of abuse of pull-quote templates to single out certain quotations as "special". There are other and more appropriate ways to attract reader interest, without favoring particular viewpoints. But doing so at the intra-article content level is not a WP goal anyway, per WP:NOT#MAGAZINE. Grabbing reader eyeballs for as long as possible, much less precisely steering them to what one editor wants to brow-beat them with, is not WP's job. Neutrally providing information readers actually want, arranging it logically and contextually, and backing it up with reliable sources, is WP's job, and the result is not going to look much like Rolling Stone or the Huffington Post blog. This is not an advertising-funded site, and we have no incentive to use psychological tricks to try to keep people here longer than they need to be here to get what they came for and get on with their lives (much of what WP:NOT policy is about is grounded in this fact). Life is short, and WP is not escapist entertainment in Web form, it's a a particular kind of information source that does note ape every gee-whiz marketing technique of other publication types.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:57, 1 September 2016 (UTC)[reply]

There are plenty of opportunities to use quotes that don't represent any "one particular party's quoted viewpoint", so the rest of what you say is nonsense. EEng 03:00, 3 September 2016 (UTC)[reply]
If it's a quotation, it is either one person, organization, publisher, etc.'s statement, or it's quoting a documentary source (biblical text, Justin Bieber song lyrics, etc). Neither of these needs to be presented in a decorative box. If we had consensus that documentary source quotes should be in decorative boxes (unlikely), we could have a special template for that, limited to such use and not allowed to unduly promote particular viewpoints. Unless and until we do, these template are a policy problem.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  10:50, 5 September 2016 (UTC)[reply]
  • (edit conflict) Support This will bring documentation more into line with widespread use. The use of quote boxes should be allowable if the circumstances of individual articles provide a need. By breaking walls of text they aid reader usability and can explain and highlight in the same way as an image. Someone in the thread above (EEng, I think) suggested the same rationale as an image caption—to draw the reader into the text—and the similarities in use are paralleled here. There is also no "procedural hijack" here, despite the handwaving: the discussion thread above was showing enough of a consensus of opinion toward this option that it's a sensible place to include a vote, unless you really want to pointlessly wikilawyer to force this into a separate proposal. (And before anyone asks, this page is still on my watchlist following my comments in the thread above). To somehow suggest that to draw readers by sparking their interest is "a blatant policy violation" is so far beyond hyperbole it's laughable (It's one of the criteria for a good caption, so an accepted standard on WP). The use of quotes in this way should be in line with other guidelines (such as the caption guideline, as well as weight, NPOV, etc, but it seems crass to do,such a disservice to our readers by denying the use of quote boxes in this way. - Gavin (talk) 06:50, 2 September 2016 (UTC)[reply]
  • Oppose—Has anyone read WP:RFC on the do's and don't's of starting and running an RFC? Agree with SMcCandlish. Tony (talk) 10:47, 1 September 2016 (UTC)[reply]
  • Support, quote boxes are often used to accent a page's information with quoted data which doesn't necessarily appear verbatim elsewhere on the page. Seems a reasonable use of presenting information to the public. Randy Kryn 11:35, 1 September 2016 (UTC)[reply]
  • Comment: Every single support comment here amounts to "Support because WP:ILIKEIT, and ignore all of the policy and other issues raised in the real RfC above, because I can't think of an answer to them. The way to WP:WIN on WP is to avoid discussion and instead engage in just-a-vote until you get what you want." This anti-RfC is essentially nonsensical; you can't invalidate policies and guidelines by canvassing up a WP:FALSECONSENSUS to change some template's documentation.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  13:06, 1 September 2016 (UTC)[reply]
    • Please don't try to dismiss everyone's opinions just because they (shock horror) run counter to yours. There is a feeling of dissatisfaction with the existing strictures of the MoS (a set of guidelines, not something religiously set in stone) I this point, and this is a perfectly valid method of addressing what is a widely ignored flaw in its formation. You accuse participants of "ignor[ing] all of the policy and other issues raised in the real RfC above": that's just not true. Absolutely no-one is ignoring it, its just that people disagree with you. I'm sorry you don't like the emerging consensus to be against you, but that is no reason to besmirch everyone else's opinion. – Gavin (talk) 13:24, 1 September 2016 (UTC)[reply]
      • If people "disagree" about the clearly highlighted policy problems of using these templates to draw undue attention to, and blatantly promote, particular quoted viewpoints, then they can actually explain this alleged disagreement, in discussion, which is what the RfC above is for. WP is not a vote, and simply declaring on behalf of others that they "disagree" with something they have not even addressed at all is not an argument. Nor is presuming to speak for them your job. What "emerging" consensus? As of this writing, it's about an even split numerically, the supports have no policy-supportable basis at all, and that's without counting three multiple [the count keeps going up] canvassing complaints. This should be speedily closed as a waste of time and against WP:RFC instructions.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:57, 1 September 2016 (UTC)[reply]
        • And every single oppose here is based on "IDONTLIKEIT" - the main difference is that no one is going around to article's written by those who dont like quote boxing trying to strongarm and wikilawyer quoteboxes into those articles. In a collaborative encyclopedia there will always be differing aesthetic viewpoints on issues such as this and we should be able and willing to accommodate this diversity whereever it is not clearly detrimental to some other goal of the project. ·maunus · snunɐɯ· 13:10, 4 September 2016 (UTC)[reply]
  • Support, although I'm slightly confused by the meaning of "regular quotes". To clarify: I strongly favour the use of block quotes (where necessary) and quote boxes (for a particularly informative or pertinent quote). Could be wrong but I believe that's in line with what editors such as Lawrencekhoo and Randy Kryn have said above. JG66 (talk) 14:40, 1 September 2016 (UTC)[reply]
  • Strong Oppose – first procedurally, since this kind of tangent within an RFC is likely to confuse and miss those who think they have already responded to the RFC. Second, due to the canvassing that's noted above; 4 editors in favor were notified on 31 Aug, and the rest the next day after this canvassing was noted; I was notified in a very misleading way, with "you may wish to reiterate your opinion in a 'support/oppose' format", but this question was not even asked before. Third, the question seems contradictory on its face: how does "regular quote" relate to a quote displayed in a box? Not in any meaning of "regular" that I know of. Isn't a regular quote one that fits into the prose of an article, in a textual order, as opposed to being pulled out by placement or boxing? Dicklyon (talk) 15:29, 1 September 2016 (UTC)[reply]
  • Slightly reluctant oppose - I don't think they fit the look and feel of an encyclopaedia article, at least not one targeted at adults. As usual I would advocate kid gloves in dealing with cases where they have been used. All the best: Rich Farmbrough, 17:07, 1 September 2016 (UTC).[reply]
  • Oppose per SMcCandlish's remarks in the above sections. This is an encyclopedia, not a magazine or a textbook, and in most any case in which these quotations are as important to the article as some have suggested they are, the quotation should be included in the text of the article itself. I imagine that there are exceptional circumstances that could warrant an exception to this, but I tried looking for an example to use and came up short, which speaks to the rarity of these situations. And I know that these rare situations are not the motivation for the opening of this section – the instigator of this discussion is currently trying to get an article passed FAC that has more than a dozen of these quote boxes.
    I should also note that it seems questionable that this section was opened while the issue was being looked at holistically and consensus was being built in the above sections – especially when the individual who began this discussion appears to have improperly canvassed her supporters here. Graham (talk) 22:56, 1 September 2016 (UTC)[reply]
Your lack of imagination is hardly an argument. I can think of many very good reasons to use illustrative quotes in quote boxes, and no good reasons to oppose them across the board and on principle.·maunus · snunɐɯ· 13:15, 4 September 2016 (UTC)[reply]
  • Comment: I made my views plain in the discussion above this thread and I presume I am not required to repeat them. There seems to be some confusion about the validity of this part of the process, announced as "not a vote", then followed by a list of supports and opposes, and I won't increase the confusion by adding mine. If the consensus is against him, McLandish and/or others will, I am sure, make a procedural objection, so I don't think the matter will end here, alas. Brianboulton (talk) 22:57, 1 September 2016 (UTC)[reply]

Discussion about canvassing allegation
Yeah, there is that. Heh. 20:07, 3 September 2016 (UTC)
    • As this is not a vote, the fact that you did not format your opinion in bold text does not make a difference. And while you contributed to the main discussion, only certain contributors to that discussion were notified of this one for some reason (though the canvasser still won't explain on what basis those people were selected). Graham (talk) 23:49, 1 September 2016 (UTC)[reply]
      • I did not ask to be canvassed, and I had stated my views long before. Is this a procedural excuse to taint or disqualify my views, even though I had absolutely no hand in the process to which you object? Brianboulton (talk) 14:32, 2 September 2016 (UTC)[reply]
        • I did not suggest that your views were wholly disqualified. I'm merely making appropriate use of {{canvassed}} to assist the closer in taking these circumstances into account. Graham (talk) 15:18, 2 September 2016 (UTC)[reply]
          • I think you are misusing the template, by giving the impression that I and other prior contributors were brought to the discussion by a canvass, and that is false. The template should not be used to cast doubt on the views of of existing contributors who had no means of knowing that the canvass was selective. Brianboulton (talk) 21:30, 2 September 2016 (UTC)[reply]
  • I have always thought that the objections against using this kind of template are overblown (I have seen them repeated for a long time). There is no reason to think that an encyclopedia cannot have this kind of quote in its articles, and the fact that the template is used in thousands of articles suggests that others think the template is OK. The MOS should reflect this kind of practice, rather than trying to over-rule it. — Carl (CBM · talk) 01:48, 2 September 2016 (UTC)[reply]
  • Comment -- Agree with Carl, Brian, the thrust of MidnightBlueOwl's argument at the top. Quote boxes are a useful way of breaking up walls of text, of adding quotes that may not fit into the general flow of a paragraph or section. Every content creator on WP makes decisions about how to organise material, and this includes deciding what images to use and where to place them; the same holds true for quotes, whether they be within the general flow of the text, like a block quote, or in the form of quote box. I too am surprised that there is such a fuss about it, I recall years ago when it was recommended to me to use them as an alternative to block quotes in certain circumstances, and have never seen it raised as a concern until recently. I think we all have better things to do with our time. Cheers, Ian Rose (talk) 02:04, 2 September 2016 (UTC)[reply]
  • There seems to be some confusion about what is actually being !voted on here. I will assume the most obvious meaning is intended: I weakly oppose using {{Quote box}} with align=none as a template for regular quotations, i.e. quotations integrated into article text, introduced in proper context, because {{Quote}} does the same thing, using the semantically meaningful <blockquote>...</blockquote> element, and because I prefer its style (and I would like stylistic consistency within Wikipedia). I was "canvassed" by talk page comment but I also participated in the discussion above. Hairy Dude (talk) 13:49, 2 September 2016 (UTC)[reply]
  • Strong support as an editor who writes about language I know better than most that some topics are best illustrated not by images but by text quotes - quote boxes are essential for making quotes that illustrate lingiustic topics by giving examples of language use. QUote boxes can also illustrate an authors style in the same way that an image illustrates a painter's style. Moreover this is one of the places were absolutely nothing is won by having rules so detailed and restrictive that editors are being micromanaged in their usage of wikipedias functions.·maunus · snunɐɯ· 06:39, 4 September 2016 (UTC)[reply]
  • Support Block quotes are useful. It should be up to the article writer as to whether to use them in a certain circumstance or not. We really need to cut the MOS back. The WP:CREEP is getting out of control. Hawkeye7 (talk) 08:55, 4 September 2016 (UTC)[reply]
  • Strong support, pretty much per Maunus. There are numerous instances where block quotes are useful but one doesn't want the quoted material in the body text. In addition to those Maunus cites, one that comes up regularly on visual arts articles is when an artwork is intended to illustrate a particular passage from literature or mythology and one needs to provide the original text from which the artist worked, but doesn't want to drop a big chunk of Middle English into the body text. I agree entirely with those above that the purpose of the MOS is to provide a broad framework in which Wikipedia operates, not to micromanage the individual writing style of each editor to conform with how the authors of the MOS think they ought to be writing. ‑ Iridescent 10:24, 4 September 2016 (UTC)[reply]
To illustrate Iridescent's work-of-art point, it's worth taking a look at Freedom_from_Want_(painting), which has three quote boxes. The first (the Roosevelt quote) is a classic example of appropriate use. The second (quote from the artist) is also fully appropriate, and a great example of a boxed quote adding interest to the article -- it speaks for itself, needs no introduction, and would be awkward and forced if given in the main text (introduced by something like "Speaking of the circumstances of the painting's composition, Rockwell stated..."). The third (quote from an art critic) seems to me the sort of questionable use SMcCandlish worries about: I'm not sure this one commentator's observation (though interesting -- "No one's giving thanks") is appropriate to highlight in this way. EEng 22:16, 5 September 2016 (UTC)[reply]

Discussion about canvassing allegation

Note: An editor has expressed a concern that participants at Wikipedia talk:Featured article candidates have been canvassed directly to this section to vote. ([58])

Neutrally notifying communities that are stakeholders in specific debates is not canvassing and suggesting it is is dishonest.·maunus · snunɐɯ· 10:57, 5 September 2016 (UTC)[reply]
Agreed. A discussion is taking place here that is of concern to numerous FAC editors – why should they not be told about it? Do we really want to suppress opinion is this way? I would remind "an editor" that canvassing means the soliciting of votes in favour of a certain person or position: giving notice of a discussion does not fall within this definition. Mike's note at FAC talk was entirely neutral and responsible. Please stop these efforts to downgrade or neutralise expressions of opinion you don't like. Brianboulton (talk) 13:35, 5 September 2016 (UTC)[reply]
Hardly a neutral action. It was soliciting a bloc vote, directly to the "voting" section, from a tight concentration of the few editors likely to support this style at this particular moment on the basis of emotion instead of reason. As is clear from discussion on that page, the "local consensus" over there is to just oppose any MoS-related "interference" with FAs and stick it hard to all those "MoS obsessives" (insert 10 other anti-MoS-editor incivilities here). There is clearly no regard at all for any of the policy concerns raised in the RfC, which this anti-RfC poll has been engineered to encourage people to not read or participate in, and to instead try to change guidelines by changing one template's documentation to defy them. WP doesn't work that way, and you all know it. This is WP:FACTION and WP:POINT at its worst.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:57, 5 September 2016 (UTC)[reply]
Since I was the editor who posted the note to WT:FAC, I suppose I should respond here for the benefit of whoever closes this RfC. First, if this is determined to be an invalid RfC, as you assert, then these supports and opposes are irrelevant; it seems sensible to proceed as if this is going to be accepted as valid, since clearly many other editors are participating on that basis. Second, is there any reason not to notify editors at WT:FAC, regardless of what the local consensus is there? Surely editors who do a lot of content creation should be notified? You're right that I hoped they would agree with my position, but that's what any editor hopes when they notify any group -- you always hope everyone agrees with you. And believe it or not, I did not know for sure how people would !vote here. I singled out WT:FAC because that's the only community on WP that I have any significant interaction with; you can check my contributions if you like. One thing you'll find is that I almost never edit MoS or MoS talk pages; none are on my watchlist and I rarely read them. I had no idea of the history of all of this till it spilled onto the FAC talk page recently. I'd never seen anything to do with the Arbcom case on infoboxes, and still haven't (though I've commented on the recent request); frankly, I consider myself uninvolved (though of course I have opinions). If you think that bringing FAC editors in is one-sided, please go ahead and leave notices in other forums. I'm willing to assume that you will do so neutrally, and without cherry-picking. And I'm curious to know why you removed the {{unsigned}} template that SarahSV put under the canvas notice; in a discussion this contentious, wouldn't it be natural for editors to want to know that you were the one who posted that notice? I would think so, and I mention it explicitly here partly for that reason. Mike Christie (talk - contribs - library) 23:50, 5 September 2016 (UTC)[reply]
@SMcCandlish:: It is not appropriate to declare that opinions contrary to yours are "on the basis of emotion instead of reason", and to infer that they should be disregarded on those grounds. That is a personal opinion, not a factual statement. I differ from you profoundly on this issue, but fully accept that your views are based on your honest convictions. May I request that you do likewise, with those that disagree with your position? Brianboulton (talk) 13:46, 6 September 2016 (UTC)[reply]
@Brianboulton and Mike Christie: Whether to put quotations in huge boxes has nothing whatsoever to do with content creation. If I only ever spent much time at WikiProject Science Fiction, would it be okay for me to solicit their votes on random subjects? Of course. I did not suggest any particular post here was based on emotion. The FAC view of this is demonstrably dominated by it right now, though. Just go read the WT:FAC discussion. Here's the précis: Two FA editors are quitting under a cloud [59] [I don't know about the third] after months of constant, undeniable, and inexcusable incivility toward everyone but other FA editors, over many unrelated matters that have in common only one thing: FA territorialism. Because FA people don't want them to leave, they are looking for a scapegoat, instead of accepting that some editors go off the rails and need a wikibreak. The dparting editors are said to have erred but hat this should be ignored because of their past contributions and because they're frustrated by disputes ... which they choose to participate negatively in. The scapegoat is, obviously, MoS and any editor who cares that an FA complies with anything in such WP guidelines (plus anyone who wants to argue about citation style, but that's "style", so blame MoS for that, too). Never mind that what these two editors are doing is a behavioral policy problem leading to multiple ANI requests, multiple ARCA requests, etc. Never mind that several content policies are also at issue. Never mind that the primary locus of this disputation is actually infoboxes which are not an MoS matter at all (MoS is neutral on them, and ArbCom, AE, and the dispute participants all insist that they're a content not style dispute). No, the only thing to do is blame MoS, blame MoS, blame MoS, and label anyone who cares about it "style obsessives" and other denigrating names, as if we're on a elementary school playground. No, I'm not going to attract other "votes" to this, because the RfC is up top, and people are still discussing the matters raised in it. This side-topic vote is a waste of time, an attempt to short-circuit discussion by a needlessly polarized red herring.

Trying to change the template's documentation to say you can use it any time you want for anything isn't going to magically undo the fact that we have years of consensus against using pull-quote templates to make block quotations leap out in the face of readers, as a WP:POLICY matter, and that nearly all editors comply with this; the only ones who don't seem to feel that they'e above the rules at "their" articles (see comment immediately below declaring the existence of a separate "FAC community"). It is not an arbitrary "style" rule; like much else in MoS, it's an inevitable interpretation of core content policy. If we want some neutral framing device for documentary sources (the Magna Carta, lyrics from an operetta, the opening of MLK's "I have a dream" speech), we can have a {{Document excerpt}} template for that probably (though people are not at all in agreement that decorative sidebars are the best approach); one that does not use giant quotation mark icons (see MOS:ICONS – more than one guideline is implicated here), and which is strictly limited to such materials, not permitted for usual quotations especially if they represent one side of issue with multiple sides (including from documents, like press releases); then add to NPOV policy an explicit rule to not abuse the template in such a way. But that sort of thing requires a mature discussion, not a "down with MoS!" voting party.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:20, 6 September 2016 (UTC)[reply]

If you could possibly try not to lie quite so blatantly. I have spun through a couple of your posts today, and they really are full of the most utter tosh of divisive nonsense. "Two FA editors are quitting under a cloud" is, I'm afraid untrue. I am neither an "FA editor", nor am I leaving under a cloud (and despite your ramblings elsewhere, although I suspected you were stalking my edits, I did not know (or care) that you were planning on some ridiculous fishing trip to ArbCom by way of further harassment—feel free to file it: it all says much more about you than me). "The scapegoat [for leaving] is, obviously, MoS and any editor who cares that an FA complies with anything in such WP guidelines": yet another deeply untrue claim, I'm afraid. I have said elsewhere why I am leaving: it is the behaviour of a small number of individuals, not something as abstract as a flexible guideline. Your numerous deeply divisive postings over several talk pages are indicative of many things, but a collegiate spirit is not one of them. And no, a malformed and one-sided request is not under a cloud (and the two former Arbs who have contacted me directly don't consider it so: I'll take their word over yours, I think). Again, it may be best of you focused on your own actions, rather than try and smear me over three? four? five? different talk pages: it really does say an awful lot more about you than me. – Gavin (talk) 21:40, 6 September 2016 (UTC)[reply]
  • Support Policy needs to conform to reality. This style is well-accepted in the FAC community and people who seldom create quality content need to stop dictating to those of us who do. Montanabw(talk) 20:53, 5 September 2016 (UTC)[reply]
    • That's unbelievably insulting to millions of editors over the course of WP's history, and over 100,000 currently acive ones. It neatly sums up what this really is: nothing but a territory dispute. At least we're clear that the idea that certain FA authors believe their are a separate "community" not subject to WP-wide consensus is not an illusion, nor is their perception than the only content of worth on WP is their own articles, some tiny fraction of 1% of our actual content. What amuses me about this is that not everyone is interested in FA and GA badge collecting. Many of us just write articles with no regard to these labels. There is lots of GA and FA-quality content on WP that doesn't have these approval stickers. If these processes generate this sort of factionalism, they should be adjusted to not do so, or replaced with something that does not. Cf. ongoing RFARB about our mainpage processes (ITN, DYK, etc.) raising problems for similar reasons.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:20, 6 September 2016 (UTC)[reply]
  • Strong Oppose Pull quotes are evil; boxes nearly so. I am working drip by drip on rewriting Bengal famine of i943 in a sandbox. If pull quotes are allowed, every valued editor who thinks he's saving the world by bashing someone on Wikipedia will have the Churchill "Why hasn't Gandhi died?" quote in huge freaking neon pull quotes, preferably very prominently displayed. Three problems with that: WP:UNDUE,WP:UNDUE, and WP:UNDUE.   Lingzhi ♦ (talk) 23:54, 5 September 2016 (UTC)[reply]
That is an amazingly stupid reason to oppose LingZhi, first of al because the proposal has nothing to do with allowing or prohibiting pullquotes, but to allow editorial discretion in the use of quote boxes. Now the fact that quote boxes may be used to there lend undue weight to things is completely irrelevant because so may literally any other part of an article from pictures to infoboxes to prose. But there are thousands of ways in which quote boxes may be used for purposes that cause no editorial problems of the sort you worry about. Basing a general restriction on editors abilities to determine how to organize articles because the feature might hypothetically be abused in an article you are working on is just not an acceptable form of argumentation. ·maunus · snunɐɯ· 05:33, 6 September 2016 (UTC)[reply]
It's not helpful to engage in name-calling, especially when the reason DS is being considered is all the name-calling.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:14, 6 September 2016 (UTC)[reply]
Come off your hihg horse McCandlish you are about the least civil editor here - with or without namecalling. I happen to consider myself on very good terms with LngZhi who generally is not stupid. BUt that does not mean that this particular argument isnt stupid because it is.<·maunus · snunɐɯ· 07:22, 7 September 2016 (UTC)[reply]
Well, aside from the issue at hand, I'm now concerned about the article Bengal famine of 1943. We can read this page's edit history, so we know you originally wrote "dickhead" where you now have "valued editor" -- and you know we can. It sounds like your intent is to turn the article into a paen to Churchill, and the unfortunate fact that this complicated man did say "If food is so scarce, why hasn’t Gandhi died yet?" and that there is a template to display this stands in your way. But we not inclined to delete our useful templates to comfit culture warriors, so your argument is quite weak. Herostratus (talk) 01:13, 6 September 2016 (UTC)[reply]
Every time I see your username, the text that precedes it baffles me completely. Seriuosly. Stumped. Compuzzled. But for your reading pleasure, do see if there is a paen to Churchil in User:Lingzhi/sandbox. And as for weak arguments...... well...  Lingzhi ♦ (talk) 01:23, 6 September 2016 (UTC)[reply]

Extended content
  • Herostratus: I'm in agreement with your position, but what exactly does a comfit ("a candy consisting of a piece of fruit, a root (as licorice), a nut, or a seed coated and preserved with sugar") have to do with anything?
  • Lingzhi: If seriuosly and compuzzled aren't words, they should be.
EEng 01:28, 6 September 2016 (UTC)[reply]
Well, "comfit" is formed by back formation from "discomfit". Similar to "gruntled", "kempt", "descript", etc. I am plussed by your remembering the candy (rather high-tone for my crowd, I'm afraid.) Herostratus (talk) 01:54, 6 September 2016 (UTC)[reply]
A Google Books search makes me think there's something to Lingzhi's concerns re: WP:UNDUE. Curly Turkey 🍁 ¡gobble! 01:49, 6 September 2016 (UTC)[reply]
Well, off topic for here, so take it over to that article's talk page I guess. Speaking as a dickhead who is apparently unable to string two meaningful words together, I'm not sure how much I can contribute. Herostratus (talk) 01:54, 6 September 2016 (UTC)[reply]
Thanks, both of you. I'm completely gruntled by your responses. Excuse me while I go get sheveled for dinner. EEng 02:55, 6 September 2016 (UTC)[reply]
It is always a mistake to try and resolve a broad, general issue on the basis of an example drawn from one article. The Gandhi box may well be an example of misuse, but to call for a site-wide prohibition on quote boxes on that basis is irrational. Brianboulton (talk) 13:46, 6 September 2016 (UTC)[reply]
  • Speedy close (and strong oppose) – This RFC is not written in a neutral manner and should be speedily closed. As to the issue, our house style is clear per WP:BQ that the {{quote box}} template should only be used for pull quotes. Pull quotes are generally unencyclopedic and almost never warranted, so I therefore strongly oppose allowing their unfettered use, especially once an article reaches the Good Article or Featured Article vetting level. Cheers! {{u|Checkingfax}} {Talk} 06:56, 7 September 2016 (UTC)[reply]
  • Abstain (is this the bottom of the Survey section, it's hard to tell any more). Quote boxes can enhance reader engagement. It might depend on the topic? But I don't really see why quote boxes should be seen as (quote) "psychological tricks". And I don't see why, if there is a majority in favour of some style change, the MoS guideline can't be changed. Or do we have to check the Chicago Manual of Style before we can breathe around here? Martinevans123 (talk) 21:32, 7 September 2016 (UTC)[reply]
    • @Martinevans123: The ironic and sad thing is that this farcical section has distracted everyone from the section higher up, about adjusting the default block quotation template so that it obviates most of the desire to use the more excessive quotation templates, which really shouldn't be used in mainspace. This is the kind of case that WP:SPITE was written about.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:33, 11 September 2016 (UTC)[reply]
      • Ah yes, there may be a touch of irony. But I don't see much sadness. I guess folks must think this is a more important topic to discuss. In fact, one doesn't often see such near-unanimous agreement in discussions, does one? Let's hope no-one starts building fences, eh? Martinevans123 (talk) 16:19, 11 September 2016 (UTC)[reply]
  • Support - frankly if we all started putting pictures of cucumbers in every article, we could start an RfC saying "cucumbers are normally put in articles" and it should be accepted. As a non-notable philosopher once said, the MoS describes what is, not what we'd like to be. Ritchie333 (talk) (cont) 10:30, 8 September 2016 (UTC)[reply]
    • See the stats above in the RfC proper. What is: nearly everyone is using block quotations correctly. The sum total of those who "just don't wanna" have probably all already "voted" here (notably failing to address any of the concerns raised in the real RfC – this is why WP:NOTAVOTE was written). The bulk of uses of the "look at me! look at me!" quote boxes in mainspace are simply due to people copy-pasting them from other articles (they're found in some old FAs, because people resist bringing the FAs into guideline compliance). I know for a fact that users are almost never choosing to use them instead of the {{Quote}} template on purpose, because as an experiment about a year ago I changed 100 articles to use that standard template instead of decorative ones, and was not reverted or challenge even once. The only time it raises any fuss is when it's done to an FA or GA that that is "stewarded" against others' influence by someone who doesn't like MOS:BQ.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:33, 11 September 2016 (UTC)[reply]
Discussion
[moved from survey section by SV]
  • Comment. If anyone objects to my closing this discussion after 30 days, let me know. I'm neutral on the issue; I don't remember ever taking a position for or against blockquotes or quoteboxes in general. I'm offering because I know most of you here, and you know me. That may come in handy; there's a lot to sort out here. I have no objection to multiple closers, although they're hard to come by for these discussions. - Dank (push to talk) 01:13, 3 September 2016 (UTC)[reply]
Let's look at some external sources on this

Much of this can be re-used to improve articles like Pull quote. While I believe "source the MoS!" campaigning is disruptive – our guidelines are determined by consensus, are not articles, and are not dictated by off-WP parties – sources are used to inform that consensus, and we really need some on this matter.

As just one example, here's several statements from a magazine's [see WP:NOT#MAGAZINE] house style guide [60]:

  • "Quotes are used to emphasize excerpts of text." ["Emphasis" is anti-NPoV, especially with a quotation, i.e. with presentation of one person/organization's own viewpoint.]
  • "we need to provide [our readers] with some focus anchors to fix their attention to the most important parts of our articles." ["Steering" readers and trying to make them accept the editor's view of what is important is directly against NOR policy.]
  • "They are used to pull a text passage out of the reader’s flow and give it a more dominant position in the post or the article." [Do I even need to comment? This is anti-encyclopedic on both counts.]
  • But this contrasts very sharply with what they say about block quotes (the kind MOS:BQ calls for): "Just like a pull quote ... block quotations ... are also set off from the main text as a distinct paragraph or block. ...[but] are usually placed within the reader’s flow." [This is exactly what MoS says to do.]

Here's a source for the fact the the style is an explicit "lure", in an definition of the pull quote style, from one of the most reputable publishers in the entire field of online copy and content presentation, SitePoint [61]:

  • "It’s a device designed to isolate and visually highlight a particularly interesting sentence within the body copy. It’s a 'lure' intended to draw skimmers into the content." [Hard to get any clearer than that this is a PoV and NOR problem.]

National Geographic Style Guide, on not misusing pull-quote style for block quotations or sidebars:

  • "pull quotes [should] be just that, material pulled [i.e., repeated] from the text and not stand-alone information." [62]

Just a few examples from a couple of minutes on Google. I haven't even delved into things like The Chicago Manual of Style on this question yet.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:49, 3 September 2016 (UTC)[reply]

All of this is irrelevant because the entire point is that the quote box can and is used for quotes that are not pull quotes. I have never added a pull quote to any article but I have frequently used the quote box.·maunus · snunɐɯ· 05:35, 6 September 2016 (UTC)[reply]
Re-read it, please, and think about what it says, not about what result you demand. The entire point of this material (other than the very last item) is that it's about aggrandizing quotation style and its known effects on readers. The last point, about actual pull quotes and their content is there, and clearly identified as a separate matter, because part of this discussion has also been about whether WP should ever allow reall pull quotes in articles at all. You would also have already known this if you'd actually read the RfC and what it's about, not just the "voting" section on a side issue.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:11, 6 September 2016 (UTC)[reply]
It ridiculous to state that emphasis is inherently anti-NPOV. Writing an article is all about selectively emphasizing information that is most likely to educate a reader about a given topic - teaching requires emphasis. Like everything else in an article from images to the text in each paragraph quotes can be used to unduly emphasize a single viewpoint, and we have rules in place for dealing with POV issues for that reason. You would of course know all of this if you actually wrote articles instead of just pontificating about how others ought to do it. Article writers need flexible tools to present information as best as possible to the reader in a near infinite number of different possible context. This is not done by restricting everyone's tool box so that all must use the same tools that you personally happen to like.·maunus · snunɐɯ· 07:19, 7 September 2016 (UTC)[reply]
Could all parties dial it down a little? We should be collaborating, not fighting. Let's find more common ground, yes? Tony (talk) 07:22, 7 September 2016 (UTC)[reply]
Kill the moderator! EEng 07:26, 7 September 2016 (UTC)[reply]
WP:NOT a classroom, and it is not the editor's job to try to "steer" readers into accepting an interpretation. Doing so violates both WP:NOR and WP:NPOV policies simultaneously. I'm sure we have common ground on not wanting to do that, yes?  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:49, 7 September 2016 (UTC)[reply]

{outdent} If we are going to look at outside precedents for guidance, we should look at encyclopedias, because Wikipedia is one, not magazines or newspapers, which Wikipedia isn't. In an encyclopedia, calling special attention to a quotation should occur rarely because of the nature of an encyclopedia. On the other hand, blocking long quotations, using <blockquote></blockquote> Wiki markup, is conventional throughout publishing for convenience, not for calling special attention to the quotation. Among other virtues, blocking long quotations makes it easy for the reader to find the quotation's beginning and end and eliminates the need to "flip" single quotation marks to double and double to single.—Finell 18:49, 7 September 2016 (UTC)[reply]

I'm not sure I get what you're saying (or maybe I just don't agree): Using <blockquote></blockquote> just indents a section of text. It doesn't really indicate that the text within the tags is a quote (unless you're reading the HTML), but the assumption is that the reader will know this (I'm not sure I agree with that assumption).
I think that if you're going to have quotations separated out from the mainline text at all then you need some way to signal to the reader that it's a quotation. (A valid position would be "No, all quotations should be inline, like this", but I doubt you could win the day (that is, get an MfD to delete all the quote templates and the MOS to deprecate the use of <blockquote></blockquote>)). So then we are down to discussing the details of how to signal to the reader that its a quote. It's a fine line. What you're suggesting is, just use a slight indent. I don't think that's enough, particularly in some layouts. I just don't equate "slight indent" with "universal signal the we are entering a quotation".
SMcCandlish's suggestion (somewhere above) of using slightly smaller text and a slightly darkened background for {{quote}} might be the best compromise we've seen so far. Herostratus (talk) 12:51, 11 September 2016 (UTC)[reply]

Spacing amendment for numbers

I would like to suggest a slight amendment to Wikipedia spacing. In the event that a reference follows a number, that a space or a comma (comma for main article, space for side info box where nothing follows e.g. membership figures) should be used to show the number and the reference number are not one and the same. It can be easy for people to become confused, especially people with reading difficulties such as dyslexia and this seems a small and simple change that can add clarity and help avoid confusion. -- (preceding by User:Helper201 at 4:21, 21 August 2016‎, restored from page rollback)

I'm not sure I exactly follow. Could you give an example? --Trovatore (talk) 20:16, 21 August 2016 (UTC)[reply]
It sounds like she's saying we should not have, say in an infobox, "Population: 187[8]" (no space after the number 187) but rather "Population:187 [8]" (space after the number 187).
We can do this by hand now and people probably do, but since we do proscribe a space before a ref generally, it might be that we need to say "but not here!" somewhere. I would hope not though. Herostratus (talk) 20:46, 21 August 2016 (UTC)[reply]
Ah, I see. I guess I don't have much to add (but will anyway). Right, it seems perfectly reasonable to add a space in that situation, but I prefer not to clutter up the MoS with a million commonsense exceptions for unusual cases. The MoS says it's a guideline that allows for occasional exceptions. If there's evidence that people are being overly rigid about the no-space rule, then I suppose we might have to add an exception. --Trovatore (talk) 21:53, 21 August 2016 (UTC)[reply]
IF we agree that's a common-sense exception, we will in fact need to have a rule about it, otherwise people will remove that space on the strength of the general no-space rule (proof: it is happening today, ergo not everyone agrees that having the space there is obvious common sense). The rule need not be in the main MOS page, just in WP:MOSNUM where all the other nit-picks about numbers are. FWIW, I agree we should have this spacing exception, as long as the ref or other superscripted number is directly contiguous with a preceding numeral or other numerical construction (e.g. a formula), though not with numbers spelled out, like "seven".  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:34, 22 August 2016 (UTC)[reply]
This is probably worst after a superscript: Area of a circle is πr2[1] (although I guess this particular example would be set as math) Kendall-K1 (talk) 01:51, 22 August 2016 (UTC)[reply]
  • For everyday numbers in normal text, no -- the superscripting and brackets make it clear what's going on, and even if a new user is momentarily confused, once you've read even just one article you'll get the hang of it and never be confused again. Math is a different matter, and as already noted that would be typeset anyway -- we could say something like "In the case of mathematical formulas, a space may be added where confusion [etc etc etc]". And to the extent anything like this is done, it should be a {{thinsp}}, not a regular space i.e. the first of the following, not the second
πr2[1] (thinsp)
πr2 [1] (regular space)
(Yes, there's a difference, and yes it matters.) EEng 02:36, 22 August 2016 (UTC)[reply]

References

  1. ^ a b c Tom Lehrer's book of math
Agreed it should be a thin-space; I'd meant to make the same point and [ahem] spaced it.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:56, 1 September 2016 (UTC)[reply]

Hello everyone. Thank you for your responses. I didn't have ideas about aspects such as mathematical equations, so I'm glad this discussion has been able to develop further. The initial aspect that brought me to this was number information in the info box on the right hand side of the page, where you would have say, 'population 567[1]', rather I'd propose 'population 567 [1]'. Instead of no space between the number and the reference number where it may become confused.

This then lead me to observing in text references too, although they aren't always as applicable because sometimes the reference is placed at the end of the sentence, after the full stop, so the divide is clear and this would be unnecessary. I think for in text references a comma would be most applicable (unless as stated a full stop already divides where a sentence ends) because it would look neater than a space and there wouldn't be unnecessary gaps, e.g. 'town ABC has seen a population increase of approximately 500,[2] people per year'. Whereas a space would be used for the info box as there is less information. Also if a bracket follows the number then in this instance I don't think the change is necessary; for example 'population increased (567)[3]', would be fine. The reference could then directly follow as it could not be confused with the number.

Can't agree with a spurious comma. We would not write "...of 500, people per year." so we should not use a comma when we add a ref. Of course in this case "...of 500, people per year.[3]" would be the thing anyway. It is unusual that a reference doesn't follow a comma or fullstop.
I would have some sympathy for a special layout for maths, where a typical text would put an equation or expression on its own line.
But even then we could just as well say:
By Euclid's theorem[3]
rather than conflate the maths and the footnotes.
All the best: Rich Farmbrough, 21:30, 24 August 2016 (UTC).[reply]
Yes, the idea of adding a comma is a complete nonstarter. And I'll say again that the brackets, the superscripting, and the difference in color make it so no one can reasonably be confused for long. I appreciate the OP's concern about dyslexia and so on but I just don't see it. EEng 21:52, 24 August 2016 (UTC)[reply]

How about the addition of a space between a number and a reference in the info box on the right hand side? I can't see any negative aspect to this small change and I haven't seen anyone present one. I know some people may think its obvious but if it could help people and it doesn't have a negative impact I don't see any reason not to allow this.

  • I don't have a strong opinion about permitting a space or some other separator. However, if we add a special case for this, let's also suggest that the situation should simply be avoided wherever possible. Something like: "When possible, avoid placing a reference directly adjacent to a numeral, as it may confuse readers. Consider rewording the sentence, replacing the numeral with a written number, or moving the reference to a different part of the sentence." Pburka (talk) 23:34, 26 August 2016 (UTC)[reply]
I'm sorry, but for simple standalone numbers (i.e. a string of Arabic numerals, not a mathematical formula that maybe ends with a numeric constant) I just don't see how anyone can reasonably be confused. I think we're worrying over nothing, at least for the case I've described, which comes up frequently in e.g. infoboxes. EEng 03:21, 28 August 2016 (UTC)[reply]
I agree with the idea of advising that people rewrite to avoid when possible; this is standard MoS advice about any potentially confusing construction.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:56, 1 September 2016 (UTC)[reply]
PS: Also agree that adding a comma is a no-go; that's semantically nonsensical.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:11, 3 September 2016 (UTC)[reply]
Fine to advise "rewrite where confusing", but we shouldn't be suggesting that The 1960 population was 123,000[1] and ... is confusing. It's not. EEng 23:05, 5 September 2016 (UTC)[reply]
As the discussion above indicates, not everyone agrees. Not sure what else to tell you. I'd never thought of it as confusing myself, but it certainly would be after a mathematical expressions, since someone could mistake it for something having to do with an exponent.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:01, 6 September 2016 (UTC)[reply]

About "MOS:NOTUSA"

(Clarify: I am talking about the paragraph linked by the MOS:NOTUSA shortcut.)

This paragraph claims: "US is more common in most other national forms of English." Is there any evidence for this? To me, as a Brit, "you-ess" sounds utterly American, and it is much more natural to call it USA. I am, of course not arguing with the situation for AmE, but the fact even that this shortcut (NOTUSA) had to be invented rather suggests that "USA" is indeed what it is called by many (at least non-American) people. Imaginatorium (talk) 19:32, 25 August 2016 (UTC)[reply]

I needed to read the paragraph of this section of the talk page to find out what it was talking about. When I simply read the heading, I thought the subject was whether WP:NOTUSA should re-direct to WP:WORLDVIEW because I thought it meant don't treat Wikipedia like it's a primary American encyclopedia, not don't use the USA abbreviation. Georgia guy (talk) 19:43, 25 August 2016 (UTC)[reply]

Imaginatorium: Lots of Americans use "USA" also. But mostly in relatively informal contexts — patriotic songs, sporting events, things of that nature. The "US" abbreviation better fits the formal tone of an encyclopedia. --Trovatore (talk) 20:00, 25 August 2016 (UTC)[reply]
Thanks for comments: I just clarified above (I hope). My point is that to me, it's the other way round: "US" is an American informality, whereas the full name of the country is "United States of America", abbreviated USA, and distinguished from various other sets of united states. I can see an argument that the Americans want it to be referred to without the 'A', and people should be able to decide their own names, but I think this should be clarified, or backed up by some evidence (e.g. a British style guide). Imaginatorium (talk) 04:50, 26 August 2016 (UTC)[reply]
I agree with Imaginatorium; there's nothing "informal" about the use of "USA" or "U.S.A." outside the United States. As just two examples, it's the standard abbreviation in the World Checklist of Selected Plant Families and World Spider Catalog, which is why you'll find this form all over Wikipedia in lists of plant and spider species. The MOS guidance on this subject is not neutral with regard to ENGVAR, as it should be. Peter coxhead (talk) 05:32, 26 August 2016 (UTC)[reply]
"US" is far preferable; "USA" is starting to sound distinctly old-fashioned ("USA Today"). Tony (talk) 06:47, 26 August 2016 (UTC)[reply]
"United States" is the standard form in Australia, required by our style guides. Hawkeye7 (talk) 06:32, 26 August 2016 (UTC)[reply]
Which "styleguides" are those? If you're referring what is disparagingly known as the "Snook Book", the federal govt thing, it's contemptible. Tony (talk) 06:47, 26 August 2016 (UTC)[reply]
In the past, I think "the US" would have been considered an informal shortened form of "the USA", but I'll have to agree with Tony that "the USA" is now becoming old-fashioned. As an American, what strikes me as odd is the lack of periods/full-stops after "U" and "S" [and "A"]. We always write, "the U.S." or "the U.S.A."  – Corinne (talk) 18:14, 28 August 2016 (UTC)[reply]
Who's "we"? That's something my father did, sure. It's more prevalent in the South, and among military, government and law people, but in great decline otherwise, probably because most US newspapers have abandoned it in headlines (except publishers those that use all-caps for headlines). I agree that it has changed within living memory; I remember a time when "the U.S." (with or without periods) was considered a little informal, but I'm going back to the early 1980s for that.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:27, 1 September 2016 (UTC)[reply]
That's a good example of the influence of ENGVAR on what seems old-fashioned. The full stops in "U.S.A." are very old-fashioned to me, being British, whereas "USA" merely seems more formal than "US". I'm in favour of allowing all four forms, so long as there is consistency within an article. Peter coxhead (talk) 19:17, 28 August 2016 (UTC)[reply]
Here in Yankeeland, "USA" is what cowboy-hat-wearing yokels chant when they hear we bombed someone again. Not exactly unrelated, it's also used in a sporting context. Its use as an abbreviation in general, formal writing verges on an exonym at this point, the way Germans feel about being called "German", I think. Heh.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:27, 1 September 2016 (UTC)[reply]
Style guides very commonly say to use "United States" as a noun, and "US" only in an adjectival construction ("US-based company", etc.), a rule WP should consider since it is so frequent and serves the purpose of clarity and avoidance of informal tone (or at least consider a version of it, e.g. "as an adjective, in tables, [etc. – whatever we think is needed for WP]"). Far too often, articles start with something like "JoeCo is a US weasel-shaving company...".

I've never seen a style guide outside the US say to spell it "U.S.", other than one newspaper's (maybe The Economist, I forget off the top of my head, and I have those books inaccessible right now due to some wall construction). An increasing number of American style guides have abandoned "U.S." for "US". Even the strongest bastion of that usage, outside the "U.S." government itself – American journalism – has turned radically inconsistent on the matter in the last decade, with the AP Sylebook abandoning the dots in headlines but retaining it in regular text, and some non-AP publishers doing the exact opposite, others using "US" exclusively, others "U.S." exclusively, and many (especially online) news sources being internally inconsistent on the matter. Many academic guides still favor "U.S.", except in the sciences, but they have slow update schedules (e.g. the last Chicago Manual of Style came out in 2010, and we're not likely to see a new one until at least 2018 but all accounts, possibly 2020). Even so, the very conservative Chicago itself now prefers "US". I've ever seen any style guide, anywhere, newer than the first half of the 20th century say to use "USA" or "U.S.A.", and even those that favor "U.S." and admit of "USA" ins some contexts say to avoid "U.S.A.", on the principle that conventional English practice is to drop the points from acronyms (anyone seen "N.A.T.O." since ca. 1984?); many specifically advise against the TLA version as archaic or colloquial. Its near-extinct use as an abbreviation in running prose should not be confused with its use a symbol in tabular data, like Olympic sports scores (IOC, FIFA, etc. use TLA country codes), the compressed data of field guides in which "US" might mean something else, in documents that use the three-letter ISO standard for all countries, etc.

As I indicated about a year go, we should eventually revisit whether to continue to permit "U.S." except in specific contexts (like U.S. government ones: "U.S. Secret Service", "U.S. Air Force", "U.S. Supreme Court", when these are abbreviated at all). We should reconsider whether consensus may change on this, maybe in another year or so, because of the rapidity with which real world usage has been shifting, the frequency with which people use "U.S." and "UK" side-by-side despite MoS saying not to, the countervailing infrequency with which anyone reverts a change of "U.S." to "US" in AmEng articles, etc. Per WP:CREEP we should eliminate rule-making that does not serve a clear purpose, and per common sense, a rule that amounts to "do whatever you want" in many circumstances isn't kind of pointless. We have the wording we have now as a hold-over from a 2000s, wishy-washy period in MoS's development when it was full of a lot of "meh, whatever" un-rule verbiage, and was prone to a lot more "my way the only way" editwarring. More editors understand today that MoS's purpose is a "pick something and stick with it instead of fighting about it forever" guideline for consistency, stability and dispute prevention, rather than a pseudo-article codifying what is "right" according to nationalist prescriptivism, or a descriptive-linguistics listing of every possible variation.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:27, 1 September 2016 (UTC)[reply]

I'd like to point out that the full official name of the United Kingdom is the "United Kingdom of Great Britain and Northern Ireland". I haven't seen the unwieldy abbreviations "U.K.G.B.N.I." or "UKGBNI" used anywhere; Wikipedia editors seem happy with the simple abbreviation "UK". Similarly, the "United States of America" can be abbreviated as "US" without much confusion. Reify-tech (talk) 19:42, 3 September 2016 (UTC)[reply]
Well, there is easy confusion with just US -> see the united states ambiguity page, additional to the potential confusion with "us" (US_(disambiguation)). USA is more specific by just one cheap letter. USA is already internationally in wide use. "United States" is an informalism maybe valid and working inside the USA, but not outside. WP should give the international perspective, so we should support the more clear and specific USA instead of the informalism US and WOS#NOTUSA should be not WP recommended or required. Shaddim (talk) 08:50, 6 September 2016 (UTC)[reply]
Well, that and virtually all style guides say not to use "US" as a noun, except sometimes in news headlines and not often even then. People can't have it both ways. Either MoS is largely grounded in what other style guides (especially academic/book publishing ones) are doing, adjusting for WP-specific needs and consensus, or we're just making up random crap to suit our whims. Historically it has been the former, and I would strongly resist that changing.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:58, 6 September 2016 (UTC)[reply]

5.9 Ampersand

There are a couple of cases listed in the main article on ampersand which are not mentioned in MOS:AMP

° In film credits for stories, screenplays, etc., & indicates a closer collaboration than and. The ampersand is used by the Writers Guild of America to denote two writers collaborating on a specific script, rather than one writer rewriting another's work. In screenplays, two authors joined with & collaborated on the script, while two authors joined with and worked on the script at different times and may not have consulted each other at all. In the latter case, they both contributed enough significant material to the screenplay to receive credit but did not work together.

° The ampersand can be used to indicate that the "and" in a listed item is a part of the item's name and not a separator (e.g. "Rock, pop, rhythm & blues, and hip hop").

I could be WP:BOLD and just add them in, but I wasn't sure if this applied to policies (as opposed to general articles). Almonaster (talk) 03:13, 31 August 2016 (UTC)[reply]

Thanks for asking. Yes, bold (but careful and thoughtful) editing even of policies and guidelines is OK; just don't be miffed if someone disagrees, reverts, and wants to see it discussed more first. It wouldn't hurt to pause and see if you get more reactions here though. Dicklyon (talk) 04:10, 31 August 2016 (UTC)[reply]
@Almonaster: I would be surprised if such a change went uncontested. I for one might question whether such fine distinctions, meaningful to perhaps one percent of readers, would be worth the increase in complexity and decrease in consistency, which are often overlooked or dismissed. ―Mandruss  04:45, 31 August 2016 (UTC)[reply]
Paragraph 2 of the introduction says: "Any new content added to the body of this page should directly address a style issue that has occurred in a significant number of instances."
Wavelength (talk) 05:15, 31 August 2016 (UTC)[reply]
I agree about adding complexity and overly subtle distinctions, and that it's only worth making changes that actually address a significant problem. Now if only that approach had been taken re hyphens and dashes. N-HH talk/edits 11:29, 31 August 2016 (UTC)[reply]
I will readily concede that the R&B case can be dropped - if it arises then an editor would probably be aware of it and find a solution.
The film credits case, I think is more serious, particularly because it is not readily apparent unlesss you are familiar with the distinction. Would it be a "significant" problem when an editor who is unaware of this inadvertently changes the meaning of an article by blindly applying consistency rules?

Almonaster (talk) 22:36, 31 August 2016 (UTC)[reply]

Wikipedia uses semicolons for such distinctions, as described at MOS:SEMICOLON.
° Semicolons are used in addition to commas to separate items in a listing, when commas alone would result in confusion.
Confusing:   Sales offices are located in Boston, Massachusetts, San Francisco, California, Singapore, and Millbank, London, England.
Clear: Sales offices are located in Boston, Massachusetts; San Francisco, California; Singapore; and Millbank, London, England.
Wavelength (talk) 15:55, 31 August 2016 (UTC)[reply]
I was aware of that use of semicolons, but I fail to see how it assists in either of the two cases I was concerned about. Almonaster (talk) 22:36, 31 August 2016 (UTC)[reply]
"Rock; pop; rhythm and blues; and hip hop". Does that help you see? --RexxS (talk) 23:20, 31 August 2016 (UTC)[reply]
Yes, thanks. It seems unnatural to me, but it is a valid solution, and I would agree there is no need to change things just for this.
Do you have any suggestions for the accreditation case (see my reply to others above)?Almonaster (talk) 01:35, 1 September 2016 (UTC)[reply]
Do you have any suggestions for the accreditation case - Give us a real-life case, and we might have suggestions. Per Wavelength's first comment, we shouldn't add guidelines to address problems that haven't been demonstrated to a significant degree in actual article content. The dismissive/glib term (which I dislike) is "a solution in search of a problem". ―Mandruss  02:25, 1 September 2016 (UTC)[reply]
Serial comma works for me: "Rock, pop, rhythm and blues, and hip hop". All the best: Rich Farmbrough, 17:16, 1 September 2016 (UTC).[reply]
Agreed that will work for genres.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  15:58, 4 September 2016 (UTC)[reply]
Stick with the semicolon usage in infoboxes, and use "and" in running prose. If the collaboration was especially close, or someone rewrote someone else's script, these are facts WP would tell readers in plain English, not cagily hint at with typographic tricks almost no one would notice or understand. Wikipedia is not film credits, and is not written in the style of film credits. We shouldn't add such extremely topical nitpicks, since every other field may have different and conflicting "oh so special" uses for ampersands or whatever; see WP:SSF for an detailed explanation of why. We cannot account for them all since they conflict, and we should not try to, per WP:CREEP, since there could be hundreds of them for "&" alone. It's more important that WP be written consistently for a general audience that try to exactly parrot a specialist usage that is meaningless to anyone but specialists steeped in it. Attempts to do things like this very frequently erupt into protracted, productivity-sucking battlegrounds; there have been many of these, including attempts to capitalize the vernacular names of species of certain things (and then of all organisms) because journals in a few fields like to do it that way; many years of insistence on using a comma before "Jr." or "Sr." as the "only" "American" way to do it, when sources did not support such a notion after around the late 1980s; still-ongoing squabbles over pop-music orthography (& vs. "and", and "The" vs. "the" in names like "George Thorogood [and|&] [the|The] Destroyers"; capitalization of short prepositions and even "a", "and", etc., in song titles); and a zillion others. If it's not the way something from Oxford University Press or the University of California Press or some other major, high-end nonfiction publisher would do it, in a work for a general audience, it's probably a poor idea on Wikipedia. PS: Even for "close collaborations" that are notable and have articles as collaborations, we already almost entirely use "and" not "&" and this seems to be well-accepted and stable; e.g. Gilbert and Sullivan, Currier and Ives, and many, many others. There are a few "&" holdouts, like Simon & Garfunkel, and Crosby, Stills, Nash & Young, but these could be normalized via WP:RM. The problem with retaining them is they inspire more "&" everywhere; people will mistake it for "the Wikipedia style", exactly the problem that lead to trying to capitalize all species common names, and the current problem of people converting block quotations into decorative quote boxes (see RfC above).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:49, 1 September 2016 (UTC)[reply]
I quite often change "&" to "and", probably on a daily basis, and certainly prefer the "and". Yet I've never changed, nor think we should, a real world name of something which already includes the "&" (Dungeons & Dragons, Crosby, Stills, Nash & Young & such). That was, and still is, the problem found in the Jr. comma debates - since Wikipedia is an encyclopedia, and not a press or style guide, it should reflect the name rather than change it for style purposes. I would love to see all the "&"'s be gone, but not when they are part of an actual name of a film, group, song, or ice cream bar. As for Simon &and Garfunkel (I prefer Garfunkel and Oates), two of their studio album covers, Bridge over Troubled Water and Parsley, Sage, Rosemary and Thyme, contain "and", as do most of their collection including Simon and Garfunkel's Greatest Hits. Randy Kryn 23:08, 1 September 2016 (UTC)[reply]
Then we should definitely change that one to Simon and Garfunkel; per MOS:TM we don't retain a marketing stylization unless it's used consistently by the subject and by the RS (e.g. M&M's, where we also retain the questionable apostrophe since it's in the official name and virtually all RS retain it, unlike the ! in Pink (singer)'s P!nk logo or the caps in Sony's SONY logo. Dungeons & Dragons is a different case; we don't change & in the title of published works (and pretty much no one else does, off-WP, either). For bands, people are going to argue about this until the end of time. Bands are very often self-inconsistent, either generally, after a label change, or whatever. E.g. Siouxsie and the Banshees is spelled at least four different ways (and The, & the, & The on their albums, and not at all consistent in sources. While a few are consistent on albums, even in exact logos sometimes, they usually are not in sources, but are more consistent in RS than bands that aren't self-consistent. For my own playlists, I use & The as a convention consistently, just to distinguish cases that are not of the form "Name & The Somethings" but are phrases that happen to have "and the" in them, like "The Earth and the Starry Sky" or whatever. Then you have character substitution complications like Florence + The Machine (or is it + the?) It's headache inducing. I would rather we settled on exact thing, and used the standard "stylized as" parenthetical. It makes it easier for editors, for reader who figure out we have a standard a approach after seeing a few band articles, reflects actual sources usage (some do use the stylization, some don't), obeys MOS:TM (since some don't, default to non-stylized), yet preserves the official name in the lead sentence. An all-win situation. It's just a matter of what to standardized on. I think the most WP-consistent would be and the. Could also apply this by default (don't we already) to company names, again with MOS:TM exception that if almost all the sources consistently "honor" and & or + or whatever, we should too. The one thing we don't do is just say "WP:OFFICIALNAME always wins; the whole point of that page is that it's often a lower-rung concern at all.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:45, 3 September 2016 (UTC)[reply]
After looking further at the album and single covers and names, Simon and/or/& Garfunkel would be an obvious candidate for a name change. I think after that the question would again fall back on the names of Wikipedia articles on their compilation albums, which are inconsistent (and where editors like myself would want to retain the '&' on the pages which feature album covers which were published with it). Even the concert in Central Park album contains 'and' instead of '&', and overall it seems neither of the principals cared very much which way the name went. Randy Kryn 11:24, 4 September 2016 (UTC)[reply]
Yeah, the album names should retain "&" if published that way (and not republished with "and"). There are some cases (can't name them off top of head, but remember that they're in my playlist) where a song and its album share the same name except for an "&" versus "and" difference. Bands seem to like to do this "clever" stuff, e.g. Tool's "Ænema" and Ænima.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  15:56, 4 September 2016 (UTC)[reply]

Why not just "%" across all pages?

In the section on numbers, it says "Write 3%, three percent, or three per cent..." Why don't we use "%" by default? There are three good reasons: (1) It's a simple symbol that is recognized easily and globally. (2) It saves 6 (!) characters. (3) It solves the dilemma of having to choose between "percent" and "per cent". Since Wikipedia is all about finding common ground, I think that adopting "%" is an obvious case. Let me know if you support this. If not, I would love to hear reasons against "%" by default. EngvarB consistency (talk) 19:40, 2 September 2016 (UTC)[reply]

Because consistency isn't everything, and unless there's evidence MOS needs a rule on something, then it needs to not have a rule on that thing, because it's huge and clumsy enough as it is. Is there any evidence editors are wasting time arguing over this? (Saving characters is, of course, an absurd argument, except maybe in infoboxes and tables, where the guideline encourages use of % already.) EEng 20:07, 2 September 2016 (UTC)[reply]
But there is a rule already, it says: "Write 3%, three percent, or three per cent." What I'm saying is that it could just be "Write 3%". I have seen many articles with a "percent" here and a "per cent" there, and a "%" in between. It's less distracting for readers if there is one uniform style. That's the whole point of a Manual of Style. EngvarB consistency (talk) 20:58, 2 September 2016 (UTC)[reply]
For the same reason that we don't have the 'rule' say just "Write three percent". We don't force a style preference when there are multiple equally valid alternatives. The consistency issue is a different problem, and one for which we already have guidance. The opening section of Manual of Style states Style and formatting should be consistent within an article, though not necessarily throughout Wikipedia. Where more than one style is acceptable under the Manual of Style, editors should not change an article from one of those styles to another without a good reason. Edit warring over optional styles is unacceptable.[b] If discussion cannot determine which style to use in an article, defer to the style used by the first major contributor. If a style or similar debate becomes intractable, see if a rewrite can render the issue irrelevant. You can change articles with a "percent" here and a "per cent" there, and a "%" in between to use a consistent format without needing any more 'rules' than we already have. --RexxS (talk) 21:30, 2 September 2016 (UTC)[reply]
I think many would agree that the encyclopedia would be better if we settled on one choice or another (for this and many issues), but it would likely be impossible to settle on which choice that should be. We have accepted the compromise that individual articles should be consistent even if Wikipedia is not.  SchreiberBike | ⌨  21:45, 2 September 2016 (UTC)[reply]

Thanks for the answers. It makes more sense to me now. So the general rule is: always consistency within articles, in some cases across articles. I'm a bit surprised though that (if I understand the manual correctly) the default for quotations is "logical style", not typographical. I would have thought that quotation style would be a much more controversial issue to be standardized than for example "%"... EngvarB consistency (talk) 22:43, 2 September 2016 (UTC)[reply]

It was, trust me. EEng 22:46, 2 September 2016 (UTC)[reply]

The "3 percent" or "3 per cent" style, like "three%", is a sloppy mix-and-match of numeric versus spelled-out styles (cf. "a 3 cm worm", or a "three-cenitmeter worm" or "three-centimetre worm"). The divergent spellings per permitted per WP:ENGVAR; it's somewhat conventional though not universal to use per cent in British and some other forms of Commonwealth English dialects (I don't recall seeing it in Canada when I lived there, though).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:50, 3 September 2016 (UTC)[reply]

We can often go either way in Canada. See, eg, this directive for federal government translators, though I couldn't say with confidence that the "two-word spelling is more common in Canada" as it does. Graham (talk) 22:19, 3 September 2016 (UTC)[reply]
General rule of thumb with Canadian English: We can usually go either way with most spelling differences – we're too polite to correct anyone. Graham (talk) 22:23, 3 September 2016 (UTC)[reply]
Right! The hilarious book How to Be a Canadian has a whole chapter on all the ways to say "I'm sorry".  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  15:49, 4 September 2016 (UTC)[reply]

Use curly apostrophes and quotes

I think Wikipedia should follow using curly/smart quotation marks and apostrophes. Possibly in VisualEditor would convert to smart/curly ones ("Text" would convert to “Text” automatically, and for apostrophes, it will convert from 'Text' to ‘Text’ (“smart” quotation marks and “smart” apostrophes). I think straight/dumb quotes and apostrophes look so weird, so curly/smart ones would be better. Also in WP a bot would convert straight to curly quotes. If you use VE, if you type ' and " whey will be converted to smart ones automatically. Thanks. 46.130.146.196 (talk) 16:08, 3 September 2016 (UTC)[reply]

that you think straight QMs and As "look so weird" is hardly a sufficient counter to the arguments given for the use of straight marks. (And I think straight marks look fine, particularly in the small-size san serif font that's the default here.) Jeh (talk) 16:21, 3 September 2016 (UTC)[reply]
Be nice. I think curlies look better too, but I know enough to know that ship sailed long ago. The OP has no way of knowing that. EEng 16:31, 3 September 2016 (UTC)[reply]
My ship sailed long ago too. Randy Kryn 19:02, 3 September, 2016
Dang, Randy... and I thought I was old! (j/k) Jeh (talk) 06:41, 4 September 2016 (UTC)[reply]
This was proposed (by me) only a few months ago and rejected. We probably shouldn't re-open this discussion more than once every year or two (maybe even longer) without a major new rationale, or it's going to be seen as tendentious lobbying. Basically, this is going to happen eventually, when all the technical problems with it are resolved, but not sooner.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:07, 4 September 2016 (UTC)[reply]

The technical impediment, and approaches to it

If I recall correctly, the issue is that in-page text searching in some browsers treats the string “foo” and the string "foo" as different. While this is desirable in a text editor used by coders, it probably is not when reading an article.

I would suggest that the way to expedite resolution of this issue would be to (perhaps with the help of others) identify what browsers have this problem, track down how to file bug reports against each affected browser at the various companies/projects that make them, and set up a page (here or elsewhere) tracking progress on getting this resolved by the various browser makers. These things can actually be resolved with such pressure. About a year ago, I got a contradiction between the W3C HTML5 Specification and the HTML/CSS Cheatsheet corrected, and have since reported the correction to WHATWG so they can correct their own HTML5 Living Standard (which is based on the Cheatsheet not the full Specification, and last I looked has not been updated yet on the matter in question, the use of the <cite>...</cite> element).

Failing that, I wonder whether Mediawiki-embedded Javascript could actually deal with this and other problems, by intercepting calls to the page-search feature and munging the data before it is submitted. I'm skeptical this approach is feasible, since the search feature is not part of the Document Object Model. But then again JS can be used to do other [mostly obnoxious] interface things like remove the tool bars and navigation buttons. So, it might be worth looking into.

Anyway, the point is, just demanding the change periodically isn't going to make it happen; fixing or working around the problems that prevent the change is what has to be done, if they're not just going to evolve away by themselves over time with increased browser consistency.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:07, 4 September 2016 (UTC)[reply]

A technically similar problem: copy-paste (or lack thereof) of CSS-generated material

We have similar problems with the copy-pasteability of lists; many browsers drop the numbers/bullets, and I worked up a technical solution for this problem, at Category:Copy-pasteable list templates, but it is not often used because its a set of templates, not the built-in list formatting wikicode.

This limitation is also true of other CSS-generated characters like quotation marks auto-provided by the <q>...</q> element. If it weren't "broken", we should be using this for inline quotations, and MOS should be recommending it. But the current behavior here is very undesirable: <q>This is a quotation.</q> gives: This is a quotation. In Opera on OS X, as just one test, the auto-generated quotation marks cannot be copy-pasted, and this really terrible for WP:REUSE. We can fix that one copy-paste problem by not having the element generate any quotation characters and require that those be done manually the way we already do them. This will require a change at MediaWiki:Common.css, then a bot that hunts down instances of <q>...</q> and replaces them with "<q>...</q>" if they do not already have quotation marks around them, or are not using inline CSS to provide non-English quotation marks for some special case where we're illustrating those (it would be best to replace such cases with Unicode characters for the guillemets or whatever, and not try to use the <q> element for that).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:07, 4 September 2016 (UTC)[reply]

Double spaces after period?

I have recently been removing double spaces after periods on various articles and than another editor came to my page and told me that it wasn't a good idea. I have never seen or heard about the use of "double spaces" in this day of age, and most of Google agrees with me, since when you search up "Should you put two spaces after a period?", most of the search results are against double spaces. The article Sentence spacing also says that "The desired or correct sentence spacing is often debated but many sources now say additional space is not necessary or desirable." I'd just like to get everyone's opinion, thanks. Hawkeye75 (talk) 06:22, 4 September 2016 (UTC)[reply]

Please don't edit to remove double spaces. All you do is make their defenders (I'm one, for full disclosure) angry, without actually making any visible change whatsoever to the rendered page. HTML already collapses multiple spaces, unless you use a "hard space" (for example, &nbsp;). I wish it didn't, but it does, so your edits don't make any difference except when viewing the source. --Trovatore (talk) 06:26, 4 September 2016 (UTC)[reply]
See no one explained to me that HTML removes double spaces automatically... I always use visual editing, so now I understand that it doesn't translate to the actual article. Hawkeye75 (talk) 06:30, 4 September 2016 (UTC)[reply]
Excuse me, but I absolutely did explain that in my first comment to you on this subject. I said that those edits of yours "do not affect the rendered text", and I also gave you an example to look at: "For example, the previous sentence has two spaces after it, while this one has just one. You'll notice that they render the same". (And they did, and do.) I also wrote there (again, in my original cmt to you) "While such edits do not affect the text seen by the reader..." (emph. added). I'm not sure how I could have been more clear. Jeh (talk) 06:38, 4 September 2016 (UTC)[reply]
A space takes one byte, so removing extra spaces reduces an article's size, and then it loads quicker. The benefits are more easily recognized when loading large articles. Because the extra space isn't rendered, as mentioned above, I'm not sure why people advocate its use within Wikipedia: All it does it take up more server space, unless I'm grossly mistaken. When push comes to shove, Hawkeye75, AutoWikiBrowser will be the tool to use to remove them all. Fdssdf (talk) 06:53, 4 September 2016 (UTC)[reply]
Correct imho. Not a huge difference, but they're a waste of bandwidth and server space. Just eliminate them. Using regex on AWB would be fairly easy. EvergreenFir (talk) 06:57, 4 September 2016 (UTC)[reply]
No, not correct, and Fdssdf is indeed "grossly mistaken". Anyone who thinks this has anything to do with performance, "server space", or anything else has no idea at all how any of this works. Stop tinkering and do something to actually contribute. EEng 07:11, 4 September 2016 (UTC)[reply]
The extra space is a contributing factor only to performance, even if negligibly. I'm not mistaken about that, even though you seemed to suggest it of I and EvergreenFir. The separate matter is whether they're worth addressing with AWB: A negligible existence is a negligible absence. Fdssdf (talk) 16:27, 4 September 2016 (UTC)[reply]
Oh, please. The extra spaces won't make a noticeable difference in page load time because a) they are not sent to the client's web browser anyway. The renderer converts the wikitext to HTML and excludes them in that step (you can verify this with the "view source" feature of your browser). And b) disk read time and rendering time at the server is far from the limiting factor in "page load time". Re disk space, removing them, in most cases I've seen, takes far more server space (for the entry in the edit history) than the removed spaces used up! The reason many people (including myself) like them is the same reason they're commonly used and even recommended in typescript: they make sentence boundaries in the edit window easier to see.
And re AWB, please see WP:AutoWikiBrowser#Rules_of_use, rule 4. You're not supposed to do that. Jeh (talk) 07:25, 4 September 2016 (UTC)[reply]
It's a pity there's no way of enforcing Rule 4. I checked my overnight watchlist changes and about a quarter of the edits were of the same level of pointlessness – adding/removing spaces, capitalizing wikilinked text, re-ordering template parameters, etc. More important than server resources, this wastes editor time. Peter coxhead (talk) 07:44, 4 September 2016 (UTC)[reply]
Oh, there are ways to enforce it. You suggest to the editor that they stop, pointing out rule 4; if they persist, try again; if they still persist, follow the complaint chain. AWB privileges have been revoked before. Jeh (talk) 10:06, 4 September 2016 (UTC)[reply]
Do be aware, though, that these minor changes are permitted as "ride-along" changes if something substantive is done in the same edit. The majority of time I see these minor changes being made by AWB, it's along with some actual correction that affects visible output. Just saying, beware filing a false report of abuse; it would probably be received like any other false accusation at another noticeboard.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:22, 4 September 2016 (UTC)[reply]
  • Oppose. This is perennial "I wanna force everyone to code the way I do for subjective trivia reasons" rehash, repeatedly rejected. The double-spacing of sentences in wikicode makes the code easier to read, and has no effect on the rendered output. People are not (except perhaps under the rarest of circumstances) reading WP over 300-baud modems, so a few bytes of space characters would be totally irrelevant even on a regular webserver. But, as noted above, the MediaWiki parser strips them before it sends the page out, anyway. The MediaWiki and WMF developers have repeatedly told us that we never need consider server performance (software or hardware) for tiny matters like this. The things that matter in that respect are much more serious (details elided, per WP:BEANS). What is it with the sudden rash of "let's do misguided things to MoS" showing up all in a row?  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:22, 4 September 2016 (UTC)[reply]
  • Oppose actively removing of harmless double spaces. Any supposed (and un-provable) benefit has been more than offset by the space consumed by just this one discussion. Making changes with no effect just adds clutter to the change log, making the job of people reviewing changes harder. It has measurable detriments with zero measurable benefit. Let's not waste any more time on this. --A D Monroe III (talk) 16:50, 4 September 2016 (UTC)[reply]

Guideline against inconsequential edits?

I think there should be a guideline somewhere discouraging the making of inconsequential edits (defined as those that don't affect the rendered text). This would include space-twiddling of almost all sorts, don't use newlines/do use newlines, etc.

This is already stated for users of AWB but I see no reason why it shouldn't apply to all edits. A common response to complaints about such edits is "there's no rule against it!" Maybe there should be. Such edits clutter up the edit history, increase editor workload, and annoy some other editors (like @Trovatore: above, and me), all for no benefit to the reader.

Such a guideline probably doesn't belong at MOS - I just put it here because the preceding section suggests it. Jeh (talk) 06:51, 4 September 2016 (UTC)[reply]

While this idea may reduce "clutter", it would put a chilling effect on editors, and that would be harmful to the project. Also, do you include link-piping in this "inconsequential" definition? Fdssdf (talk) 07:03, 4 September 2016 (UTC)[reply]
Every rule or even guideline has a "chilling effect" on editors; it is something to consider, but not a reason to reject any idea out of hand. Personally I don't see why "Don't fix what isn't broken", with a list of fewer than a dozen examples of things often fixed but not broken, would be terribly chilling. Jeh (talk) 07:28, 4 September 2016 (UTC)[reply]
A "chilling effect" on editors who seem to spend most of their time making such edits would be a very good thing in my view. Peter coxhead (talk) 07:48, 4 September 2016 (UTC)[reply]
(It's amazing how many people keep arguing that there's something wrong with advice to not do "work" that does not improve Wikipedia one iota for the reader, but which adds to the workload of other editors, in some cases annoyingly so.)
I'm not sure what you mean by the second. I know what link-piping is, but what sort of change are you asking about? If you mean changing a word or phrase to make it a WL, no, that's not inconsequential - besides the fact that the link renders in blue, the behavior of the page is changed. If you're just changing the code for a WL to a different form, for example changing [[Example|examples]] to [[example]]s, yes, that's inconsequential and "fixing what isn't broken". But at least the change will be plainly obvious in the diff display. "fixed" double-spaces, not so much. Jeh (talk) 07:28, 4 September 2016 (UTC)[reply]
  • Strong oppose. The last thing we need is a "don't you touch my article" rule that serves no purpose whatsoever other than enabling one editor to try to punish another for making good-faith edits. This would immediately be WP:GAMEd to start an enormous number of disputes alleging that all sorts of small changes qualify as "inconsequential" because a particular editor has low regard for fine distinctions that are important to others. If you find your watchlist being triggered too often by edits you don't care about, set it to ignore minor edits. We have a rule somewhere that we don't want WP:BOTs making such changes; the rationale for this is that bots going around editing thousands (or more than thousands) of articles at a time is a major drain on server resources and triggers many, many editors' watchlists all at once, so this should not be done for reasons that some editors might consider trivial. This "mass changes" rationale does not apply to manual edits and human editors, whom we do not treat like mindless automata. If an editor considers a spacing or other issue important, it's not someone else's job to castigate them for caring about something another individual isn't focused on. See higher up this very page for serious discussion of regular versus thin-spacing between numerals and superscripted citations; obviously some people care about it, while others would not. PS: I think I detect a whiff of the "no one may ever touch my citation formatting" pseudo-concern in this; even if that is not what motivated this request, proceeding with it would certainly re-enable a tremendous amount of disruptive cite-formatting disputation.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:31, 4 September 2016 (UTC)[reply]
  • Conditional support. WP already have a daunting number of rules new editors must somehow learn immediately; it's not good to add to them needlessly. Is this one needed? I think it is in one sense: I've seen new accounts used to make dozens of pointless edits in a rush to be auto-confirmed, apparently just for the purpose of evading page-protection. I certainly would not like a rule that would provide a rationale for reverting such edits; that would be making things worse in most cases. But something that states "don't waste others' time" with a lot of such edits, or something along that line, could be useful where the problem gets excessive. --A D Monroe III (talk) 14:33, 5 September 2016 (UTC)[reply]
    • That's not what this is about and would have no effect on that uncommon issue at all (anyone like that would simply hunt down it's/its typos or misspelling of "the" and "hte", making incontrovertibly constructive but also obviously trivial edits to rack up the needed numbers.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:16, 6 September 2016 (UTC)[reply]
  • Strong oppose. There are lots of possibilities for beneficial changes to the "Wikitext" layout, formatting, spacing etc. that have no visible effect in the rendered article. Just one that comes to mind ... sometimes text is pasted in with line-breaks from the source. These remain in the "Wikitext", disrupting the flow of text in the text editor. I remove them on sight. This would apparently be against the guideline. 81.152.193.175 (talk) 22:08, 7 September 2016 (UTC)[reply]

Opinion needed on a possible page move

Please visit and comment here:

Many thanks.

Anna Frodesiak (talk) 06:55, 4 September 2016 (UTC)[reply]

As much as possible, avoid linking from within quotes, which may clutter the quotation, violate the principle of leaving quotations unchanged, and mislead or confuse the reader.

Despite being called into question time and again,[1][2][3][4][5][6][7] the above rule remains essentially the same as when it was added in Oct 2006 following a discussion. When I look at these conversations, it doesn't even look like the rule was ever built upon a clear, unanimous consensus in the first place, or has ever since been firmly supported, established or enforced.[8] I think this obscures its overall validity as a WP:POLICY as well, as expressed in the last comment at this discussion by Pmanderson.

I also couldn't agree more with the last comment about this issue on this talk, by SMcCandlish: "it's more helpful to say 'do this' than just 'don't do that'." So here's my proposed revision, in which I attempt to elaborate on the current rule rather than to alter it:

Version 1

Wikilinks within quotations must be kept to a bare minimum. Only link a word or phrase that is unequivocally referring to a unique and specific entity or notion—that is, usually a proper name or technical jargon—except when it is universally recognized and therefore easily understood by most readers (see Wikipedia:Manual of Style/Linking § Overlinking).

Excessive: Smith wrote, "The [[1990s]] [[German]] [[film]], [[Cinematography|shot]] on [[70 mm film|70&nbsp;mm]], is [[Epic film|bigger]] and more [[Film budgeting|expensive]] than ''[[Ben-Hur (1959 film)|Ben-Hur]]''."
Modest: Smith wrote, "The 1990s German film, shot on [[70 mm film|70&nbsp;mm]], is bigger and more expensive than ''[[Ben-Hur (1959 film)|Ben-Hur]]''."[9]

If such a subject is mentioned somewhere else in the article, however, then link those instead of the one inside the quote (see also Wikipedia:Manual of Style/Linking § Repeated links). And even if not, consider adding or moving a mention of the subject to the surrounding encyclopedic passage.

Confusing: "[[Paris, Texas|Paris]] still has the best", food critic John Smith said in 2007. (Reader must click on link to discover that the obvious interpretation of "Paris" is incorrect.)
Acceptable: "[[Paris, Texas|Paris[, Texas]]] still has the best", food critic John Smith said in 2007.
Better: "Paris still has the best", food critic John Smith said in 2007, referring to [[Paris, Texas]].[10]

Most importantly, never give links to words that are remotely semantically ambiguous or use piped links to direct to articles whose subject is significantly broader or narrower than the displayed text (Easter egg links). This is to avoid leaving any room for original research or violation of text–source integrity.

Bad: [[United States Declaration of Independence|Four score and seven years ago]] our [[Founding Fathers of the United States|fathers]] brought forth on [[North America|this continent]] a new nation, conceived in liberty, and dedicated to the proposition that [[all men are created equal]].
OK: Four score and seven years ago our fathers brought forth on this continent a new nation, conceived in liberty, and dedicated to the proposition that all men are created equal.[11]

Clunky (?) examples aside, I think this generally sums up the points discussed in this talk before (as cited). What I would love to find out is if people think this is overall in the right direction or not, whether they might agree or disagree about some minutiae. Nardog (talk) 08:14, 4 September 2016 (UTC)[reply]

  • It's about time we tackled this idiotic provision. Without mulling it carefully (bedtime!) the above is a great start; subject to the OP's permission of course, I added a note to one of the examples.
  • Re "Only link a word or phrase that is unequivocally referring to a unique and specific entity or notion—that is, usually a proper name or technical jargon": Too strong, I think. There's no difference between linking within a quote and linking in a paraphrase of that quote: we need to be sure that what we're linking to reflects what the source was referring to; beyond that, if the link helps the reader understand the quote, that's no different from a link that helps the reader understand a paraphrase.
  • Re "except when it is universally recognized and therefore easily understood by most readers": Isn't this just trying to say what WP:OVERLINK says, and (I say again) the guiding principles for linking don't need to be any different inside quotes than they are outside quotes, so they don't need to be restated here in different ways.
  • Here's another example that might be useful:
The outer of the two rooms is of Alabama marble, with fluted columns and Ionic capitals.
EEng 08:45, 4 September 2016 (UTC)[reply]
Yes, I am certainly being conservative here. My approach as a starting point was basically to fist clarify, paraphrase, and elaborate upon the current rule to bring it closer to the reality of what editors do. Nardog (talk) 02:18, 5 September 2016 (UTC)[reply]
  • I definitely support this change, whether or not the above word is perfect or eventually changed. (It's a #honour to have inspired something.) To be honest, I completely forgot this policy existed. I linked something in a quote the other day. That's just one example of how this policy is widely ignored and not supported by consensus. It definitely needs to be changed, whether or not it's changed to the above specifically. McLerristarr | Mclay1 08:49, 4 September 2016 (UTC)[reply]
  • Support (with some copyedits). We've needed to rectify this for a long time. Pretty much no one follows the current rule; it's surely the #1 most-triggered WP:IAR, because there are very few circumstances where adding explanatory text outside the quote to provide link points for the words already used in the quote produces better material. (The "Paris, Texas" example is good, because "Paris" by itself is confusing, and per WP:REUSE we cannot depend on an explanatory link to be available.) It instead usually results in redundant and repetitive material that is frustrating for editors and brow-beating and intelligence-insulting for readers. All rules in MoS and other guidelines (and policies) are not followed some of the time by some editors, because people just show up and start editing without reading all these rules first (and we want it that way; these rules are primary for clean-up gnomes). However, we should not retain a bogus rule that is intentionally ignored as nonsense by virtually all editors who are well aware of the rule; it's a matter of WP:CREEP and WP:COMMONSENSE (and WP:POLICY, which tells us these pages exist to codify actual best practices, not try to force changes that no one actually practices).

    Copyedits: Do not use <tt>...</tt>. This element has not even existed in HTML for years (and if you're habitually using it, please stop - cleaning up after it is a maintenance headache). The correct element in this context is <code>...</code>, and it should wrap the entire example that represents wikicode, not just the part with linking brackets. "Only link a word or phrase that is unequivocally referring to a unique and specific entity or notion—that is, usually a proper name or technical jargon—except when it is universally recognized and therefore easily understood by most readers" doesn't flow right. Try "... or technical jargon. Do not link something that is universally recognized ...". Use {{Crossref}} around crossreferences. "If such a subject is mentioned somewhere else in the article, however, then link those instead of the one inside the quote" doesn't have plurality agreement, and we generally do not want people to link multiple instances, remember. Compress the verbiage; e.g., that entire string can be replaced with "If the term is used outside the quote in the article, link it there instead". Other parts of it can similarly be compressed. The whole segment that starts with "Most importantly, never give links to words that are remotely semantically ambiguous" suffers from this problem. We should also not introduce anything like "never" and "remotely", per WP:BEANS; they're just drama-generation tools (see other thread on this talk page about terrible idea for a rule against "inconsequential" changes). Guidelines do best with "do" and "do not" wording versus "always" and "never" (which seems to deny that WP:IAR exists), and subjective pronouncements like "remotely" and "inconsequential" and "most importantly" incite interpretational disputes. "This is to ..." wording is awkward; it's better to integrate policy rationales directly into the rule's sentence. That whole bit should probably be rewritten. We also don't need to provide the "OK" example that just shows no linking. I think part of our point here would be that well-known quotations are often best left without linking inserted into them. It makes more sense to just say so that to provide an "un-example" with no links in it, for no clear reason.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  13:10, 4 September 2016 (UTC)[reply]

Thanks for your suggestions. I'm not an experienced editor here on enwp, let alone its policies, so this is very helpful stuff. So please feel free to make changes below. Nardog (talk) 02:18, 5 September 2016 (UTC)[reply]
This is tangential and rather applies to the entire MOSes, but my problem with <code>...</code> is that it totally butchers the {{xt}}/{{!xt}} styling (at least with the default CSS). I found this template {{Plaincode}}, can we use this within {{xt}}/{{!xt}}'s? Nardog (talk) 02:43, 5 September 2016 (UTC)[reply]
We've not needed to do this, and have {{mxt}} (green) and {{!mxt}} (red) for this. The main problem is mix-and-matching styles on the same line; just use one:
{{em|Excessive}}: <code>{{!mxt|Smith wrote, "The <nowiki>[[1990s]] [[German]]</nowiki> ...}}</code>
gives:
Excessive: Smith wrote, "The [[1990s]] [[German]] ...
In this case, it's neither necessary nor desirable to show this markup, though. Just use plain {{xt}} and allow the links to link. This will illustrate the "sea of blue" effect in the quoted material.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:54, 6 September 2016 (UTC)[reply]

Version 2 (currently waiting for SM to edit if his suggested changes)

SMcCandlish, instead of everyone else wading through all your suggestions, why don't you just edit them into the version I've helpfully pasted in below, in a series of self-contained quanta? Start with the most obvious, unobjectionable ones, leaving the ones people may want to discuss or modify for the last. Then people can step through your edits, follow your reasoning in your edit summaries, and revert or modify for further discussion here. (Nardog, I hope you won't object to this approach.) I've already added the "Alabama marble" example, just so it doesn't get lost. EEng 18:37, 4 September 2016 (UTC)[reply]

Per suggestion below, I've made some edits [https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&diff=738826688&oldid=738825763to the V2 text. Mitch Ames (talk) 08:08, 11 September 2016 (UTC)[reply]

Wikilinks within quotations must be kept to a minimum. Where possible, use linking elsewhere in the article to make linking inside the quotation unnecessary. Only link a word or phrase that is unequivocally referring to a unique and specific entity or notion—that is, usually a proper name or technical jargon—except when it is universally recognized and therefore easily understood by most readers (see Wikipedia:Manual of Style/Linking § Overlinking).

Example: The outer of the two rooms is of Alabama marble, with fluted columns and Ionic capitals.
Excessive: Smith wrote, "The [[1990s]] [[German]] [[film]], [[Cinematography|shot]] on [[70 mm film|70&nbsp;mm]], is [[Epic film|bigger]] and more [[Film budgeting|expensive]] than ''[[Ben-Hur (1959 film)|Ben-Hur]]''."
Modest: Smith wrote, "The 1990s German film, shot on [[70 mm film|70&nbsp;mm]], is bigger and more expensive than ''[[Ben-Hur (1959 film)|Ben-Hur]]''."

If such a subject is mentioned somewhere else in the article, however, then link those instead of the one inside the quote (see also Wikipedia:Manual of Style/Linking § Repeated links). And even if not, consider adding or moving a mention of the subject to the surrounding encyclopedic passage.

Confusing: "[[Paris, Texas|Paris]] still has the best", food critic John Smith said in 2007. (Reader must click on link to discover that the obvious interpretation of "Paris" is incorrect.)
Acceptable: "[[Paris, Texas|Paris[, Texas]]] still has the best", food critic John Smith said in 2007.
Better: "Paris still has the best", food critic John Smith said in 2007, referring to [[Paris, Texas]].

Most importantly, never give links to words that are remotely semantically ambiguous or use piped links to direct to articles whose subject is significantly broader or narrower than the displayed text (Easter egg links). This is to avoid leaving any room for original research or violation of text–source integrity.

Bad: [[United States Declaration of Independence|Four score and seven years ago]] our [[Founding Fathers of the United States|fathers]] brought forth on [[North America|this continent]] a new nation, conceived in liberty, and dedicated to the proposition that [[all men are created equal]].
OK: Four score and seven years ago our fathers brought forth on this continent a new nation, conceived in liberty, and dedicated to the proposition that all men are created equal.

@Jayaguru-Shishya: notified me and others of this discussion and thinks it should be at Wikipedia:Manual of Style/Linking. I don't agree, since the impugned statement is on Wikipedia:Manual of Style whereas Wikipedia:Manual of Style/Linking has nothing about quotes. As regards the substantive issue; I am in favour of not having any "rule" on this and letting editors use their discretion. I am sure some readers find links within quotes to be ugly, but they are a minority who need not be accommodated. Sometimes wikilinking in a quote is convenient and transparent. It shouldn't violate WP:EASTEREGG, but that's not specific to quotes. jnestorius(talk) 16:14, 5 September 2016 (UTC)[reply]

I don't know if Jayaguru-Shishya thinks it should be at Wikipedia:Manual of Style/Linking, because it DOES have something about quotes: one sentence in WP:LINKSTYLE. And I actually sort of agree a written rule about this is redundant, but that was already once dismissed (years ago, though). But wouldn't you agree a revision would be at least better than leaving the current rule (Nirvana fallacy)? I think a change is more easily attained when it's gradual than when it's drastic. Nardog (talk) 16:49, 5 September 2016 (UTC)[reply]
So you have already tried proposing this at Wikipedia:Manual of Style/Linking, but it didn't end up that well and now you are posting it here? Did I get it right? That'd be WP:FORUMSHOPing, I am afraid. Posting the same thing over and over in hope to "have better luck next time" isn't advisable either.
Anyway, this is the wrong place to discuss the changes concerning WP:MOSLINK. I bet the majority of the editors there aren't even aware of this discussion. Cheers! Jayaguru-Shishya (talk) 17:59, 5 September 2016 (UTC)[reply]
I'm afraid but no, you didn't get it right. I honestly don't even know how one could possibly get such an impression. I proposed this here first, then linked to this discussion on MOS:LINK where it virtually has the summarized version of WP:MOS#Linking (because I had the exact same thought as you that editors there might not notice) only to be reverted by you, so I started a discussion there on WT:MOSLINK as you suggested when reverting. I don't know how that's forumshopping or "posting the same thing over and over". Nardog (talk) 18:29, 5 September 2016 (UTC)[reply]
If it's going to affect the wording at the main MoS it's better to discuss it here. See below; an RfC at MOS:NUM is now leading to dispute here because the RfC didn't take into account the wording at this page only at MOS:NUM. In general, any non-trivial MoS-related discussion is probably better held here, because far more people watch and comment at this page than at something like WT:MOSLINK.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:13, 6 September 2016 (UTC)[reply]
Re: request to edit in changes – Okay, but I'll have to come back to it later. The "give me PoV-pushing quote boxes or give me death" stuff further up the page has soured my appetite for editing here today, and I'm focusing on article copyediting, category cleanup, and template work.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:13, 6 September 2016 (UTC)[reply]
I've no objection to discussion here about important changes to MOS offspring guidelines, as long as they're section-linked at the offspring talkpage. Is the green-background text above the existing, or has it been edited? I don't really want to encourage editors to use awkward square-bracket placements, although it's not exactly wrong to do it. "Paris[, Texas] still has the best" might be better as [[[Paris, Texas|Paris, Texas]]]. Also, we might consider suggesting that wherever it's convenient to link an item in the vicinity of a quotation rather than withing it, that might be preferable. Tony (talk) 03:47, 6 September 2016 (UTC)[reply]
If you mean the block beginning Wikilinks within quotations must be kept to a bare minimum with the vertical bar at the left (I ask because to me it looks more bluish than green), it's all new; the current guideline says simply As much as possible, avoid linking from within quotes, which may clutter the quotation, violate the principle of leaving quotations unchanged, and mislead or confuse the reader. I'm editing your suggestions into Version 2, subject of course to others' approval
  • You'll notice, if you look at the rendering of your own post just now, that triple brackets don't work the way one wants -- you have to use {{bracket}}.
  • I added Where possible, use linking elsewhere in the article to make linking inside the quotation unnecessary.
I have to say, though, that someone's suggestion that we might simply drop the current guideline is an attractive one. If trouble arises, then we can add guidance along the lines of what we've been discussing. EEng 04:08, 6 September 2016 (UTC)[reply]
There are other approaches than {{bracket}}; I use &#91;[[Link here]]&#93; because I memorized those HTML character entity codes years ago. You can also do [<nowiki />[[Link here]]]. In all cases, it's fiddly, so we don't want to advise it (no one will comply, and it will be easily broken).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:37, 6 September 2016 (UTC)[reply]
I should have said, "You need to use {{bracket}} or something." If this basic proposal gets traction, then we can talk about what markup to recommend (since, when you think about it, inside a quote is major use case for a bracketed link). I'm glad we've got back the old Sandy McCandlish we know and love. EEng 21:31, 6 September 2016 (UTC)[reply]
I think the biggest argument against removing the rule entirely would be precisely because it has existed for so long. So instead of paraphrasing or elaborating on it, it may be just enough to say something along the lines of "With regard to linking, quoted texts are no different from any other types of texts. But since they are more susceptible to a violation of WP:NOR or WP:EGG, see to it that they adhere to MOS:LINK." Nardog (talk) 08:20, 7 September 2016 (UTC)[reply]
Thinking it over, I'm thinking we might keep the first and second examples above, drop the third, and drop the explanatory text in favor of something much shorter such as what Nardog just suggested. But to not confuse things too much, let's wait for SMcCandlish's edits to Version 2, then think about what to do next. EEng 00:16, 8 September 2016 (UTC)[reply]
You all can just integrate what I suggested if you want; I probably can't get to this until tonight or tomorrow.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:17, 8 September 2016 (UTC)[reply]
Some sugestions:
  • bare minimum should be minimum. The word "bare" adds no semantic value.
  • instead of
Where possible, use linking elsewhere in the article to make linking inside the quotation unnecessary.
use
Where possible, link a word or phrase elsewhere in the article instead of in the quotation.
  • In
that is, usually a proper name or technical jargon
the juxtaposition of "that is" and "usually" seems wrong. I suggest just deleting the former, ie:
... entity or notion—usually a proper name or technical jargon—except ...
  • The sentence
Only link a word or phrase that is unequivocally referring to a unique and specific entity or notion ... except when it is universally recognized and therefore easily understood by most readers
is potentially ambiguous. The "except" clause could be read as being an exception to "only" rather than "link". I suggest instead:
Only link a word or phrase that is unequivocally referring to a unique and specific entity or notion—usually a proper name or technical jargon—and not a common term easily understood by most readers (see Wikipedia:Manual of Style/Linking § Overlinking)
Mitch Ames (talk) 07:11, 11 September 2016 (UTC)[reply]


Greetings! First of all, please do not refactor the proposal that has already been made, and has already been answered to. I noticed seven instances where the original proposal was modified even though the discussion was already going on.[63][64][65][66][67][68][69]

Second, although not an RfC, I oppose because adding wikilinks to quotes is something that intervenes the original statement of the author; the destination article might present ideas that are totally different from the ideas that the author was talking about, or in the worst cases might present original research. For example, an inventor of something back in the year X might mistakenly be linked to already altered conceptions of the same thing in the future — in the year Y, let's say. Moreover, when it comes to piped links, the original say of the author could be linked to something totally different, and the risk just increases. For this reason, we already have the current guideline which says: "...avoid linking from within quotes, which may [...] violate the principle of leaving quotations unchanged, and mislead or confuse the reader..." Last, if the object we want to wikilink in the quote doesn't exist in the rest of ther article, is it really worth of wikilinking in the first place?

The opening post of this discussion thread stated:

Despite being called into question time and again,[1][2][3][4][5][6][7] the above rule remains essentially the same as when it was added

But doesn't this imply quite strongly that even though introduced seven times, the proposal hasn't gained any support?

I also wonder the statement that "it doesn't even look like the rule [...] has ever since been firmly supported, established or enforced." Where is this commentary based on? I have always removed links from the quotations and moved them outside the quotation if possible, just like my many co-editors have done.

Last but not least, when it comes to this "Paris, Texas" example, we already have policies dealing with such cases, such as WP:LINKSTYLE (direct link [[Riverside, California]], or piped link [[Riverside, California|Riverside]]), and WP:SPECIFICLINK (...Always link to the article on the most specific topic appropriate to the context from which you link...") This is a good demostration why the discussion should be taken to Wikipedia talk:Manual of Style/Linking instead of here. Indeed, WP:MOS only has one single sentence when it comes to linking; WP:MOSLINK has a whole page discussing with the different nuances and specific cases. For example, I am interested in the linking guidelines, but I haven't watchlisted WP:MOS personally as it covers a whole deal of other things but hardly linking. I bet many other editors neither do.

Cheers! Jayaguru-Shishya (talk) 20:50, 11 September 2016 (UTC)[reply]

Version 2: comments

  • "If such a subject is mentioned somewhere else in the article, however, then link those instead of the one inside the quote (see also Wikipedia:Manual of Style/Linking § Repeated links). And even if not, consider adding or moving a mention of the subject to the surrounding encyclopedic passage.."

    What is "such a subject"? What does "those" refer back to? And even if not what? Even without addressing those points, a better opening might be: "However, if such a subject is mentioned elsewhere in the article, link those ..."

  • Is "most importantly" necessary? ("Never" is already intensive.) "Remotely semantically" is a little clumsy, and what does "semantically" add here? Either remove altogether or replace with "at all ambiguous? Tony (talk) 07:39, 11 September 2016 (UTC)[reply]
  • Mitch Ames, Tony1: Will you please just edit your ideas directly into V2? A series of small edits, each with a clear edit summary, will allow others to follow your changes. Likely most if not all will be uncontroversi, but if someone dislikes something we can discuss it then. EEng 07:56, 11 September 2016 (UTC)[reply]
please just edit your ideas directly into V2 - Done. Mitch Ames (talk) 08:10, 11 September 2016 (UTC)[reply]
This edit to the V2 text might address the first of Tony1's points. Mitch Ames (talk) 08:26, 11 September 2016 (UTC)[reply]

Using non-Courier New monospaced fonts for code, preformatted text, etc.

Are the rules of using a non-Courier New monospaced fonts used for Code, preformatted text, etc. like Consolas, Everson Mono, Lucida Console, Lucida Sans Typewriter, Dejavu Sans Mono, etc. 46.130.128.129 (talk) 10:54, 4 September 2016 (UTC)[reply]

@46.130.128.129: It's not clear what your asking, nor what context you are thinking of. Setting a specific font is not a good idea, because we have no idea what fonts someone may have installed. In most cases it should simply be set to font-family: monospace; so that people see it in whatever their browser-default monospace font it, or a custom one they have set (I use one intended for coders that better distinguishes between 1, l, and I than most of them do, for example).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  13:14, 4 September 2016 (UTC)[reply]

Year-range example

The new consensus at MOS:DATERANGE is that in general year-ranges are XXXX–XXXX (4-year ending). The example at Wikipedia:Manual of Style#In ranges that might otherwise be expressed with to or through, which is intended to illustrate the choice of en-dash vs other dash-like symbols has been "the 1939–45 war". That is now contrary to the year-format style guideline. DATERANGE says there can be exceptions, but the given example does not seem to be one. And if the given example is an exception, then it's a poor choice (and unexplained) for a generic example. I am interested to hear from USer:RexxS, who undid my conversion (and USer:EEng's fix of my goof) to "the 1939–1945 war", a basis for continuing to use the now-against-MOS style here. DMacks (talk) 20:08, 4 September 2016 (UTC)[reply]

There's nothing to discuss. RexxS is simply behind the times -- see note at head of [70]. EEng 20:28, 4 September 2016 (UTC)[reply]
(edit conflict) The example at Wikipedia:Manual of Style#In ranges that might otherwise be expressed with to or through has been in place since Tony1 put it there in on 14 June 2007, and changing long-standing wording at the manual of style requires more than a cryptic edit summary. I'm not opposed to the new consensus for the guidance at DATERANGE, but some regard needs to taken of common usage. In the example in question, "1939–45" isn't simply a period of time, it's actually a title: "the 1939–45 war" and certainly to my reading, that feels much more normal that "the 1939–1945 war". This may be simply a regional thing, and others may find the 1945 more normal, but where this is not immediately clear, common courtesy suggests that it be discussed for the particular example, rather than fought out in an unproductive edit war. --RexxS (talk) 20:31, 4 September 2016 (UTC)[reply]
I'm not sure how a phrase of my intent, a link to another page with the specific problem, and an alternative solution is "cryptic", but now here we are. As my edit-summary and above comment invite, please propose a less "title-like"/"common use special case" example if you feel this one is an exception to the current general standard for writing the terminal year of a year-range. DMacks (talk) 20:53, 4 September 2016 (UTC)[reply]

The dispute here is over whether to change 1939–45 war to the 1939–1945 war, per the recent RfC scrapping the old guideline preferring XXXX-XX (with exceptions) in favor of preferring XXXX-XXXX all the time (with minor exceptions for things like football seasons and fiscal years) -- see the link I gave above. The purpose of the example is to illustrate that ndashes are used to express certain kinds of ranges, period; Rexxs' idea that the "1939–45 war" is some kind of special exception, or title, or something, has nothing to do with it, and is no business of this example. So to avoid the problem, I've boldly changed the example to Henry VIII reigned 1509–1547. If Tony1 gets the ping above, I'm sure he'll help us out here. EEng 21:29, 4 September 2016 (UTC)[reply]

(edit conflict) @DMacks: Thank you for politely engaging in debate on the point. The summary of the RfC was "The community has decided that four year date ranges (i.e. XXXX-XXXX) should be the default style used in Wikipedia. A limited number of exceptions apply to this. Firstly, when space is at a premium, such as in tables or infoboxes, 2 year date styles may be used. Secondly, applications such as sports seasons, fiscal years, and consecutive years use the two-year date range convention without problems. These applications can continue to do so. This list is not intended to be exhaustive, and exceptions can apply with a strong local consensus."
First, any wording used since 2007 in the MOS enjoys a strong local consensus, so I'm not unreasonable in asking you to follow the instructions at the top of the MOS page: "Any substantive edit to this page should reflect consensus. When in doubt, discuss first on the talk page." I appreciate that you may feel the RfC is the only consensus that needed to be reflected, but I disagree: local consensus such as here is a specific exception to the conclusions of the RfC.
Secondly, the use of "the 1939–45 war" is common enough as a Google search will reveal. I would speak of "the nineteen-thirty-nine forty-five war" and that is the natural way of thinking about it to me. Indeed, our article World War II links to Occupation of Poland (1939–45), has multiple uses of XXXX-XX year ranges in its section headings, and has several sources that use "1939–45" in their titles, so this isn't just something I've made up.
Now, I accept that others may find "the 1939–1945 war" more natural. Perhaps they didn't grow up in the immediate proximity of that war as I did. I don't know. It's also true that Occupation of Poland (1939–1945) is a redirect, so must be a plausible search term, and that our WWII article also uses "1939–1945" as do the titles of several other sources. To be fair, usage is split between the two variants, not just on Wikipedia, but in the outside world in this case. If you feel that our normal guidance of "Where more than one style is acceptable, editors should not change an article from one of those styles to another without a good reason. Edit warring over optional styles is unacceptable. If discussion cannot determine which style to use in an article, defer to the style used by the first major contributor." is not applicable here, then fair enough. It would be better, though, if we had more reasoned opinions available that just our two. --RexxS (talk) 21:54, 4 September 2016 (UTC)[reply]
@EEng: Thank you. Your edit changing the example to a date range that avoids my concerns is an excellent solution, in my humble opinion. I'm happy to close the debate in favour of that. (Although I should say that the issues of article titles, etc. may need more attention yet in order to implement the new consensus.) --RexxS (talk) 22:03, 4 September 2016 (UTC)[reply]
You're welcome. And since you're being so gracious I've recalled the unmanned killer drone, and even decided not to unfriend you. Have you visited The Museums? EEng 22:25, 4 September 2016 (UTC)[reply]
Agreed that a stock-phrase example is an exception. If there's something actually conventionally named "the 1939–45 War" in the same fashion as "the War of 1812", then don't change it. If it's just a description like "2000–2012 terrorist attacks in France", follow the guideline.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:07, 6 September 2016 (UTC)[reply]
Surely there's no objection to "the 2015–16 financial year" ... Tony (talk) 07:35, 6 September 2016 (UTC)[reply]
It appears that the point, and conclusion, of the RfC is there was such objection, but I didn't follow it all that closely after initial comments there. The gist appeared to be that habitual use of YYYY–YY format leads to things like "2009–10" which looks to many readers like "October 2009" not "2009–2010"; the hyphen and en dash are not distinct in all fonts. Even the exact case "2009–10 fiscal year" might be interpreted as "a fiscal year of 2009 ending in October rather in than some other month", I suppose. It's just two additional characters and won't kill anyone.  :-)  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:29, 6 September 2016 (UTC)[reply]

Additional input needed to resolve RfC

 – Pointer to relevant discussion elsewhere

The MOS:COMPASS RfC at Talk:Eritrea#Location has turned circular and unresolveable, with about half a dozen parties sticking to their positions immovably no matter what is offered. I would suggest that an influx of fresh eyes on the matter would be of great benefit before it gets any more WP:LAME.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:38, 5 September 2016 (UTC)[reply]

It's certainly unfortunate any time a discussion re COMPASS starts wandering in circles. Maybe some fresh eyes can give it new direction and move the needle a little. EEng 01:42, 5 September 2016 (UTC)[reply]
Indeed!  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:07, 6 September 2016 (UTC)[reply]

Use of Palmarès as a heading

 – Pointer to relevant discussion elsewhere

I have opened a discussion on whether Palmarès (French for list of achievements or list of winners) should be the standard heading used for a cyclists results. Where can I seek opinions on this? Thanks. BaldBoris 20:22, 5 September 2016 (UTC)[reply]

I'm against everything French just on basic principle. EEng 03:10, 6 September 2016 (UTC)[reply]

See Wikipedia:Village_pump_(technical)#Showing_related_articles.2C_especially_on_Mobile Jytdog (talk) 22:08, 7 September 2016 (UTC)[reply]

How to emphasize words in an already-italic text?

If a text is already italicized, how do I emphasize words in a text that’s already italic?

Example: This is a fantastic sentence.

If I want to emphasize the word “fantastic,” do I make it italic (but since it’s already italic, it returns to normal formatting), or do I make it bold?

Example one: This is a fantastic sentence.
Example two: This is a fantastic sentence.
PapíDimmi (talk | contribs) 22:58, 7 September 2016 (UTC)[reply]

I say it's example one. EEng 00:10, 8 September 2016 (UTC)[reply]
Since italicizing quotes is optional, what scenario would this come up in? Primergrey (talk) 12:03, 8 September 2016 (UTC)[reply]
That is a fantastic question. EEng 14:26, 8 September 2016 (UTC)[reply]
Italicizing quotations isn't "optional"; it's expressly deprecated at both MOS:QUOTE and MOS:ITALICS. If it were italicized for a legit reason, like being non-English, and had something emphasized in it, the normal way to do this is to de-italicize. If the material quoted was emphasized in the original and also included something else emphasized on top of that (e.g. by boldfacing or underlining), then it would make sense to use {{strong}} to boldface that part.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  16:53, 8 September 2016 (UTC)[reply]
Emphasizing something that’s already emphasizing, and it’s already italic? Oh my… This is too much for me. I have to sit down.
PapíDimmi (talk | contribs) 23:16, 8 September 2016 (UTC)[reply]
Actually, if you want to be a semantics mega-nerd, the way to really do a non-English quotation that contained emphasis would be He sarcastically said, "''{{lang|es|Mi casa no es {{em|style=font-style:normal|su}} casa.}}''", with italics and language markup (in that order) for the Spanish, then an {{em}} (or <em>...</em>) using CSS to de-italicize the emphasized part as visual counter-emphasis to the italics. :-)  I think I lot of people would just use the {{strong}} approach, not knowing the CSS geekery, and of course someone who doesn't care about this stuff at all would probably just do something like ...said "''Mi casa no es'' su ''casa.''" Anyway, it comes up so infrequently that MoS need not address it, and even most gnomes wouldn't bother with the CSS approach. Something I keep meaning to work on is an inline quotation template that uses the <q>...</q> element (which WP should be using), and, with CSS cascading, could auto-handle this sort of thing, e.g.: ...said, {{quote inline|lang=es|Mi casa no es {{em|su}} casa.}}, producing the same output as the "mega-nerd" version above.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:02, 11 September 2016 (UTC)[reply]

Updated "Scrolling lists and collapsible content" section

I've updated WP:MOS#Scrolling lists and collapsible content:

  • Google's increased transcoding of WP articles for millions of people is a serious issue. (See Wikipedia talk:Manual of Style/Accessibility#Lightweight pages via Google.)
  • Our mobile stats are now at about 45% of pageviews, and guesstimated to be over 75% of users at least some of the time.
  • Copyedited; the section had a lot of unclear language in it.
  • Updated to reflect current (desirable) usage; we use pre-collapsing, legitimately, for a few more things that just navboxes and redundant table cells.
  • Moved the geekery into footnotes.
  • Expanded the list of known "mobile-unfriendly" CSS classes.
  • Distinguished between different types of accessibility issues and different user classes.
  • Addressed why people sometimes want to collapse-box entire sections and what they should be doing instead (section better, rewrite trivia lists as encyclopedic prose, split an over-long article, remove indiscriminate junk).
  • Told people how to test mobile accessibility easily.
  • Cross-referenced key terms to guidelines and policies (remember that people almost always read MoS by section shortcuts, not from top to bottom).
  • Put dos/don'ts in concrete terms.
  • Reduced the excessive stressing about the spoilers thing; that hasn't been a controversy in years.

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:24, 11 September 2016 (UTC)[reply]

PS: I mentioned this over at WT:MOSACCESS; it's possible this section should be ported over to that MoS subpage, including its footnotes, then re-summarized here in more clipped form.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:06, 11 September 2016 (UTC)[reply]