Edge Rewrite
restyle Source code View original
// HTMLRewriter · presentation

This page was redesigned at the edge.

Cloudflare fetched the original article and streamed it through HTMLRewriter to apply an entirely new visual system without rebuilding the source page.

Jump to content

Wikipedia talk:Manual of Style

Page contents not supported in other languages.
Add topic
From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:MOSTALK)
Latest comment: 1 day ago by Redrose64 in topic Italicized section headings with a colon (:) at the end.

Style discussions elsewhere

[edit]
Latest comment: 8 months ago1 comment1 person in discussion

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

[edit]

(newest on top)

Pretty stale but not "concluded":

Capitalization-specific:

This section is an excerpt from Wikipedia talk:Manual of Style/Capital letters § Current.[edit]


Move requests:

Other discussions:

Concluded

[edit]

Italicization of self-refs, redux

[edit]
Latest comment: 3 days ago56 comments9 people in discussion

Sometime circa 2014, @SMcCandlish took it upon themself to (as far as I can tell) unilaterally change the manual of style's recommendation about whether parenthetical references to other articles/sections like "(see above)" or "(see Main page)" should be italicized. In my opinion this change was typographically wrong, ugly, harmful to readers and editors, and not carried out according to any appropriate procedure. (But maybe I'm missing some other discussion or RFC. I didn't do an exhaustive survey.)

The previous recommendation and prevailing practice site-wide (and in my opinion obviously typographically correct choice) was to not italicize "see also" asides wrapped in parentheses. It was documented by @Cedders in the MoS in 2009:

A further type of cross-reference may occur within a paragraph of text, usually in parentheses. For example:

At this time France possessed the largest population in Europe (see Demographics of France).

Unlike many traditional reference works, the convention on Wikipedia that has evolved is that "see" or "see also" are not in italics. Nor are the article titles put in quotation marks.

This recommendation matches common practice from professionally typeset sources, which will either use italics or use parentheses, or sometimes neither (just using commas or dashes, or putting such references in sidenotes or footnotes), but rarely both. Parenthetical asides are already clearly offset from the text by the parentheses; adding italics on top of that accomplishes nothing except to make them gratuitously distracting.

SMcCandlish threw up a "disputed" tag on the manual of style page Wikipedia:Manual of Style/Text formatting § Uses of italics that are specific to Wikipedia, started a talk page discussion Wikipedia talk:Manual of Style/Text formatting/Archive 5 § Italicization of self-refs, created a {{crossreference}} template, and then when nobody else replied, went ahead and unilaterally changed Wikipedia:Manual of Style/Text formatting § Uses of italics that are specific to Wikipedia to now say that such asides should be italicized. As far as I can tell this change was not backed by any evidence of consensus or buy-in from other editors, but only at best indifference / lack of awareness of the discussion.

Since that time, most existing articles and most new articles continue to follow the prevailing practice of just putting such asides in parentheses without italics, which remains as far as I can tell the dominant consensus style. That is: the MoS recommendation is not consistent with ordinary Wikipedia practice. But sometimes editors, in an attempt to be helpful, go through all of the asides on some page or another and change them all to be italicized / wrapped in crossref templates, in a bot-like fashion. In my opinion such edits are (mildly) disruptive and unhelpful.

In my opinion, this manual of style change should be reverted based on apparent editor consensus, and the {{crossreference}} template should be changed to not italicize its content, to make intra-article style more consistent. At the very least, the manual of style should clarify that this italicization is optional and should recommend against changing upright text to italics following WP:STYLEVAR. Any articles using italics for this should drop the parentheses. But in my opinion any change to the MoS to italicize such asides should go through a formal RFC with significant community involvement instead of just a unilateral edit of the manual of style to enforce one person's misguided personal preference. –jacobolus (t) 21:37, 27 July 2026 (UTC)Reply

