Jump to content

Wikipedia talk:Manual of Style

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Flyer22 Frozen (talk | contribs) at 22:45, 9 September 2020 (→‎WP:Surname and MOS:GENDERID with regard to drag queen articles: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

Style discussions elsewhere

Add a link to new discussions at top of list and indicate what kind of discussion it is (move request, RfC, open discussion, deletion discussion, etc.). Follow the links to participate, if interested. Move to Concluded when decided and summarize conclusion. Please keep this section at the top of the page.

Current

(newest on top)

Capitalization-specific:

This section is an excerpt from Wikipedia talk:Manual of Style/Capital letters § Current.[edit]

Move requests:

Other discussions:

Pretty stale but not "concluded":

Question

What about articles regarding subjects that span multiple styles of English, such as the War of 1812? Royal Autumn Crest (talk) 01:56, 3 September 2020 (UTC)[reply]

Concluded

Extended content
2019:
2018:
This section is an excerpt from Wikipedia talk:Manual of Style/Capital letters § Concluded.[edit]
Capitalization-specific:
2023
2022
2021

Non-breaking spaces with written-out units

As a follow-up to topic-specific discussions at Talk:Hassium and User talk:DePiep#MOS and NBSP, it seems that the current MOS guideline on the usage of non-breaking spaces when separating numbers from written-out units (e.g. 5 kilometers (instead of 5 km); 118 elements) is open to interpretation. It advises to use non-breaking spaces when line breaks are awkward, which they seem to be in this case; however, implementing this would apparently require making heavy changes to lots of articles, as it is not strongly established as are the examples given in the MOS section.

I thus ask, should the same guideline for quantities and abbreviated units be followed for fully spelled-out units? Should non-breaking spaces be used only with abbreviations, or always with units and quantities? I would like to establish a more definite MOS guideline, in which one or the other is widely agreed upon as common practice. ComplexRational (talk) 00:46, 10 March 2020 (UTC)[reply]

  • I really, really wish people would stop jumping straight into a project-wide RfC before working with other editors to frame the questions to be posed. I urge you to withdraw this. And MOSNUM is probably the right place for this. (Main MOS vs subsidiary pages is a longstanding problem.) EEng 01:26, 10 March 2020 (UTC)[reply]
Where else would you suggest discussing this, seeing as its outcome is not specific to the articles for which this was discussed, and the question is pretty straightforward from these discussions? If it can be held elsewhere, I will withdraw; however, I don't think that place is MOSNUM because this issue pertains to MOS:NBSP, which is not its own MOS sub-page. I'm open to ideas. ComplexRational (talk) 02:02, 10 March 2020 (UTC)[reply]
I'd suggest discussing it right here (or at Talk:MOSNUM, but since ultimately it's an aesthetic, not technical, issue I guess here is fine.) There are plenty of people here who have thought a lot about formatting issues, and many have outside professional experience, and with their participation I suspect the issue can either be resolved or boiled down to a clearcut question. Open-ended RfCs like you've started, which pull random people from all over into an unstructured discussion, just end up a mess. EEng 03:28, 10 March 2020 (UTC)[reply]
Okay, I withdrew it as an RfC. Let's play it out as a regular discussion now; I apologize for being unaware of this potential complication. ComplexRational (talk) 09:53, 10 March 2020 (UTC)[reply]
Ping to prevent archiving. EEng 12:49, 27 March 2020 (UTC)[reply]
I don't see the "jumping into an RfC" that EEng is referring to here. I do see a reasonable description by ComplexRational of a MOS detail to be clarified somehow. Do I miss some invisible redacted editing? Please clarify. As it stands now, the OP is correct and relevant to me. -DePiep (talk) 00:01, 1 April 2020 (UTC)[reply]
Yes, obviously, like the OP said: he had set this up as an RfC but later withdrew it at my urging. EEng 00:28, 1 April 2020 (UTC)[reply]
Eh, that 'obvious' part is not visible then?, like in an talk edited afterwards (ouch)? Must I do homework research to see it? -DePiep (talk) 00:34, 1 April 2020 (UTC)[reply]
Jesus Christ, the OP wrote, just above here: Okay, I withdrew it as an RfC. 01:46, 1 April 2020 (UTC)
I think the point that is puzzling both DePiep and me is there seems to be no trace of the !RfC for us to see what issues had been raised. Starting an RfC and then withdrawing it should surely leave something in a history somewhere. There are no links, nor anything in contributions that I can find. What am I missing? --RexxS (talk) 14:11, 1 April 2020 (UTC)[reply]
The most recent diff before I withdrew upon EEng's suggestion was [2]. All that changed since then was removal of the RfC template; the content of my original post is the same now as it was then. ComplexRational (talk) 14:43, 1 April 2020 (UTC)[reply]

In traditional typography, typesetters would ensure that sentences didn't break onto another line at a point where the result was a new line starting with something that didn't make sense alone, or where the break would produce a semantic dissonance. So they would avoid lines starting with an abbreviation:

  • something something ... a distance of 15
    km

as well as lines that changed meaning when the next line was read:

  • something something ... a cost of $5
    million

In electronic document processing, when line length can change with screen resolution or window size, the non-breaking space was used to prevent those sort of breaks from happening. I don't believe there has ever been any rationale for placing a non-breaking space between numbers and normal recognisable English words, because those don't produce problems, other than in cases like the second example. There is really nothing wrong with seeing:

  • something something ... a distance of 15
    kilometres

and it is especially ludicrous to extend the fetish for non-breaking spaces in quantities to normal counted items. There is nothing wrong with reading:

  • something something ... a squad of 24
    football players

The examples at MOS:UNITNAMES reflect these simple principles, and I can't see what other interpretation could be made of the present guidance:

  • Use a non-breaking space ({{nbsp}} or  ) between a number and a unit symbol, or use {{nowrap}} ...
  • ... and a normal space is used between a number and a unit name.

If somebody wants to change those guidelines, then they really should be proposing what changes they want made and the reasons for them. --RexxS (talk) 19:07, 27 March 2020 (UTC)[reply]

Just for the record, I wasn't proposing a change. I was merely asking for clarification, and if any disagreement were to arise, then firmly establish one way or another. What is written here makes sense, now I only propose that it is made crystal clear for other (copy)editors in the MOS:NBSP section (to use only with abbreviations). ComplexRational (talk) 00:10, 1 April 2020 (UTC)[reply]
(ec) @RexxS:, these examples are undisputed, and are clear by WP:NBSP and WP:MOSUNIT. Minor detail: your example of 15<regularspace>kilometres is not in the MOS explicitly, but well observed, also by {{Convert}} — end of detail.
Note: for simplicity, an "_" (underscore) says NBSP.
A question arose when reading in MOS:NBSP: It is desirable to prevent line breaks where breaking across lines might be confusing or awkward. -- note the criterium "awkward". The examples given are (1) unit symbols - no problem, see before, and (2) exampes of number-in-proper-name (Boeing_747).
Some editors state that the "awkward" situation may also occur in situations with a number inline, i.e. in running text. Examples (in here): element_114, the expected magic 114_protons, ....
My (opposing) point is that such number-word combinations are not awkward, can reasionably occur in any running sentence, are part of a reading habit, and so are not 'awkward' and do not allow an NBSP. Otherwise, this whole enwiki could require a MOS-change in ~every article, or have inconsistent styles between articles re this line-breaking.
So, first question: do we recognise this is a Good MOS Question to discuss? -DePiep (talk) 00:25, 1 April 2020 (UTC)[reply]
There's long been a need for the nbsp/nobreak guidance to be improved. I've never done anything about it because I realized some cases would need a discussion. EEng 00:28, 1 April 2020 (UTC)[reply]
@DePiep: It certainly seems that something ought to be done to educate editors about when to use (and not use) non-breaking spaces. I just looked at the Island of stability article you pointed out. Over 200 non-breaking spaces. Seriously? I've just removed four that you could see at a glance occur at places where the line could never break. No doubt somebody will revert me, citing MoS instead of thinking for themselves. I'm not sure repeating the already crystal clear guidance in MoS is the solution though. Either they never read MoS or they don't understand what a line break is. Either way, tinkering with the MoS won't have any effect on them. As for your actual examples, I've long ago given up trying to convince others that there's absolutely nothing wrong with reading
  • Flerovium, with the expected magic 114
    protons, was first synthesized in 1998
Although to get a line break there, you would have to be viewing on a screen with a maximum line length of less than 40 characters. Even my 1978 vintage TRS-80 could manage that. --RexxS (talk) 03:06, 1 April 2020 (UTC)[reply]
  • If 114 protons can't be broken, then you may as well say that every number has to be followed by an nbsp, always, and that would be silly.
  • I do think Z = 112 shouldn't break, though that would be better coded as {{nobr|Z = 112}} than the current Z&nbsp;=&nbsp;112
  • I'm not sure that all the examples at MOS:NBSP belong there, and I wonder if there shouldn't be some other cases listed.
EEng 04:20, 1 April 2020 (UTC)[reply]
User:RexxS: that is my understanding of MOS:NBSP too, including its background (typography). It's just, I stopped editing because of EW, started a talk, and involved editors correctly started a wider talk here. But I see no need to admonish other editors, instead we could use a clearer MOS text and explanation here, for fellow editors. -DePiep (talk) 08:28, 1 April 2020 (UTC)[reply]
I now see that the section title here is a much narrower issue than the wide one ComplexRational and I were discussing/editing. As the Island of stability example show, it was and is about all of MOS:NBSP. This complicates/disturbs this talk flow, I must excuse. (how to proceed?). -DePiep (talk) 08:32, 1 April 2020 (UTC)[reply]
@EEng and DePiep: Apologies, I was too focused on the quantities issues and not enough on the general nbsp guidance, which does seem to be missing. IMHO, we should have a guideline that says something like
  • Numbers followed by an ordinary English word (not an abbreviation, or similar) do not require a non-breaking space between them in normal circumstances.
There are also many circumstances where a non-breaking space is unnecessary because a line break can't happen there. There are three examples in Island of stability: in the caption of the infobox (the width is fixed, regardless of window size); in reference number 5 (too close to the start of a line for a line break to be possible); and in the table caption "Most stable isotopes of superheavy elements (Z ≥ 104)" (the table can't become narrow enough to wrap the caption onto another line). I've tried pushing the zoom up to 250% and narrowing the window to its minimum, but I can't find a setting that could cause a line break where one had been placed. Nevertheless, I don't suppose that is anything we can, or should, try to give guidance about in MoS for fear of causing more confusion. --RexxS (talk) 14:06, 1 April 2020 (UTC)[reply]
In the first image, a line break appeared at 70% zoom on my computer screen, and indeed was awkward. What exactly are you suggesting would risk more confusion? The MoS is supposed to make things as clear as possible, and I wouldn't have started this thread had it been clear from the beginning (echoing EEng – There's long been a need for the nbsp/nobreak guidance to be improved.). ComplexRational (talk) 14:40, 1 April 2020 (UTC)[reply]
Thanks for explaining how you got the line break in the image caption; I hadn't considered zooming out that far. But do you think anybody actually reads Wikipedia at 70% zoom? I can't even get any of my browsers to zoom at 70% to see the effect. Still, it's possible, so best to leave in the {{nowrap}} in that case. The general point about infobox images with captions shorter than the image width is worth understanding, though.
What I am suggesting is that there are many cases where we simply don't need a non-breaking space, i.e. whenever it's not possible for the line to break at that point, but that it's difficult to try to give foolproof guidance to cover those cases, so I don't think we can come up with a form of words that would be helpful. Can you?
Do you agree with my suggested clarification above: Numbers followed by an ordinary English word (not an abbreviation, or similar) do not require a non-breaking space between them in normal circumstances. and if not, why not? --RexxS (talk) 16:33, 1 April 2020 (UTC)[reply]
Makes sense, I understand what you're saying about captions. Would it then also be better to use {{nobr|1=''Z'' = 114}} (for example) throughout the article, if this would be preferred to a pair of nbsp's? (On an unrelated note, maybe a new template should be created following whatever this discussion establishes, as this is pretty common in chemistry and physics articles.) ComplexRational (talk) 18:18, 1 April 2020 (UTC)[reply]
I agree with this wording, it addresses the elephant in the room and is easy enough to follow. I would specifically use it as an antithesis to the MOS points advising nbsp with units (70_km) or parts of the name (Airbus_A380), though I suppose saying "not an abbreviation" already addresses that. The only thing that may raise questions is "normal circumstances" – I'd rather leave that out and add an additional bullet point saying something along the lines of Non-breaking spaces are not required in fixed-with table cells or image captions, especially when the text is not long enough to wrap., or else work out through discussion what the most common exceptions would be (that would otherwise confuse editors unfamiliar or too familiar with MOS). ComplexRational (talk) 18:18, 1 April 2020 (UTC)[reply]
Most editors, in my experience, prefer {{nowrap}} over multiple consecutive non-breaking spaces in a phrase. It makes the wikitext more readable for other editors (the same reason we prefer to avoid html entities where possible).
The "normal circumstances" would be to cover exceptions like
  • ... his fee for the service was $50
    thousand.
where a non-breaking space between the number and the next word would avoid giving the reader the impression the fee was $50 until they read on to the next line. But I'm happy to accommodate other views such as giving examples of specific exceptions instead of stating "normal circumstances".
While I think about it, there is a good case for what I called the "semantic dissonance" to be noted as a rule in other places as well:
  • ... the great-grandnephew of Queen Mary
    II
To anyone familiar with Tudor/Stuart history of England, it first reads as Mary I of England, then as Mary II of England when the next line is reached and obviously should be avoided. That represents one of the very few phrases where I would have no hesitation in recommending the use of a non-breaking space for cogent, rather than aesthetic reasons.--RexxS (talk) 19:26, 1 April 2020 (UTC)[reply]
This is already covered at MOS:NUM, to the extent any of this needs any rule-mongering. It advises using non-breaking spaces in strings like 5 cm, but it does not advise doing this when using spelled-out words. It doesn't advise against it, either. Like most things, it is left to editorial discretion. Nothing is broken. No, we do not need another template, since {{nobr}} and {{nbsp}} work fine. So does just using &nbsp;. Yes, it is WP:Common sense to non-breakify certain strings like "$50 thousand", and "Mary II". No, we don't need a rule about it, or we would've already had one by now. No, we do not need anyone going around inserting non-breaking spaces robotically in proximity to every number they see, per WP:MEATBOT ("ain't broke, don't 'fix' it").  — SMcCandlish ☏ ¢ 😼  11:29, 3 June 2020 (UTC)[reply]

NBSP for numeric followed by words

Hi all, I recently put up Wikipedia:Featured article candidates/1985 World Snooker Championship/archive2 for FAC. SandyGeorgia commented that there should be some additional non-breaking spaces for items such as "15 seeds, 103 entrants, 32 participants". I don't really mind putting these in, but wanted to clarify our MOS, and how it effects these types of phrases. My understanding at WP:NBSP is that we should use these on names, such as World War 2, and measurements, such as 10 Miles. However, should we also use these on regular expressions, such as "20 people"? I don't mind either way, but wanted to clarify before I do wholesale changes. Best Wishes, Lee Vilenski (talk • contribs) 14:19, 10 July 2020 (UTC)[reply]

The guideline gives patchy and somewhat conflicting advice on this entire subject. I'm going to give you what I think will be useful guidance, but we must brace ourselves for people to leap out at us from all corners of the project to denounce what I say as at best the product of unfathomable ignorance, and at worst detrimental to the moral fiber of the nation.
There are two (maybe more, but two I can think of offhand) things we're trying to prevent:
  • (1) You don't want tiny fragments that look odd alone stranded on the start of a line. Thus World War{nbsp}2 and Henry{nbsp}VIII.
  • (2) You don't want two things separated by a linebreak if the reader, seeing just the first part, will be momentarily misled and have to back up and rethink when he sees the bit on the next line. Thus $2{nbsp}million, because if the million goes on the next line the reader first thinks "Two dollars", and then when he sees the million he has to back up and think "Oh, wait, Two million dollars". (This is a peculiarity of the fact that money symbols go at front of quantities rather than at the end as with other units. Can anyone think of a similar example not involving money?)
