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

Usage of & versus a break[edit]

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:

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[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 <br /> not <br> (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 ,<br />, 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[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[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 <br />, 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[reply]
Thanks for confirming, will implement as you suggested. —Indian:BIO [ ChitChat ] 07:09, 26 July 2015 (UTC)Reply[reply]

is this a policy on wikipedia[edit]

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

MOS page no longer an MOS page[edit]

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[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[reply]
Not the first time this has been tried, e.g. here among various other cases.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  01:18, 3 August 2015 (UTC)Reply[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[reply]

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

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

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

Wikipedia’s “Manual of Style/Text formatting” currently does not explicitly permit the boldfacing of inline, or row, headings. Under Boldface, at https://en.wikipedia.org/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:

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:

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

Comments

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

is really that much better than

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[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[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[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[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:

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

RogerKni (talk) 13:27, 30 July 2015 (UTC)Reply[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[reply]

Advice about using columns in articles[edit]

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[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[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[reply]
And presumably other than in Notes and References sections – right? ~ J. Johnson (JJ) (talk) 20:56, 31 July 2015 (UTC)Reply[reply]
See also Australian hip hop § Notable artists, which uses ((divcol)). —sroc 💬 06:50, 1 August 2015 (UTC)Reply[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[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[reply]
Is there some recurrent problem that MOS needs to address?  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:04, 1 August 2015 (UTC)Reply[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[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[reply]

Capitalization and capitalisation[edit]

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

to vs. that[edit]

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[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[reply]
used to compute sounds best to me. Darkfrog24 (talk) 21:14, 4 August 2015 (UTC)Reply[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[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[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[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[reply]
I'd buy that for a dollar.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:29, 6 August 2015 (UTC)Reply[reply]

American English categories[edit]

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

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

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

 — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  00:21, 30 July 2015 (UTC)Reply[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[reply]
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[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[reply]

  1. 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.
  2. 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%.)
  3. 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[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[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[reply]

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[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[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=MC2" 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[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[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[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[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[reply]
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[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[reply]
Thank you. I appreciate the effort. ~ J. Johnson (JJ) (talk) 20:55, 3 August 2015 (UTC)Reply[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[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).
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[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[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[reply]

. 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[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[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[reply]
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[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[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[reply]
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[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[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[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[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[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[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[reply]

MOS's own overuse of "U.S."[edit]

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

Strongly disagree about what? There are multiple things here to agree or disagree with:
  1. MOS should follow its own advice.
  2. MOS always using "U.S." conflicts with its own advice to not do this in pages that also use "UK", "UN", etc.
  3. We should sometimes check that MOS's claims about use of "U.S." are true, not blindly assume they'll be true forever.
  4. 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[reply]
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[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[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[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:
  1. 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.
  2. 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[reply]

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

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

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

American journalism sources

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

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

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

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

Dirtlawyer1 (talk) 18:19, 11 August 2015 (UTC)Reply[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[reply]

ABC and its affiliates mostly seem to avoid the "U.S." usage
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

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

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

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

Any more than, say, 10 years old are useless for this analysis

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[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[reply]
Style guides

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

Dictionaries

Will add more as I go through the bookshelf and the documents drive.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:14, 12 August 2015 (UTC)Reply[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[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[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[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[reply]

FAQ addition on argument to authority[edit]

Previous WP:BRD discussion on this stalled at Wikipedia talk:Manual of Style/Archive 167#Sourcing and proof

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:

 — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:27, 8 August 2015 (UTC)Reply[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[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[reply]
Why would we do that for MOS and for no other policies or guidelines?  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:19, 9 August 2015 (UTC)Reply[reply]
—Wavelength (talk) 00:30, 9 August 2015 (UTC)Reply[reply]
Why would we do that for MOS and for no other policies or guidelines?  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:19, 9 August 2015 (UTC)Reply[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[reply]
Well it's a guideline. Both are covered by WP:POLICY. :-)  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:35, 9 August 2015 (UTC)Reply[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[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[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[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[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[reply]

Request for comment: Deprecation of the Template:English variant notice[edit]

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(TALKCONT) 07:00, 14 August 2015 (UTC)Reply[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[reply]

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

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

Centralized spot for capitalization after hyphenation[edit]

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

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

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

43rd governor of Kentucky[edit]

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[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[reply]
Amazingly helpful, thanks. - Dank (push to talk) 17:52, 18 August 2015 (UTC)Reply[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[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[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[reply]

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

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

Linking to non-English Wikipedia pages in mid-article[edit]

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

Block quotations have decorative quotation marks in mobile view[edit]

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

Include country when mentioning placenames?[edit]

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[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[reply]
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[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[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[reply]
More