Do you seriously want to challenge a change that happened 12 years ago based on insufficient consensus at that time? I'd say it has long since clearly gained EDITCON if nothing else. As for the substantial question: I think it makes sense to treat both kinds of internal cross-references similarly. So as long as hatnotes are italicized, inline cross-references should be italicized too. Gawaon (talk) 02:50, 28 July 2026 (UTC)Reply
Yes, seriously: one person's unilateral bad decisions made years ago without (contemporary or current) consensus should not be forced to remain for all time. (a) I think there is insufficient consensus today, and the typical example I encounter does not have both parens and italics; as far as I can tell only a trivially tiny minority ever preferred this style, and they have tried to unilaterally force it on everyone else without appropriate justification; and also (b) I think this is simply typographically wrong, ugly, distracting, and makes Wikipedia look amateurish, and so should be reverted to the language from 2014 on basic grounds of typographic style and good taste.
"makes sense to treat both kinds of internal cross-references similarly" – In that case, you should support removing parentheses from any "see also" aside which is italicized. I would also be okay with that as a recommended style, if the community prefers. You can certainly find plenty of professionally typeset sources which use italics as the method of indicating such asides. What you won't often find is a professionally typeset source redundantly using both italics and parentheses for this.
A third acceptable alternative would be for the MOS to use neutral language which makes clear that the choice of style for such asides is an arbitrary preference with any more or less reasonable alternative allowed as long as each article is internally consistent. That would probably most closely match the current empirical consensus of editors. –jacobolus (t) 04:21, 28 July 2026 (UTC)Reply
Forget about how the change came about; it was 12 years ago. Any change made now would need to gain consensus on its merits alone. Personally, I remain unconvinced for the reason already given above. I also think that "allow both variants" would be a bad solution. The good thing about conventions is that they are uniform, minimizing reader surprise. Whether or not we change the convention, it shouldn't result in an "either variant is fine" solution. Gawaon (talk) 05:33, 28 July 2026 (UTC)Reply
There are a very wide range of style questions about which the MOS recommendation is "allow variants", and it works completely fine. But picking a single style would be fine; it just shouldn't be the current recommended variant, which is straightforwardly typographically bad. Either the previous recommendation (of unitalicized parenthetical asides) or an alternate recommendation – italicized but not parenthetical asides – could be adopted. The latter would have the advantage of matching the style used by Wikipedia policy pages, but Wikipedia policy pages and Wikipedia articles don't necessarily need to have the same style. –jacobolus (t) 06:51, 28 July 2026 (UTC)Reply
How would "not parenthetical asides" work in inline style? Can you give a specific example? Gawaon (talk) 09:14, 28 July 2026 (UTC)Reply
Sure. Putting these asides in italics offsets them from the text:
We have been discussing the use of italics. See Wikipedia:Manual of Style § Italics. We have also been discussing variations of style. See also Wikipedia:Manual of Style § Retaining existing styles.
Alternately, we could use parentheses:
We have been discussing the use of italics. (See Wikipedia:Manual of Style § Italics.) We have also been discussing variations of style. (See also Wikipedia:Manual of Style § Retaining existing styles.)
Either of these does a fine job of offsetting the aside from the text. Both of these styles are relatively common in published works. But redundantly combining them is distracting and unnecessary:
We have been discussing the use of italics. (See Wikipedia:Manual of Style § Italics.) We have also been discussing variations of style. (See also Wikipedia:Manual of Style § Retaining existing styles.)
–jacobolus (t) 17:46, 28 July 2026 (UTC)Reply
I personally like this, as it makes the cross-reference stand out more, clearly distinct from the rest of the paragraph. Just as hatnotes stand out by getting a paragraph of their own, being indented, and set in italics. They are triply marked, while inline cross-references are merely doubly marked. Redundant? Yes. Harmful? No; rather useful I'd say, visually setting them clearly off from the text of the article – in the case of inline references far more than parentheses alone, or italics alone, could. So I'd plead to keep these redundancies, in the interest of improving the reading experience. Gawaon (talk) 02:19, 29 July 2026 (UTC)Reply
But these are not hatnotes. They serve a completely different purpose and have completely unrelated typographical needs. To be more explicit: the original and most important hatnotes are disambiguation links, whose point is to redirect readers who accidentally arrived at the wrong place; the hatnotes are explicitly not part of the text, and disambiguation links are not even related to the text. We move them entirely out of the regular text stream and set them in a different typeface so that readers are clearly notified that they are separate and shouldn't be read as part of the article. Other kinds of hatnotes don't necessarily need such a treatment, but we typeset them consistently to avoid mixing up too many different styles. That is all fine. But even so we merely italicize the hatnotes; we don't make them bold, or put them in a visually heavy box, or make them blink. They are clearly visible but they don't to out of their way to call attention to themselves.
Making things look garish does not "improve the reading experience". It just confuses/distracts readers and makes them think we are incompetent and careless. –jacobolus (t) 06:20, 29 July 2026 (UTC)Reply
"See also" hatnotes and "see" inline cross-references serve the same purpose; they only differ in where they are placed. Gawaon (talk) 07:47, 29 July 2026 (UTC)Reply
This is not correct. The hatnote is an extra-textual commentary about an entire section, telling you that the topic of the section is also treated elsewhere (either the current section is a short summary of that link, or the alternate link covers the same or an overlapping topic from a different perspective).
The inline 'see also' link is an explicit part of the article content, which points readers to an explanation of a particular term, sentence, point of confusion, etc., either on the same page or on a different page. There are alternate ways of achieving the same explanatory effect: linking to an external resource (e.g. in a citation footnote), floating an explanatory figure to the side of the text, including a parenthetical gloss of a term, or the like.
These two are almost entirely distinct in their purpose and their typographical constraints and needs. –jacobolus (t) 07:56, 29 July 2026 (UTC)Reply
That's not my understanding of them, and does not seem to describe their regular usage. {{Crossreference}} describes them as usually "unprintworthy" and points to the "{{Hatnote}} meta-template and its various progeny" for "block-level crossreferences" – so, exactly the same thing, but block-level. It also mentions that it's rendered via Module:Hatnote inline – so a {{Crossreference}} is essentially just a hatnote without a hat. Gawaon (talk) 11:15, 29 July 2026 (UTC)Reply
The crossreference template and its documentation was entirely created by one editor whose personal views do not, in my opinion, reflect the consensus of the community or typical readers' understanding of such cross-references in Wikipedia or other published reference works.
I don't think these should generally be considered "unprintworthy". (Though in some cases they might be; it would be worth having a broader community discussion about that topic, but it's probably a bit off topic here.) –jacobolus (t) 11:20, 29 July 2026 (UTC)Reply
I also find this visually pleasing. It's also worth noting that these inline "see also" are generally discouraged, so readers likely see them relatively rarely. pburka (talk) 16:45, 29 July 2026 (UTC)Reply
Regardless of whether various editors find it visually pleasing or not (we already know some do and some don't and that this is personally subjective), the fact remains that the template italicizing guarantees that the crossreferetial aside will be distinct from the central content of the article, while we cannot ever guarantee that parentheses (round brackets) would be added to them, nor italics, in the absence of the template. (We know this for a fact already because various editors, mostly unaware of the template and MoS and WP:SELFREF and so forth, some more experienced and just uninterested in templates and otehr formatting), will just write something like "... at the end of 2012. See [[Whatever the other article title is]] By mid-2013, ...", with no markup of any kind. As with all matters in all guidelines, we cannot expect and do not require that people adhere to them when writing content here; the only actual need is for editor who do not bother with such fine points to not disrupt other editors massinging our content into forms compliant with the guidelines and otherwise improving it. No one "owns" and article and the content they put into it. Furthermore, there are good reasons to permit punctuation differences in approach to crossrefs. In material already heavy in italics (perhaps lots of work titles, or lots of non-English phrases), setting off an aside with paretheses may be highly desirable as an additional visual distinction. In a passage already highly clustered with parens (perhaps content about a progamming language that uses them copiously), then it might work better to have a cross-reference without them, or to put the crossref in square brackets. In any such circumstance, it might be better to do something else, like rework the text to use an in-context link instead of an explict "instruction to the reader" crossref, or (if the crossref pertains to a good block of material), to use a "traditional" block-format hatnote.  — SMcCandlish ☏ ¢ 😼  11:15, 30 August 2026 (UTC)Reply
I agree with jacobolus. Silent consensus only exists until challenged; once its challenged, it's gone. A unilateral change to a guideline that literally no other editor weighed in on (just as likely out of indifference than actual concurrence) is the weakest of the weak kind of "consensus". Further, the MOS is supposed to reflect actual editing practice: if editors are all but universally doing something different, and all professional online publications are doing something different, then the MOS should be changed to reflect the reality. Arguing for status quo because of the length of time it's been in place is not a valid argument (I'm sure it's some kind of informal fallacy but I don't know the name off the top of my head). ~2026-40817-33 (talk) 21:57, 28 July 2026 (UTC)Reply
Not correct all, or one drive-by anon could instantly discredit literally hundreds of lines of actual policy, and thousands of lines in guidelines. In reality, an editor has opened a question when one was not present before (for over a decade). Long-standing material is presumed to have consensus; an unchallenged change to it will also come to such a consensus over time, but the proposed change here has already been controverted immediately and unequivocally by multiple editors. So what we are left with is a question of whether the extant material still has consensus (which does not mean unanimity).  — SMcCandlish ☏ ¢ 😼  11:15, 30 August 2026 (UTC)Reply
I don't know what styleguides recommend, but I did a quick spotcheck of another encyclopedia (Britannica), and found "(See Sidebar: Ralph Rose and Martin Sheridan: The Battle of Shepherd’s Bush.)" and "(See also Sidebar: Dorando Pietri: Falling at the Finish.)" in "London 1908 Olympic Games" (the first page I looked at). pburka (talk) 20:01, 28 July 2026 (UTC)Reply
Fair enough. Note the upright (not slanted) parentheses. Current online Britannica seems to only sometimes use parens, but apparently always italicizes see or see also. A different example: See also list of herbs and spices. A print version of Britannica from the 1970s (first one I found) uses no parentheses, with italics for 'See also' and small caps for the article name. A print version of Britannica from 2003 uses no italics at all, sometimes uses parens, and puts article names in small caps. Example 1: This article discusses the further development of sub-atomic particle theory, as well as the various classes of subatomic particles and current areas of research. See also the articles atoms: their structure, properties, and component particles; mechanics: energy, forces, and their effects; and radiation for additional information on the interactions of subatomic particles and on their role in the structure of matter. For details on the detection and measurement of subatomic particles, see particle accelerators. Example 2: (For further details on the history of the Byzantine Empire, see also the Macropædia article byzantine empire, the history of the.) –jacobolus (t) 23:01, 28 July 2026 (UTC)Reply
Yeah, when even a singular particular publisher is inconsistent in their styling of cross-references, we cannot give any credit to the argument that WP has to do it this way or that way because of what one or more off-site publisher allegedly prefer.  — SMcCandlish ☏ ¢ 😼  11:15, 30 August 2026 (UTC)Reply
To the contrary: this is good evidence that the most reasonable appearance depends on the context, and trying to standardize it to a single specific style is destroying relevant information which the author/editor was trying to communicate. Writing in general, including writing on Wikipedia, is full to the brim of such cases, and in general we take no position on them, but instead leave choices to authors' discretion and local consensus. –jacobolus (t) 11:42, 30 August 2026 (UTC)Reply
I think we should allow for some flexibility. I like the recommended combined approach in certain circumstances where we are essentially adapting the function of certain hatnotes like {{Redirect}}, {{For}}, {{About}}, etc. This is especially useful when there is a primary redirect to an anchor at at list entry or in the middle of a section. The idea is to make this stand out for readers who landed there expecting to find some other topic. Where the internal cross reference is directly relevant to the subject of the article(see above; see Demographics of France) I can see the argument for making it more integrated with the surrounding text but I don't think this matters all that much. —Myceteae🍄‍🟫 (talk) 20:35, 28 July 2026 (UTC)Reply
The need to flag inside-the-same-page crossrefs with a printworthy parameter means the template still needs to be applied. Having it veer around between italic and not, often enough in the same block of text, based on the criterion (entirely opaque to virtually all readers) of which page a particular link points to, which could change at any time, would border on intentionally confusing, the tail wagging the dog.  — SMcCandlish ☏ ¢ 😼  11:15, 30 August 2026 (UTC)Reply
I was editing a similar cross-reference recently and after experimentation felt the following looked the best:

For gaming use, baize is traditionally dyed green, in mimicry of a lawn (see History of cue sports),

which I submit for the consideration of the crowd. (I do not think the parens should be mandatory; they just worked for the sentence in this case.) Dingolover6969 (talk) 08:46, 31 July 2026 (UTC)Reply
However, I think it's weird that the article title is italicized here, because this violates the major–minor works rule, or at least will appear to to the casual reader, so perhaps making that xref template just do the colored background and smaller text would be best.

I'm also fine with editors doing the common style (see also X) with no fancy formatting, which I'm sure many will continue to do.Dingolover6969 (talk) 08:51, 31 July 2026 (UTC)Reply

Are there any objections to my BOLDly changing Wikipedia:Manual of Style/Text formatting to be more permissive of variant styles? @SMcCandlish hasn't shown up to this discussion, and nobody else seems particularly attached to the site-wide imposition of his personal preference. –jacobolus (t) 18:27, 21 August 2026 (UTC)Reply

I think we should allow some variance, as I've said. I'm not sure what exactly the MOS should say or if this is something we even need to address. —Myceteae🍄‍🟫 (talk) 19:48, 21 August 2026 (UTC)Reply
I think I'd change the MOS to say that some external reference works italicize just phrases like see or see also, some reference works italicize the entire cross-reference, some reference works wrap such cross-references in parentheses and don't italicize them, and some combine parentheses with italics. On Wikipedia, some articles use parentheses, some use italics, and some use both, and any of these styles can be fine subject to local consensus and intra-article consistency. –jacobolus (t) 19:54, 21 August 2026 (UTC)Reply
That's awfully wordy. Do you think we need to address this at all? This appears to be an occasional practice that editors accomplish in a variety of ways. We've had guidance of some sort for a very long time but it's not followed. Sometimes it is useful to document explicit consensus to allow particular WP:STYLEVAR or to document a lack of consensus for how to handle something but in this case I don't see the benefit. —Myceteae🍄‍🟫 (talk) 23:07, 21 August 2026 (UTC)Reply
One alternative would be to just revert to the version from 2014. –jacobolus (t) 00:14, 22 August 2026 (UTC)Reply
There is certainly no consensus for that. I just did a quick skim of the discussion, having not looked at this for several weeks, and I see more support for either the current recommendation or allowing variance than I do for reverting to the old guidance. —Myceteae🍄‍🟫 (talk) 01:39, 22 August 2026 (UTC)Reply
The OP and several other comments here have "fallacy of the revelation of policy" problems (in short: all edits on WP are made by editors, so the fact that someone in particular made an edit that the OP doesn't like is just immaterial, and so is which editor made that edit.) Trying to personalize style-related disputes by making them be about an editor instead of the merits of the matter under discussion is a bad idea.

Moving on: Anything of this sort that has a decade of stability is considered to have an established consensus. If someone wants to undo (or otherwise radically change) something like that, they need a widely-advertised RfC concluding with consensus to make such a change, and with full awareness of the consequences of doing it and what would have to be re-engineered to compensate.

The central rationale for the italics is that they match our other permissible Wikipedia self-references (generally hatnotes and other cross-references, especially to resources outside the current page). This style was selected, in WP's earliest days, to set off such material in a clear way (when it is not otherwise set off in very obvious manner, e.g. dispute/warning templates and their big colored boxes). Since then, CSS classes are also used, so that such material can be purged from re-uses of WP content in which such cross-refs to outside material would not be helpful (typically, in printed material). The {{crossreference}} AKA {{xref}} template, and other variants of the {{hatnote inline}} meta-template, use the same italic style as all other hatnotes (most of which are block not inline – block vs. inline being the only difference between regular hatnotes and inline cross-references).

Furthermore, this has absolutely nothing to do with some other publishers italicizing things like see and c.f. (but not italicizing what follows them). That our hatnote style and those other publishers' annotation styles both involve italics is purely coincidental. Some other publisher's "See Section 7.13" style is not Wikipedia style, at all, so there is no reason for a discussion to exist here about how to impose that style in our articles by mucking around with our templates. That some editors have been trying to mimic that off-WP style in some articles (probably ones that few other editors pay any attention to) does not suddenly establish a consensus for WP to permit completely random stylization of cross-references on an article-by-article basis. We have the Manual of Style for a reason, primarily to make the site a consistent experience, across articles, for our readers. What's being proposed here is inimical to that goal, just to make a few editors happy about how they get to "decorate".

Next, this is an error, flat-out:

I was editing a similar cross-reference recently and after experimentation felt the following looked the best:

For gaming use, baize is traditionally dyed green, in mimicry of a lawn (see History of cue sports),
That would be badly mis-applying the CSS class for self-referential notes, to surround only the link to "History of cue sports", with the result that when someone reusing our content for print (or whatever) strips out these self-references, the string "(see,)" will erroneously be left behind. And this has nothing to do with "I ... felt [something] looked the best". This is not a matter of stylistic choice, it's a technical issue.

The technical matter could be "divorced" from style by not having the crossref template apply any italics, but that would be a terrible idea. We'd then have a sharp stylistic mismatch between different WP selfref components, with block ones being italic and inline ones sometimes not being italic, and thus being easily mistakable for primary article content instead of WP-referential cross-referencing, which would be, frankly, a completely pointless loss of reader-facing, functional UI/UX feature, to satisfy a trivial peeve of a number of editors that can be counted on one hand. Such a change (de-italicizing {{crossref}}) would even be a net negative for editors in general, too: without the italics, it would be impossible to tell whether the self-referential cross-ref had been marked up as a self-referential cross-ref at all, without editing the article in source mode and finding that specific spot in the article's code, a big waste of editor time. And it would make it more likely that the template would be misapplied to only surround selected parts of the self-ref, lacking any visual clue during preview.

Any time one comes upon something personally felt to be disagreeable in a guideline or policy page and one thinks "This is stupid, and there must not be any reason for it, so it should be fine if I change it willy-nilly to suit my personal preferences", one is making a mistake. We have an active corps of many thousands of users, some of them here for 20+ years, and our guideline and policy pages are watchlisted by many, plus their content is subject to more debate and refinement than anything else on the system (MoS pages much more so than other P&G pages). The OP has not magically discovered a mistake everyone else missed, but simply hadn't bothered to find out the reasons behind why something is the way it is.
 — SMcCandlish ☏ ¢ 😼  10:52, 22 August 2026 (UTC)Reply

This seems hypocritical, or to be generous let's say extremely inconsistent.

Anything of this sort that has a decade of stability is considered to have an established consensus. If someone wants to undo (or otherwise radically change) something like that, they need a widely-advertised RfC concluding with consensus to make such a change, and with full awareness of the consequences of doing it and what would have to be re-engineered to compensate.

Any time one comes upon something personally felt to be disagreeable in a guideline or policy page and one thinks "This is stupid, and there must not be any reason for it, so it should be fine if I change it willy-nilly to suit my personal preferences", one is making a mistake.

This is precisely what you did yourself.
Your original change was made, to a page which had been stable and widely adopted for many years, basically on a whim with no evidence at all of consensus (you started a brief discussion which had literally no other participants). There was no "widely advertised RFC", just one person's preference.

being easily mistakable for primary article content instead of WP-referential cross-referencing

I think this is the crux of the problem: In my opinion you have a misconception about what type of "content" these cross-references are and how authors and readers use them. I consider such references to be "primary article content"; they are substantially if not entirely distinct from hatnotes, both in their function, and perhaps especially in their typographical role. As a result you have tried to force a unification of style based on a bad premise. The result is poor typography: distracting and arguably incorrect.

when someone reusing our content for print (or whatever) strips out these self-references

These asides should not be stripped out of a printed version of an article. Stripping them out is removing part of the article content. (You will notice that the reason we have such asides is because authors/readers are used to them from print-based reference works, where they are ubiquitous.) But we also shouldn't be going out of our way to clutter our markup up today with metadata that might be useful for a hypothetical alternate future version of Wikipedia that doesn't yet exist.

pointless loss of reader-facing, functional UI/UX feature

To be contrary, the existing style is a counter-functional "UX anti-feature" which harms legibility of our articles.

without the italics, it would be impossible to tell whether the self-referential cross-ref had been marked up as a self-referential cross-ref at all

So what? Neither readers nor editors care whether a particular parenthetical aside has been wrapped in a particular metadata template. There's no strong reason that these asides should need a template at all. The project would be better off if such a template had never been created.
Now that the template exists, it's not worth the trouble of trying to eliminate it, but changing the MOS will discourage people from doing drive-by additions of this template to places where it is not necessary. –jacobolus (t) 14:18, 22 August 2026 (UTC)Reply
You have your opinion, but a change to the MOS would require reaching a consensus in this discussion. Currently I don't get the impression that we're going there. Gawaon (talk) 03:16, 23 August 2026 (UTC)Reply
The current version in the MOS is, however, not based on any evidence of consensus. In such cases the MOS should probably refrain from taking a position; otherwise it is effectively lying to readers. –jacobolus (t) 03:28, 23 August 2026 (UTC)Reply
The MOS shouldn't take a position on itself? That doesn't make sense. And the current version has about 12 years of EDITCON, by your own account. On a page watched by more than 3000 people, that's about the highest level of consensus one could hope for. Gawaon (talk) 04:08, 23 August 2026 (UTC)Reply
No, the MOS shouldn't take a position on topics where there is clearly no editor consensus. –jacobolus (t) 04:35, 23 August 2026 (UTC)Reply
To address jacobolus's complaints in detail (but collapsed to avoid derailing this discussion with a bunch more back-and-forth between two editors, and as usual it takes much more verbiage to dispel nonsense claims than to make them):
 — SMcCandlish ☏ ¢ 😼  10:26, 30 August 2026 (UTC)Reply
I'd really recommend other people skip this gish gallop. The essential gist is that anything SMcCandlish one time decided was correct can never ever be changed, because «incoherent gesticulation». If you want I can go point by point explaining why your points are substantially false, misleading, and/or hypocritical. But to be honest you don't really seem interested in understanding anyone else's point of view, and I doubt anyone else reading here would benefit from it, so it seems like a waste of time. –jacobolus (t) 11:11, 30 August 2026 (UTC)Reply
Thanks @Jacobolus for tagging me. I might as well comment as the person who raised the topic within the MoS in the ancient past (2009). As I recall, the reason I did so was that I was used to reading see and see also in italics in (British) print encyclopaedias, but when editing and checking for precedents on Wikipedia articles at the time found an almost uniform lack of italics, and I wanted to know myself how to edit such things consistently and resolve a problematic edge case for any editor in a similar situation. The guidance on hatnotes was clear, whether references or for any other type of meta-textual information, but was not followed and not relevant for inline references. Titles of longer works would be italicised, but Wikipedia articles themselves are generally not.
My preference would normally be to follow print tradition, but a) it seemed the tacit preference for no italics had come into being for understandable reasons: it's unnecessary and in longer articles disturbs the neat text; b) I wasn't going to try somehow to find all the relevant occurrences of "see" and italicise them. The existence of a template is therefore useful.
Things may have changed since my active editing days. Reflecting many years later, I'm glad the example survived, although I can't remember what article I found it in. I suspect if Jacobolus is correct, the lack of italics in parenthesised cross-references is down to editorial laziness, so may tend in that direction again whatever the MoS says. (Is there any way to research what editors tend to do?) These funny little connectives in a reference work are clear enough if set off as a sentence in parentheses. I also speculate that the print convention was only ever see and see also because q.v. (quod vide) is a foreign phrase. (As @SMcCandlish said at the time "It is correct that the practice, favored in some academic journals, of italicizing only the "see" or "see also" part is eschewed on Wikipedia, and that's an important and valid thing to note." and now "That our hatnote style and those other publishers' annotation styles both involve italics is purely coincidental.")
I do think italicising a wikiref is going to be a problem if you make it appear like a book title, and it is also not print convention. So there's probably no reason to italicise the "see" (if we agree there's no reason to follow print) and a potential problem with putting the WP article title in italics. The MoS at the moment seems inconsistent on this: "Instead, like hatnotes, these parenthetical cross-references are set off by being italicized in their entirety ... Wikipedia's own article titles are not put in quotation marks in such cross-references." Are the article titles in italics or not? By the way, what about the surrounding parentheses? I also think the reference "as Wikipedia self-references" is confusing as that guideline is about the editorial voice to the reader, and not formatting; therefore I would suggest it is eliminated.
So I suppose it comes down to: i) we would prefer consistency, but it may be hard to establish on a relatively obscure issue unless everyone uses the template; ii) the argument for inline cross-references being italicised is that they are then consistent with hatnotes, which often include cross-references; iii) the argument for having them in roman is that is is consistent with body text, which also often includes cross-references. In aesthetic terms, I'd therefore follow Jacobolus's suggestion of parens or italics but not both. The remaining argument for italics is that it might help delimit the text that the "see" refers to, before you get back into the substance of the article - but then parentheses also do that perfectly adequately. I notice that the {{Style}} box itself uses italics, although it feels unnecessary to have one set of references in italics and another (those that are supposedly more relevant) not.
Hope you come to a good conclusion. --Cedderstk 14:11, 27 August 2026 (UTC)Reply
@Cedders: There is no contradiction here: "Instead, like hatnotes, these parenthetical cross-references are set off by being italicized in their entirety ... Wikipedia's own article titles are not put in quotation marks in such cross-references." Are the article titles in italics or not? Italics are not quotation marks, so yes, the entire crossref is italic: (See also Edinburgh Castle and ...); not (See also "Edinburgh Castle" and ...); and not, in mimicry of some off-site publishers, (See also Edinburgh Castle and ...). Doing the last of these is very fiddly (unwarranted except in a case we'll get to in a moment). More importantly, when an italicized segment of text contains something that itself would be italicized for an independent reason (e.g. title of a opera, or an organism's scientific name like Brassica oleracea), then the convention (for over a century) is to to de-italicize it (reverse italicization). So, doing (See also Edinburgh Castle and ...) is actually italicizing the WP article title as a major work like a novel or movie (which we don't do), it's just in the reverse-italics context of an already-italics longer string of text. On the other hand, this would actually be correct for, e.g., a film: (See also Spider-Man: Brand New Day and ...), and should be done, same as we go through extra markup steps to italicize the work-title part of a disambiguated work on a disambiguation page, as in Dracula (1958 film), not Dracula (1958 film).  — SMcCandlish ☏ ¢ 😼  10:26, 30 August 2026 (UTC)Reply
No "off-site publisher" does what you propose here. I would be somewhat surprised you to find a single print example (ideally from before 2010) that matches any of your red-highlighted styles in the above comment. Or even if you can find one in an obscure corner somewhere, none of these was a widely accepted style anywhere before you made it up.
How titles of operas are italicized is an irrelevant non sequitur. –jacobolus (t) 10:52, 30 August 2026 (UTC)Reply
PS, some other bits: "italics ... might help delimit the text that the 'see' refers to, before you get back into the substance of the article - but then parentheses also do that perfectly adequately" – Parentheses (round brackets) and any other setting-off other than italics are frequently missing. If the template enforces italics, then visually distinction from "the real content" is guaranteed. Block hatnotes could even more arguably be done without italics because they are also forcibly indented (not even otptional), yet the consensus remains to italicize them. Next, {{Style}} has some italicized crossrefs in it because they are crossrefs (for which a style variance isn't warranted simply because they're in a template; that would be more confusing than anything), to material elsewhere that is tangentially related to the subsection in which the crossref appears. There's not going to be confusion between the main elements in that section and the crossref, because they are clearly laid out as the "meat" of the section in alpha order, centered in a bullet-delimited list, while the footnoted crossref is at the bottom and clearly introduced with "(See also ..." making it clear it's an aside. Our readers already encounter italics used for much more than emphasis (species epithets, work titles, foreignism, words-as-words, etc.), and in fact enounter it far more often for these things than for emphasis here (encyclopedias being loath to engage in any emphasis not found in quoted material), so there's little danger of the reader misinterpreting the crossref as being the most important thing in the section, for multiple reasons. On the notion of inverting the italic relationship, so that each section's most relevant links are italic and the crossrefs (in the few cases there are any) aren't: that would be fly in the face of a long-standing principle of typographic wisdome, including in online UI: If you emphasize everything, then nothing is emphasized. I.e., you'd just have a big bunch of text all in italic face for no explicable reason. :-)  — SMcCandlish ☏ ¢ 😼  10:47, 30 August 2026 (UTC)Reply
The point of the text of Wikipedia articles is to communicate the author's thoughts and ideas to the readers. In some examples authors have decided to put a "See XYZ topic" aside in parentheses. In other examples, authors have preferred to just leave them as a sentence, or used commas, dashes, or semicolons to offset them. All of those choices are completely fine in practice: readers have no trouble understanding the meaning, authors have no trouble editing the source, and those with typographic taste generally have no issue with any of them. Such a variety of styles has worked completely fine for Wikipedia throughout its history, down to today when most such links that I find are still written as ordinary prose, often but not always offset by parentheses, and almost never italicized.
The only time your own personal parentheses + italics style appears in articles is when some "gnome" editor, trying to strictly enforce every sentence of the MOS, comes to wrap everything in unnecessary and ugly templates. The existence of such editors does not indicate anything about sitewide consensus, but only shows that if you make up a rule, however arbitrary or bad, a few will be excited to impose it on everyone else. –jacobolus (t) 11:00, 30 August 2026 (UTC)Reply
First, that's abosolutely not the point of the text of WP articles, which in reality is to communicate a summary of the reliable source material to our readers; editors' own "thoughts and ideas" as "authors" are actually prohibited from our content by policy, at WP:NOR and WP:NOT#ORIGINAL and WP:OWN and the meta-policy WP:5P. I'm not sure I should continue engaging with you at all after this. You've not understand or addressed, just sidesteped or ignored, every single substantive point I have made, and every time you propound your supposed understanding of Wikipedia and its workings you are demonstrably flat-out wrong.