(3) Notice that the logic of (2) doesn't arise with normal quantities like 15 seeds or 2 million dollars (i.e. no nbsp used in these cases) because as the reader scans "15<linebreak>seeds" there's nothing misleading about 15 alone at the end of the line, and the same for scanning "2<linebreak>million dollars" or "2 million<linebreak>dollars". When you think about it, if you required nbsp in constructions like that, then you're pretty much saying every number anywhere must be followed by an nbsp, and that can't be right. So I would not put {nbsp} in your examples.
(4) Units of measure are a special case. By the logic of (3), there's no {nbsp} in 10 kilometers. However, I think the guideline does recommend an {nbsp} in the case of 10{nbsp}km, because at the start of a line km looks weird in a way kilometer doesn't. (km is what's called a unit symbol, whereas kilometer is what's called a unit name, and there are several other ways in which unit symbols and unit names are treated differently, so there's nothing odd about treating them differently here.)
Perhaps the principles laid out above can be the start of a revival of this thread. EEng 03:04, 12 July 2020 (UTC)[reply]
Or perhaps not. In the meantime, here are some other places I think (comment invited, of course) nbsp would be needed or not needed. Probably some or all of these are give by others in the posts above but I want to get them down while they're on my mind.
Needed:
  • In DMY dates e.g. 28{nbsp}May or 28{nbsp}May 1935, because at least some readers will find separation of the day-in-month from the month odd. (Further explanation on request as to why this is different from the case of 10 kilometers.)
  • In MDY dates e.g. May{nbsp}28, 1935, because "28, 1935" looks ludicrous at the start of a line.
  • He responded, "Better you than{nbsp}I." or The smallest reading was{nbsp}5.
  • 9:30{nbsp}a.m. because I think it's somewhat analogous to a unit symbol (see above); and definitely 9:30{nbsp}am, because "am" alone and separated from the "9:30" could cause the reader to trip and fall.
  • several{nbsp}.22 shells, because starting a line with a . looks weird
  • <certain image caption situations, details to be supplied (centered captions, left-aligned captions)>
  • Ellipsis or other fragments at the start of a quotation: He listed them as "1.{nbsp}Good goals, 2. Good planning, 3. Good execution; or The torn frament read, "...{nbsp}for the love of God!"
Not needed:
  • 123 Main Street
EEng 00:48, 14 July 2020 (UTC)[reply]
  • I ask people here: how often have you struck a dangling numeral at the end of a line? Me: not that I can recall. Tony (talk) 07:08, 14 July 2020 (UTC)[reply]
    By struck do you mean "run into/happened to find" or "struck out/had to get rid of"? EEng 16:14, 14 July 2020 (UTC)[reply]
  • I could see having a summary section somewhere (hopefully not in the main page, maybe in MOS:TEXT) about "Appropriate uses of non-breaking spaces" or some heading title like that, in which we could suggest these sorts of cases, without implying that they're required. People already rankle as the currently fairly-strongly-recommended ones in MOS:NUM and a few other places. So, there's opportunity to cry "WP:CREEP!" here if this discussion produces more rules, rather than optional tweaks for polishing up text for maximum usability.  — SMcCandlish ☏ ¢ 😼  02:30, 15 July 2020 (UTC)[reply]
    Definitely for FA-level polishing, mostly, but there's one situation where I've found it worth the trouble to apply nbsp/nobr fairly liberally: in image captions, because their short line length means bad breaks do occur now and then unless you prevent them. EEng 03:45, 15 July 2020 (UTC)[reply]

Nobility

There's a tendency on articles about noble families to describe children as "issue" and to say that the father has children by [name of wife]. I know the aristocracy does view heritage like breeding horses, but is this appropriate for Wikipedia? Guy (help!) 15:34, 4 June 2020 (UTC)[reply]

Dhtwiki, "issue=" is a parameter in the nobility template, and the term is often used especially in articles on fake nobility ("Her Imperial and Royal Highness" the social worker) presumably prompted by that. I think we should rename the parameter from "issue" to "children". Guy (help!) 11:20, 8 June 2020 (UTC)[reply]
"Issue" has the virtue of being shorter. Would "children" be better understood? Does "issue" have any implication of "lawfully begotten" (i.e. not out of wedlock), a condition that I believe is still important in inheriting noble titles. Dhtwiki (talk) 07:19, 9 June 2020 (UTC)[reply]

the Terminology section?

Hello, I was unsuccessful to find a MOS or rule about where the Terminology section should/can be placed? I ask this because there is a debate about it: Talk:Video game#Please add the section "Terminology" please add something about it, thanks.--Editor-1 (talk) 04:08, 13 June 2020 (UTC)[reply]

This is not something MOS is going to specify. It's something editors on particular articles need to work out for themselves. EEng 04:12, 13 June 2020 (UTC)[reply]
The explained problem in Talk:Video game#Please add the section "Terminology" is that the Terminology section is placed in the child/forked articles while the main article lack it, my mean about "where the Terminology section should/can be placed?" was about that situation, not where to place the Terminology section in articles.--Editor-1 (talk) 04:46, 13 June 2020 (UTC)[reply]
I looked into it and commented, but it's not an MoS issue. It's really a WP:MERGE/WP:SPLIT and WP:SUMMARY issue, i.e. a content (and information-architecture and usability) not style matter.  — SMcCandlish ☏ ¢ 😼  14:16, 24 July 2020 (UTC)[reply]

Semi-protected edit request on 15 June 2020

Under the section "Contractions," change cannot to can not. Cannot is itself a contraction, so suggesting it as an alternative to "can't" is slightly ironic. 73.204.53.149 (talk) 22:05, 15 June 2020 (UTC)[reply]

What you say is completely incorrect. Can't is a contraction of cannot, but cannot cannot be called a contraction of can not, because it is not; they mean completely different things. EEng 22:14, 15 June 2020 (UTC)[reply]
What? Google plainly defines 'cannot' as can not, and classifies it as a contraction. Merriam-Webster also defines it as meaning 'can not.' I don't know of a single alternative definition for cannot. --2601:583:4381:9B90:989C:5EC1:FFA6:1F22 (talk) 00:32, 16 June 2020 (UTC)[reply]
 Not done for now: please establish a consensus for this alteration before using the {{edit semi-protected}} template. RandomCanadian (talk / contribs) 22:17, 15 June 2020 (UTC)[reply]
Sorry, what? That's not right. These edit-request threads are perfectly appropriate places to start a discussion of a potential change. It's what they're for. And WP:NOTBURO. EEng 22:21, 15 June 2020 (UTC)[reply]
Declining edit requests for potentially controversial edits is pretty standard, especially when someone has expressed disagreement immediately after, especially on a PAG page with a DS notice like this one. Even with a decline, all are still welcome to discuss. If a consensus emerges, the request can be reopened (or someone participating in it can just go ahead), but closing out ones like this helps keep the queue managed. –Deacon Vorbis (carbon • videos) 00:49, 16 June 2020 (UTC)[reply]
Then the decline should say, "Not done at this time, but feel free to continue discussing in this thread". The idea that you should get consensus first, then make an edit request, is silly because once consensus is reached the edit request is superfluous. EEng 04:11, 17 June 2020 (UTC)[reply]
When a non-autoconfirmed editor tries to edit a semi-protected page, we show them a big blue button that says "Submit Edit Request", which overwhelmingly get summarily closed for lacking consensus. It would probably be more constructive just to direct them to make the proposal on the talk page for discussion. (That advice is also there, but the big blue button is more prominent.)--Trystan (talk) 04:55, 20 June 2020 (UTC)[reply]
So my point is we should treat edit requests as proposals for discussion. Once the discussion's underway the edit request can be changed to Answered to get it out of the queue, since presumably editors active on the talk page will take it from there, as with any other thread. EEng 04:37, 21 June 2020 (UTC)[reply]
"Cannot" means "not able to", "can not" means "able not to". There's a subtle difference. --Khajidha (talk) 19:47, 17 June 2020 (UTC)[reply]
Or "able to not". EEng 21:51, 14 July 2020 (UTC)[reply]
Yep. I think the OP is correct a in hollow-victory way, in that the linguistic process that produced cannot was one of contraction. But this is a fallacy of equivocation, in which a very general, procedural, and mass-noun sense of contraction is being misapplied in a context that is addressing a very narrow, concrete, count-noun meaning, namely informal contractions of the apostrophe sort (can't). It could have also addressed the "eye dialect" sort (gonna), though I don't think we even need to address those; editors know better than to use them in articles. In all of WP's existence, I think this is the first time anyone has suggested the rule is confusing, yet they're making a clever enough argument that they're clearly not actually confused but trying to nit-pick. At any rate, cannot isn't "a contraction"; it's a word that was produced by contraction. "A contraction" in the sense we mean here is a short-hand for a longer expression (don't for do not) with the same meaning, while cannot and can not don't actually have quite the same meaning, since Early Modern English. By the OP's definition, probably most of English would consist of contractions, since a tremendous number of our words are borrowings directly (or via one form of French or another) from Latin or Greek but shortened. Even many native English words are squished-down versions of longer Anglo-Saxon originals. We also obviously don't mean regular abbreviations that happen to be produced via contracting out the middle letters; British formal writing (per New Hart's Rules and Fowler's) does not put stops at the ends of these (St for Saint, Dr for Doctor) but does put them, like American publishers do, at the ends of truncation abbreviations (like Prof. for Professor). I don't think I've ever seen anyone "confused" that this section means any of that stuff, either. It's pretty clear what it's addressing when the example is of the apostrophe-bearing sort, and the linked article section (Contraction (grammar)#English) also only provides apostrophe-contraction examples. Maybe the OP would be better off suggesting that the article address other forms of contraction in English?  — SMcCandlish ☏ ¢ 😼  02:20, 15 July 2020 (UTC)[reply]

Names of organisms that include hyphens and dashes is not mentioned in the MOS

A recent move discussion was held at Severe acute respiratory syndrome-related coronavirus on whether to use a hyphen or dash in its name in the article title. The move discussion was closed improperly/prematurely/etc. as there was no consensus to move, prose across numerous articles was not updated to reflect the move, and I and another user were in the middle of a discussion. The issues I raised were unresolved in the move discussion, so I am bringing them up here since this is a MOS issue.

Currently, the usage of hyphens and dashes in biological names is not addressed in the MOS. Note that for viruses, Latin binomial nomenclature is not used, so hyphens are common in virus names but presumably rare for non-viruses. On Wikipedia, there has been a longstanding consensus among people who edit virus articles to defer issues like this to the ICTV, the organization responsible for virus taxonomy, including spelling, punctuation, etc. There are currently 191 virus species that have a hyphen in their name and none that have a dash. For these reasons, hyphens have become standard across all virus articles for virus names, regardless of the manner that the hyphen is used in the name. The recent move of SARSr-CoV has broken the consistency on this matter, so I am bringing attention to it here.

From looking at how hyphens are used in virus names, I found the following different ways:

  • 1. in a sequence of letters and numbers, e.g. Escherichia virus KWBSE43-6
  • 2. as part of -associated, -related, -dependent, and -like constructions, e.g. Adeno-associated dependoparvovirus A, Severe acute respiratory syndrome-related coronavirus, Mimivirus-dependent virus Sputnik, and Phasi Charoen-like phasivirus
  • 3. as part of a proper name within a virus name, e.g. Avon-Heathcote Estuary associated kieseladnavirus
  • 4. as part of a description within a virus name, e.g. Tomato pseudo-curly top virus, Turnip vein-clearing virus, Foot-and-mouth disease virus, and Acidianus bottle-shaped virus
  • 5. as part of -borne constructions, e.g. Soil-borne cereal mosaic virus
  • 6. the "T-lymphotropic" viruses, e.g. Primate T-lymphotropic virus 1
  • 7. "type-x" viruses, e.g. Guinea pig type-C oncovirus

A resolution to this issue would be beneficial. Essentially, two things should be addressed:

  • 1. how hyphens and dashes should be used in scientific names
  • 2. how hyphens and dashes should be used in common names

Because of the different ways that hyphens are used in virus names, I've thought that it may be beneficial to amend the MOS to state that names of organisms should use whichever (hyphen or dash) is part of their name. In my opinion, this is preferable to having multiple approaches to dealing with these names, which would create a lot of inconsistency in virus articles. Velayinosu (talk) 04:28, 21 June 2020 (UTC)[reply]

The move has broader implications than one article so I figured that this would be a better place since it's a MOS issue. You're free to state how you think scientific and common names should be dealt with too you know, but maybe we need uninvolved people for this discussion to go anywhere. Velayinosu (talk) 03:36, 5 July 2020 (UTC)[reply]

I have struck parts from the original comment that were inappropriate and want to clarify that my opinion (the last paragraph) is for scientific names and that the hyphen is standard for virus scientific names on Wikipedia, though there may not be explicit stated consensus for it even though there is a general practice of deferring topics like this to the ICTV. Velayinosu (talk) 00:19, 7 July 2020 (UTC)[reply]

It's not clear what you mean by "the hyphen is standard for virus scientific names on Wikipedia". What about places where the en dash is appropriate? Wikipedia style is to not use hyphens to stand for what en dashes mean. Dicklyon (talk) 06:13, 7 July 2020 (UTC)[reply]
I mean that on nearly all virus articles the hyphen is used for scientific names, regardless of the construction used in the name, so it is in effect standardized, including for situations when one might think a dash should be used. Velayinosu (talk) 02:45, 8 July 2020 (UTC)[reply]
Do you know examples of ones where WP style would be to use an en dash but we've accepted a hyphen due to the ICTV? Dicklyon (talk) 04:30, 8 July 2020 (UTC)[reply]
In particular, most of your examples are good examples of the uses of hyphens. But a few are not. For example, the Avon–Heathcote Estuary is named for two rivers, and a hyphen between those would not make sense in a style where en dashes are used for that; see for example this book where you can see the dash between them is longer than a hyphen on the same page. There's no reason to change that to a hyphen just because it's included in a virus name. Dicklyon (talk) 06:38, 7 July 2020 (UTC)[reply]
@Dicklyon: this takes us, yet again, to the endless discussions of where the boundaries are between substance and style. The scientific names used in the ICTV are identifiers: exact strings of characers. The hyphen is part of the identifier and should not be changed. If you search the ICTV taxonomy database at https://talk.ictvonline.org/taxonomy/ with the string "Avon–Heathcote Estuary associated kieseladnavirus" (i.e. containing a dash rather than a hyphen) you get "No results". You have to search with a hyphen to find the species. Its name has a hyphen not a dash. Peter coxhead (talk) 08:01, 7 July 2020 (UTC)[reply]
If you put the quote marks you also get no result. But the fact that their search is broken doesn't need to be a problem that drives our article title styling. It does find strings like avon-HEATHCOTE, so it's obviously doing some kind of text normalization or flexible matching; just needs to be fixed a bit. Dicklyon (talk) 15:26, 7 July 2020 (UTC)[reply]
All your search shows is that the search function on the ICTV's website is not case sensitive and it recognizes portions of names. It's working as intended, not broken. Velayinosu (talk) 02:45, 8 July 2020 (UTC)[reply]
If it won't allow matching of an en dash to a hyphen or hyphen-minus or nonbreaking hyphen, it's broken. Dicklyon (talk) 04:30, 8 July 2020 (UTC)[reply]

Note that there is a related WP:RM discussion ongoing at Talk:Middle East respiratory syndrome-related coronavirus, citing MOS:SUFFIXDASH. Most of the examples given above in item 2 use only a single word before the "-associated, -related, -dependent, and -like" suffix. The guidance provided in MOS:SUFFIXDASH only differs when dealing with a multi-word phrase before the suffix. —BarrelProof (talk) 16:50, 7 July 2020 (UTC)[reply]

Additional information: the ICTV explicitly states on its website[4] that hyphens are the only permitted form of punctuation in virus taxonomic names, i.e. dashes are prohibited. Velayinosu (talk) 04:59, 8 July 2020 (UTC)[reply]

Plainly the move was in error. This is not a style question, but a question of fact. And the fact is the international standard is plainly that the names contain hyphens, not dashes. Changing it has created an erroneous, made-up name. Factual errors like this can't be allowed to persist. oknazevad (talk) 11:27, 9 July 2020 (UTC)[reply]
@Velayinosu: I would decouple this entirely from discussion of a particular move or particular case at all. The evidence-gathering so far is a good start, but this will probably be more productively (though more slowly) hashed out at WT:MOSORGANISMS. That's a long-term-stable draft guideline that gets into all the tiny nitpicks of biological nomenclature, and is surely where we would put anything about hyphens in scientific and vernacular names of organisms. Be aware also that not all the rules that apply to zoological and botanical names apply beyond them, especially in virology. So we may not be able to generalize very far from virus example to other things or vice versa.  — SMcCandlish ☏ ¢ 😼  01:47, 15 July 2020 (UTC)[reply]

Commas withing WP:MOS

What rules apply for commas within WP:MOS? In particular, do English or American rules apply to the comma after exempli gratia (e.g.)? The article is currently not consistent. Shmuel (Seymour J.) Metz Username:Chatul (talk) 08:22, 29 June 2020 (UTC)[reply]

The MOS seems to be written in American English (it uses AmE color, not BrE colour, and it uses AmE/BrE -ize forms, not BrE -ise forms), and so it seems that a comma should be used after e.g. for stylistic consistency. (Personally, I would prefer for example spelled out in running text and e.g. used in parentheses.) Doremo (talk) 10:43, 29 June 2020 (UTC)[reply]
This is not an article (fact) and therefore need not be consistent in its style (current consensus), as odd as that my seem (my opinion). Primergrey (talk) 16:03, 29 June 2020 (UTC)[reply]
MOS is an ecumenical zone in which all ENGVARs coexist side by side in peace and harmony. EEng 20:13, 29 June 2020 (UTC)[reply]
It was written in AmEng. I hope it's not grown internally inconsistent. Tony (talk) 14:38, 30 June 2020 (UTC)[reply]
Long, long ago. And there's nothing wrong with that -- it's fun in fact. It's a reminder that this is an international project. See User:EEng#A_rolling_stone_gathers_no_MOS (my userpage having grown to the point that there's no topic not somehow related to it). EEng 16:11, 30 June 2020 (UTC)[reply]
Dialectal style varies by MoS page (though I think most of the MoS is in AmEng). And -ize isn't just American, but also often Canadian, and used in Oxford spelling in British/Commonwealth English. But the idea that "e.g." versus "e.g.," is a UK/US distinction isn't anything I've ever seen good sourcing for. There's another thread about it already on this talk page anyway, so it's probably worth using one thread or the other for such investigations. I don't know why Primergrey wants to argue that MoS and other internal pages need not be written consistently or following any style best practices at all, but it's an omphaloskeptical argument to present, since we do in fact write these pages pretty consistently and following MoS on most applicable points, and they are getting better in both respects over time, not worse.

Back to i.e. and e.g.: What I've noticed is that after either of these, a comma tends to be used with long, complex material, but omitted with short, simple material. There's a tiresome old argument that they "must" have a comma because the closest idiomatic translations in English, "for example" and "that is", would require one. It's a linguistically unsound argument, because foreign loans often do not behave in their new language exactly like directly corresponding native expressions would, and their literal meaning is often completely opaque to almost everyone using them. We already know that Latinisms abbreviated in English are used by habit without perfect understanding by many, and defy various other English norms (e.g., by being preferred in parentheticals and footnotes rather than in running text; by being written e.g. instead of EG like other initialisms; by often not undergoing plurality or other adjustments that would be required of the English equivalent; by sometimes taking counterintuitive irregular plurals when they do take them, e.g. pp., qq.v.; by abbreviating for no reason – i. is the same length as id; by being irregularly punctuated and spaced – compare etc. for et cetera and q.v. or even q. v. for quod vide; and so on).

So, there really isn't any reason to expect a comma to be "mandatory" after i.e. or e.g., especially if inserting one doesn't actually improve the reading flow or comprehension. "Drupes are pitted fruit, such as plums, apricots, cherries, and many other single-seed fruits, including some produce more often thought of as vegetables (e.g. avocados)" wouldn't really be improved by adding a comma. But the same "death to commas" behavior that results in messes like "In 1900 Ireland ..." when "In 1900, Ireland ..." was meant, with a very different meaning, can also result in awkward-looking stuff when e.g. precedes, without a comma, a long list of things or an otherwise complex bit of material, and i.e. with no comma also can have an "I have to go back and re-read this sentence" effect. So, "... co-starring Buster Poindexer (i.e. David Johansen) and ..." isn't going to be helped by a comma. But one works much better in "Buster Poindexter (i.e., David Johansen of New York Dolls fame, working under an alias he first used on an eponymous album in 1987)"; it really looks like a comma is accidentally missing from a construction like that if you remove it.
 — SMcCandlish ☏ ¢ 😼  03:13, 15 July 2020 (UTC)[reply]

Removal of "UK" from location field in infoboxes

Is there a policy regarding the UK not being necessary in location field for companies, organisations etc. and that the constituent nation i.e. England, Scotland, Wales and Northern Ireland is sufficient?

For example I changed the location on Deltic Group from:

| location = [[Milton Keynes]], UK to |location = [[Milton Keynes]], England, UK Edit link: [5]

Subsequently user User:IceWelder removed the UK from the location from their edit:

| location = [[Milton Keynes]], England, UK to |location = [[Milton Keynes]], England Edit link: [6]

There a few other articles where this has happened: Rockstar North, Denki. Rather than get into an edit war I instigated a discussion about it and we couldn't come to an agreement on this point. I suggested it might be best to get advice/help from the Administator noticeboards. Discussion link: [7]

Conversely, the user User:Beagel has insisted that United Kingdom be added in full for the Vattenfall UK article in their edit summaries: [8] and [9]

|| location =London, England, United Kingdom

So its all a bit confusing!

I've edited quite a number of articles in the format |location = Place, Nation, UK without any issues.

Some clarification on this would be most welcome. Angryskies (talk) 11:55, 1 July 2020 (UTC)[reply]

Standard practice on articles related to association football players is for UK to be excluded from place of birth/death. GiantSnowman 11:59, 1 July 2020 (UTC)[reply]
Angryskies, thanks for opening this thread. For the sake of discussion, I would like to reiterate my main point against the inclusion of "UK" in infoboxes. It has been, as far as I am aware, the status quo not to, because naming the constituent country already makes for an unambiguous location identifier, making listing the sovereign state above it unnecessary. Another example with the same status is:
  • [[Willemstad]], Curaçao
  • [[Willemstad]], Curaçao, Kingdom of the Netherlands
  • [[Amsterdam]], Netherlands
  • [[Amsterdam]], Netherlands, Kingdom of the Netherlands
