Wikipedia talk:Manual of Style/Text formatting

de facto or de facto

Is de facto considered a foreign term or is it considered a loan-phrase for the purposes of MOS:FOREIGNITALIC? –MJL ‐Talk‐^☖ 04:02, 25 April 2023 (UTC)

My take is that it's been in every English dictionary ever printed, so it's an archetypal loan-phrase, no italics. Remsense聊 18:38, 24 October 2023 (UTC)

Lots of Latin- and French-ism borrowings are found in English dictionaries but still often rendered in italics as not fully assimiliated (especially multi-word ones like in flagrante delicto, de rigeur, etc.), very commonly in legal writing. People are going to disagree on these, using "de facto" instead of "de facto" is not an error, and the matter is not worth fighting about. Just be consistent within an article.  — SMcCandlish ☏ ¢ 😼  01:09, 25 October 2023 (UTC)

I don't think it's an error in the abstract, but if what MOS:FOREIGNITALICS means what it presently says, words that have been 'properly' loaned into English shouldn't be italicized as a rule. I hope I haven't come off as belligerent, I'm just curious where the line is intended to be and what form it should take.Remsense聊 01:52, 25 October 2023 (UTC)

Lots of bright lines are intentionally not drawn by this style guide, to permit as much editorial freedom as is practical. See MOS:BLOAT: we generally only add a line item to MoS when it has been the subject of long-term, repetitive, disruptive editorial dispute. And even when we do add one, it often still permits editorial judgment, with wording like "usually", "often", "may", "recommended", etc. This is not a hard-and-fast policy. Cf. also WP:P&G: "Guidelines are sets of best practices supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply." It would not be practicable for MoS to try to list out definitively every loan word/phrase and whether it should be italicized. Even determining on a case-by-case basis is apt to end up being a matter of whoever has more time to waste digging around in dictionaries and other sources to support their case that the term is or is not assimilated enough to warrant italicizing any longer. This is why I suggest just leaving it alone. It does not break anything if it appears as "de facto" in one article but "de facto" in another. We just don't want to see both styles in the same article. And consider also consistency as a class: if the article is making heavy use of italics for such phrases in general, there is probably no good reason to try to make a special exception for this specific term, while if it's presenting lots of fairly well-assimilated Latinisms without italics, it would probably not make sense to try to force italics on just this one.  — SMcCandlish ☏ ¢ 😼  02:49, 25 October 2023 (UTC)

Oh, certainly, I agree it would only make sense as a class, see my topic below. I suppose there's a particular sense of noise that I would concretely rather avoid with this class, but I could definitely see one seeing it as guideline bloat. Remsense聊 02:51, 25 October 2023 (UTC)

Italics or not?

Should all these words be written in italics? idam, antahkarana, buddhi, ecc. JackkBrown (talk) 12:03, 4 June 2023 (UTC)

@JackkBrown: Yes, since they are not fully assimilated into English like "yoga" is. More properly, they should be written with lang-template markup, e.g. {{lang|sa-Latn|idam}}.  — SMcCandlish ☏ ¢ 😼  01:11, 25 October 2023 (UTC)

Use bold for minor sub-sub-sections?

Some articles use bold mark-up on very minor sub-sub-section titles. Such as, for example,

   '''Stringer pallet'''

and

   '''Carrier block'''

subsections in the current version of the Pallet article.

Other articles exclusively use the "==", "===", "====", "=====", etc. section mark-up for every section and sub-section, no matter how minor.

I expected to find some advice to specifically recommend something like (a) "make the most minor sub-sections bold -- they are not important enough to appear in the table of contents"; (b) "always use section markup, so it appears in the table of contents, no matter how minor the section"; or (c) "either style is acceptable, so don't bother senseless switching back and forth (see MOS:RETAIN)".

Should MOS:SECTIONS or MOS:NOBOLD specifically recommend (a), (b), or (c)? Is there some other place in the manual of style that already does recommend (a), (b), or (c)? --DavidCary (talk) 18:01, 14 June 2023 (UTC)

You are looking for MOS:PSEUDOHEAD Gonnym (talk) 18:23, 14 June 2023 (UTC)

Gonnym, thank you. I see MOS:PSEUDOHEAD is exactly what I'm looking for. --DavidCary (talk) 07:12, 26 November 2023 (UTC)

MOS:BADITALICS - What is a proper name??

I read the description on proper noun 10 times and I still can't decide: Is Arena (countermeasure) a proper noun or a proper name? I had never heard of the term "proper name" before Wikipedia. Schierbecker (talk) 17:21, 3 August 2023 (UTC)

The term would generally be 'proper noun', at least as taught in American schools. Remsense聊 18:37, 24 October 2023 (UTC)

