Wikipedia talk:Manual of Style

Q: Do we use hyphen or hyphen-minus in double-barrelled surnames?

It appears that biographies on WP are routinely ignoring the guidance in MOS:HYPHEN and instead are using the hyphen-minus. Is there consensus to do so, or did it just slide under the radar? LeadSongDog come howl! 21:29, 26 March 2018 (UTC)

Do you have examples? I can't actually make my Mac generate a hyphen-minus easily, even though I have an external keyboard with a numpad. Both the key to the right of 0 (zero) and the numpad minus sign generate a character that matches \u002D. I think, given hyphen and hyphen-minus are encoded the same way in ASCII per Hyphen § Hyphen-minus, they are effectively the same. —Joeyconnick (talk) 22:34, 26 March 2018 (UTC)

Yes, \u002D is the hyphen-minus (also known in ASCII as hyphen, originally). On any keyboard, the minus or hyphen key gives you this character, whether you call it hyphen or hyphen-minus; UNICODE also has another character that's specifically for hyphen, but I'm not aware of any place that's in use by anyone for anything. Dicklyon (talk) 03:38, 27 March 2018 (UTC)

Its most likely - no one reads MOS-HYPHEN or is even aware it exists rather than 'ignoring' it. As a practical issue, do whatever one comes naturally to you, an automated gnome will come by and correct it if its "wrong". It gives them something to do. In short, dont worry about it. Only in death does duty end (talk) 00:05, 27 March 2018 (UTC)

Most editors don't pay attention to the MOS, but many of us do. Our gnoming is not generally easy to automate. Dicklyon (talk) 03:43, 27 March 2018 (UTC)

All of the examples in MOS-HYPHEN actually use minus-hyphens instead of real hyphens. I think it's safe to say that we don't actually use unicode hyphens on Wikipedia. Kendall-K1 (talk) 00:10, 27 March 2018 (UTC)

The hyphen-minus is the standard glyph for a hyphen (as it says at Hyphen-minus, "The hyphen-minus (-) is a character used in digital documents and computing to represent a hyphen"). Hyphen-minus is the name that Unicode made up for this code point and glyph, to recognize that in addition to being used for hyphen it's also commonly used (in code, not in typography) as minus sign. I'm pretty sure that MOS:HYPHEN never meant to suggest otherwise, but perhaps it needs an explicit clarification is someone is questioning that. Dicklyon (talk) 00:14, 27 March 2018 (UTC)

Maybe a single sentence at the end of MOS:HYPHEN? I'm tempted to actually discourage use of unicode hyphen, because using it could complicate searches. But I don't want to start a huge argument over this. Kendall-K1 (talk) 13:25, 27 March 2018 (UTC)

I agree with Kendall-K1 as a practical matter. On most computers, it is easier to type a "hyphen minus" than it is to type a Unicode hyphen. If you look at articles (including, fittingly enough, Hyphen-minus), the title is encoded with a hyphen minus, not a Unicode hyphens. The situation is comparable to apostrophes and quotation marks where the ASCII ' is used instead of the fancier curved Unicode apostrophes. Generally, if we're going to adopt standards, we should maximize accessibility, not prescribe Unicode specifications to our encoding. E to the Pi times i (talk | contribs) 14:49, 27 March 2018 (UTC)

MOS:HYPHEN is about hyphenation in general; only the first line is about surnames. Why pick out surnames only? Following the OP's logic, almost every hyphen in Wikipedia should be a Unicode hyphen, so every time some user types a "hyphen-minus", a bot should trot round and change it do a Unicode hyphen! Really?
As Dickylon said, it's obvious that that whoever wrote MOS:HYPHEN had in mind the character that's on everyone's keyboard, which almost all humans call a hyphen. As the article Hyphen-minus says, "The hyphen-minus is a character used in digital documents and computing to represent a hyphen or a minus sign ... However, in proper typesetting and graphic design, there are distinct characters for hyphens ..." Wikipedia is a digital document, not a properly-typeset or graphic-designed document.
Do we really need a formal proposal to add a line to MOS:HYPHEN to make this clear? — Stanning (talk) 17:55, 27 March 2018 (UTC)

We shouldn't have to, no. But; this is The MoS, after all  :) —SerialNumber54129 ^{paranoia /cheap shit room} 17:57, 27 March 2018 (UTC)

