Misplaced Pages

Revision as of 09:59, 5 December 2022

faq page Frequently asked questions Misplaced Pages's Manual of Style contains some conventions that differ from those in some other, well-known style guides and from what is often taught in schools. Misplaced Pages's editors have discussed these conventions in great detail and have reached consensus that these conventions serve our purposes best. New contributors are advised to check the FAQ and the archives to see if their concern has already been discussed. Why does the Manual of Style recommend straight (keyboard-style) instead of curly (typographic) quotation marks and apostrophes (i.e., the characters " and ', instead of “, ”, ‘, and ’)‍? Users may only know how to type in straight quotes (such as " and ') when searching for text within a page or when editing. Not all Web browsers find curly quotes when users type straight quotes in search strings. Why does the Manual of Style recommend logical quotation? This system is preferred because Misplaced Pages, as an international and electronic encyclopedia, has specific needs better addressed by logical quotation than by the other styles, despite the tendency of externally published style guides to recommend the latter. These include the distinct typesetters' style (often called American, though not limited to the US), and the various British/Commonwealth styles, which are superficially similar to logical quotation but have some characteristics of typesetters' style. Logical quotation is more in keeping with the principle of minimal change to quotations, and is less prone to misquotation, ambiguity, and the introduction of errors in subsequent editing, than the alternatives. Logical quotation was adopted in 2005, and has been the subject of perennial debate that has not changed this consensus. Why does the Manual of Style differentiate the hyphen (-), en dash (–), em dash (—), and minus sign (−)? Appropriate use of hyphens and dashes is as much a part of literate, easy-to-read writing as are correct spelling and capitalization. The "Insert" editing tools directly below the Misplaced Pages editing window provide immediate access to all these characters. Why does the Manual of Style recommend apostrophe+s for singular possessive of names ending in s? Most modern style guides treat names ending with s just like other singular nouns when forming the possessive. The few that do not propose mutually contradictory alternatives. Numerous discussions have led to the current MoS guidance (see discussions of 2004, 2005, 2005, 2006, 2006, 2007, 2008, 2008, 2008, 2009, 2009, 2009, 2012, 2013, 2015, 2016, 2017, 2017, 2017 (the RfC establishing the present consensus), 2018, 2018, 2019, 2021, 2022). Why doesn't the Manual of Style always follow specialized practice? Although Misplaced Pages contains some highly technical content, it is written for a general audience. While specialized publications in a field, such as academic journals, are excellent sources for facts, they are not always the best sources for or examples of how to present those facts to non-experts. When adopting style recommendations from external sources, the Manual of Style incorporates a substantial number of practices from technical standards and field-specific academic style guides; however, Misplaced Pages defaults to preferring general-audience sources on style, especially when a specialized preference may conflict with most readers' expectations, and when different disciplines use conflicting styles.

Discussions on this page often lead to previous arguments being restated. Please read recent comments, look in the archives, and review the FAQ before commenting.

Manual of Style

This page falls within the scope of the Misplaced Pages: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 This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Misplaced Pages 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. For information on Misplaced Pages'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 Misplaced Pages policies of Misplaced Pages's policy and guideline documents is available, offering valuable insights and recommendations.

Archives

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 31, 32, 33, 34, 35, 36, 37, 38, 39, 40 41, 42, 43, 44, 45, 46, 47, 48, 49, 50 51, 52, 53, 54, 55, 56, 57, 58, 59, 60 61, 62, 63, 64, 65, 66, 67, 68, 69, 70 71, 72, 73, 74, 75, 76, 77, 78, 79, 80 81, 82, 83, 84, 85, 86, 87, 88, 89, 90 91, 92, 93, 94, 95, 96, 97, 98, 99, 100 101, 102, 103, 104, 105, 106, 107, 108, 109, 110 111, 112, 113, 114, 115, 116, 117, 118, 119, 120 121, 122, 123, 124, 125, 126, 127, 128, 129, 130 131, 132, 133, 134, 135, 136, 137, 138, 139, 140 141, 142, 143, 144, 145, 146, 147, 148, 149, 150 151, 152, 153, 154, 155, 156, 157, 158, 159, 160 161, 162, 163, 164, 165, 166, 167, 168, 169, 170 171, 172, 173, 174, 175, 176, 177, 178, 179, 180 181, 182, 183, 184, 185, 186, 187, 188, 189, 190 191, 192, 193, 194, 195, 196, 197, 198, 199, 200 201, 202, 203, 204, 205, 206, 207, 208, 209, 210 211, 212, 213, 214, 215, 216, 217, 218, 219, 220 221, 222, 223, 224, 225, 226, 227, 228

This page has archives. Sections older than 60 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

Style discussions elsewhere

This section is pinned and will not be automatically archived.

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)

