Wikipedia talk:Manual of Style/Archive 168

{{aan} I will endevour to respond as quickly as possible.

Usage of & versus a break

Hi all, although I believe that breaks are better usage, still wanted to confirm, what is the MOS for separating two names in a list order? Which one should it be from the following:

Ryan Murphy & Brad Falchuk
Ryan Murphy Brad Falchuk

There is an existing problem with all the American Horror Story articles using the former as opposed to the latter. —Indian:BIO ^{[ ChitChat ]} 04:32, 25 July 2015 (UTC)[reply]

Using it where? I just looked at American Horror Story and did not see it. Agreed, use linebreaks (unless the two people are a team and credited as such), but it's   not   (the shorter, sloppy version makes the server do extra parser work for no reason). Depending on the nature of the infobox field, it may be , , when giving a short inline list and you want it to break at a specific point. PS: There are also templates for doing inline lists {{plainlist}} and {{comma separated entries}}, and MOS should probably start recommending them where appropriate (probably not in MOS proper, but at MOS:LIST and WP:INFOBOX, because the coding and semantic markup results will be superior, and it will be easier for wiki editors who are not "HTML people" to maintain. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:01, 26 July 2015 (UTC)[reply]

Hi SMcCandlish the usage is at American Horror Story: Freak Show and American Horror Story: Hotel in the episode lists, sorry should have guided you to the edit area. Thanks for clarifying, I think {{plainlist}} should be better for using it. Shall I change in the article? —Indian:BIO ^{[ ChitChat ]} 05:31, 26 July 2015 (UTC)[reply]

@IndianBio: Oh, under the "Written by" column. I'd thought this was about infoboxes. Okay. I wouldn't, after all, use the inline list templates (two isn't a "list", really), nor  , since there's no need to line-break it for people with wide montitors (it all fits on one line for me, and would look weird and vertical-space-wasting to line-break forcefully between those two names. It's just regular text, and should use "and", or "," not "&" (which implies they're a unit of some kind); "and" is clearer, but if space is at a premium, comma will do. If the intent is to just ensure that, at narrower window widths, the individual's names don't line-break, but the cell's content can break at the conjunction, just {{nobr}} around each name::

{{nobr|[[Ryan Murphy]]}}, {{nobr|[[Brad Falchuk]]}}

— SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 06:53, 26 July 2015 (UTC)[reply]

Thanks for confirming, will implement as you suggested. —Indian:BIO ^{[ ChitChat ]} 07:09, 26 July 2015 (UTC)[reply]

is this a policy on wikipedia

is this a policy on wikipedia — Preceding unsigned comment added by A8v (talk • contribs)

These are guidelines that are widely accepted by the community. See this page to read about what policies and guidelines are. EvergreenFir (talk) Please {{re}} 21:08, 27 July 2015 (UTC)[reply]

Short answer... No... it isn't "Policy"... but it is excellent guidance, and is widely accepted as such. The MOS itself states that we can make an exception to this guidance if necessary ... but it takes a fairly solid consensus to do so. Be prepared to make a compelling case that an exception is necessary. Blueboar (talk) 01:11, 28 July 2015 (UTC)[reply]

Blueboar is right to advise caution. In my experience, people treat the MoS as if it were a set of non-negotiable rules, even though they're technically not supposed to. Darkfrog24 (talk) 16:02, 28 July 2015 (UTC)[reply]

In my opinion, a lot of that stems from Wikipedia's over use of short-cuts... when a policy or guideline has too many short-cuts pointing to its various sub-devisions, people tend to only pay attention to the sub-devision that is linked by the short-cut... and ignore the rest of the policy or guideline... such as the part where it says it's OK to make exceptions to it. MOS is not the only guideline or policy where that is an issue. Blueboar (talk) 20:09, 28 July 2015 (UTC) [reply]

MOS page no longer an MOS page

Just FYI, WP:Manual of Style/Stand-alone lists has, in a barely attended WP:RM, been renamed WP:Stand-alone lists and the MOS banner removed from it. To compensate for the resulting mess, I've restructured the document to keep the content-related matters in one cluster, the style-related in another, and the naming ones in a third, and adjusted shortcuts (that I knew of) to point to the right sections, so people can find thing. While, in this one isolated case, the result is actually a more cohesive document (it could go the other way easily if something like this is tried on another page), this could have been achieved simply by moving some sections around, and if some RfC really concluded it was desirable to move some of the material to another page, to separate the content and style material, I guess that could have been done, but I'd lay money against a consensus to do that. The objection behind the RM that "a style guideline shouldn't be saying anything about content" is basically nonsensical (various parts of MOS directly address content and always have, and there is no policy sharply dividing our guidelines into "types"), and it can be turned right back on itself: A content guideline has no business dictating style matters. [rolling eyes]

I bring this up because it seems likely to me that this WP:POINT exercise could lead to similar attempts to "de-MOS" various pages. WP doesn't need territorial wikilawyering of this sort. The purpose of a page like that is to centralize for editors the WP advice on stand-alone lists, not stake "claims" on this or that as a content guideline "versus" a style guideline. It's a counterproductive notion that there's some kind of opposition between two different "kinds" of guideline. There's not. We label them one way or another as a shorthand; it's a convenience of categorization, and, as with articles, there's no reason at all a guideline can't be in two categories at once. Someone may propose forking such a page into separate the style, naming-convention, and content guidance, but I think that would be unhelpful for editors, the vast majority of whom don't care what kind of guideline banner it has on it, just what its content is. See the hatnote pile at the top of Wikipedia:Manual of Style#Titles of works, and see the ~2 years to took to clean up outright WP:POVFORKing between MOS:LIFE, WP:NCFAUNA, WP:NCFLORA, and various other pages, as examples of why this has proven repeatedly to be a bad idea. For categorization purposes, what is now a section redirect at WP:Manual of Style/Stand-alone lists can be categorized as a style guideline, for example, and everyone can find what they're looking for without any splitting. They could have without the renaming and banner-changing. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 04:05, 2 August 2015 (UTC)[reply]

I wonder why the RM wasn't publicized here. It seems a natural place to do so. Darkfrog24 (talk) 12:30, 2 August 2015 (UTC)[reply]

Not the first time this has been tried, e.g. here among various other cases. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:18, 3 August 2015 (UTC)[reply]

FWIW, there was notification at WikiProject MOS on July 26 for the RM discussion that began on July 23.—Bagumba (talk) 02:17, 3 August 2015 (UTC)[reply]

Wikipedia's "Manual of Style/Text formatting" should allow boldfacing of "row headings"

Proposal: Include the following in the short list of things that it is permissible to boldface:

As an inline heading (also known as a row heading) in a list, between the * at the beginning of the list entry and the rest of the entry's content, and having the concise characteristics of a higher-level, own-line heading, rather than of discursive text.

[Proposal was WP:REFACTORed to top of section, because the nom's draft version and later-accepted version are both buried in a lot of oddly-formatted material. I helped draft the final version, so consider me co-nominator, but I disclaim any connection to the off-topic material below by the original nominator. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:29, 26 July 2015 (UTC)][reply]

Wikipedia’s “Manual of Style/Text formatting” currently does not explicitly permit the boldfacing of inline, or row, headings. Under Boldface, at https://wiki.riteme.site/wiki/Wikipedia:Manual_of_Style/Text_formatting#boldface, under == Boldface ==, then under === Other uses ===, the advice reads (all below is quoted material until the line):

Use boldface in the remainder of the article only in a few special cases:

To identify terms in the first couple of paragraphs of an article, or at the beginning of a section of an article, which are the targets of redirects to the article or section (e.g. sub-topics of the article's topic, rather than the synonyms as already boldfaced per the above). (See Wikipedia:Redirect § What needs to be done on pages that are targets of redirects? for examples and further details.)
Mathematical objects traditionally written in boldface such as vectors and the rational number symbols Q and Z.
In some citation formats, for the volume number of a journal or other multi-volume works.

As a result, a STiki Barnstar of Bronze Merit-winner who has been keeping tabs on my edits in a particular article (“Patterson-Gimlin film”) has deleted the boldfacing of over a dozen inline headings, including some that pre-existed my editing. When I protested, he cited the aforesaid Manual via “MOS:BOLD”.

However, lower down on the same page in that very Manual, the boldfacing of inline headings is employed (all below is quoted material until the line):

Italic type (text like this) should be used for the following types of names and titles, or abbreviations thereof:

Major works of art and artifice, such as albums, books, video games, films, musicals, operas, symphonies, paintings, sculptures, newspapers, journals, magazines, epic poems, plays, television programs, radio shows. Medium of publication or presentation is not a factor; a video feature only released on video tape, disc or the Internet is considered a "film" for these purposes, and so on. (See WP:Manual of Style/Titles § Italics for details.)
Court case names: FCC v. Pacifica. (Case citation or law report information is presented in normal font)

In addition to the fact of exiting common use, documented above, boldfacing of row headings is fairly common and unobjectionable in publishing. It's user-friendly for the same reason that the boldfacing of standalone headings is helpful. It helps the reader grasp the outline of the material, and helps the re-reader navigate it more easily; it provides readers with visual "handholds" in a blank wall of normal text. (These advantages can be seen in a second instance of the Style Manual's use of a boldfaced inline heading style, at the end of its References section.)

The deleter of my boldfacings is acting in good faith, and he has a good case as the Manual is currently worded. And furthermore, even if he were to agree to undo his deletions, which I think he may have hinted at in his latest comment, another person could come along and justifiably delete them again, based on the Manual’s wording. So that wording should be expanded. Here’s what I suggest as a new second item in the Manual’s list above. Improvements welcome:

“* As an inline heading, also known as a row heading, in a list format (preceded by an *), which should come at the beginning of the text and have the concise characteristics of higher-level, own-line headings, rather than of discursive text.” RogerKni (talk) 18:33, 24 July 2015 (UTC)[reply]

@SMcCandlish: :@Melonkelon: :@Herostratus: SMcCandlish has commented on my write-up above in a different location, Village Pump: Policy, where I posted it before posting here. (I should have waited another 12 hours before posting here, in which case I'd have reorganized my comment above as he suggested, and put the proposed new text first, and the rationale second.) He provided these additional justifications for this change to the Style Manual:

"The real rationale #1 for this is that a heading is a heading, and doesn't serve a suddenly-different purpose when it is put inline to better suit the format of a list or other layout need. "The #2 rationale is that it's already deployed in similar situations, so not permitting it for lists is inconsistent and confusing. Examples: a) row and column headers in tables (a world-wide default in GUI browsers, not just on WP); b) glossary entries and any other things that resolve to dt markup in HTML (the boldfacing is hardcoded into MediaWiki as the default font-weight for the element); c) inline headers for infoboxes, navboxes, and similar templates; d) list entries on disambiguation pages and set index articles; d) ... [there are probably other examples]."

He's also suggested some tweaks to the wording I proposed for the Manual in the last paragraph of my submission just above, which I've accepted, so it now reads:

'* As an inline heading (also known as a row heading) in a list, between the * at the beginning of the list entry and the rest of the entry's content, and having the concise characteristics of a higher-level, own-line heading, rather than of discursive text.' RogerKni (talk) 20:32, 25 July 2015 (UTC)[reply]

Comments

Support the version at the top of the thread, which the proponent agreed to, as seen later in the proposal. My rationale in detail is discernible here, from previous discussion, but boils down to: 1) A heading doesn't magically become a not-heading when it is formatting inline, to fit the needs of the presentation. 2) This is consistent with a myriad of other inline headings in Wikipedia, all boldfaced, including list entries already in disambiguation pages, set index articles, and many others; data table column and row headers; infobox and navbox headers; glossary entries; etc. It is also used frequently through WP:POLICY pages include MOS itself. In short, it's simply a glaring omission. Nothing about it requires boldfacing, or conversion to a format that would suggest boldfacing, or that any particular punctuation or other formatting mandates boldfacing; it's simply permitting what most of us are already doing. PS: I suggested removing all the inter-editor venting and the weird formatting before posting, but didn't do so promptly enough, I gather. That stuff shouldn't prejudice the actual wording proposed, which I massaged; I'm essentially the co-nominator of the text at the very top. Amenable to tightening, BTW. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:29, 26 July 2015 (UTC)[reply]

Discussion

Well, you have a reasonable point. I think that you went way down the primrose path at Patterson–Gimlin film, sprinkling boldfacing throughout the article text far too liberally, and this is why the the other editor went on a general rampage of cutting out bolding in the article, including the instances you cite as being OK. This has perhaps poisoned the well a little bit? Any, just on the merits of your point:

You have a reasonable point, and your example (showing the use of bolding in WP:BOLD in a way not actually prescribed in that article) is quite amusing. However, I'm not convinced. First of all, I don't know as it'd an improvement to always require this. For instance, I'm not certain that

Major works of art and artifice, such as albums, books, video games...

is really that much better than

Major works of art and artifice, such as albums, books, video games...

It might be. Matter of taste, maybe. However, I'm all in favor of allowing but not requiring it because I'm a let-a-thousand-flowers-bloom kind of guy. Others aren't, they are more lets-look-like-a-publication-with-an-actual-stylebook-rather-than-your-sisters-scrapbook people, and that's reasonable too. Herostratus (talk) 22:46, 25 July 2015 (UTC)[reply]

This example does not actually qualify at all, though, if this were article text:

Major works of art and artifice, such as albums, books, video game...

That's is discoursive text running directly with the prose that follows it. MOS, as a policy page, is not written in encyclopedic style but is a work of technical writing, and its own use of "* Boldfacing, follow-on material in same sentence" in many cases, also found on lots of WP:POLICY pages, isn't what's at issue here, or illustrative of the "rule". The proposed addition also would not be "requiring" much less "always requiring" it. The recommendation for the whole section in which the new item would appear is "should", and that's fine. Something serving as a heading should have this formatting, whether block or inline (cf. table headers, etc.). It doesn't mean everything with a colon is a heading, or mean anything else other than it says. The thousand flowers can bloom as they will:

This is dialogue. (I think there is a convention for that, maybe it's italics or bold, I don't remember, and I don't know if it's a convention MOS supports; not germane to this discussion.)

MacGyver: "I don't use guns."

This isn't really a heading per se but a simple identifier; the years would be in sequential numeric order, and nearly identical, so boldfacing them serves no purpose, except maybe when each list entry is substantial block of text; up to editorial discretion to treat it as an inline heading or not:

2015: Won the [insert a bunch of award stuff here]

In the case of these two:

Psychology – Introduced by [whoever], the concept initially described [blah blah], and today encompasses [yadda yadda] ...
Anthropology – In physical anthropology, the term denotes [foo] and is distinguished from the meaning [bar] in cultural anthropology and linguistics ...

those are obviously inline headings, despite the en-dash format instead of colon usage. And so on. I'm skeptical that we really need to spell all this out, but some examples like this could be used to illustrate the point. It should not be done here (MOS is long already!), but at a new little subsection at MOS:LIST. If we add one, include an instruction not to mix and match styles in the same list, and that's probably about all we'd need to say. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:51, 26 July 2015 (UTC)[reply]

Revision

@SMcCandlish: :@Melonkelon: :@Herostratus:

In light of the feedback above, I've modified my proposal to read:

Under the 'Boldface' section of the Manual of Style (MOS), then immediately under the 'Other uses' subheading, insert the following:

"Boldface may be used, but need not be:

"* For an inline heading (also known as a row heading) in a list, between the * at the beginning of the list entry and the rest of the entry's content, and having the concise characteristics of a higher-level, own-line heading, rather than of discursive text."

How is this for wording in 'a new little subsection at MOS:LIST'? (I'll add an appropriate heading when I get there. Suggestions welcomed now.)

• "* Inline headings need not be followed by any particular punctuation mark, or by any punctuation mark at all, provided the boldfaced text could stand alone as a heading; in other words, provided it has 'the concise characteristics of a higher-level, own-line heading.'

• "* Boldfaced inline headings should be avoided in a list of one-line entries whose inline headings have a similar and predictable nature, such as a list of consecutive years, and in borderline cases, impossible to define by rule, where boldfacing would look too 'busy.' "

RogerKni (talk) 22:01, 27 July 2015 (UTC)[reply]

Comments

"Need not be" is fine, and would help prevent over-bolding (a potential concern raised above).

Both bullet points for MOS:LIST seem fine in meaning, though could use some wordsmithing (e.g. in the second one, "... avoided in a list of one-line entries whose inline headings have a similar and predictable nature, such as a numeric sequence; or other cases where boldfacing may be more distracting than helpful."). The first bullet would be better saying something about the characteristics than quoting the statement about them, but nothing comes instantly to mind. I'm unable to think of a case that would have no punctuation at all; inline use would seem to require some demarcation between inline heading and follow-on text (indeed, it would be necessary for WP:ACCESSIBILITY purposes, since text-to-speech and some text-only browsers have no boldfacing, so it would just produce a run-on). We should specify that some divider is needed, and suggest that the colon (:) and the en dash (–) are common choices, but that whatever is used, it should be consistent throughout the list, and that a change of style from one to another in the same article should be avoided for lists of a similar character [It's often desirable to use a different style for completely different kinds of lists, though]. This reminds me, we should probably eventually have a template for this, that has a CSS class; I can handle that myself if the proposal is accepted. I don't see any outright objections so far, but the messy formatting of this, with all these horizontal lines, makes it hard to parse (and I'm not trying to 'count votes", just observing that there don't seem to be many objections to address in re-drafting, or any objections to the whole idea. Specific wording suggestions for MOS:LIST can be made over at WT:MOSLIST later, after hammering out here. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 22:34, 27 July 2015 (UTC)[reply]

SMcCandlish wrote, just above: "I'm unable to think of a case that would have no punctuation at all; inline use would seem to require some demarcation between inline heading and follow-on text (indeed, it would be necessary for WP:ACCESSIBILITY purposes, since text-to-speech and some text-only browsers have no boldfacing, so it would just produce a run-on)."

I think it would not be unusual for list items to lack a punctuation mark after their boldfaced inline heading, and yet not produce an accessibility problem. Here’s an example, consisting of lead-in text followed by three list-entries, in which only the "Author-(letter)" portion is boldfaced:

Authors have expressed themselves as follows on the XYZ Affair:

Author-A says it’s an outrage, citing . . .
Author-B insists it’s no worse than a dozen other scandals . . .
Author-C couldn’t be reached for comment; his answering machine . . .

Text-to-speech software would not produce a funny-sounding run-on in those cases. Therefore, I suggest appending the last sentence below to the first paragraph of advisory’s text, so the proposal's text reads:

• "* Inline headings need not be followed by any particular punctuation mark, or by any punctuation mark at all, provided the boldfaced text could stand alone as a heading; in other words, provided it has 'the concise characteristics of a higher-level, own-line heading.' If no punctuation is employed, the boldfaced text should be the subject of the sentence or clause that follows.

• "* Boldfaced inline headings should be avoided in a list of one-line entries whose inline headings have a similar and predictable nature, such as a list of consecutive years, and in borderline cases, impossible to define by rule, where boldfacing would look too 'busy.' "

Modifications welcome. RogerKni (talk) 06:31, 28 July 2015 (UTC)[reply]

@RogerKni: But "Author-A says it's an outrage, citing ..." has no inline heading; it's entirely discursive text. The "If no punctuation is employed, the boldfaced text should be the subject of the sentence or clause that follows" bit is directly contradicting "the concise characteristics of a higher-level, own-line heading". Doing something like "Author-A says it's an outrage, citing ..." is precisely what we don't want, and what people would kill this proposal to prevent!

As an aside, if someone did "Author-A: "It's an outrage." (citing ...), that's dialogue reporting, in which the speaker identification should probably be treated as an inline heading. I checked around; usage in external sources is wildly inconsistent, but leans toward boldface, italics, ALLCAPS, and SMALLCAPS, the latter two of which are more or less banned on Wikipedia, and the second of which will conflict with other uses of italics, which just leaves bold, in exactly the style we're recommending: "Author-A: 'It's an outrage.' (citing ...)" I.e., give dialogue as an example of when to use this, if we end up giving exmples. This last iteration of the proposal text doesn't see to address anything I raised above, BTW.

It's not helpful to keep repeating what everyone is saying and repeating the barely-modified blocks of text. This has already gotten so long that other editors won't read it. Better to hash out some wording tweaks for a while, then produce a redraft after some more iterations, or we'll just lose everyone. It would also be helpful if you learned our conventional ways of formatting talk page posts, indenting replies with ":" at the beginning of a line and replies to replies below them with "::", and so on. The discussion will be much easier to follow for other editors (which is who we're trying to attract to the discussion). [I'm trying to command you to do this or that, I'm saying as a practical matter there's basically only one way to do it or people will mostly just ignore it and move on.] — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:21, 28 July 2015 (UTC)[reply]

@SMcCandlish: :@Melonkelon: :@Herostratus:

SMcCandlish wrote just above, quoting an example I’d used:

'But "Author-A says it's an outrage, citing ..." has no inline heading; it's entirely discursive text.'

That assumes that a punctuation mark is needed to delimit an inline heading. But I think the end of boldfacing adequately signifies the end of the heading; furthermore that "Author-A" does have "the concise characteristics of a higher-level, own-line heading".

No reader would be led astray by the lack of a punctuation mark in the four-line example I supplied above (about "the XYZ affair"). The boldfaced authors' names at the start of each list-entry are clearly topic-headings for that entry. It would not be reader-friendlier to write the topic word twice instead, thus: "Author-A. Author-A says it's an outrage, citing ..."

Nor would it be writer-friendlier, or copy-editor-friendlier. Wordy existing paragraphs are often easier to follow if copy-edited into a list format, with each sentence being a list-entry. Once that has been done, it is additionally helpful to the reader to boldface the subject of each line, if it happens to begin the sentence. It is also less work for the editor than rewriting the sentences and inserting extra words and punctuation.

In order to address an SMcCandlish suggestion of 22:34, 27 July 2015, I propose that the following text (largely copied from his) follow the first sentence in the first paragraph of my two-paragraph proposal above:

"Suggested punctuation marks after an inline heading are the colon (:) and the en dash (–), although others are acceptable. Whatever mark is chosen, it should be consistent throughout the list. For lists of a similar character, a change of mark from one to another in the same article should be avoided."

SMcCandlish wrote, "It's not helpful to keep repeating what everyone is saying and repeating the barely-modified blocks of text." I will avoid doing so in the future. My intent was to be helpful by avoiding the need for readers to look back to prior comments for context, but to bundle and repeat it locally.

I feel I am out of my depth in packaging and promoting my proposal here. I'd appreciate it if you, SMcCandlish, or some other Wikipedia adept who is reading this, would volunteer to "carry the ball" henceforth. — Preceding unsigned comment added by RogerKni (talk • contribs)

@RogerKni: I understand it can be frustrating. I'll be happy to carry the ball on this one, because I care about it, too. BTW, whatever external editor you are using (Microsoft Word?) you need to turn off the "smart quotes" (curly quotes) feature in it, or use a different, plain-text-only one; it is changing ' and " into the curly versions, on the fly, and breaking wiki-formatting. I've had to fix several of your posts, including the above one, in this regard. It would do that in articles, too.

Early in this discussion people were already objecting, in other wording, to the idea that "the end of boldfacing adequately signifies the end of the heading". I.e., we'll get nowhere without there being a punctuator of some kind. It's not that any reader would be led astray, it's that boldfacing the beginnings of list items when they don't have the character of *Item: Discursive material here is seen as excessive. That's basically why we don't already have a "rule" permitting inline headings in lists: No one has been able to articulate a rule that doesn't permit willy-nilly boldfacing simply to introduce list items, and this is widely objected to. It's the main objection to the proposal as originally drafted, here, too. So, if we want any support at all for sometimes using bold for inline headings, ever, it'll have to be narrow and specific, because consensus already "assumes that a punctuation mark is needed to delimit an inline heading".

There would be no need to use the redundant construction '''Author-A'''. Author-A says "whatever they said..."; if it's desirable to treat the speaker as a inline heading, then dialogue format '''Author-A''': "Whatever they said ..." will do.

There's a general consensus against copyediting paragraphs into lists, but rather the other way around is favored. See, e.g., MOS:TRIVIA which strongly advises to rewrite lists of details into prose paragraphs. MOS:LIST has similar advice more generally

It's already implicit that other characters than : and – could possibly be used; MOS is just a guideline. It's hard to think of ones that would be appropriate very often, so the WP:CREEP principle applies here. MOS should not try to pre-figure every conceivable scenario, or it will be 10x longer than it already is. :-)

At this point, I think the proposal has bogged down so much it's best to just close it and launch another one later. I'll be happy to do that. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:37, 30 July 2015 (UTC)[reply]

@ SMcCandlish. Re your willingness to relaunch my proposal: Good, I’m happy to hand over the baton.

Re curly quotes: I created my previous post in Word, but I replaced its curly punctuation marks with straight/plain quotes and apostrophes taken from your comment before it, which I had copied into Word. I don’t know what went wrong. This time I’ll check how it looks and correct it on-site.

(Say, maybe Wikipedia could/should add a filter that automatically converts curly items as they are pasted into it.)

If Wikipedia's 'consensus already "assumes that a punctuation mark is needed to delimit an inline heading"' then there is no practical hope for me to fight it in my proposal.

But I don’t accept its contention that: 'if it's desirable to treat the speaker as a inline heading, then dialogue format Author-A: "Whatever they said ..." will do.' That’s because the boldfaced name at the start will often not be a 'speaker,' but merely the subject of the sentence. So dialog format would not suffice, because his remarks are paraphrased, as in the three list-example-items I provided above. To handle paraphrased remarks when a punctuation mark is required after the boldfaced portion, an undesirable repetition of the name would be needed.

As for, 'No one has been able to articulate a rule that doesn't permit willy-nilly boldfacing simply to introduce list items': I think I did so when I wrote, 'If no punctuation is employed, the boldfaced text should be the subject of the sentence or clause that follows.' That’s adequately restrictive. I urge the consensus to ponder this.

Re: 'There's a general consensus against copyediting paragraphs into lists . . . . ' Oops!

PS: A period should be explicitly mentioned as a permissible punctuation mark, along with the colon and N-dash.RogerKni (talk) 13:33, 30 July 2015 (UTC)[reply]

RogerKni (talk) 13:27, 30 July 2015 (UTC)[reply]

I'll try to factor in some of this when revising for later re-proposal. I think you're trying to get too much all at once. Proposals usually fail here if they are not very simple, basic, and minimal in the changes they introduce, providing the fewest possible avenues of dispute or opposition. Your desire for * '''Jones''' said blah blah blah will definitely raise such objections; this is the very style that is already raising concerns just in the initial drafting. (I object to it myself, because there is no distinction between the alleged heading an the running prose. I'd bet a zillion dollars the majority of editors would agree.) Let people get used to * '''Jones:''' "quotation here" first, at least. As for . as a divider, it would need to be limited to specific things, probably, like ordinal lists: * '''Rule 2.1.8.''' Text here., but even then I'd suggest dropping it from the initial proposal, because anyone will rightly point out that there's no reason not to use a colon there, and we do not want people injecting sentence fragments followed by . just to "get away with" boldfacing like mad in lists. I.e., it's yet another place where many people would raise objections and kill the proposal. The point of a proposal to add something to MOS or any other guideline is generally to describe current, active best practice on Wikipedia, not to inject new preferences. So, we should propose what we can almost certainly get, codifying actual usage here, not propose something so broad it will almost certainly be rejected. Use later proposals to try introducing other refinements. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:37, 4 August 2015 (UTC)[reply]

Advice about using columns in articles

Do we actually have any MOS advice about when to use columns in articles? By "columns", I mean {{multicol}} and related formatting, not the "rows and columns" in proper tables. MOS:COLUMNS is a red link, and my search turned up nothing obvious. WhatamIdoing (talk) 19:07, 30 July 2015 (UTC)[reply]

Is there an article that actually uses multiple columns (other than in a proper table?)... if so, could you give us an example? Blueboar (talk) 23:54, 30 July 2015 (UTC)[reply]

There are a number of WP:Embedded lists which do so. Special:Whatlinkshere/Template:Multicol or any of the family of templates should provide an example, such as Arthur Laurents#Directing. --Izno (talk) 03:05, 31 July 2015 (UTC)[reply]

And presumably other than in Notes and References sections – right? ~ J. Johnson (JJ) (talk) 20:56, 31 July 2015 (UTC)[reply]

See also Australian hip hop § Notable artists, which uses {{divcol}}. —sroc 💬 06:50, 1 August 2015 (UTC)[reply]

Note this from Wikipedia:Manual of Style/Layout § Standard appendices and footers §§ See also section (MOS:SEEALSO):

Contents: A bulleted list, preferably alphabetized, of internal links to related Wikipedia articles. Consider using {{Columns-list}} or {{Div col}} if the list is lengthy. The links in the "See also" section might be only indirectly related to the topic of the article because one purpose of "See also" links is to enable readers to explore tangentially related topics.

—sroc 💬 06:57, 1 August 2015 (UTC)[reply]

Also refer to Wikipedia:Manual of Style/Accessibility § Block elements §§ Tables §§§ Layout tables, which discourages the use of tables for layout purposes. —sroc 💬 07:01, 1 August 2015 (UTC)[reply]

Is there some recurrent problem that MOS needs to address? — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:04, 1 August 2015 (UTC)[reply]

It's not hard to find examples. See all of List of sites on the Queensland Heritage Register in Toowoomba, the long list at House#Employment-free house, Istanbul World Political Forum#Participants, Jackie Gleason#Career accomplishments, four columns at Horacio Ferrer#Lyrics to Music by Piazzolla, etc. WhatamIdoing (talk) 00:15, 4 August 2015 (UTC)[reply]

Right, but what's the nature of the objection? Is there a serious issue to address? The only one of these I find objectionable is the first one, since it looks exactly like a real estate sales listing website. The rest of these seem like good uses of space. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:29, 5 August 2015 (UTC)[reply]

Capitalization and capitalisation

For those with an interest in either of these issues, I have made a proposal to change the style guide at Wikipedia_talk:Manual_of_Style/Capital_letters#Clarifying_MOS:INSTITUTIONS. Comments are welcome. Ground Zero | t 17:39, 5 August 2015 (UTC)[reply]

to vs. that

A recent edit to Fast Fourier Transform changed:

A Fast Fourier Transform (FFT) is an algorithm to compute the Discrete Fourier Transform (DFT) of a sequence (or its inverse)

to:

A Fast Fourier Transform (FFT) is an algorithm that computes the Discrete Fourier Transform (DFT) of a sequence (or its inverse).

It seems to me that this is an MOS question, though I don't know the answer either way. Gah4 (talk) 20:07, 4 August 2015 (UTC)[reply]

If this is a straw poll, then speaking as someone with a Bachelor's Degree in English Writing I'd vote for that computes or perhaps used to compute. DonIago (talk) 20:34, 4 August 2015 (UTC)[reply]

used to compute sounds best to me. Darkfrog24 (talk) 21:14, 4 August 2015 (UTC)[reply]

That computes is by far the best, since it's 100% active voice, meaning clearer and easier to read. Used to compute is worst since it's passive voice. To compute is okay, but I like the first better. That said, I don't think there should be a policy for this kind of thing. BTW, get rid of the parentheses, since if you need hyphens or parentheses, it's probably either bad writing or unnecessary punctuation. Oiyarbepsy (talk) 05:47, 5 August 2015 (UTC)[reply]

Yes, active vs. passive was what I was wondering, but forgot the terms. Is there no MOS related to this? Gah4 (talk) 06:11, 5 August 2015 (UTC)[reply]

One concern: Does the algorithm actually do the computing or is it a tool that the human operator use to do the computing? A hammer doesn't build a fence; it is used to build a fence. In that case, the passive is preferable because it is more accurate and provides an extra level of information. Darkfrog24 (talk) 14:34, 5 August 2015 (UTC)[reply]

A hammer doesn't build a fence, but a scalator lifts people, and a plane flies between cities. Algorithms are active agents that perform automated behavior; it's not uncommon to refer to automatic machine as performing an action rather than "being used to" perform it. Diego (talk) 15:05, 5 August 2015 (UTC)[reply]

A program (or the trendy synonym "application") is often said to perform computations. Algorithms are abstract procedures; they can be carried out by a person mentally or with pencil & paper. They can also be implemented with a program (which must be written by a programmer). So I would not use active voice where an algorithm is the subject of the sentence, any more than I would say a recipe cooks food. Jc3s5h (talk) 16:54, 5 August 2015 (UTC)[reply]

I wouldn't go quite as far as Jc3s5h (because of the factors Diego Moya comments on). In this particular case, I think the passive voice is more accurate, and this might be true of statements about all algorithms, which are the "basic machines" (like levers) of the mathematical and programming worlds, incapable of acting in any way on their own without direct and continued application of external input. They don't do anything whatsoever on their own. This is not true, of, say, various forms of "application" and "server" software that do all kinds of things without our direct input once we set them loose. My inbound-traffic firewall actually does reject connection requests on its own, based on various criteria I gave it. I am not using it to reject each of these requests, or I'd spend all day individually saying yes or no to them (though I am using it for the purpose of rejecting unsafe network traffic in the aggregate). This distinction is as sharp as dead and alive for me: I do actually individually deny or approve outbound requests with a different program (other than a few blanket rules, like allowing my web browsers to contact any port 80 or port 445, except advertisers and malware sites I auto-block with blacklists, another automated function). The entire point of so-called "AI" in the current sense (i.e. expert systems) is that they make independent decisions based on "training". It's analogous to highly trained dogs: I use a dog to guard my house. But when the dog decides to bark at a particular passing stranger but not bark at familiar people, that's the dog's decision. I'm not using the dog to bark at that particular stranger. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 20:26, 5 August 2015 (UTC)[reply]

As an computer scientist, "an algorithm to do X" sounds completely right to me. It means that the purpose of the algorithm is to do X, not that it necessarily does it correctly. So I can say "X is an algorithm to solve problem A, but it doesn't work in all cases." The active voice often means something slightly different. "I wrote an algorithm to solve problem A, but it actually solves a slightly different problem." Saying that an algorithm is used to solve problem A does not require that it actually solves problem A. Peter coxhead (talk) 06:25, 6 August 2015 (UTC)[reply]

I'd buy that for a dollar. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 18:29, 6 August 2015 (UTC)[reply]

American English categories

Should Category:Use American English and its monthly subcategories be treated as cleanup categories? Does membership in this category mean that some change is needed to the article? It appears in Category:Clean up categories. Thanks, Oiyarbepsy (talk) 04:12, 3 August 2015 (UTC)[reply]

Yes (and same for the British or Commonwealth one, whatever it's called). Random editors make misc. additions to article all the time that don't match the WP:ENGVAR of the article. Cleaning that up would seem to be the primary if not sole rationale for these categories. The related {{Use American English}}, etc., templates themselves seem to exist primarily to forestall edits that don't match the ENGVAR, with the categorization they perform being a secondary, "if that fails" function. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 06:20, 7 August 2015 (UTC)[reply]

@SMcCandlish:So, then, I should verify that it uses American English for the entire article and then remove the template, since the maintenance concern is then addressed? The template shouldn't stay there forever if it's gonna put articles in the monthly maintenance category backlog. Oiyarbepsy (talk) 13:19, 7 August 2015 (UTC)[reply]

Oh, nah, that's not the intended result. The template needs to remain. Hmph. I guess it'll need to come out of the maint categories then, and people can just treat this one as optional maint. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 13:29, 7 August 2015 (UTC)[reply]

Proposal - how about have people check, and if everything is OK, change the month to the current month? At the very least, it's a quick fix, even if not the right one. However, I don't see why English variety templates need months at all. Oiyarbepsy (talk) 23:02, 7 August 2015 (UTC)[reply]

That sounds reasonable. Presumably date was added because the cleanup categories are all dated. It also, incidentally, tells us when an ENGVAR was affirmatively asserted, which could be relevant for some discussions, but I'm not sure that's compelling. However, the date parameter would need to be retained for your solution to be viable. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:11, 8 August 2015 (UTC)[reply]

Proposal: Disable giant quotation marks in mainspace; deprecate pull quotes in articles

There are virtually no legitimate uses of pull quotes in WP articles, because WP is not written in news style. Worse, editors are rampantly ignoring the instructions in both MOS:QUOTES and the documentation of the pull quote templates like {{cquote}}, and using them as pure decoration for block quotations. I've used {{cquote}} around the proposal details below, to illustrate it. The majority of the uses of these templates are to incorrectly format block quotations in articles. This can be resolved by putting a namespace test in the templates that suppresses display of the giant, decorative quote marks if the templates are used in articles. The small number of existing, actual pull quotes in articles can be reformatted with another template, such as {{quote box}}, that no one tries to abuse for inline block quotations (it shunts the quotation into a right-hand sidebar box, which is a more common style for pull quotes that using weird, giant quotation marks, anyway). I've illustrated the {{quote box}} template with the "Note" to the side of the proposal details below. Actually, mostly pull quotes in mainspace could just be removed, but that should arguably be up to article-by-article consensus determinations.

Several of us have been trying to clean up this mess for years, and it never gets any better, so it's demonstrably time to just do away with the "attractive nuisance" of {{cquote}} adding giant quotation marks in mainspace.

Note

These proposals are all severable (e.g., one might favor 1, 3, 4, without actually deprecating pull quotes; or support #1, 2, 4, without recommending any template for pull quotes at all; etc.)

“

Details:

Disable the display, in mainspace, of giant quotation marks in templates that use them.
Recommend generally against the use of pull quotes because they are rarely appropriate in encyclopedic text.
Recommend {{quote box}} for pull quotes, in the rare case that consensus at a page is certain that one should be included. [Or recommend some other replacement template(s) without giant quotation marks.]
Use AWB or some other process to convert most uses of {{cquote}} in mainspace to {{quote}}, or when it is clearly a pull quote (because the same quote is repeated elsewhere in the article), to {{quote box}} [or some other alternative].

”

— SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:21, 30 July 2015 (UTC)[reply]

Update: There's yet another problem with this rampant abuse of pull quote templates for block quotations: They (quite properly) have role="presentation" This makes them semantically meaningless, like tables used for layout, and spacer GIFs. It's wrong markup to use these for block quotations, not just abuse of a template to force an visual appearance against house style. This is a serious accessibility problem, since anything with role="presentation" is going to be ignored by some screen readers, and probably some text-only browsers. I.e. block quotations misformatted this way will simply not appear for such users. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:13, 9 August 2015 (UTC)[reply]

support - these are rampantly abused in almost every situation that I have seen them in articles. i cannot imagine where they would be appropriate. -- TRPoD aka The Red Pen of Doom 00:32, 30 July 2015 (UTC)[reply]
- The only arguably legitimate cases – rare – that I've seen are in very large articles, where a pull quote is used to repeat and highlight a quote or partial quote that has already been given in a dense block of paragraphs. Even if these cases are great ideas (dubious), there are very few of them. I think it's dubious because it's extremely difficult to do this without triggering WP:UNDUE concerns. If you then need two pull quotes, to illustrate both sides of an issue, that's a visual mess, and better handled with a section summarizing the opposing views. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:46, 30 July 2015 (UTC)[reply]
Conditionally Support: The MoS recommends blockquotes for longer quotes, and also has guidelines for their format: no quotation marks, no pull quotes, and no italics. However, the standard {{quote}} template has no way (that I know of) to force [extra] indentation of a quote inserted next to a left-justified image. I have seen many articles where either italics or cquotes are used to set such quotes off from the surrounding text. (The correct formatting can be achieved using a blockquote HTML instruction followed by a CRLF and a colon-forced indent, but I don't think this is accepted as standard practice.) If the quote template could be modified to do these indentations properly (preferably automatically, but with a separate parameter directive if necessary), I would wholeheartedly support the proposal. 2600:1006:B11A:ED71:14E8:C473:9B00:7111 (talk) 01:13, 30 July 2015 (UTC)[reply]
- The fix for this problem has just now been submitted at MediaWiki talk:Common.css#Fix for very long-standing problem of blockquote not working with images. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:04, 30 July 2015 (UTC)[reply]
  Further update: Template:Quote/doc#Next to left-floated images. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:15, 9 August 2015 (UTC)[reply]
  - Wow, that was quick. Thanks. If it was that easy, it makes me wish I'd taken an HTML class.

With that under control, I support the proposal. Normally I oppose hard-coded, unbypassable restrictions, but as you point out this guideline is pretty clearly decided but pretty widely ignored, so one change to the template would save an awful lot of wasted time changing articles. 2600:1006:B11A:ED71:14E8:C473:9B00:7111 (talk) 04:09, 30 July 2015 (UTC)[reply]

Oppose. I don't see that the case has been made that this has to be decided centrally. While I personally do not often find occasion to use this feature, I also don't see it causing widespread harm; whether an individual use is appropriate can be discussed on a case-by-case basis. --Trovatore (talk) 01:20, 30 July 2015 (UTC)[reply]
- Things don't have to be "harmful" to be poor style rejected by consensus. It's already has been decided centrally, for years, and is being evaded (out of carelessness mostly, though sometimes obstinacy) because of a shiny template acting as a beacon, "use me, u-u-use m-e-e", despite MOS and the template's own documentation saying not to. The case-by-case approach has been tried, for years, and dismally failed. It will continue to fail because 99+% of the time it's added to an article without discussion, and content editors at articles are not going to argue about it. Article talk pages are not for arguing over style quibbles; settling such matters is why MOS exists in the first place. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:45, 30 July 2015 (UTC)[reply]
  - Far too much is decided centrally. This is a bad thing. I know you feel differently. --Trovatore (talk) 02:01, 30 July 2015 (UTC)[reply]
    - Um, ok. But this was already decided centrally years ago. Maybe you want to make a counter proposal that block quotations should use giant quotation marks, and MOS changed to say that? Or whatever it is that you want? — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:04, 30 July 2015 (UTC)[reply]
      - So what it seems to me you're saying is, stuff was decided centrally previously, but it isn't being followed, so now we should decide more stuff centrally, to make it easier to enforce the old stuff. Is that a fair summary? That's a genuine question; it's certainly possible that I've missed your point, and if so, then please do point out where. --Trovatore (talk) 03:47, 30 July 2015 (UTC)[reply]

It's clarifying the existing consensus. This process, which you object to for being "centralized" (like everything else with {{guideline}} or {{policy}} on it), has already proven fruitful, in identifying precisely why MOS is being ignore by some editors: They're doing it to work around a CSS bug, that is even now being slated for correction at Mediawiki talk:common.css; the problem has been known to exist since 2010 I think, but only just now nailed down. But <gasp>, this, too must be Evil and Bad, since that's another sinister centralized discussion. But don't tell anyone, the cabal might overhear, and send in a black ops team to silence you. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:09, 1 August 2015 (UTC)[reply]

Support 1, but I'm not sure this is a MOS issue. The guide and the template already say not to use this style in article space, but it is used, probably because it's easy and visually interesting. I support changing the template to display as a regular block quote in article space. Pburka (talk) 03:22, 30 July 2015 (UTC)[reply]
Heck no, absolutely not. {{cquote}} is great, it's one my go-to tools. This whole thing is kind of a clusterfuck, but not really as bad as you might think, as long as few things are understood.

First, right, there's essentially no need or use for pull quotes in this encyclopedia, of course not; every reasonable person understands that, I would think.
Second, {{cquote}} (which, absurdly, devolves to the misnamed {{Pull quote}}) has nothing to do with pull quotes and never has, notwithstanding the silly and universally ignored admonitions in the instructions. (If you don't believe me, do a random search of uses of the template; I did 20, and all 20 were regular quotes rather than pull quotes, and I assume (and certainly hope!) that that scales up indefinitely at ~100%.)
Third, the use of the large quotation marks is pleasing to the eye, communicates quickly and efficiently to the reader that she is shifting from reading body text to reading a quotation, and is in line with reasonably professional, reasonably modern layout.

You can call big quotes a cliche or you can them a timeless classic, but either way I grant they're not cutting edge; but at least don't scream "Hi, we're from the 20th century! Isn't HTML cool?" to the reader, as {{Quote box}} does. So ugly.

I'm old enough to remember using the ASCII line characters (╔ and ═ and so forth) to draw boxes. {{Quote box}} is maybe a slight improvement on that and brings the look up into a kind of 1990s vibe. Whee. As to {{Quote}}, it's terrible -- using only indentation (which is often lost on mobile devices, on image-heavy layouts, or if your text size is set larger than standard) keeps the reader guessing about what she's reading -- is it a quote? Is it body text? You have to read ahead to figure this out. Completely breaks one's concentration, to no gain. Just awful.

Anyway, here's the solution: just do as I and everybody else who uses {{cquote}} does: simply ignore the stuff about pull quotes. Problem solved! (Obviously, we could improve things by removing the admonition about pull quotes and otherwise bring the instructions in line with actual practice. That'd be ideal. I tried doing that but an editor objected. Fine. It's not worth fighting about, as long as everyone understands -- as they appear to do -- that those instructions are just something some individual wrote a long time ago and is not worth paying any mind to.) Herostratus (talk) 04:20, 30 July 2015 (UTC)[reply]

Um, except there is no consensus at all for giant quotation marks as block quotation style on Wikipedia. The fact that a pull quote template (even if you want to call it not-a-pull-quote-template) is being misused to format a tiny fraction of block quotations doesn't magically change that. The fact that most uses of this template are for block quotations does not translate somehow into "most block quotations use that template"; just ain't the case, never has been, never will be. The fact that a CSS problem was causing block quotation to be undifferentiated from other prose when mashed up against a floated image is the primary reason some editors were citing WP:IAR to use {{cquote}} for block quotations, or to italicize quotations (or do some other thing to differentiate the text). When the CSS issue is fixed, shortly, this IAR rationale no longer exists, leaving nothing but an "I like giant quotation marks" feeling. If you think everyone loves giant quotation marks, we can just have an RfC, as I suggested to Trovatore, to see if consensus agrees with you. I think we all already know how that will go. If you think {{quote box}} is ugly propose some CSS changes to it. There are lots of ways to do more subtle things stylistically than what that template does. If you can demonstrate genuine usability problems with {{quote}}, same story: CSS exists for a reason, and it can probably be handled with a minor style change, e.g. a subtle background color shift, just enough to pass accessibility tests for contrast. Your 'at least don't scream "Hi, we're from the 20th century! Isn't HTML cool?" to the reader ... Completely breaks one's concentration, to no gain. Just awful.' is precisely why the giant quotation marks are deprecated. They look like some 13-year-old's "My First Webpage" idea of "design". We have an entire additional guideline against festooning articles with cutesy little graphics like this. For a reason. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:32, 1 August 2015 (UTC)[reply]

PS: {{Cquote}}'s very first explanatory documentation stated clearly it "is a template meant for pull quotes, the visually distinctive repetition of text that is already present in the same article. In most cases, this is not appropriate for use in encyclopedia articles.", etc. This, along with the related MOS material, dates to 2006, and consensus has not changed in favor of plastering giant quotation marks all over Wikipedia in the intervening 9 years, sorry. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:41, 1 August 2015 (UTC)[reply]

Oppose, they aren't that 'giant' and are usually interesting to run across. They accent that 'this is a quote', and usually are used for important quotes. If there are too many on a page I can see a reduction, but an occasional use seems to enhance, rather than injure, a page. Randy Kryn 12:00, 1 August 2015 (UTC)[reply]
- - The are that giant. They default to hard-coded, non-flexible 40px which is huge for most situations and insanely huge for many, and they go up and up depending on which parameter you use. They're just unbelievably poorly thought out, by people who want to make WP look like their blog. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:13, 9 August 2015 (UTC)[reply]
- They accent that 'this is a quote', and usually are used for important quotes.

This points out a significant problem with the way they are currently (mis)used. Why are Wikipedia editors deciding which quotes are "important"? Or, why would unimportant quotes be viewed as acceptable in the first place? 2600:1006:B11A:ED71:14E8:C473:9B00:7111 (talk) 22:40, 1 August 2015 (UTC)[reply]

Who should be deciding which quotes are important other than the Wikipedia editors? ~ J. Johnson (JJ) (talk) 20:16, 2 August 2015 (UTC)[reply]

Surely reliable sources and WP:UNDUE policy decide such questions. The quote I de-emphasized in at Franklin Delano Roosevelt is a case in point. There were no sources indicating anything important about the quote. It did not lead to passage in that legislation of the idea it was promoting. It's not (unlike, e.g. "E=MC²" for Albert Einstein) the best-known thing the subject said. It's not become a stock phrase. There's nothing particularly special about it, among all the pithy, political things FDR said. It was just really, really meaningful to some editor who decided to force it to be meaningful to all readers whether they'd like that or not. If reliable sources tell us that "To be, or not to be, that is the question" is the #1 best-remembered line from Hamlet, an argument could be made for pull-quoting that line in the section at Hamlet that covers that part of the play (after already quoting it in-context in the main article prose). That's an argument that should be made at Talk:Hamlet, and I think many editors would oppose it as inappropriate anyway. (I can think of multiple objections that range from: pandering to pop culture triviality instead of authorial intent; to inspiring a WP:TRIVIA-violating precedent to pull quote allegedly memorable quotes from every scene in every plot outline on WP; among others). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:29, 4 August 2015 (UTC)[reply]

All that seems pretty reasonable. I believe your point is that these decisions should be made on the basis of various standards and sources, etc., rather than on pure personal "I like it". To which I agree. However, these things don't "decide" by themselves, and there is no bot to to do that; in the end a human has to decide how all these apply. My question is which humans should decide such issues: Wikipedia editors (presumably knowledgable and acting in good faith)? a select group of "special" editors? admins only? the WMF? or just Jimbo? If WP editors generally (or any substantial portion) are not properly applying the standards, etc., then the misuse of this template is probably a minor instance of a more general problem. ~ J. Johnson (JJ) (talk) 22:50, 4 August 2015 (UTC)[reply]

I'm not sure I understand the point of the question. It's decided the way every other decision is made on WP: The editors who care enough to participate form a consensus as best they can. WP editor are in fact generally properly applying the template and the MOS; we have hundreds of thousands of block quotations in WP, and only a sliver of a fractional percentage of them are misusing Template:Pull quote and its giant quotation marks style. I agree taht there is a more general problem. It's the "I will do whatever I want, and MOS can go @#$% itself" attitude problem. There's not much to do about that issue other than nail down the style matters that they want to run off with, until they just knock off the "this is my blog, so give me my style or give me death" behavior. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:04, 5 August 2015 (UTC)[reply]

Keep in the mind the original question: "Why are Wikipedia editors deciding which quotes are "important"?" My point is that there is a continuum of what constitutes "Wikipedia editors", and the broader issue of centralizaton (or not) can be mapped to that continuum: from giving individual editors total freedom to make decisions, to giving a group ("of editors who care enough to participate") the power to decide for everyone, with no freedom for anyone else to deviate. Both extremes can be appropriate; the implicit question here is what level is appropriate for deciding on whether to use any kind of pull-quote. ~ J. Johnson (JJ) (talk) 21:45, 6 August 2015 (UTC)[reply]

Why do I need to "keep in mind" a question that is moot? Actual pull quotes are almost always WP:NPOV and WP:UNDUE problems; there is already a site-wide [anyone may freely insert the word "centralized" here, to send themselves into a pointless fit of pique if they like] decision, in the form of policies. The severable question of whether to use obnoxious giant-quotation mark icons (or other graphical decoration) to delimit block (as distinct from pull) quotations was also already decided, in site-wide ["centralized"] guidelines, both at WP:MOS quite specifically, and more broadly by MOS:ICONS. Non-neutral point of view and undue weight are not permissible, and giant quote icons around block quotations are not desirable, according to the community, per those policies and guidelines. "Who got to decide" was the entire editor base in the aggregate, over many years of editing these policies and guidelines. WP:CONSENSUS does not require unanimity. The fact that some editors ignore rules they don't like (without an WP:IAR-cognizant reason) is just an WP:OTHERCRAPEXISTS argument. This never prevents us from having a rule that is generally useful and represents the general consensus, even if there are a few who'd rather that it went a different way, oor virtually nothing would ever be decided on WP.

On the "freedom" and "centralization" stuff

All this talk of "freedom" is hyperbole that misses WP:NOT#DEMOCRACY (much less is WP some total anarchy). By such a rationale, every rule we have might as well just be deleted, since all rules on WP are created by exactly the same process and have the exact same effect (to encourage some choices and discourage others). You've already made and I've already refuted the same argument before; this any-rules-at-all-infringe-my-freedom angle seems to be a go-to argument for you, but it's not working. If you want to tie this to "freedom", fine, let's do that temporarily just for the sake of argument: The basic maxim of civil libertarianism is Your freedom to swing your fist ends when it hits my face. Your "freedom" to festoon articles with cutesy icons ends when the community at large creates guidelines saying they don't want these editorial dukes punching us in the readerly visage. Your "freedom" to rub every reader's nose forcefully into unduly cherry-picked statements you insist on browbeating them with ends when the community enacts policies against reader facial abuse by that kind of hamfisted skewing of point of view and emphasis, too. Same request I've made of everyone here: Please show us even one single case of a genuine pull quote on Wikipedia that isn't a POV/UNDUE problem. It's been over a week, and zero participants have produced a single candidate.

On second thought, it's better to consolidate this into the user talk discussion; see User talk:SMcCandlish#"Centralization" and "freedom". — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 06:15, 7 August 2015 (UTC)[reply]

Comment. I am not aware that cquotes are "rampantly abused", or that pull quotes lack "legitimate uses" in WP articles; these points are not yet established. And I have a vague memory, on once encountering such "gigantic quotes", of finding that instance not just interesting, but even amusing, And I don't know why WP articles should not occasionally be amusing. So I would be reluctant to universally and arbitrarily prohibit them. (I agree with Trovatore: "far too much is decided centrally".)

As to rampant use: how often? And is there any measure of how much of that is misuse, abuse, or just lack of care in selecting a quote template? Are there more nuanced ways of dealing with such cases? ~ J. Johnson (JJ) (talk) 20:33, 1 August 2015 (UTC)[reply]

I'm going through uses of Template:Pull quote a.k.a. Cquote right now, and virtually all uses of it are for formatting block quotations. It's actually hard to find real pull quotes in articles. When I find them, I invariably wonder "Why on earth is this being pull-quoted, other that to lead the reader?" There are also some things that look like pull quotes which are not. I'm listing examples in separate comment below, to keep them (here's that Evil Bad word again) centralized in one spot instead of mingled into the thread. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:23, 3 August 2015 (UTC)[reply]

Thank you. I appreciate the effort. ~ J. Johnson (JJ) (talk) 20:55, 3 August 2015 (UTC)[reply]

Revision: Actually, on closer examination, I have yet to find a single genuine pull quote. In each case that looked like one it was just a quote being excessively highlighted, not a pull quote (i.e. repeated quote that appears elsewhere, in proper context) — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:16, 4 August 2015 (UTC)[reply]

Update: A day later, after going through another page of 50, same story. No actual pull quotes, just block quotes misformatted, or tiny quotations someone's POV-pushing out of context, or (rarely) a blockquote using Template:Pull quote as a workaround for the CSS bug mentioned above (I'm leaving those cases alone for now, though if the CSS fix takes much longer, I'll make a temporary "Template:Quote-next-to-image" to deal with it; it would later be silently redirectable to Template:Quote).

Query - MOS:QUOTE states: "Do not enclose block quotations in quotation marks (and especially avoid decorative quotation marks in normal use, such as those provided by the {{centered pull quote}} template, which are reserved for pull quotes)." Thus MOS:QUOTE seems to implicitly recognize that pull quotes may be used, and that large so-called "large decorative quotation marks" may be used for pull quotes. Am I missing something here? Dirtlawyer1 (talk) 21:09, 1 August 2015 (UTC)[reply]

You're missing that nobody uses pull quotes because nobody should. That passage in MOS:QUOTE is simply an artifact. Delete it on the grounds that rules should follow practice. The admonition to "avoid decorative quotation marks in normal use" is nonsense. Somehow, sometime, it got put in there. By consensus? Or just by a few editors? If by consensus, in 2004? If in 2004, how many editors advocating for that are even still here? To what extent are we to be be ruled by the dead hand of vanished editors? Yet removing stuff like that require consensus -- total agreement, or at any rate a supermajority, which you are unlikely to get. Just ignore silly stuff. I've already pointed out that large quote marks are a standard in text layout for quotes, because they signify in a pleasing way and generally accepted way that the enclosed text is a quotation. Just ignore silly stuff. Herostratus (talk) 01:56, 2 August 2015 (UTC)[reply]

Herostratus, given that you support the continued use of the template which SMcCandlish proposes to ban, I believe you misinterpret both the existing language of MOS:QUOTE in context and misunderstand the point of my question above. The existing language of MOS:QUOTE supports the continued permitted use of this template and pull quotes. Dirtlawyer1 (talk) 14:51, 2 August 2015 (UTC)[reply]

(edit conflict)Herostratus: Please quote us the "standard" to which you refer. I see giant quotation marks used on a lot of blogs, but it's not a standard style in encyclopedias, newspapers, or any other class of mainstream, general-audience publications. I'm sorry that you are so upset that there's a long-standing consensus against cutesy icons being used for decoration here, but there is. There's a consensus against the idea that sort of thing is "pleasing" in an encyclopedia, both at MOS main and the entire guideline MOS:ICONS. If you want to change this, you know where WP:VPPRO is. Denialism that the consensus means what it means, that it has existed for a long time, and that it was decided for a reason doesn't do anything to change it. You write as if there's some groundswell of support across the encyclopedia for using giant quotation marks around block quotations. Prove it. Show us this army of giant quotes fans. You write as if everyone just ignores MOS with regard to block quotations and pull quotes. But it just isn't true. There are at least tens of thousands of block quotations on Wikipedia, and only a vanishingly small fraction of a percent of them are misusing {{pull quote}} to format them, mostly out of not reading MOS or the template's own documentation (when they're correctly formatted with {{quote}} they almost always stay that way), and where it's being done on purpose with a WP:IAR reason it appears to invariably because the quote is sandwiched between two images (see above about the CSS bug, which is about to be fixed). There are virtually no genuine pull quotes in Wikipedia at all. I spent hours trying to find one yesterday, and every single possible instance was either a misformatted regular block quotation, or a PoV-pushing exercise introducing some short quotation that did not already appear in the page and making it smack the reader in the eyeballs as hard as possible. Show us where genuine pull quotes are actually being used in articles, in ways that raise no POV concerns, and based on a consensus at the article's talk page that it's the best approach. I doubt there are enough examples in all of WP that it would take two hands to count them. Can you find even one? — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:16, 4 August 2015 (UTC)[reply]

Deprecate pull quotes as a start--they are generally used for editorializing, to put a quotation out of its context. This is common both in promotional articles and inn controversial ones. (e.g.

“

An excellent product

”

“

a significant increase in deaths

”

. The only valid use I can think of is to highlight a famous quotation, and this can be done with other means, such as boxes, that are less attractive to those who misuse it to evade WP:NPOV. DGG ( talk ) 04:47, 2 August 2015 (UTC)[reply]

Citation needed. I haven't seen that. And that'd only be an argument for deprecating all quote highlight devices such as {{quotebox}} (or even the use of quotes at all). Herostratus (talk) 14:28, 2 August 2015 (UTC)[reply]

That would be a perfectly fine outcome. Half of this proposal, remember, is to deprecate pull-quotes in mainspace (and MOS doesn't care whether pull quotes that are limited to non-mainspace are ugly or not; MOS only cares about reader-facing parts of the encyclopedia). They're almost never used correctly on WP, and many of us are skeptical that they don't automatically, perhaps inescapably raise WP:NPOV problems even when the proper form is observed. I'm moving my growing pile of randomly encountered examples to a separate comment, below. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:11, 3 August 2015 (UTC)[reply]

Strongly Oppose - Having reviewed the rationales supporting this proposed deprecation/ban of pull quotes and this particular template, I adamantly disagree, primarily for three reasons. First and foremost, there is no substantive difference between the quote box template liked and advocated by the OP and the so-called "large quotation marks" template that has incurred his ire. Second, what difference there is between the two templates is the result of their respective visual graphics. The purportedly favored quote box is graphically primitive, resembling so many of our infobox designs -- like they were created on a Commodore 64 in 1982; the purportedly disfavored template has a far more modern and visually appealing appearance. Third, there is absolutely nothing wrong with the judicious use of so-called pull quote, and the parade of horribles supposedly resulting from their use is, in reality, either grossly exaggerated or non-existent.

This is yet another example of unnecessary "instruction creep" based on the personal preferences of the would-be regulators. That, by itself, is reason enough to oppose this proposal. Wikipedia advances and improves, often in fits and starts, by the innovation of its volunteer editors. MOS should not be used to stymie those innovations. If other editors want to discuss a more sophisticated guideline that provides succinct guidance when the use of pull quotes is substantively and graphically acceptable, I would be willing to to entertain that discussion, but an over-reaching ban of this template and pull quotes should be flatly rejected. Dirtlawyer1 (talk) 14:51, 2 August 2015 (UTC)[reply]

- To address your reasons in order: 1) If pull quotes were deprecated entirely in mainspace (half of what's proposed here), we wouldn't be using {{Quote box}} either. Even if we wanted to keep quote box for some circumstances, making it look better is just a matter of CSS tweaking, as was already discussed above. If you don't like the way it looks, WP:JUSTFIXIT. 2) So what? We routinely deprecate and delete redundant templates, which we both agree is basically what we have here. That is mostly what WP:TFD exists for. But dealing with a particular template is not the point of this proposal. Stopping the PoV-pushing and visually obnoxious abuse of giant quotation marks in mainspace is half of it, and stopping the PoV pushing abuse of news-style pull quotes is the other, severable goal. 3) Show us an example, and I'm sure anyone here can describe why it's a POV problem or otherwise unencyclopedic. Ironically, another opponent of this proposal actually describes precisely what the problems with pull quotes are: "they ... are usually interesting to run across. They ... usually are used for important quotes". I.e., the entire purpose of them is to pointedly manipulate and lead reader attention, to something one PoV is pushing as "important". — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:59, 3 August 2015 (UTC)[reply]
  - SMcC, it sounds like you have a problem with POV-pushing, not pull quotes. One does not necessarily result from the other; in fact, a sentence or two judiciously quoted may often summarize an article or major point of the article;s narrative in a way that the lead cannot. I recommend that we treat the disease, if in fact there is one, not the symptoms. We can discuss how best to clarify the proper purpose of pull quotes by tweaking MOS:QUOTE, but I would like to see several examples of existing uses of this template that you find so offensive. As for my comments about the current state of most of our article graphics appearing as if they were generated by a 1982 Commodore 64, I stand by them. Most of our article graphics are appallingly bad. Dirtlawyer1 (talk) 01:39, 3 August 2015 (UTC)[reply]
    - Pull-quoting is an inherently POV-pushing news style. It's not encyclopedic. I've been going through uses of Template:Pull quote for hours, and I can't find even one legit, non-POV, reader-helpful case of its use. It's all one of two things: Misuse of the template as a Template:Quote substitute for block quotations, or abuse of the template for POV-pushing pseudo-pullquotes (pointed statements that do not appear, in context, elsewhere in the article, and are being highlighted to draw the reader to a conclusion an editors wants them to). Last time I was cleaning up misuse of the template, I did run across I think two uses of it for actual, real, pull quotes, both of which were questionably appropriate, again for POV/NOR "lead the reader" reasons. Even if we posit that it could be done without it being a POV problem, the costs of this outweigh the benefits. The intended effect, of summarizing the article, is supposed to be served by the WP:LEAD, anyway, and sections are summarized simply by properly writing introductory sentences, and paragraphs constructed properly. The solution to the problem that too many editors write like middle-school students is to write better, not to festoon articles with in-yo'-face graphically decorative quotations. This is not someone's blog. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:44, 3 August 2015 (UTC)[reply]
Oppose, per instruction creep and central interference. If people want to use them, there's no harm in it. Sarah ^(talk) 17:45, 2 August 2015 (UTC)[reply]
- This recurrent filibustering on the basis of "centralisation" is getting tiresome. The entire purpose of a style manual is to provide centralised style advice. To oppose because it's centralized is pure WP:IDONTLIKEIT. You and Trovatore know where WP:VPPOL is, and just need to get on with it: Propose to decentralise MOS. You both seem convinced consensus is somehow on your side despite over a decade of evidence to the contrary. Prove it. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:59, 3 August 2015 (UTC)[reply]

I think the concern about centralization is where a small group of editors makes a decision (and all decisions at this level are by a small group of editors) which is then enforced on everyone else. It is one thing to have a group (small or otherwise) that intensively studies some topic or problem to come up with the best possible guidance, which most editors come around to, and we tolerate a few hold-outs. It is quite something else to decide that all articles must conform in someway; no exceptions allowed, or even possible. While I allow that conformity is sometimes appropriate, it seems necessary to again remind that the MOS is a guideline, and to quote the nutshell: "Use common sense in applying it; it will have occasional exceptions." That there are problems (as you have referred to before) is something to work on, but I do not (yet?) see the need for authoritatian measures. ~ J. Johnson (JJ) (talk) 21:31, 3 August 2015 (UTC)[reply]

That's one way of looking at it, and there's another, but I needn't elaborate on it here. The problem with the "MOS is just a small group of editors" notion is that it's one of the most watchlisted pages on the system, and intensively watchlisted in particular by people who don't like it to expand or be restrictive and are critical of it, as well as those who work on it regularly and have a good sense of what will be stupid if added to it. It takes much more consensus to get something into MOS than average. At this point you can tell whether there's a real problem with an idea for changing MOS by a) do any of the MOS regulars oppose it (we're far more critical of potential additions than anyone else is, because we track over time what the effects are and how they interplay with other "rules"), and b) does anyone who is not an MOS regular object other than the less-than-a-handful who habitually resist everything on "ant-centralization" grounds? The anti-centralizers don't tell us anything about a proposal, only about their own extreme wiki-political position that MOS should not exist. In the end, all that MOS is, is guidance that most editors come around to, with a few hold-outs tolerated, as you put it. It's not possible for a guideline to force conformity "no exceptions allowed". It's perfectly reasonable for a rejected style to be removed from a template; this kind of cleanup is done quite routinely. Or prevented from firing off in mainspace; this is less common but has precedent (e.g. Template:Strongbad). If for some WP:IAR reason someone insists on some MOS-unsanctioned style no matter what in some particular article, all they have to do is <div style="arbitrary CSS here"> to evade the guideline. We shouldn't be providing templates that effectively encourage evasion, and make it really, really easy, just for personal "it looks pleasing to me" reasons. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:16, 4 August 2015 (UTC)[reply]

Illustrative examples of abuse: Since most uses of Template:Pull quote are actually to mis-format block quotations, it takes a prohibitive amount of time to provide piles of examples, but I've taken a few hours to go through the first 50 pages of "What links here" results for Template:Pull quote a.k.a. Cquote, and every single case that isn't just mistaken use of the template for block quotes is a problem:
- That. is not a pull quote; the text does not appear anywhere else in the prose of the article. It's one editor's highly PoV attempt to force the readers' attention to what that editor thinks is the key to understanding the New Deal. It's blatant PoV editorializing, as well as original research – if you do even a few minutes of source research, you find that secondary sources provide that where were multiple rationales behind that policy strategy, not just low wages; our own article covers this in very section in which this nonsensical abuse of a pull quote template appears. And it's totally out of context; it has nothing at all to do with the paragraph that precedes or follows it. I fixed it here.
- One I fixed here, that had the effect of making the "most important" point in the entire Bede article (according to whoever decided to abuse the pull quote template) just three words that Bede said about the Bible. I mean, really, WTF? This has to stop.
- Similar example in the lead at Gioachino Rossini. Haven't done anything with that one yet. The quote is so context-free I'm not even sure where to integrate it, or just delete it.
- Just fixed another one here, which was using an unsourced pair of non-contiguous statement to shove in reader's faces a pseudo-pullquote editorializing one side's view about a legal case.
- Oh, here it was being used half a dozen times in an infobox to add giant quotation marks all over the references section.

I could do this all day, and I doubt I'd find a single legitimate use of a pull quotation on Wikipedia. How many more examples would anyone like of how this is being misused? — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:02, 3 August 2015 (UTC)[reply]

I'd be happy to see {{cquote}} modified so that it doesn't display the quotation marks in the main namespace. A namespace switch should solve the problem without needing to edit the articles, and then they can be cleaned up at leisure whenever someone is editing the article anyway.
On the question as it was introduced, I disagree that encyclopedia articles "aren't written in news style"; I believe what the OP means is that they're not written in "tabloid style". Wikipedia articles should adhere quite closely to the key points of actual news style (most important information first (aka inverted pyramid), first sentence clearly and directly identifies the main subject (aka never bury the lede), no teasers, write concisely and clearly, etc.) WhatamIdoing (talk) 01:13, 4 August 2015 (UTC)[reply]

Some aspects of newswriting structure apply to encyclopedia writing; rather they're formal writing structure in general, which newswriting also uses. There are dozens of ways encyclopedic writing is not like newswriting at all, however, and most of them are stylistic (presentation) not structural (content). I wasn't meaning to imply that the two have nothing at all in common. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:16, 4 August 2015 (UTC)[reply]

Support. Yep, I support all four of those proposed changes, although I hear some of the voices here who have expressed concern about any decision being made so centrally. The giant quote marks add emphasis, particularly in the setting of block quotes, that's completely uncalled for when guidelines require a balanced tone in prose. I'm afraid I can't come up with specific examples, but I remember seeing block quotes (that is, when they're rendered as cquotes) that give an inordinate level of importance to a few lines of text, thanks to the grand punctuation treatment, so that any previous (inline) quotes appear trumped. In cases where the discussion concerns a contentious issue and we're giving conflicting opinions, it can seem as if we're signposting a particular commentator's or protagonist's viewpoint. I've seen them used in quote boxes also (along with a tinted background). It just looks gimmicky – like an advertising flier. JG66 (talk) 16:42, 4 August 2015 (UTC)[reply]

Oppose We don't need to remove this option, contrary to the proposers claim there are many good reasons why one might choose to emphasize a quote in this way in an article. There is no need to ever remove options just for the purpose of enshrining specific editors' aesthetic preferences in hard rules. A good MOS does not micromanage, but simply handles the general impression. ·maunus · snunɐɯ· 18:04, 4 August 2015 (UTC)[reply]
- So demonstrate it. Not by WP:POINT to go out of your way to try to manufacture one, but by demonstrating extant, legitimate usage. Same thing I've asked every other opposer to do. If no one will rise to the challenge, then there's no basis for the opposition. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:40, 5 August 2015 (UTC)[reply]

Noone has to "rise" to you "challenge" - it is a question of taste, and whether you like any specific usage or not is irrelevant - so no I have no reason to give you some example of a usage that I consider appropriate and which you can then subsequently poo-poo based on some arbitrary criteria for good style .·maunus · snunɐɯ· 07:38, 5 August 2015 (UTC)[reply]

You're commingling two severable concerns. MOS already says not to use giant quotation marks: "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". So it is not a question of taste. That question was raised years ago and settled; I'm sorry that you don't like the way that went. If you want to change it you know where WP:VPPRO is, or how to open a WP:RFC right here. Separately, actual pull quotes are extremely rare on WP (I've been looking for three days and still can't find one), because they almost invariably pose a WP:NPOV problem. I'm not asking you to provide an example of a pull quote on WP so anyone can critique it stylistically, but to demonstrate an example that isn't a PoV problem, i.e. a WP:CORE content policy issue. I.e., there appears to be no policy-cognizant rationale for use of pull quotes at all, even aside from the already settled matter of abusing pull quote templates for non-pull-quote material. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:04, 5 August 2015 (UTC)[reply]

I agree that MOS shouldn't micromanage, but a warning might not be a bad idea. Are there any cases where a warning is given for something that seems to be against the MOS guidelines? Many editors don't read MOS until it is too late. Gah4 (talk) 19:52, 4 August 2015 (UTC)[reply]
- As far as I know, there's no such things as a MOS-related warning. When people misuse the template for things that are not pull quotes, the appropriate thing to do is reformat the quotation correctly. Hypothetically, if there were an actual pull quote being used and its use seemed questionable for POV or other policy reasons, the appropriate thing to do would be to raise a discussion about it on the article's talk page, not issue "warnings". But I can't seem to find any actual pull quote in Wikipedia articles, anyway. Every single case of use of Template:Pull quote in mainspace that I've looked at so far (the first two pages of the "What links here" results for that template) is one of the two previously outlined misuses of the template for things that are not pull quotes. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:53, 5 August 2015 (UTC)[reply]
Oppose I don't see much substance to the argument here beyond WP:I DON'T LIKE IT. We already have plenty of issues trying to make things stand out against too much formatted copy. Pulling a tool out of the functional arsenal out is a bad idea. Trackinfo (talk) 02:16, 5 August 2015 (UTC)[reply]
- Same as with everyone one: Please demonstrate. I've been through 150 uses of this template over the last few days, and in every single case it has been one of the following: 1) Misuse of {{Pull quote}} to markup a block quotation not a pull quote. 2) Misuse of {{Pull quote}} to markup some tiny quotation that is neither a pull quote nor a block quote, but something one editor wants to browbeat readers with in a POV-pushing manner. 3) Occasional use as an "emergency" measure to get around the CSS bug documented above. In a substantial number of cases it's clearly just totally random, because the same article uses two or even three block quotation styles in the same page, with no rhyme or reasons (obviously I've been cleaning these up as I go along). I have yet to find a single actual pull quote. Even if there are some, how much do you want to bet they raise a PoV problem in the context in which they're used? Assuming there might be some that don't, how many do you think really need to be formatted that way in order to help readers? Can you give even one example? I'm not making an ILIKEIT argument. The argument is based on the plain wording of MOS and the template's own documentation, and days and days of actual research into how this template and style are being (mis)used. That's three reality-based rationales. And you have brought "I don't see ...". Technically, I suppose that's WP:IDONTKNOWIT not ILIKEIT. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:39, 5 August 2015 (UTC)[reply]
Update: The "desperation" use of Template:Pull quote as a workaround for block quotations (not pull quotes) that were not formatting properly next to images, has now been obviated; see Template:Quote/doc#Next to left-floated images. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:27, 5 August 2015 (UTC)[reply]
Comment A (separation of semantic and presentation templates). As an infrequent editor, what I mostly want is a simple way to mark something semantically as a {{block-quote}}, and be able to have faith that it will render in an attractive and understandable manner across desktop, tablet, and text-to-speech. This would then redirect to or encapsulate the desired underlying template, like {{Quote}} or {{Quotation}}. Occasionally, I might find a need to tweak the layout, which is where a presentation-specific template might have to be used directly. In a perfect world, there would be a small set of recommended templates that would implement MOS and clearly indicate their intent. Pelagic (talk) 01:18, 9 August 2015 (UTC)[reply]
Comment B (fix poorly marked-up articles). Personally, I feel that the current MOS guidance to use only indenting without quotes or italics leaves block quotations looking a little underdistinguished in some contexts.^† Perhaps that is why people are adding extra typographic embellishments. If it's just an end-run around the house style, then it needs to be removed at the source, just like you would if an editor had added ''italic'' mark-up to a whole block quote. Or perhaps most editors don't understand what a true pull quote is. Then they should be informed by having their markup corrected to {{blockquote}}. Either way, you find something like {{pull quote|This is really a block quote}}, which is misleading mark-up and ideally should be fixed where it occurs. Pelagic (talk) 01:18, 9 August 2015 (UTC)[reply]

† But the addition of any other styling to block-quotes is likely to be controversial, and could break things. In any case it should be done through CSS, not add-on markup. {{Quote box|{{Pull quote|{{Big|{{Strong|Do we like this?}}}}}}}} Pelagic (talk) 01:18, 9 August 2015 (UTC)[reply]

Comment C. But I also see SMcCandlish's point, that correcting the many misuses where they occur is time-consuming. And, yes, when a template exists, it says "uuuse meee". For the many editors who have not encountered the, umm, "social" aspects of Wikipedia, the existence of a template may seem to imply that its use is officially approved. Disabling the giant quotes could help, but then it leaves you with a confusing situation where two templates effectively do the same thing. Pelagic (talk) 01:18, 9 August 2015 (UTC)[reply]
Comment D (proper pull quotes). As for the styling of genuine pull quotes, normal usage in magazines is to float a small box, with a border or tint. In newspapers with narrow columns the box spans one or two columns, and is set off with top and bottom rules (lines/borders). Text style is larger, often bolder, and sometimes set in a different font. Big quote marks may be added, particularly for an opinion piece or he-said-it type of quote from an interview, but not typically when a normal sentence from the text is being promoted. Could we have a template & CSS class that achieve all of this? Is it worth the effort? Pelagic (talk) 01:18, 9 August 2015 (UTC)[reply]

P.S. sorry for the "Comment A, Comment B, Comment C" business, but I couldn't see a workable way to split a single list item into manageable paragraphs. Also sorry for signing each one separately, but's necessary in case the items get separated by intervening commentary. Pelagic (talk) 01:18, 9 August 2015 (UTC)[reply]

Support (2) "Recommend generally against the use of pull quotes because they are rarely appropriate in encyclopedic text.". MOS already says to use {{quote}} not {{cquote}} for block quotations, and it's being ignored. Proper pull quotes aren't being used much in article space, but if it would help to make it explicit in MOS, then do add the guidance that they are inappropriate. Pelagic (talk) 01:59, 9 August 2015 (UTC)[reply]

Qualified-Support (1) "Disable the display, in mainspace, of giant quotation marks in templates that use them". I was initially neutral or weakly against this, on the grounds that it could add confusion and be kludgy. But after skimming the discussion at Template talk: Pull quote, I am more in favour. However, if it's mostly {{cquote}} that's the problem, then can we start by adding the context-switch just to that one template? Or change the redirect as was supported in 2013? Pelagic (talk) 01:59, 9 August 2015 (UTC)[reply]

@Pelagic: Changing the {{Cquote}} redirect so it goes to {{Quote}} would be handy for the cleanup effort, since about 90% of uses of that are for misformatting block quotations, and 9.999% for PoV-pushing short quotes that are not even block quotations, with only a tiny, tiny handful of actual pull quotes ever being used in mainspace. But thousands of the same misuses are directly calling {{Pull quote}}, or using other redirs to it, e.g. {{Centered pull quote}}, so that won't actually fix the problem. Doing a namespace switch on {{Pull quote}} would temporarily fix about 99% of the problem, but as we can see above, some editors have an "I will use giant quotation marks no matter what" attitude, so it just needs to be deprecated across-the-board. So, yes, I support both of these moves, but they are only partial measures, and will continue to lead to WP:GAMING misuse of pull-quote formatting for block quotations, and for PoV-pushing short quotes.

Re: Comment A: {{Quote}} already allows you to tweak layout; got that covered.

Comment B: Most editors here very clearly do not understand what a true pull quote is. As for block quote, this "undistinguished" style of indentation is what almost all publications do. There'd probably be considerably resistance to doing something "fancy" with it, but maybe a barely WCAG-acceptable contrast shift in the background could do it. Whatever, it would be a separate proposal, and a major site-wide change to hundreds of thousands of articles, I would think.

Comments C, D: If we just got rid of giant quotation marks, the templates could certainly be merged; almost all the quote templates already have been. In the ultra-rare case that someone want to use a genuine pull-quote there are other templates for this, and the not-so-awesome box styling of the more popular one, {{Quote box}}, is simply matter of some CSS tweaking to improve. I'm skeptical it's worth the effort because a) we have almost no real pull quotes, and b) actual use proves that people will abuse PQ templates to POV-push non-PQs. WP doesn't need PQs. Just because some publications use them doesn't mean WP has to (and is almost entirely does not). After a week of looking, I still can't find a single extant example. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:56, 9 August 2015 (UTC)[reply]

MOS's own overuse of "U.S."

Most if not all cases of the MOS itself using "U.S." instead of "US" should be replaced. MOS does not directly advise use of the dot-laden form; we just note that it is popular in North American but that the leading US style guide has deprecated it. MOS does advise: "Use of periods for abbreviations and acronyms should be consistent within any given article and congruent with the variety of English used by that article." While MOS does not have to follow itself, we generally do ensure that it does, or it is difficult to get people to follow it in articles. Since MOS refers to the "UK", etc., in various places, it should for consistency refer to the "US" not the "U.S.", except when illustrating the string U.S. in a words-as-words manner.

We should probably also revisit MOS's claims that "In American and Canadian English, U.S. (with periods and without a space) is the dominant abbreviation for United States" and check the ground truth of this assertion, but that's another matter for another time. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 04:52, 10 August 2015 (UTC)[reply]

I strongly disagree. ... By all means, let's review what current American style guides say on points, but in the mean time, let's not impose our personal preferences on the MOS by removing all instances of "U.S." -- it is, after all, the majority practice in American English. Dirtlawyer1 (talk) 05:40, 10 August 2015 (UTC)[reply]
- [Detailed evidence and arguments about source usage refactored into new topic, below, since that's a separate matter. Whether it's the dominant usage in American publications is not being questioned here. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:39, 12 August 2015 (UTC)][reply]

Strongly disagree about what? There are multiple things here to agree or disagree with:

MOS should follow its own advice.
MOS always using "U.S." conflicts with its own advice to not do this in pages that also use "UK", "UN", etc.
We should sometimes check that MOS's claims about use of "U.S." are true, not blindly assume they'll be true forever.
That's actually a separate issue from whether MOS should follow its own advice.

[material about the sourcing issue refactored to thread below] — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:08, 10 August 2015 (UTC)[reply]

"US/"U.S." is one of those times when English has multiple correct options. I don't think we should ban one of them unless we can show that doing so would solve a problem.

If precedent is needed, note "The Hague" vs "the Hulk"; some proper nouns get a capital T and some do not.

As for whether style guides still say to use "U.S.," SmC makes a very valid point, and one that's easy enough to address. [Text moved to relevant subsection established by SmC] Darkfrog24 (talk) 16:17, 11 August 2015 (UTC)[reply]

As to what the MoS should say in its own text, is it inconsistent right now or does it use "U.S." consistently right now? I prefer U.S. in this case because it would be easier to find in a CTRL-F search and therefore easier to modify if necessary. Darkfrog24 (talk) 16:25, 11 August 2015 (UTC)[reply]

"The Hague" is a different kind of case, covered under a different MOS rule, and one in which usage is almost 100% uniform in reliable sources, which is nothing like the case with "U.S." MOS's use of "U.S." is inconsistent in that several of these pages also have "UK", and we're advising consistently using "US" in such cases, not mix-and-matching styles. It may well also be inconsistent in another way, using "U.S." in some places and "US" in others, but I didn't check, since it's not necessary to make such a case. There's no need to search-and-replace "U.S." other than to "US" anyway, so I don't see what utility point there would be. It's something we'd only need to do once. That "U.S." would be easy to replace with "US" is an argument for replacing it with "US", not for keeping it as "U.S." Heh. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:48, 12 August 2015 (UTC)[reply]

SmC, if what you're trying to do is convince other people that you're right, then yes it is a good thing to check. By "inconsistent," I mean "Does the MoS use 'U.S.' sometimes and 'US' other times." I used "The Hague" as an example of how we sometimes allow two seemingly inconsistent usages in the same article: "In one issue, the Hulk visited The Hague," etc.

Actually, the CTRL-F matter would be useful in many more situations. Two spring to mind:

Assessing the national flavor of the MoS, such as checking how many times the MoS mentions specific countries (Does the MoS mention America too often? More often than France?) The American-ness of Wikipedia comes up occasionally so this might turn out to be useful.
Serving users who come to the MoS looking specifically for American English rules/guidance. Searching for "American" and "U.S." would be less of a hassle than searching for "American" and parsing every single "US," even if they think to enable whole-word and case matching, which not everyone does. Darkfrog24 (talk) 20:43, 12 August 2015 (UTC)[reply]

Is "U.S." still the dominant usage among Americans, and if so, to what extent?

[Later-added intro to give this some context, after a refactor to split unrelated topics that were being confused:] Some editors might suggest: "MOS should stop recommending [or even stop allowing] 'U.S.' instead of 'US'." — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:39, 12 August 2015 (UTC) [Note: I did not make this argument, nor did anyone else in recent memory.][reply]

I strongly disagree. The overwhelming majority of American style guides continue to strongly prefer "U.S." over "US" for writing prose in American English. And this is reinforced by the overwhelming use of "U.S." in mainstream American media. If anyone doubts this, a quick Google news search of the largest American newspapers will disabuse them of their misperception of what is most commonly used in American publications. Below are listed the 20 largest daily newspapers in the United States by circulation:
[list refactored to top of #American journalism sources so we can keep the lists orderly]

Yes, there are publications that routinely use "US" in prose, but they represent the decidedly minority practice in the face of mainstream media usage. By all means, let's review what current American style guides say on points. Dirtlawyer1 (talk) 05:40, 10 August 2015 (UTC)[reply]

I have added the remaining 13 of the 20 most widely circulated daily newspapers in the United States to the above list. Seventeen of the top 20, or 85%, consistently use the abbreviation "U.S." in preference to "US" (without periods). It is also worth mentioning that of the three of the 20, or 15%, that consistently use the abbreviation "US" (without periods) in prose, two are tabloids.

Of the five major national television news networks in the United State, four of the five, or 80%, consistently use the abbreviation "U.S." in prose, and the fifth appears to use it inconsistently. This use by the major American television news networks is completely consistent with the "dominant" usage of "U.S." in the American print news media. Dirtlawyer1 (talk) 18:40, 11 August 2015 (UTC)[reply]

[lists refactored to #American journalism sources so we can keep the lists orderly]

Attempts below to characterize these newspapers as "local" in nature is misleading at best, and ignorant of America's mainstream media at worst. As a group, they represent "prestige" journalism in the United States, including the so-called "national" papers, The New York Times, USA Today, Wall Street Journal and The Washington Post. As such, they are extremely influential in the daily usage of millions of Americans, and at least one of them even publishes its own American English style guide. From that list, it is clear that that "U.S." represents the dominant usage among major American daily newspapers, and their influence is widespread and represents the present mainstream consensus in American journalism. I will respond later today or tomorrow with a list of American style guides and their guidance on the topic of "U.S. vs. US" usage in American English. Dirtlawyer1 (talk) 18:19, 11 August 2015 (UTC)[reply]

I said some of them were local, and specifically said some where not. Don't put words in my mouth, especially after expanding the list to include additional entries that were not there the first time. Also please stop throwing accusations of "ignorance"; I already addressed this with you on my talk page. It's WP:UNCIVIL at best. Just because someone disagrees with the influence you want to ascribe to some publications doesn't make them know-nothings. In particular, I find it questionable that what newspapers in particular (especially since more and more of the public get their news from online content aggregators and news portals today) or news outlets more generally are doing is a good indicator of overall usage across all American WP:RS material. (I think it will presently also prove to be the dominant usage in other American paper sources, but not in online sources unconnected to a paper source. That's not a matter of whether you or I say so, but a matter of what source research demonstrate, and that needs to be conducted in an orderly fashion or it's a waste of time and effort. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:50, 12 August 2015 (UTC)[reply]

The conclusions I'm coming to so far are:

"U.S." probably is the dominant practice in running prose in American paper journalism (and online copies thereof, and on-screen text in the TV equivalent).
This tells us nothing about general usage, only journalistic use.
This tells us nothing about the suspect claim that it's favored in Canadian English.
"U.S." may not be dominant in online usage, except at sites tied to paper/TV journalism, and even there usage is mixed.
"US" is the minority usage is modern, American dictionaries.
Usage is mixed in American and general style guides. But several of the most influential outside of news journalism prefer "US"'.
Whatever dominance "U.S." may have in journalism, it is slipping, and usage is actually quite inconsistent, even in the same publication (most often between headlines vs. running prose).
This all suggests that MOS should not recommend it, but simply permit it especially in reference to the U.S. government (incl. the military and the legal system), in articles in American English.

It's been my experience that when I change "U.S." to "US" in articles, I'm virtually never reverted on it, unless it's when there's a topical tie to the US government or branch thereof.

[lists refactored to #American journalism sources, so we can keep the lists orderly]

— SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:50, 10 August 2015 (UTC) Updated: 17:26, 12 August 2015 (UTC)[reply]

I personally don't have a problem with an editor changing an article solely to suit his or her own personal preference so long as that editor doesn't make a big deal of any reversion or takes it to the talk page. It sounds like that's what's going on with you, SmC. Darkfrog24 (talk) 20:49, 12 August 2015 (UTC)[reply]

American journalism sources

Major U.S. newspapers that consistently use "U.S." (with periods) in prose:

"Kelli Ward enters GOP Senate race against John McCain," The Arizona Republic
"Johnny Isakson, David Perdue split on highway funding bill," The Atlanta Journal Constitution
"Dem Senate hopeful Zopp offers support for friend facing grant-fraud sentencing," Chicago Sun-Times
"Despite gaffes, it's Kirk or bust for Republicans," Chicago Tribune
"U.S. Senate votes to curtail sweeping surveillance of Americans' phone records," The Dallas Morning News
"Republican Ellen Roberts faces difficulty for possible U.S. Senate run, The Denver Post
"U.S. Senate passes roads bill; House won’t take up now," Detroit Free Press
"In the U.S. Senate, it's Ted Cruz, of counsel for the right," Houston Chronicle
"Top U.S. Senate candidates run quietly, for now," The Los Angeles Times
"Endorsement: For U.S. Senate, Al Franken," Minneapolis Star
"Torricelli, a decade later, wants back in to the Big Game," The Newark Star-Ledger
"Charles Schumer: From bold assemblyman to U.S. Senate power player," Newsday
"29 U.S. Scientists Praise Iran Nuclear Deal in Letter to Obama," The New York Times
"Top aide to Wolf approached about running for US Senate, Philadelphia Inquirer
"Kander has $1.1M to challenge Blunt for US Senate seat," San Francisco Chronicle
"Senate poised to take up education bill," USA Today
"U.S. Senate Blocks NSA Surveillance Bill, Patriot Act Extension," Wall Street Journal
"Edwards: ‘Make room for one black woman’ in the U.S. Senate," The Washington Post

Major U.S. newspapers that consistently use "US" (without periods) in prose:

"Cardinal wants funding to Planned Parenthood cut," The Boston Globe
"State Assembly group wants to change proposed presidential primary date that conflicts with Passover," New York Daily News
"‘One man, one vote’ ruling could upend New York politics," New York Post

Dirtlawyer1 (talk) 05:40, 10 August 2015 (UTC)[reply]

Updated: Dirtlawyer1 (talk) 18:19, 11 August 2015 (UTC)[reply]

Major television news media that consistently use "U.S." (with periods) in prose:

"Democrat Katie McGinty Running for US Senate in Pennsylvania, ABC News
"NSA phone data collection suspended," CBS News
"With Kamala Harris in for Senate bid, Tom Steyer edges closer to a run," CNN
"Wisconsin's Feingold to run for US Senate," Fox News

Major television news media that inconsistently use "U.S." (with periods) in prose:

NBC News

Dirtlawyer1 (talk) 18:19, 11 August 2015 (UTC)[reply]

Usage is in fact wildly mixed. While most of Dirtlawyer1's [originally posted] examples are local-market publications, it's actually true that plenty of papers read nationwide in the US (Wall Street Journal, New York Times [which he did cite], Washington Post, and several others) consistently use "U.S." But some don't, and many use it only inconsistently. I'll start by looking at news sources, below, and save other kinds of sources for later analysis. This is just from a couple of minutes of search results, on "US government" and "US interests". Note: In this section I'm intentionally providing "US" counter-examples to the above "U.S." examples. In later sections (style guides, dictionaries, etc.), I'm not cherry picking but just checking modern sources in the order I grab them from the bookshelf or harddrive. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:50, 10 August 2015 (UTC) Updated: 17:26, 12 August 2015 (UTC)[reply]

ABC and its affiliates mostly seem to avoid the "U.S." usage

ABCNews portal at Go.com (but not entirely consistently; see below)
ABC Action News
ABC 7 News

So do several other major news outlets

A very large number of sources eschew this style in headlines, headings, titles, etc., but seem to prefer it in running prose

ABCNews portal at Go.com (but not always; see above)
U.S. News and World Report (yes really, despite their own title)
Voice of America
KGNS TV (NBC, Texas)
Huffington Post
Reuters
Fox Business News
Yahoo News (US)
Native Times
Alaska Dispatch News
The Hill (Washington DC)
Star Tribune (Minneapolis)

One noteworthy thing in this regard is that the metadata emitted by many sites and used by search engines uses "US" not "U.S." This "not in headlines" (and, evidently, metadata) is because of the AP Styleguide's recommendations; see style guides section below.

The trend in WP:NOTPAPER news publications is away from "U.S."

Some do, of course, use "U.S.", but that usage is definitely not "dominant", and only appears to prevail in publications tied directly to paper newspapers and magazines.

"US" is frequent in tech publications

It's actually hard to find tech news using "U.S."

"US" is also frequent in a lot of narrower-market news sources

Christian Science Monitor
Christian Today
KZTV News (Oregon)
WLRN News (Florida)
Caribbean Journal (though it might be influenced by British or French usage)

Plenty also use "U.S.". The point being, usage is very mixed, and is clearly becoming increasingly mixed over time. If you do searches like this every few years, as I do, you'll notice it palpably.

As an odd datapoint, I've found that content in the International New York Times tends to use "U.S." at the parent site, but "US" when syndicated, e.g. in India, etc. This tells us the preference of the publisher, but nothing about usage. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:50, 10 August 2015 (UTC)[reply]

Neat! I think we should continue to allow both U.S. and US, even though U.S. seems like it would be less likely to be confused with "us." Darkfrog24 (talk) 16:19, 11 August 2015 (UTC)[reply]

Style guides, dictionaries, and other tertiary sources on U.S. vs US

Regarding style guide sources, I did hear that Chicago MoS changed its mind a few years back but I don't know if it said to allow both or to prefer "US." Tony1 would remember; he was pretty happy about it.Darkfrog24 (talk) 16:19, 11 August 2015 (UTC)[reply]

No need to remember; I have it and many others, just hadn't gotten around to the quoting yet. :-) I've included it below. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:47, 12 August 2015 (UTC)[reply]

Style guides

The APA Style guide (via Purdue Owl) says to use just "U.S." [1] Darkfrog24 (talk) 16:19, 11 August 2015 (UTC)[reply]
Chicago Manual of Style, current (16th) ed. U. of Chicago Pr, at "10.2: Acronyms, initialisms, contractions": "Use no periods with abbreviations that appear in full capitals, whether two letters or more and even if lowercase letters appear within the abbreviation: VP, CEO, MA, MD, PhD, UK, US, NY, IL". (It continues with an odd rule that MOS does not implement and never would because we don't use "N.Y." or "Ill.": "In publications using traditional state abbreviations, use periods to abbreviate United States and its states and territories: U.S., N.Y., Ill. Note, however, that Chicago recommends using the two-letter postal codes (and therefore US) wherever abbreviations are used").
The ACS Style Guide, 3rd ed. (2006), American Chemical Society: Does not match WP usage any way on such questions. It uses "U.S." but it also uses "U.K." which WP would never do. It does not offer a rationale/rule for this. It does have a rule about when to abbreviate at all, but it does not agree with WP usage: "Use the abbreviations U.S. and U.K. as adjectives only; spell out United States and United Kingdom as the noun forms in text. Either United Kingdom or U.K. may be used in addresses." (p. 161). Its chapter "Abbreviations and Acronyms" (pp. 158–162), largely illustrates no-dot usage, including for US states, and numerous other examples ("UV ultraviolet", etc.), but has idiosyncrasies, e.g. "P.O. Post Office (with Box and number)" (odd capitalization in the original), despite the fact that USPS and other postal services specifically advise against this style (it complicates OCR of addresses), and recommend "PO". So, ACS is not a reliable source on this matter, though it is of course on chemical nomenclature and other subjects within its area of expertise.
MHRA Style Guide, corrected 2nd ed. (2009), Modern Humanities Research Association. "4.4: Use of Full Point", p. 24 says: "(b) countries, institutions, societies, and organizations (none of them italicized): UK, USA, BL, BM, UNAM, ..." (and it does the same in the next section, with US state abbreviations). MHRA does not contain the character string "U.S." anywhere within it. While the MHRA is published in the UK, it is used in the humanities broadly, not only by UK writers/publishers (the major ones like Oxford U. Pr. and Cambridge U. Pr. are bi-continental anyway, and produce a larger output in the US than they do in the UK).
MLA Handbook for Writers of Research Papers, 7th ed. (2009), Modern Language Association. "7: Abbreviations; 7.1: Introduction" (p. 234): "The trend in abbreviation is to use neither periods after letters nor spaces between letters, especially for abbreviations made up of all capital letters." At "7.3: Geographic Names", it never uses dots except when truncating, e.g. "Afgh." for "Afghanistan". In the long list of country name abbreviations, it gives: "US, USA United States, United States of America" (p. 239), just like for all other country acronyms. At "5.7.14: A Legal Source", (pp. 205 206) it specifically recommends The Blue Book but adapting it to the MLA's style, illustrating this with "... 347 US 483-96. Supreme Court of the US. 1954 ..." (emphasis added). This is the dominant style guide in American academic writing (in the absence of an in-house or field-specific standard).
The Associated Press Stylebook and Briefing on Media Law 2009, p. 286: "U.S. The abbreviation is acceptable as a noun or adjective for United States. In headlines it's US (no periods). USA No periods in the abbreviated form for United States of America." (inconsistent words-as-words italics in original).
The McGraw-Hill Handbook of English Grammar and Usage, 1st ed. (2005), weirdly has no distinct chapter on abbreviation, nor one on punctuation, and does not cover this even with examples (e.g. in the "Capitalization" chapter, where one might expect examples of acronyms). It's a very grammar-focused work, and intended for everyday people, not professional writers of any kind.
Gardner's Modern American Usage, 3rd ed. (2009), Oxford U. Pr. "U.S.; U.S.A. As the shortened forms for United States of America, these terms retain their periods, despite the modern trend to drop the periods in most initialisms. U.S. is best reserved for use as an adjective ... although its use as a noun in headlines is common. In abbreviations incorporating U.S., the periods are typically dropped" (p. 835).

Will add more as I go through the bookshelf and the documents drive. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 17:14, 12 August 2015 (UTC)[reply]

Dictionaries

Oxford Dictionaries allows both [2]. Darkfrog24 (talk) 16:19, 11 August 2015 (UTC)[reply]
Oxford American Dictionary, 3rd ed. (2010), p. 1907 gives "US" as the primary spelling: "US → abbr. – (also U.S.) United States". Nearly identical entry for "USA (also U.S.A.)". At p. 1892: U•nit•ed States (abbr. US or U.S.)".
Merriam-Webster's Collegiate Dictionary, 11th ed. (2003), p. 1378: "US abbr United States" is all it says. There is no entry for "U.S." (I checked both back and front of "U" section, as well as the "Geographical Names" chapter). M-W Collgiate is the best-selling US dictionary in the US. Merriam-Webster is part of Encyclopaedia Britannica, Inc. (based in the US since 1920, despite its name). Several M-W dictionaries are abridged from this one, and can be treated as the same source, but some others are derived from the Webster's Third New International Dictionary (1961), which itself is too old to matter here, but newer dictionaries based on it should be treated as separate sources.
Webster's New College Dictionary [previously Webster's II], 3rd ed., Random House (2008), p. 1330: "US 1. Uncle Sam. 2. Uniform System (of lens aperture). 3. United States. u.s. Lat. 1. ubi supra (where [mentioned] above). 2. ur supra (as above)." Does not give "U.S." anywhere, including in the "Geographical Names" entry for United States of America. Like various other "Webster's" dictionaries, this one is independent of the Merriam-Webster publications. Webster's II New Riverside Dictionary explicitly states it was abridged from the Random House New College, so I'm counting them as a single source.
Random House Webster's Dictionary, 4th ed., p. 788: "US or U.S., United States". Curiously, they elsewhere give "UK, United Kingdom"; "U.A.E. or UAE, United Arab Emirates"; "U.S.S.R. or USSR, Union of Soviet Socialist Republics", as if explicitly deprecating "U.S."
American Heritage Dictionary of the English Language, 5th ed., Houghton Mifflin Harcourt (2011), p. 1907: "US or U.S. abbr. 1. Uncle Sam. 2. Uniform System (of lens aperture). 3. United States. 4. United States highway." Similar "USA or U.S.A." entry. On p. 1895: "United States or United States of America Abbr. US or U.S. or USA or U.S.A. This is very noteworthy, because (as its name suggests) this is the most conservative and traditionalist American dictionary; it was created explicitly to counteract the descriptivist vs. prescriptivist stance of Webster's Third New International Dictionary (1961). The other AH dictionaries are all abridged from this one; treat as one source (I checked: AH College Dict. has identical entries, and the little paperback desk one has no entry).

Will add more as I go through the bookshelf and the documents drive. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 17:14, 12 August 2015 (UTC)[reply]

Refactoring

Moved to User talk:SMcCandlish § Please do not refactor other editors' comment

Off-topic. This has nothing to do with improving MOS. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 13:19, 12 August 2015 (UTC)[reply]

The following discussion has been closed. Please do not modify it.

@SMcCandlish: Per WP:TPO, I have objected to your refactoring of my comments on this talk page. I have left a message on your user talk page, even as you continue to edit here: do not refactor other editors' comment. Will you revert your refactoring of my comments on this talk page, to which I have objected and as requested? Dirtlawyer1 (talk) 12:22, 12 August 2015 (UTC)[reply]

And I've objected to you revert-warring to preserve counterproductive confusion between unrelated threads. This is precisely the kind of refactoring that WP:REFACTOR advises. [trim - moved the rest to my talk page] — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:33, 12 August 2015 (UTC)[reply]

And now you're continuing the discussion on my talk page again. I'll be happy to do likewise. We do not need to have the same conversation on two pages at once. This conversation has nothing to do with improving MOS. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:37, 12 August 2015 (UTC)[reply]

FAQ addition on argument to authority

The Manual of Style, like other Wikipedia policies and guidelines, is not encyclopedia content governed by external sources. Such pages are sets of internal rules developed by editorial consensus of the Wikipedia community. Consensus discussions about style may compare the approaches of various external style and usage guides, but this is not required for Wikipedia to come to consensus. Inclusion of advice depends on neither third-party authority nor internal proof of an ongoing problem, but is based principally on common sense about best practices for the broad encyclopedia readership.

This is a variant of the last version discussed, tightening the meaning, and adding links, e.g. to WP:Common sense and WP:ENC. This FAQ addition would make two key points:

MOS, like the rest of WP:POLICY material, isn't determined by what external entities might prefer that the community do; argument to authority has no sway here, and WP guidelines and policies are not subject to WP:GAMING by pretense that they are articles subject to WP:RS.
These pages largely codify extant best practices preferred by the community already; lack of ongoing conflict is proof that it is working, not evidence against these best practices. Demands for proof of extant problems in this sphere are a WP:FILIBUSTER technique that waste a lot of editorial time. [When we do just impose a rule, it's largely for technical reasons, e.g. "don't use curly quotes because they interfere with searches". This is infrequent enough we don't need to blather about it in a FAQ point.]

— SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:27, 8 August 2015 (UTC)[reply]

But there is dissent and conflict, so by your reasoning that's proof that it is not working.
If the question that this is meant to answer is "Why should I do what the MoS says?" or "Why isn't the MoS sourced?" then we should either provide an actual answer or not draw attention to the question. This text doesn't do that. The bottom line is that the MoS does have a problem with whims and cliques and it should be based on sources and not on whatever the majority of us felt looked good. That is one of the MoS's key problems (if by "problem" we mean "reason why people disregard it, even when they shouldn't") and the bug should not be presented as a feature.
"Why doesn't the MoS have to follow the sourcing rules?" is not a frequently asked question.
If we want to be constructive, we're better off addressing these issues one at a time. To an extent, the FAQ already does this: "Why does the MoS require straight quotes?" "For the non-arbitrary, observable reason that curly ones can interfere with some kinds of searches." "Why does the MoS require British style even in non-British articles?" "Here is both sides of the debate on that, BTW British continually wins when challenged (so think twice before challenging)," etc. These two questions, though they address very different rules (in that one is practical and the other is arbitrary) both head off further conflict, one by providing the reasoning behind the decision and the other by acknowledging the position of opponents. "The MoS doesn't have to follow the sourcing rules ...uh ...because it doesn't" does not.

My position: Add explanations to individual frequently asked questions as needed. Do not add the proposed text unless circumstances change (either the MoS's sourcing or the frequency with which people ask about current processes). Darkfrog24 (talk) 20:41, 8 August 2015 (UTC)[reply]

Responses, in order:

You can't "prove a negative" that way. There will always be conflicts of opinion about such matters. The fewer there are, the more it is working, whatever the majority of editors are doing. That some conflict arises absolutely does not "prove" that it's not working and has to be scrapped.
Then propose better wording. But you're not getting at what the actual issue is.
But it is a FAQ. Again and again and again editors, mostly opponents of MOS existing or saying much of anything, rant tendentiously or filibuster endlessly, and only at MOS, about "sources" for this point or that. WP policies and guidelines are not tied to third-party publications, but alone out of all WP:POLICY material, people keep trying to impose this on MOS. It's WP:Disruptive editing nonsense and it needs to stop.
It's unclear to me why you think that "MOS doesn't use external sourcing because WP:POLICY is determined internally, not externally" somehow means "The MoS doesn't have to follow the sourcing rules ...uh ...because it doesn't". In fact I flatly disbelieve that you believe this; I believe you're flibustering this time, as before, because your clearly stated intent is to change MOS to be externally sourced, point by point, which is something you will never get consensus for.

— SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 04:19, 9 August 2015 (UTC)[reply]

Oppose. I'd like to see the MOS rely more heavily on external sources, and in discussions about style, appeal to authority is a strong (but not decisive) argument. Pburka (talk) 00:21, 9 August 2015 (UTC)[reply]

Why would we do that for MOS and for no other policies or guidelines? — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 04:19, 9 August 2015 (UTC)[reply]

See Wikipedia talk:Manual of Style/Archive 105#Guideline-by-guideline citation of sources (November 2008).

—Wavelength (talk) 00:30, 9 August 2015 (UTC)[reply]

Why would we do that for MOS and for no other policies or guidelines? — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 04:19, 9 August 2015 (UTC)[reply]

The MOS is a policy. WP policies do not require references, and if added, they should be removed. SMC has it right, we develop policies internally. GregJackP Boomer! 07:44, 9 August 2015 (UTC)[reply]

Well it's a guideline. Both are covered by WP:POLICY. :-) — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:35, 9 August 2015 (UTC)[reply]

SmC, I was not attempting to prove that the MoS isn't working. I was pointing out that your argument "The MoS must be working because there is no conflict" is not valid. Whether or not the MoS is working must be ascertained in some other way.

I propose that we not add text to this effect at all. It's like putting up a glowing neon arrow pointing to a reason not to follow the MoS. (My pipe-dream preference would be to source the MoS, but I don't think enough of us are on board for that.)

Can you point to someone saying, "I don't have to follow the MoS because it's not sourced" or saying "Ptui on the MoS for [reason that would be solved by adding this text]?"

No, I am indeed translating your "policy" sentence to mean "because we say so." I'll see if I can spell it out more clearly: "Why doesn't the MoS have to follow WP:V even though there are many sources for grammar and style?" "Because it's a policy and not an article." "Oh, well what rules govern policy?" "Rules that we made up." "Well then why not make up a rule that says the MoS should be sourced?" "Because we don't feel like it." And I think that the sort of person who'd ask the first question would translate that to "Because we like telling other people what to do," even though that's not always true.

Filibustering means that I'm holding the floor and blocking you by preventing anyone else from talking (because in situations that can be filibustered, only one person may speak at a time). I'm not. The only thing I'm withholding from you is my own support and approval. You are perfectly free to try to form consensus without me, and the only thing I am allowed to do about it is say in the discussion why I don't think anyone else should support this proposal either. So that's what I did. Darkfrog24 (talk) 12:56, 9 August 2015 (UTC)[reply]

SmC has twice asked, "Why would we do that [provide sources] for the MoS and for no other policies or guidelines?" One answer to that question is "Because large numbers of high-quality sources for the MoS's content exist, and this is not the case for most other guidelines. Darkfrog24 (talk) 12:59, 9 August 2015 (UTC)[reply]

See WP:INDISCRIMINATE. The fact that something exists doesn't mean it must be included. That common sense principle applies even more to WP:POLICY material than it does to articles, because the former has a tight, specific, practical purpose, and does not exist to be generally informative and interesting. And in point of fact, a large amount of what is covered by various WP:POLICY pages could be externally sourced to third-party works on collaboration, non-profit operations, sociology, organizational development and lifecycles, volunteer management, delegation and division of labor, online community, affinity groups, co-ops, etc., etc. On the other matter, see WP:FILIBUSTER. It has a specific meaning here, and you're well aware of it.

You're also mistaking my argument. I do not argue that MOS must be working because there is no conflict. I specifically said there will always be conflict and that it cannot be taken to indicate that best practices are not working, that MOS is not working, or that a proposed addition to MOS isn't needed because there's lack of proof of an immediate problem. The general decrease in the same kinds of conflict over time is a strong indicator, however, that the recognition and codification of these best practices has a marked effect in curtailing the recurrence of disputes about the same things. The evidence of this is all around us. When's the last time you saw a putsch to capitalize Bottle-nosed Dolphin or Mountain Lion? When's the last time we had a debate about whether quotations should be italicized? How long has it been since there was a flamewar about whether to include the Japanese-script form (with latinized transliteration) parenthetically after the common English-language name for a Japanese subject? Ever noticed that no one fights about whether to write "3 cm", "3cm", "3CM", "3 CM.", etc.? We have well over 1,000 individual "rules" that are applied nearly uniformly and without strife across Wikipedia because they've bubbled to the top as the consensus way to do it, and have been codified here. In the vast majority of cases, they were already being used and were having notable positive effects before being added to MOS, which simply made them more likely to be followed. There's a reason that wikiproject advice pages that are properly written to promote consensus-based best practices (not to push some specialized-style agenda) are often adopted into the MOS and naming conventions and even the content guidelines over time. And is has jack to do with item-by-item citation to external "authorities". I think I'm skipping two of your points, but it's stuff we've been over before. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 05:10, 10 August 2015 (UTC)[reply]

"What is the correct way to write/punctuate/spell X?" usually has a much more concrete answer than "What is the best way to ascertain that a source is reliable?" or "What is the best way to resolve a type-Y conflict?" The second and third questions are very open-ended and have multiple possible good answers. Cases in which English gives more than one correct answer are more the exception than the rule.

"Applied uniformly"? Have you checked?

SmC, I'm not filibustering or WP:FILIBUSTERING you. I'm just disagreeing with you. I don't think we should add your proposed text. Darkfrog24 (talk) 16:12, 11 August 2015 (UTC)[reply]

All text every added anywhere here other than by some committee process is someone's proposed text. Even if you put a lot of faith in WP:BRD, which fewer and fewer of us do

BRD has too much B in it for this page. Except for trivial changes, we should always D first. --Trovatore (talk) 21:44, 12 August 2015 (UTC)[reply]

Request for comment: Deprecation of the Template:English variant notice

An editor has asked for a discussion on the deprecation of Template:English variant notice. Wikipedia:Village pump (proposals)#RfC: Should Template:English variant notice be deprecated?.—Godsy^(TALK_CONT) 07:00, 14 August 2015 (UTC)[reply]

Forum shopping notice

Moved to Wikipedia:Administrators' noticeboard/Requests for closure § Administrative

The virtually unanimous consensus a week or two ago to deprecated the huge banner version of the ENGVAR templates (see Wikipedia talk:Manual of Style/Archive 167#Proposal to deprecate Template:English variant notice) is being forum-shopped in an "RFC" that is not actually an RFC, at WP:Village pump (proposals)#RfC: Should Template:English variant notice be deprecated? (and WP:VPPRO wouldn't even be the right venue for such a discussion anyway; it would be WP:VPPOL, since this is not a proposal). I don't know what the intent is, though I note that I announced a day or two ago that I was working on the WP:TFD for these and a categorization merger plan, and the pseudo-RFC, pseudo-proposal does not appear to have understood anything in the previous discussion, but is an odd "we need ENGVAR templates!" overreaction. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 14:37, 14 August 2015 (UTC)[reply]

RfC: piping a wikilink for the sole purpose of inserting the 's

Hi! You may be interested in Wikipedia talk:Manual of Style/Linking#Saxon genitive and piping. It is about [[George Washington|George Washington's]] administration vs. [[George Washington]]'s administration wikilinks. Thanks in advance! -- Basilicofresco (msg) 04:54, 16 August 2015 (UTC)[reply]

Centralized spot for capitalization after hyphenation

Weirdly, there was no one place this was located, but it was scattered about in MOS:CAPS and not written in generalized form. I've fixed this at WP:Manual of Style/Capital letters#After hyphenation, with shortcut MOS:HYPHENCAPS. Also added a one-liner summary at WP:Manual of Style#Hyphens. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:23, 19 August 2015 (UTC)[reply]

Notice of proposal regarding unusual prepositions in titles (re: clarification request in RM closure)

FYI

– Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Capital letters#Proposal regarding unusual prepositions in titles (re: clarification request in RM closure). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:51, 18 August 2015 (UTC)[reply]

Oppose: the proposal is in conflict with real-world usage, has no evidence to support its axioms, and is WP:CREEP. It's a solution looking for a problem based on a misunderstanding of how the English language works. Curly Turkey ¡gobble! 03:25, 21 August 2015 (UTC)[reply]
This is not a vote, it's a Pointer to relevant discussion elsewhere. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 17:31, 21 August 2015 (UTC)[reply]

43rd governor of Kentucky

This is in today's TFA (See the Main Page today, or Wikipedia:Today's featured article/August 18, 2015 anytime.) There's a question at WP:ERRORS about whether to capitalize "governor". Both copyedited text in general and wikiproject practice tend to be inconsistent on the point. WP:MOSCAP says to capitalize the office ("was King of France", which is a singular office), but of course it would be "43 kings of France" rather than "43 Kings of France", so one interesting question is whether "43rd governor of Kentucky" more closely resembles the former or the latter. Thoughts? - Dank (push to talk) 14:53, 18 August 2015 (UTC)[reply]

The consensus on what sources I've dug up in a few minutes seems to be to not capitalize "governor" unless it is used with the person's name: "Governor Smith vetoed a bill. He is the third governor to do so." AP Blue Book USA Today Utah.gov AP Political Guide (search for "capitalize the titles") Purdue Owl (search for "mayor")

However, I did find one notable exception. The U.S. Government Printing Office says that a title can be capitalized when used immediately after the person's name to "indicate preeminence in certain specialized instances," which I take to mean "John Smith, Governor of Kentucky." Darkfrog24 (talk) 17:45, 18 August 2015 (UTC)[reply]

Amazingly helpful, thanks. - Dank (push to talk) 17:52, 18 August 2015 (UTC)[reply]

Yeah, that's use with name as title. It's distinct from "when John Smith was the governor of Kentucky". Some (especially American) style guides might capitalize it there, too (i.e., when John Smith was the Governor of Kentucky), and some writers (probably zero style guides) would even do this: *when John Smith served Kentucky as its Governor. MOS would consider both of those to be overcapitalization. The only difference, however, between Kentucky Governor John Smith, and John Smith, Governor of Kentucky, is syntax. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:29, 21 August 2015 (UTC)[reply]

Capital letter is helpful here. It clarifies that this is his official title, while "governor of Kentucky" leaves open the possibility that he's the 21st guy to be in a position of governing the state, regardless of official title. Nyttend (talk) 03:46, 22 August 2015 (UTC)[reply]

It should also be capitalized when referring to the specific office: The Governor of Kentucky has powers of appointment that the governors of most states do not. DES ^(talk) 21:12, 22 August 2015 (UTC)[reply]

WT:MOSNUM: Resolving self-contradictory advice on constructions like "two hundred six"

FYI

– Pointer to relevant discussion elsewhere.

This thread needs additional input: Wikipedia talk:Manual of Style/Dates and numbers#Resolving self-contradictory advice on constructions like "two hundred six" — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 22:27, 22 August 2015 (UTC)[reply]

Linking to non-English Wikipedia pages in mid-article

Where are we covering this? I don't mean how to do it but whether/where to do it. I keep running across cases like this:

None of these strike me as appropriate in running article prose, but I can't seem to find a "rule" against it. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 19:08, 22 August 2015 (UTC)[reply]

There isn't a rule against it. WP:Wikimedia sister projects#When to link explicitly encourages interlanguage links (see also Help:Interlanguage links#Inline links). I don't see a problem with these links – they serve a useful purpose, and can be made fairly unobtrusive with the {{Ill}} template. DoctorKubla (talk) 16:07, 23 August 2015 (UTC)[reply]

For "when" to use a redlink followed by a link to an article on the topic in another Wikimedia project, see also Wikipedia:Red link#Dealing with existing red links, sixth main bullet.

I suppose {{ill|de|Krokodil (Swiss band)|Krokodil (Schweizer Band)|Krokodil}} *should* be the preferred format, it makes the blue interwiki-link go away automatically once the English Wikipedia article has been initiated. --Francis Schonken (talk) 18:02, 23 August 2015 (UTC)[reply]

I don't see a fundamental issue with the 2nd there. I would have problems in running text with the others. The Wikidata team is actually working on an extension for "automated non-articles" as in a stub non-article will be displayed to a user with a red link... --Izno (talk) 20:20, 23 August 2015 (UTC)[reply]

Block quotations have decorative quotation marks in mobile view

MOS:BLOCKQUOTE states: "Do not enclose block quotations in quotation marks (and especially avoid decorative quotation marks ...)". However, the mobile skin includes a style for the <blockquote> element that forces decorative quotemarks (and also imposes a font change for good measure). The relevant style appears to be served up by load.php. You can see the effect by comparing a page in desktop view with the same page in mobile view. (The second paragraph is a blockquote.) Can/should we do anything to address this? – Wdchk (talk) 01:18, 24 August 2015 (UTC)[reply]

These CSS effects are added by the mobile extension. We can submit a bug to Phabricator, but no guarantees. I think we might also be able to override it in MediaWiki:Mobile.css (I'm not sure how the cascading works between those two CSS files). We should do at least the former. --Izno (talk) 11:01, 24 August 2015 (UTC)[reply]

Include country when mentioning placenames?

There is a disagreement between two editors at The Boy with the Leaking Boot as to whether placenames mentioned (as locations of copies of the statue) should, or should not, include "United States" and "England". One view is if people are too ignorant to know that California is in America and Lincolnshire is in England (or are too lazy to click a link) then that's their fault. We shouldn't have to awkwardly and unnecessarily insert country names after every place. Another view is in an international encyclopedia such as this we need to give full place names with country - not everyone who reads this will recognise every US state (I sometimes forget whether "Michigan" is in Canada or USA) or British county.

I cannot find anything in WP:MOS to help: the section on Geographical items is about choice of name, historic name, etc, not level of context given for the name.

(a) If there is guidance about this somewhere, please show us where.

(b) Perhaps, if there is no such guidance, there should be?

MOS afficionadoes would be welcome to chip in to the discussion at Talk:The Boy with the Leaking Boot. Thanks. PamD 13:55, 16 August 2015 (UTC)[reply]

Having it specified would be useful. From what I've seen, the norm is similar to that of WP:OVERLINK. If the place is widely known (e.g., California or New York City) there is no need to specify its location to a wider geographical area. If the place is relatively unknown to a global audience (e.g., Iowa or Akron) or there are multiples of that location (e.g., Cleveland) then we should specify it (which for the latter would disambiguate it). EvergreenFir (talk) Please {{re}} 17:04, 16 August 2015 (UTC)[reply]

As far as places in the US are concerned, as long as the State name (California, Texas, Wisconsin, etc.) is included there is no need for "United States" be included as well. The average English speaking reader (our audience) does not need to be told that Sandusky, Ohio is in the United States... because he/she will already know that Ohio is in the United States. I would say the same assumption of a preexisting familiarity will be true for the Provinces in Canada, the States and Territories of Australia, and the Counties of the UK.

However, the assumption of a preexisting familiarity will not extend to States/Departments/Provinces/Regions of other countries. The typical English speaker probably will not be aware of the provinces of Gabon... so adding Gabon when mentioning towns in Nyanga would be helpful.

In other words, I would object to creating a one-size-fits-all "rule" for this. Take it on a case by case basis. Blueboar (talk) 12:27, 18 August 2015 (UTC)[reply]

I'm wary about making assumptions about our "typical" reader knows, particularly when writing a general encyclopedia where it is often good practice to state the obvious. According to List of countries by English-speaking population, the countries with the second, third, and fourth largest English-speaking populations are India, Pakistan, and Nigeria. My knowledge of the interior geography of those countries is spotty at best; it would be very presumptuous to assume someone there must have a detailed knowledge of mine.--Trystan (talk) 13:29, 18 August 2015 (UTC)[reply]

For those who don't know that Ohio is in the United States... well, that's what links are for. Blueboar (talk) 13:42, 18 August 2015 (UTC)[reply]

NOTE: As far as the specific article (ie The Boy with the Leaking Boot is concerned... I have attempted to resolve the issue by simply reorganizing the article a bit... I have added "by country" section headers. With section headers that mention the name of the country, there is no longer a need to add the country name every time we mention a town's name (the reader will know that the town is in the US or UK etc because the section header says so). This may not necessarily resolve the generalized question, but hopefully it will resolve the immediate dispute that raised that question. (Sometimes it helps to think "outside the box"). Blueboar (talk) 14:24, 18 August 2015 (UTC)[reply]
It agree with this: As far as places in the US are concerned, as long as the State name (California, Texas, Wisconsin, etc.) is included there is no need for "United States" be included as well. But I know that many do not. This should be settled with a site-wide, well-advertised RfC, mentioned at WP:VPPOL and WP:CENT. We keep coming back to this without resolution. It's getting perennial. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:59, 21 August 2015 (UTC)[reply]
- Seems to me that it depends. Big cities will be easily recognized, but some cities have the same name as well known cities. There is a London, Ontario, Canada, where London would not be unambiguous, and many might not know the provinces of Canada. A smaller city might not be enough to make the state name easily recognized. Make assumptions that include less than typical readers, supply enough links for the truly atypical reader. Gah4 (talk) 23:58, 24 August 2015 (UTC)[reply]