So try this. Dicklyon (talk) 19:11, 27 March 2018 (UTC)

Thank you all for the feedback. To clarify, I have no horse in this race, I just wished to address an apparent contradiction in the guidance. The text linked to hyphen yet the Tim Berners-Lee example used a hyphen-minus. So, I'm not at all suggesting widespread disruption, just a cleanup of the guidance text. If others are content that a wording change will do that job, then so am I. Cheers. LeadSongDog come howl! 21:22, 27 March 2018 (UTC)

Blockquote length

Format a long quote (more than about 40 words or a few hundred characters, or consisting of more than one paragraph, regardless of length) as a block quotation

Is it just me, or is 40 words a little short? I was reverted for removing blockquote formatting from a quote over 63 words. At least on my monitor (which is not particularly large), the quote I edited looks rather sparse displayed as a blockquote, and yet it's more than 50% longer than the minimum wordcount. I'd probably suggest something closer to 80 words, maybe more. Popcornduff (talk) 07:32, 29 March 2018 (UTC)

Disagree, I think 40 words is a reasonable transition point. Nikkimaria (talk) 11:57, 29 March 2018 (UTC)

I am going to concur with Nikkimaria. In my opinion, as long as the quote is over 1 line on a reasonable sized monitor, it is acceptable for use in blockquote (though not required). E to the Pi times i (talk | contribs) 12:13, 29 March 2018 (UTC)

Not everyone uses the same skin or monitor size. --Izno (talk) 13:27, 29 March 2018 (UTC)

I used the adjective "reasonable" because not everyone has the same display. There is a range of variation, but at a certain point the display size is outside the norm (e.g. a phone screen or a large monitor). Lines are the main way the average reader evaluates the display when reading through an article. Because line count is not an objective standard for the wiki, word count is the avenue of prescription. If other editors disagree with my standard of 1 line, it's fine. I do think that fundamentally, line count is the standard pertaining to the reader, but if we don't prescribe using that measurement it's admittedly a less useful course of discussion. E to the Pi times i (talk | contribs) 14:03, 29 March 2018 (UTC)

Mobile is the new norm: 5 of every 9 (55%) page views in the main space are from mobile. And there is variation across skins, which was the other point I was trying to stress. --Izno (talk) 14:43, 29 March 2018 (UTC)

The APA recommends 40 words; the MLA recommends "four lines of prose or three lines of verse"; CMOS 100 or more--"six-to-eight lines of text in line a typical manuscript", as well as others in the 5+ lines realm. The 40 words that the APA suggests are a bit shorter than the MLA's recommendation (about 2.5 lines pre-indentation with some lorem), and clearly the others are closer to the realm of 80 words or so. I would probably support inlining only those quotes longer than 65-80 words, if we want a direct count. --Izno (talk) 13:27, 29 March 2018 (UTC)

• How 'bout saying 40-60 and leaving it at that. There's more to such decisions than a word count. EEng 16:08, 29 March 2018 (UTC)

JOBTITLES

Have I misinterpreted MOS:JOBTITLES? Revert by @SounderBruce: says I did, but I don't think so. Dicklyon (talk) 00:35, 31 March 2018 (UTC)

I might add that the entire section doesn't match common use in American English by media outlets and doesn't make much sense in general. "County executive" (with the lowercase) is fine, but "Snohomish County executive" is not because it breaks the consistency here. SounderBruce 00:37, 31 March 2018 (UTC)

I would say it should be "King County Executive" as that is a formal title of the office, but the others should be lowercase (e.g. the powers of the county executive were) as usage is as common nouns. MB 00:48, 31 March 2018 (UTC)

It was my intent to leave it capped where suggested by MOS:JOBTITLES and not otherwise. Were there instances that you think I got wrong? It looks to me like this also follows closely what most sources do; are there instances where someone thinks I'm wrong about that? Dicklyon (talk) 00:59, 31 March 2018 (UTC)

In the diff you provided above, you changed the first quoted "King County Executive" to "King County executive". And in the search you just provided, it looks like most sources (at least on the first page) have it all caps. I agree with all the other changes you made to make the generic county executive or executive lower case. MB 01:18, 31 March 2018 (UTC)