• Misplaced Pages talk:Manual of Style/Infoboxes#RfC about exceptions to WP:INFOBOXPURPOSE and commanders/leaders in Template:Infobox military conflict
• Misplaced Pages talk:Organizing disambiguation pages by subject area#RfC: make this page a guideline – proposal to elevate essay to guideline status; possibly merge to MOS:DAB.
• Misplaced Pages talk:Manual of Style/Biography#Neopronouns RfC – several options under discussion, including singular they, using neo-pronouns like xie, always referring to subject by surname, etc.
• Misplaced Pages talk:Manual of Style/Linking#RfC about hatnote links to Simple English Misplaced Pages – followup to a TfD
• Talk:Proto-Indo-European homeland#BCE or BC – another MOS:BCE question
• Misplaced Pages talk:Manual of Style/Icons#Flags in tables of national subdivisions – should subnational flags be used in such tables?
• Misplaced Pages talk:Manual of Style/Icons#Sub-national flags used in lists of national beauty pageant contestants – ditto
• Talk:Staffordshire Bull Terrier#Quotes RfC – two quotes were removed, should they remain in the article?
• Talk:Winston-Salem, North Carolina#RfC about Info Box – involves MOS:INFOBOX and MOS:ICONS and should be a broader discussion than just about this single article. Summary: about 50% of our US city articles include highway signs in the infobox, which is very inconsistent.
• Misplaced Pages talk:Manual of Style/Trivia sections#Does this guideline (and its section MOS:POPCULT) apply to stand-alone lists or "in popular culture" articles?
• mw:Reading/Web/Desktop Improvements/Third prototype testing – WMF seeks feedback on draft new WP layout, ToC, menus, etc. It's worth paying close attention to all elements on the page and submitting meaningful feedback about them (handling of text flow and infoboxes, presentation of block quotations, etc., etc.), not just the specific things the feedback form asks about.

Capitalization-specific:

Move requests:

• Talk:Philippine Offshore Gaming Operator#Requested move 13 January 2025 – Use sentence case?
• Talk:Bodhi Tree#Requested move 11 January 2025 – Lowercase "tree"?
• Talk:Rapperholic Concert#Requested move 10 January 2025 – Lowercase or omit "concert"?
• Talk:Adlersky City District#Requested move 10 January 2025 – Lowercase "city district" on 4 city districts of Sochi?
• Talk:Slab-grave culture#Requested move 28 December 2024 – Capitalize Slab Grave?
• Talk:Tri-State tornado outbreak#Requested move 18 December 2024 – Was this a "Tri-State tornado outbreak" or a "tri-state tornado outbreak"?
• Talk:Island Cove (Cavite)#Requested move 17 December 2024 – Should this be called the Island Cove POGO Hub or Island Cove POGO hub?

Other discussions:

• Talk:Syrian civil war#Capitalisation of Iraqi civil war - lowercase?
• Talk:Fullbore target rifle#Major rework – Is it too risky to ask people who are carrying firearms to use lowercase?
• Misplaced Pages talk:Article titles#Request for comment on the relationship between WP:CRITERIA and WP:TITLEFORMAT
• Talk:Dorothy Kilgallen#Capitalization of the word mass – "her funeral Mass" vs "her funeral mass"
• Talk:Julian (emperor)#Capitalization of "emperor" – should "emperor" be capped when referring to a specific person?
• Misplaced Pages talk:Naming conventions (ethnicities and tribes)#Indigenous – continuation of an RM discussion on capitalization of "indigenous"
• Talk:War on terror#Capitalisation of "global war on terrorism" in prose
• Misplaced Pages talk:Manual of Style/Music#THEBAND disambiguators – what to do about "The" in parenthetical disambiguators?
• Talk:F1NN5TER#Capitalization – Should the online persona be called "F1NN5TER", "F1nn5ter" or "Finnster"?
• Misplaced Pages talk:Naming conventions (geographic names)#Capitalisation of "oblast" when used as the name of a Ukrainian administrative division – May affect other administrative divisions (e.g. raion) and other nations for which such terms are used

Pretty stale but not "concluded":

• Talk:Upstate New York#Other plausible capitalization issue – Capitalization of "Upstate" New York.
• Talk:Southern Italy#Lowercase or uppercase? – Capitalisation of "southern". Also "northern" and "central" in related articles.
• Misplaced Pages talk:Naming conventions (capitalization)#Capitalization of geologic names – Despite being opened on an NC talk page, this is about usage in general not just in our article titles.
• Talk:Fall of Saigon#Names section and capitalisation – capitalisation of Vietnamese language names and capitalisation of their English translations?
• Talk:Union Jack#Case consistency – Union Flag, or Union flag?