Adding the United Kingdom or the Kingdom of the Netherlands as an additional identifier does not help the reader in any way.
Whatever the outcome of this discussion, it should be included somewhere in the MoS (in respect to both the UK and the K.o.t.Netherlands, as well as any other constituent country constellation) for future reference. Regards, IceWelder [✉] 12:09, 1 July 2020 (UTC)[reply]
This relates to a similar discussion I've had with EEng on countries in general within infoboxes. Perhaps a guideline for UK, or other constituent countries, in infoboxes shouldn't be made specifically as a result of this discussion. Might be better to hold off until we can make a single, clear and consistent guideline for countries in infoboxes. ProcrastinatingReader (talk) 12:33, 1 July 2020 (UTC)[reply]
Well, this discussion could be the springboard for doing that, but a single Procrustean approach won't be satisfactory. The US situation has its subtleties; the UK situation has its subtleties; Australia and Canada have their special considerations. So a comprehensive discussion of all of them is likely to end with slightly different rules for each. In recent years I've come around to believing that infoboxes should be a scrunch more at-a-glance than article text, so that (for example) an infobox should say Westport, Connecticut, US. EEng 12:12, 2 July 2020 (UTC)[reply]
  • There is a general lack of consistency, at least relating to the UK. For now, it appears to come down to what editors in local articles wish to do. It is an area which needs clarification and a MOS guideline, though. ProcrastinatingReader (talk) 12:36, 1 July 2020 (UTC)[reply]
  • I don't necessarily think we need a MOS policy, but omitting "UK" after England, Scotland, & Wales seems correct & usual. A better case can be made for including it for Northern Ireland. I think the Netherlands examples are different (also French overseas territories). I'm very clear "Netherlands, Kingdom of the Netherlands" should not be used - either one will do. But "Curaçao, Kingdom of the Netherlands" is necessary on en:wp - maybe not on nl:wp. Johnbod (talk) 12:38, 1 July 2020 (UTC)[reply]
    Johnbod, I think a worse case can be made for including it against Northern Ireland, if we're considering any constituent country of the UK. I would imagine that there's a very diverse range of opinions you'll get, especially from NI people, on including "UK" after "Northern Ireland". ProcrastinatingReader (talk) 13:01, 1 July 2020 (UTC)[reply]
    Maybe - but that's the case for pretty much anything to do with NI. But in terms of how likely readers from the rest of the world are to be confused, I think it can be justified. Obviously those in Ireland are already well aware. Johnbod (talk) 13:04, 1 July 2020 (UTC)[reply]
  • Similar to what GiantSnowman indicates, there's a convention for individuals on some page clarifying demonyms which can probably be adapted. For specific locations, the UK should be kept in as it helps makes the infobox more immediately accessible to an international audience who may not be familiar with the situation, whereas removing it doesn't bring a benefit to the reader. CMD (talk) 13:19, 1 July 2020 (UTC)[reply]
  • Note, there is also an issue as to whether it should be "UK" or "United Kingdom" - the two diffs at the top were changing from the first to the 2nd. Personally, I think a linked "UK" is enough. Johnbod (talk) 13:31, 1 July 2020 (UTC)[reply]
  • We only need 1 country specified in location fields, there is no ambiguity by removal of UK. It also makes it clearer and shorter. A much more problematic situation is the removal of county from the field so you end up with <place>, UK which is not very helpful. I think that <place>, <county>, <constituent country> is what should be specified as that makes clear where we are referring to without having to going through any links to determine the place. Removing the county would be like removing the state in US articles. Keith D (talk) 13:42, 1 July 2020 (UTC)[reply]
  • I agree with IceWelder having location, country, sovereign state (like UK and K.o.t. Netherlands) is unnecessary and does not help readers. Stating that the location is based in England/Wales/Scotland already establishes where it is without needing "UK". Knowing that England/Wales/Scotland are in the UK is basic geography which we should not have to show readers in every infobox (if they do not know they can always look it up at their respective articles). The only possible exception would be Northern Ireland given that its status is variously described as a country, province or region. I would suggest adding a guideline on this to MoS. Regards  Spy-cicle💥  Talk? 14:07, 1 July 2020 (UTC)[reply]
    The most recent official denomination for NI is also "country", as far as I am aware, but it has the same status as Scotland and Wales nonetheless. Wales even used to be called a "principality" by the UK as recently as 2007.[10] We should treat all four constituent parts the same, IMO. IceWelder [✉] 14:18, 1 July 2020 (UTC)[reply]
    Legally they are all constituent countries. Northern Ireland has, historically, had more devolved power than Scotland. Currently, there are various differences still, though I wouldn't call it 'more' devolved. Both certainly have more local authority than Wales, though. But indeed, from a MOS standpoint, they should be treat the same. Though some readers may confuse Northern Ireland as being part of the Republic rather than the UK, similar confusion could be had for other constituents too (as to whether they're independent or not), for which the "if they do not know they can always look it up at their respective articles" advice applies. I can't imagine it would be proper for Northern Ireland to retain a different MOS guideline to the rest of the UK in this matter.
    If we're being perfectly honest here, many readers don't really know how the UK is made up of constituent countries, or the difference between England and UK etc (many believe the two are interchangeable). So, I don't think we're adding or reducing any confusion by this guideline, for the purposes of the UK.
    Editors should remember that we serve a worldwide audience, though, not just a Western one. This is the same issue with not suffixing "United States" (or U.S.) in infoboxes for some U.S. related articles. Many Americans can't even name all their states, never mind people across the world. The sovereign country should always be mentioned imo, an abbreviation may be acceptable for the US and UK. The same issue exists for UAE's emirates. Should UAE be omitted after Dubai? Maybe. How about after Umm Al Quwain?
    My opinion: let's just be consistent. Where there is a strong, well-recognised devolved authority (constituent country, emirate, state, whatever) we include that as well as the name of the sovereign country. We're not really "wasting space", and it does clear up confusion. ProcrastinatingReader (talk) 16:45, 1 July 2020 (UTC)[reply]
    But the point is that there is no confusion. This is the English Wikipedia, not the Simple English Wikipedia. Nearly all educated people are aware that Wales is part of the United Kingdom, California is part of the United States, etc. We don't write for the lowest common denominator because Simple English Wikipedia was created for that purpose. --Coolcaesar (talk) 16:58, 1 July 2020 (UTC)[reply]
    I have no opinion on the topic of this section, but as a Brit who's lived in the US (Texas and Long Island) for over thirty years I am quite sure you're too optimistic about "nearly all educated people". (And that's a relatively easy question; ask for the difference between Great Britain and the British Isles and you'll really get blank stares.) I work in IT and would guess that most of the few dozen people I've had that conversation with over the years had degrees; less than half knew the relationship between, say, Scotland and England, or England and the UK. Mike Christie (talk - contribs - library) 17:02, 1 July 2020 (UTC)[reply]
    What Mike Christie said. The English Wikipedia targets a worldwide, general audience of literate people, not just "educated people". Even many "educated people" (assuming educated means passed high school, or has a degree) are unaware of the differences. The idea of constituent countries is foreign to many. Anecdotally, I've met many people across Europe with degrees who use England and UK interchangeably. They know Scotland exists, perhaps in their head they view it as a state, but they wouldn't really be able to say with confidence what the relationship is between each.
    One doesn't study British history in most areas of the world. You can be totally literate and educated and not know this. Wikipedia isn't an academic journal, it's one of the largest sites on the internet and the featured result from Google on topics we discuss. Someone wants to learn about Beyoncé, Google gives them a convenient snippet of our lead plus a "Wikipedia" link. ProcrastinatingReader (talk) 17:35, 1 July 2020 (UTC)[reply]
    I agree. That someone who is sufficiently educated and fluent in the English language to read and contribute to the English language Wikipedia would necessarily know anything about UK geography and government is a faulty assumption. There are hundreds of millions of English speakers around the world with zero ties to the UK, and no need to ever deal with the place. The idea that all English speakers should know about Britain is, frankly, arrogant. We have no reason to make that demand and not add two bloody letters to the infobox. oknazevad (talk) 03:55, 2 July 2020 (UTC)[reply]
    This just reads like WP:OR. You do not need to study British history to know that England, Wales, Scotland, and Northern Ireland are part of the United Kingdom. Moreover, think about what the parameter is being used for location. Most people know where England, Scotland, etc are located. We do not need to explain they are a part of the UK on every single infobox, that is what the country articles are for. If readers are still unsure of where they are located they can click on the link to the specific location e.g. Milton Keynes links to England and the United Kingdom or readers can use the search bar. Remember this is English Wikipedia not Simple English Wikipedia. Regards  Spy-cicle💥  Talk? 16:23, 2 July 2020 (UTC)[reply]
  • The other relevant guidelines are MOS:INFOBOXPURPOSE and MOS:INFOBOXGEO. These offer advice to keep information succinct and to use informal names, short forms or abbreviations where doing do would not lose any significant information. Infoboxes are, by their nature, short on space and if we don't need to write "UK", we should omit it; similarly there's no case for ever writing "United Kingdom" in an infobox or for writing "Kingdom of the Netherlands" when "Netherlands" serves the same purpose. --RexxS (talk) 17:30, 1 July 2020 (UTC)[reply]
    Rexx, (maybe you know this, but) Kingdom of the Netherlands (political) and Netherlands (geographic and political) are not the same thing - from Kingdom of the Netherlands: "The four parts of the kingdom—the Netherlands, Aruba, Curaçao and Sint Maarten—are constituent countries (landen in Dutch) and participate on a basis of equality as partners in the Kingdom ...." I agree we never need to use both one after the other, but there are times when one is appropriate, and times when the other is. It's like "England, UK" etc, but even less likely to be well understood by many readers from the other side of the world. Johnbod (talk) 14:49, 2 July 2020 (UTC)[reply]
    Yes I knew, John, but the point of MOS:INFOBOXGEO is that it's okay to use informal names as long as we don't mislead, and that's especially pertinent in infoboxes. If there's a need to refer particularly to the Kingdom of the Netherlands, a piped link – [[Kingdom of the Netherlands|Netherlands]] would be perfectly reasonable (i.e. not an "easter egg"). --RexxS (talk) 15:04, 2 July 2020 (UTC)[reply]
    Personally, I think seeing just "Curaçao, Netherlands" is easter-eggy. Johnbod (talk) 15:40, 2 July 2020 (UTC)[reply]
    Surely that would only be the case if someone was surprised that following the link in "Curaçao, Netherlands" took them to Kingdom of the Netherlands. I can't imagine anybody being surprised by that. --RexxS (talk) 16:58, 2 July 2020 (UTC)[reply]
    It's not only about surprise per se. The principle is that information that should be in visible text should not be hidden in the choice of target for a piped link. (This is part of why piped links are generally bad; like goto statements there are reasons to use them, but only for very specific reasons.) I personally was not aware that there was a distinction between "Netherlands" and "Kingdom of the Netherlands" before reading this discussion, and I would indeed have been surprised for the link to take me somewhere other than Netherlands. In summary, in this case, "Kingdom of the Netherlands" should be spelled out in visible text, and not hidden behind a piped link. --Trovatore (talk) 17:37, 2 July 2020 (UTC)[reply]
    (I looked at a little more of the context of this discussion and I want to clarify what I said. I don't mean that we necessarily need to mention the Netherlands at all, when including Curaçao in an infobox. Just saying Curaçao may well be sufficient, if the island's political status is not of great importance to the topic of the surrounding article. What I object to is the piped link [[Kingdom of the Netherlands|Netherlands]], which I think codes information into the choice of target of a piped link, something we should avoid. Either spell the information out in visible text, or leave it out.) --Trovatore (talk) 07:17, 3 July 2020 (UTC)[reply]
    "'GOTO Considered Harmful' Considered Harmful". EEng 18:13, 2 July 2020 (UTC)[reply]
    • The "if we don't need to write" argument could apply to any level of location. If that was the simply applied criteria, we wouldn't need to include anything after "London" in relevant articles. CMD (talk) 06:14, 2 July 2020 (UTC)[reply]
      • @Chipmunkdavis: The "if we don't need to write" argument could apply to any level of location. Yes it could, and does. It all depends on what you think the audience is most likely to understand from the context. In the article England, the capital is given as London. That's fine, because the location of London in England can be assumed by most readers. In other contexts, it may be less obvious and we might write "London, England". I don't think anybody has yet found a context where "London, England, UK" would be needed. The point remains that we keep the location as short as possible in infoboxes, consistent with unambiguously supplying key information. --RexxS (talk) 12:38, 2 July 2020 (UTC)[reply]
        • I don't think the England infobox relates much either way to infoboxes locating very specific buildings/locations. In terms of conciseness, "London, UK" is even shorter and as unambiguous. "London" alone again more so. CMD (talk) 12:46, 2 July 2020 (UTC)[reply]
          London's probably not the best example because it's a special case. Why not stick with Milton Keynes? EEng 12:51, 2 July 2020 (UTC)[reply]
          London is a fine example of the principle of "just enough and no more" in infoboxes. New York would have similar considerations. --RexxS (talk) 15:04, 2 July 2020 (UTC)[reply]
          But just "New York" is ambiguous, as it can also refer to the state. There's a reason the article on the city is at New York City. oknazevad (talk) 15:48, 2 July 2020 (UTC)[reply]
          RexxS, I personally agree, but a concern I raised with EEng on his talk was that I'm biased from a Western viewpoint, and we have an international audience of readers. "London, England, UK", "New York City, New York, US", and "Dubai, Dubai, UAE" look pretty silly. I think the state/constituent country/etc should be omitted where omitting would have no loss of meaning. But I think the country should still be kept strictly in abbreviated form (if a well known abbreviation exists), so "London, UK", "New York City, US" and "Dubai, UAE" (3rd is slightly confusing, as it's unclear if it refers to city or emirate, but meh). There are other cities a reader should be reasonably familiar of country, like Shanghai, but I would still bet many Western readers don't know it's in China, so I'd find "Shanghai, China" appropriate. We can't have one standard for popular Western cities and another for Asian ones. Adding 2 letters isn't wasting space, doesn't look silly imo, and it's consistent and most informative. ProcrastinatingReader (talk) 16:07, 2 July 2020 (UTC)[reply]
          @Oknazevad: I know "New York" is ambiguous, and that's why I wrote [[New York City|New York]], which doesn't refer to the state.
          @ProcrastinatingReader: But we can use "London" and "Shanghai, China" as part of the same standard if that standard is "the shortest that readers will recognise". We think that most readers would know that London is in England, but the same wouldn't apply to Shanghai. This is still the English Wikipedia. As for writing "London, UK", it looks very strange, imho. The country that NYC belongs to is the US, but the country that London belongs to is England. We would similarly write "Glasgow, Scotland" and "Belfast, NI".
          It is indeed the English Wikipedia. English as in the language, spoken by many around the world, and our readership isn't exclusively western. I'm strongly opposed to any exceptions Western countries get to inflate some egos and act like everyone in the world should know where their cities are. It's two letters, just suffix "UK" and keep it consistent. There's no good reason to omit. ProcrastinatingReader (talk) 01:04, 3 July 2020 (UTC)[reply]
          The special case was the point as I was discussing the concision argument. For Milton Keynes, "Milton Keynes, UK" would probably be the shortest well-recognised format. CMD (talk) 16:19, 2 July 2020 (UTC)[reply]
          My point was that the piping renders the link ambiguous. There's nothing incorrect or uncommon with using "New York City" unpiped.
          As for the use of "London, UK" vs "London, England", the former is analogous to using "New York City, US", while the latter is analogous to "New York City, New York". The idea that England, Scotland, Wales, and Northern Ireland are comparable to the overarching sovereign state and not provinces/states/other subdivisions in other countries is the issue. It's an assumption that all readers are familiar with the structure of the UK as a country (and by all objective definitions of the word it is a country, even if it's subdivisions are also known as countries for historical reasons). I don't think we can make that assumption for a worldwide audience where there's hundreds of millions of native speakers and those who have learned the language because of its status as the main international Lingua Franca of the day with zero connection to the UK. Indeed, I always find that assumption outright off-putting. oknazevad (talk) 17:34, 2 July 2020 (UTC)[reply]
          I disagree that piping renders a link ambiguous. Anyone uncertain about the meaning of a term only has to follow the link to have that uncertainty removed. All disambiguation works like that.
          "London, UK" simply is not analogous to "New York City, US" because the country that London belongs to is England, not the UK. A football player born in NYC can play for the USA Soccer team; a player born in London may play for the England football team, but not the UK football team because it doesn't exist. There are no "provinces/states/other subdivisions" in other countries that are comparable to England, Scotland, Wales and Northern Ireland, for historical reasons. I don't accept that English has "zero connection with the UK", or with England, for that matter. The cultural background, history, legal system, monarchy and institutions belonging to the home countries has had a profound impact on the language, at least as great as that of any other English-speaking country, and it's frankly ridiculous to think that anyone learns English without becoming aware of that impact. --RexxS (talk) 21:45, 2 July 2020 (UTC)[reply]
          Links don't "remove ambiguity" because you must never ever ever assume someone is going to follow a link. Piped links for disambiguation are OK only if it's obvious where the link is going. --Trovatore (talk) 00:15, 3 July 2020 (UTC)[reply]
          RexxS, just so I'm not misinterpreting you here, are you saying it's ridiculous that people learn English and don't learn about the cultural background, history, legal system, monarchy and institutions of the United Kingdom? And if so, and assuming it is ridiculous, does that mean we should expect our readership to know all of these things, and to force that down their throat we should omit the UK? Do we learn about the same of China, Germany, Switzerland, Hong Kong, India, etc.? And, as you will know from teaching in schools, many UK students also don't know any of these things. The concept of 'constituent country' and the legal background of this alone is foreign, beyond elementary understanding, to the majority of people under the age of 25, never mind all the other stuff you mentioned. Also, comparison to football teams is a bit shocking, because football teams aren't governed by any international treaty standard but instead by an organisation which creates identities mostly based on patriotism. UK is the sovereign country. Infoboxes should refer to the sovereign country, not any smaller division, for 'notable cities' where subdivisions (like state, emirate, constituent country, etc) should be omitted. ProcrastinatingReader (talk) 01:10, 3 July 2020 (UTC)[reply]
          There are plenty of people within England itself who don't understand all this historical interplay and impact. Plenty of people learn English without learning much at all about the UK. Probably most people. CMD (talk) 01:57, 3 July 2020 (UTC)[reply]
          Sure, I've taught thousands of kids and every one of them knew that London is in England, NYC is in the USA, Paris is in France, and so on. Are the kids I taught in the deprived areas of England somehow smarter than those in the USA, in India, in Australia? I don't think so. I have a Belgian friend married to a Swedish woman, whose common language is English and their tri-lingual four-year old lad knows I come from England when I come to visit. Simple geography isn't rocket science. Why do you think we have MOS:OVERLINK? We don't link places like "Berlin; New York City, or just New York if the city context is already clear; London, if the context rules out London, Ontario; Southeast Asia" because we assume that our readers have at least a passing familiarity with those places, and don't need to read their article to find out where they are. We have the Simple Wikipedia that's aimed at readers who need a simplified version of Wikipedia; there's no need to dumb down this version to solve a problem that doesn't exist. --RexxS (talk) 09:13, 3 July 2020 (UTC)[reply]
          Knowing London is in the UK is not the same as knowing "the cultural background, history, legal system, monarchy and institutions belonging to the home countries". Even if it was, no, kids in England are probably not smarter than those elsewhere, but yes, they will know things about England and the UK that the children in the other countries do not. Those children will in turn probably know more about New York, Mumbai, and Sydney, than students in England. I really don't see what intelligence, or English language comprehension, has to do with it at all. CMD (talk) 15:48, 3 July 2020 (UTC)[reply]
    • And a what about an Olympian from London? There is no English Olympic team. Soccer is a special case, not general international definition of the term "country". oknazevad (talk) 22:48, 2 July 2020 (UTC)[reply]
  • The special pleading about who knows what is parochial, and just depends on who is speaking. Whatever we decide to do about pinpointing Accra, Goa, or Guangzhou, we should do with every other city including in the UK. The kid reading in Mumbai about Manchester, should get directly comparable info as the kid reading in Manchester about Mumbai. (Not to mention, the kid in Birmingham, and the kid in Birmingham)-- Alanscottwalker (talk) 22:14, 2 July 2020 (UTC)[reply]
    My point exactly. The English language may have its roots in England, and that may have shaped the language, but the language is spoken by hundreds of millions of people that have zero ties to the country. It's those people we have to serve as well. The mentality that speaking English means one should automatically know the geography of the country is rooted in the empire mindset. The English language no longer belongs to Britain, but to the world. oknazevad (talk) 22:48, 2 July 2020 (UTC)[reply]
    I have no ties to France, but I can read the French Wikipedia, and I know the geography of France well enough to know that Paris is in France, without being told. The kid in Mumbai reading about London is pretty unlikely not to know that it's located in England. --RexxS (talk) 23:18, 2 July 2020 (UTC)[reply]
    And if they are not in Mumbai but in Ontario? (Also, since Wikipedia is not about you, there is no point in you talking about yourself.) Alanscottwalker (talk) 00:41, 3 July 2020 (UTC)[reply]
    Why not "..., England, UK, Earth, Solar System, Milky Way? Who needs both "England" and "UK"? Keep it short. Tony (talk) 05:47, 3 July 2020 (UTC)[reply]
    Just to be clear: We’re (or, at least, I’m) not arguing for England and UK, but simply UK. The name or common abbreviation of the sovereign state should always be used.
    Tony1, You are Nigel Molesworth and I claim my five pounds. Guy (help!) 12:17, 3 July 2020 (UTC)[reply]
    Short? That leads to either, just, UK, or just, Eng., even if one truly but oddly thinks, England, UK, is terribly long. Besides which, whether England and UK need each other is a matter of deep politics or civil war. -- Alanscottwalker (talk) 12:47, 3 July 2020 (UTC)[reply]
    I can assure you that most everyone in Canada knows than London is in England. London, Ontario, is almost universally referred to as London, Ontario, unless you're within the city boundaries, and even then qualification is common. pburka (talk) 20:27, 29 August 2020 (UTC)[reply]
  • Adding the individual countries of the Union is completely pointless. There is only one Milton Keynes in the UK, we do not need to clarify that it's in England, though I can see why Scottish editors would want to be cleare that it's nothing to do with them. Guy (help!) 12:12, 3 July 2020 (UTC)[reply]
  • Keep it simple, the UK is the sovereign country, we don't need to bother with whether a place is also in E, NI, S or W. -- DeFacto (talk). 12:38, 3 July 2020 (UTC)[reply]
    • Keeping it simple would be procrustean (word of the day, thanks Eeng). England, Scotland, Wales and Northern Ireland is sufficient. Nobody says "I'm from the UK". They compete in the Olympics as Britain. Other major international sports like rugby and football are represented by England, Wales, etc. --Cornellier (talk) 23:47, 4 July 2020 (UTC)[reply]
  • Of course, this will all unravel when Scotland and Northern Ireland leave the union. Tony (talk) 08:03, 4 July 2020 (UTC)[reply]
  • comment I didn't think this topic would snowball into the discussion that it has! I don't find myself any clearer as to whether or not removal of the sovereign state of the UK from the location field in the infobox is valid or not. I just edited the Heathrow Airport article adding England and had it reverted by another user stating in their edit summary I think having it as London, UK (as the sovereign state rather than London, England is more suitable here. by User:OcarinaOfTime [11]
    Angryskies thanks for the ping - I will of course go with consensus on this issue once this emerges but my view is that for a major piece of national transport infrastructure like Heathrow, it's more relevant to the whole UK, not just England. OcarinaOfTime (talk) 11:56, 9 July 2020 (UTC)[reply]
    Infoboxes should contain one of suburb or city, and country, e.g. Hounslow, England or London, England. No need for suburb and city, country / state or crown dependency. Jeraldshield (talk) 05:45, 10 July 2020 (UTC)[reply]
  • It does depend on circumstances, and editors should give up on the idea of trying to impose consistency over this - but there are never any circumstances in which "England, UK" is the way to go. One or the other... depending. Ghmyrtle (talk) 08:52, 10 July 2020 (UTC)[reply]
    The question I asked, is should it be removed, if it was already in the article or if added, it should be removed. There is no policy so this is why it is confusing. Jeraldshield has said there is no consensus for having UK in the location box, and has removed UK from the FirstGroup article, despite it being in place for over a year and is accusing me of edit warring. So it is an issue that some consensus should at least be made to avoid edit wars. — Preceding unsigned comment added by Angryskies (talk • contribs) 12:46, 12 July 2020 (UTC)[reply]
    Since none of these is incorrect – Milton Keynes, England / Milton Keynes, UK / Milton Keynes, England, UK – anyone changing one to the other is simply out to cause trouble. Often for political reasons. Anyone who does it a lot, and there are editors in this discussion who do it a lot, should be blocked. Trying to impose consistency is without consensus, futile, unnecessary and almost certainly due to some ulterior motive. Nobody is that anal as to find it a problem unless they have a particular personal beef. Bretonbanquet (talk) 12:58, 12 July 2020 (UTC)[reply]
    Well, a very narrow topic-ban would be more appropriate than a block, and either result would need a well-diffed showing of doing this robotically without regard to disruptive fallout, or doing it in a targeted, politicized manner guaranteed to cause disruptive fallout.  — SMcCandlish ☏ ¢ 😼  03:24, 15 July 2020 (UTC)[reply]
  • Always found it frustration, how the United Kingdom seemingly gets special treatment in this area. Very few would complain about "Portland, United States" or "Portland, Oregon, United States"; "Winnipeg, Canada" or "Winnipeg, Manitoba, Canada". BUT, "Liverpool, United Kingdom" or "Liverpool, England, UK"? oh my goodness. GoodDay (talk) 15:51, 29 August 2020 (UTC)[reply]
It’s odd that you should say that, because I see the US getting treated differently. For the rest of the world it’s usually ‘place, country’ whereas for the US it is often ‘place, state, country’. ‘Place, country’ should be sufficient; most of these references are blue-linked so anyone either interested or ignorant is only one click away from the full info, anyhow. One thing to be aware of is that there is a group of IP editors systematically changing UK/Britain to English/Welsh/Scottish - particularly noticeable on biographical pages - and my unsubstantiated guess is that this is being driven by the Scottish independence campaign and a wish to establish England/Scotland as separate entities ahead of time. I don’t know whether this has been raised elsewhere in talk but my view would be that WP sticks with official nationality (whilst doubtless continuing the special treatment for the US, it obviously being critical that readers realise that Badiddlyboing is in Odawidaho rather than just the USA). — Preceding unsigned comment added by MapReader (talk • contribs) 17:12, 29 August 2020 (UTC)[reply]
"Portland, United States", "Vancouver, Canada", "Kiev, Russia, Ukraine", "Sydney, Australia", may get some opposition. But nothing compared to the opposition in the British bios. GoodDay (talk) 17:27, 29 August 2020 (UTC)[reply]
(um... Kiev isn’t in Russia. It is the capital of Ukraine. Which makes me think we can not simply assume people know basic geography). Blueboar (talk) 20:30, 29 August 2020 (UTC)[reply]
Dang, sometimes we do get Russia & USSR confused :) GoodDay (talk) 20:33, 29 August 2020 (UTC)[reply]
The US is treated specially (by always specifying City, State except in the cases of a handful of cases such as New York City, Chicago, Los Angeles, San Francisco ...) because the US has the unusual condition of place names being routinely repeated in many or even most states. So Portland, United States would be absurd and meaningless -- see Portland#United_States. Not that I'm an expert, but I'm not aware of any other country where this phenomenon is found so extensively, probably because of (a) the country's rapid development over such a wide area and (b) the fact that, during most of that development, the apparatus of public administration was very decidedly concentrated at the state level, not the national. EEng 19:59, 29 August 2020 (UTC)[reply]
That’s a very US-centric comment, Mr Eng! It’s not unusual, at all; the UK has tons of repeated village names (try looking up Whitchurch). Indeed the link to Sandy Balls below, which I had never heard of, throws up a second Godshill to add to the one I know. The difference, if there is one, is that few of the UK’s repeated place names are settlements of any size, and where they are, they are often differentiated along the lines of Kingston-upon-Hull (routinely called just Hull) and Kingston-upon-Thames, similarly for two of our Newcastles, etc. MapReader (talk) 05:22, 30 August 2020 (UTC)[reply]
As I understand it, there's little resistance to having United States or US included, though. For example: Very few would object to "New Orleans, Louisiana, US", but many would object to "Edinburgh, Scotland, UK". GoodDay (talk) 20:03, 29 August 2020 (UTC)[reply]
Well speaking as an American I think both the US and the UK should be included (speaking now only of infoboxes). See my post a little bit down from here. EEng 22:32, 29 August 2020 (UTC)[reply]
  • This issue has come up again today in edits to the article of a fairly obscure British singer, here. I've raised the issue on the talk page of the editor concerned, here, but don't seem to be making much progress. It's tiresome and frustrating. Can we please agree, in guidance, that in infoboxes and introductory sentences, it is only necessary to include either "England" or "UK" for placenames, and not both. It may simply be a WP:BRITENG issue, but in British articles one or the other, not both, should apply. Ghmyrtle (talk) 18:38, 29 August 2020 (UTC)[reply]
    We should be using UK only, in that case. But I'm a realist about this topic & have a darn good idea of how using UK only, will be received. GoodDay (talk) 18:51, 29 August 2020 (UTC)[reply]
    My view is that, as the sovereign state, "UK" is essential (unless the time in question was before the UK was formed) in the international context of this encyclopaedia. England, Northern Ireland, Scotland or Wales are redundant, but could be used alongside "UK" if the context warrants it, and there is a consensus to include it. -- DeFacto (talk). 19:11, 29 August 2020 (UTC)[reply]
    The specific issue I am dealing with, is whether an infobox should state a birthplace as "Bermondsey, London, England, UK". I say it should not - it should be one or the other. I actually don't mind too much if it's England or UK - but not both. Ghmyrtle (talk) 19:23, 29 August 2020 (UTC)[reply]
    Ghmyrtle, I'd prefer it with UK and not England, but - if 'England' is important for some other reason - England, UK. But never just England. -- DeFacto (talk). 19:38, 29 August 2020 (UTC)[reply]
  • Anecdotal, but I just saw a video on YouTube where an expat Englishman (who has lived in the US for about five years) tried to put all the state names on a map of the US... I was not surprised that he could not place them correctly, but what DID surprise me was that he said that he had never heard of a state named “Rhode Island” before. This taught me that we can not assume people know things about the world that we take for granted. We can not assume that people know the constituent parts of the US, the UK, or any other nation. There are likely to be people who DON’T know that England is part of the UK. Our job is to educate them. Blueboar (talk) 20:30, 29 August 2020 (UTC)[reply]
  • Always include "United Kingdom" or "UK" The United Kingdom is not special: it's [city], [administrative division] (if those are used), [state]. ―Justin (koavf)❤T☮C☺M☯ 20:44, 29 August 2020 (UTC)[reply]
    By state you mean sovereign state? EEng 22:32, 29 August 2020 (UTC)[reply]
  • Remember that this discussion is specifically about infoboxes. For article text blindly giving complete qualification (Portland, Oregon, United State) can often be awkward, so we have various (imperfect and controversial) rules for that. And for a long time I figured that infoboxes should follow those same rules. But I've come to realize (partly though discussion with ProcrastinatingReader) that infoboxes should give even the ill-informed reader information he can grasp at a glance, and that means erring a bit on the side of more rather than less. Therefore, even though guidelines call for article text to say Portland, Oregon, the infobox should say, Portland, Oregon, US or (yes) Dundee, Scotland, UK. A comma, a space, and two extra letters will help some small % of readers. EEng 22:32, 29 August 2020 (UTC)[reply]
    Past experience with this topic has made me quite skeptic, where the United Kingdom is concerned. "Cardiff, Wales, UK" or "Belfast, Northern Ireland, UK", would likely raised some hackles. If you & others can overcome the opposition? yas are a better man, then I. GoodDay (talk) 22:44, 29 August 2020 (UTC)[reply]
    and two extra letters will help some small % of readers that may be a dangerous assumption. ProcrastinatingReader (talk) 23:09, 29 August 2020 (UTC)[reply]