It's more that "proper name" is mostly a philosophy usage and "proper noun" more a linguistics usage, but "proper name" in broad usage also encompasses capitalized derivates of proper nouns, like "Scottish" (in languages like English that capitalize such terms; many, including Spanish, lower-case them and only capitalize the noun forms: escocés, escocesa 'Scottish', Escocia 'Scotland'). The term "proper adjective" or "proper modifier" is sometimes used for the derived forms, but these terms seem to have little currency compared to "proper name" used in the general sense. Overall, I think WP's MoS should prefer the term "proper noun" where ever practical, because we have been beset in the past by people trying to apply a broad, loose philosophy-derived defintion of "proper name" in an effort to over-capitalize a large number of things, when MoS clearly, necessarily means the linguistics sense, being a work about language usage not a treatise on philosophy of naming. Despite the obviousness of this, such "give me capitals or give me death" behavior has risen to very disruptive levels in the past, so it is best to nip it in the bud.  — SMcCandlish ☏ ¢ 😼  01:20, 25 October 2023 (UTC)

Bold face after redirects

One fairly often sees apparently random bold face text in the middle of articles. I just came across an example here. When editing that section, hidden text indicates that the bold was added due to WP:R#PLA.

The talk page at WP:R is protected, hence my post here instead. But the guideline says:

Wikipedia follows the "principle of least astonishment"; after following a redirect, the reader's first question is likely to be: "Hang on... I wanted to read about this. Why has the link taken me to that?" Make it clear to the reader that they have arrived in the right place.

The linked article contains this:

When the principle of least astonishment is successfully employed, information is understood by the reader without struggle. The average reader should not be shocked, surprised, or confused by what they read.

It's always seemed to me that the use of bold face for text in this way is misguided. Certainly, a reader who has been redirected to the middle of an article will wonder if they are in the right place, and bold face like this may help them to realise why. But a far greater number of readers will not have followed any redirect. They will just be reading an article in which arbitrary text suddenly appears in bold face. Following the principle of least astonishment, if one of two groups of readers are unavoidably going to be astonished, it is better if it is the smaller group, is it not? 83.3.91.154 (talk) 15:50, 3 September 2023 (UTC)

A term being boldfaced isn't particularly "astonishing", especially given the frequency with which WP employs bold for redirects. But I'm not going to opine on the matter much more strongly than that. Anyway, I requested unprotection of Wikipedia talk:Redirect at WP:RFPP since it seems to have been protected accidentally when the guideline page was protected.  — SMcCandlish ☏ ¢ 😼  01:39, 5 September 2023 (UTC)

I agree, (apparently) random boldface is not particularly astonishing. If you want to improve things, consider adding a boldfaced mention of the redirect term to the lead and remove the section link from the redirect. Also, if there are no articles linking through the redirect and few page views, it is arguably appropriate to remove the boldface. ~Kvng (talk) 03:54, 9 September 2023 (UTC)

I think you're missing the point. The word "astonishing" is only relevant because the guideline mentions the "principle of least astonishment". What you have here is a choice: bold face a term, to avoid "astonishing" people who arrive via a redirect, or don't bold face it, to avoid "astonishing" the people who did not follow a redirect but arrived by reading the article in the normal way. Which group is bigger? Without any doubt, the latter. So a guideline that seeks to follow the "principle of least astonishment" is failing to do so. 185.106.155.193 (talk) 11:38, 10 September 2023 (UTC)

Do we have data proving that most people read articles from top-to-bottom? Some redirects are quite popular. But this is, in turn, missing a bigger point: arriving at an article that isn't what you were looking for, and not easily finding in it what you were looking for, it a high astonishment level, while seeing something boldfaced, which most regular readers by now probably understands indicates a redirect term, is hardly any astonishment at all. The comparison you are making is uneven at best.  — SMcCandlish ☏ ¢ 😼  11:49, 10 September 2023 (UTC)

"Do we have data proving that most people read articles from top-to-bottom?" - How many articles do you arrive at by way of redirects to sections, as compared to all the articles you look at?

"...which most regular readers by now probably understands indicates a redirect term..." - that's total guesswork, and I doubt it is in any way realistic. Most readers of Wikipedia articles are not familiar with any of the policies and guidelines, and do not want to have to guess what they are.

Perhaps the real point is that redirecting people to sections of articles is generally a pretty bad idea and should be avoided. 185.106.155.193 (talk) 12:25, 10 September 2023 (UTC)