Concluded

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)

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

  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)

  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)

  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)

  Ping to prevent archiving. EEng 12:49, 27 March 2020 (UTC)

  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)

  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)

  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)

  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)

  The most recent diff before I withdrew upon EEng's suggestion was . 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)

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)

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)

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

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)

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

• 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 = 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)

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)

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)

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

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)

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 Misplaced Pages 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)

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)

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)

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)

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

NBSP for numeric followed by words

Hi all, I recently put up Misplaced Pages: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 14:19, 10 July 2020 (UTC)

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)

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)

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

  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)

  Perhaps that was meant to be "stuck", the synonym for "put". —⁠ ⁠BarrelProof (talk) 23:58, 13 August 2021 (UTC)

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

  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)

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

  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)

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

Looking at that on my screen, the   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)

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)

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)

Does this still need to remain unarchived?

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

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)

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)

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)

Footnotes should appear before a colon, just like dashes

I updated a woefully outdated page about the certificate of analysis (COA), and I have a section with five footnotes followed by a colon, followed by the corresponding bullets. A bot came along and moved only the first citation in front of the colon and ignored the rest. That's one problem. The next is that, and I argue, footnotes should appear before the colon when a subsequent bulleted list follows. Just like the exception for dashes, an exception for footnotes before colons should be made. Using my example of the COA:

"Broadly speaking, however, the following represent elements that may be common to a COA:" followed by bulleted items

The referenced claim is that "there are indeed elements that are common to a COA." The footnotes back up THAT specific claim, that there are elements common to a COA. The bullet points after the elements, as previously cited, are an extension of that claim, but arguably the footnotes belong with the initial claim about elements of a COA, just like the footnotes should appear with the claim made before an end dash appears. I hope I explained my case. At a bare minimum, if footnotes after a colon is non-negotiable, the bot needs to move all the footnotes after the colon, not just one.

Lostraven (talk) 15:08, 28 September 2022 (UTC)

The "exception" link above should be: exception. The bot edit is here; pinging NicoV regarding the WikiCleanerBot bug.  MANdARAX  XAЯAbИAM  15:45, 28 September 2022 (UTC)

I suspect the bot was confused by the unbalanced quotation mark in <ref name=CTCalCode22" />.  MANdARAX  XAЯAbИAM  15:54, 28 September 2022 (UTC)

Hi Lostraven and Mandarax.

• As Mandarax said, only one citation was moved because the following one has unbalanced quotation mark, so the bot didn't consider it as a reference. So it should be a very rare case.
• I see no mention of this exception in the MOS, and if I understand your point it should be also the case if the reference was applying to the last part of a sentence with an ending dot, but it's not the case: even if a citation applies to only the end of the sentence, then the citation is still after the terminal dot. --NicoV 17:43, 28 September 2022 (UTC)

"I see no mention of this exception..."

It's linked above. It states: "Exceptions: Ref tags are placed before dashes, not after." I continue to argue that, just like dashes, ref tags should appear before colons. Lostraven (talk) 21:21, 29 September 2022 (UTC)

I see no reason these two cases (dashes and colons) should be treated as equivalent. In saying that, I would prefer superscript references were not placed next to these punctuation marks on either side, wherever possible. — HTGS (talk) 00:50, 29 September 2022 (UTC)

Footnotes go after the colon, always, even though the footnote might only source the material before the colon, just like footnotes go after a period, always, even though the footnote might only source the material before the period. —David Eppstein (talk) 01:33, 29 September 2022 (UTC)

We don't need any more exceptions to the general rule, which has served us well, and the exceptions to which already lead to enough confusion and debate.  — SMcCandlish ☏ ¢ 😼  08:09, 18 October 2022 (UTC)

Capitalization in astrological sign infoboxes

Using Pisces (astrology) as an example, there are some things in the infobox that are correctly capitalized. Dictionary.com agrees that Pisces should be capitalized whether it is referring to the sign or the constellation. It's also correct to capitalize the name of the planets. But what about the symbol? User:64.222.135.42 claims it should be "Two Fish" while I think it should be "two fish". Similarly, I see now reason to capitalize the element (water) or quality (mutable).

Is there anything about them being in an infobox that would lead to different capitalization than if they were in running text?

A complicating factor is that while the name and the constellation are used in both astronomy and astrology, so there are numerous high quality sources to refer to. But the element, quality, domicile, exaltation, fall, and detriment have no scientific basis and are based on magical thinking, so it's hard to find a reliable source about them. Jc3s5h (talk) 15:59, 6 October 2022 (UTC)