You failed to mention the "The" and correlate that to the guideline. And you failed to note that the page hits where it is capped are wikipedia pages. Most others use lowercase, don't they? There is perhaps 1 in 10 that does it differently from what our guideline suggests. Or do you see more? Dicklyon (talk) 01:29, 31 March 2018 (UTC)

To go through one by one, (discounting WP and duplicate sources) I see once occurrence from kingcounty.gov where it refers to King County Executive, and six other sources using the King County executive/Executive. One third of those with "The" have Executive capitalized (2 out of 6). Of course the count might change if more pages are investigated. Regardless, I agree with all your changes except that one that I think is a formal title. MB 01:54, 31 March 2018 (UTC)

Which one change are you referring to that you think is wrong? The lead sentence? I did that because it's what MOS:JOBTITLES says to do, and it's what most sources do (two-thirds by your estimate?). Dicklyon (talk) 02:58, 31 March 2018 (UTC)

Yes, the one in the lead. That looks to me like a formal title, as in "Richard Nixon was President of the United States" from the examples. To make it match the MOS, the "the" could be removed there. If you look at President of the United States, you will see President is also capitalized even though it is preceded by an article. I think we should follow the precedent in 1/3 of the sources and the POTUS article. MB 03:33, 31 March 2018 (UTC)

Got it. I'm not keen on letting an article precedent override the MOS, but for now I'll do it that way and see if there's any other objection. Dicklyon (talk) 04:03, 31 March 2018 (UTC)

My reading is the same as MB's. "King County Executive" is a formal title and should be capitalised, others lowercase per MB. Only in death does duty end (talk) 01:36, 31 March 2018 (UTC)

So no comment relative to what MOS:JOBTITLES says, or what sources do differently, or what specific changes that I made you would object to? I'm looking for specifics of what I did wrong, relative either to guidelines or sources, not just generalizations. Dicklyon (talk) 02:56, 31 March 2018 (UTC)

Well, according to the edit summary that accompanied the revert, what you did “wrong” was to inappropriately decapitalize a specific job title (treating it as if it were a generic one). Blueboar (talk) 11:20, 31 March 2018 (UTC)

But have you read MOS:JOBTITLES? It lays out very specifically the conditions under which we cap such things. Can you comment with respect to that, which is what I requested at the outset? Dicklyon (talk) 16:50, 31 March 2018 (UTC)

MOS:JOBTITLES says in part "Offices, titles, and positions...are capitalized only in the following cases...[w]hen a formal title for a specific entity (or conventional translation thereof) is addressed as a title or position in and of itself." An example given in the guideline is "Richard Nixon was President of the United States."

I think "is addressed as" is very poor wording and hard to understand. My best guess is that "Richard Nixon was President of the United States" applies the title "President of the United States" to Richard Nixon, and because the title is applied to a specific entity, Richard Nixon, "President" is a proper noun and capitalized. When the phrase "president of the United States" is not being applied to a particular person, "president" is a common noun. The part about "president" being common if it is preceded by an article seems dubious to me, especially if the article is "the". Jc3s5h (talk) 17:31, 31 March 2018 (UTC)

OK, so you're saying that maybe the problem is what the guideline says, not that I misinterpreted it? Dicklyon (talk) 23:35, 31 March 2018 (UTC)

What I wrote is my attempt to interpret the guideline, but the guideline is hard to interpret. So I agree with your original article edit that lead to this discussion. Jc3s5h (talk) 23:56, 31 March 2018 (UTC)

Boilerplate leads in lists

The articles in List of LGBT-related films by year all have leads in the form "This is a list of lesbian, gay, bisexual or transgender-related films released in <year or decade>. It contains theatrically released films that deal with important gay, lesbian, bisexual, or transgender characters or issues and may have same-sex romance or relationships as a plot device." The use of a self-referencing lead goes counter to some MOS recommendations (included below). My question is: is there a better lead which avoids self-reference in this set of lists?

Reading the through the guidelines, the general theme for the MOS entries is avoid self-reference and redundancy, while MOS:LEADOFALIST and WP:Stand-alone lists also mention inclusion criteria as something important to state in the lead. These two guidelines seem to be in conflict sometimes (possibly in this case, with the criteria in the second sentence), and we may want to revise the main MoS/Lead entry to mention that the lead should also include inclusion-criteria for lists.