Well, what's the decision? GoodDay (talk) 18:23, 3 September 2020 (UTC)[reply]

State names in infobox field

There's a question at Talk:WRNN-TV#Location field that two other editors have (it briefly turned into an edit war) and I couldn't find anything in the MOS about this.

{{Infobox broadcast}} includes a location field to list the city of license and target market of a TV station. One editor thinks this field should read "New Rochelle, New York / New York, New York", and the other thinks it should read "New Rochelle/New York, New York". Should the state name be repeated more than once in listing cities in the same state or not? Raymie (t • c) 05:54, 2 July 2020 (UTC)[reply]

Avoid where it's clear to readers with an IQ above about 50. Tony (talk) 05:48, 3 July 2020 (UTC)[reply]
If it's two cities, they shouldn't flow over two separate lines. Mind, the infobox doesn't really explain what location means, especially when there is a separate city field. CMD (talk) 06:46, 3 July 2020 (UTC)[reply]
The discussion is at the linked page, not here. oknazevad (talk) 16:08, 3 July 2020 (UTC)[reply]
Go with the less redundant version, but use "New York City, New York" so it doesn't look like a copy-paste error. And there's no need to use a slash in here. So: "New Rochelle and New York City, New York". And as for "they shouldn't flow over two separate lines", we have no control at all over what the reader's font sizes are. Given that infoboxes are a fixed size but the text in them is resized at will by the end user (in system settings, browser settings, on-wiki user CSS, or all three), exactly where things may wrap should never be a factor in deciding what should go in an infobox, because it's just not predictable.  — SMcCandlish ☏ ¢ 😼  03:29, 15 July 2020 (UTC)[reply]
  • I would put the states in consistently. Consider cases where the station is located in one state, but the target market is a city in another (adjacent) state... say: Newark, New Jersey and New York, New York. Blueboar (talk) 20:37, 29 August 2020 (UTC)[reply]

Capitalization of "Black" when used as a race

AP and The New York Times among others are starting to capitalize "Black" when used to refer to the skin color or race. Should we add this to our MOS? - Jasonbres (talk) 23:56, 8 July 2020 (UTC)[reply]

Jasonbres, see Wikipedia_talk:Manual_of_Style/Capital_letters#Proposed_update_to_MOSCAPS_regarding_racial_terms. Discussion in progress. Schazjmd (talk) 00:19, 9 July 2020 (UTC)[reply]
Jasonbres, This would be a very big change and we should probably have an RfC on this matter. Note also that The New York Times explicitly does not capitalize "brown" or "white" but the AP are issuing a decision on "white" soon. Other sources are explicit about capitalizing "Black" but not "white" (e.g.) but remain silent on other things capitalized by the AP such as "Indigenous". Such a big change with so many variables will require community input on a large scale. See also, e.g. https://www.theatlantic.com/ideas/archive/2020/06/time-to-capitalize-blackand-white/613159/ ―Justin (koavf)❤T☮C☺M☯ 00:22, 9 July 2020 (UTC)[reply]
This one seems to have some NYT discussion on the subject, and I think I mostly agree with the first one. It might be that Black is an abbreviation for African-American, as, for example, it fits on protest signs. Probably unrelated, but the genetic diversity across Africa is much more than the genetic diversity of all the rest of the world, htough I suspect that the slave trade only used a small part of Africa. Otherwise, is Black supposed to include Africans visiting from Africa, or otherwise not Americans? As many have noted, even in the same sentence, brown is not capitalized. Gah4 (talk) 22:09, 10 July 2020 (UTC)[reply]
If one were to capitalize Black and White as stand-ins for generalized ethno-racial categorizations, then Brown should be as well, when used in that manner. But none of them should be capitalized when not used in this way, e.g.: "People with OCA-2 albinism do not have truly white skin, but effectively translucent, producing a pale pinkish hue." "Some of the villagers of Banaka are so dark-complected they appear almost pitch black except in bright sunlight." "Her Afro-Cuban cousin Mario is a darker brown than her siblings and other cousins." However, use of "Brown" in reference to non-Caucasian peoples is a bit of an informalism (it does not have anywhere near the saturation of "Black" and "White" in mainstream writing), so WP probably should be be using it in this sense anyway.  — SMcCandlish ☏ ¢ 😼  00:40, 15 July 2020 (UTC)[reply]

WP:ERA, MOS:STYLERET, MOS:RETAIN

Dear colleagues: This discussion, which began on my talk page, regards changes to an article's "era" style i.e. the choice of AD/BC vs. CE/BCE – see WP:ERA. EEng 21:57, 11 July 2020 (UTC)[reply]

It shouldn't be necessary but what to do about editors arguing that only those wanting a change need give arguments pertinent to the article? See Talk:Stonehenge which unfortunately is not the only place I've seen that argument. Doug Weller talk 18:49, 28 June 2020 (UTC)[reply]

OK, now I see. Hmmm. I hate to say it but I think that's the design, something like MOS:RETAIN. Now, RETAIN works pretty well in general -- do you think it might help to either import some of the RETAIN language into ERA, or maybe make ERA explicitly reference RETAIN as the way to make era decisions? (I say all this without thinking about it very much, so maybe there's a pitfall I'm not seeing.)
I'm sure you know that this probably won't be easy, no matter what. If you think this idea is a good one, why don't you do a bit of private analysis of ERA vs RETAIN, maybe tell me here what you're finding, and if it still seems like a good idea then we can talk about how to get key MOS elites quietly on board. EEng 20:03, 28 June 2020 (UTC) P.S. Just in case you missed it, you are officially listed at WP:CONFUSED.[reply]
Does MOS:STYLERET apply here? --A D Monroe III(talk) 21:58, 28 June 2020 (UTC)[reply]
Oh God, it's all coming back. MOS:RETAIN is about ENGVAR, whereas MOS:STYLERET is about style stuff in general. Or the other way around. My heart is starting to palpitate even now. Pardon me while I go lie down. Doug Weller, I'm still willing to walk this path with you, if (after reviewing everything) you think there's a feasible path to change. I'm going to ping SMcCandlish for his brief (BRIEF!) preliminary (PRELIMINARY!) thoughts. EEng 22:12, 28 June 2020 (UTC)[reply]
I admit that we don't ever have said anything about arguments against a change - apparently "I don't like the change" has always been seen as sufficient. The problem I have with this is that that's got nothing in common with the way we hold discussions elsewhere - it turns what should be a discussion into something where those in favor of change have to have reasons, those against just have to shout WP:RETAIN. In other words, a poll where the close can't do much more than count the numbers - it doesn't matter if those favoring no change have reasons specific to the article or not. If we did AfDs, RfCs, etc like this it would be a mess to say the least. I'm sorry that we lost "A personal or categorical preference for one era style over the other is not justification for making a change." along the way.
The other problem is the phrase "established style", which I've discussed before. Some editors believe that "established" doesn't mean a style established by a discussion, others that it means the original style unless there was a discussion agreeing to change it, so that even if it was changed 15 years ago that change did not make it the established style. The two together make change very difficult - era styles may be the hardest thing to change on Wikipedia, I don't know. Nor do I know how to change this particular problem. It would be easy to change the guideline so that arguments on both sides have to be based on the article, although that wouldn't make every discussion easy as for many even if the wording says that arguments need to be based on the article and not general issues what's most appropriate may not be obvious. I've seen editors argue that some Old Testament books are more important to Christians than to Jews, for instance.
Ironic that I've come here after reverting an editor who insisted that all articles should use BCE/CE (although they backed down) and insisting that they start a discussion. Doug Weller talk 17:55, 29 June 2020 (UTC)[reply]
I'm sorry, I'm not seeing in there whether you think it would be helpful to make the ERA guidelines more the RETAIN and/or STYLERET. EEng 18:42, 29 June 2020 (UTC)[reply]
Twice sorry, once for not answering your question directly, second for not answering it timely. Real life...
RETAIN's first sentence looks good, for ERA styles it would read "When an era style's consistent usage has been established in an article, maintain it in the absence of consensus to the contrary." Maybe I'm missing something, but I can't see why that's being used as an excuse to revert back to the original style just because someone changed it without discussion years ago. Do you? And I like "Sometimes the MoS provides more than one acceptable style, or gives no specific guidance. The Arbitration Committee has expressed the principle that "When either of two styles are [sic] acceptable it is inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change."[3] If you believe an alternative style would be more appropriate for a particular article, discuss this at the article's talk page " from STYLERET. I'd also like a simple sentence saying something like "Discussions should focus on the article in question, not personal preferences or principles." Doug Weller talk 14:42, 2 July 2020 (UTC)[reply]
OK, thanks. McCandlish hasn't edited since I pinged him above, so since there's no hurry (?) on this let's wait for his response. He'll know the secret history of how the guidelines got the way they are. EEng 15:03, 2 July 2020 (UTC)[reply]

@Doug Weller and A D Monroe III: Sorry, I've also been busy of late, what with the world being on fire. My semi-brief and not very preliminary thoughts: RETAIN is about ENGVAR; STYLERET is more general. ERA is pretty vague/flexible. My personal habits are to switch things to BCE/CE dating any time there is no connection to the history of Christendom, and I'm rarely reverted. If I get reverted, I don't fight about it, I just move on, though I may circle around in months or years and do it again and maybe get it to stick (not as a plan – I don't have a "hit list", I just may happen across it again and do my usual). If it pertains to the history/society of Europe, the Near East, or North Africa, and involves anything to do with 1 AD or later, I leave it at BC/AD, and may even impose it if there's a clear connection to Christendom and its history/background (but would not if there is not). Equivalent dates in some other calendar systems are also valid to include (as parenthetical conversions) in some cases (especially Islamic subjects). If it's purely a science topic, I use BCE/CE, since religio-cultural baggage isn't relevant. My reasons for these changes are "substantial" in ArbCom terms, though not necessary overwhelming. In my experience, there are rarely article-talk-page discussions about this stuff; it's a lot like citation formatting and date formatting. I might engage in such a thread if one arose, but I'm not on a warpath to impose this quasi-consistency, and am not inclined to argue about it much. [Everyone breathes a sigh of relief.]  — SMcCandlish ☏ ¢ 😼  22:19, 3 July 2020 (UTC)[reply]

This sneaky approach is exactly why Doug's "oh-if-it's-been-there-for-a-few-years-its-ok" approach doesn't work. Would you also apply this to ENGVAR, Doug? And if not, why not? But thanks for being so honest about your tactics, SMcCandlish. You seem to assume that all our readers actually understand BCE, which even in America isn't true, still less elsewhere, for example India - a tough case for the "I-stand-proud-against-oppressive-Christian-ideology" crowd (see the Stonehenge discussion for some stirring rhetoric along these lines). Johnbod (talk) 14:01, 5 July 2020 (UTC)[reply]
There's nothing "sneaky" about it, it just application of editorial judgement while gnoming around. If the topic has nothing to do with Christendom (or "Chistendom-embedded" topics like European and Near East history), then there is no reason to use BC/AD dating. It's not a matter of "oppression" but of cultural appropriateness, WP:Systemic bias, etc.  — SMcCandlish ☏ ¢ 😼  23:52, 14 July 2020 (UTC)[reply]
It clearly gaming WP:ERA to push your own POV, and sneakily returniung to do it again if reverted. And what about India, where the locals all use BC/AD unless they are academics writing for an international audience? What is culturally appropriate for articles about obscure Indian temples that no non-Indian is ever likely to look at, and where many of the actual readership don't understand BCE/CE, not being American? Johnbod (talk) 03:37, 15 July 2020 (UTC)[reply]
Is see nothing in MOS:RETAIN as vague or "flexible". If an article is (or was) all AD/BC, it should not be changed to BCE/CE without consensus, and vice versa. Editors changing this to their personal preference is explicitly what RETAIN prohibits. Right? --A D Monroe III(talk) 19:49, 4 July 2020 (UTC)[reply]
The only people who feel strongly about this issue are those for who it is a matter of religious identity (or lack of it). The rest of us may have mild preferences which may vary by article but if we relax the guidelines, we'll have endless repetitive ill-tempered mass warfare in which reasoned debate will be about as useful as a koala trying to stop a state-wide bushfire by widdling on it. If anyone feels like making the effort to tighten up the definition of "established style", that might be useful, I'd be happy to support it. I don't have any suggestions about what that tightened definition might be. Richard Keatinge (talk) 11:09, 5 July 2020 (UTC)[reply]
I disagree that the only people who feel strongly about this issue are people who consider it a matter of religious identity (or lack of it). I feel strongly about it, because it is a matter of accessibility (as I have said on the Stonehenge Talk page). But I agree that the purpose of the guidelines should be to avoid endless repetitive mass warfare. (I have no opinion on koala bears’ powers of extinguishment. ) Sweet6970 (talk) 12:48, 5 July 2020 (UTC)[reply]
Me too. Johnbod (talk) 14:01, 5 July 2020 (UTC)[reply]
I stand corrected! Nevertheless, I feel that the only changes to WP:ERA should be in the direction of tightening it. Richard Keatinge (talk) 12:54, 5 July 2020 (UTC)[reply]
RETAIN is about ENGVAR (about "varieties of English"); it is not about trans-dialect questions like BC/AD and BCE/CE. So all this waving around of it like a law is off-base (doubly, since it is a guideline not a policy, so it doesn't really "prohibit" anything at all). It's entirely reasonable to change from one format to the other to better match the nature of the topic (which really has nothing to do with "changing to their personal preference" – if we have editors going around changing everything to BC/AD or to BCE/CE, then they need to stop doing that). The actual reasoning behind ENGVAR, however, is sensibly applicable here, and not everyone in this discussion would be happy to do: if there's a strong national/cultural tie, (e.g. to European and Christendom history) then there's a plausible reason to use BC/AD, but absent one there is not.

It's more important and relevant to look at MOS:STYLERET: "it is inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change". If there's such a reason, then it's not against the guideline. The same section also suggests talk-page discussion first, but (as I've noted earlier) this rarely happens, and a guideline like this does not have the force of policy. MoS's own lead basically suggests the same things as a general matter for all style issues; not changing style without a good reason is part of the entire MoS, and is not specific to this or any other particular matter. Next, MOS:ERA: "The default calendar eras are ... BC and AD, and BCE and CE .... Either convention may be appropriate for use in Wikipedia articles depending on the article context. ... An article's established era style should not be changed without reasons specific to its content". It also suggests having a discussion first, but again this is not a requirement; even just basic WP:EDITING policy trumps it. We need to stop thinking and talking about this in terms that basically boil down to "Who can I punish for changing BC to BCE in my article?" WP just doesn't work that way. More to the point, MOS as a whole and STYLERET make it clear that a change for a good reason is permissible, and ERA even specifically states that the surrounding subject-matter content is such a reason.