I'd expect them to be lower case. Compare something like silver, with "Appearance: lustrous white metal" "Group: group 11" "Period: period 5". MOS:CAPS says "only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized". If you are finding that some sources capitalise these concepts and others don't, then that standard hasn't been reached.

Using capitals to indicate the specialness of a particular term is explicitly verboten by MOS:EMPHCAPS ("This includes over-capitalization for signification, i.e. to try to impress upon the reader the importance or specialness of something in a particular context").

(side note: astrology is obviously nonsense, but I think that published works on it could be reliable sources for capitalisation even though they are not reliable sources for, y'know, how the universe actually functions). Furius (talk) 21:03, 6 October 2022 (UTC)

But if a major supermajority of all sources, not just astrology specialized sources, don't capitalize it, then we wouldn't either (see WP:Specialized style fallacy). That said, my own reading suggests to me that use of these names (Virgo, Pisces, et al.) in a purely astrological sense is almost universally capitalized (e.g. in newspapers, etc.), whether we'd all like that or not.  — SMcCandlish ☏ ¢ 😼  08:08, 18 October 2022 (UTC)

Clarification on MoS foreign-language quotations in non-Latin scripts

The Wiki Manual of Style states "When editors themselves translate foreign text into English, care must always be taken to include the original text, in italics (except for non-Latin-based writing systems), and to use actual and (if at all possible) common English words in the translation."

I interpreted this part of the MoS to mean that an original text of non-Latin script should be included and that that original text should not be italicized. Another Wiki editor interpreted this part of the MoS to mean that original texts in non-Latin scripts should not have the original included at all. Please clarify what is meant here. BlakeALee (talk) 23:00, 7 October 2022 (UTC)

The original text of non-Latin script should be included and that original text should not be italicized. One sees this frequently with Ancient Greek, Cyrillic, and Chinese throughout the wiki. (there is a policy to exclude the script for Indic languages WP:INDICSCRIPT, but that is a special policy for that context only) Furius (talk) 23:09, 7 October 2022 (UTC)

Thank you. BlakeALee (talk) 00:40, 9 October 2022 (UTC)

When there are two scripts used for the same language, and only one is in modern use, should the archaic form be replaced by the modern form? E.g., should an editor use the Aramaic alphabet for a Hebrew text originally in Canaanite script? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:20, 9 October 2022 (UTC)

I *feel like* that's something that should be decided on a case by case basis. E.g. if the article is about an inscription and gives the original text of it, I'd think you'd give it in the original script. But if it is an article about weaponry and you quote the inscription for the name of a type of sword, I'd give it in the script people commonly read... Or just in transliteration. I don't think it makes sense to have a blanket rule. Furius (talk) 16:24, 9 October 2022 (UTC)

Even if only an archaeologist or biblical scholar would be able to read the original? Would it be appropriate to give the text in both script?

As an example, in Tetragrammaton, some inscriptions for יהוה use the Canaanite alphabeth, which is unintelligible to most modern readers of Hebrew. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:45, 10 October 2022 (UTC)

Yes, that's my point. One can't and shouldn't generalise. It depends totally on the individual case. Furius (talk)

In answer to the original question, "(except for non-Latin-based writing systems)" applies only to "in italics" (which we do not apply to Cyrillic, etc.), or there would be no comma before "in italics". It was punctuated carefully for a reason. On the broader question that's developed, of what languages/scripts to use, I agree with Furius that a blanket rule is not something to make here. It's a matter of contextual relevance and is going to vary on a case-by-case basis.  — SMcCandlish ☏ ¢ 😼  08:17, 18 October 2022 (UTC)

Redundant "birth_name" in infoboxes

Too much often I do this kind of a very obvious edit: removing the redundant "birth_name" from an infobox when it exactly matches the current name.

Of course I've never met any objections, and I've even made my pattern to describe my edits in edit summaries ('"birth_name" is redundant since he never changed it').

Yet we better avoid such questions altogether by explicitly stating that these claims are redundant. And since the biographical infoboxes are numerous, the best place to put a summary seems to be the MoS. With a shortcut to use instead of my rather clumsy current practice.

So, let's decide on a wording and where exactly to put it.

How about this one:

There shouldn't be |birth_name= (or similar) parameter in infobox of a person who never changed it.

And the place?

I guess the right place would be below MOS:BIRTHNAME, just to clarify it. (With its own shortcut).

Feel free to suggest something else on both wording and location.

Ping to (may I already call you my friends?) SMcCandlish and EEng. — Mike Novikoff 20:30, 10 October 2022 (UTC)

• WP:MOSBLOAT -- you just said there's never been a problem over this. And the doc for Infobox Person says only use if different from name. EEng 21:17, 10 October 2022 (UTC)

  Yes, I have been removing redundant birth names for years from all kinds of bios based on that statement in {{infobox person}} and have never received any objection. I don't see a problem either. There is a related issue that could be addressed if someone had the inclination. Some sports biography infoboxes have |full_name=. I have removed that when identical using the same rational and been reverted because some sports editors believe it somehow minimizes name vandalism by having the field filled in rather than left blank. MB 21:58, 10 October 2022 (UTC)

  you just said there's never been a problem – Not really. You see, "no objections to my edits" is not equal to "no problems". The problem is that I have to do these edits. (And I don't use any advanced search, so I surely miss a lot of cases.) {{Infobox Person}} doc is fine, yet many articles use other templates that don't even mention this. — Mike Novikoff 22:41, 10 October 2022 (UTC)

  Well, it is redundant and should be removed. Don't leave a blank parameter in there, just remove the parameter entirely. I don't have any objection to adding a one-sentence instruction about this in MoS as suggested above.  — SMcCandlish ☏ ¢ 😼  22:44, 10 October 2022 (UTC)

  Add an instruction to MOS? Sandy, do you have a fever? EEng 01:10, 11 October 2022 (UTC)

  Thank you! Yes, I do usually remove the parameter entirely. — Mike Novikoff 22:55, 10 October 2022 (UTC)

  Let me make a better suggestion: add a hidden comment, <!--leave empty since same as subject's common name-->. EEng 01:10, 11 October 2022 (UTC)

  It's a job to be done. Not in the articles (I've always appreciated your sense of humor), just in the (have I already said that?) very numerous templates. — Mike Novikoff 18:45, 18 October 2022 (UTC)