Guideline quotes for reference

Wikipedia:Manual of Style/Lead section § lead sentence says: if the page is a list, do not introduce the list as "This is a list of X" or "This list of Xs...". A clearer and more informative introduction to the list is better than verbatim repetition of the title. A good example of this is the List of Benet Academy alumni. (See also Format of the first sentence below). Wikipedia:Manual of Style/Lists § Lead section or paragraph says: The contents of an article that is a stand-alone list should be clear. If the title does not make clear what the list includes, then the list's lead section should do so. Don't leave readers confused about the list's inclusion criteria or have editors guessing as to what may be added to the list. [...] Lead sections and paragraphs should also follow the Self-references to avoid guideline. And Wikipedia:Stand-alone lists § Lead says: A stand-alone list should begin with a lead section that summarizes its content, provides any necessary background information, gives encyclopedic context, links to other relevant articles, and makes direct statements about the criteria by which members of the list were selected, unless inclusion criteria are unambiguously clear from the article title. This introductory material is especially important for lists that feature little or no other non-list prose in their article body. Even when the selection criteria might seem obvious to some, an explicit standard is often helpful to both readers, to understand the scope, and other editors, to reduce the tendency to include trivial or off-topic entries.

Some context for these questions: I recently created a template that produces the style of leads, but the phrasing appears to conflict with MoS. (It is currently nominated for deletion for conflicting with WP:Templates, but that's not the issue I want to address here.) (This comment was refactored.) E to the Pi times i (talk | contribs) 16:58, 6 April 2018 (UTC)

Note: I have linked to this discussions at WikiProject:Lists, since they may have useful feedback. E to the Pi times i (talk | contribs) 17:04, 6 April 2018 (UTC)

"late" and "former"

I keep seeing this popping up in articles, for example Ronald Reagan being referred to as "the late former President of the United States". Encyclopedias know no time, they don't use informal colloquialisms such as "late" to refer to dead people and dead past office holders would not be referred to as "former" in formal English (i.e. "Gerald Ford, the 38th president of the United States", not "Gerald Ford, the former 38th president of the United States") Paul Benjamin Austin (talk) 07:42, 6 April 2018 (UTC)

You are correct. There is even a guideline on this but my brain is in overload at the moment and I cannot, for the life of me, remember the shortcut. --AussieLegend (✉) 09:09, 6 April 2018 (UTC)

I would be interested to see the guideline, although I routinely adjust such wording anyway. A classic issue seems to be saying that "X was born to the late Y", which is almost always untrue even though it is possible for a parent to die prior to the child being born. I am beginning to see a lot of unnecessary uses of would also, eg: "he would become High Commissioner before leaving the diplomatic corps for academia". The writer means "he was High Commissioner ..." etc - Sitush (talk) 09:17, 6 April 2018 (UTC)

Or "was opened by the late", "was voiced by the late" etc. I really don't think the zombie apocalypse has started yet so dead people simply don't do these things. I wish I could find that guideline. --AussieLegend (✉) 09:27, 6 April 2018 (UTC)

For my response, see your cross-post at Wikipedia talk:Manual of Style/Biographies#"late" and "former". Not a good idea to split discussion. ―Mandruss ☎ 09:29, 6 April 2018 (UTC)

Not exactly the same thing, but I spend a lot of time trimming redundant time indicators. For example: "Initially released in Japan in 1997, the game was later ported to the PlayStation in 1999." When it's obvious which order events happened in - especially because we give dates - words like "initially", "first", "later", "subsequently", "previously", "earlier" etc are pointless. Popcornduff (talk) 11:33, 6 April 2018 (UTC)

"Sandwiching" text between an infobox and image

We have the following guideline: "Avoid sandwiching text... between an image and an infobox or similar." But can anyone explain to me why we need it? I can understand why it looks bad to have text between two images, but the infobox is often so long that it is a waste of space not being able to place images next to it. Also, this "rule" is often ignored, with good results. FunkMonk (talk) 06:43, 9 April 2018 (UTC)

In my experience it's often ignored with very bad results. The problem arises when looking at the 'desktop' version of Wikipedia, rather than the mobile version, on small screens, such as a tablet. The space for text is then very narrow, and it doesn't matter what is sandwiching text, you can end up with a column a few words wide. Since mobile devices are used more often now than monitors, and not everyone is happy with the mobile version (which doesn't display all the information), it's even more important to avoid sandwiching text.

The solution with short articles and long taxoboxes is to place images sufficiently important to be included centrally, using a packed mode gallery or a multiple image. Peter coxhead (talk) 06:54, 9 April 2018 (UTC)

Doesn't that go against WP:galleries, though? If the results are only bad on extremely small screens, is it really a problem that should affect all other screen sizes? The problem is circumvented in the Wikipedia app in any case, where an image is centred on the screen with only text above and under. Seems to be the same case when you look at Wikipedia on a smartphone without the app. Any images are automatically shown below the infobox. FunkMonk (talk) 08:06, 9 April 2018 (UTC)

WP:GALLERIES doesn't say that relevant images can't be collected together in a short article.

Are you looking at the mobile site or the desktop site? (See Wikipedia:Enable mobile version.) Compare APG IV system, for example, when viewed in the desktop and mobile versions. The mobile version shows nothing in the section "Short version". Compare any taxon article with a taxonbar (e.g. Ponerorchis cucullata). The taxonbar isn't shown on the mobile version. So to get the full content you often have to view an article in the desktop version, regardless of the device on which you are viewing it. A smartphone may have so narrow a screen that there's no room for text between sandwiched images/infoboxes, whereas a tablet screen may have enough room to show a narrow text column, and I can confirm that it definitely produces some poor presentations.

I agree that if styling were properly adjusted for screen size in all the different ways of displaying Wikipedia – desktop site, mobile site, app, whatever – then sandwiching would not be a problem, and we should probably be pressing the tech people to fix this. (Another problem, as noted above, is what is left out of some of these viewing methods.) Peter coxhead (talk) 09:14, 9 April 2018 (UTC)

I'll have a look at a tablet later today. Don't all mobile phones automatically switch to mobile mode? FunkMonk (talk) 10:43, 9 April 2018 (UTC)

Ok, I am looking at an article in desktop mode now, and though it admittely has very little room for the text between the infobox and the first image, who even uses desktop mode, and why? Aren't we unnecessarily adapting to an outdated mode of viewing Wikipedia on such devices? FunkMonk (talk) 10:51, 9 April 2018 (UTC)

I use desktop mode because it is easier to find things and just read the article than having to open each individual heading one at a time. --Khajidha (talk) 11:10, 9 April 2018 (UTC)

I always use desktop view because mobile view is just so, so, so, bad for editing. It's ok for reading, but IMO is absolutely useless for editing. older ≠ wiser 11:14, 9 April 2018 (UTC)

Right, so you both edit from mobile devices? Didn't take that into account. It would seem it mainly benefits editors then (and the sandwiching would not be a problem for the majority of readers, who don't use desktop mode)? FunkMonk (talk) 13:04, 9 April 2018 (UTC)

See, to me, your "Aren't we unnecessarily adapting to an outdated mode of viewing Wikipedia on such devices?" has the problem almost entirely reversed. Why are we attempting to force Wikipedia's content to "fit" on a device that isn't designed to handle it? If people want to look at the internet on their phones, they should find a phone that can handle the internet the way it is. These phones exist now, so why are we continuing to offer this half-assed, bastardization of a "mobile site"?--Khajidha (talk) 13:38, 9 April 2018 (UTC)

This to me is a really strange tack to take. Publishers who said "they should learn to read news on paper the way it was meant to be read!" are no longer in business. Wikipedia is an online site and thus is seen via many different portals and devices, and it makes sense to make format considerations for all of them, especially when mobile viewing is increasingly the dominant form of web viewing. If anything, pages should be designed mobile-first rather than the other way around. As to "the infobox is so long it interferes with the body text", that sounds like maybe editors shouldn't be trying to dump every detail into the infobox, the article lead isn't adequately covering the article, or another issue. Der Wohltemperierte Fuchs^(talk) 16:05, 9 April 2018 (UTC)

Of course it doesn't go against WP:GALLERIES! Most people never read what that actually says, often relying on a folk-memory of what it used to say in 2006, when it was about preventing all-gallery pages in article space, then common. Johnbod (talk) 14:19, 9 April 2018 (UTC)