WikiProject Manual of Style | |||||||||||||
|
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)
- Wikipedia talk:Manual of Style/Biography#Neopronouns RfC [moved] – several options under discussion, including singular they, using neo-pronouns like xie, always referring to subject by surname, etc.
- Wikipedia talk:Manual of Style/Linking#RfC about hatnote links to Simple English Wikipedia – followup to a TfD
- Talk:Proto-Indo-European homeland#BCE or BC – another MOS:BCE question
- Wikipedia talk:Manual of Style/Icons#Flags in tables of national subdivisions – should subnational flags be used in such tables?
- Wikipedia 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.
- Wikipedia 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:
- Wikipedia talk:Manual of Style/Capital letters#Midsentence capitalization of the – Capitalize The when referring to [T/t]he Church of Jesus Christ of Latter-day Saints?
- Discussion originally started here: WT:Manual of Style/Latter Day Saints#Capitalization issue
- RfC later filed 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
- WT:WikiProject Ice Hockey#Lower casing of First team & Second team All stars. – Follow NHL's capitalization style, or WP's?
- WP:RM discussions
- Talk:So into You (Tamia song)#Requested move 1 November 2022 – Capitalize "into"?
- Talk:Modern Paganism#Requested move 23 August 2022 – Lowercase "Paganism"? Initially closed as lowercase 28 August 2022; relisted 31 October 2022 after a move review
- Talk:Neopaganism in Scandinavia#Requested move 14 August 2022 – Change "Neopaganism" to "Modern [P/p]aganism"? Result: "Modern paganism" (lowercase)
- Talk:Post-it Note#Requested move 30 October 2022 – Move to lowercase?
- Talk:List of body men#Requested move 29 October 2022 – Use uppercase for the role title?
- Talk:N.EX.T#Requested move 24 October 2022 – Simply format as the mixed-case word "Next" with diambiguation – e.g. "Next (Korean band)"?
- Talk:Mid-American Conference Baseball Tournament#Requested move 23 October 2022 – 700 or so case-fixing sports tournament moves (proposal for a bot).
- Talk:Vice-admiral of the red#Requested move 22 October 2022 (also Vice-admiral of the White) – Uppercase "admiral"? Uppercase "red"?
- Talk:Harrier Jump Jet#Requested move 18 October 2022 – proper name?
- Talk:NEXT (Chinese band)#Requested move 11 October 2022 – Drop the all-caps?
- Talk:The Mink Case#Requested move 5 October 2022 – Should the title use capital letters for the killing of minks in Denmark?
Concluded
Extended content
| ||
---|---|---|
|
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 [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)
- 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)
- Jesus Christ, the OP wrote, just above here:
- 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)
- 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)
- 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)
- 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)
- 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)
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
- Flerovium, with the expected magic 114
- 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 currentZ = 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.
- If
- 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 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)
- 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.
- ... his fee for the service was $50
- 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
- ... the great-grandnephew of Queen Mary
- 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)
- Makes sense, I understand what you're saying about captions. Would it then also be better to use
- 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 –
- @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
- @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
- 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)
- 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 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)
- 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)
- 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)
- 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)
- 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:
Bare | Wikilinked | |
---|---|---|
Using {{nowrap}} | World War I | World War I |
Using
|
World War I | World War I |
- 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)
Percent again
Percent clarification
I would like to propose a small update to the percent description. The description is spot on with regards to how to use it. 3% Three percent Three per cent (however much I personally hate this option; but that is one of the reasons there is a style guide)
On what not to use, the style guide is a lot less clear Do not use: 3 % I think we should add: 3 percent 3 per cent. As invalid options. That is implied in the text, but it is not stated in the examples. Additionally, to be completely clear, I think we should add: Whether it is the first time in the article you use percent or not. if you do not write out the number, do not write out the percent. That also means that 70% can be written in only one way. I consider this a clarification of the rules, not an update (Together with how to write numerals in Wiki)
Percent update
The is one very small inconsistency with the percentage standards as opposed to most percentage standards. Where 3–5 m is correct for 3 to 5 meters (and 3 m – 5 m is not), the percentage standard is to include the percent in both instances, thus: 3%–5%. I guess that has to do with number formatting, as well as the fact that a lot of text could be added between the 3% and the 5%. — Preceding unsigned comment added by 82.207.179.62 (talk • contribs) 08:05, June 15, 2022 (UTC)
MOS:HYPHEN
MOS:HYPHEN has an image of college students stating "four-year old children", meaning these college students are in their fourth year (seniors) at a university. However, college students are not kids, but young adults and have obtained the age of majority, so the description is somewhat misleading. That is why I added a note explaining that sources sometimes refer to college students as college kids because of their youthfulness. cookie monster 755 02:38, 1 July 2022 (UTC)
- They're all somebody's children. I've removed your overanxious pedantry. EEng 04:36, 1 July 2022 (UTC)
- I'd missed that pics had been introduced in that section. They're cool. Tony (talk) 08:27, 1 July 2022 (UTC)
- And they're old children. Phil Bridger (talk) 08:59, 1 July 2022 (UTC)
- Questions: is that expression, or even just "old children", actually in use in the USA in the context of university graduates - Ive never heard of that usage in the UK? At what age do students graduate from Texas Tech University?
- That is different form of pedantry, EEng#s. You are using children in the "vertical" family relationship sense, with no age implications whatsoever; the photo concerns contempories, using the word to mean young people who have not yet reached puberty or become adults. Davidships (talk) 09:58, 1 July 2022 (UTC)
lol. cookie monster 755 18:44, 1 July 2022 (UTC)
- This seems to be a litany of people not getting the point, which is, in the context of hyphenation, that these children are four-year (in that they are studying four-year courses) and old (as children go). Mildly humorous things like this lose most of their effect if they have to be explained, but it seems that it is necessary to do so. Phil Bridger (talk) 20:33, 1 July 2022 (UTC)
- They are not children though, they are young adults. I know they are four-year uni students. cookie monster 755 00:36, 2 July 2022 (UTC)
- Just want to chime in saying that I think we should keep the humorous example. I think that it emphasizes the importance of hyphens while keeping it entertaining. Heck, the fact that folks are missing the point just adds to the charm. Mason (talk) 02:02, 2 July 2022 (UTC)
- I am not sure why you need to be sassy, EEng#s. I already explained myself above. cookie monster 755 21:18, 2 July 2022 (UTC)
- For crying out loud, it doesn't matter whether the caption is literally true or not, and there's nothing "sassy" about saying that. It and the accompanying picture are only there to light-heartedly illustrate the importance of correct hyphenation. Phil Bridger (talk) 21:53, 2 July 2022 (UTC) P. S. And yes, EEng, I did mean "litany".
- Phil Bridger as my grandmother said, for cryin' on a crutch. Be nice always
cookie monster 755 23:15, 2 July 2022 (UTC)
- Phil Bridger as my grandmother said, for cryin' on a crutch. Be nice always
- For crying out loud, it doesn't matter whether the caption is literally true or not, and there's nothing "sassy" about saying that. It and the accompanying picture are only there to light-heartedly illustrate the importance of correct hyphenation. Phil Bridger (talk) 21:53, 2 July 2022 (UTC) P. S. And yes, EEng, I did mean "litany".
- I think it's touching that you all still think students spend four years at university. At that school, they're almost as likely to have taken five years to graduate.[3] WhatamIdoing (talk) 16:01, 14 July 2022 (UTC)
- Being from a country where most students graduate in three years I'm rather jealous of all these students who spend four years at university, let alone five, as many of my Polish relatives seem to. Phil Bridger (talk) 16:11, 14 July 2022 (UTC)
- In Guatemala there is the public university, a storied institution of social resistance and activism, but also where reportedly decades ago crooked Army officials dropped drug cargos from helicopters, the government kidnapped and murdered students and faculty, and crooked radicalized students used to haze new admissions throwing them naked in pools of feces and urine, extort businesses and rob fellow students as a tax. Currently it's 5.5 years to finish all courses and then there is the thesis and the private exam to defend it. So I guess it takes about 6 years to graduate from a Business Administration degree. I was an old child, now I guess I am practically an old orphan. Thinker78 (talk) 18:13, 14 July 2022 (UTC)
- Being from a country where most students graduate in three years I'm rather jealous of all these students who spend four years at university, let alone five, as many of my Polish relatives seem to. Phil Bridger (talk) 16:11, 14 July 2022 (UTC)
- I agree that we should keep the examples of four(-)year-old children, but I feel like the example actually works better without the third image with four-year old children. Nobody actually says it this way, it's grammatically and factually questionable, and it's confusing. Everytime I see this thing shared online (like today in this Reddit post), the first comment is "I don't understand the third one". ―Jochem van Hees (talk) 11:53, 18 July 2022 (UTC)
- Yes. The third panel uses language that you're unlikely to encounter anywhere else, and it could sow confusion with people who might take it seriously as proper English usage. There are students in their fourth-year at four-year colleges, but they won't be referred to as "four-year old children". The first two panels are witty enough, along with the fish examples, and go far to making clear that people who care about the MoS aren't just a bunch of dreary old scolds. Dhtwiki (talk) 23:13, 19 July 2022 (UTC)
- I am not sure why you need to be sassy, EEng#s. I already explained myself above. cookie monster 755 21:18, 2 July 2022 (UTC)
Is there any point in reviving this discussion? I still think there are good, unchallenged arguments for removing the third image. ―Jochem van Hees (talk) 11:43, 16 September 2022 (UTC)
Clarifying periodical titles?
I recently wrote Reason. I had gone back and forth in my head a few times about whether it would be better to write it as Reason Magazine for clarity, and eventually ended up with the shorter version. In Special:Diff/1108245559, Victuallers went with the longer version, which is fine. I tend to write "Time Magazine" (even though the correct title of the periodical is just "Time"), but I'd never write "The New York Times Newspaper". Is there some general style rule which covers this? -- RoySmith (talk) 14:31, 3 September 2022 (UTC)
- No strong view myself but I don't think that the name is all that is required. "Charles Dickens" works, if you hane heard of him. but then I would suggest "The Victorian novelist Charles Dickens" is a better title. If you are still with me, then "The magazine Reason" is more quickly digested, than just "Reason" - irrespective of what the magazine decides is its title (they may think everyone will see "Reason".. and they don't). Victuallers (talk) 14:46, 3 September 2022 (UTC)
- In properly styled running text, italics would also offer a hint to the reader. William Avery (talk) 15:29, 3 September 2022 (UTC)
- I don't think Magazine should be capitalized or italicized unless it's actually part of the proper name: New York Times newspaper or New Yorker magazine, but Brooklyn Magazine. It's fine to include as a descriptive term if it makes the text clearer. pburka (talk) 15:51, 3 September 2022 (UTC)
- I agree with the the above; only capitalize and italicize the proper name. If necessary to clarify that you are talking about a magazine, newspaper or whatever, label it in the text e.g. "Time magazine said ...". I do note that New York, like Chicago and many others do not include the word magazine in their name, but when used outside of references they should be labeled to avoid confusion. Establishing the correct name of a magazine is not always straight forward. For instance Time magazine, in it's own writing calls itself Time Magazine, but does not have the word magazine on its cover. When in doubt, I go with the name used in the Wikipedia article if there is one, or if not, what I can see on the periodical's printed cover. SchreiberBike | ⌨ 18:49, 3 September 2022 (UTC)
- Concur with Pburka, and this is already covered at MOS:TITLES. — SMcCandlish ☏ ¢ 😼 17:16, 12 September 2022 (UTC)
Złoty or zloty?
I know this is not the best place to put this, but I think this page has pretty high traffic with lots of MOS experts--and frankly I wouldn't rightly if I have a position here, and what validity it might have. So, I'd appreciate it if some of you could have a look at Talk:Polish_złoty#Requested_move_10_September_2022 and maybe weigh in. Thanks, Drmies (talk) 20:17, 17 September 2022 (UTC)
Chimpanzees
A chimpanzee with a typewriter, given an infinite amount of time could create the Wikipedia Manual of Style, except it would probably be infinitely better.
Passive voice is one example of how MOS ignores aspects of reality. The penchant for the active voice came, fairly recently, from humanities academics and popular writers. It is fine for what these people write, but the passive voice was adopted by the Royal Society, founded in the late 17th century, for its scientific publications. The use of the passive voice in science thus has a long and distinguished history. It was and is still used - try writing a scientific paper in the active voice and it will look and sound like the product of an imbecile - because it gives a very necessary distance between the writer and the phenomena being described. It is impersonal, which science strives to be. Contrast the following: "An agarose gel was eletrophoresed, and the DNA fragments proved to be of the following sizes ..." and, "I ran an agarose gel in the electrophoresis tank, then I sized the DNA fragments, which were ..."
MOS also weighs against constructions that are perfectly standard in English usage. I was staggered that an editor asserted that MOS effectively vetoes the construction "He suffered from a chronic illness..." WTF!!!!
So much of Wikipedia's working is ridiculous, but MOS is probably the worst. I am not in a good mood, editing Wikipedia often has that effect on me. Urselius (talk) 10:12, 18 September 2022 (UTC)
- The Manual of Style does not prohibit passive voice, and it has recently been updated to make that more clear - see the discussion earlier on the page.Nigel Ish (talk) 10:28, 18 September 2022 (UTC)
- Anyone or anything with an infinite amount of time will succumb to the heat-death of the universe, manuscripts probably unfinished. Primergrey (talk) 01:58, 19 September 2022 (UTC)
- Whether to use passive or active voice is sometimes a subtle and complex decision. Generally don't use passive where active would be perfectly good; but don't adopt a slavish rule against the passive. To begin with it allows you to start a clause with a different word—what comes first is called the grammatical theme. The succession of themes in a text should make sense as a logical sequence. It can add to cohesiveness and help the reader. Tony (talk) 08:42, 19 September 2022 (UTC)
- In the name of Jesus, Tony, please let's let passive sleeping dogs lie! Last thing we need is a new round of wheel-spinning on this. EEng 09:18, 19 September 2022 (UTC)
- Whether to use passive or active voice is sometimes a subtle and complex decision. Generally don't use passive where active would be perfectly good; but don't adopt a slavish rule against the passive. To begin with it allows you to start a clause with a different word—what comes first is called the grammatical theme. The succession of themes in a text should make sense as a logical sequence. It can add to cohesiveness and help the reader. Tony (talk) 08:42, 19 September 2022 (UTC)
-
- "heat-death of the universe" contradicts "infinite amount of time". - MasterQuestionable (talk) 05:25, 20 September 2022 (UTC)
- And that's my point. Primergrey (talk) 07:43, 20 September 2022 (UTC)
- "heat-death of the universe" contradicts "infinite amount of time". - MasterQuestionable (talk) 05:25, 20 September 2022 (UTC)
-
- So?.. - MasterQuestionable (talk) 10:19, 20 September 2022 (UTC)
- Valid conclusion, though not with very substantial cause. - MasterQuestionable (talk) 05:08, 20 September 2022 (UTC)
Drive-by critics who don't actually read the guidelines they criticize
Such critics with typewriters, given an infinite amount of time, could create a Wikipedia Manual of Style, but it probably wouldn't be better. EEng 01:27, 19 September 2022 (UTC)
- Garbage-In Garbage-Out. - MasterQuestionable (talk) 05:08, 20 September 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[2][4][11][13][14]:" 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 (Talk on frwiki) 17:43, 28 September 2022 (UTC)
- Hi Lostraven and Mandarax.
- 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)
Discussion about soft redirects to sister projects
Please see Wikipedia talk:Wikimedia sister projects#Soft redirects to sister projects which needs input from additional editors. Thryduulf (talk) 12:37, 1 October 2022 (UTC)
Discussion about Flags_in_tables_of_national_subdivisions
Please see Wikipedia_talk:Manual_of_Style/Icons#Flags_in_tables_of_national_subdivisions, which needs input from additional editors. Furius (talk) 23:53, 3 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)
- 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)
- 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)
- 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)
- 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)
- 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
- 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)
- 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)
- 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)
- Excellent idea. EEng 03:17, 11 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?
Wikipedia: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)
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)
MOS:COLLAPSE and the mobile app
- Discussion at Wikipedia:Village pump (technical)#MOS:COLLAPSE_and_tables/sections_defaulting_to_collapsed_state_on_mobile_app
There is a discussion about how the Wikipedia 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)
- 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)
- Contrary to the assertion, death is not per se a major point, since everyone dies. EEng 15:58, 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)
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 Wikipedia: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)
- Perhaps John Smith (head only)? Anyway, for further guidance on this matter, see Wikipedia:Biographies of dead persons. — Preceding unsigned comment added by Herostratus (talk • contribs)
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. SilverserenC 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)
- Purely to find the article as an example - I remembered the how, but not the who. Johnbod (talk) 03:15, 21 October 2022 (UTC)
- Sadly, we don't have a :Category:Deaths by fellow guests. pburka (talk) 02:28, 21 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)
- 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": [5]. I would like to offer a very extended edit summary :)
I rewrote the following fragment (primarily written in [6] 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, thecollapsed
,mw-collapsed
, andautocollapse
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 Wikipedia article via Google.[a] Several other CSS classes, used manually or by templates, will render content inaccessible to mobile users.[b]
- ^ 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 Wikipedia 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.[1]
- ^ 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 fromwgMFRemovableClasses
. No top icons are displayed, sotopicon
is missing.
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" ["As noted, CSS and JavaScript support are required to operate the show/hide toggle"] – 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 forcollapsed
andautocollapse
since around 2018 (since [7] and following edits). - "Moreover, hidden content is not available in the mobile version of Wikipedia 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) [Google Web Light rendering], Talk:Hurricane Julia (2022) [Google Web Light rendering], Hurricane Julia (2022) [original no-JS mobile site], Talk:Hurricane Julia (2022) [original no-JS mobile site].)
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 ⋠T⋡ 23:07, 20 October 2022 (UTC)
- For guidance see Wikipedia: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)
- 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)
- 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)
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)
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 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)
- 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 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)
- 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 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)
- 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)
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 Wikipedia: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[cetacean needed] (she|they|xe) 17:48, 26 October 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)
Discussion at Wikipedia talk:Manual of Style/Dates and numbers § Article titles for years: BC/AD or BCE/BC
You are invited to join the discussion at Wikipedia talk:Manual of Style/Dates and numbers § Article titles for years: BC/AD or BCE/BC. Interstellarity (talk) 14:18, 29 October 2022 (UTC)