• My general feeling is that the proper place for documenting parameters of templates would seem to be either the template documentation or the comments in the sample templates that are usually used to fill these in, rather than in the MoS where the people filling them in won't see them. —David Eppstein (talk) 01:54, 11 October 2022 (UTC)
• I agree this needn't be in the MOS. I feel there's probably a simple technical solution: don't display birth_name in the rendered infobox it's the same as their usual name. pburka (talk) 02:50, 11 October 2022 (UTC)

  Excellent idea. EEng 03:17, 11 October 2022 (UTC)

  An idea is excellent indeed, yet it might be hard to implement it. What will you compare your ${A} to? Just one example regarding the Russian names: they always have a patronym, it is always mentioned in the lead (and tends to be in an infobox too) but never in the article's name. How do you parse that? With Lua maybe (though I'm not sure there either), surely not with the conventional dumb template language. — Mike Novikoff 18:20, 18 October 2022 (UTC)

  It's not necessary that the comparison work perfectly in all cases. If the two forms of the subject's name are equal, then it will detect that and suppress. If not, well, no harm done. EEng 19:20, 18 October 2022 (UTC)

  Agreed, it would definitely be better than nothing if you as a template editor implement even a simplest case. — Mike Novikoff 20:28, 18 October 2022 (UTC)

  Plus you're moving goal posts. The original problem said "when it exactly matches the current name." If that's really a frequent occurrence, we can deal with it technically, and I think we can all agree that identical names don't belong in birth_name. Variants require more judgment. pburka (talk) 20:15, 18 October 2022 (UTC)

See previous discussions for Template talk:Infobox person/Archive 30#Birth name parameter and Template talk:Infobox person/Archive 36#Birth name parameter. 191.112.53.57 (talk) 03:28, 12 October 2022 (UTC)

What is the target for WP:Clarity?

Misplaced Pages:Clarity redirects to this page, but there is no section target for it to land on. Where should it link to? – Jonesey95 (talk) 23:30, 11 October 2022 (UTC)

In other words, there's a lack of clarity. Ironically enough. GoodDay (talk) 23:34, 11 October 2022 (UTC)

It links to the {{anchor}} in the lead. The original section has been removed. DrKay (talk) 07:23, 12 October 2022 (UTC)

MOS:PREFIXDASH doesn't include instructions

The MOS:PREFIXDASH section just includes a list of examples with no instructional text. It's unclear what the actual rule is. pburka (talk) 17:33, 12 October 2022 (UTC)

Seems to me the heading makes things clear. EEng 17:48, 12 October 2022 (UTC)

The heading reads: "Instead of a hyphen, when applying a prefix or suffix to a compound that includes a space or a dash". What are we supposed to use "instead of a hyphen"? I think the answer is an unspaced en-dash, but that's far from obvious. pburka (talk) 20:41, 12 October 2022 (UTC)