MOS:ERA probably does need minor updating. E.g., it still says "AD may appear before or after a year (AD 106, 106 AD)", but there was a row about this semi-recently in which the conclusion was that there's no reason to continue using old-fashioned "AD 106" style. Using it an article with "106 BC" or "2nd century AD" style is apt to confuse readers or at least look inconsistent. It's certainly incompatible with the general MoS instruction to not mix different styles for the same thing in the same article (found in STYLERET, and MOS:US, and the main WP:MOS lead, among other places). If we were going to tweak any of this language, it should be revise that ERA line-item to say to use "106 AD" order in all four BC, BCE, AD, and CE cases (except where directly quoted material uses "AD 106" order).

 — SMcCandlish ☏ ¢ 😼  23:52, 14 July 2020 (UTC)[reply]

I follow MOS:STYLERET and WP:ERA. That said, my personal preference is to resist language changes connected to political correctness, so I'm going to use AD/BC in any article with no established style, and I'm not going to tell you what pronouns to use when you refer to me. And if you want to know which English honorific to use when referring to me, you may refer to me as "the honorable Jc3s5h". Jc3s5h (talk) 14:30, 5 July 2020 (UTC)[reply]

I'm not sure why you think it's condemnation-worthy to bring one's socio-political viewpoint to the matter, when you are simply bringing your own equal-but-opposite one. That's not standing on principle, it's simply being on the other side the very WP:BATTLEGROUND you pretend to deplore. You're basically stating in a WP:POINT-oriented way that you'd rather push your viewpoint than do what is best for the particular article context. As far as I'm concerned, that's sufficient grounds for anyone to revert you without discussion and use BCE/CE in any context in which it's a better fit, because your rationale for using BC/AD isn't based on logic but on a desire to stick it to your ideological enemies. Meanwhile, most people are not taking this as an ideological issue to begin with. It's simply a choice between international, secular, and culturally more neutral language. Trying to make it a religious dispute is silly, anyway, because even most biblical scholars think that the historical Jesus (if there was one) was born a bit earlier. The point at which this calendar system pivots has been arbitrary all along. While BC/AD make cultural sense on Wikipedia for various topics, they're technically probably misnomers.  — SMcCandlish ☏ ¢ 😼  23:52, 14 July 2020 (UTC)[reply]
@Johnbod: era style is not like WP:ENGVAR in that although ENGVAR doesn't say where a variety should be used, it links to WP:TITLEVAR which is clear - "If a topic has strong ties to a particular English-speaking nation, the title of its article should use that nation's variety of English". There's nothing like that for era styles, and you don't seem to think the word "established" has any meaning.
But I ran into something interesting today - well, not just me. Someone is using proxies going through articles changing BCE to BC - when reverted they return with a new IP address. Eg [12] [13] and [14] - I'm not the only Admin to notice it (fortunately the other Admin is more clued in about proxies and was able to confirm my suspicions. They seem random articles so I'm guessing whoever is doing this is using a search. Doug Weller talk 18:06, 5 July 2020 (UTC)[reply]
Few ENGVAR arguments involve the "strong ties" aspect, which tends to make things much clearer. Most revolve round "first use" issues, & are similar to ERA rows. It seems to me that you are the one who doesn't believe in "established" styles. it's no surprise there are people changing to BC - personally I seem to come across more doing it the other way, typically with edit summaries like "correct date" - like the Stonehenge guy in fact. Another persistent offender has turned himself in just above - I hope you give him a good talking-to. Johnbod (talk) 20:59, 5 July 2020 (UTC)[reply]

I enforce WP:ERA often. Which is clear on the matter. I don't really know if there is much else to do about it, or if there is even a need. It is a perennial problem. A centralized discussion by those who think otherwise and/or are in preference of one system versus the other, is always available. Who knows, maybe it's a discussion worth having. But probably not. El_C 18:20, 5 July 2020 (UTC)[reply]

I've just realised that there is another problem WP:ERA says "Apply Wikipedia:Manual of Style § Retaining existing styles" which says don't change existing styles without discussion. But it also says "An article's established era style should not be changed without reasons specific to the article", which is not the same thing. Does this mean that if an article had always had one style, but three months ago someone changed it without discussion, that the new style is the existing style so needs discussion before changing? "Do not change existing styles" is surely bad wording inviting editwarring. Doug Weller talk 08:21, 9 July 2020 (UTC)[reply]
I would say certainly not, but I think an undiscussed change for reasons of general preference takes far longer to become "established" than you do. I don't follow your last point at all - removing "Do not change existing styles" is a sure way to vastly increase edit-warring. Johnbod (talk) 08:46, 9 July 2020 (UTC)[reply]
Why? Surely ""An article's established era style should not be changed without reasons specific to the article" is sufficient? I'm not sure you're right about how long it takes to be established, but then there aren't any criteria. Doug Weller talk 18:28, 10 July 2020 (UTC)[reply]
No, it means don't change the style without reasons specific to the subject/content of the article. I'm not sure where you got the idea that has something to do with time spans. This "I was here longer" or "I was here first" confusion keeps coming up with regard to all the *VAR guidelines. People need to actually read them. The choice made in the first major contribution is only a last-resort fallback position, after all attempts to reach consensus have failed. It is not the default or preferred style, and whoever made it does not have more say. It only comes into play when someone wants to make a change and a subsequent discussion cannot come to consensus on whether to accept that change, to go with the current style (the one before that change), to go with some new third choice, to use the style that was longest used in the article, to use the first style used in the article, or any consensus at all. That would leave resolution in limbo indefinitely, so the forced resolution is to use the style in the first non-stub version (or the first non-stub version to have the applicable material).  — SMcCandlish ☏ ¢ 😼  23:52, 14 July 2020 (UTC)[reply]
He's got the idea from the wording of the policy: "An article's established era style should not be changed without reasons specific to its content". And one bit you need to read is (MOS:RETAIN "Edit-warring over style, or enforcing optional style in a bot-like fashion without prior consensus, is never acceptable." I've put a query for you above. Johnbod (talk) 03:45, 15 July 2020 (UTC)[reply]
  • There's nothing to talk about here, IMO; the "retain" policies are clear that such things are not to be enacted without a darn good reason (not to mention that BCE/CE is still based on the nominal date of Jesus's birth, but that's another thing), and nothing in the original talkpage or this discussion gives me reason to suspect otherwise. – John M Wolfson (talk • contribs) 04:40, 15 July 2020 (UTC)[reply]

RfC: Proper and improper use of monospace

Should one of the below § proposed guidelines be added to the Manual of Style?[note 1] Psiĥedelisto (talk • contribs) please always ping! 17:43, 14 July 2020 (UTC)[reply]

Proposed guideline Template:&numero

Withdrawn proposal

Below Wikipedia:Manual of Style/Text formatting § Font family, add the following:

Monospace

See also: Wikipedia:Manual of Style/Computing § Command-line elements

Monospaced fonts should be used only when necessary to avoid unnecessary overemphasis. Monospace should generally not be used when:

  • The context is not technical or computing related, and extreme accuracy in the characters of the text is not needed for another reason; readers can deduce it from context. While a simple computer program is liable to confuse lol with 101 or IoI or lullaby for 1u11aby, a human is unlikely to do so.
  • None of the possible characters could be confused for one another. For example, Unicode notation consists of a ⟨U⟩, a ⟨+⟩, and then between one and eight hexadecimal numbers (digits between 0–0 and F–16). As in no common font can any of the characters in the set U+0123456789ABCDEF be confused for one another, monospace is unnecessary emphasis.[note 2] So, write U+058D ֍ (<#salted#>), not U+058D ֍ (<#salted#>).

Notes

References

  1. ^ This is Psiĥedelisto's first RfC, so might have formatting errors. I hope it doesn't, I looked at a few examples...
  2. ^ If adopted, {{unichar}} will be changed to match consensus. See also Template talk:Unichar § Deviation of task, which is the seed of this IRC.

Proposed guideline Template:&numero

Withdrawn proposal

Same text as [[:#Proposed guideline Template:&numero|§ Proposed guideline Template:&numero]], just put on Wikipedia:Manual of Style/Computing instead. Psiĥedelisto (talk • contribs) please always ping! 17:43, 14 July 2020 (UTC)[reply]

Proposed guideline Template:&numero

Psiĥedelisto turned SMcCandlish's comment below into a proposal.

After the first sentence of Wikipedia:Manual of Style/Text formatting § Font family, add the following:

!votes

Discussion

  • @Psiĥedelisto: Can you provide some context please? Why is this enough of a problem that it needs to be added to the MoS? -- King of ♥ ♦ ♣ ♠ 18:05, 14 July 2020 (UTC)[reply]
    @King of Hearts: Sorry, I don't understand what you're getting at with this comment. Guideline Template:&numero was provided if you don't think it's important enough for the main MoS, but shouldn't every agreed upon style convention be in the MoS, especially if a new consensus would change a long-standing template like {{unichar}}? Psiĥedelisto (talk • contribs) please always ping! 18:16, 14 July 2020 (UTC)[reply]
    We could also put in the MoS "don't use Comic Sans," but we don't do that because it's unnecessary (WP:CREEP). What are examples of people incorrectly using monospaced fonts, such that the problem is important enough to have an official guideline against? -- King of ♥ ♦ ♣ ♠ 18:24, 14 July 2020 (UTC)[reply]
    @King of Hearts: Well, {{unichar}} is one example :-) Apparently, before {{char}}, {{code}} was being used many places it shouldn't have been. (Per Template talk:Char § I have doubts about this template). I would say this is a common mistake. Psiĥedelisto (talk • contribs) please always ping! 18:42, 14 July 2020 (UTC)[reply]
    We also don't need to put "don't use &numero; in MoS, either, since most editors don't do it. I do agree with the view, in an earlier discussion elsewhere, that we should not be applying monospace to characters and other strings that are being discussed as characters and other strings; MOS:WAW wants these in italics, or in double quotation marks if italics are already heavily used in the material for something else. An exception would be when a glyph is being discussed as a glyph per se (i.e., as computer output) or as a keystroke per se (i.e., as computer input). The <samp> and <kbd> elements exist for these cases and are already monospace. <Samp> is also used for various other forms of output, e.g. paths and filenames (output of a computer directory listing).

    This proposed new rule is too fiddly and too prescriptivism-based. If we needed an MoS line-item to address monospace at all, it should be advice to simply not use monospace other than for computer and other technical material for which it is customary – and leave it at that. If we start listing off exactly what it's okay or not okay to use it for, the list will simply grow and grow as more use-cases come up. It is actually customary in technical writing to put the hexadecmial Unicode codepoint designations in monospace. WP didn't invent that. The fact that it might not be utterly necessary for reader comprehension is irrelevant. Same goes for putting genus and species names in italics and capitalizing the genus. No one's brain would asplode upon encountering "homo sapiens" instead of "Homo sapiens", but the real world prefers it a particular way, and reputable publishers follow that preference in the main. Our general approach to all "optional style" questions (absent some Wikipedia-specific technical consideration) is that we apply a style if the vast majority of high-quality publications do it, and we don't otherwise. There's not any reason to stop using this WP:Common sense in the case of monospace/nonproportional font usage. Especially when various HTML elements (including <code>, <samp>, <kbd>, and <pre>) are monospace by default in all visual browsers. We would have to use custom stylesheet tricks to override that, which would confuse a lot of people, and in turn require re-doing various templates that use such elements and need the monospace to reintroduce it. And this isn't really about whether OCR can easily distinguish between 1, I, and l (though that matters for WP:REUSE reasons), it's mostly about the failure of various fonts used by human readers to clearly distinguish them. And it always has been, long before WP existed.

    [The only case I can think of in which WP has overridden the default behavior of an HTML element's font styling was eliminating the forced italics of <cite>, and we only did that because there's a dispute between W3C and WHATWG about what this element is. WHATWG is a mini-consortium of browser makers, and they want this element to mean the title of a work, while W3C is a macro-consortium of, basically, all the users of the Web, so W3C simply wins when they say this element is for citation information in general. It's why our template-generated citation tags are wrapped in this element and it doesn't do font crap. WHATWG's italics were wrong anyway, even if their scope limitation had been accepted by the Web development community, since minor works' titles go in quotation marks not italics.]

    Anyway, if we have anything about monospace at all as a general-rule matter, it belongs is MOS:TEXT along with the other font-style stuff. And it should be cross-referenced to any other sections that address monospace for particular uses (e.g. in MOS:NUM and MOS:COMP) MOS:COMP would not be a good home for a general rule, since the entire point of that rule would be discouraging use of monospace for things it is not appropriate for (i.e., things that probably will not be addressed by MOS:COMP). In the end, this is much like use of serif font in mathematical formulas (sometimes mandatorily for certain things). The average person might not feel they need it, but it is the way it is done, and we don't need to browbeat editors about it. Those with a maths background already know about it (and might or might not want a MOS:NUM rule to always use it in the mandatory cases, but otherwise just happy that our math markup tools do the serifs they're supposed to); meanwhile, those who don't know about this are not regularly abusing serif font styling in articles, so from an MoS perspective, there's no frequently recurrent, endless-arguments issue to codify an answer to. Same with monospace. We just don't have a continual, heated, unresolving series of arguments about its use.

    PS: I do not understand the footnote above that seems to be attributing this RfC to me. I didn't write it, and if I ever wrote something very similar, it is not what I would support now, on later and more detailed reflection.  — SMcCandlish ☏ ¢ 😼  21:58, 14 July 2020 (UTC)[reply]

    @SMcCandlish: Please kindly see [15]. I messed up, and it was not at all intentional. I thought that the magic word {{REVISIONUSER}} was automatically WP:SUBST'd. It's not, very sorry. I was too lazy to type/copy my ĥ. Won't happen again. Psiĥedelisto (talk • contribs) please always ping! 23:12, 14 July 2020 (UTC)[reply]
    Psiĥedelisto I edited the RFC to include your username instead of {{REVISIONUSER}}. It was still causing trouble even with safesubst. It's puzzling why you used such an roundabout manner to put your username in, but unimportant. I think everything is fixed now. Alsee (talk) 23:44, 14 July 2020 (UTC)[reply]
    Oh, ha ha. That useless magicword has bit me in the butt before, too.  — SMcCandlish ☏ ¢ 😼  00:30, 15 July 2020 (UTC)[reply]
  • @Psiĥedelisto: I have basically the same questions as King of Hearts above. There are many different kinds of RFC, but in in many cases it's a good idea to provide a little more background for people newly arriving. First, lets set aside {{unichar}}. (I'll get back to it.) What is the general background here, is there (A) one or more arguments over this issue that we are trying to resolve? If so, links and/or more info on previous debate please. (B) Is this a recurring issue that is regularly and uncontrovercially resolved in the way you suggest? If so, some sample diffs would be helpful. (C) Is this a new idea to change a singificant amount of existing conent? If so it would help to have some links or examples of what it is that we'd be changing. (D) Aside from {{unichar}}, are there few or no other particular cases and you merely propose this as a general good idea? We usually avoid bloating guidelines or MoS if there isn't any significant issue.
    Regarding template {{unichar}}, it looks like the parameter sans=y does what you want. Do I understand that correctly? That you basically want to make sans=y into the default or only mode? And if so, could you point to some pages that make significant use of this template to make it easier to review and consider whether that is a beneficial change? Thanx. Alsee (talk) 22:48, 14 July 2020 (UTC)[reply]
    @Alsee: Mojikyō was the article that made me decide that the way {{unichar}} worked was a problem. I was familiar with the Unicode standard and Unicode technical writing (I've been known to engage in it), so I knew that it's quite odd to use monospace when discussing the characters. It's less odd when discussing Unicode in a programming context. I added |sans=y while writing Mojikyō. I decided it should be default, and this was the way to get that done. I'm not aware offhand of other wrong uses of monospace. I've withdrawn my first two proposals and gone with SMcCandlish's instead. --Psiĥedelisto (talk • contribs) please always ping! 12:40, 19 July 2020 (UTC)[reply]
  • WHO IS USING "OUTSIDE OF"? On the outside of the tennis ball, yes. But not where "outside" is a preposition. Tony (talk) 07:52, 20 July 2020 (UTC)[reply]
@Tony1: see Merriam-Webster. Many compound prepositions seem to my ears to be growing in use compared to the single word synonym. It's possibly influenced by "out of". Peter coxhead (talk) 07:35, 21 July 2020 (UTC)[reply]

A discussion about collapsible elements in mathematics articles

I am very aware of MOS:COLLAPSE. In fact, I have removed collapsible elements on many occasions.

However, I'm also aware that we receive many complaints that our mathematics articles are too challenging to follow for many of our readers. As an OTRS agent, I've seen many such concerns expressed by readers. It's also ubiquitous enough in Wikipedia that the FAQ in WikiProject mathematics has several questions along this line.

I do know that we are not a textbook, and I support the position that we should not have all of the elements of a textbook in an article.

However, I also believe there is an important distinction between many prose oriented articles and mathematically inclined articles. To pick a sentence from Julius Caesar:

Leaving his command in Gaul would mean losing his immunity to criminal prosecution by his enemies; knowing this Caesar openly defied the Senate's authority by crossing the Rubicon and marching towards Rome at the head of an army.

Any reader with a high school level knowledge of English can comprehend this sentence. Expert historians might well believe that a deep knowledge of history would provide insights about that sentence beyond that picked up by the casual reader, but this is a matter of degree. In contrast, if our article on polynomials illustrated the product of polynomials as follows:

and

then

It would be a factual statement, one that a significant portion of the readership would not comprehend. While much of our adult readership covered this in a high school class, some weren't paying attention at the time, and some did pay attention, but have forgotten the details in the intervening years. If for some reason, they were now interested in multiplying polynomials, the short statement wouldn't provide much help.

Again, I'm not proposing changing the article into a textbook, but I think we can provide more help while falling far short of the exposition one might expect to see in a textbook. For example I'm not remotely considering a list of problems for the students intended to help them reinforce their knowledge.

In fact, the article did include a bit more; it contains one intermediate step. It's my belief that the reader is well served by adding a couple additional intermediate steps, which I have done recently. However, I recognize that I am treading closely to the line between encyclopedia and textbook, and I suspect there will be some pushback about including these intermediate steps.

We have several levels of readers of mathematical articles. At one extreme, we have people with mathematical degrees who may be using mathematics on a daily basis, and they may visit an article simply to recall exactly how something is expressed. We have other readers who may have a solid knowledge of mathematics, but haven't been actively using mathematics on a day by day basis, have reason to refresh their recollection of how something works, and want to see in Wikipedia what it has to say. Then there are some readers who may have covered this material in high school, but zoned out, or maybe even mastered it to some degree at the time, but have completely forgotten some of the basics. How do we write an article that addresses the needs of all of them?

One possibility is the use of collapsible elements (which explains why I am posting this in MOS as opposed to WikiProject mathematics.)

Imagine that we explain polynomial multiplication as follows:

If

then

which can be simplified to

In this example, the accomplished mathematician glanced at the introductory phase, know that they know how to do polynomial multiplication, glanced at the last sentence and moved on. The second group of readers who mastered this at one time but haven't looked at it in a while, might look at it in a little more detail and may not even click on the show button. Another group of people will look at it, click on the show button, and say to themselves "oh ye,s I remember this now" then hide it again and move on. Another group of readers might click on the show button and leave it open and walk through the steps.

The obvious point being that the use of a collapsible element allows us to do an exposition of this concept that can appeal to several levels of mathematical knowledge.

I just checked the mobile view, and it appears that the mobile view automatically displays the material, and encloses it in a labeled box. If this approach became ubiquitous, readers at higher level would know to skip over the material in the box and would not be disadvantaged.

I know that the prohibition on collapsed elements is a long-standing position, but it is equally long-standing that a substantial portion of our readership finds are mathematical articles close to useless. I think the use of a collapsible box, used judiciously, could be used to improve articles without a significant cost.--S Philbrick(Talk) 16:41, 19 July 2020 (UTC)[reply]

FWIW, I believe that collapsible elements are also sometimes used for proofs in mathematics articles, on the principle that most readers will not want to read a proof, but sufficiently many might that it would be a disservice to omit it entirely. --JBL (talk) 21:36, 20 July 2020 (UTC)[reply]
I agree with the OP's general thrust, except the "make it collapsed" conclusion. Collapsed content is an accessibility problem. I don't buy the argument that it's okay to make it collapsed because some will not want to see it. That's robbing Peter to pay Paul. Every article on every topic has material in it that isn't of interest to some readers of the article. We include it anyway to be complete, and all readers of this site already understand this. This "be complete, no matter what" principle begins right at the lead sentence. E.g.: "Elvis Aaron Presley ..., also known simply as Elvis, was an American singer and actor." The only fragments of that which will not already be known to 99.99% of our readers are "Aaron" and "and actor".  — SMcCandlish ☏ ¢ 😼  01:54, 22 July 2020 (UTC)[reply]
Paging David Eppstein. EEng 04:49, 22 July 2020 (UTC)[reply]
I'm not convinced that hidden elements (and the accessibility problems they raise) are ever really necessary. The better solution is to be more careful about the level of audience expected for an article in mathematics (or on any other technical subject): spell things out in detail when one would expect readers of this topic to need spelling out, don't spell things out in so much detail for articles that are anyway going to be hopeless for less-advanced readers. Many mathematical publications provide detailed proofs of their claims, but we should only provide those proofs when they are enlightening to readers, not as a mere verification of the truth of what we say, because Wikipedia is based on a different sourcing-based mechanism for verifiability. The same goes for steps of calculations. —David Eppstein (talk) 04:58, 22 July 2020 (UTC)[reply]
Well said.  — SMcCandlish ☏ ¢ 😼  13:48, 24 July 2020 (UTC)[reply]
I pinged him here so I deserve some of the credit. EEng 03:00, 25 July 2020 (UTC)[reply]
 — SMcCandlish ☏ ¢ 😼  03:39, 25 July 2020 (UTC)[reply]
An interesting question is what level of original calculation Wikipedia is allowed to engage in. For example, it is not WP:OR to convert units ({{convert}}), compute someone's birth year based on age attested in a dated RS ({{birth based on age as of date}}), or calculate the present value of historical currency ({{inflation}}). Where do we draw the line? When does a series of logical deductions go too far for WP:BLUE? -- King of ♥ ♦ ♣ ♠ 20:39, 23 July 2020 (UTC)[reply]
That is something that needs to be clarified, but it's off-topic for MoS, and is not directly involved in the formatting-and-presentation-and-access issue raised here. I would raise it at WT:NOR instead.  — SMcCandlish ☏ ¢ 😼  13:48, 24 July 2020 (UTC)[reply]
I'm also not convinced that hidden content is a good way to go. On the other hand, I also don't think it's possible in general to pick a right level of presentation for your readers. I can read a lot of technical stuff, but many math articles leave me in the dust because they're in an unfamiliar territory with unfamiliar language and don't go far enough in connecting to the basics that someone might have gotten from pretty good high-school and college level math classes. (and I just submitted by first attempt at a paper in the Proceedings of the American Mathematical Society in spite of not being a mathematician for real). Dicklyon (talk) 03:13, 25 July 2020 (UTC)[reply]
Until I recently removed it, {{math proof}} allowed for collapsing. Did you know of the template? :) My general opinion of anything related to collapsing in mainspace is that either a) you think the material is not actually necessary for the article and hence you should remove it (in general spirit of how we write our articles, such as WP:SUMMARY), or b) you think the material is actually necessary in which case it has no business being hidden away from the user. (This ignores the accessibility concerns of collapsing elements.) --Izno (talk) 15:21, 25 July 2020 (UTC)[reply]
To allow collapsing is probably okay, as long as it is off by default, and the documentation says to not make it collapsed in mainspace content. If people keep doing it anyway, then the solution is to install a namespace detection switch in the code, as we did with decorative quotation templates, to just disallow the behavior in mainspace. There are project- and user-space use cases for auto-collapsing the material, so just nuking the feature probably isn't a good idea. Same with various other templates that have this feature (track listings, sports results, etc.).  — SMcCandlish ☏ ¢ 😼  03:50, 8 August 2020 (UTC)[reply]