But I'll answer the second part, and then move on. Of course your claim about "the only time" the template is used it's by handful of individuals is nonsense. You seem to be making it clear that your actual purpose here is attacking a group of editors you have a bone to pick with because of what they choose to work on (and I would wager it's rooted in previous conflicts about style trivia in which you didn't get what you wanted). Let's return to reality again: The vast majority of all MoS points, and points in other guidelines, and all templates that involve them, are applied after-the-fact by later editors (either more experienced ones who do it kind of automatically as they go, or cleanup-focused editors who are more programmatic about it, and sometimes by bots when it's something a bot can do reliably). That does nothing to magically invalidate anything in the MoS or any other guideline, and certainly doesn't call into question particular line-items you personally have a bugbear about. It's entirely normal for any fine-point item (especially with nerdy techical matter behind it, like CSS classes and WP:SELFREF compliance) to be found more often (most especially in newer articles, lower-quality articles, and obscure-topic ones) without the prescribed markup than with it, unless and until someone has taken the time to do mass cleanup, e.g. with AWB. This is obviously and predictably because most editors are short term and do not read the MoS or other guidelines at all, except maybe in small part when looking for an answer to a specific question. Even our long-term editors make no effort to memorise the whole our guidance, just that which regularly affects them. It is entirely expected, by everyone, and is clearly a matter of policy (WP:EDITING) that editors do not have to read and comply with most guidelines, much less style ones, to contribute here, and that any guideline deficiencies in their material will be cleaned up later, probably by someone else. The only time one would be called to task for something connected to style is if one appeared to be writing with a servere inability to communicate (WP:COMPETENCE); or employing apparently intentional disregard for even the basics of English writing just to waste others' time (WP:NOTHERE, WP:TROLL, WP:VANDAL); or activistically thwarting others' editing to bring the material into guideline compliance (WP:DE, WP:TE, WP:NOTHERE). There is no MoS rule one must learn and abide by to edit here, and most editors ignoring a large number of them is not and never will be evidence against them (or one in particular) as consensus best practices to implement as clean-up. That's how the entire project works and has always worked. And, as usual (at least in your material here so far) you evince no understanding of this at all, despite having an account about the same age as mine. I find this rather troubling, and I really can't see it being productive to continue with you on this subject any further.
 — SMcCandlish ☏ ¢ 😼  11:54, 30 August 2026 (UTC)Reply