OK, I see what you're saying now. Looks like these little subsections were once a bullet list with an introduction. Check out my fix made just now. EEng 21:03, 12 October 2022 (UTC)

Looks better. Thanks. pburka (talk) 01:12, 13 October 2022 (UTC)

MOS:COLLAPSE and the mobile app

Discussion at Misplaced Pages:Village pump (technical)#MOS:COLLAPSE_and_tables/sections_defaulting_to_collapsed_state_on_mobile_app

There is a discussion about how the Misplaced Pages app is defaulting to collapsed tables/infoboxes (and references sections) at the village pump for any editor concerned or wishing to participate. See link above. —Locke Cole • t • c 16:33, 14 October 2022 (UTC)

Do people die in their ledes?

Apologies if this is the wrong talk page, but I have noticed something and I am not sure what the actual guidelines are. Here is an example: Ken Starr. The lead covers his career, his basic deal, and some stuff that went on in his life up to about 2020... then it stops. He died in 2022. Should this be in the lead, or only in the body? jp×g 14:46, 16 October 2022 (UTC)

• I think it depends on whether the circumstances of his death are a notable part of the article. Compare John Lennon. The lede summarizes the article. Starr's death is a sentence in the article, and there's very little to say about it. Mackensen (talk) 14:59, 16 October 2022 (UTC)
• The lede is the summarization of the article's major points. Death is a major point and if it is covered in the article, the lead should mention it too.Blue Pumpkin Pie (talk) 14:49, 16 October 2022 (UTC)

  The lead includes Starr's date of death and refers to him in the past tense. That seems sufficient to me. pburka (talk) 14:52, 16 October 2022 (UTC)

  Contrary to the assertion, death is not per se a major point, since everyone dies. EEng 15:58, 16 October 2022 (UTC)

  There is no way to be more dead than having "(DATE1 – DATE2)" right after your name. A mention of the circumstances of a person's death in prose really depends on the prominence of these circumstances in relation to key events during their lifetime. –Austronesier (talk) 20:22, 16 October 2022 (UTC)

  "William Shakespeare (1564–1616) is a dead English playwright, poet and actor." pburka (talk) 20:38, 16 October 2022 (UTC)

Hey, what will we do when someone's cryogenically preserved head gets reanimated? How will we indicate that inside the parentheses? Instead of waiting until it actually happens I think we should should have an RfC so we're prepared. EEng 20:56, 16 October 2022 (UTC)

Not necessary as it would obviously be in a new article. Just need to decide on the disambiguator. MB 21:02, 16 October 2022 (UTC)

Perhaps John Smith (head only)? Anyway, for further guidance on this matter, see Misplaced Pages:Biographies of dead persons. — Preceding unsigned comment added by Herostratus (talk • contribs)

But John Smith already needs dabs, so we'd end up with John Smith (anatomist and chemist, head only) and John Smith (astronomer, head only) and John Smith (lexicographer, head only) and so on. What a mess. EEng 00:10, 21 October 2022 (UTC)

Date of death goes in the parentheses in the lead sentence, and was already in Starr's article. More detailed circumstances of death are usually not lead-worthy, unless there is something unusual about the death. There are exceptions but Starr does not appear to be one of them. —David Eppstein (talk) 21:12, 16 October 2022 (UTC)

Noticing the Lennon example. Let's be clear to outsiders, we're discussing Ken Starr (as an example), not Ringo Starr (who's still alive). GoodDay (talk) 21:24, 16 October 2022 (UTC)

I concur with EEng and Austronesier and David Eppstein. Everyone dies; for those this has happened to, this is generally indicated by including the death date shortly after the name. For unusual cases, where the death was under noteworthy circumstances, the lead may include more information, in WP:DUE balance to coverage of the event in the article body. Thus the lead at the Lennon article.  — SMcCandlish ☏ ¢ 😼  03:33, 18 October 2022 (UTC)

Starr died of "complications from surgery on September 13, 2022, at the age of 76" - not lead-worthy. It has a section to itself, which poor WP articles tend to do, but here there seems no "later life" section it could go into. But I have seen some bios where a decidedly unusual manner of death is not mentioned in the lead when it should be, and only appears right at the end - at least one murder. I can't remember examples unfortunately. Johnbod (talk) 04:43, 18 October 2022 (UTC)

As an example where a death is mentioned in the lede and is notable enough to do so, there's Marion Miley. Silverseren 04:51, 18 October 2022 (UTC)

Indeed - and a search on "murdered by a fellow guest" brought me to Johann Joachim Winckelmann, actually pretty famous, where the murder was only mentioned at the bottom of a long article until I added it to the lead in July. Johnbod (talk) 05:24, 18 October 2022 (UTC)

I'm sorry, but I have to ask... Why were you searching "murdered by a fellow guest"? EEng 00:02, 21 October 2022 (UTC)

Purely to find the article as an example - I remembered the how, but not the who. Johnbod (talk) 03:15, 21 October 2022 (UTC)

That's a lie. I overheard Johnbod a few months ago saying he regularly searches for "murdered by a fellow guest". I couldn't quite catch the reason, but it was something like "mumble fisheries burglegurgle not in the face unintelligible and then you'll be saved." Firefangledfeathers (talk / contribs) 02:53, 26 October 2022 (UTC)

Sadly, we don't have a :Category:Deaths by fellow guests. pburka (talk) 02:28, 21 October 2022 (UTC)

• How about John Hamilton (Royal Navy officer) - lead-worthy death? You decide. Johnbod (talk) 02:44, 26 October 2022 (UTC)

About "Scrolling lists and collapsible content"

I just made some changes to the section "Scrolling lists and collapsible content": . I would like to offer a very extended edit summary :)

