Jump to content

Wikipedia talk:Manual of Style: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
JBrahms (talk | contribs)
125 edits
Line 534: Line 534:


As the title shows, there are two ways to type the possible plurality of a noun. ''Orange(s)'' OR ''Apple/s''. Which is correct? I believe the first is more common but still... also, maybe this should be added to the MOS? [[User:3point1415|3point1415]] ([[User talk:3point1415|talk]]) 21:03, 15 January 2023 (UTC)
As the title shows, there are two ways to type the possible plurality of a noun. ''Orange(s)'' OR ''Apple/s''. Which is correct? I believe the first is more common but still... also, maybe this should be added to the MOS? [[User:3point1415|3point1415]] ([[User talk:3point1415|talk]]) 21:03, 15 January 2023 (UTC)

:Far be it from me to proclaim one type of signifier "correct" but generally I have seen Orange(s) more commonly than Apple/s. I'd say it should be added to the MOS considering how these things can be interpreted differently by people who haven't encountered them before.
:[[User:JBrahms|JBrahms]] ([[User talk:JBrahms|talk]]) 02:43, 25 January 2023 (UTC)


== Elementary school ==
== Elementary school ==

Revision as of 02:43, 25 January 2023

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.

Welcome to the MOS pit


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

    Concluded

    Extended content
    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 [1]. 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 fragment read, "...{nbsp}for the love of God!"
    • July{{nbsp}}28, 1942 ????
    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]
      Perhaps that was meant to be "stuck", the synonym for "put". —⁠ ⁠BarrelProof (talk) 23:58, 13 August 2021 (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 at 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]
    • I'm surprised to see the above quote from MOS:NUM (WP:UNITNAMES): "a normal space is used between a number and a unit name". Personally, I would find a line break within the example's "29
      kilograms" rather ugly. —⁠ ⁠BarrelProof (talk) 00:05, 14 August 2021 (UTC)[reply]
      Me, too. The position "you're pretty much saying every number anywhere must be followed by an nbsp" that EEng spoke against earlier actually seems to me to be the best practice. Your example of a break between 29 and kilograms not only looks "ugly", but makes me think that there has been a misprint of some sort causing me to have trouble understanding what is written. --Khajidha (talk) 19:38, 24 August 2021 (UTC)[reply]
    • Somewhat related, but since the discussion here is almost-exclusively referencing insertion of NBSPs, I wanted to re-raise this previous discussion where I advocated for using Template:nowrap instead of NBSPs. The simple reason being that (at least on my system / in my browser) {{nowrap}} has the same effect as the insertion of NBSPs, without affecting spacing of the text the way NBSP does (again, at least on my system). Here's the example I presented:
    Bare Wikilinked
    Using {{nowrap}} World War I World War I
    Using &nbsp; World War I World War I
    Looking at that on my screen, the &nbsp; version has a much larger — in fact, uncomfortably large — space between "War" and "I", whereas the {{nowrap}} version is spaced normally. If we can protect phrases against wrapping without making the formatting look weird, I figure that makes the decision on when/whether to do so a bit less fraught. -- FeRDNYC (talk) 02:52, 15 August 2021 (UTC)[reply]

    Something from somewhere else

    From User:Tony1/Monthly_updates_of_styleguide_and_policy_changes / WP:Wikipedia_Signpost/2008-07-07/Dispatches --EEng 15:34, 18 January 2021 (UTC)[reply]

    Non-breaking spaces. The narrower scope for using non-breaking (i.e., "hard") spaces was significantly clarified. They should be used:

    • in compound expressions in which figures and abbreviations or symbols are separated by a space (17 kg, AD 565, 2:50 pm);
    • between month and day in dates that are not autoformatted (August 3, 1979);
    • on the left side of spaced en dashes; and
    • in other places where displacement might be disruptive to the reader, such as £11 billion, 5° 24′ 21.12″ N, Boeing 747, and the first two items in 7 World Trade Center.

    Improve Controlling line breaks section

    It seems that it would be good if the example markup of 5° 24′ N included a non-breaking space between the 5degrees and the 24minutes and the N. DGerman (talk) 21:18, 6 August 2021 (UTC)[reply]

    Does this still need to remain unarchived?

    EEng? valereee (talk) 17:20, 20 February 2022 (UTC)[reply]

    Along with patrollers reflexively responding to edit requests with "Get consensus first", it's one of those things I plan to get to sometime between now and when I die. EEng 17:31, 20 February 2022 (UTC)[reply]
    It's been here for two years. I say let it archive. If people want to raise it again, and maybe get a clearer consensus, then okay. But this isn't attracting new meaningful commentary.  — SMcCandlish ☏ ¢ 😼  15:37, 25 May 2022 (UTC)[reply]
    But it acts as a mute reminder that I need to get back to this someday! Isn't that reason enough for keeping it here? EEng 02:08, 26 May 2022 (UTC)[reply]
    It's been another 7 months. This is just a really big block of clutter at this point.  — SMcCandlish ☏ ¢ 😼  17:01, 25 December 2022 (UTC)[reply]

    RfC on mid-sentence and mid-article title capitalization of the in the full name of the LDS Church

    There is a request for comment about mid-sentence and mid-article title capitalization of the in the full name of the LDS Church at Wikipedia talk:Manual of Style/Capital letters#RfC on mid-sentence and mid-article title capitalization of the in the full name of the LDS Church. Please contribute there. Thank you. SchreiberBike | ⌨  12:38, 23 October 2022 (UTC)[reply]

    This has already resolved, in favor of lower case.  — SMcCandlish ☏ ¢ 😼  14:18, 20 December 2022 (UTC)[reply]

    Content dispute over non-English addition

    There is a content dispute regarding MOS:FOREIGNITALIC and MOS:FOREIGN at Talk:Minneapolis#Photo of Owamni. An editor added a translation of Saint Anthony Falls--a local waterfall--into Dakota, to enhance an edit about a local restaurant. The input of others would be appreciated. Magnolia677 (talk) 20:46, 24 October 2022 (UTC)[reply]

    That discussion has already archived, as Talk:Minneapolis/Archive 9#Photo of Owamni.  — SMcCandlish ☏ ¢ 😼  14:19, 20 December 2022 (UTC)[reply]

    Does MOS:OUR cover "our Sun"

    Brought up by Trovatore on a revert. Why wouldn't it? This would also cover "our galaxy" (Milky Way would substitute), "our Solar System", etc. When uppercased the 'Sun' refers to the star of the Solar System (also uppercased). The language seems clear: "To maintain an objective and impersonal encyclopedic voice, an article should never refer to its editors or readers using I, my, we, us, our, or similar forms". Thanks. Randy Kryn (talk) 07:30, 25 October 2022 (UTC)[reply]

    So you might mention that the "our" in the passage you quote was actually added by you personally, less than half an hour before your edit that I reverted, so to pull it in in support could mislead readers who weren't aware of that.
    I can see the point that the Sun is already a proper noun and doesn't really need qualification, but that doesn't apply to the "our galaxy" you mentioned in the previous edit summary. How exactly would you describe these objects to a reader who doesn't know (say) which galaxy is the Milky Way?
    It seems to me that the first person plural is properly avoided when it refers to Wikipedia or its editors, but not so much when it refers to the human race as a whole. Our universalist impulses do us credit, but they get kind of silly when they try to avoid being specific about our very species and the location that it will inhabit for the foreseeable future. --Trovatore (talk) 07:43, 25 October 2022 (UTC)[reply]
    I added "our" because the section abbreviation is literally MOS:OUR. You objected to "our Sun" and wanted to talk page it, but now you don't, so fine so far, and a good point about "our galaxy". How about "our Solar System", "our Moon", etc.? Randy Kryn (talk) 07:49, 25 October 2022 (UTC)[reply]
    I think that the language you propose does not make it clear that the objection to "our Sun" is that "Sun" is already a proper noun. This point does not really even seem to be about the first person, but about possessive determiners with proper nouns, which I'm not sure we really need a guideline for, but if we were to have one, this would probably not be the section I'd put it in. --Trovatore (talk) 07:56, 25 October 2022 (UTC)[reply]
    Agreed on the example used, I had suggested a poor choice if not fully explained and was rightfully reverted. But to the point of this section, MOS:OUR does seem to cover "the Sun", "the Solar System", and "the Moon". Randy Kryn (talk) 08:01, 25 October 2022 (UTC)[reply]
    I would think that in such a case, our is being used in a manner similar to the example exception of an historical article. It is being used to refer to us, the collective world rather than editors or readers. Furthermore, if we use any modifier other than the with such terms (sun, galaxy and solar system), they are inherently being used as a common noun like "our dog". Cinderella157 (talk) 08:47, 25 October 2022 (UTC)[reply]
    Perhaps if they are lowercased as you've written them, but Earth's inhabitants have only one Sun, one Moon, and one Solar System when uppercased (where 'our' would be redundant). Randy Kryn (talk) 09:18, 25 October 2022 (UTC)[reply]
    One is a modifier. It implies there may be more than one and that what it precedes is a common noun. But that was not my primary point. Cinderella157 (talk) 10:15, 25 October 2022 (UTC)[reply]
    "Our" Moon only works outside of MOS:OUR when "moon" is lowercased and not at the Moon's proper name. Same with "our" sun and solar system - our only falls outside of MOS:OUR at lowercase and not at the uppercased proper names. Randy Kryn (talk) 18:06, 26 October 2022 (UTC)[reply]
    MOS:OUR was clearly not meant to apply to this. The point of MOS:OUR is WP:NPOV; WP doesn't identify with any particular population or individual. However, the "our" in "our sun" or "our galaxy" is everyone, so there is no NPoV problem.  — SMcCandlish ☏ ¢ 😼  14:16, 20 December 2022 (UTC)[reply]

    WP:MOS#Consecutive punctuation marks suggestion

    2 suggestions:

    1: maybe change

    so is usually better

    to

    so it is usually better

    2: maybe add a Better example to contrast with He made several films with Sammy Davis Jr..:

    Where a word or phrase that includes terminal punctuation ends a sentence, do not add a second terminal punctuation mark. If a quoted phrase or title ends in a question mark or exclamation mark, it may confuse readers as to the nature of the article sentence containing it, and so is usually better reworded to be mid-sentence. Where such a word or phrase occurs mid-sentence, new terminal punctuation (usually a period) must be added at the end.

    Incorrect: Slovak returned to the Red Hot Chili Peppers in 1985 after growing tired of What Is This?.
    Acceptable: Slovak returned to the Red Hot Chili Peppers in 1985 after growing tired of What Is This?
    Better: Slovak, having grown tired of What Is This?, returned to the Red Hot Chili Peppers in 1985.
    Incorrect: He made several films with Sammy Davis Jr..
    Correct: He made several films with Sammy Davis Jr.
    Better: He and Sammy Davis Jr. made several films together.

    --173.67.42.107 (talk) 20:47, 10 November 2022 (UTC)[reply]

    That seems reasonable, and no one's objected to it.  — SMcCandlish ☏ ¢ 😼  14:22, 20 December 2022 (UTC)[reply]

    Talk:2022 Morbi bridge collapse has an RFC

    Talk:2022 Morbi bridge collapse has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. BilledMammal (talk) 06:45, 14 November 2022 (UTC)[reply]

    Talk:2022 Morbi bridge collapse#RfC: ₹4 lakh or ₹400,000 has an RFC

    Talk:2022 Morbi bridge collapse#RfC: ₹4 lakh or ₹400,000 has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. — Preceding unsigned comment added by BilledMammal (talk • contribs) 16:19, 29 November 2022 (UTC)[reply]

    Intros to cities, towns, boroughs, and census-designated places

    I've reviewed WP:USPLACE, which states: "Articles on US cities should never be titled "City, Country" (e.g., "Detroit, United States") or "City, State, Country" (e.g., "Kansas City, Missouri, U.S.") because that is contrary to general American usage." That makes perfect sense. It seems similarly logical that the introductory sentence for cities, towns, boroughs, and census-designated places also follow this approach for the same reason. The nation, of course, already appears in the Infobox and categories, and the addition of the nation in the introduction yet again increases the wordiness and can't be something any reader really needs to see or has doubts about. So am I correct that, as appears to be common practice, there is no need to state "United States" again in the introduction of these pages? Would the following be correct:

    Bangor is a borough located in Northampton County, Pennsylvania.

    Or should it read:

    Bangor is a borough located in Northampton County, Pennsylvania, United States.

    The former appears broadly acceptable and common with most editors and on most pages. And yet, here we are: a few editors (perhaps four or so) insist the latter is necessary and are embarking on vast additions of "United States" in these pages' intros. Does a policy exist on this precise question? If not, sadly, I think we've reached the point where one is necessary. Thanks for any guidance. Keystone18 (talk) 03:17, 24 November 2022 (UTC)[reply]

    Because this is an encyclopedia with an international audience, it is appropriate for the lead to provide the context of what country we're talking about. The lead is meant to provide an accessible overview and stands on its own (per MOS:LEAD) without requiring the reader to also reference infoboxes or categories. The second option above is correct. Nikkimaria (talk) 03:30, 24 November 2022 (UTC)[reply]
    Please sign your comment since you're the editor in question engaged in these vast additions of "United States" on these pages. Keystone18 (talk) 03:27, 24 November 2022 (UTC)[reply]
    In WP:USCITIES and also the WP:U.S. counties page, the guidance for the introductory section is as follows:
    • Name of city and location in state
    • City proper population (US Census figures should be used. When appropriate, other reliable estimates may be included as a supplement to Census figures.)
    • Metro population (US Census figures should be used. When appropriate, other reliable estimates may be included as a supplement to Census figures.)
    • Brief note about historical roots/founding
    • Primary industries supporting its economy (e.g. service, manufacturing, tourism, etc ...)
    • Notable unusual characteristics and characteristics commonly associated with it

    That first entry instructing the name of the city and location in the state and consciously not mandating or even suggesting inclusion of "United States" is as close to any guidance on this as I can find and should be sufficient guidance. There certainly is no stylistic requirement, or even a suggestion, that "United States" be again listed in the introductory of U.S. location pages. Keystone18 (talk) 04:26, 24 November 2022 (UTC)[reply]

    That essay makes it very clear that its suggestions are supplementary to LEAD. Nikkimaria (talk) 04:39, 24 November 2022 (UTC)[reply]
    WP:INFOBOXPURPOSE clearly says an article should remain complete with its summary infobox ignored. Without specifying the country in the lead, readers may have no idea where the place is located. This is not listing United States "again", it is listing it for the first time which is necessary. MB 16:36, 24 November 2022 (UTC)[reply]
    The argument against including “United States” is that the average reader (even those from the non-English speaking world) will know the names of the 50 US States - they may not know which state is where on the map, but they will recognize the name and know that it is within the US. Similar to how readers will know that EU member states are within the EU. Thus, specifying that (say) a town in the State of Nevada is in the US is unnecessary. Saying Nevada is enough. Blueboar (talk) 17:14, 24 November 2022 (UTC)[reply]
    The difference, of course, is that EU member states are sovereign states and US states are not! The EU is not a country. -- Necrothesp (talk) 17:26, 24 November 2022 (UTC)[reply]
    There are plenty of Americans that do not know that New Mexico is a US state. It's foolish to assume that the "average reader" in an international audience can recognize all 50 states. MB 18:41, 24 November 2022 (UTC)[reply]
    I've come across the "New Mexico is outside the country, it's part of Mexico" comment in person, so I can concur that even Americans don't know the names of all the states. Not every one can list the 50 states, so I don't think it's reasonable to expect someone from outside of the country to know that level of detail. - Aoidh (talk) 05:51, 27 November 2022 (UTC)[reply]
    • Comment I think the country should always be included in the first line of a location. Not everyone knows what the US states are (including some Americans), and if you don't put United States in then people may believe that locations in the state of Georgia are in fact in the country of Georgia. We shouldn't presume the knowledge that people know the US states anymore than people are expected to know the counties of the United Kingdom or the provinces of China. Oddly enough the education systems of other countries don't usually tell people about sub-divisions of other countries and aren't taught the 50 states. I don't think it's reasonable to expect non-Americans to know that Arkansas, Idaho or New Mexico are states in the United States anymore than they should be expected to know Yukon is a territory of Canada or Pernambuco is a state in Brazil. Always put the country as part of the location in the opening sentence. It's okay to presume people know, in English, the names of large major world player countries, but I don't think anyone should be expected to know the internal sub-national divisions of those countries. And note I don't think this should apply just to the US, but to all countries. Canterbury Tail talk 17:33, 24 November 2022 (UTC).[reply]

    Definitely include United States at first mention for the reasons already noted, not just where it is needed to avoid potential ambiguity, but to respect readership needs. Don't forget that the population of the USA is a smallish subset of the world's 2 billion-odd English speakers - including not just those from 1st language or bilingial upbringings, but also those who have reasonable learned profiency, because EngWP is much more comprehensive in many areas than most other language wikis. If "city, state, country" can seem too clunky, there are other clear formulations, eg "Birmingham is a city in the north central region of the U.S. state of Alabama." Davidships (talk) 02:49, 25 November 2022 (UTC)[reply]

    • Do not include United States. This just clutters the lead. A person who wonders what New Mexico is can click the link and find out. Most readers will recognize most state names as US most of the time, so the clutter is not worth it. Dicklyon (talk) 00:09, 27 November 2022 (UTC)[reply]
    We're an international encyclopaedia that happens to be based in the United States, not an United States encyclopaedia. Don't presume geographical knowledge of things that are not actually common knowledge to non-Americans (and to some Americans.) Canterbury Tail talk 00:33, 27 November 2022 (UTC)[reply]

    From what I've seen over the years. Canada, the United States & the United Kingdom appears to be the three countries that habitually aren't shown. The Canadian provinces/territories; American states/territories, British constituent countries, tend to only be shown. GoodDay (talk) 00:20, 27 November 2022 (UTC)[reply]

    Doesn't mean they shouldn't be, it's possibly just a centric viewpoint of the original writing editor not thinking it's necessary because they know it. It's often the case with places in India as well. However we are an international encyclopaedia, and should write like it. Canterbury Tail talk 00:33, 27 November 2022 (UTC)[reply]
    FWIW, I'm in favour of including "Canada", "United States", "United Kingdom" as we include the sovereign state for the other countries of the world. You'll likely get support for the Canadian & American bios & places. But probably resistance in the British bios & places. GoodDay (talk) 00:40, 27 November 2022 (UTC)[reply]
    • We go round on this every now and then, but guidelines are clear on this once you find the right ones to read together:
      • WP:Manual_of_Style#Geographical_items (aka MOS:PLACE): A place should generally be referred to consistently by the same name as in the title of its article (see Wikipedia:Naming conventions (geographic names) ... Thus we consult ...
      • WP:Naming_conventions_(geographic_names)#United_States (aka WP:USPLACE): articles on populated places in the United States are typically titled "Placename, State" ... [never] "City, Country" (e.g., "Detroit, United States") or "City, State, Country" (e.g., "Kansas City, Missouri, U.S.") (In addition, per [2], the following cities do not even take that state qualifier: Atlanta, Baltimore, Boston, Chicago, Cincinnati, Cleveland, Dallas, Denver, Detroit, Honolulu, Houston, Indianapolis, Las Vegas, Los Angeles, Miami, Milwaukee, Minneapolis, New Orleans, New York, Oklahoma City, Philadelphia, Phoenix, Pittsburgh, St. Louis, Salt Lake City, San Antonio, San Diego, San Francisco, Seattle, Washington, D.C.)
    If you think articles should identify US cities as e.g. "Ketchum, idaho, United States", then you first need to explain why the article on that city is titled simply Ketchum, Idaho. EEng 03:26, 27 November 2022 (UTC)[reply]
    That guideline combo doesn't address the question under discussion here, though. "Atlanta is a city in Georgia" and "Atlanta is a city in Georgia, United States" are both entirely consistent with MOS:PLACE as in both cases the city is named as "Atlanta"; the rest of the sentence is not part of the name. Nikkimaria (talk) 03:46, 27 November 2022 (UTC)[reply]
    Sure it addresses it. To avoid the obvious complication inherent in "Georgia" as an example, let's switch to California. Writing California, United States also violates WP:USPLACE, since the title of the California is, well, simply California. EEng 04:43, 6 December 2022 (UTC)[reply]
    By that reasoning one should explain why Manchester isn't at Manchester, England, United Kingdom. Article titles have a requirement to be brief. Article leads don't have that same restriction. oknazevad (talk) 04:09, 27 November 2022 (UTC)[reply]
    • Include the country. It does no harm, and makes it clear for an international readership that may not know US states, Canadian provinces, constituent countries of the UK, Mexican states, Brazilian states, etc. Countering systemic bias is a good goal. This is one way to do that. oknazevad (talk) 04:14, 27 November 2022 (UTC)[reply]
    • I think it would be reasonable to have a clear guideline on this saying to either A) name the country (in short form for US and UK), or B) link the subnational division and leave the country off. Both approaches have proven satisfactory for a long time now. Given how many reader-editors WP has, it would be way more than ~4 editors pushing on this if option B were unintelligible broadly. Yet option A is not inherently broken in any way, and we need not make it forbidden. It's especially useful in cases like Georgia (confusable with another country), New Mexico (often mistaken for part of Mexico), Nunavut (which many people have never heard of and which only dates to 1999), and Northern Ireland (yes, there are people who don't know it's part of the UK).  — SMcCandlish ☏ ¢ 😼  07:54, 7 December 2022 (UTC)[reply]

    Addition of "part of a system ..." to WP:&

    On 9 June, someone modified the WP:& paragraph to say that "&" should be used instead of "and" when it is "part of a system such as the WGA screenwriting credit system" (@Alex 21). As far as I know, this was a "bold" undiscussed addition. I don't think that is appropriate:

    • It seems to endorse the principle that the use of specialist styling systems is generally permissible in the Wikipedia MoS, which is contrary to the popular Wikipedia:Specialized-style fallacy concept.
    • It seems to adopt the WGA screenwriting credit system as a specific endorsed system for use in the English Wikipedia as part of the Wikipedia Manual of Style. Has that been agreed? Note that the WGA screenwriting credit system is an extensive and very specific set of guidelines and associated specific processes for dispute resolution.

    I have just reverted that addition.
    —⁠ ⁠BarrelProof (talk) 18:14, 25 November 2022 (UTC)[reply]

    I don't care either way, but it is absolutely the agreed consensus in certain WikiProjects to credit television and film writers on Wikipedia the way that they are credited in official productions. If you have an issue with that, take it up there. -- Alex_21 TALK 23:46, 25 November 2022 (UTC)[reply]
    For purposes of this discussion, I am only focused on what WP:& should say. —⁠ ⁠BarrelProof (talk) 23:52, 25 November 2022 (UTC)[reply]
    This discussion relates to those WikiProjects. The addition was simply an example of a long-standing consensus. -- Alex_21 TALK 23:54, 25 November 2022 (UTC)[reply]
    I don't think it is helpful to the MoS to provide examples of instances where particular Wikiprojects have established a local consensus to follow some external guideline. I remember a time when there was a convention of using a capitalization convention for the names of bird and butterfly species that was different from what was done for other fauna. There was also a recent discussion of a special use of capitalized "The" when referring to a particular religious institution. Such things might happen, but I don't think that is the sort of thing the MoS should be generally accepting and encouraging. —⁠ ⁠BarrelProof (talk) 01:40, 26 November 2022 (UTC)[reply]
    Indeed. When weird "my wikiproject decided ..." variances from normal writing come to light at the MoS level, they consistently get rejected. We learn rapidly that other general-audience publishers do not follow the pet style, and that it has been imported from specialist writing (or even a single entity's house style). This is looking like another case of that. If an average newspaper has no problem writing "produced by Jane Doe and Joe Blow" where WGA would prefer "&", WP has no reason to prefer "&". At very least it has no business being in our MoS; people can argue at a particular article for writing "&" and demonstrate that independent sources consistently do so for the specific case in question.  — SMcCandlish ☏ ¢ 😼  08:01, 7 December 2022 (UTC)[reply]

    MOS:NOTE

    Discussion at Talk:Acts of the Apostles § RFC

     You are invited to join the discussion at Talk:Acts of the Apostles § RFC. Elizium23 (talk) 09:01, 29 November 2022 (UTC)[reply]

    Action comedy film

    There is a discussion to move action comedy film to action-comedy film. Editors, including those who work with MOS:DASH, are invited to weigh in on if this is necessary or not, or helpful or not. The discussion is here: Talk:Action comedy film § Requested move 3 December 2022. Thanks, Erik (talk | contrib) (ping me) 14:28, 4 December 2022 (UTC)[reply]

    Clarification of MOS:LIST

    If an editor is able to give clarification at Talk:Fort Albany First Nation#Notability of council list it would be appreciated. There is a dispute about whether three lengthy lists of mostly non-notable names should be added to the article, per MOS:LIST. Thank you. Magnolia677 (talk) 21:49, 6 December 2022 (UTC)[reply]

    MOS:PF

    MOS:PF says: All ref tags should immediately follow the text to which the footnote applies, with no intervening space, with a note that they can be spaced apart from the preceding content by a hair space in the unusual case that the results of not spacing could be visually confusing, such as when a citation immediately follows an exponent. However, the section text itself uses hair spaces between plain words and ref tags: here{{hsp}}{{Dummy ref|10}} and London{{hsp}}{{Dummy ref|10}}. I don't think that not having these spaces would be "visually confusing". Thus, is it setting a bad example, or somebody believes that these spaces are really needed but forgot to properly describe this (not so) "unusual case"? — Mikhail Ryazanov (talk) 22:39, 12 December 2022 (UTC)[reply]

    I have the weird idea I may have put those {hsp}s there, but if so I have no idea why. I removed them. EEng 07:00, 13 December 2022 (UTC)[reply]
    OK, thanks! — Mikhail Ryazanov (talk)
    You're welcome! Herostratus (talk) 16:55, 13 December 2022 (UTC)[reply]

    Even if the page has been linked in nearby text, adding the same link within a caption has seemed common sense to me because some (many) readers only look at pictures (especially further down the article). I was reverted on one (first time that I can recall), and told it was against MOS. But I can't find anything about links on the WP and MOS pages for captions. Anyone know the quick answer? As usual I'll call upon the maestro of MOS, SMcCandlish. Thanks. Randy Kryn (talk) 21:25, 14 December 2022 (UTC)[reply]

    • Not the maestro, but I can tell you that in my experience, the admission of repeated links in infoboxes has been seen as a tacit green flag for them in captions. I think that's the only way the MOS has figured into it. Primergrey (talk) 03:45, 15 December 2022 (UTC)[reply]
    MOS:REPEATLINK explicitly allows for duplicate links in captions. oknazevad (talk) 03:50, 15 December 2022 (UTC)[reply]
    Right.  — SMcCandlish ☏ ¢ 😼  05:00, 15 December 2022 (UTC)[reply]

    Requested move Asian people > Asians

    Requested move that may be of interest: Talk:Asian_people#Requested_move_13_December_2022 Valereee (talk) 17:06, 18 December 2022 (UTC)[reply]

    It's more of a (somewhat socio-politicized) semantics argument than a style one.  — SMcCandlish ☏ ¢ 😼  14:04, 20 December 2022 (UTC)[reply]

    Short descriptions

    Does the MOS cover short descriptions anywhere? WP:SHORTDESC says that "All mainspace articles should have a short description" and WP:SDFORMAT gives some style advice. If correct, shouldn't these points be moved to the MOS? a455bcd9 (Antoine) (talk) 09:38, 19 December 2022 (UTC)[reply]

    Probably not. That's metadata, not part of the encyclopedic content.  — SMcCandlish ☏ ¢ 😼  09:46, 20 December 2022 (UTC)[reply]
    Hi @SMcCandlish: short descriptions are more than metadata: they appear in Wikipedia mobile and on desktop searches (see Wikipedia:Short description). They're similar to infobox content, covered by Wikipedia:Manual of Style/Infoboxes.
    The MOS only mentions short descriptions in:
    Please note that WP:VG/SHORTDESC is the video games MOS, even though the above quote seems to give general recommendations. So I would either:
    • Move that quote to a new section MOS:SD in WP:LEAD, or
    • Make WP:SHORTDESC part of the MOS (as the MOS already defers to this page regarding short descriptions)
    (and then maybe modify the aforementioned quotes if other contributors disagree with their recommendations)
    What do you think? a455bcd9 (Antoine) (talk) 10:42, 20 December 2022 (UTC)[reply]
    If "the MOS already defers to this page [WP:SHORTDESC] regarding short descriptions", then what is the problem you're trying to fix? I don't see that anything's broken. MOS also, for example, makes reference to article titles, and defers to WP:AT and various NC guidelines, but we don't feel a need to merge them. Same with citations and WP:CITE.  — SMcCandlish ☏ ¢ 😼  14:01, 20 December 2022 (UTC)[reply]
    OK perfect then, thanks @SMcCandlish! a455bcd9 (Antoine) (talk) 14:02, 20 December 2022 (UTC)[reply]

    Broken heading markup in the MOS

    Please don't embed the span class in a markup. For example:

    ===Apostrophes <span class="anchor" id="Foreign characters that resemble apostrophes"></span>===

    It breaks the link to the text in the edit history. -- Ancheta Wis   (talk | contribs) 11:47, 19 December 2022 (UTC)[reply]

    Fixed that one (with an anchor tag under the heading).  — SMcCandlish ☏ ¢ 😼  09:45, 20 December 2022 (UTC)[reply]
    {{Anchor}} is explicit that the span tag to anchor a section does go in the section-header. DMacks (talk) 20:08, 3 January 2023 (UTC)[reply]

    "earned" a degree or "received" a degree

    Not too long ago, I was reverted for changing a line in a biographical article from "earned a degree" to "received a degree". This has stuck in the back of my mind since. I always say "received" since "earned" makes a judgment about the merit of the person having the degree. There are certainly people who have degrees who did the bare minimum to get it, or had their degree conferred on nonacademic merits (some college athletes come to mind). I don't think it is Wikipedia's place to deem a degree "earned", and would propose that our guidelines should prefer merely saying someone has "received" a degree unless we are quoting a source that specifies that they "earned" a degree, or detailing the academic achievements by which they did so. BD2412 T 17:23, 20 December 2022 (UTC)[reply]

    Awarded a degree, surely? Betty Logan (talk) 18:24, 20 December 2022 (UTC)[reply]
    The normal English is 'took', as in "he took a first in Greats". Justlettersandnumbers (talk) 19:00, 20 December 2022 (UTC)[reply]
    But 'received' seems fine too; the awarding would be done by the college. Justlettersandnumbers (talk) 19:06, 20 December 2022 (UTC)[reply]
    Americans don't "take" degrees; that is British English and sounds like theft to me. In American English either received or earned is fine; "graduated with" is also common, as is "was awarded". Its all a matter of what sounds right to an editor, so the reversion was probably just a disagreement in style. StarryGrandma (talk) 19:21, 20 December 2022 (UTC)[reply]
    Also the "earned" is as in earned a paycheck - no merit involved, just completed the requirements. StarryGrandma (talk) 19:24, 20 December 2022 (UTC)[reply]
    Sometimes people receive a degree even though they didn't formally complete the requirements, in that they were allowed to skate through classes by lax professors. From the sources that usually report such biographical details, although we can guess that the degree was earned, we never really know. There are also people who receive a paycheck without completing the requirements to earn it. BD2412 T 20:52, 20 December 2022 (UTC)[reply]
    "Awarded" sounds a bit too colloquial to me. If we were writing from the standpoint of the institution, I would thing, "conferred" would be better. But either way we would then have to word these so that the subject was awarded the degree by the institution rather than our current common usage of received (or earned) the degree from the institution. BD2412 T 20:58, 20 December 2022 (UTC)[reply]
    I think we are dealing with WP:ENGVAR here, saying the same words but meaning different things. The English-speaking people divided by our common language. StarryGrandma (talk) 21:27, 20 December 2022 (UTC)[reply]
    I agree. "Received a degree" states a much more readily observable fact than "earned a degree". If someone has a diploma on the wall then, unless it's a counterfeit, I can conclude they received it, but only people who were in their vicinity at the time will be able to say with any confidence whether they earned it. Largoplazo (talk) 21:31, 20 December 2022 (UTC)[reply]
    I prefer "earned" whether or not it was with the minimum marks (many wooden spooners work hard). But I would prefer if the MOS was not overly prescriptive. Hawkeye7 (discuss) 23:00, 20 December 2022 (UTC)[reply]
    I mean, "earned" is just a common way of saying the thing, there's no implication of merit. One can earn a twenty-year prison sentence for instance, and that construction is common. One can earn a $100,000 salary even if she doesn't do much. One can earn a trip to the disabled list with an injury. And so on. You're defining "earned" too narrowly. It's all good, and the usual procedure for stuff like this is just use the the term you think best, give other writers the same courtesy, and if someone changes your word, either just roll your eyes and mutter "oh, brother" to yourself, or -- as is your perfect right -- roll it back and invite her to go to the talk page and convince us that her term is an improvement, and good luck with that. Herostratus (talk) 00:48, 21 December 2022 (UTC)[reply]
    “Earned” irks me too, and I often change it, but we’re not going to prescribe something like that in the MOS. — HTGS (talk) 17:46, 21 December 2022 (UTC)[reply]
    I thought degrees were “conferred”. Peacemaker67 (click to talk to me) 17:54, 21 December 2022 (UTC)[reply]
    The university (or the Archbishop of Canterbury) confers the degrees, but this is from the perspective of the student. Hawkeye7 (discuss)
    Ready???
    Terminal Boulevard
    EEng 22:07, 21 December 2022 (UTC)[reply]
    Does it have to be any of awarded/earned/received/whatevs? I usually just say "has a degree" if the subject comes up. --Vometia (talk) 09:51, 2 January 2023 (UTC)[reply]
    Has doesn't work if you want to give the year the person got it. EEng 14:09, 2 January 2023 (UTC)[reply]

    In the US, one will sometimes see employment ads that require applicants to have an "earned" degree. I think this is to distinguish those degrees that one obtains the normal way, by attending classes and perhaps doing supervised research, from honorary degrees, awarded because a person has become prominent in some way. Jc3s5h (talk) 22:19, 21 December 2022 (UTC)[reply]

    Meryl Streep being graduated from Harvard. "Thanks for the sheepskin! Now I gotta go peruse the want ads!"
    Are there really that many honorary degree recipients reading the want ads? EEng 01:25, 23 December 2022 (UTC)[reply]
    I suppose this also bears on the debate over "graduated from Harvard" vs "was graduated from Harvard". The latter was considered technically correct (in the days of prescriptive grammar). "Graduated from" is an exception, almost a sport, from the usual construction for these matters... we don't say "she elected to Congress" for instance. Being elected, appointed, arrested, hired, etc. are things done to you. For some reason, being graduated is considered different I guess. But that's silly IMO. You can meet all the requirements such that you will automatically get promoted to Mook 2nd Class, but we still say "she was promoted to Mook 2nd Class", not "she promoted to Mook to 2nd class". Sorry, but you have a 4.0 grade average, but somebody else has to sign the forms actually graduating you, and maybe they won't if you're a felon or something. Conversely, things that you really do do yourself are more direct: "she shot at". For some reason getting a degree has migrated from the "she was appointed to" section of the forest to the "she threw to" part. Why I don't know. Herostratus (talk) 06:59, 22 December 2022 (UTC)[reply]
    If it makes you feel any better, OED attests graduate as a v. intransitive, "To take a university degree" as early as 1807 (then calls out application to high schools as specifically US usage). EEng 01:18, 23 December 2022 (UTC)[reply]
    I would consider "earned a degree" to "received a degree" to be synonyms and therefore equally valid. "Graduated from XXX" would also be valid. As usual, I consider flipping between equally valid synonyms as editors changing the article to suit their own personal style/locale and discourage such changes - in the spirit of WP:RETAIN. "took a degree" sounds weird to my Australian ears, as though the university wasn't going to give it to them unless they forced it somehow - is that an American or UK thing? For the "earned" vs "easy course", well, as long as they fulfilled the course requirements then it was earned - it doesn't have to be a hard earned thing. And any mention of an honorary degree must have the word "honorary" mentioned - therefore the reader will automatically know that the degree is a gift to the receiver done without fulfilling the usual requirements (coursework, submitted papers/thesis, etc).  Stepho  talk  01:55, 23 December 2022 (UTC)[reply]
    Re 'took' - To me this is the same extremely common usage as in "take a chance", "a sabbatical" or "the bus" - indeed, "take an exam" (when not "sitting" one). And in AmEng Billy Strayhorn wasn't forcing New York to give him a whole subway line. But AusEng? Davidships (talk) 13:57, 23 December 2022 (UTC)[reply]

    Small caps in quotations

    Should MOS:CONFORM recommend that small caps formatting generally be preserved in quoted material? A recent edit by Libhye introduced such a rule. This puts this guideline in conflict with MOS:SMALLCAPS (part of MOS:CAPS), which advises "In quoted material, all caps or small caps for emphasis should be replaced with italic emphasis or, in an already italic passage, boldface". I'd love to see the change happen at both pages, or neither. Libhye mentioned Tony1 thanking them for the change, so a ping for them as well. Firefangledfeathers (talk / contribs) 05:37, 27 December 2022 (UTC)[reply]

    Addendum: it was actually a series of two edits which also changed the guidance on all caps and underlining/spacing within words. Firefangledfeathers (talk / contribs) 05:45, 27 December 2022 (UTC)[reply]
    Two things: small caps are one of four standard faces in each font: roman (normal), italic, bold, and small caps. Second, I don't think I like that business of replacing small caps with italics in quotations. Normal all-caps, yes—it's too much in your face. Tony (talk) 08:19, 27 December 2022 (UTC)[reply]
    Removing underlining, space ing within words, and all caps from MOS:CONFORM seems to go against many discussions here. I guess small caps have also been discussed, and they are certainly unwanted in MOS:ALLCAPS/MOS:SMALLCAPS. -- Michael Bednarek (talk) 08:49, 27 December 2022 (UTC)[reply]
    I'm not seeing consensus for the changes, and am planning to restore the status quo ante in a couple days if no one else chimes in. Happy to see further discussion, or another form of dispute resolution, but leaving up inconsistent guidance that's unsupported by consensus is untenable in the medium term. Firefangledfeathers (talk / contribs) 03:48, 31 December 2022 (UTC)[reply]
    I already restored the section "Typographic conformity" some days ago. -- Michael Bednarek (talk) 04:17, 31 December 2022 (UTC)[reply]
    I missed it! Thanks, MB. Firefangledfeathers (talk / contribs) 04:27, 31 December 2022 (UTC)[reply]

    Use of diacritics in page titles

    I have been overhauling several ancient history pages, and it appears to me that some of these will need to be renamed to fit their academically accurate names. The problem is that English Wikipedia does not seem to allow me to rename, for example, Yatie and Te'el-hunu to Yaṯiʿe and Teʾelḫunu, likely because of the diacritics used in these names even though there are existing pages where these diacritics are used. How can I deal with this issue? Antiquistik (talk) 11:37, 2 January 2023 (UTC)[reply]

    Is this desirable? This is the English language Wiki, and as such keeping to English versions of the name is likely to be of more use to our readers (remember WP:RF) than an obscure set of diacritics. I would leave the pages as they are, and add your "academically accurate names" in the lead. If you are really desperate to include these obscure names, try adding redirects. Martin of Sheffield (talk) 16:51, 2 January 2023 (UTC)[reply]
    I agree. Follow WP:COMMONNAME whenever possible and use redirects for not-so-common names. Masterhatch (talk) 17:02, 2 January 2023 (UTC)[reply]
    Don't use diacritics. GoodDay (talk) 17:16, 2 January 2023 (UTC)[reply]
    Sometimes use diacritics. See WP:DIACRITICS. It's complicated, but I read the core as "follow the general usage in reliable sources that are written in the English language". SchreiberBike | ⌨  17:44, 2 January 2023 (UTC)[reply]
    Thanks for the input, @Martin of Sheffield:, @Masterhatch:, @GoodDay:, and @SchreiberBike:. However, I will need to point out that these diacritics are very commonly used in the Romanisation of Semitic languages, including of Hebrew and Arabic, and are already used in the titles of articles relating to these languages, and these articles themselves are about relatively obscure historical figures with no universally agreed on common names other than their academically-accurate names, which aligns with what @SchreiberBike: is saying.
    And, while we are here on English Wikipedia, I do see that German Wikipedia, which therefore also doesn't use diacritics relating to the Romanisation of Semitic languages for the bulk of its articles, has been able to adequately use these diacritics in page names without it reducing the navigability of their platform.
    And, given that overhauling Wikipedia's ancient history entries will likely require the expansion of our coverage of linguistics and the possible creation of numerous pages with similar names, I would nevertheless appreciate if I could be provided with a way to use the appropriate diacritics in the page names while also using redirects when necessary to easy navigation by readers. Antiquistik (talk) 17:48, 2 January 2023 (UTC)[reply]
    Most titles with diacritics are possible and allowed, but you have to have certain level of adminship to move an article to a title with certain diacritics. Use the process described at WP:RM#TR if you think the move is uncontroversial, and an admin might move it for you. Indefatigable (talk) 18:03, 2 January 2023 (UTC)[reply]
    It's controversial. So, for me, you have an article "Yatie" which OP is saying should be at "Yaṯiʿe". Well but what good is "Yaṯiʿe" to me? I don't know what a "ṯ" is, what it is called, or how it is pronounced (altho I would guess "t"). "iʿe", what is that? "ie" is a dipthong, and now you're putting punctuation in the middle of a dipthong, the heck am I supposed to do with that. "Yatie" I can at least try to pronounce, it's presumably either "YAY-tee" or "YAH-tee" so I've a 50% chance of being in the right general area at least. If I see "Yaṯiʿe" I will do the work of stripping away the odd glyphs and end with "Yatie" I suppose, so at least there's that (unlike some other cases). But "not all that confusing, this time" isn't a high bar. You shouldn't need a college education to read the Wikipedia. Also, people can't search on "Yaṯiʿe" anyway. Herostratus (talk) 00:45, 3 January 2023 (UTC)[reply]
    Controversial. The main reason they were not used in our English language sources is that the typesetters lacked them, or found them a nuisance. This is increasingly not the case now that we have computers, but they create more problems. One that I'm constantly running into is code pages. Put simply, I cannot always cut and paste them in order to feed them to the bots or automated tools. (Don't get me started on the stupid ndash.)
    In addition, I would caution their use with modern languages. I have fielded complaints for the subjects of BLP articles (and the biographers of dead ones) that the use of glyphs is endorsing certain political perspectives ie claiming for the subject a nationality with which they do not wish to be associated. As such, I have removed them under WP:BLP, WP:NPOV and WP:COMMONNAME. Hawkeye7 (discuss) 02:03, 3 January 2023 (UTC)[reply]
    I figure it this way. If they ain't in the english alphabet? Then don't use'em. GoodDay (talk) 03:19, 3 January 2023 (UTC)[reply]
    The pages should be at their common name in English. If that is with diacritics, so be it. For example, the Yugoslav-American scholar Jozo Tomasevich is at that title, not Jozo Tomašević. However, that is probably because he published with that name in English, and used it in general. Many Yugoslav bios are at names that include diacritics because it is the most common way their names are rendered in English language sources. Throughout his extensive English works on Yugoslavia in WWII, Tomasevich consistently uses diacritics for names and places etc. So do Marko Attila Hoare, Sabrina Ramet and Stevan Pavlowitch in their works on the same time and place. Peacemaker67 (click to talk to me) 06:13, 3 January 2023 (UTC)[reply]

    Gluing/joining words and unspaced em-dashes together

    This is my first time participating in the MOS talk page, so please forgive me if I made any mistakes in this admittedly bikeshed-y question.

    Currently, part of the MOS's recommendation on the spaced en-dash's usage is as follows:

    Ideally, use a non-breaking space before the en dash, which prevents the en dash from occurring at the beginning of a line ...

    However, there is no recommendation like this for unspaced em-dashes, despite the fact that:

    • Line breaks can occur before em-dashes, meaning em-dashes can also occur in the beginning of a line like unspaced un-NBSPed en-dashes (to verify, try zooming-in in Dash#Em-dash; here's a screenshot)
    • There are "gluing characters" that we can use (accessible using {{zwj}} and {{Word joiner}}) to glue a word and an em-dash together, preventing em-dashes from occuring in the beginning of a line
    • We can also create a "gluing em-dash" template (as a parallel to {{snd}}) that uses one of the gluing-character templates/raw characters so that it can be easily added in pages

    Has there been a discussion before where this specific facet of unspaced em-dashes was discussed and voted against? Thank you for your patience! LightNightLights (talk) 14:33, 2 January 2023 (UTC)[reply]

    I've thought about such a thing but have never succeeded in figuring out which of the many joiner thingamajigs actually works on more or all browsers. More globally: I personally find spacing mishaps (like dash at the start of a line, or references to World War
    I    ) highly annoying, but it happens so infrequently, and the work that will be needed to formulate guidelines (not to mention the annoyance other editors will express at having MOS even more bloated for such a minor issue) has kept me from really getting into it. But I plan to, sometime between now and when I die -- see #Non-breaking_spaces_with_written-out_units on this very page. EEng 20:45, 2 January 2023 (UTC)[reply]

    User of logos - case: Sydney Opera House

    Hi there - a question on whether there is a Wikipedia position on using logos in infoboxes. In particular, as seen here on the Sydney Opera House article (logo on top of info box). To me, it looks out of place and a distraction to the article. I'm inclined to remove it, but would like to consider any other opinions first. thanks --Merbabu (talk) 00:48, 5 January 2023 (UTC)[reply]

    It's pretty standard to include a small version of the logo in the infobox. See for example Argos_(retailer) (taken purely at random). I'd leave the opera house logo exactly as it is, remove it and I'd guess you'll be reverted fairly quickly. Martin of Sheffield (talk) 08:48, 5 January 2023 (UTC)[reply]
    OK thanks for your comments. I should have mentioned, it's only appeared in recent months. With no discussion in support or against.--Merbabu (talk) 09:01, 5 January 2023 (UTC)[reply]
    PS - I'd be keen to see whether there are other famous buildings with similar logos in Infoboxes. Hopefully there are more closer examples than an online retailer (Argos). --Merbabu (talk) 09:03, 5 January 2023 (UTC)[reply]
    Would the Royal Opera House be a good example? Martin of Sheffield (talk) 09:19, 5 January 2023 (UTC)[reply]
    I suspect the Sydney Opera House logo won't stay in that article article much longer; see c:Commons:Deletion requests/File:Sydney Opera House logo.svg. -- Michael Bednarek (talk) 11:56, 5 January 2023 (UTC)[reply]
    • The Royal Opera House infobox suffers from a bad case of Harry Elkins Widener Syndrome and looks utterly ridiculous. Similarly, readers will be puzzled by the presence of the black-paper silhouette cutout right about the photo of the Sydney Opera House in real life -- they won't recognize it as a logo. A logo makes sense for an entity without a single recognizable location -- a chain retailer, for example -- but in cases such as these two, it's infobox overload. EEng 13:38, 5 January 2023 (UTC)[reply]

    Colored-underlining links in example-text templates

    Admittedly, this is a minor issue on the grand scheme of things, but I think it might help (albeit only a little bit) if, in the Manual of Style, we underline wikilinks in example-text templates like {{xt}} and {{!xt}} with the color of that example-text template. It would help readers distinguish if an example text is allowed or disallowed ({{xt}} or {{!xt}}) without having to check the page's source text and, in my opinion, simply helps with readability by just that much.

    For reference, here are some underlining styles if we do end up implementing this (taking an example from MOS:NUMNOTES):

    LightNightLights (talk) 20:53, 6 January 2023 (UTC)[reply]

    Clarification on the publication of business addresses

    Would it be possible to clarify Wikipedia's position on the reproduction of business addresses on this page, specifically when published by reliable sources? Without wading this discussion down in political details, there are instances I can link to where the business address of one organisation has been included in their article, but the same information has been explicitly excluded from others, citing doxing/potential real-world harassment concerns. So either posting business addresses is OK or should be discouraged across the board. I've been a Wikipedian for over 15 years, but even I'm not sure if this is the correct page to ask this question, or if any particular user has the right to make this sort of sweeping change. An RfC maybe? But I believe this issue needs to be addressed one way or the other. Homeostasis07 (talk/contributions) 01:44, 13 January 2023 (UTC)[reply]

    This question is being asked in the context of LGB Alliance, a group that has taken office space at 55 Tufton Street, and the association of this address with numerous right-wing, libertarian, pro-Brexit groups of dubious/opaque financing has been the topic of over 1000 news articles (search Google News for "Tufton Street"). Some editors are trying to censor this information wrt LGB Alliance, edit warring over its mention and trying to delete Category:Tufton Street, etc. Of course, those editors are not at all concerned that all the articles we have on the other notorious residents of that address are on Wikipedia and all these addresses are publicly available records such as Ofcom or Company House. That LGB Alliance has taken an office at 55 Tufton Steet is recorded at the organisation's own article, at the 55 Tufton Street article, in a number of newspaper articles, at OfCom's public website and hundreds of other websites (if google search results are to be believed). This is hardly a doxing issue. -- Colin°Talk 08:00, 13 January 2023 (UTC)[reply]
    I agree. Doxing would be about making private or hard to collate public information easily available. That isn't the case here. Moreover, I would say that in this instance, removing mention of 55 Tufton Street is simply not justified because reliable sources have mentioned the connection as something significant, such as here, here, and here (an opinion piece, but a statement of fact is made in the piece). Most articles on the other organisations housed at 55 Tufton St mention it because, as Colin says, it's something reliable news and political media talk about. It's true that LGB Alliance didn't want their connection to 55 Tufton Street made public, but I don't think it's Wikipedia's job to help them suppress information in the public domain and now publicised and commented on in RS. OsFish (talk) 09:16, 13 January 2023 (UTC)[reply]

    Long dash confusion

    MOS:EMDASH contradicts itself. First it says, "An em dash is unspaced." Then it shows, "The birds – at least the ones Darwin collected – had red and blue feathers," I am confused, should the mdash be spaced or not? Comfr (talk) 07:06, 13 January 2023 (UTC)[reply]

    That appears to be an en-dash, not an em-dash. You should be able to tell that it's a bit shorter: en-dash is "–", em-dash is "—". When used in the way you quote, en-dashes are spaced, but em-dashes are unspaced. And now I'm wondering what happened to the ell-dash, for when we want them extra-long. —David Eppstein (talk) 07:29, 13 January 2023 (UTC)[reply]
    Thanks for clearing this up. I wish mediawiki had a tool for distinguishing between similar characters. Sometimes I must resort to using a hexadecimal editor to tell what I am editing. Comfr (talk) 08:15, 13 January 2023 (UTC)[reply]
    David Eppstein, I don't know if it's an ell-dash, but I made {{long dash}} a while ago. It doesn't seem to be much used. Justlettersandnumbers (talk) 08:47, 13 January 2023 (UTC)[reply]
    Justlettersandnumbers, from the fact that David set it in small type I think this is a joke. Historically en-dashes were the same width as the letter "n" and em-dashes as "m". That would make a putative ell-dash rather narrow! Martin of Sheffield (talk) 09:00, 13 January 2023 (UTC)[reply]
    I thoght he meant the ell-dash (for when we want them extra-long) would be an ell in length. DuncanHill (talk) 21:22, 15 January 2023 (UTC)[reply]
    Twinkle, when turned on and in editing mode, helpfully marks dashes with an 'm' or 'n', while leaving hyphens unmarked. Other parsers might do the same. Dhtwiki (talk) 15:29, 13 January 2023 (UTC)[reply]

    First and third questions on the FAQ use inconsistent reasoning

    The first question on the FAQ says that we use straight quotation marks because they are easier to type, even though curly quotes are considered smarter. The third question on the FAQ says that we use different characters for different kinds of hyphens/dashes because it's smarter even though the hyphen (-) is easiest to type. Why the inconsistency?? Georgia guy (talk) 18:25, 14 January 2023 (UTC)[reply]

    Plural(s) vs Plural/s

    As the title shows, there are two ways to type the possible plurality of a noun. Orange(s) OR Apple/s. Which is correct? I believe the first is more common but still... also, maybe this should be added to the MOS? 3point1415 (talk) 21:03, 15 January 2023 (UTC)[reply]

    Far be it from me to proclaim one type of signifier "correct" but generally I have seen Orange(s) more commonly than Apple/s. I'd say it should be added to the MOS considering how these things can be interpreted differently by people who haven't encountered them before.
    JBrahms (talk) 02:43, 25 January 2023 (UTC)[reply]

    Elementary school

    I'm wondering what the policy is on school type naming. Should the first school be referred to elementary school or primary school. TheHaloVeteran2 (talk) 16:23, 18 January 2023 (UTC)[reply]

    This could be a ENGVAR situation. I know that “Elementary” is sometimes used in the US (as is “Primary”) but is it used in the UK or other parts of the world? Perhaps both/either is acceptable. Blueboar (talk) 16:35, 18 January 2023 (UTC)[reply]
    English and Welsh usage is "Primary" which is usually split into infants (up to 7) and junior (8-11). I'm not sure about the Scottish system which does differ in some respects from England. Martin of Sheffield (talk) 16:51, 18 January 2023 (UTC)[reply]
    I don't know the usage elsewhere, but in the US the nomenclature is highly Balkanized, at least partially due to the federal structure of the government, with schools being the responsibility of state and local governments. All of these exist
    • K-8-4
      1-8
      Elementary school
      9-12
      High school
    • K-6-3-3
      1-6
      Elementary school
      7-9
      Junior High School
      10-12
      Senior High School
    • K-5-3-4
      1-5
      Elementary school
      6-8
      Middle school
      9-12
      High school
    among others, depending on location and year. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:58, 18 January 2023 (UTC)[reply]

    Propose moving the shortcut MOS:COMPNOW and WP:COMPNOW to the section "Verb Tense".

    Both MOS:COMPNOW and WP:COMPNOW currently are shortcuts that take the reader to the page Wikipedia:Manual of Style/Computing (failed proposal). And although the page proposal failed for technical reasons, the section about "tense" is still a sound principle and is supported by the wording within MOS:TENSE which states By default, write articles in the present tense, including those covering works of fiction... and products or works that have been discontinued.

    I may also suggest moving some of the wording from MOS:COMPNOW to this MOS as well. Such as Always use present tense for verbs that describe genres, types and classes, even if the subject of the description (e.g. program, library, device) no longer exists, is discontinued or is unsupported/unmaintained. JOJ Hutton 10:40, 20 January 2023 (UTC)[reply]

    Why not the precomposed ellipsis character?

    Wikipedia's style for an ellipsis is three unspaced dots (...); do not use the precomposed ellipsis character (…)

    I understand this is the policy, but why is that Wikipedia prefers unspaced periods over the designated ellipsis character? Thanks – Olympian loquere 03:34, 21 January 2023 (UTC)[reply]

    I have no idea why WP does that, but I think we're trying to follow most style guides, which strongly prefer either three unspaced dots or three spaced dots in formal written English. The ellipsis in one character looks quite tacky. --Coolcaesar (talk) 15:47, 21 January 2023 (UTC)[reply]

    Should the "then-[title] [name]" construct be hyphenated or not?

    For example, "her then-husband Joe". 'Then-husband' seems to be a compound modifier, and according to MOS:HYPHEN #3 should be hyphenated. However, according to at least one style guide, this construct should not be hyphenated. If it shouldn't be I think we should mention this in the MoS. Ping User:Jonesey95. –CWenger (^ • @) 21:37, 21 January 2023 (UTC)[reply]

    to previous discussion on my talk page. Here's an adapted version of what I said there: Nobody would write "the future-president Jane Smith" (for "Jane Smith, who would in the future become president") or "her Italian-boyfriend John Brown" (for "John Brown, her boyfriend, who is Italian"). The word "then" works the same way in this context. It is confusing because "then" is usually an adverb, so our brains get stuck in the wrong frame. This discussion originated from edits to Rachel Bilson. I linked to two mainstream style guides in my edit summaries there: National Geographic's, and the Cambridge Dictionary. These were the most mainstream style guides I could easily find on-line. I'll dig up some books if necessary. – Jonesey95 (talk) 00:49, 22 January 2023 (UTC)[reply]
    How would you formulate this as a rule though? I agree 'then' is an adjective here but as I said before, it's not that the [adjective]-[noun] [noun] construct that doesn't get hyphenated, because we have short-story writer in the MoS. –CWenger (^ • @) 01:10, 22 January 2023 (UTC)[reply]
    For what it's worth, the phrase then-President is used by White House and by Axios, itself quoting a judge's opinion. This is also used by NOAA, the DOJ, Department of State, and the University of Ohio. Then-husband is more hit-or-miss but is used by organizations that would follow style guidelines of their own, but I think if there were a convention against the hyphen then all these institutions wouldn't be using one in this instance. (Rolling Stone, apparently in a mad bid to give me a headache, uses the phrase then-future President Trump) - Aoidh (talk) 01:20, 22 January 2023 (UTC)[reply]
    Also the Cambridge Dictionary is ambiguous because its example is: I wanted to live in the city, but my then husband preferred the country. There is no compound modifier in that sentence so I am not arguing for hyphenation in that instance. –CWenger (^ • @) 03:07, 22 January 2023 (UTC)[reply]

    Clarifications on captions format

    MOS:CAPTION says: The text of captions should not be specially formatted, except in ways that would apply if it occurred in the main text (e.g., italics for the Latin name of a species). Does this imply that manual centering (which anyway doesn't work properly in thumb captions), using boldface to imitate "a caption title", hard-coded line breaks and so on are also forbidden? For example, this edit obviously violates MOS:REFSPACE and MOS:SMALL; but are {{center}} and ''' there also against MOS:CAPTION in general? And what about adding obvious interface remarks like <small>(click to enlarge)</small> here? Mikhail Ryazanov (talk) 20:44, 22 January 2023 (UTC)[reply]

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