The vast majority of all MoS points, and points in other guidelines, and all templates that involve them, are applied after-the-fact by later editors

This is so profoundly incorrect that it's hard to believe someone who has spent any time here can make a claim like this. The "vast majority" of manual of style sections are typically followed as a matter of course by most authors and editors, violated only by accident, and either done correctly up front or changed by any ordinary reader or author when they are recognized as being in error, which typically happens organically sooner or later, even if nobody bothers to run the page through a MOS-basher bot. Some of them are ordinary rules of idiomatic professional English, while others are points where many editors recognized a point of common confusion or controversy and discussed together to settle on a consensus choice, because alternatives were either incorrect or causing a clear problem (sometimes just edit wars). A few – such as wikipedia's use of "straight" rather than “curly” apostrophes and quotation marks – are enforced incorrectness which persist out of historical inertia based on practical considerations from 2 decades ago.
If you can think of any other MoS entries which express something other than common practice by Wikipedians, where a single person added their preference to the MoS without discussion, and where alternative styles remain common throughout the encyclopedia, please list them, and we should discuss removing or changing them to conform to editor consensus. –jacobolus (t) 15:21, 30 August 2026 (UTC)Reply
The point of the text of Wikipedia articles is to communicate the author's thoughts and ideas to the readers. I think you misspelled the word "author's". The point of WP articles is to communicate the thoughts and ideas of authors (specifically plural) to readers. It is collaborative, 2nd only to factualness / provability. Some authors are subject-matter experts (or at least subject-matter capable). Others are better at copyediting focusing on refining specific tone, wording, and style (i.e., MOS) to articles. As a complete resource, WP is no longer a collection of individual articles with vastly differing styles and tones; as each article matures, the authors and editors must balance the need for subject-specific tone, and the fact that each article is but a part of a massive encyclopedia. The arrow of each article's quality and style is towards contributing to an encyclopedic tone that can only come about with a MOS that guides the very many, very fine, editorial decisions.
The only time [...] style appears in articles is when some "gnome" editor, trying to strictly enforce every sentence of the MOS, comes to wrap everything in unnecessary and ugly templates. Again, your wording and use of scare-quotes belies (IMO) a disdain of the editorial process that only seems to favor your style. WP is not a collection of personal wikis; it is not Medium.com; it is a project that aims to document the world's knowledge in an encyclopedic manner. I cannot think of a single successful encyclopedia that doesn't arc its editing towards in-house specific house rules, even ones that allow for a variation in styles in many places.  — sbb (talk) 20:04, 25 September 2026 (UTC)Reply
Yes, and those house rules are established by a team of professional typographical experts, rather than by single random amateurs. They follow the established principles / best practices of professional typography, rather than completely discarding/disregarding them. –jacobolus (t) 20:13, 25 September 2026 (UTC)Reply
I don't understand your point. Nobody is suggesting single random amateurs set house rules, nor advocating anybody completely discard[]/disregard[] them.  — sbb (talk) 22:40, 30 September 2026 (UTC)Reply
This particular "house rule" was invented by one random amateur, based on no expertise and no research, with no discussion or consultation with anyone, and certainly no consensus of Wikipedians.
It completely ignores both the standard conventions for solving this specific problem and also the more general established principles of professional typography. –jacobolus (t) 22:43, 30 September 2026 (UTC)Reply
And yet nobody else seems to be upset about it. Nor does this discussion seem to be going anywhere after two months. pburka (talk) 23:07, 30 September 2026 (UTC)Reply
Most people don't care much about typography at all, which is fine: they shouldn't have to.
What this discussion has demonstrated is that there is still no consensus for including this bad advice in the Manual of Style, which should never have been added in the first place. It should be removed on the grounds that the MOS is supposed to reflect the established consensus and common practices of Wikipedia editors, which this section does not.
If it were removed or rewritten to reflect better typographic practices nobody beyond the one guy who made it up and maybe a couple of other people would care at all, and the result would be fewer pointless edits trying to force this bad style around the encyclopedia –jacobolus (t) 23:34, 30 September 2026 (UTC)Reply
You throw around phrases like "one random amateur", "no expertise" and "no research" as pejoratives. And in the specific person you're referring to, they have quoted and cited many manuals of house styles (CMOS, APA, etc.) many, many times. To say they have "no expertise" and "no research" is casting aspersions by gish-galloping. It's one thing to do that in a debate or argument about a subject; it's quite another when doing it about a person. It's very unprofessional. There's no need to do that. Please, don't.  — sbb (talk) 23:50, 30 September 2026 (UTC)Reply
Sorry, are you saying because this person has, in unrelated other discussions, quoted some academic style guides "many times", that makes them a professional typographer or typographic expert? –jacobolus (t) 00:06, 1 October 2026 (UTC)Reply
My intention is not to insult anyone, so I apologize if it seems that way. Most people are not typographical experts, and there's nothing wrong with that.
My point is just that we shouldn't take one single Wikipedian's idiosyncratic personal preferences, just because they took the initiative to edit the manual of style at some point in the past, and require that all Wikipedia articles must follow those. That's both a broken process and leads to stylistically bad results. Instead, we should base our manual of style on (a) demonstrated typographical practices of established professional reference works, which are not hard to determine by direct examination, (b) basic principles of effective typography (for example, the principle that typographical special effects should typically be limited to one at a time, enough to indicate contrast without being distracting, and the principle that the parentheses characters should not themselves be italicized unless perhaps they are directly part of an italicized passage), and (c) the consensus and prevailing choices made by Wikipedians. –jacobolus (t) 00:20, 1 October 2026 (UTC)Reply
Strong objection. WP is a quite mature product, compared to other encyclpedias out there. WP should begin the process of consolidating on a house style, IMO.  — sbb (talk) 18:36, 23 September 2026 (UTC)Reply

Bot task to remove erroneously italicized commas

[edit]
Latest comment: 29 days ago42 comments16 people in discussion

I recently proposed a bot task for fixing approximately 82,000 instances on Wikipedia of commas being erroneously italicized after italicized terms (see, for instance, the comma after Pulse Weekly here; additional details are at the BRFA). One editor objected that the task is too minor to be worth doing by bot, so a BAG suggested I inquire here about whether or not there is consensus to proceed. Do you all consider this an error that'd be worth fixing by bot? Sdkb talk 06:01, 13 April 2026 (UTC)Reply