I rewrote the following fragment (primarily written in in 2016 by @SMcCandlish):

Collapsible templates should not conceal article content by default upon page loading. This includes reference lists, tables and lists of article content, image galleries, and image captions. In particular, while some templates support a collapsible parameter or manually-added CSS class, and this is permissible, the collapsed, mw-collapsed, and autocollapse states should not be used in articles to pre-emptively force the closure of these elements, except as noted below. Any information hidden in this way when the page loads will be irreversibly invisible to the aforementioned classes of users, as well as a growing number of low-bandwidth users in Asia who reach a Misplaced Pages article via Google. Several other CSS classes, used manually or by templates, will render content inaccessible to mobile users.

1. As noted, CSS and JavaScript support are required to operate the show/hide toggle. Moreover, hidden content is not available in the mobile version of Misplaced Pages even on devices that have that support, because the mobile version's servers strip that content out before sending the page. In 2016, Google launched a Google User Content service that, like the earlier Google Lite and Google Web Transcoder, strips hidden material from pages when they are accessed through Google searches, before content is delivered to users with slow connections. The service has already been deployed in India (where English is a major language) and Indonesia, with additional national markets planned for 2016 and forward. These services also completely strip out navboxes.
2. Applying, or using a template that applies, any of the following CSS classes will cause the affected content to be inaccessible to mobile users, and this list may not be exhaustive: navbox, mbox-image, vertical-navbox, nomobile are from wgMFRemovableClasses. No top icons are displayed, so topicon is missing.

1. "Google Launches Streamlined Lite Version Of Mobile Search Interface For Slower Connections", Search Engine Land
   "Google Testing Faster & Lightweight Mobile Search & Optimizing Your Web Page For Slow Connections", Search Engine Land

I'm afraid that several of the points made in this paragraph weren't right:

• "Any information hidden in this way when the page loads will be irreversibly invisible to the aforementioned classes of users" – It's true that JavaScript is needed to use the toggle, but when it is disabled, the content is simply not collapsed (it is not removed). This has always been the case for mw-collapsed, and it's the case for collapsed and autocollapse since around 2018 (since and following edits).
• "Moreover, hidden content is not available in the mobile version of Misplaced Pages even on devices that have that support, because the mobile version's servers strip that content out before sending the page" – This is not true, the collapsibility is not working on mobile (T111565), but the content is again not collapsed (it is not removed). Some elements are hidden (like navboxes), but not the elements using those standard collapsible classes. I'm not sure if it was always this way, but it definitely is so now.
• "In 2016, Google launched a Google User Content service that, like the earlier Google Lite and Google Web Transcoder, strips hidden material from pages when they are accessed through Google searches, before content is delivered to users with slow connections." – This seems to be called Google Web Light now, I was able to access it following the instructions on https://developers.google.com/search/docs/advanced/mobile/web-light#see-the-web-light-version-of-a-web-page and a proxy geolocating to Pakistan, and it seems to be based on the no-JS version of the mobile site, which hides navboxes etc. but not the collapsible classes. (It's a real pain to access it, so here are some copies for your reference: Hurricane Julia (2022) , Talk:Hurricane Julia (2022) , Hurricane Julia (2022) , Talk:Hurricane Julia (2022) .)

I hope this is acceptable, as I haven't touched this page before. Matma Rex talk 23:27, 17 October 2022 (UTC)

Thanks for the testing and updating.  — SMcCandlish ☏ ¢ 😼  03:30, 18 October 2022 (UTC)

Block quotes to be italicized or no?