How to fix curly quotes?

As the header states, is there any quick/easy way to fix curly quotes being used in an article, or does it have to be done manually one-by-one? Asking this in regards to the episode summaries for All That (season 11). Thanks in advance. Magitroopa (talk) 18:51, 19 July 2020 (UTC)[reply]

I use the "source" editing mode and when that window is open, and the Advanced button is selected, on the far right is a "search and replace" button. There are probably other ways using other editing modes, but that one works. It must be used with care because it's possible for the curly quote to be part of a URL or a file name where replacing one with the other will mess things up. SchreiberBike | ⌨  19:04, 19 July 2020 (UTC)[reply]
Yep. Always compare what changed before saving. For my part, I do such cleanup in an external editing application which I can use more quickly (and which also has regex grep search/replace, which is useful for fixing various other things). I use BBEdit for this, in macOS, though there are good Windows and *n*x text-editing apps, too. I think there's a way to make all editing be done in such an app, but I only do this for tedious stuff, so I just copy the article code over, use my external editor, then paste it back in, preview to find or correct any obvious errors, and compare versions to pore over them one last time for inadvertent things like mangling a URL.  — SMcCandlish ☏ ¢ 😼  01:45, 22 July 2020 (UTC)[reply]

MOS:HEAD is ambiguous as to whether table captions and headers can contain links (and so is MOS:HEADERS). –LaundryPizza03 (dc̄) 15:26, 24 July 2020 (UTC)[reply]

What would lead you to believe that links are not allowed in table captions and headers? I do not see ambiguity, I simply see no comment on the matter. --Izno (talk) 16:53, 24 July 2020 (UTC)[reply]

Proposed addition to MOS:TEXT or MOS:WAW to codify some actual practice

Disputes about this stuff pop up not every other day, but frequently enough that they should be addressed.

Text of proposed addition:

A monospaced (non-proportional) font should be used only for strings of technical material for which this style is conventional in reliable sources. This is preferably done with {{kbd}} or the <kbd> element for input, and {{samp}} or <samp> for output, both broadly defined. When writing about a character as a glyph or codepoint in a digital communications context, it is often appropriate to use monospace, though characters as such should otherwise be given italics. When necessary to provide extended information about a Unicode character, use {{Unichar}}. Examples of direct user input (e.g. of a strong or weak password), can be rendered with {{kbd}}. Filenames, directory paths, URLs, and similar computer strings can also be rendered with {{samp}}. For illustrating an actual keyboard or controller key, see {{key press}} and related templates. Samples of computer source code should be rendered with the block template {{code}} if multi-line, or simply with the <code> element if inline in a sentence.

I'm normally resistant to additions at this late a stage in MoS's development (see WP:MOSBLOAT), but even WP:POLICY indicates that the purpose of guidelines is documenting actual WP best practices. My first instinct, in a previous discussion, was to just use the first sentence of this and leave it at that. But we have long-established templates for most of this, and should recommend their use, instead of leaving people to willy-nilly try to make up their own approaches to these matters.

I would prefer to shunt this into MOS:TEXT, though I suppose it could live in MOS:WAW (where we also address characters as characters in the broader sense). I am just leery of adding this to the main MoS page which is already long, and which should focus on the "frequently asked questions". In MOS:TEXT, it could have a heading of something like "Monospace, computer text, and key presses". And I'm not averse to various tweaking of this text; I just wrote it one go, though I've been thinking about it for a long time.

PS: The last sentence calls for using the bare <code> element inline in the sentence because the {{code}} template applies syntax-highlighting coloration, and we should not do that in the middle of a regular-text sentence, where it is distracting, over-emphasizing, and devoid of context. Syntax highlighting only serves a useful function when it is in a block of code, clearly distinguishing different code elements from each other in a pattern.
 — SMcCandlish ☏ ¢ 😼  22:41, 24 July 2020 (UTC)[reply]

Did you somehow miss #RfC: Proper and improper use of monospace where this issue is already being discussed on this very talk page? —David Eppstein (talk) 07:44, 25 July 2020 (UTC) (Actually from longer ago but I forgot to sign, sorry. —David Eppstein (talk) 07:44, 25 July 2020 (UTC))[reply]
I'm assuming that's the "previous discussion" he's referring to, which seems to have withered after 4 or so days of silence and not much support. Dicklyon (talk) 23:41, 24 July 2020 (UTC)[reply]
This might indeed be better-placed as a subsection of the above. --Izno (talk) 00:46, 25 July 2020 (UTC)[reply]
I thought about it, but this page is getting long despite the "aggressive" archive bot, and people are more apt to jump down here and see what's latest than pore over a long list of older threads, most of which are pretty moribund. A concrete proposal didn't emerge from that older discussion, so I'm making one here.  — SMcCandlish ☏ ¢ 😼  03:33, 25 July 2020 (UTC)[reply]
There is also the fairly quiet MOS:COMPUTING, which much of the above seems to target. I also would prefer this be in one of the subpages rather than the main page as the use of monospace is more esoteric than not these days. --Izno (talk) 00:46, 25 July 2020 (UTC)[reply]
Addressed in subthread below. There's unresolved history.  — SMcCandlish ☏ ¢ 😼  03:33, 25 July 2020 (UTC)[reply]

The fate of MOS:COMPUTING and MOS:COMPSCI

About two years ago (maybe three?), there was extensive discussion here about MOS:COMPUTING, and the consensus was that it is basically not salvageable and is not a guideline or a part of MoS, but just some essay that was controlled by two people making up whether they felt like. I proposed that "MOS:COMPSCI" (which is a WP:PROJPAGE essay, and not part of MoS either, though well-accepted and stable) should absorb any useful bits of MOS:COMPUTING before its formal deprecation with {{Failed proposal}}, but there was no consensus there to keep any of it at all. I think some bits and pieces of MOS:COMPUTING could be kept, and merged into other places, but it is long overdue to have {{Guideline}} removed from it, and probably moved to something like "Wikipedia:Manual of Style proposals (computing)" or something, so it is no longer part of the MoS tree. I'd meant to do that over a year ago myself but just forgot about it. Maybe we should just go do it, or maybe another discussion should happen, perhaps about keeping certain tidbits from it. And it would probably be worth discussing making the more sensible and consensus-based COMPSCI actually a part of MoS and not a wikiproject page.  — SMcCandlish ☏ ¢ 😼  03:33, 25 July 2020 (UTC)[reply]

IP editor correcting every inverted conditional they find

206.246.15.24 (talk · contribs · deleted contribs · logs · filter log · block user · block log)

They are determined to change every incidence ([17][18][19][20] etc.) of inverted conditionals they find to a phrasing starting with "if". They apparently think they are correcting a grammatical mistake. The conditional inversion actually sounds more formal and appropriate for an encyclopedia to my ear. Am I missing something? What's the best way to handle a problematic editor like this? —DIYeditor (talk) 17:53, 25 July 2020 (UTC)[reply]

This one was especially bad because not only did they "correct" something that wasn't wrong, they messed up the logic (tense) of the sentence. Maybe this is more into CIR/ANI territory. —DIYeditor (talk) 18:01, 25 July 2020 (UTC)[reply]

I would leave a note on that editor's talk page. BeenAroundAWhile (talk) 04:47, 4 September 2020 (UTC)[reply]

Guideline needed

Noticing a discussion on Talk:2040s, I followed the links to Wikipedia:WikiProject Years. There is a guide to writing a year-based article, but it needs transferred and fleshed out to the MOS since a long time. Seems straightforward, requiring some inclusion and other guidance added but format is already detailed with examples. ~ R.T.G 14:32, 1 August 2020 (UTC)[reply]

One idea for the COMMONALITY section: Footnote addressing usage in South Asian articles

I'd like to add a footnote to "Use universally accepted terms [...] ten million is preferable to one crore (Indian English)."

In South Asia-related articles one should use both British/American and South Asian numerals together, with British/American ones first and South Asian ones second if that is the convention followed in South Asian formal English language sources (such as government documents and newspapers like The Hindu and Dawn). This is because Indian numerals have become a feature of South Asian Englishes to the point where Indian/Pakistani/etc readers expect them, but one also needs non-South Asians to understand too.

South Asian sources in English tend to use lakh/crore with South Asian currencies (such as Indian and Pakistani rupees) but use the regular million/billion with foreign currencies like US dollars and British pounds.

  • 1 million (10 lakh) Indian rupees (conversions to foreign currency here)
  • 1 million U.S. dollars (no lakh here)

WhisperToMe (talk) 05:49, 3 August 2020 (UTC)[reply]

yes, I agree in principle, but wonder if we need to be so prescriptive. I remove these systematically and have never had any issues or complaints, only thanks. --Ohconfucius (on the move) (talk) 11:23, 4 August 2020 (UTC)[reply]
@Ohc on the move: If it's alright may I see an example of two of one of the removals? I'd be interested in seeing the context. Anyway I feel it's important to be a bit more prescriptive is that a lot of people from native English speaking countries aren't really aware of the situation in South Asia or why the readers from South Asia might want to see numbers in that format. The WMF is clearly wishing to get more Indian readers and India would be a major viewer and contributor source. WhisperToMe (talk) 07:48, 6 August 2020 (UTC)[reply]
@WhisperToMe: I do so many, and usually systematically, that I don't keep a record, nor am I able to find a historical example. However, this edit will give you an idea of what a typical edit looks like. As the {{INR}} template is widely used, the job is made a lot easier. I'm less able to remove in-line occurrences on a large scale because text usually is more tricky to treat; citations are always left alone. -- Ohc ¡digame! 08:09, 8 August 2020 (UTC)[reply]
I think MOS:TIES would apply in that case, and it could be written as "10 lakh (1 million) Indian rupees".—Bagumba (talk) 09:25, 6 August 2020 (UTC)[reply]
It should be the other way around: Write for the larger number of readers. It's a fallacy to suppose that Indic peoples who use English fluently/regularly do not understand "million".  — SMcCandlish ☏ ¢ 😼  03:46, 8 August 2020 (UTC)[reply]
It's not like a currency conversion, and I don't see any real reason to glose the terms in such a way when there are ways of expressing it in plain English. -- Ohc ¡digame! 08:09, 8 August 2020 (UTC)[reply]
If the statement in the OP is accurate, that Indian numerals have become a feature of South Asian Englishes, then I would think this is an ENGVAR issue and the convention followed in South Asian formal English language sources should be followed in the relevant articles. I do not see a reason to treat South Asian Englishes differently from any other ENGVAR. Newimpartial (talk) 10:55, 8 August 2020 (UTC)[reply]
MOS:TIES says to use the "English of that nation." It's not that Indians do not understand "million". The MOS does not say that MOS:COMMONALITY has greater weight.—Bagumba (talk) 11:30, 8 August 2020 (UTC)[reply]
I don't think anyone is saying that Indians do not understand "million". I'm sure most residents of the UK now understand "truck" as well. But if official sources (like governments and newspapers of record) use a certain format as part of their variety of English, then WP should do the same where that variety of English applies. Newimpartial (talk) 11:37, 8 August 2020 (UTC)[reply]
Fallacious reasoning. The government and newspapers of India are writing for Indians; WP is writing for everyone who can understand English, including when writing about India. It's also incorrect to suggest that krore is "a feature of South Asian Englishes" as a blanket statement. It's a feature of some South Asian Englishes. Both extremes on this are, well, extreme. WP has no reason to completely suppress krore, any more than we do to suppress inches in articles about the UK, etc. But per MOS:NUM, krore should be converted, and per WP:COMMONALITY, the internationally understood system should be used first and krore provided as the conversion, in articles about places in which krore is actually used by a substantial portion of the population. WP:ENGVAR doesn't enter into this, because a) that rule applies when MoS has no reason to care which version is used (color versus colour, etc.), yet we do have a strong reason to prefer numbering systems understood by nearly everyone; and b) krore is not at all used in India exclusively or near-exclusively; it's preferred by some people there for some contexts, and even many Indian publishers provide conversions to the more broadly understood system, unless they are local-oriented publications who do not expect many non-Indian readers. So, it is neither a integral and necessary part of Indian English (like the u in colour is in British English), nor a "six of one, half-dozen of the other" concern for MoS and WP; writing for more readers is clearly the preferable option.  — SMcCandlish ☏ ¢ 😼  21:33, 24 August 2020 (UTC)[reply]

Colons and footnotes

​ Today my reading of two article sections was obscured, made more difficult that is, by footnotes that followed a colon. The footnotes made me read the colon as a period, which it wasn't, and even while the colon was obviously (which I saw later) meant to open a quote, I was confused for some long seconds. I think the footnotes should follow the quotes, not the colons, so I edited [21] and [22]. I am convinced I did the right thing there, but the corrected way of placing footnotes might be quite common, so I thought it might be worthwhile to add a few words on this at Wikipedia:Manual_of_Style#Punctuation_and_footnotes. If someone has an idea how to, please do so. Or of course just discuss the subject here. Greeting, Eissink (talk) 22:06, 16 August 2020 (UTC).[reply]

References and colons

In the Punctuation and footnotes section, Eissink has added Ref tags do not follow a colon. I didn't see any discussion of that on the talk page, so I'm starting one.

When a list is introduced by an introduction ending with a colon, and the same reference supports all of the items in the list, it's common to put the single ref on the introduction rather than repeating it for each item. The new guidance doesn't account for that, and would result in a construction such as:

The X in the Y are4: instead of The X in the Y are:4

I don't think it looks better with the footnote preceding the colon. What do others think? edit to add Eissink and I were apparently typing at the same time, oops. Thanks, Izno, for making this a subsection! Schazjmd (talk) 22:10, 16 August 2020 (UTC)[reply]

Schazjmd, you are totally right on the example of a list. I probably could have better started a discussion, but my edit was in good faith (yet I had not given it enough thought). I hope you agree with the examples I have given above. It is not a major problem, of course, but in those examples I think my edits have improved the articles, and I couldn't find a guideline on this, so I thought I'd just add it, but again: you make a good point. Since I'm not a native speaker of English, it's probably better not to be the frontrunner in editing the Manual of Style, but I hope you (and others) see my point. Thanks, Eissink (talk) 22:30, 16 August 2020 (UTC).[reply]
Eissink, I do agree with your point where the colon is introducing a quote, that the ref should follow the quote itself. (Do people use colons that way? I was taught to use a comma, as in James said, "Not now, I don't." Sorry, digression.) But when I saw the addition, the first thing that came to my mind is lists because that's when I most often use one.
Also, I apologize if anything in my wording made you feel like I didn't think you were editing in good faith. That wasn't the case at all. I just thought it was a change that hadn't been discussed and thought that it should be. Schazjmd (talk) 22:44, 16 August 2020 (UTC)[reply]
My example was pretty poor, I must admit, but I think people in many written languages do use colons to introduce quotes, at least it's common in Dutch (my mother tongue, besides Tweants). And no apologies needed – lately I tend to be perhaps over-apologetic, having earlier too often been interpreted as too bold (or even blunt), even when I didn't intend to be. Eissink (talk) 23:10, 16 August 2020 (UTC).[reply]
  • While one can never be sure what others are seeing with all their various browsers on all the many platforms using who-knows-what zoom level and fonts, I find that if a ref tag immediately follows a quote mark then the two are just a bit too close for comfort. Maybe that's what the OP's experiencing. In such cases I add a hairspace i.e. {{hsp}}. Take a look:
"Hello."[2] <== no hsp
"Hello." [2] <== using hsp
Consider the following:[2] <== no hsp
Consider the following: [2] <== using hsp
To be honest, I don't think the {hsp} is needed with the colon, but maybe the OP will find it helpful nonetheless. EEng 02:35, 17 August 2020 (UTC)[reply]
Hairspace is new to me, so thanks for that, but it's beside my point. Yes, a readability problem led to distinguishing the problem, but the problem is of course the position of the ref tag, that imo should follow the quote, not the introduction to the quote. Eissink (talk) 10:07, 17 August 2020 (UTC).[reply]
In general a ref tag should come just after the last thing it verifies, but there are times when that's a bit awkward, such as in precisely the situation above i.e. a list or table. The construction The X in Y are:[99] [bulleted list] is perfectly fine in such cases, because (when you think about it) the ref tag covers the verb are; in other words the ref tag can be seen to verify that the X in Y "are" whatever we then go on to say they are. We have to credit our readers with some intelligence. EEng 03:54, 19 August 2020 (UTC)[reply]
@Markworthen: What does the Chicago Manual of Style say about (references and) colons? Thanks, Eissink (talk) 18:48, 18 August 2020 (UTC).[reply]
Nothing specific about colons, but this statement covers them: "Relative to other punctuation, the number follows any punctuation mark except for the dash, which it precedes." :0)   - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 19:16, 18 August 2020 (UTC)[reply]
No, ref tags do not go inside the block quotation markup. They are not part of the quote, so doing that is falsifying the quoted material and is an abuse of the <blockquote>...</blockquote> element. For short, inline quotes, the citation can come after the quote, as the markup problem does not arise. PS: If you are having readability problems, change your browser font settings or use WP:USERCSS to introduce some custom kerning. The <ref> tag uses class="reference", so you could do something like .reference { padding-left: 0.2em; } in Special:MyPage/common.css to create a little bit of space:[1]
Doing it this way will not junk up the wikicode with innumerable {{hsp}} instances which will probably get deleted by the next editor to come along away.
 — SMcCandlish ☏ ¢ 😼  21:10, 24 August 2020 (UTC)[reply]
SMcCandlish, I'm confused by your comment. We're discussing whether Ref tags do not follow a colon. is appropriate. I'm not sure where blockquote comes into it. Could you clarify whether you agree with Ref tags do not follow a colon. or not? Schazjmd (talk) 21:41, 24 August 2020 (UTC)[reply]
Just read the discussion. E.g., "where the colon is introducing a quote, that the ref should follow the quote itself". That's okay for an inline quote, but not for a block quote. In the latter case, the ref tag definitely does go after the colon, comma, or period at the end of the regular text introducing the quoted material. Ref tags can come before colons for other reasons; there's nothing magically different about them. This discussion was predicated on an individual's text display/legibility problem, for which I have provided a simple solution that doesn't disrupt the wikicode for others, and requires no WP:CREEP changes to the guidelines.  — SMcCandlish ☏ ¢ 😼  21:53, 24 August 2020 (UTC)[reply]

