{{aan} I will endevour to respond as quickly as possible.
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)
<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)
<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]]}}
is this a policy on wikipedia — Preceding unsigned comment added by A8v ( talk • contribs)
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)
Proposal: Include the following in the short list of things that it is permissible to boldface:
*
at the beginning of the list entry and the rest of the entry's content, and having the concise characteristics of a higher-level, own-line heading, rather than of discursive text.[Proposal was WP:REFACTORed to top of section, because the nom's draft version and later-accepted version are both buried in a lot of oddly-formatted material. I helped draft the final version, so consider me co-nominator, but I disclaim any connection to the off-topic material below by the original nominator. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 02:29, 26 July 2015 (UTC)
Wikipedia’s “Manual of Style/Text formatting” currently does not explicitly permit the boldfacing of inline, or row, headings. Under Boldface, at /info/en/?search=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)
"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)
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)
MacGyver: "I don't use guns."
2015: Won the [insert a bunch of award stuff here]
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 ...
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)
"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)
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)
'
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)
RogerKni ( talk) 13:27, 30 July 2015 (UTC)
* '''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)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)
— sroc 💬 06:57, 1 August 2015 (UTC)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.
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)
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)
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)
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)
{{
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)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.
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)
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)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)
{{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)
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)
They accent that 'this is a quote', and usually are used for important quotes.
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)
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 |
rampantly abused", or that pull quotes lack "
legitimate uses" in WP articles; these points are not yet established. And I have a vague memory, on once encountering such "gigantic quotes", of finding that instance not just interesting, but even amusing, And I don't know why WP articles should not occasionally be amusing. So I would be reluctant to universally and arbitrarily prohibit them. (I agree with Trovatore: "
far too much is decided centrally".)
{{
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)“ | An excellent product | ” |
“ | a significant increase in deaths | ” |
. The only valid use I can think of is to highlight a famous quotation, and this can be done with other means, such as boxes, that are less attractive to those who misuse it to evade WP:NPOV. DGG ( talk ) 04:47, 2 August 2015 (UTC)
{{
Quote box}}
either. Even if we wanted to keep quote box for some circumstances, making it look better is just a matter of CSS tweaking, as was already discussed above. If you don't like the way it looks,
WP:JUSTFIXIT. 2) So what? We routinely deprecate and delete redundant templates, which we both agree is basically what we have here. That is mostly what
WP:TFD exists for. But dealing with a particular template is not the point of this proposal. Stopping the PoV-pushing and visually obnoxious abuse of giant quotation marks in mainspace is half of it, and stopping the PoV pushing abuse of news-style pull quotes is the other, severable goal. 3) Show us an example, and I'm sure anyone here can describe why it's a POV problem or otherwise unencyclopedic. Ironically, another opponent of this proposal actually describes precisely what the problems with pull quotes are: "they ... are usually interesting to run across. They ... usually are used for important quotes". I.e., the entire purpose of them is to pointedly manipulate and lead reader attention, to something one PoV is pushing as "important". —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
00:59, 3 August 2015 (UTC)
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)
<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){{
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){{
Pull quote}}
to markup a block quotation not a
pull quote. 2) Misuse of {{
Pull quote}}
to markup some tiny quotation that is neither a pull quote nor a block quote, but something one editor wants to browbeat readers with in a POV-pushing manner. 3) Occasional use as an "emergency" measure to get around the CSS bug documented above. In a substantial number of cases it's clearly just totally random, because the same article uses two or even three block quotation styles in the same page, with no rhyme or reasons (obviously I've been cleaning these up as I go along). I have yet to find a single actual pull quote. Even if there are some, how much do you want to bet they raise a PoV problem in the context in which they're used? Assuming there might be some that don't, how many do you think really need to be formatted that way in order to help readers? Can you give even one example? I'm not making an ILIKEIT argument. The argument is based on the plain wording of MOS and the template's own documentation, and days and days of actual research into how this template and style are being (mis)used. That's three reality-based rationales. And you have brought "I don't see ...". Technically, I suppose that's
WP:IDONTKNOWIT not ILIKEIT. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
07:39, 5 August 2015 (UTC){{block-quote}}
, and be able to have faith that it will render in an attractive and understandable manner across desktop, tablet, and text-to-speech. This would then redirect to or encapsulate the desired underlying template, like {{
Quote}}
or {{
Quotation}}
. Occasionally, I might find a need to tweak the layout, which is where a presentation-specific template might have to be used directly. In a perfect world, there would be a small set of recommended templates that would implement MOS and clearly indicate their intent.
Pelagic (
talk)
01:18, 9 August 2015 (UTC)''italic''
mark-up to a whole block quote. Or perhaps most editors don't understand what a true pull quote is. Then they should be informed by having their markup corrected to {{
blockquote}}
. Either way, you find something like {{pull quote|This is really a block quote}}
, which is misleading mark-up and ideally should be fixed where it occurs.
Pelagic (
talk)
01:18, 9 August 2015 (UTC){{Quote box|{{Pull quote|{{Big|{{Strong|Do we like this?}}
}}
}}
}}
Pelagic (
talk)
01:18, 9 August 2015 (UTC){{quote}}
not {{cquote}}
for block quotations, and it's being ignored. Proper pull quotes aren't being used much in article space, but if it would help to make it explicit in MOS, then do add the guidance that they are inappropriate.
Pelagic (
talk)
01:59, 9 August 2015 (UTC){{cquote}}
that's the problem, then can we start by adding the context-switch just to that one template? Or change the redirect as was supported in 2013?
Pelagic (
talk)
01:59, 9 August 2015 (UTC){{
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)
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)
[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.]
Dirtlawyer1 ( talk) 05:40, 10 August 2015 (UTC)
Updated: Dirtlawyer1 ( talk) 18:19, 11 August 2015 (UTC)
Dirtlawyer1 ( talk) 18:19, 11 August 2015 (UTC)
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)
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.
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.
It's actually hard to find tech news using "U.S."
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)
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)
Will add more as I go through the bookshelf and the documents drive. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:14, 12 August 2015 (UTC)
Will add more as I go through the bookshelf and the documents drive. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:14, 12 August 2015 (UTC)
Off-topic. This has nothing to do with improving MOS. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 13:19, 12 August 2015 (UTC) |
---|
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)
|
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)
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)
An editor has asked for a discussion on the deprecation of Template:English variant notice. Wikipedia:Village pump (proposals)#RfC: Should Template:English variant notice be deprecated?.— Godsy( TALK CONT) 07:00, 14 August 2015 (UTC)
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)
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)
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)
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)
Pointer to relevant discussion elsewhere.— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:31, 21 August 2015 (UTC)
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)
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)
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)
{{
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)
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)
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. Pam D 13:55, 16 August 2015 (UTC)
As far as places in the US are concerned, as long as the State name (California, Texas, Wisconsin, etc.) is included there is no need for "United States" be included as well.But I know that many do not. This should be settled with a site-wide, well-advertised RfC, mentioned at WP:VPPOL and WP:CENT. We keep coming back to this without resolution. It's getting perennial. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:59, 21 August 2015 (UTC)
{{aan} I will endevour to respond as quickly as possible.
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)
<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)
<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]]}}
is this a policy on wikipedia — Preceding unsigned comment added by A8v ( talk • contribs)
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)
Proposal: Include the following in the short list of things that it is permissible to boldface:
*
at the beginning of the list entry and the rest of the entry's content, and having the concise characteristics of a higher-level, own-line heading, rather than of discursive text.[Proposal was WP:REFACTORed to top of section, because the nom's draft version and later-accepted version are both buried in a lot of oddly-formatted material. I helped draft the final version, so consider me co-nominator, but I disclaim any connection to the off-topic material below by the original nominator. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 02:29, 26 July 2015 (UTC)
Wikipedia’s “Manual of Style/Text formatting” currently does not explicitly permit the boldfacing of inline, or row, headings. Under Boldface, at /info/en/?search=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)
"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)
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)
MacGyver: "I don't use guns."
2015: Won the [insert a bunch of award stuff here]
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 ...
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)
"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)
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)
'
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)
RogerKni ( talk) 13:27, 30 July 2015 (UTC)
* '''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)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)
— sroc 💬 06:57, 1 August 2015 (UTC)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.
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)
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)
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)
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)
{{
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)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.
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)
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)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)
{{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)
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)
They accent that 'this is a quote', and usually are used for important quotes.
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)
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 |
rampantly abused", or that pull quotes lack "
legitimate uses" in WP articles; these points are not yet established. And I have a vague memory, on once encountering such "gigantic quotes", of finding that instance not just interesting, but even amusing, And I don't know why WP articles should not occasionally be amusing. So I would be reluctant to universally and arbitrarily prohibit them. (I agree with Trovatore: "
far too much is decided centrally".)
{{
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)“ | An excellent product | ” |
“ | a significant increase in deaths | ” |
. The only valid use I can think of is to highlight a famous quotation, and this can be done with other means, such as boxes, that are less attractive to those who misuse it to evade WP:NPOV. DGG ( talk ) 04:47, 2 August 2015 (UTC)
{{
Quote box}}
either. Even if we wanted to keep quote box for some circumstances, making it look better is just a matter of CSS tweaking, as was already discussed above. If you don't like the way it looks,
WP:JUSTFIXIT. 2) So what? We routinely deprecate and delete redundant templates, which we both agree is basically what we have here. That is mostly what
WP:TFD exists for. But dealing with a particular template is not the point of this proposal. Stopping the PoV-pushing and visually obnoxious abuse of giant quotation marks in mainspace is half of it, and stopping the PoV pushing abuse of news-style pull quotes is the other, severable goal. 3) Show us an example, and I'm sure anyone here can describe why it's a POV problem or otherwise unencyclopedic. Ironically, another opponent of this proposal actually describes precisely what the problems with pull quotes are: "they ... are usually interesting to run across. They ... usually are used for important quotes". I.e., the entire purpose of them is to pointedly manipulate and lead reader attention, to something one PoV is pushing as "important". —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
00:59, 3 August 2015 (UTC)
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)
<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){{
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){{
Pull quote}}
to markup a block quotation not a
pull quote. 2) Misuse of {{
Pull quote}}
to markup some tiny quotation that is neither a pull quote nor a block quote, but something one editor wants to browbeat readers with in a POV-pushing manner. 3) Occasional use as an "emergency" measure to get around the CSS bug documented above. In a substantial number of cases it's clearly just totally random, because the same article uses two or even three block quotation styles in the same page, with no rhyme or reasons (obviously I've been cleaning these up as I go along). I have yet to find a single actual pull quote. Even if there are some, how much do you want to bet they raise a PoV problem in the context in which they're used? Assuming there might be some that don't, how many do you think really need to be formatted that way in order to help readers? Can you give even one example? I'm not making an ILIKEIT argument. The argument is based on the plain wording of MOS and the template's own documentation, and days and days of actual research into how this template and style are being (mis)used. That's three reality-based rationales. And you have brought "I don't see ...". Technically, I suppose that's
WP:IDONTKNOWIT not ILIKEIT. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
07:39, 5 August 2015 (UTC){{block-quote}}
, and be able to have faith that it will render in an attractive and understandable manner across desktop, tablet, and text-to-speech. This would then redirect to or encapsulate the desired underlying template, like {{
Quote}}
or {{
Quotation}}
. Occasionally, I might find a need to tweak the layout, which is where a presentation-specific template might have to be used directly. In a perfect world, there would be a small set of recommended templates that would implement MOS and clearly indicate their intent.
Pelagic (
talk)
01:18, 9 August 2015 (UTC)''italic''
mark-up to a whole block quote. Or perhaps most editors don't understand what a true pull quote is. Then they should be informed by having their markup corrected to {{
blockquote}}
. Either way, you find something like {{pull quote|This is really a block quote}}
, which is misleading mark-up and ideally should be fixed where it occurs.
Pelagic (
talk)
01:18, 9 August 2015 (UTC){{Quote box|{{Pull quote|{{Big|{{Strong|Do we like this?}}
}}
}}
}}
Pelagic (
talk)
01:18, 9 August 2015 (UTC){{quote}}
not {{cquote}}
for block quotations, and it's being ignored. Proper pull quotes aren't being used much in article space, but if it would help to make it explicit in MOS, then do add the guidance that they are inappropriate.
Pelagic (
talk)
01:59, 9 August 2015 (UTC){{cquote}}
that's the problem, then can we start by adding the context-switch just to that one template? Or change the redirect as was supported in 2013?
Pelagic (
talk)
01:59, 9 August 2015 (UTC){{
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)
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)
[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.]
Dirtlawyer1 ( talk) 05:40, 10 August 2015 (UTC)
Updated: Dirtlawyer1 ( talk) 18:19, 11 August 2015 (UTC)
Dirtlawyer1 ( talk) 18:19, 11 August 2015 (UTC)
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)
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.
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.
It's actually hard to find tech news using "U.S."
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)
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)
Will add more as I go through the bookshelf and the documents drive. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:14, 12 August 2015 (UTC)
Will add more as I go through the bookshelf and the documents drive. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:14, 12 August 2015 (UTC)
Off-topic. This has nothing to do with improving MOS. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 13:19, 12 August 2015 (UTC) |
---|
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)
|
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)
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)
An editor has asked for a discussion on the deprecation of Template:English variant notice. Wikipedia:Village pump (proposals)#RfC: Should Template:English variant notice be deprecated?.— Godsy( TALK CONT) 07:00, 14 August 2015 (UTC)
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)
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)
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)
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)
Pointer to relevant discussion elsewhere.— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:31, 21 August 2015 (UTC)
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)
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)
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)
{{
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)
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)
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. Pam D 13:55, 16 August 2015 (UTC)
As far as places in the US are concerned, as long as the State name (California, Texas, Wisconsin, etc.) is included there is no need for "United States" be included as well.But I know that many do not. This should be settled with a site-wide, well-advertised RfC, mentioned at WP:VPPOL and WP:CENT. We keep coming back to this without resolution. It's getting perennial. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:59, 21 August 2015 (UTC)