I've seen block quotes where the block quotation is both presented in italics or standard text. To me, the italics seems to look more presentable and appear to indicate that the text is actually a quotation more apparently. I would like to know if there is MOS guidance on block quotes appearing in italics. Yes, no, or is it up to the individual editor? TY. — Moops 23:07, 20 October 2022 (UTC)

For guidance see Misplaced Pages:Manual of Style#Quotations in italics. StarryGrandma (talk) 23:25, 20 October 2022 (UTC)

And the short answer is "no italics". There isn't a style guide on earth that recommends that practice. Some people do it because some blog software packages do it by default. (Why? No one knows).  — SMcCandlish ☏ ¢ 😼  00:26, 21 October 2022 (UTC)

Our article block quotation says that quotations were originally italicized rather than indented to set them off from surrounding text, and that "block quotations can be distinguished from the surrounding text by variation in typeface (often italic vs. roman)". So your dogmatic statement that this practice is never recommended seems to be an exaggeration, at best. That said, our style guide is clear that we don't do this here. —David Eppstein (talk) 00:56, 21 October 2022 (UTC)

Quote me a style guide recommending it.  — SMcCandlish ☏ ¢ 😼  02:51, 21 October 2022 (UTC)

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 Misplaced Pages 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)

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)

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)

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 Misplaced Pages 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)

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)

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)

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)

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)

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)

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)

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

RfD regarding MOS: shortcut to an explanatory essay

An editor has identified a potential problem with the redirect MOS:LONGDAB and has thus listed it for discussion. This discussion will occur at Misplaced Pages:Redirects for discussion/Log/2022 October 25#MOS:LONGDAB until a consensus is reached, and readers of this page are welcome to contribute to the discussion. -- Tamzin (she|they|xe) 17:48, 26 October 2022 (UTC)

Of considerably more importance is: Misplaced Pages talk:Organizing disambiguation pages by subject area#RfC: make this page a guideline.  — SMcCandlish ☏ ¢ 😼  21:03, 10 November 2022 (UTC)

Mainstream publications are capitalizing both Black and White

I noticed in this article: https://www.washingtonpost.com/health/2022/10/19/covid-deaths-us-race/ that both Black and White are capitalized. Perhaps this is a good cue to mirror this as policy here, to avoid what I imagine have been divisive editing battles. 2600:1012:B028:F35F:4957:F090:2315:B94B (talk) 16:48, 28 October 2022 (UTC)

They have been divisive. I'm skeptical that today is soon enough to revisit this; I would give it another year for source usage to even out more. The current status quo is black/white or Black/White, left to editorial consensus at the specific article. The previous big discussion had a clear consensus against Black-but-white usage.  — SMcCandlish ☏ ¢ 😼  20:44, 10 November 2022 (UTC)

Discussion at Misplaced Pages talk:Manual of Style/Dates and numbers § Article titles for years: BC/AD or BCE/BC

 You are invited to join the discussion at Misplaced Pages talk:Manual of Style/Dates and numbers § Article titles for years: BC/AD or BCE/BC. Interstellarity (talk) 14:18, 29 October 2022 (UTC)

Are continents capitalized

I know the talk page is not a forum but are continents capitalized GenZenny (talk) 17:03, 5 November 2022 (UTC)

If you mean the names of continents, Africa, Asia, North America, etc., then yes. BD2412 T 17:12, 5 November 2022 (UTC)

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.

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

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)

Discussion at Talk:LeAnn Rimes (album) § Album name same as artist's name

 You are invited to join the discussion at Talk:LeAnn Rimes (album) § Album name same as artist's name. Sundayclose (talk) 19:10, 19 November 2022 (UTC)

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)

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)

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)

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)

That essay makes it very clear that its suggestions are supplementary to LEAD. Nikkimaria (talk) 04:39, 24 November 2022 (UTC)

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)

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)

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)

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)

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)

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

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)

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

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)

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)

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)

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)

• 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 Misplaced Pages: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" ... "City, Country" (e.g., "Detroit, United States") or "City, State, Country" (e.g., "Kansas City, Missouri, U.S.") (In addition, per , 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)

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)

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)

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

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 Misplaced Pages MoS, which is contrary to the popular Misplaced Pages:Specialized-style fallacy concept.
• It seems to adopt the WGA screenwriting credit system as a specific endorsed system for use in the English Misplaced Pages as part of the Misplaced Pages 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)

I don't care either way, but it is absolutely the agreed consensus in certain WikiProjects to credit television and film writers on Misplaced Pages 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)

For purposes of this discussion, I am only focused on what WP:& should say. —⁠ ⁠BarrelProof (talk) 23:52, 25 November 2022 (UTC)

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)

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)

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)

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.

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) 14:28, 4 December 2022 (UTC)