Ref tags before closing paren

Since we're on the subject of punctuation vs. ref tags (that is, the little superscript [99] thingamajigs), I want to bring up the current provision that ...

Where a footnote applies only to material within parentheses, the ref tags belong just before the closing parenthesis.

While this has a superficial logic to it, it actually makes no sense and serves no purpose. Consider this passage:

The earth revolves around the sun. (It also rotates on its own axis.)[1]

Fine. But under the guideline, if each statement is supported by its own source, we're supposed to move the last ref tag inside the parens, like this:

The earth revolves around the sun.[2] (It also rotates on its own axis.[3])

Why? A ref tag logically covers all material back to the next-prior ref tag, whether that material's in parens, not in parens, or a combination. Period. Without this special provision we'd be doing this:

The earth revolves around the sun.[2] (It also rotates on its own axis.)[3]

... which is perfectly sensible and unambiguous. Moving the ref tag inside the parens achieves nothing and looks awful. By the logic of this "parenthesis" exception, if a ref tag applies only to material within a single sentence, then we should move the ref tag before the period/stop closing the sentence[1]. That would be dumb of course, and so is the current special provision for parentheses. I propose we remove it. EEng 02:35, 17 August 2020 (UTC)[reply]

References

  1. ^ They actually do this on frwp, and it looks ghastly. Here's passage from fr:Donald_Trump:
    Trump n'est pas envoyé sous les drapeaux pendant la guerre du Viêt Nam 19. Durant ses études, de 1964 à 1968, il obtient quatre reports d'incorporation 20. Puis, après avoir été jugé bon pour le service en 1966, il est réformé en octobre 1968 21. Dans une interview accordée en 2015, il affirme avoir été réformé en raison d'une épine calcanéenne au talon 22. En 1969, il obtient un chiffre élevé à la loterie organisée pour la conscription, ce qui lui aurait de toutes manières permis d'échapper au service 21,23,24.
    Lovely, huh? But they eat frogs and snails and endangered birds, so go figure.
By the way, what you may consider some sort of joke about French people, probably intended to somehow strengthen your point, I find pretty tasteless and quite offending, actually. Is it considered normal here to make such condescending remarks to other language wiki's? I don't think so, but it might be that I'm missing some clue. Eissink (talk) 10:20, 17 August 2020 (UTC).[reply]
I don't know what joke you're talking about. From our article on the Ortolan bunting:
Excuse me while I go drown the ortolans, mon ami.
The ortolan is served in French cuisine, typically cooked and eaten whole ... The birds are caught with nets set during their autumn migratory flight to Africa. They are then kept in covered cages or boxes. The birds react to the dark by gorging themselves on grain, usually millet seed, until they double their bulk ... The birds are then thrown into a container of Armagnac, which both drowns and marinates the birds.
The bird is roasted for eight minutes and then plucked. The consumer then places the bird feet first into their mouth while holding onto the bird's head. The ortolan is then eaten whole, with or without the head, and the consumer spits out the larger bones. The traditional way French gourmands eat ortolans is to cover their heads and face with a large napkin or towel while consuming the bird. The purpose of the towel is debated. Some claim it is to retain the maximum aroma with the flavour as they consume the entire bird at once, others have stated "Tradition dictates that this is to shield – from God’s eyes – the shame of such a decadent and disgraceful act", and others have suggested the towel hides the consumers spitting out bones. This use of the towel was begun by a priest, a friend of Jean Anthelme Brillat-Savarin ...
Ortolan hunting was banned in France in 1999, but the law was poorly enforced and it is thought that up to 50,000 ortolans were illegally killed each year during the autumn migration ... France's ortolan population fell 30% between 1997 and 2007.
Quintessentially French from start to finish, n'est-ce pas? If you like, I can insert similarly mild national stereotypes about Brits, Jerries, Russkies, or Yanks, for balance.
Returning to the actual point at hand, I honestly cannot understand what you're saying.
  • You say
The earth revolves around the sun.[2] (It also rotates on its own axis.)[3]
is ambiguous (presumably in something about its citations). In what way? You say I'm trying to fix something that is not broken, but unless you can explain what's wrong with the above (which is what we would do as a matter of course if the guideline didn't go out of its way to tell us to do something else) then it's the guideline that's trying to fix something that isn't broken. WP:MOSBLOAT is a serious problem, and every unnecessary provision we can remove is a victory.
  • What does
That way you suggest that whatever is in the footnote, it is also responsible for placing the sentence between parentheses, which is however an editing choice.
– mean?
EEng 16:37, 18 August 2020 (UTC)[reply]
Suppose we have two footnotes in a parenthetical remark. (Like, one footnote for one claim,[1] and then a second footnote for a second claim.[2]) If we put the second footnote outside the parens, the grouping of the parentheses would make it appear that the second footnote covered the whole parenthetical remark, when actually it is only intended for the later part of the remark. So to accurately describe what the footnote covers, we would necessarily need it to be inside the parens. Now imagine the same scenario, but where a sloppy editor has omitted footnote 1 and left the first claim uncited, keeping only footnote [2]. Still, the footnote must be inside the parens, to avoid the false implication that it covers the whole remark. So requiring footnotes to be outside enclosing parens can lead to logical trouble. In some circumstances, footnotes must go inside. If they cover the entire parenthetical remark (or more), and only if they cover the entire parenthetical remark or more, they can go outside. If you want a real example of this, consider the lead of a biography that has separate citations for birth and death dates, or maybe only a citation for the death date but not the birth date. —David Eppstein (talk) 17:09, 18 August 2020 (UTC)[reply]
If the parenthetical isn't very long, we could also have both references outside the parens. El Millo (talk) 17:18, 18 August 2020 (UTC)[reply]
  • @EEng: I have a major problem with you altering your initial contribution significantly áfter two other editors have responded to it (also see WP:REDACTED). For new readers, it is now totally unclear what I was reacting upon. This is not how one should react, you are obscuring the dialogue tremendously. I would have undone it, if not others had already responded to it all, but please don't ever do that again.
I think it is totally clear what I meant with both my contributions. Concerning my opposition to your proposal, I could not have been more clear, so I regret that you seem not to be able to grasp what I said. Concerning your comparison of one French (editorial) habit with another cultural habit (eating certain animals), thereby implying that the former is somehow a poor choice which one must 'go figure' bad taste as is, presumably, the national diet: to me that's not only childish, but condescending. I may be wrong in assuming you like to use Wikipedia Talk pages as some sort of personal blog where you try to be the most funniest Wikipedian on the planet, but I find such attention grabbing, if that is what it is, rather presumptuous and pathetic. Anyhow, I remain strongly opposed to your proposal – that you don't seem to be able to understand what I mean by a totally clear sentence on the range of a footnote as compared to an editorial choice to place a sentence between parentheses, might not be your biggest problem, but maybe you could give it another try. Eissink (talk) 17:49, 18 August 2020 (UTC).[reply]
All I did was change my link to the frwp article to an actual quote from it, thus saving people a click. So sue me.
Beyond that I'll just note (a) that you didn't answer my two straightforward questions, and (b) I'm not the only one – see below – who can't understand what you're trying to say. To be honest (and it pains me to say that but you drive me to it) much of what you write is unintelligible. EEng 23:20, 18 August 2020 (UTC)[reply]
@Eissink: I, for one, did not understand your stance on the subject. Ignoring the attempts at comedy displayed above, what is your position on refs inside or outside the parentheses? Do you think it is ambiguous to have (something like this)[1] instead of (something like this[2])? Because I think it would be equivalent to, as EEng said, doing something like this[3]. instead of doing it like this.[4] El Millo (talk) 18:16, 18 August 2020 (UTC)[reply]
@El Millo: I think your examples consist of a dependent clauses, where EEng's example focussed on an independent clause, on a self-contained proposition:
The earth revolves around the sun.[2] (It also rotates on its own axis.)[3]
Do you see the difference? If an editor chooses to add an indepedent clause and for one reason or the other chooses to place it between parentheses, with the period preceding the closing bracket, the latter is an editorial choice that should, imo, not be attributed to an external source. Eissink (talk) 18:42, 18 August 2020 (UTC).[reply]
Well, that example there is plain bad grammar. That should be The earth revolves around the sun (it also rotates on its own axis). in which case I would personally put both refs after the period. We should base ourselves on sentences that are clearly grammatically correct and that represent a common use of parentheticals, instead of focusing on uncommon or outlandish examples. El Millo (talk) 18:50, 18 August 2020 (UTC)[reply]
Um, no, it's The earth revolves around the sun (it also rotates on its own axis) that exhibits bad grammar. It's run-on sentence – basically a parenthetical version of The earth revolves around the sun, it also rotates on its own axis. EEng 23:23, 18 August 2020 (UTC)[reply]
Well, El Millo, please don't blame me for reacting on exactly that example, that is pretty much the core of the proposal. While the example might be bad grammar or outlandish, as you say, the principle exhibited was quite clear, and that was precisely what I reacted upon. How should I react on something that is not proposed? (And the choice of the editor to completely alter and fancy the contribution later doesn't make all of this more clear.) Eissink (talk) 19:00, 18 August 2020 (UTC).[reply]
I don't blame you, I'm asking you to move past that in order to have a meaningful discussion from now. El Millo (talk) 20:02, 18 August 2020 (UTC)[reply]
We weren't on that point when you asked me to elaborate on what, according to yourself, "would be equivalent to" what EEng proposed, which it wasn't. But sure, why not just pretend and agree my contribution was not meaningful anyway, right? Guess I'm responsible for the mess of others. I'm done here. Bye, Eissink (talk) 20:19, 18 August 2020 (UTC).[reply]
Okay, if you want to purposefully misinterpret my comment in order to feel accused, blamed or aggravated in some other way, go ahead. I'm trying for you to ignore something you might consider childish or inappropriate in order to actually discuss the subject, instead of just arguing against that particular user for said inappropriate childishness. El Millo (talk) 20:31, 18 August 2020 (UTC)[reply]
Well, the French consider Jerry Lewis a comic genius, so I'm inclined to discount their idea of what constitutes childishness. EEng 23:27, 18 August 2020 (UTC)[reply]
  • Agree - I suggest we adopt the Chicago Manual of Style policy: "Though a note number normally follows a closing parenthesis, it may on rare occasion be more appropriate to place the number inside the closing parenthesis—if, for example, the note applies to a specific term within the parentheses."[1] (I don't want to copy-and-paste the whole section [14.26] since it's copyrighted material.) There's also a public web page that addresses the topic in more general—but still applicable—terms at FAQ item: Punctuation:

Question: When using a superscript footnote number at the end of a sentence, should the period precede or follow the footnote number? What about footnote numbers in midsentence that fall next to some other form of punctuation (comma, semicolon, etc.)? Answer: Please see CMOS 14.26: “A note number should generally be placed at the end of a sentence or at the end of a clause. The number normally follows a quotation (whether it is run into the text or set as an extract). Relative to other punctuation, the number follows any punctuation mark except for the dash, which it precedes.”

  - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 18:16, 18 August 2020 (UTC)[reply]

References

  1. ^ Chicago Manual of Style, 17th ed., (Chicago: University of Chicago Press, 2017), §14.26