By itself, seems like a pretty insignificant change. Nikkimaria (talk) 04:03, 14 April 2026 (UTC)Reply
Because it's an AWB bot, it can be run alongside the general fixes set, so often the comma fix will not be the only change the bot makes.
My overall view is that, while it's certainly not the most earth-shattering change to a page, it is an improvement, and it's clearly in compliance with WP:COSMETICBOT because it changes the output HTML of the page. It is something that I occasionally notice as a reader. I'd like to get further input to establish a consensus about whether we can proceed. Cheers, Sdkb talk 01:11, 11 June 2026 (UTC)Reply
Notified: Wikipedia talk:Manual of Style/Text formatting. Sdkb talk 01:13, 11 June 2026 (UTC)Reply
It's worth fixing these. I fix them manually when I'm cleaning up other formatting errors at the same time. pburka (talk) 23:05, 21 June 2026 (UTC)Reply
Would it distinguish between name-internal commas (The good, the bad, and the ugly) and commas that should be romanised? Tony (talk) 23:14, 21 June 2026 (UTC)Reply
@Tony1, because it's only looking at commas at the end of an italicized phrase, it will properly handle name-internal commas like in your example. Sdkb talk 03:23, 23 June 2026 (UTC)Reply
Nice. Tony (talk) 04:44, 23 June 2026 (UTC)Reply
... unless it's erroneously formatted as ''The good,'' ''the bad,'' ''and the ugly'', I suppose. Unfortunately, I have seen this kind of markup fairly frequently, possibly as a result of visual editor use. pburka (talk) 01:16, 24 June 2026 (UTC)Reply
That should be fixable by a bot, possibly another one. Gawaon (talk) 03:06, 24 June 2026 (UTC)Reply
Although I understand the logic behind using italics in this way, I do consider this bot task to be questionable. A straight comma immediately following italicised letters creates a visual imbalance between the characters, which is why professional typesetters often set punctuation marks in italics in such cases, precisely to avoid this. Numerus (talk) 23:15, 23 June 2026 (UTC)Reply
As a former professional copy editor myself, I have not encountered an argument before that italicizing the comma in this situation would be grammatically correct. Chicago advises making it non-italicized, as does APA. Sdkb talk 05:12, 24 June 2026 (UTC)Reply
As I remember it, until their 15th or 16th edition the CMOS recommended italicizing commas in this case. In recent editions they have reversed that recommendation, now considering abstract logical correctness more important than typographical niceness. Grammar has nothing to do with it in any case. Gawaon (talk) 08:41, 24 June 2026 (UTC)Reply
There can't be any question of it being grammatically incorrect. It can be argued to be typographically incorrect, but that's a matter of style. Erik Spiekermann has a lot to say about typography, but I don't see anything about italicizing punctuation in his best-known book. WhatamIdoing (talk) 02:55, 3 September 2026 (UTC)Reply
I've only just seen this discussion. I objected to doing this as a standalone bot task in the initial proposal, and I still object to that now. I have no objection to it becoming part of AWB's fixes or some other task that makes some substantial change at the same time but on it's own it's far too minor to be clogging up watchlists, page histories, etc. Thryduulf (talk) 21:13, 10 July 2026 (UTC)Reply
Yes this would be a great bot! I always fix those manually as well. However, it should also fix instances of multiple italics separated by a non-italicised space, such as ''The good,'' ''the bad,'' ''and the ugly'' as suggested above. (This is especially common when using the VE.) Otherwise it might sometimes make the problem worse, not better. FaviFake (talk) 10:01, 11 July 2026 (UTC)Reply
Bumping thread. Per this comment. FaviFake (talk) 12:05, 2 September 2026 (UTC)Reply
Would that bot be good enough to correct ''The New York Times,'' ''The Guardian'' ''and The Daily Telegraph'', or make it worse? (contrived example, I know) — Preceding unsigned comment added by NebY (talk • contribs)
In that example, it would fix the erroneous italicized comma (but wouldn't do anything on the erroneously italicized "and", which is a separate error). Sdkb talk 16:41, 2 September 2026 (UTC)Reply
Contrived, but a good point. I don't see how the bot could distinguish these two cases:
  • ''The good,'' ''the bad,'' ''and the ugly'' should be changed to ''The good, the bad, and the ugly''
  • ''The New York Times,'' ''The Guardian'' ''and The Daily Telegraph'' should be changed to ''The New York Times'', ''The Guardian'' and ''The Daily Telegraph''
Whatever the bot is programmed to do in such a case, one of these will be made worse. Maybe the bot should simply stay away from such cases and leave them to us humans. Or maybe tag them with an HTML comment or something. — Chrisahn (talk) 17:02, 2 September 2026 (UTC)Reply
The second example wouldn't be made worse: just a different kind of wrong. pburka (talk) 17:06, 2 September 2026 (UTC)Reply
We could certainly exclude the 6,600 instances where another italicized term directly follows if we are concerned about the good-bad-ugly potential error. FaviFake and I reviewed around 200 examples of those instances, though, and did not find the error to exist in practice, so my mild preference would be not to make that exclusion. Sdkb talk 17:11, 2 September 2026 (UTC)Reply
Sounds good. The good-bad-ugly case seems to be rare, so we could program the bot like this:
  • ''The New York Times,'' ''The Guardian'' ''and The Daily Telegraph'' is changed to ''The New York Times'', ''The Guardian'' and ''The Daily Telegraph''. Nice.
  • ''The good,'' ''the bad,'' ''and the ugly'' is changed to ''The good'', ''the bad'', and ''the ugly''. Not great, but acceptable, since it's going to happen rarely.
— Chrisahn (talk) 17:28, 2 September 2026 (UTC)Reply
Oops. I just realized that so far we've only talked about a bot that handles commas, not "and". So I guess the bot would do this:
  • ''The New York Times,'' ''The Guardian'' ''and The Daily Telegraph'' is changed to ''The New York Times'', ''The Guardian'' ''and The Daily Telegraph''. The "and" is still erroneously italicized.
  • ''The good,'' ''the bad,'' ''and the ugly'' is changed to ''The good'', ''the bad'', ''and the ugly''. Still wrong, but rare.
Or should we let the bot also change ''and Foo'' to and ''Foo''? Somewhat extends the topic of this discussion... — Chrisahn (talk) 17:34, 2 September 2026 (UTC)Reply
No, we probably shouldn't do that "and" thing. A search for ''and brings up lots of stuff that looks sketchy but probably can't be fixed by a simple rule: — Chrisahn (talk) 17:40, 2 September 2026 (UTC)Reply
I hadn't seen that search before, and I agree that the false positive rate is very low. I support the bot task. pburka (talk) 17:39, 2 September 2026 (UTC)Reply
(edit conflict)Yes, but I was thinking of the extra task FaviFake and previously Gawaon proposed, to "fix instances of multiple italics separated by a non-italicised space". NebY (talk) 17:05, 2 September 2026 (UTC)Reply
I wouldn't want to see this change as the only modification made in an edit. Technically it's not a cosmetic change, but I'd prefer to see this only happen if at least one clearly non-cosmetic change is also being made. Mike Christie (talk - contribs - library) 13:11, 2 September 2026 (UTC)Reply
That's my feeling too. If we can filter out enough false positives, let's add something like (\w),''(?! *') → $1'', (with a few more checks) to WP:AWB/T. Certes (talk) 14:17, 2 September 2026 (UTC)Reply
While we're in there, we could also change good,'' ''the to good, the if it's not already being done. The required hieroglyphs are something like ([^'])''(\s+)''(?!') → $1$2. Certes (talk) 14:29, 2 September 2026 (UTC)Reply
I think you're talking about italicized strings consisting only of whitespace. Is that right? pburka (talk) 14:37, 2 September 2026 (UTC)Reply
I think they're actually talking about combining consecutive italicised strings separated only by whitespace, e.g. ''Lastname,'' ''Firstname'' → ''Lastname, Firstname'', although I'm unsure why the comma is relevant in such cases? Thryduulf (talk) 14:59, 2 September 2026 (UTC)Reply
And I'm not sure that an intervening comma can be handled by a bot. Compare:
  • "Milton's most famous works were Paradise Lost, Paradise Regained, and "When I Consider How My Light is Spent"." The first two are separate works, so the comma should not be italicized.
  • "Her famous book, Eats, Shoots & Leaves, was about the importance of correct comma placement."
I'd suggest only attempting this when the following text is not italicized. WhatamIdoing (talk) 03:04, 3 September 2026 (UTC)Reply
Notified: Wikipedia:Village pump (proposals). Thryduulf (talk) 13:19, 2 September 2026 (UTC)Reply
Since this has now been shared to VPR, I'll give a quick summary of where we're at for anyone joining in. There are more than 100,000 instances on Wikipedia of the style error in which a comma is erroneously italicized after an italicized term, e.g. per ''Foobar Times,'' blah blah blah. You can use this search query (it may take a minute to load) to see a bunch of them.
This is admittedly a small error, but it's one that myself and other pickier readers and editors notice, so I contend that it's worth fixing. I've created a bot that can do so while also fixing any other errors an article has that are part of the general fixes set. Myself and others have at this point reviewed/tested hundreds of edits it would make and have found it to work successfully.
The question for this discussion is whether this task abides by WP:COSMETICBOT, which establishes a distinction between cosmetic and substantive edits and states that cosmetic edits should not usually be done on their own. Per the bot dictionary, A cosmetic edit is one that doesn't change the output HTML or readable text of a page. By contrast, a substantive edit is one that does change the output HTML or readable text of a page. I contend that this task is a small but substantive edit, because it changes the readable text of the page. @Thryduulf has argued that we should be interpreting "cosmetic" more expansively to mean any minor edit, and that this change is far too minor to be clogging up watchlists, page histories, etc. My view is that changes to the cosmetic bot policy should be proposed to the policy, not applied ad hoc to specific tasks. I also would oppose a change loosening the definition of a cosmetic edit. I do not find the watchlist cluttering argument persuasive, since, as @Tenshi Hinanawi has noted, bots can be hidden from watchlists and WP:HIDEBOT can be used to hide specific bots. Fundamentally, small improvements for readers are still improvements, so we should make them rather than leaving in errors just so that editors won't have as many edits on their watchlist.
Cheers, Sdkb talk 17:46, 2 September 2026 (UTC)Reply
This seems borderline. I would prefer this to be rolled into larger edits, as others have opined above. CMD (talk) 00:24, 3 September 2026 (UTC)Reply
I think it's an acceptable task, but I think it needs to be done conservatively. WhatamIdoing (talk) 03:05, 3 September 2026 (UTC)Reply
As somebody who is probably responsible for half of the flawed italic punctuations, yes, please let a bot clean up after this. GreenLipstickLesbian💌🧸 06:06, 3 September 2026 (UTC)Reply
I agree. This is objectively not a cosmetic edit and it should be done by a bot. Policy changes can be discussed at the policy's talk page. FaviFake (talk) 06:49, 3 September 2026 (UTC)Reply
Such a minuscule change in appearance would rightly be called cosmetic in any other context but Wikipedia's peculiar "invisible to the public" usage when discussing bots, and it will be entirely reasonable for general editors to describe it that way and worse if they find it cluttering their watchlists and demanding their attention - and if it's run on 100,000 instances, that'll be a lot of editors. Likewise, it's only "substantive" within the peculiar usage of WP:COSMETICBOT; it doesn't make any sort of semantic change or even as much as change one character for another. It shouldn't be done on its own, even if it abides by COSMETICBOT. NebY (talk) 16:07, 3 September 2026 (UTC)Reply
There has also been some (minor) objections on the basis that not everyone agrees that this is or ought to be considered an error in the first place. Numerus argued that professional typesetters italicize such commas, and Gawaon said that CMOS recommended italicizing them until their 15th or 16th edition. I agree with Gawaon's characterisation of the two styles: "abstract logical correctness" vs "visual niceness". This discussion has mostly proceeded on the assumption that italicization in these cases are unquestionably incorrect, when it appears there are differing views on this mattet. So I would ask: is this something we need to decide one way or the other, or do we allow stylistic variation? HierophantOfOmens (talk) 20:44, 3 September 2026 (UTC)Reply
The current edition of the CMOS and APA both explicitly advise not italicizing the comma in that instance. We don't have a link to the former edition that Gawaon recalls advising something different, nor a link to any other major professional style guide advising something different. So I think it's fairly clear that the consensus among professional style editors is to not italicize the comma. Sdkb talk 22:35, 3 September 2026 (UTC)Reply
I also pointed out that CMOS has since changed its recommendation. I tend to agree that the logical placement makes sense and that bot edits fixing this would therefore be an improvement. I agree with NebY, however, that these edits are clearly cosmetic in substance, even if not literally so – ordinary readers won't notice a change. I wouldn't consider that an urgent argument against the bot task, but it is worth bearing in mind. If this cleanup task could be combined with other bot cleanups that are running anyway, that would probably be the better solution to avoid watchlist clutter. Gawaon (talk) 04:18, 4 September 2026 (UTC)Reply

Lists

[edit]
Latest comment: 18 days ago4 comments4 people in discussion

So I was checking out MOS:LIST, and had a question. Is there some barometer for an individual's achievements when making a list? Specifically this list has a lot of awards that feel like they may not be encyclopedia worthy? There's a lot that are referenced by youtube videos or press releases and I have not found any coverage in RS's mentioning them. GhostOfMuir (talk) 06:04, 3 September 2026 (UTC)Reply

The usual sourcing requirements apply to lists. Any entries not supported by reliable sources can be marked "citation needed" or simply deleted. Also, lack of relevance can be a reason for deletion even if an entry is sourced. Gawaon (talk) 09:25, 3 September 2026 (UTC)Reply
These are all very obscure awards. Of course the subject is also a controversial topic. You could remove them as insignificant, but you may encounter pushback. An alternative would be to provide context for the awards (e.g., the important-sounding "Freedom Award" would be more informative as the "Riverton Mayor's Freedom Award, awarded by the mayor of Riverton, Utah, in 2023"). (This is general advice, as this isn't really a MOS issue.) pburka (talk) 21:07, 6 September 2026 (UTC)Reply
When answering conflict of interest requests, I generally look for at least one of (1) the award itself is notable (e.g. has a Wikipedia article) or (2) that individual receiving that award has receivied nontrivial independent coverage (e.g. not by either the individual themselves or by the awarding organization). For (1) obviously we would also require a source, but I would accept one not independent of the award, like the award's own list of honorees. I don't think this is formally codified in policy anywhere but it's the standard a lot of reviewers use. Rusalkii (talk) 22:26, 15 September 2026 (UTC)Reply

Slash in a song title

[edit]
Latest comment: 12 days ago12 comments7 people in discussion

Hey folks. Should a slash in a song title be spaced or unspaced? I'm seeing it both ways -- for example, "Gone, Gone / Thank You" (spaced) and "Hard Feelings/Loveless" (unspaced). I'm looking at MOS:SLASH but it doesn't seem to address this question. I personally prefer spaced, but is there a MOS guideline for this? — Mudwater (Talk) 02:01, 5 September 2026 (UTC)Reply

I'm not convinced that there should be a uniform rule for this. There is at least one song titled "20/20" for which unspaced is the only reasonable option, for instance, and I'm sure there are songs for which spaced is preferable. —David Eppstein (talk) 02:12, 5 September 2026 (UTC)Reply
The general convention is no spacing when a slash coordinates single words, letters, symbols, etc. (thus, "20/20", "A Better Son/Daughter") and spacing when material on one or either side contains a space, hyphen, etc. (thus, "Gone, Gone / Thank You", "Hard Feelings / Loveless"). That is:
"A Better Son/Daughter" = "A Better Son or a Better Daughter"
"A Better Son / Daughter" = "A Better Son or (a) Daughter"
"Hard Feelings / Loveless" = "Hard Feelings or Loveless"
"Hard Feelings/Loveless" = "Hard Feelings or Hard Loveless" —Doremo (talk) 03:14, 5 September 2026 (UTC)Reply
Yes, that's the general convention and I think it would make sense to follow it when rendering song titles, just as we apply other standards to do with capitalization and so on. Popcornfud (talk) 03:56, 5 September 2026 (UTC)Reply
An exception to the "no spacing when a slash coordinates single words" might be to use spacing when a track is a mashup or segue between two one-word song titles. There are several of these listed at List of mashup songs, most currently spaced but at least one not. —David Eppstein (talk) 06:44, 5 September 2026 (UTC)Reply

Thanks, everybody. — Mudwater (Talk) 20:38, 6 September 2026 (UTC)Reply

There is a relevant discussion at Talk:Mount Cook Village#Requested move 31 August 2026. The mention of using a spaced slash when the slash separates multi-word expressions was removed relatively recently – at 22:19, 16 November 2025 (UTC). —⁠ ⁠BarrelProof (talk) 19:40, 8 September 2026 (UTC)Reply
That seems a bit unfortunate. Apparently, during the discussion that led to that outcome, nobody thought about the "alternative titles" use case discussed here. Gawaon (talk) 02:02, 9 September 2026 (UTC)Reply
Nobody in that discussion was discussing the use of spaced slashes at all - and while that bullet point would indeed have covered the use case discussed in this thread, it was, admittedly, not a well-worded bullet point. Particularly the last part ("if for some reason the use of a slash cannot be avoided") was what agitated everyone over it (understandably so)

I don't think it would be contrary to that discussion to add a bullet point about spaced slashes and when they should be used instead of unspaced slashes, i.e., alternative titles, as has been said - and I will note another use wrt to song titles, that is, for "two-in-one" songs (e.g. "Aquarius" / "Let the Sunshine In"). The focus of that discussion was the language "if for some reason the use of a slash cannot be avoided." That language should stay removed, but if there's general agreement about the other things discussed here, I support that addition. HierophantOfOmens (talk) 12:36, 9 September 2026 (UTC)Reply
I agree. Gawaon (talk) 14:56, 9 September 2026 (UTC)Reply
I also agree. And WP:NZNC#Convention for dual names also agrees (at least nearly always, since one or the other of the New Zealand place names nearly always includes a space). —⁠ ⁠BarrelProof (talk) 16:19, 9 September 2026 (UTC)Reply
Please see this edit. —⁠ ⁠BarrelProof (talk) 00:13, 22 September 2026 (UTC)Reply

Discussion at Wikipedia talk:Manual of Style/titles hatnote include § Inappropriate nagging

[edit]
Latest comment: 22 days ago1 comment1 person in discussion

 You are invited to join the discussion at Wikipedia talk:Manual of Style/titles hatnote include § Inappropriate nagging. FaviFake (talk) 08:23, 11 September 2026 (UTC)Reply

Discussion at Wikipedia talk:Manual of Style/Linking § How to describe something as both a "black comedy" and a "comedy drama"?

[edit]
Latest comment: 19 days ago2 comments1 person in discussion

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Linking § How to describe something as both a "black comedy" and a "comedy drama"?. —Myceteae🍄‍🟫 (talk) 14:17, 14 September 2026 (UTC)Reply

This discussion concerns the intersection of and discrepancies between several MOS subpages. —Myceteae🍄‍🟫 (talk) 14:24, 14 September 2026 (UTC)Reply

Discussion at Wikipedia talk:Manual of Style/Accessibility/Alternative text for images § Straw poll on the quality of MOS:ALT

[edit]
Latest comment: 15 days ago1 comment1 person in discussion

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Accessibility/Alternative text for images § Straw poll on the quality of MOS:ALT. Guy Macon (talk) 21:56, 18 September 2026 (UTC)Reply

Supplement to the MoS for the British honours system

[edit]
Latest comment: 9 days ago1 comment1 person in discussion

As part of my work as Wikimedian in Residence at The Gazette, I have drafted a supplement to the MOS, for the British honours system. I am grateful for advice I have received from colleagues at The Gazette.

The intention, after discussion, is to have it adopted as part of the MoS.

Please see Wikipedia:GLAM/The Gazette/MoS and comment in its talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 10:49, 24 September 2026 (UTC)Reply

Discussion at Talk:Capitalization of Internet § Requested move 15 September 2026

[edit]
Latest comment: 8 days ago1 comment1 person in discussion

 You are invited to join the discussion at Talk:Capitalization of Internet § Requested move 15 September 2026. Notifying here because this RM also covers the primary usage at the Internet article, and if the term is lowercased there, editors in other articles may decide to adopt that usage. Sdkb talk 17:52, 25 September 2026 (UTC)Reply

[edit]
Latest comment: 1 day ago37 comments7 people in discussion

The last paragraph of MOS:HEADINGS, § Heading-like material, states,

Aside from sentence case in glossaries, the heading advice also applies to the term entries in description lists.

Specifically, I'm asking about links in wikitext semicolon–colon description lists. My reading of the quoted text, and the entire HEADINGS section, leads me to interpret it that basically anything that looks like a heading in prose text (that is, ignoring table headers) should not have links in the so-called 'heading' text; the link should be moved to a hatnote, or simply inlined in the description definition text if possible.

For instance, the {{glossary}}-structured {{term}} documentation states,

For the same reasons that links to other pages are discouraged in headings, links are discouraged in glossary terms

(comment: of course, I realize that a template's documentation is not specifically normative, nor do they impute external requirements upon MOS; rather, assuming there is no contradiction, the documentation of templates merely echoes, re-states, or implements MOS. I'm quoting {{term}}'s documentation on that basis, assumption, and reading alone).

Is there a way we can get clearer directive on this? Should I open an RfC to tweak the MOS's text in the lat paragraph to specifically state the interpretation that links should not be in the term-portion of ;:-delimited lists?  — sbb (talk) 20:22, 25 September 2026 (UTC)Reply

This would be so much clearer with a concrete example. I'm guessing that might be the linking of Triangular, Square and Pentagonal in the list at Platonic solid as in this version, which you've been disputing in edit summaries with David Eppstein - is that right? Have you run into this matter in other articles? NebY (talk) 21:00, 25 September 2026 (UTC)Reply
In MOS:HEADING the prohibition on links in section headings is purely for "technical reasons", not made more specific, but one of these technical reasons is that section headings become part of tables of contents and wikilinks do not work well in that context. Another technical reason might be that there is an html id created from the section heading and we do not want wikilinks to interfere with that. For {{term}}, also, the same technical reason applies: the argument to term is used to create an html id.
However, for pure definition lists, none of these technical reasons applies. Definition lists are not part of the table of contents. The terms of a definition list (the part after a ":" and before the ";" that separates it from the definition) are converted into html <dt> ... </dt> without any id. There is no technical obstacle to including links. So if it is only for technical reasons that we prohibit links in section headings, and separately in arguments to {{term}} in glossary articles, that prohibition is invalid for definition lists used as definition lists in other kinds of articles. It has no reason to be there other than a foolish consistency. —David Eppstein (talk) 23:25, 25 September 2026 (UTC)Reply
Did you mean to write:
The terms of a definition list (the part after a ";" and before the ":" that separates it from the definition)
;term:definition →
term
definition
—Trappist the monk (talk) 23:34, 25 September 2026 (UTC)Reply
Yes. Strike that, reverse it. —David Eppstein (talk) 23:48, 25 September 2026 (UTC)Reply
Yes, links everywhere other than in headings should be fine. Gawaon (talk) 03:56, 26 September 2026 (UTC)Reply
For clarification, do the terms of description lists count as 'headings' in your opinion? Visually speaking, being bolded and on their own line, they definitely serve a function similar to headings.  — sbb (talk) 06:19, 26 September 2026 (UTC)Reply
No. Gawaon (talk) 09:06, 26 September 2026 (UTC)Reply
You are correct, this Differences between links in dt/;term vs. without at Platonic solid is what's motivating this question for clarification. But it's not the only case; there are other cases in other articles that I would change (assuming my understanding of this on changing (but I'm holding off pending clarification in this discussion).
The point of my interpretation is that headings (and heading-like material, such as <dt> in description lists, or {{term}} in {{glossary}}-structured lists, is that headings are anchor or link destinations, not jupming-off points. I think it's stylistically poor to highlight a term, heading, or pseudo-heading, just to link people away from it before the prose defining or describing the term is even stated or read.
For a larger example, compare the Glossary of cue sports terms with the Glossary of nautical terms (M-Z); the latter having a mish-mash of {{term}}s that are links and ones that aren't.
Another example, much more similar to the one in Platonic solid that sparked this, is the "monogon/digon" description list near the top of Regular polygon § Regular convex polygons. That is an example of heading-like material that is partially linked (partial links in headings are prohibited in MOS:HEADINGS). Again, the point is that headings, and heading-like material, are certainly visually anchor destinations (from a reading perspective).  — sbb (talk) 07:21, 26 September 2026 (UTC)Reply
Description lists can be glossaries that you might want to link to the entries of, but they can also not be those things. Indeed, as designed in html and as implemented when using ;: syntax in Wikipedia, you cannot link to them; they did not initially have anchors, ;:-syntax does not give them anchors, and the ability to add anchors to any tag in html is a much later addition than dl/dt/dd. When they are not things that you want to link to the entries of, it is a foolish consistency to insist that they must follow rules intended only for linking to them.
It would not be the first time you have taken some minor technical workaround intended for a very narrow situation and blown it far out of proportion into some general rule; see Wikipedia talk:WikiProject Mathematics/Archive/2026/Sep § Should the LaTeX space in integrals be changed from '\,' to '\mathop{}\!' site-wide? —David Eppstein (talk) 07:31, 26 September 2026 (UTC)Reply
it is a foolish consistency to insist that they must follow rules intended only for linking to them. In every interaction with me that you have initiated in the last 2 weeks, you have used insulting or condescending language. Please don't cast aspersions on other editors' mentalities.
as designed in html and as implemented when using ;: syntax in Wikipedia, you cannot link to them; they did not initially have anchors, ;:-syntax does not give them anchors I don't understand your appeal to originalism in HTML. We're not beholden to the limitations of HTML 1.0. WP has moved to HTML 5. And as far a as linking to ;: syntax, that's what {{anchor}} and {{vanchor}} are for.
It would not be the first time you have taken some.... Completely non-sequitur. You are attacking me or attempting to discredit my efforts to edit by making ad hominem and condescending attacks at me. Cease it. That's not a request. I'm sure you have been wrong in the past; and even if you haven't, your opinion and preference has been overruled by consensus, and you were likely not treated the way you have treated me. And if you were treated that way, it wasn't by me. So stop it.  — sbb (talk) 08:12, 26 September 2026 (UTC)Reply
the ability to add anchors to any tag in html is a much later addition than dl/dt/dd Prior to HTML 4.0, link destinations within a page had to be to an <a name="target">...</a> element; the only way of making a heading become the target of such a link was to put the a element inside the <h2>...</h2> tags, as with the second example at HTML 3.2 spec: The A (anchor) element: 
<h2><a name=mit>545 Tech Square - Hacker's Paradise</a></h2>
HTML 4.0 added the id= attribute to all HTML tags, without exception, and at the same time permitted such tags to be used as the target anchor for hypertext links. This means that HTML like <h2 id=mit>545 Tech Square - Hacker's Paradise</h2> became a simpler way of writing the above example, but moreover, meant that you could also write a valid definition list where every term can be linked to without adding a elements to every term: 
<dl id-Glossary-A>
  <dt id=Abcdise>Abcdise<dd>Shorthand for "alphabetize"; a term sometimes used in ...
  <dt id=Accessibility>[[WP:Accessibility|Accessibility]]<dd>The art of making it possible for everyone ...
  <dt id=Actionable>Actionable<dd>In [[WP:Featured content|featured content]] promotion discussions, all objections to ...
  <dt id=Admin>Admin<dd>Short for ''[[WP:Administrators|administrator]]''. A user with extra technical ...
</dl>
and that's without <dfn>...</dfn> elements. There's nothing special about headings as link targets; HTML has always provided the means for a link target to be placed anywhere in a page, it's just that the id= attribute makes it easier. --Redrose64 🌹 (talk) 10:32, 26 September 2026 (UTC)Reply
Thank you for the examples. I did find the mixing of linked and unlinked text in the same terms in Platonic Solid jarring without considering whether or not any technical issues arise, but Glossary of nautical terms (M–Z) demonstrates nicely how well linking terms works; it's clear, helpful to readers, and avoids awkwardly repeating the term in the description just to link it (or hiding the target in a piped link). It's a mild stylistic variation of similar good presentation at List of Roman deities#Alphabetical list; we shouldn't try to rule it out or remove it. Those examples also demonstrate how qualitatively different the terms are from the functional section headings that shouldn't be linked, and how wrong it would be to extrapolate from the guidance on those. NebY (talk) 10:00, 26 September 2026 (UTC)Reply
I disagree with your conclusion regarding Glossary of nautical terms (M–Z); I think it contrasts well with the List of Roman deities § Alphabetical list. The Roman deities is essentially a list-style glossary with sentence fragments, and neither a hatnote-per-term, nor a re-statement of the link term in the body of every list item (rather than the "term heading" because of utter redundancy), would be appropriate. Once the "body" or description/definition of a term can reasonably accommodate an outlink, IMO that's where it should go, rather than in the term "heading".  — sbb (talk) 19:17, 26 September 2026 (UTC)Reply
In Glossary of nautical terms (M–Z), it would be tedious and unhelpful to have
mack
A mack is a structure which ....
man overboard
1.  "Man overboard" is an emergency call that ...
2.  A man overboard is a person who has fallen into the water ...
and so on and on. I hope that's not what you're suggesting. NebY (talk) 21:02, 26 September 2026 (UTC)Reply
I'm suggesting providing a {{glossary hatnote}} saying "Main article: man overboard" if it exists, and otherwise following something like your 'mack' example. Quite simply, following the guidance of the {{glossary}}, {{term}}, etc. documentation, which exhorts authors to not put links in description list terms. For a consistent and well-done example, see Glossary of cue sports terms. I don't see why Glossary of nautical terms (M-Z) needs to have links in terms, but cuegloss can do it without needing link in terms.  — sbb (talk) 21:34, 27 September 2026 (UTC)Reply
A jumble of normal glossary or dictionary styling, hatnotes and full sentences would be messy, inconsistent and obtrusive. It's bad design and there's no reason our readers should have to put up with (or turn away from) a tedious and longwinded presentation that's worse than an ordinary print dictionary or glossary. NebY (talk) 09:06, 28 September 2026 (UTC)Reply
I'm not trying to be obtuse, and I sincerely want to know: do you think Glossary of cue sports terms is a jumble, is mess, inconsistent, and obtrusive? Do you think it is tedious and worse than Glossary of nautical terms (M-Z)? Specifically, I think the latter is presentationally worse, less encyclopedic, less polished.  — sbb (talk) 15:56, 28 September 2026 (UTC)Reply
Yes. NebY (talk) 18:25, 28 September 2026 (UTC)Reply
I agree with NebY here. Glossary of nautical terms (M–Z) is much more reader-friendly and better organized, while Glossary of cue sports terms would benefit from a serious overhaul. Gawaon (talk) 02:48, 29 September 2026 (UTC)Reply
'Once the "body" or description/definition of a term can reasonably accommodate an outlink, IMO that's where it should go' – but why? Gawaon (talk) 03:17, 27 September 2026 (UTC)Reply
Because at that point, the "heading" vs. "body text" distinction is apparent; there is enough meat in the definition that there's enough sentences to organically blue-link the term, or to substantiate a "Main article: xxxx" {{ghat}}note.
Headings and pseudo-headings already are in bold. Having many of them also blue-linked (or worse, partially blue-linked due to multiple definition terms) is ugly, and IMO not encyclopedic.
Let me ask a related counter-question that might be more illustrative: if there were no technical problems at all in the WP engine, so that any section heading could support having links in them, would it be okay to have links in headings moving forward? Is the only reason we don't currently allow links in headings is because there's some sort of technical restriction in the WP engine? I mean, if we really wanted to support links in headings, then it's not a difficult matter to change the MOS to require use of some {{heading}} template that will produce the necessary HTML markup, and deprecate use of wikitext heading markup. But the fact we don't tells me we're okay with not having links in headings as a stylistic restriction, and not purely and exclusively as a technical restriction.
So... considering that "no links in headings" is a stylistic restriction, it comes down to where is the distinction between headings, pseudo-headings, description list terms, and other heading-like material, regarding links?
IMO, NebY's example of List of Roman deities § Alphabetical list is a perfect counter-example, where links in the pseudo-heading / description term are perfectly fine; the list is all incomplete sentences; it would serve just as well if it were a table-based list like the List of Greek deities, where the column row headers contain links.
That's what my question is looking to explore, and provide clarification for.
Finally, and as alluded to in my original question: if there is no restriction on having links in pseudo-headings and description list terms, then if I were to make edits to {{glossary}}-structured lists to remove links in the description terms / {{term}}s, in accordance with guidance as specifically noted in those templates' documentation, and it becomes an editing dispute, what's the recourse? Is the statement in {{term}}'s documentation For the same reasons that links to other pages are discouraged in headings, links are discouraged in glossary terms, wrong? As long as that wording is there, would I be wrong to edit according to it?  — sbb (talk) 22:33, 27 September 2026 (UTC)Reply
The "no links in headings" thing is primarily for mobile users, who tap a heading to uncollapse (or collapse) a section. If tapping the heading actually took them elsewhere, that would (a) be confusing and (b) prevent access to the section content. --Redrose64 🌹 (talk) 22:55, 27 September 2026 (UTC)Reply
That makes sense. The mobile interface (at least on Android) does not collapse definition lists so that rationale again does not apply to definition lists. —David Eppstein (talk) 23:07, 27 September 2026 (UTC)Reply
There is nothing preventing somebody from creating a collapsible set of {{glossary}}-structured templates that relies on CSS flex box to collapse a glossary into a long multi-column list of terms that can be clicked on to open to see their definition, strictly for the intention of being mobile-friendly (to minimize long scrolling). If that were to be implemented, then links in those terms would be similarly unfriendly to mobile just as links in collapsing headings is mobile-unfriendly.
The point being, I think the rationale needs to move beyond both past-technical-limitation and presently-not-doing-it-that-way. This is a manual of style discussion, and opinions of "I don't prefer that style" are entirely sufficient when coming to consensus of overall stylistic direction. Just as a directive such as using title case vs. sentence case in headings is not about technical limitations or anything more objective than homologation one way or the other, this is similarly just a matter of style and consensus.  — sbb (talk) 03:25, 28 September 2026 (UTC)Reply
Re "opinions of "I don't prefer that style" are entirely sufficient when coming to consensus of overall stylistic direction": Well, no. This is false. We leave lots of matters of style to opinion, do not prescribe a specific style for them, and do forbid gratuitously changing from one style to another. Imposing style restrictions has a higher bar than that.
As for your hypotheticals about how we must impose technical restrictions because someone someday might possibly introduce a variant stylesheet that did something nonstandard, the less said the better. —David Eppstein (talk) 01:31, 30 September 2026 (UTC)Reply
Well, no. This is false. We leave lots of matters of style to opinion, do not prescribe a specific style for them, and do forbid gratuitously changing from one style to another. Imposing style restrictions has a higher bar than that. I'm talking about, when coming to a consensus for stylistic matters, "I prefer" and I don't prefer" whatever style is absolutely sufficient in order to state one's vote in an RfC (or even pre-RfC, when OP is just asking for clarification). IMO, plainly-stated preference is better than dubious or incorrect claims regarding technical capability. Honest preference does not need defending or justification. Claims based on technical capabilities or historicity require truth, and can waste others' research time if the claims are disproven or mistaken.
My hypothetical never claimed "we must impose technical restrictions". I merely suggested that such a collapsing glossary list would present the same benefits (condensing required space and minimizing lots of vertical scrolling) and drawbacks (need to have a safe space to click on the term to expand the definition) for mobile users that collapsing headings and sections currently present. Nowhere was an implied or stated "must"; that was incorrect of you to infer that.  — sbb (talk) 14:57, 30 September 2026 (UTC)Reply
It is still a hypothetical and extremely unlikely scenario; stop worrying about it. Gawaon (talk) 15:18, 30 September 2026 (UTC)Reply
I'm not worried about it, at all. It was simply an illustrative example. The point was to support the notion of being mobile-friendly, while also questioning the veracity of specific claims regarding the motivated reason(s) for not having links in headings. That's all.  — sbb (talk) 15:34, 30 September 2026 (UTC)Reply
Well, avoiding links in headings avoids very real problems with people having to click on headings to uncollapse the section on mobile. No corresponding problems exist for definition lists, nor will they realistically emerge in the foreseeable future. That is a fact and I suggest we stick to it. Gawaon (talk) 04:36, 1 October 2026 (UTC)Reply
Well, avoiding links in headings avoids very real problems with people having to click on headings to uncollapse the section on mobile. 100% agreed. That was never under debate, at all. I only challenged the claim that that The "no links in headings" thing is primarily for mobile users. (strong emphasis mine in the quoted text). That is, the prohibition against links in headings existed long before mobile was even a practical consideration. That's all.
No corresponding problems exist for definition lists, nor will they realistically emerge in the foreseeable future. Challenge accepted, hold by beer. (😊 Sorry, I'm kidding. I'm not sure I have the CSS technical skills to pull that off; but I would love to be able to demo that functionality).  — sbb (talk) 14:39, 1 October 2026 (UTC)Reply
Definition lists, like the other two types of list (ordered and unordered), have no header row: they just jump straight in with the first entry. So to make them have a heading, title etc. needs something extra beforehand; and to make that "something extra" perform a collapse function, it needs to be some sort of wrapper like {{cot}}/{{cob}}. These generate a div element; and when you click "show" or "hide", it's the div you're collapsing, not its contents. It doesn't matter whether those contents are a definition list, another list or just plain text. So the "no links in headings" thing doesn't apply to lists per se, but is debatable whether they should be permitted on a {{cot}}. --Redrose64 🌹 (talk) 07:32, 2 October 2026 (UTC)Reply
The "no links in headings" thing is primarily for mobile users, don't get me wrong, I agree with being acutely aware of mobile viewers and making sure mobile works well. But in regards to your specific claim that the rule is primarily for mobile users, citation needed. Here's the MOS wording from Oct 1 2007 (arbitrary date mid-2007 when the iPhone was barely even out; mobile was certainly not a major consideration):

In headings and subheadings: [...] links are never used, in favor of linking the first occurrence of the item in the section text;

The text in the MOS from Mar 1 2007 states Avoid putting links in headings; try to link the first occurrence of the word or phrase in the section text, instead.
Again, I'm not disputing that not putting links in headings for mobile reasons is good; I'm disputing that it is primarily for mobile users.
And what is more, that rationale contradicts the rationale stated by David Eppstein, who maintains it's strictly a technical limitation due ot the WP engine, automatic ToC generation, etc.
Finally, for the same rationale, I suggest that anything heading-like (headings, pseudo-headings, description list terms, etc.) should strongly avoid links in them, being a "safe" space to touch and land on, without accidentally taking the mobile userout of their reading context. Too much blue every where can mobile a MOS:SEAOFBLUE minefield; keeping heading-like material as link-free as possible seems like goo design, as well as good encyclopedic MOS direction.  — sbb (talk) 23:20, 27 September 2026 (UTC)Reply
Your opening post contains these questions: Is there a way we can get clearer directive on this? Should I open an RfC to tweak the MOS's text in the lat paragraph to specifically state the interpretation that links should not be in the term-portion of ;:-delimited lists? So far five people have commented (I am the sixth); three of them have explicitly said your interpretation is wrong, and the rest have not commented on that question. In my opinion, this would be a good opportunity to read the room let this idea go. --JBL (talk) 12:06, 27 September 2026 (UTC)Reply
"Read the room and let this idea go"? Why? I have strong opinions, weakly held. I absolutely will abide by consensus, one way or the other. But just because some people disagree with me now doesn't mean that I'm wrong, I'm merely in the minority position. That doesn't mean that I can't still advocate for the position I believe is better, and make my best case, while following consensus in the meantime.
Please, there is no need to tell somebody "let this idea go". I didn't ask for clarification to change my mind; this isn't Reddit's r/ChangeMyView. I have made edits based on my understanding of this subject, that I am seeking clarification and consensus for. If my understanding is rct, so be it; I will edit accordingly moving forwards. But that doesn't mean I need to essentially "drop it and let it go" here, which is what I can't help but infer from your comment.
It clearly had traction at one time (hence the conflicting direction in {{term}}'s documentation). Does "consensus" merely mean the 5 or 6 editors who respond in the first 2 days, but the opinions of people who respond a week (or even month) later don't count because they didn't rush in immediately? After all, there is no timeline on dispute resolution, or moving towards clarification, or even change, later, if necessary.  — sbb (talk) 21:46, 27 September 2026 (UTC)Reply
I stopped reading at the word “why?” The answer is that this is a collaborative project and obsessively pressing a point in the face of many people telling you you’re wrong is uncollaborative, uncollegial, a waste of the time of other editors, and consequently disruptive. Continuing after explicitly being asked to stop, moreso. (You have been here long enough that to include the WP: links that go with these straightforward assertions risks sounding condescending, so I omit them.) Please stop. --JBL (talk) 01:14, 28 September 2026 (UTC)Reply
Nobody asked me to stop except you. Others asked me clarifying questions. So you appear to be having a problem with either me, or with the fundamental question to begin with. Regardless, your objection is noted, you don't have to read any more.  — sbb (talk) 03:08, 28 September 2026 (UTC)Reply

Avoiding multi-word hyphenated items

[edit]
Latest comment: 6 days ago2 comments2 people in discussion

Multi-word hyphenated items: It is often possible to avoid multi-word hyphenated modifiers by rewording: One instance of this I've encountered repeatedly lately are cases like "the 8th-century BC prophet Isaiah". I think these should definitely be avoided and replaced, not only because they show an increasing tendency towards telegraphese, and are frankly ugly, but also because they raise issues of spelling: shouldn't it be "8th-century-BC", with full hyphenation throughout the adjunct? --Florian Blaschke (talk) 17:18, 27 September 2026 (UTC)Reply

The one-hyphen version would be correct only if Isaiah was from British Columbia and flourished around 750 AD. The two-hyphen version is correct for the meaning that the writer intended. Indefatigable (talk) 22:54, 27 September 2026 (UTC)Reply

Discussion at Talk:Flydubai Flight 1073 § Date and incident in the first sentence per MOS:FIRST

[edit]
Latest comment: 2 days ago1 comment1 person in discussion

 You are invited to join the discussion at Talk:Flydubai Flight 1073 § Date and incident in the first sentence per MOS:FIRST. Dw31415 (talk) 03:05, 1 October 2026 (UTC)Reply

Italicized section headings with a colon (:) at the end.

[edit]
Latest comment: 1 day ago3 comments3 people in discussion

Hello everyone! Hope y'all are having a good day. I am a new editor and I wanted to suggest a possible formatting change for section headings.

My idea is to have section headings appear in italics and have a colon (:) at the end of the heading. I think this could give headings a slightly different visual style and make them feel more distinct from the text underneath them. Besides, it just gives a sense of... Art! And also (I personally think) people would be more used to it AND it would make more sense.

For example:

Current "History"

Proposed: ''History:''

(See what I did there?)

I understand that Wikipedia tries to keep its formatting consistent, so I would like to hear what other editors think before making any larger changes. I am also open to suggestions or modifications to the idea if there are concerns about readability, accessibility, or consistency with the current Manual of Style.

As I said before, I am a new editor, so I would appreciate any feedback or advice about whether this would be appropriate for Wikipedia and, if so, what the proper process would be for proposing it.

Thank you and cheerio! Anonymous The Himothy (talk) 15:23, 2 October 2026 (UTC)Reply

Welcome to Wikipedia, @Anonymous The Himothy! Unfortunately, this is very unlikely to succeed. A change like this would require a lot of input and a high degree of consensus. It is a major change that would impact nearly every article and project page. It would also be a major departure from how other Wikimedia projects are formatted, including other language versions of Wikipedia and sister projects like Wiktionary. I'm not sure it's correct that people would be more used to this style. Section headings or chapter titles are formatted many different ways in print and online. Our approach of using a much larger size and a distinct font is fairly common. Keep in mind, also, that Wikipedia is one of the most visited sites on the web. Millions of readers are already quite familiar with the way we do things. The change is likely to be quite jarring, though of course people would get used to it. I hope this is not discouraging but I wanted to be honest and realistic about the prospects of this succeeding. —Myceteae🍄‍🟫 (talk) 16:40, 2 October 2026 (UTC)Reply
@Anonymous The Himothy: You can do this for yourself (but nobody else) by opening up Special:MyPage/common.css and pasting in the following two CSS rules: 
/* Make all section headings italic */
.mw-heading1>h1,
.mw-heading2>h2,
.mw-heading3>h3,
.mw-heading4>h4,
.mw-heading5>h5,
.mw-heading6>h6 {
  font-style: italic;
}
/* Add a colon to the end of all section headings */
.mw-heading1>h1::after,
.mw-heading2>h2::after,
.mw-heading3>h3::after,
.mw-heading4>h4::after,
.mw-heading5>h5::after,
.mw-heading6>h6::after {
  content: ':';
}
This works on English Wikipedia only. If you want it to also work on other Wikimedia sites - such as Commons, Wiktionary, other-language Wikipedias etc. you should put it into meta:Special:MyPage/global.css instead. --Redrose64 🌹 (talk) 22:17, 2 October 2026 (UTC)Reply
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&oldid=1378087479"