"How many ..." - Lots and lots and lots. The reason I asked is because in the discussion leading up to the changing of MOS:DUPLINKS, evidence was presenting proving that our readers (especially mobile ones) do not read our articles top to bottom but jump around all over the place, both within the same article and across articles. So what research do you have counter to this? That regular readers of WP understand our most common markup conventions is common sense; you can call it "guesswork" if you like, but it's educated guesswork at worst, and you're not one to be talking about guesswork when you are presenting guesses that directly contradict the research that changed DUPLINKS. "Perhaps the real point is that redirecting people to sections of articles is generally a pretty bad idea and should be avoided." This is a baldfaced assertion with which virtually no editors agree, and is contrary to the entire nature of WP as a heavily-link hypertext work (cf. WP:NOT#PAPER, MOS:LINK, etc.).  — SMcCandlish ☏ ¢ 😼  21:01, 10 September 2023 (UTC)

"Lots and lots and lots" - you're claiming that the majority of the time, when you follow a link to an article, that link takes you not to the top of the article, but to a section of it? There is very strong evidence that that is not the case: just look at the links in any article. How many take the reader to subsections, and how many take them to the top of the article? I just checked for Paris. It links to 1067 different articles. 1065 of those links - 99.8% - take the reader to the top of the article rather than a subsection. So how would you be managing to follow 0.2% of the links "lots and lots and lots" of the time? And you think that seeking to avoid those 0.2% of links is "contrary to the entire nature of WP"? I think you've lost track of what's being discussed here. The vast majority of links that you or anyone else follow take you to the top of the article. Links that take you to somewhere in the middle are the issue. Bold face within an article to help the small number of people who arrived via a redirect to a section is unhelpful to the far larger number of people who arrived by scrolling down the page from the top. 213.86.69.236 (talk) 05:09, 11 September 2023 (UTC)

I think I just read more complex material than you do or something. Many of the articles I read (and work on) are very long and have numerous redirects that go directly to sections in them. At any rate, I'm no longer interested in arguing in circles with you. Good day.  — SMcCandlish ☏ ¢ 😼  11:30, 11 September 2023 (UTC)

That's very funny. I really cannot imagine why you've chosen to behave in this confrontational way about a formatting issue. Care to provide an example of one of these articles with "numerous" redirects to sections? I do hope we don't have to conclude that you were making anything up. 86.187.160.119 (talk) 15:31, 17 September 2023 (UTC)

You have to consider both frequency and degree. If encountering random bold is more frequent, it is certainly less astonishing. Even if we had the numbers, we would probably still have difficulty agreeing on which situation is worse overall. I did suggest above a way to avoid section links in redirects. Where applicable, I agree this is the best solution. ~Kvng (talk) 15:01, 10 September 2023 (UTC)

So, you're in agreement with yourself? I'm not sure what solution you're proposing, to what alleged problem.  — SMcCandlish ☏ ¢ 😼  02:53, 25 October 2023 (UTC)

bold in song articles (fake headings)

An edit of mine removing boldface was reverted by @ResolutionsPerMinute; the reason was that other song articles use bold in that manner. I tend to look to this manual of style rather than similar articles, but the manual style of rife with exceptions and contradictions that are not linked to in MOS:BOLD. Is there something I missed? ~TPW 15:14, 12 October 2023 (UTC)

I think "look at similar articles" is valid advice in such cases; the MoS can't handle every detail. Gawaon (talk) 16:10, 12 October 2023 (UTC)

If the usage is to make it look like a header, then just make it a real section header with "===". Gonnym (talk) 16:20, 12 October 2023 (UTC)

There is also MOS:FAKEHEADING, which does seem to support bold, but not semi-colons, for pseudo-headings. The current guidelines do seem quite confusing. --Yodin^T 17:10, 12 October 2023 (UTC)

Yup, there seems to be no shortage of style guidance that's confusing and could benefit from some discussion. I'd much rather that the manual of style be explicit, rather than editors fighting because some rely on the style guide and others come to an understanding that's not documented in the style guide. That's the purpose of a manual of style, isn't it? ~TPW 17:32, 12 October 2023 (UTC)

I completely agree, it would be helpful either to discourage the use of bold pseudo-headings if there was consensus to do that, or to list them at MOS:BOLD#OTHER if not. @TPW do you oppose the use of bold pseudo-headings in general? And would anyone object if I added a mention of MOS:FAKEHEADINGs at MOS:BOLD for now, while both are part of the MOS? --Yodin^T 09:21, 13 October 2023 (UTC)

All I object to is the idea that an editor should be expected to guess as to local consensus. Either pseudo-headings are fine sitewide, or they are not. I'd prefer there not be any exceptions, but if there are let's have them laid out in detail in a centralized list, such as MOS:BOLD in this case. ~TPW 14:01, 17 October 2023 (UTC)

There is no topic-by-topic list of "exceptions" regarding such a thing, and shouldn't be one. I tend to agree with other comments below that the ToC problem can be solved by using {{TOC limit}}, so we really no longer have any need to permit pseudo-headings at all, especially since they lead to accessibility problems.  — SMcCandlish ☏ ¢ 😼  19:16, 17 October 2023 (UTC)

Creating subsections with === for each and every track listing bloats up the TOC like Thanksgiving dinner (compare this to something more reasonable), and I find that quite distracting. By applying bold pseudo-headings across hundreds of song articles with Track listings sections, I am introducing consistency that does not seem to be explicitly outlined elsewhere, not even in WP:SONGS. ResPM (T🔈🎵C) 17:26, 12 October 2023 (UTC)

A wikiproject is the last place any editor should be looking for style guidance. Whatever the outcome of this discussion, I'd like to see the actual manual of style updated to reflect it, because that makes it a lot easier for editorial compliance. ~TPW 17:34, 12 October 2023 (UTC)

Yes. That said, using bold to make pseudo-headings isn't against any rule (and the main reason to do it is in fact to avoid massively lengthening the ToC). But using ; markup to do it against MOS:DLIST, because it's an abuse of list markup which causes accessibility problems.  — SMcCandlish ☏ ¢ 😼  19:38, 12 October 2023 (UTC)

If it's distracting to you, then ignore it. Some people use assisted technology to read articles and for them it's helpful. Also, I personally find your "less reasonable" example perfectly fine. Especially if you add the country headers that were added to the "more reasonable" example which then make these headers one level deeper and visually smaller. Gonnym (talk) 19:45, 12 October 2023 (UTC)

@Gonnym Are there accessibility issues for the "more reasonable" example given above (You're Makin' Me High), or the use of bold pseudo-headings at MOS:FAKEHEADING? --Yodin^T 09:11, 13 October 2023 (UTC)

MOS:FAKEHEADING says this Screen readers and other assistive technology can only use headings that have heading markup for navigation. so yes, there are accessibility issues when actual headers aren't being used. I have no idea if there are others, as this area isn't my specialty. Gonnym (talk) 10:42, 13 October 2023 (UTC)

It suggests using {{TOC limit}} to avoid the issues raised by ResolutionsPerMinute above, and that "Using a pseudo heading at all means you have exhausted all other options. It is meant as a rarity." But {{TOC limit}} seems not to be working with the new Vector 2022 skin. I've now raised this issue on Phabricator, which also had suggestions for fine-grain control of TOCs, which could remove the technical reasons that currently permit pseudo-headings. But for now it looks like MOS:FAKEHEADINGs are supported by the MOS (albeit as a last resort), and accessibility concerns with it should probably be discussed there, rather than here. --Yodin^T 12:10, 13 October 2023 (UTC)

It's just that using proper subsection headers for e.g. six groups of two-to-five lines of text seems extravagant. They look better for prose than lists, which, as the name implies, Track listings sections are. Accessibility is a legitimate issue, but readability and presentation are just as important. I don't want to say using pseudoheaders "looks better," because that's my insignificant opinion, but a lot of song articles were that way before I came along, so there must be some benefit. ResPM (T🔈🎵C) 21:33, 13 October 2023 (UTC)

Might be worth trying to get consensus for a template that would display as bold text (in the same way that level 4+ headers currently are, for example), but render as h3 tags, so that it would be fully accessible, but also improve readability. Something like this should work: <h3 style="font-size:100%">test</h3>

Alternatively, how about using the bullet point method in the second example you gave? That way it would render as a list with sub-items, which again should address accessibility concerns. --Yodin^T 22:08, 13 October 2023 (UTC)

For another option, when there are a bunch of micro-sections in series and they're short and consistent in their style and purpose: template-structured glossary markup (which is not just for things that literally are glossaries; the underlying "association" or "description" list markup has various uses). See MOS:GLOSSARIES for the gist, and Template:Glossary and its related templates.  — SMcCandlish ☏ ¢ 😼  05:51, 14 October 2023 (UTC)

This example could plausibly be formatted as a definition list:

;Australian 7-inch and cassette single
:1. "The Machine's Breaking Down" – 4:38
:2. "Rumour Has It" – 3:55
;Australian 12-inch single
:1. "The Machine's Breaking Down" (club mix Hot Dr. mix)
:2. "The Machine's Breaking Down" (radio mix)
:3. "The Machine's Breaking Down" (extended dance mix)
:4. "Rumour Has It"

Australian 7-inch and cassette single

1. "The Machine's Breaking Down" – 4:38

2. "Rumour Has It" – 3:55

Australian 12-inch single

1. "The Machine's Breaking Down" (club mix Hot Dr. mix)

2. "The Machine's Breaking Down" (radio mix)

3. "The Machine's Breaking Down" (extended dance mix)

4. "Rumour Has It"

This is not a pseudo-heading because we really are using the material after each bold item to provide detail about that item, as definition lists do. Note that there needs to be no blank lines between the lines per MOS:LISTGAP. There should be no accessibility issues because we are using the ;: wikiformatting as it is supposed to be used rather than to hack up pseudo-headings or indentation. Also note the manual track numbering; auto-numbering with ":#" works but adds unnecessary indentation. —David Eppstein (talk) 16:06, 17 October 2023 (UTC)

Yes, this is why I said see MOS:GLOSSARIES, since it provides not just that semicolons-and-colons option but a more robust templated version with less easily-broken syntax:

{{glossary}}

{{term|Australian 7-inch and cassette single}}

{{defn|no=1|"The Machine's Breaking Down" – 4:38}}

{{defn|no=2|"Rumour Has It" – 3:55}}

{{term|Australian 12-inch single}}

{{defn|no=1|"The Machine's Breaking Down" (club mix Hot Dr. mix)}}

{{defn|no=2|"The Machine's Breaking Down" (radio mix)}}

{{defn|no=3|"The Machine's Breaking Down" (extended dance mix)}}

{{defn|no=4|"Rumour Has It"}}

{{glossary end}}

That markup permits blank lines (but not extraneous HTML elements) between items, and items with nested complex markup like multi-line input, block quotations, hatnotes, etc.  — SMcCandlish ☏ ¢ 😼  19:26, 17 October 2023 (UTC)

clearer language re:foreign italics

Please tell me if this is overly legalistic or guideline creep, but I think loan-phrases (as opposed to foreignisms) being italicized should be textually proscribed, as opposed to its present light, somewhat ambiguous discouragement. I think it's safe to draw a hard line here, since italicization simply doesn't contribute that much extra information in potential borderline cases. Remsense聊 18:42, 24 October 2023 (UTC)

@Remsense: If I understand it right, you are saying you want to change this guideline to specifically discourage loan-phrases from being italicized? What kind of loan-phrases are you referring to? –MJL ‐Talk‐^☖ 03:00, 25 October 2023 (UTC)

Yup! Here's a list that I hope provides a representative sample:

• de facto (but probably not ad eundem)
• chargé d'affaires (but probably not accolé)
• qi (but probably not taijitu)
• rōnin (but probably not bokken)
• status quo ante bellum (but probably not magistra vitae)
• Deus ex machina (but probably not eidos)
• Landsknecht (but probably not Gedankenexperiment)

My line's probably fairly wonky, mood-dependant and arbitrary, but I'm fairly convinced it should go a considerable way in the deitalicizing direction. Remsense聊 03:32, 25 October 2023 (UTC)

There is no bright line between these categories. Any particular phrase will show up in one dictionary (a more inclusive one) and not another, and different works will categorize it differently. There is already a thread above about this. To recap: We have no reason to try to impose a bright-line rule about this, as the purpose of MoS is not prescriptively legislating every aspect of writing style here, but presenting text that is consistent (within an article) and comprehensible for readers, and resolving/preventing recurrent disruptive "style fights" between editors. There is no long-term problem of editors battlegrounding over whether to write "de facto" or "de facto", so we have no cause to try to rule-make about it. The rationale for guidelines like this is to encapsulate clear consensus-accepted best practices, not try to force a change in practice, or force one practice over another where multiple approaches are broadly accepted (as appropriate for encyclopedic-register writing). See also MOS:STYLEVAR. Put another way: we have nothing to gain (and much editorial goodwill to lose) by forcing "de facto" or "de facto" style across a wide swath of terms that some people would like to classify as fully-assimilated loan words and other would consider not-full-assimilated foreignisms (and really, people would tend to disagree on a term-by-term basis; meanwhile, exactly where anyone falls on such a discussion is likely going to be significantly affected by personal familiarity with a particular term, e.g. because of more common use of it within their profession or even just the genre of reading material they spend more time with).  — SMcCandlish ☏ ¢ 😼  03:06, 25 October 2023 (UTC)

I think there is a meaningful distinction made when certain classes of words are treated as foreign, e.g. in law, philosophy, religion, and so on, in a way that creates a small, but real sense of, well, foreign-ness. That's my main impulse here. Remsense聊 03:34, 25 October 2023 (UTC)

Well, I have to strenuously disagree with the majority of your examples above. Many of them have very limited use in English, and even where they have a fair amount they are most often encountered under a differently anglicized spelling, like chi, and ronin and charge d'affaires with no diacritics. Gendankenexperiment and Landsknecht are not of a comparable type; the first is a generic term while the second is a proper name for a group of mercenaries (directly comparable to the Gallowglass, which is also a proper name). Several of these like Gedankenexperiment and Deus ex machina and status quo ante bellum are field-specific jargon with only limited use outside science and theatre/media crit and international law, respectively. If I were to suggest any general principle it would be that if the borrowing from a non-English language is multi-word or contains a diacritic, it should be italicized; if it is one-word and contains no diacritics, it should be given without italics if the preponderance of modern dictionaries and other sources on English usage treat it as English and not as a foreignism that has gained some currency in English (thus "arguendo" and "lapsus", but "alias" and "video"; "brunoise" and "mirepoix" but "aioli" and "fondue"). But I am not proposing any such rule, for reasons I've already given: in short, it would just be subject to endless wikilawyering by people with way too much time on their hands to wear out the competition in attempts to subjectively "prove" enough assimilation to WP:WIN in their style-war WP:BATTLEGROUNDing. No thanks. Just continue to leave all this to editorial discretion at particular articles. Especially since a particular term's assimilation level actually varies by context. In many cases, an English adoption of a foreignism has a specific, divergent meaning in the jargon of a particular field in English, and is pretty well-assimilated with that novel meaning within that subset of English, and may not need italicization in an article on that subject; but it remains a non-assimilated foreignism that should probably be italicized when used (perhaps metaphorically) even with the new meaning outside of its jargon home in our language; and it remains an italicized foreign word entirely when it's used with the original meaning it had in the origin language. (This is especially the case with a lot of Latin as well as a few French terms in English legal usage, but there are many other cases, e.g. German Gymnasium has nothing to do with the meaning of English gymnasium, and Spanish arroyo means 'stream' but is used in Southwest American English to mean 'usually dry streambed; small canyon, ravine'.) No evidence has been presented of long-term, intractable, repetitive dispute about such matters, so MoS needs no new rule about it.  — SMcCandlish ☏ ¢ 😼  05:13, 25 October 2023 (UTC)

Use of italics in relation to food and drink

On most of the food and drink pages italics are used improperly (I have spent many hours of my days correcting errors of this kind), for example: many times on a page a food is put in italics and on the same page many times it's not; on one page a food is made italics and on others the same food is not made italics; it almost always happens that when one enters a wikilink of a food put in italics, one is confronted with a page without that food in italics. I myself struggle to continue reading foods and drinks pages, I don't want to imagine in the mind of a reader how much bloody confusion is created. I would propose to have a bot act by removing all italicised food and drink terms, or, even better, selecting every existing food, deciding whether to make it italic or not, and, again through the bot, changing everything at the same time, without (which is impossible) doing it without bot. I, however, have done my best, but I will announce that I will never again spend time on this problem, as I am in an endless loop. I wonder what's the point of italicising a food If there is zero uniformity. JackkBrown (talk) 00:52, 10 November 2023 (UTC)

It's unclear what sort of response to make to this without some specifics. What I would guess at from this vague report is that various food and drink items are rendered in italics per MOS:FOREIGN because they are not English-language terms. In such a case, the unitalicized instances should be italicized. If someone has been putting some instances of English-language terms in italics, like bread and mince pie, these should not be in italics. There are apt to be some judgement-call cases like enchilada and étouffée where the term originates in a foreign language but has currency in some particular English dialects; in those cases, consensus should be established at the article on the dish whether to consider it as English or as an italicized foreignism, and the usage of italics or not at other pages that mention it should follow the lead of the main article.  — SMcCandlish ☏ ¢ 😼  15:32, 10 November 2023 (UTC)

For an example, see the list of Italian dishes which the OP has been working on. The first entry is Acquacotta in which italics are reserved for variations rather than the primary dish. That seems sensible as the primary dish name appears repeatedly and it would be wearisome for both readers and editors to have it italicised, especially if language templates were used for every occurrence. Andrew🐉(talk) 10:17, 28 January 2024 (UTC)

@Andrew Davidson: so you're saying that "acquacotta" on the list of Italian dishes page shouldn't be written in italics? JackkBrown (talk) 12:04, 28 January 2024 (UTC)

Italics or not?

Should the terms "trigon" (game), "Episkyros", "caid" (sport), "harpastum", "Pasuckuakohowog" and "Calcio Storico Fiorentino" be put in italics? JackkBrown (talk) 16:40, 14 November 2023 (UTC)

Yes, since they are foreign terms that are not widely assimilated into English. And none of these should be capitalized, per MOS:SPORTCAPS, including even fiorentino since Italian does not capitalize adjectives derived from proper nouns. Where feasible (i.e. not in headings, where we don't inject templates) these should be wrapped in {{lang|grc-Latn}}, {{lang|ga}}, {{lang|la}}, {{lang|pim}}, {{lang|it}}, as appropriate.  — SMcCandlish ☏ ¢ 😼  18:27, 14 November 2023 (UTC)

"Thyrsus"

Hi, "Thyrsus" and "Kylix" goes in italics? JackkBrown (talk) 17:00, 15 November 2023 (UTC)

You already asked this in user talk; yes, they are italic for a reason, as non-English (ancient Greek) words.  — SMcCandlish ☏ ¢ 😼  22:47, 15 November 2023 (UTC)

Underlining what's being pointed out

In this edit to One (pronoun), SMcCandlish replaced underlining with emboldening, citing MOS:UNDERLINE, which has this to say:

Underlining is used in typewriting and handwriting to represent italic type. Generally, do not underline text or it may be confused with links on a web page.

(My emphasis, natch.) This implies to me that there are times when underlining can be appropriate. Additionally, boldface is somewhat iffy. MOS:BOLD says of it:

Boldface (text like this) is common in Wikipedia articles, but is considered appropriate only for certain usages. [...] For semantical emphasis (to denote importance, seriousness, or urgency), you can also use the HTML element <strong>...</strong>, or the template {{strong}}. This is desirable because the words can stand out for text to speech and other software, important due to accessibility issues.

Unsurprisingly, underlining in wikitext with the HTML U tag results in <u>underlining</u> with the HTML U tag. But emboldening with multiple apostrophes results in <b>emboldening</b> with the HTML B tag. Both U and B are presentational rather than semantic (or "semantical"). So from the point of view of text-to-speech, multiple-apostrophe emboldening doesn't seem an improvement over regular underlining. And however unshouty the intention, boldface can be criticized for shoutiness.

How about either Template:Uline (permitting different kinds of single underline) or Template:Uuline (for a double underline)?

• I daresay one of these would be better.
• I daresay one of these would be better. (Or some other color/width variation.)
• I daresay one of these would be better.

I'd go for Template:Uuline myself, but I'm open to persuasion. -- Hoary (talk) 00:27, 10 December 2023 (UTC)

Agree--Brett (talk) 01:24, 10 December 2023 (UTC)

Incidentally, using Template:Uuline in wikitext for this currently brings <span style="border-bottom:3px double">this</span> in HTML. Nothing about this is semantic: like DIV, SPAN is semantically a blank, and the border-bottom attribute is presentational (which is what CSS is for). Perhaps <span class="emph">this</span> would be better, with CSS specifying elsewhere (i) for mainstream browsers that span.emph should be interpreted as bringing about a double underline, or a green dotted underline (yes, CSS can do all this), or anyway some way (decided on by WMF web designers, perhaps) of emphasizing that is not regular underlining, not emboldening, and not italicizing, and (ii) for audio browsers that it should be interpreted as -- well, others will have a better idea than I do. -- Hoary (talk) 02:53, 10 December 2023 (UTC)

Just see MOS:UNDERLINE. It is not a style Wikipedia uses, and this was a decision the project came to a consensus about something like 20 years ago. If you need to "call out" a text fragment like this in a visual way, use italics. If italics are already over-represented in that content for another purpose (foreign terms, titles of works, whatever), then use boldface. There is nothing new or special about this. Whether it should really be done with semantic emphasis (<em> or {{em}} for the italic kind, or <strong> or {{strong}} for the bold kind) is debatable, and I'm not sure I care at all. As long as it's not underlining.  — SMcCandlish ☏ ¢ 😼 

I have to disagree on this. The standard display for links on Wikipedia is blue, no underline, with underline on hover. A black, non-hovering underline in rare circumstance seems perfectly acceptable. For those rare readers who have unusual, custom CSS enabled, underlines should be quite clearly contextual, but perhaps a double underline would provide more distinction. Note that underlines are certainly used (and useful) in some areas, including linguistics (eg, Antecedent (grammar)). It is a very different web than it was 20 years ago; there is room for a (small and constrained) change to the MOS. — HTGS (talk) 05:49, 12 December 2023 (UTC)

Disagreeing with one rationale (i.e. that it looks like links to too many readers) does not address all of them, most notably the fact that we already have two prescribed ways of doing visual and, where appropriate, semantic emphasis. There is no rationale for a third one, especially when there's a two-decade consensus against using it. Being able to find a few instances of the guideline not being followed, on pages virtually no one watchlists, is not evidence the guidelines are broken or that consensus has changed. Just saying it could change doesn't mean it should change. Having what amounts to a WP:ILIKEIT feel for underlining isn't an argument for us to reverse consensus and start underlining. If there is a field-specific use of underlining that is codified by an international standards body and nearly always employed in writing applicable material in that field, then we'd be fairly likely to internally codify an exception for it, as we have done at MOS:ALLCAPS for some specialized uses of smallcaps. But we remain entirely clear that we otherwise do not use small-caps or all-caps, just like we don't use underline. Bust wanting to write something like "She goes to the store" to highlight that something is a verb is better done with "She goes to the store" or, in material already festooned with italics for other purposes, "She goes to the store". We have zero demonstrable need for a third markup style to do this.  — SMcCandlish ☏ ¢ 😼  00:50, 14 December 2023 (UTC)

Three further comments:

(a) in Chrome (at least on Android and Chromebook), all wlinks are underlined unless an editor has specifically specified "No underline". So this is how the large majority of readers see wlinks presented. This reality can lead to horrendous complications, see discussion at Talk:Glossary of mathematical symbols#Potentially confusing wikilink markup

(b) Wikipedia is not alone in deprecating underlines: as a lasting markup for text, it has been removed from HTML, see Underscore#HTML <u> and CSS.

(c) It is a proof-reader's mark on typescript and manuscript which says "italicise this text". No self-respecting typographer would use it.

Just don't. --𝕁𝕄𝔽 (talk) 20:33, 27 January 2024 (UTC)

List of multiple discoveries, Bold format

Editorial input is sought at Talk:List_of_multiple_discoveries#Bold_format regarding the use of bold format in the article. Mitch Ames (talk) 00:56, 1 January 2024 (UTC)

Appropriateness of bolding redirect

Additional opinions are needed at Talk:Daria#Tracy Grandstaff regarding whether it is appropriate to place Grandstaff's name in boldface while Tracy Grandstaff is a redirect to Daria. Thank you for providing additional opinions. DonIago (talk) 05:54, 7 January 2024 (UTC)

Proposed clarification about Foreign terms

In this edit at Adolf Hitler, I removed language markup that previously was coded thus:

The baptismal register did not show the name of his father, and Alois initially bore his mother's surname, {{lang|de|"Schicklgruber"|italic=no}}.

dropping the {{lang|de}} template and retaining only the double quoted name. This seems self-evidently correct to me, because this occurs in running English text, and there's no reason for marking it up with a {{lang}} template. Put another way, none of the criteria listed at Template:Lang#Rationale apply, and in particular, the screen reader item does not apply, as we don't want to switch pronunciation to German in the middle of an English sentence just to pronounce his birth name. (If further argument were needed: plenty of native-born Germans have names of Russian (or Turkish) origin, so then what: we tag the name for German pronunciation? Or we tag it for Russian or Turkish, even though the person involved would pronounce it in the German fashion?)

The tricky part, is how to word this parsimoniously in the text, without using as many words as I just did. Perhaps this addition to § Foreign term would do:

−

When a name should not be italicized, language markup can still ensure proper pronunciation in screen readers, by using the <code class="tpl-para" style="word-break:break-word; ">|italic=unset</code> parameter: <code>{{[[Template:Lang|lang]]|de|italic=unset|Nürnberg}}</code>.

+

When a name should not be italicized, language markup can still ensure proper pronunciation in screen readers, by using the <code class="tpl-para" style="word-break:break-word; ">|italic=unset</code> parameter: <code>{{[[Template:Lang|lang]]|de|italic=unset|Nürnberg}}</code>. However, language markup should not be used for the name of an individual, unless it is part of a longer expression in the language.

Or maybe:

Names of foreign individuals or personal names of foreign origin in running English text in the article should generally not have language markup.

Either of these would have covered the situation I changed wrt "Schicklgruber", and I would have liked to be able to link a MOS section in the edit summary to substantiate my edit. Mathglot (talk) 01:47, 27 January 2024 (UTC)

Given that there are cases where someone's name may have a non-standard pronunciation even within the same language (e.g. Diane Arbus), relying on language tags to aid screen readers is already a problematic approach. I'm a big fan of pronouncing names correctly, but language tags are not the solution. Orange Suede Sofa (talk) 03:10, 27 January 2024 (UTC)

Yeah, I had Shelley Fabares in mind (Ralph Fiennes is another) but I figured I had said enough already (but it works as a self-reply ;-) ). Mathglot (talk) 03:28, 27 January 2024 (UTC)

Oppose change that broad. If there's an unusual case like Ralph Fiennes, just don't use it in that case. And there is no need to use it for simple cases that a screen reader is not going to mangle (maybe that includes Schicklgruber, I'm not sure). But for some languages, like Irish and Scottish Gaelic, no screen reader is going to do anything but completely mangle a name like Saorbhreathach Ó Flaithbheartaigh (Irish) or Dior-bhorgàil Ìomharach (Scottish) that doesn't have the lang tag (not that every screen reader is going to be able to handle every language already, but the markup needs to be there for those that support the language, which is something that will grow over time).  — SMcCandlish ☏ ¢ 😼  19:58, 27 January 2024 (UTC)

Double italics implies no italics?

Outside Wikipedia, I'm used to the convention of brief expressions that would normally be italicized in running text (such as a foreign term) being unitalicized to maintain the font style contrast with surrounding text when the brief expression is embedded in a longer section of text which is italicized for other reasons. I wonder if we do this? An example might be (1) a major work title inside a hatnote. (Also, out of curiosity: does anyone know if there's a name for that type of unitalicization?)

Another type of "double" is when two different italicizing criteria listed at MOS:ITALICS both apply to a single expression, for example, both MOS:WAW and MOS:FOREIGNITALIC at the same time. For a RW example, see sentence two at Affiche Rouge (2):

"The term Affiche Rouge also refers more broadly to the circumstances surrounding the poster's creation and distribution..."

Should 'Affiche Rouge' be italicized? The term Affiche Rouge is being treated as a term, therefore MOS:WAW applies and it should be; MOS:FOREIGNITALIC also applies, so does that negate the original italicization criterion, or just confirm it? Another might be (3) a {{Main}} or {{Further}} link (normally italicized) linking an article about a book/major work whose title is normally italicized. Would it matter, if (4) the {{Further}} template had three links, say, and only one of them was a major work (or fulfilled any other italicization criterion) so that two "regular" links would be italicized, but the one book article link would not?

I think I tend towards: 1=no italics, 2=yes, 3=yes/either, 4=no. Mathglot (talk) 01:27, 13 February 2024 (UTC)

About your example: of course Affiche Rouge is to be italicized – if there are two reasons use italics, that doesn't make these reasons go away. (Assuming somebody says to you: "I had two reasons to do it, hence I didn't do it." – Would you consider that person sane?) The classical actual case of "double" italics becoming non-italic are, of course, book titles within book titles, say How The Lord of the Rings Created Modern Fantasy Literature.

As for hatnotes, I'd say it applies if only parts of a note element are to be double-italicized. You can see an example at The Lord of the Rings#Reception, which has a hatnote:

Main article: Literary reception of The Lord of the Rings

On the other hand, I wouldn't un-italicize an article title just because it's rendered in italics itself. For example, the "Context" section of the latter article has a hatnote:

Further information: J. R. R. Tolkien and The Lord of the Rings

One could argue that "The Lord of the Rings" should be un-italicized here, but I don't think that would be particularly helpful (rather it could be confusing). Effectively it means in this context: see our article "The Lord of the Rings", not see the book The Lord of the Rings, so there's no reason for another set of italics. Gawaon (talk) 07:47, 13 February 2024 (UTC)

Bolding titles

Hi, I've been told that I shouldn't bold titles however it's not stated in WP:MOS as far as I can see. On List of kingdoms in Africa throughout history, I would like to bold the headings referring to regions (like North Africa, East Africa) to make their superiority to the time periods (Ancient, Post-classical) clearer, particularly in the 'Contents' list.

Also I would like to bold 'List of kingdoms' to denote its importance relative to 'Comparison' and 'History periods', which just offer supplementary information.

Thank you in advance for any help Alexanderkowal (talk) 20:47, 12 March 2024 (UTC)

I guess you missed MOS:NOBOLD? Listen to what people tell you, they are right! (In this case, maybe not in others.) Gawaon (talk) 07:47, 13 March 2024 (UTC)

Also MOS:FAKEHEADING. Gonnym (talk) 08:14, 13 March 2024 (UTC)

@Gonnym I might be blind but it doesn’t say don’t bold section headings as far as I can see Alexanderkowal (talk) 09:41, 13 March 2024 (UTC)

See Wikipedia:Manual of Style/Text formatting#Automatically applied boldface older ≠ wiser 09:47, 13 March 2024 (UTC)

@Bkonradmy bad thank you Alexanderkowal (talk) 09:50, 13 March 2024 (UTC)