Exceptions: Ref tags are placed before dashes, not after. Where a footnote applies only to material within parentheses, the ref tags belongs just before the closing parenthesis.
with
Exceptions: Ref tags are placed before dashes, not after, and may be placed inside a closing parenthesis to parallel other ref tags within the parenthetical:
The earth is round.[1] (And it rotates and revolves.)[2]
but
The earth is round.[1] (And it rotates[2] and revolves.[3])
Does that capture it? If so let's give plenty of time for others to opine, because I know from experience that this is the sort of unimportant thing people can attach great importance to. EEng 23:03, 18 August 2020 (UTC)[reply]
Maybe if you find it unimportant, you shouldn't annoy people who do take it seriously with your remarks. Eissink (talk) 00:23, 19 August 2020 (UTC).[reply]
Clearly I find the issue important enough to have opened the thread and made the bulk of the contributions to it, so perhaps there's some subtlety here you're not discerning. For your benefit here it is: while in the great scheme of things the specific choice is comparatively unimportant (not to say that there isn't a best choice, nor that it's not worth going to reasonable trouble to identify it), people get very exercised about challenges to their personally favored conventions. Now if you could focus for a moment on the issue at hand instead of your offended sensibilities, do you have any comment on my proposed guideline text? EEng 00:55, 19 August 2020 (UTC)[reply]
  • I don't know if we should be strictly advising the reference come after the parentheses, but certainly from the examples given I Agree with removing the advice and/or adopting some variation of the Chicago advice. CMD (talk) 01:10, 19 August 2020 (UTC)[reply]
  • I tend slightly differently I think. Assertion: we should prefer placing the reference after some punctuation, but not parentheses. In the case of a full sentence in parentheses, that places the ref inside; in the case of some partial sentence, then the ref goes outside after the following punctuation mark. That leaves parenthetical statements with multiple clauses internal but no terminating punctuation before the parenthetical and some mix of the set; my preference is that such cases be rewritten. (In fact I think parentheses have very little place in encyclopedic writing at all and articles with should be rewritten without or removed as beneath notice, but I don't want to bring that into the conversation [he said parenthetically].) --Izno (talk) 20:51, 19 August 2020 (UTC)[reply]
    @Izno: For more clarity, could you illustrate your preference with an example? Thanks. El Millo (talk) 20:57, 19 August 2020 (UTC)[reply]
    The earth revolves around the sun.[1] (It also rotates on its own axis.[2])
    The earth revolves around the sun (and also on its own axis).[3]
    But rewrite usually The earth revolves around the sun (and also on its own axis, though sometimes a figgity bob).
    mostly to avoid messes of citing much internally to the parentheses, but also to avoid excessive awkward/lengthy parenthetical constructions. --Izno (talk) 21:06, 19 August 2020 (UTC)[reply]
  • Oppose change. We've been over this many times before, and the answer is always the same: Putting it outside the parenthetical leads to mis-citation (especially after later editors add, remove, and otherwise change bits of it), and even when it does not it confuses the reader about what the citation is being used to verify, since the ref outside the parenthetical implies that the source is being cited for everything – including the material before the parenthetical – all the way back to the previous citation (or the beginning of the article). There is nothing "superficial" about the logic. What is in fact superficial is the desire to move the citation outside the parenthetical because you subjectively feel that it looks better.  — SMcCandlish ☏ ¢ 😼  21:04, 24 August 2020 (UTC)[reply]
    But the the ref outside the parenthetical should imply that the source is being cited for everything – including the material before the parenthetical – all the way back to the previous citation. If it doesn't then there should be another ref tag before the opening paren. If I'm wrong please give an example. EEng 04:19, 25 August 2020 (UTC)[reply]
    We usually do not use citations in leads (other than of stubs, which pretty much just consist of leads) at all, except for potentially controversial or surprising statements that some readers are apt to disbelieve before reading the meat of the article. More importantly, the WP:V policy is that claims must be reliably sourceable, not already sourced before being added to an article (otherwise over half of Wikipedia's content would have to be deleted). I'm surprised you're making this argument, EEng, since we have been over this before at least twice, though I suppose the last time was a few years ago.  — SMcCandlish ☏ ¢ 😼  06:59, 25 August 2020 (UTC)[reply]
  • Disagree as written. The example given is flawed. A parenthetical statement will rarely be a new sentence. Further, the more common example is a paragraph that has an overall source at its end and a parenthetical within it that is separately referenced. The logic that the reference applies to all material back to the previous reference is clearly not true in this case for either reference. In most cases a ref outside the parenthesis will work just fine, but there is a difficult case when the parenthetical occurs at the end of the para. For clarity, the parenthetical reference needs to either be inside the paretheses, or else it goes between the closing parenthesis and the period. Moving the general ref in front of the parethetical clause (which at first sight seems to be a solution) will actually cause more confusion since it is now in the middle of the last sentence. So does it apply to just half a sentence or what?
We really shouldn't be micromanaging formatting at this level. Better to leave it to article editors to find the best solution in specific cases. SpinningSpark 15:49, 27 August 2020 (UTC)[reply]
  • Disagree as written. Spinningspark has put the case very clearly; especially the last paragraph. Leave it to article editors to achieve the necessary clarity. Peter coxhead (talk) 17:04, 27 August 2020 (UTC)[reply]
  • Could one of SMcCandlish, Spinningspark, or Peter coxhead please give concrete examples of what they're talking about, and in particular how the presence of parentheses somehow creates a new, different situation? EEng 03:22, 29 August 2020 (UTC)[reply]
    "Louise McKenzie Doodah (1 January 1901 – 31 December 2001) was a transwoman (born intersex[1]) activist and writer, best known for her novel The Unlightable Being of Bareness." If this is not a stub, then it is unlikely any other citation in the lead is needed, because it's unlikely anything in this lead is potentially controversial about this hypothetically well-known figure, other than the claim to have been born intersex rather than clearly male or female, which (again hypothetically) hadn't been well-publicized. Maybe someone on the talk page has already challenged the assertion, and required that a citation for this appear in the lead. If the cited source is only a source for that particular fact and not for, say, the birth date and middle name, then the citation must go inside the parenthetical, or it will falsely be posing as a citation for everything from the first word up to "intersex".

    Problems like this get even worse in long main-body paragraphs, which are frequently peppered with verifiable but not yet verified additions by drive-by editors, sometimes in mid-sentence. It's not uncommon for single sentences in controversial- or complicated-topic articles to have several citations for specific clauses making severable claims in the sentence. If one of these is parenthetical, then the only way a citation specifically for that is not going to be misleading is if there is another citation immediately before the opening parenthesis (round bracket), which we cannot guarantee. Even if it's incidentally a true condition at this moment, this situation only holds as long as no one ever inserts anything new between those two elements without a citation, which on this wiki is a very unsafe bet. In short: citation accuracy is far more important than subjective typographic quibbles.  — SMcCandlish ☏ ¢ 😼  05:25, 30 August 2020 (UTC)[reply]

  • The worst thing about the examples right up at the top is that hideous full stop inside the brackets. Stick the full stop outside the brackets, and drop the full stop after sun, and they all look a lot better. MapReader (talk) 06:34, 29 August 2020 (UTC)[reply]
    No, the stop/period belongs inside that "(It also rotates on its own axis.)" example; it is a full parenthetical sentence, not a parenthetical clause with in a larger sentence. Doing "(It also rotates on its own axis)." is an error, about which every style guide ever published would concur. Of course, rewriting without a parenthetical to begin with is often a good choice. WP uses brackets too often as it is.  — SMcCandlish ☏ ¢ 😼  05:25, 30 August 2020 (UTC)[reply]
    And too many parentheses as well. EEng 05:35, 30 August 2020 (UTC)[reply]

Should more than one name of an academic institution be used in an article?

If a person's alma mater has changed names since he or she graduated, should his or her biography include both names? For example: "He studied drama at the Carnegie Institute of Technology (now Carnegie Mellon University)". I have not been able to find anything in the Manual of Style that applies to this situation. Eddie Blick (talk) 01:27, 19 August 2020 (UTC)[reply]

This is no different than if the name of a city or a country or a corporation changes: if you think it will aid the reader's comprehension, then say it. But don't link it twice, as you did above, since both links go the same place. (Personally I'd pick the old name to be the one linked, since it's conceivable that will go to a specific section in the main article e.g. a history section.) EEng 03:44, 19 August 2020 (UTC)[reply]
Personally, I think it's completely unnecessary to state the current name of any institution, city, country, organisation or anything else unless it's actually relevant to the article. If the reader is interested enough they'll click on the link and find out what it's called now. -- Necrothesp (talk) 13:08, 19 August 2020 (UTC)[reply]
unless it's actually relevant to the article – That's just another way of saying what I said: if you think it will aid the reader's comprehension. Like everything else it's an editorial judgment. EEng 13:50, 19 August 2020 (UTC)[reply]
No, that's not what I meant. If, say, the new name was adopted during the period covered by the article then it's relevant to mention it. But such (sadly, often seen) things as born in Calcutta (now Kolkata) or born in Constantinople (now Istanbul), or indeed he attended the Carnegie Institute of Technology (now Carnegie Mellon University), when the names weren't used at the time is completely pointless and unnecessary. It only "aids the reader's comprehension" if the reader is too lazy to click through, and it's not our job to pander to lazy readers. That's why this is a fully linked encyclopaedia. -- Necrothesp (talk) 10:41, 20 August 2020 (UTC)[reply]
EEng#s and Necrothesp, Thank you for your feedback. I also feel that adding the current name is unnecessary, but I occasionally see expressions like the one I quoted, and I wanted to find out how others felt. I appreciate your help Eddie Blick (talk) 01:50, 20 August 2020 (UTC)[reply]
Why they changed it, I can't say. People just liked it better that way? –Deacon Vorbis (carbon • videos) 13:24, 19 August 2020 (UTC)[reply]
Deacon Vorbis, I was curious about that, also. The Carnegie Mellon University article says that the change resulted from a 1967 merger of Carnegie Institute of Technology with the Mellon Institute of Industrial Research. Eddie Blick (talk) 01:54, 20 August 2020 (UTC)[reply]
See Istanbul (not Constantinople) and have yourself a listen –Deacon Vorbis (carbon • videos) 02:00, 20 August 2020 (UTC)[reply]
I think it depends. If someone attended the College of New Jersey prior to 1746, we should always mention that it is now known as Princeton University, to avoid confusion with the modern TCNJ. But otherwise it is optional. -- King of ♥ ♦ ♣ ♠ 02:47, 20 August 2020 (UTC)[reply]
That's a good point. I had not considered the aspect of duplication of a previous institution's name. Eddie Blick (talk) 00:44, 22 August 2020 (UTC)[reply]

European American vs. whites, white people, white Americans, or Caucasians

This discussion pertains to Wikipedia:Manual of Style § Contested vocabulary "Avoid words and phrases that give the impression of straining for formality, that are unnecessarily regional, or that are not widely accepted."

I wanted to make an inquiry about the current status on Wikipedia surrounding articles using the term European-American versus whites, white people, white Americans, or Caucasians. I've noticed the use of this uncommon term occurring in more and more articles and other places. See latest search results that show over 4,000 hits.

However, a search on Google Ngram reveals that European American has never been a common term from 1800 until 2019 in comparison to whites, white people, white Americans, or Caucasians. Mitchumch (talk) 06:53, 23 August 2020 (UTC)[reply]

We should use the terminology that is widely accepted, bearing in mind that race and ethnicity are social rather than biological constructs. Currently, the general term is white AmericanTFD (talk) 05:15, 28 August 2020 (UTC)[reply]

I think it depends on exactly what you're talking about. There may be some reasonable niche usages for "European-American" as a distinct notion from "white". But I agree that we shouldn't generally replace "white American" by "European American" when not making such a distinction.
On another note, we should definitely avoid "Caucasian" in the sense of "white", which is just confusing. Armenians, Azerbaijanis, Georgians are Caucasians; Germans not so much. --Trovatore (talk) 06:28, 28 August 2020 (UTC)[reply]
I also have concerns that this term was deliberately used by proponents of white supremacy that are active on Wikipedia. I'm NOT saying that every editor that has used this term is a supporter of white supremacy. But, I am concerned. Please see European-American Unity and Rights Organization founded by David Duke. White supremacists have a history of duplicating African-American organizations. See:
What can be done to address this concern? Mitchumch (talk) 16:00, 28 August 2020 (UTC)[reply]
Mitchumch, I do hope you meant I'm not saying that every editor that has used this term is a supporter of white supremacy. Schazjmd (talk) 16:14, 28 August 2020 (UTC)[reply]
Schazjmd, That was a bad typo. Thanks for catching that. Mitchumch (talk) 16:17, 28 August 2020 (UTC)[reply]
I would venture to say that any editor who is making a concerted effort to introduce this phrase into articles, and particularly to replace existing language with this phrase, is acting questionably. BD2412 T 16:48, 28 August 2020 (UTC)[reply]
I agree. I think that one reason it's used by white supremacists is to exclude Jews. We should use white American. Doug Weller talk 17:26, 30 August 2020 (UTC)[reply]

This terminology plugs into two big themes of American society:

  1. The U.S. is a settler colony, and American culture attaches great significance to ancestral origins, which are widely celebrated both in the USA and in some of the countries which exported their people. (e.g. Ireland makes a big fuss over Barry from Moneygall).
  2. The U.S. is a racially divided nation, with a history of slavery and a type of apartheid. That racial divide is described in many ways, one of which is by ancestral origin: "African American" vs "European American", which means black vs white.
Wikipedia accepts categorisation by national origin as ethnicity. For various complex reasons, Wikipedia categorisation accepts "African American" an ethnic term, and accepts categorisation on that basis ... but categorisation practice deprecates "European American" as a racial categorisation.
This is complex stuff, as we try to find neutral terminology to describe a bitterly-fractured society, while also reflecting widely-used terminology. It's a delicate balance.
I think that at category level, we have it right. The reasons why "African American" is ethnic but "European American" is racial are subtle and complex, but broadly right.
However, usage in articles is a more complex issue than the binary choices involved in categorisation. I suggest the articles should follow the reliable sources for that article: if the sources commonly describe someone as "European AMerican" (or "Northwestern European"), then the article can use that term, but should attribute it per WP:ATTRIBUTEPOV. --BrownHairedGirl (talk) • (contribs) 20:59, 3 September 2020 (UTC)[reply]
  • Well, we do have an article on European American which suggests it is used somehow, so wouldn't that have to be tackled first?
Also, just FYI if it helps, African American was to be rather deliberately an ethnicity.[23] (So, perhaps it's a matter of assumptions about words, in hearing or reading European American, would you be thinking of a group of ethnicities not a race, and would you think that it could include at least some Jewish Americans, and would you think it makes sense for someone to say, I am African American and European American) -- Alanscottwalker (talk) 21:54, 3 September 2020 (UTC)[reply]

Inconsistent guidelines on diacritics

Hi there! I'm a bit lost on exactly what the go is here, since there's some inconsistency here. Basically, WP:UE and MOS:DIACRITICS states to use the anglicised version of terms if it's used in the majority of sources, except for proper names which WP:PROPERNAME then says to always use diacritics, which conferred means that Wikipedia could purposefully go against the majority of reliable, English-language sources. What exactly is the low-down on using diacritics when:

  1. they're used by the majority of reliable, English-language sources,
  2. there is no exact majority etc

There have been previous attempts to have regional guidelines on such (Wikipedia:Naming conventions (Vietnamese)), but they've failed to get consensus become any policy or guideline. ItsPugle (please use {{reply|ItsPugle}}) 03:28, 24 August 2020 (UTC)[reply]

– Courtesy pinging possibly interested editors: In ictu oculi and Mztourist.

I don't see such inconsistency here. WP:PROPERNAME clearly says, Wikipedia normally retains these special characters, except where there is a well-established English spelling that replaces them with English standard letters. El Millo (talk) 03:41, 24 August 2020 (UTC)[reply]
Sorry, just to clarify but by well-established, it means the majority of reliable, English-language sources right? That descriptor is a tad ambiguous to me as I thought it meant published articles where the subject is the use of diacritics or another MOS (like APA etc), but if it just means based off sources... ItsPugle (please use {{reply|ItsPugle}}) 03:44, 24 August 2020 (UTC)[reply]
@ItsPugle: Yes it does. El Millo (talk) 03:46, 24 August 2020 (UTC)[reply]
  • Hello ItsPugle - most of these questions you are asking have already been answered in the two RMs where you tried to reopen diacritics discussions of 10 years ago which were just closed as consensus against your proposal. As above WP:PROPERNAME clearly says, Wikipedia normally retains these special characters, except where there is a well-established English spelling that replaces them with English standard letters. This "Wikipedia could purposefully go against the majority of reliable, English-language sources" is a view you have. You want to go counting English print sources to duplicate Low-MOS sources so as to make en.wikipedia take the look of the Brisbane Courier Mail, for example. And you're right, and all Wikipedia editors and all the Wikipedia article corpus is wrong, correct? In ictu oculi (talk) 07:34, 24 August 2020 (UTC)[reply]
  • My understanding of the sense of WP:UE is that it's supposed to be about differences of spelling or differences of naming rather than about differences of keeping or omitting the proper accents on characters. So we can use Austria instead of Österreich or Nuremberg instead of Nürnberg but we would never use *Osterreich or *Nurnberg. Some people really do have different names, or different variations of the spelling or ordering of their names, that they use in English-language sources, compared to the name they would have used in their original language; our article is titled Paul Erdős, not Erdős Pál, for instance. But when the difference really amounts to "we're too illiterate or technology-challenged to get the accents right", we should take the effort to get the accents right, even if a majority of older English-language sources really were too illiterate or technology-challenged to get the accents right. I'm not sure whether it might make sense to somehow clarify this in the linked guidelines. —David Eppstein (talk) 07:52, 24 August 2020 (UTC)[reply]
I can hardly believe this, but @Facu-el Millo: after you cited WP:PROPERNAME at 03:44, 24 August 2020 the editor above went straight to Wikipedia:Manual_of_Style/Capital_letters#Proper_names and rewrote it: 03:49, 24 August 2020‎ ItsPugle talk contribs‎ 59,004 bytes -2‎ →‎Diacritics: clarifying what "well-established" means. I've reverted it but the editor keeps challenging to take him to ANI, so if that happens this is a diff that should be noted. In ictu oculi (talk) 07:54, 24 August 2020 (UTC)[reply]
@In ictu oculi: The only change I made was clarifying the meaning of "well-established". That's literally it. To be more specific, I changed "where there is a well-established English spelling that replaces them with English standard letters" to where the majority of reliable, English-language sources replace them with anglicized equivelants [sic] as per my discussion with Facu-el Millo. And I'm not "challenging" you to take me to the ANI, I'm calling on you to stop claiming misbehaviour then not doing anything as it comes across as you just trying to smear my character. I'm sure I've also mentioned this before, but "the editor above" has a name, and it's common courtesy and easier to write {{u|ItsPugle}}. ItsPugle (please use {{reply|ItsPugle}}) 08:11, 24 August 2020 (UTC)[reply]
That's not a clarification, that's a change from the way people have been repeatedly telling you it works to the way you would like it to work. Don't do that. —David Eppstein (talk) 16:55, 24 August 2020 (UTC)[reply]
Would you be able to explain why replacing a phrase with its meaning isn't a clarification? I genuinely don't understand how it wasn't and just want to make sure I haven't missed anything. ItsPugle (please use {{reply|ItsPugle}}) 22:49, 24 August 2020 (UTC)[reply]
If you still don't understand that being well-established as a variant English spelling has a very different meaning from taking a numerical count of sources (especially in situations where those sources didn't use a variant spelling, they merely dropped the accents for technical reasons) then I think WP:IDIDNTHEARTHAT may be coming into play. —David Eppstein (talk) 00:18, 25 August 2020 (UTC)[reply]
In practice, what happens is that if reliable sources indicate that the diacritic belongs there (even if they are not a majority of sources), then WP uses the diacritic. WP:ABOUTSELF overrides this. E.g., many US celebs with Spanish names that usually have acute accents in them (Rodríguez, Guzmán, etc.) eschew them in their professional names. Jingoistic organizations that are reliable for some things (lazy news publishers, lazy sports leagues, etc.) that just can't be bothered to spell the name correctly, do not override ABOUTSELF; if the subject uses the diacritic in their own material (official webpage, Twitter, etc.), then WP will also. For geographic names, the principle that a long-standing English-language name for the place should be used can override locals' use of a diacritic, but this is for places like Munich/München, not for, say, São Paulo or other places that have not had diacritic-free names in English for many centuries. In practice, then, it's not likely to apply except to Old World locations within the ambit of direct European influence. Seeming exceptions generally have other explanations. E.g. Quebec is not spelled Québec on WP because it is not spelled that way in English by the Canadian government [24] or press [25], for the most part (nor is it usually pronounced even in an approximation of the French way in English).  — SMcCandlish ☏ ¢ 😼  21:00, 24 August 2020 (UTC)[reply]
Heck help us, if a push towards using (example) Japanese & Chinese letters on english language Wikipedia begins. GoodDay (talk) 00:08, 25 August 2020 (UTC)[reply]
Huh? This seems to be a strange non sequitur. This discussion has nothing to do with entirely different writing systems.  — SMcCandlish ☏ ¢ 😼  06:37, 25 August 2020 (UTC)[reply]

@ItsPugle: Indeed it's frustrating how diacritics have taken over english language Wikipedia. But what can you do, when a majority of editors want them inserted in article content & article titles. Heck, for these last few years, an individual has been mass creating 'french' based articles & immediately moving them to diacritics-style titles. So again, what can you do about it. PS - If enough editors want red to spell b-l-u-e? then that's how it will be spelt. GoodDay (talk) 00:03, 25 August 2020 (UTC)[reply]

The notion that English doesn't have and use diacritics is a silly myth [26]. If you want to rid English of diacritics, you're going to have to lobby Merriam-Webster and the other dictionary publishers to excise them first. WP doesn't determine English, we follow it. You might also want to see what happens when editors engage in anti-diacritics "lobbying" efforts on Wikipedia [27]. The community is tired of it. At any rate, I don't think we should entertain style arguments from someone who writes "english" and "french", who doesn't use hyphens and commas properly, and who replaces the word "and" with "&".  — SMcCandlish ☏ ¢ 😼  06:54, 25 August 2020 (UTC)[reply]
No, if one wants to rid English Wikipedia of diacritics or at least cut down on the usage, one needs to convince a huge majority of editors. These things are decided by the community, which is why we have diacritics across the project. GoodDay (talk) 14:55, 25 August 2020 (UTC)[reply]
You seem to be defeating your own argument. No matter how many times the idea of removing the diacritics from en.WP comes up, it never gains traction. It's become another of those "drop the stick" matters.  — SMcCandlish ☏ ¢ 😼  22:41, 25 August 2020 (UTC)[reply]
Indeed, it will never gain traction, on this project. GoodDay (talk) 23:04, 25 August 2020 (UTC)[reply]
"it's common courtesy and easier to write ItsPugle]". I've never seen that before, and I am obsequiously courteous. BeenAroundAWhile (talk) 04:40, 4 September 2020 (UTC)[reply]

Discussion at WikiProject RuPaul's Drag Race about pronouns

Opinions are needed at Wikipedia talk:WikiProject RuPaul's Drag Race #Hatnote to explain pronouns. Flyer22 Frozen (talk) 04:18, 26 August 2020 (UTC)[reply]

Windrose spelling

Could someone give a link to the MOS regarding spelling of compass directions? -DePiep (talk) 10:09, 30 August 2020 (UTC)[reply]

I can't, but I think British and American usage is different. Anyway, it should be consistent. BeenAroundAWhile (talk) 04:37, 4 September 2020 (UTC)[reply]

Singular/plural possessive

For a magazine like Sojourners, is the possessive singular, or plural? I.e. "on Sojourners's website" or "on Sojourners' website"? Dicklyon (talk) 03:50, 1 September 2020 (UTC)[reply]

I guess I would say Soujourners's, as ugly as it looks. The website doesn't belong to multiple Sojourners, but to the singular Sojourners magazine. --Trovatore (talk) 17:33, 1 September 2020 (UTC)[reply]
I would sidestep the whole issue by writing "the Sojourners website". I think that would be cleaner anyway - regardless of plural possessive issues, I would write "the Rolling Stone website", not "Rolling Stone's website". Popcornfud (talk) 17:38, 1 September 2020 (UTC)[reply]
Good idea. Did that. Dicklyon (talk) 05:23, 4 September 2020 (UTC)[reply]

Citations in headings - alternatives?

MOS:HEADINGS rightly prohibits including citations or footnotes in section headings, because of the numerous technical issues they cause. However I do see them being used occasionally when the citation supports an entire section, for example at #Masthead in List of The New York Times employees. Is there a preferred alternative place to put the citation in this case? the wub "?!" 21:10, 2 September 2020 (UTC)[reply]

When a section head introduces a list that are all based on the same source, I cite the source for each item (if it's a short list) or add a lead-in sentence to introduce the list and add the source on the lead-in. Schazjmd (talk) 21:15, 2 September 2020 (UTC)[reply]
That sounds like a good way of doing it. Emir of Wikipedia (talk) 21:19, 2 September 2020 (UTC)[reply]
Especially for that NYtimes case, a short line under the Masthead could be "This is the list of masthead employees as of date.(source)". You'd want that for each H2 section obviously. --Masem (t) 21:33, 2 September 2020 (UTC)[reply]
Ohh, the "as of date" is a nice touch. Schazjmd (talk) 21:40, 2 September 2020 (UTC)[reply]
Yeah, I'm not sure of the turnover at the Times but that way, no one is pressured to be to-the-day current. Obviously, if its 2020, and we're saying "as of 2015" maybe an update is appropriate... :) --Masem (t) 21:44, 2 September 2020 (UTC)[reply]
Thanks all. I was worried about a lead-in sentence feeling redundant, but using it to include "as of date" is a great idea. That's what I went with. the wub "?!" 12:09, 4 September 2020 (UTC)[reply]

Quotation marks should be inserted around block quotes attributed solely by numeric reference.

Although Wikipedia generally discourages quotations for good reasons I contend that when they are used it is a misleading practice and contrary to established common usage to omit quotation marks around block quotes. See MOS:BLOCKQUOTE. I would cite "The Kings's English" in support of my position that they are necessary for clear identification.Horatius At The Bridge (talk) 22:43, 2 September 2020 (UTC)[reply]

But the work you refer to does not use quotation marks around block quotations. Jc3s5h (talk) 23:00, 2 September 2020 (UTC)[reply]
  • I don't know where the OP could get such an idea but only the sloppiest publications put quote marks around blockquotes. (The infamous pullquote is another matter.) `EEng 02:07, 3 September 2020 (UTC)[reply]
Sorry, I should have made my objection clearer. The examples of block quotations in the cited extract all contained an attribution at the close of the quote but this is not a required component of MOS:BLOCKQUOTE as I understand it. If a named derivative source was also necessarily included it would address my concerns but a bracketed numeric reference does not. Horatius At The Bridge (talk) 09:04, 3 September 2020 (UTC)[reply]
Could you please give an example of what you're talking about? EEng 13:30, 3 September 2020 (UTC)[reply]
Something like this perhaps (but in an article and without the blush)

Mgasparin's Law: As a discussion on ANI gets longer, the probability that EEng will add a sarcastic comment or image approaches 1.

[28]

and obviously without the quotation marks Horatius At The Bridge (talk) 19:50, 3 September 2020 (UTC)[reply]
While I'm flattered at your choice of material, and abashed that I can't think of an appropriately sarcastic image to place here, I still can't tell what you're talking about. Do you have an example from an actual article? EEng 21:20, 3 September 2020 (UTC)[reply]
It was this recent edit which arrested my attention on the subject Horatius At The Bridge (talk) 21:28, 3 September 2020 (UTC)[reply]
I think they mean that a block quote should be followed with an attribution, like you get when using {{txl|blockquote} with the parameters author/title/source, not just a ref num (which may contain the same information). MB 00:44, 4 September 2020 (UTC)[reply]
That example looks OK to me. What is wrong with it? BeenAroundAWhile (talk) 03:57, 4 September 2020 (UTC)[reply]
As I see it, the problem in the two examples in that edit, is the lack of any inline author attribution to introduce the quotes. The quoted text, whether set as a block quote or not, simply floats – the reader has no idea whose words they are. And that's got nothing to do with adding quotation marks/inverted commas, because they wouldn't solve the problem at all. JG66 (talk) 04:06, 4 September 2020 (UTC)[reply]
So what is that little number in the corner? Is that what Horatius is talking about? BeenAroundAWhile (talk) 04:30, 4 September 2020 (UTC)[reply]
That would be the citation, supporting the sentence(s) as one would expect whether the text was a direct quote or written in Wikipedia's voice. But the point is with those edits (which just changed the quoted sentences to block quotes, presumably because of the length) is that the reader arrives at the block quote each time not knowing who's "saying" this. Which is the sort of information that should be given up front in the case of block quotes. JG66 (talk) 04:39, 4 September 2020 (UTC)[reply]
+1 EEng 05:03, 4 September 2020 (UTC)[reply]
+2 Exactly so and corrected in its present form. Horatius At The Bridge (talk) 13:08, 4 September 2020 (UTC)[reply]

I found an address that needs correcting.

I attempted to correct the address associated with Arkansas State Capitol in https://en.wikipedia.org/wiki/National_Register_of_Historic_Places_listings_in_Little_Rock,_Arkansas. However, 5th St does not exist in Little Rock. We have either West or East Capitol Avenue. I wished to change 5th St to that but could not. Google Maps might show both names. OpenStreetMap should only show the one name. I know the area well enough to be a source. Please correct the name.

Thank you,

Andrew L [File:Screen Shot 2020-09-09 at 11.06.52 AM] — Preceding unsigned comment added by Anddooh (talk • contribs) 16:11, 9 September 2020 (UTC)[reply]

WP:Surname and MOS:GENDERID with regard to drag queen articles

At Wikipedia talk:WikiProject RuPaul's Drag Race#Moving forward (100 list), I mentioned the fact that drag queens are not simply their personas. So when someone states that they only identify as a female/a woman when in drag, then it can be WP:Undue and confusing to refer to them with feminine pronouns throughout their Wikipedia article, especially when it comes to their early life as separate from their career. It can leave readers thinking that the person identifies as transgender when they don't. I noted that I state this regardless of the fact that transgender is an umbrella term. In Sasha Velour's case, it's stated that "Steinberg is genderqueer and does not have any preferred pronouns when not in drag. Her drag persona, Sasha Velour, is referred to as 'she'." So when the article title is the drag queen name per WP:Common name, and the drag queen has stated what Velour has stated on pronouns, which surname or pronouns are best to use? At the moment, the Sasha Velour article has one section (the one concerning RuPaul's Drag Race) that refers to Velour by their stage name while the rest of the article refers to Velour by their birth name/legal name (Steinberg). I don't think we should mismatch pronouns or names.

Thoughts? Flyer22 Frozen (talk) 22:45, 9 September 2020 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&oldid=977616192"