Wikipedia talk:Manual of Style/Text formatting

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

Use bold for minor sub-sub-sections?[edit]

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)[reply]

You are looking for MOS:PSEUDOHEAD Gonnym (talk) 18:23, 14 June 2023 (UTC)[reply]
Gonnym, thank you. I see MOS:PSEUDOHEAD is exactly what I'm looking for. --DavidCary (talk) 07:12, 26 November 2023 (UTC)[reply]

Use of italics in relation to food and drink[edit]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]

Italics or not?[edit]

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)[reply]

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)[reply]

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

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)[reply]

Underlining what's being pointed out[edit]

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)[reply]

Agree--Brett (talk) 01:24, 10 December 2023 (UTC)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]

List of multiple discoveries, Bold format[edit]

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)[reply]

Appropriateness of bolding redirect[edit]

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)[reply]


Proposed clarification about Foreign terms[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

Double italics implies no italics?[edit]

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)[reply]

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:
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:
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)[reply]

Bolding titles[edit]

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)[reply]

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)[reply]
Also MOS:FAKEHEADING. Gonnym (talk) 08:14, 13 March 2024 (UTC)[reply]
@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)[reply]
See Wikipedia:Manual of Style/Text formatting#Automatically applied boldface olderwiser 09:47, 13 March 2024 (UTC)[reply]
@Bkonradmy bad thank you Alexanderkowal (talk) 09:50, 13 March 2024 (UTC)[reply]