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

Style discussions elsewhere
| This section is pinned and will not be automatically archived until 13:00, 2 June 2046 (UTC). |
Add a link to new discussions at top of list and indicate what kind of discussion it is (move request, RfC, open discussion, deletion discussion, etc.). Follow the links to participate, if interested. Move to Concluded when decided, and summarize conclusion. Please keep this section at the top of the page.
Current
(newest on top)
- Talk:LGBTQ and Wikipedia#Requested move 7 August 2026 – Does LGBTQ need to modify something?
- Talk:Jessie (2011 TV series)#Totah's name as used in this article – Discrepancy between MOS:TVCAST and MOS:GENDERID? (June 2026)
- Wikipedia:Village pump (policy)#Upgrade MOS:ALBUM to an official guideline – RfC: Should Wikipedia:WikiProject Albums/Album article style advice be promoted from its current status as a WikiProject advice page to a subject-specific guideline within the MOS? (January 2026)
- Talk:RBMK#Is "RBMK reactor" grammatically correct? Can RAS syndrome apply to acronyms from another language if one of the words has a 1:1 English translation? — Preceding unsigned comment added by Please call me Blue (talk • contribs) 20:46, 23 January 2026 (UTC)
- Wikipedia talk:Manual of Style/Spelling RfC: Should theater be adopted as the standard American English spelling? (December 2025)
- Template talk:WikiProject Manual of Style#Updating template – updating wording on a widely used template
- Talk:New Zealand#Use commonly understood words – On the applicability of current discussions here concerning ENGVAR and COMMONALITY to articles written in New Zealand English
- Wikipedia talk:Manual of Style/Infoboxes#Flags and coats of arms - Usage of flags and coats of arms in infoboxes relating to entities with them
- Talk:Carleton S. Coon#Birth and death places – a discussion pertaining to MOS:IBP (April 2025)
- Wikipedia:Village pump (policy)/The term committed suicide – A perennial unresolved usage debate has returned, with a variety of proposals (March 2025)
- Summary of prior related major discussions: MOS:SUICIDE, MOS 2014, WTW 2016, MOSBIO 2017, MOS 2017, VPPOL 2018, VPPOL 2017, WTW 2018, CAT 2019, VPPOL 2021, VPPOL 2023
- Talk:Vasa (ship)#Informational footnotes (again) – a discussion pertaining to MOS:RETAIN and MOS:LAYOUT (Jan.–Feb. 2025, following on a not quite conclusive Feb. 2024 RfC)
- Wikipedia talk:Manual of Style/Biography#Proposal to import a line-item from WP:JUDAISMSTYLE into MOS:BIO – to use policy-based material on "Christ" found in an essay but more useful in a guideline (Nov. 2024)
Pretty stale but not "concluded":
- * Wikipedia:Village pump (policy)#(stylized in all caps) – Concerns MOS:STYLIZED (August 2026); archived with minimal participation and no formal conclusion
- Talk:Archimedes/Archive 4#MOS:'S – on whether this subject should be exempt from MOS:POSS (Dec. 2024 – March 2025) Result: rough consensus to keep Archimedes' screw and similar possessives for Ancient Greek names per WP:COMMONNAME, no conclusion.
- Talk:Fun (band)#RfC on article tense – RfC (June–July 2025) on whether to refer to an inactive, but not apparently disbanded band in the present or past tense. Result: Modest participation discussion stalled, no conclusion.
- RfC needed on issue raised at Wikipedia talk:Manual of Style/Biography/2024 archive#British peer titles in infoboxes (June–July 2004, archived without resolution). Presently, the royalty/nobility wikiprojects have imposed putting British peerage titles in place of names in biographical infoboxes, against MOS:BIO, MOS:INFOBOX, and the template's documentation. Either the community will accept this as a best practice and the guidelines changed to accomodate it, or it should be undone and the infobox used consistently and as-intended.
- A MOS:JOBTITLES revision RfC needs to be drafted, based on Wikipedia talk:Manual of Style/Biography/2023 archive#JOBTITLES simplification proposal (Dec. 2023 – Jan. 2024, archived without resolution). JOBTITLES remains a point of confusion and conflict, which the guidelines are supposed to prevent not cause.
- Wikipedia talk:Naming conventions (companies)#Use of comma and abbreviation of Incorporated – Involves MOS:TM (plus WP:COMMONNAME, WP:OFFICIALNAME, WP:POLICYFORK). Covers more than thread name implies. (Dec. 2023 – Jan. 2024) Result: Stalled without resolution; at least 3 options identified which should be put to an RfC.
- Wikipedia talk:Manual of Style/Islam-related articles#NPOV usage of "the prophet Muhammad" or "the prophet" – Involves MOS:HONORIFIC, MOS:DOCTCAPS, WP:NPOV, WP:CHERRYPICKING, etc. (Sep. 2023 –) Result: Still unresolved, though consensus seems to lean toward permitting lower-case "prophet" when needed for disambiguation, but no agreement yet on specific guideline wording.
- Help talk:Table/Archive 9#Indenting tables – Help page is conflicting with MOS:DLIST and MOS:ACCESS on a technical point. (Aug. 2023 – Jan. 2024) Result: No objection to fixing it, and a suggestion to just do it WP:BOLDly, but the work actually has to be done.
Capitalization-specific:
- Talk:Grave Error: How The Media Misled Us (and the Truth about Residential Schools)#Requested move 24 August 2026 – lowercase "the", uppercase "about"?
- Talk:Once Upon a Time#Requested move 25 August 2026 – Move this disambiguation page to sentence case and append "(disambiguation)"?
- Talk:TOPLYGA#Requested move 25 August 2026 – Change to "Toplyga"?
Other discussions:
- Talk:Other (philosophy)#Capitalizing "other" posted August 21, 2026
- Wikipedia talk:WikiProject UK Railways/Archive 60#Railway line article names (archived, most recent comment: 30 August 2025)
- Talk:North Yemen civil war#Capitalising "26 September revolution" - in prose? (most recent comment: 24 July 2025)
- Talk:Left-Bank uprising#Capitalization – Should "Left-Bank" be capped? (most recent comment: 10 June 2025)
- Talk:Thirty Years' War/Archive 2#Imperial v imperial (most recent comment: 28 May 2025)
Concluded
Extended content | ||
|---|---|---|
|
Italicization of self-refs, redux
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)
- 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)
- 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)- 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)
- 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)
- How would "not parenthetical asides" work in inline style? Can you give a specific example? Gawaon (talk) 09:14, 28 July 2026 (UTC)
- 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)
- 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)
- 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)
- "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)
- 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)
- 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)
- 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)
- 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)
- "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)
- 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)
- 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)
- 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)
- Sure. Putting these asides in italics offsets them from the text:
- How would "not parenthetical asides" work in inline style? Can you give a specific example? Gawaon (talk) 09:14, 28 July 2026 (UTC)
- 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)
- 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)
- 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)
- 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.
- 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)
- 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)
- 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)
- 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 ),
- 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)
- 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)
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)
- 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)
- 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)
- 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)
- One alternative would be to just revert to the version from 2014. –jacobolus (t) 00:14, 22 August 2026 (UTC)
- 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)
- One alternative would be to just revert to the version from 2014. –jacobolus (t) 00:14, 22 August 2026 (UTC)
- 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)
- 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)
- 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 ),
- 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)- 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)
- 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)
- 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)
- 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)
- 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)
Typo
There's a typo in the explanation of comma splices. The word "Accepted" seems to have shifted position in the description of the exception concerning two short clauses using the quote "Life is short, art is long." ~2026-42636-56 (talk) 08:57, 2 August 2026 (UTC)
- Further to this, I realise now that it's not actually a typo. It just reads like one when viewed on mobile because the word "Accepted" is in a separate text column on the left, and the example text on the right is partly in black (whereas generally elsewhere the page the right column will have text of a fully different colour, being usually just a quoted example). This creates a section of black text that seems to read (across both columns), "(two brief Accepted: clauses in an aphorism;". This is presumably not apparent on a larger screen. I don't know if this is worth attention, but it did throw me when reading it.
- The double-column format works well enough elsewhere on the page but sometimes the word in the left column is low enough to create awkwardness alongside the right hand text. There may be an argument for making sure the left column text always sits at the top, next to the start of the right column text it labels, instead of being kind of vertically centred and floating further down. I can't see that changing this would cause any problems. ~2026-42636-56 (talk) 08:30, 3 August 2026 (UTC)
- I've said it before and I'll say it again: different people have different setups. There are many variables involved, not just physical screen width. We cannot possibly code to suit everybody. --Redrose64 🌹 (talk) 18:28, 3 August 2026 (UTC)
- I agree this doesn't look great, but the default vertical alignment for wiki tables is "middle", for better or worse. To "fix" this we'd need to either add
style="vertical-align:top;"to each cell or add {{Table vertical alignment}} templates and classes to each table. pburka (talk) 22:22, 3 August 2026 (UTC)- I'm sorry - I'm new to this and thought maybe the simplest thing would be to adjust that left cell. Another option would be losing the table and adopting the method used elsewhere in the style guide, where the description is at the beginning in black and the example follows directly in the same sentence in a colour. This would be more work and I realise this might have been discussed a hundred times already, and I respect the view that it might not be necessary or that the visual separation offered by the tables is better. I have the utmost respect for all the good and important work done here. ~2026-42636-56 (talk) 07:52, 4 August 2026 (UTC)
Navbox (Navigational Template) film years
I cannot find the exact place in the MOS where it states that films in navboxes shall be permanently conjoined to the year in which they were released so that they may occupy twice the space they should, so I apologize if this topic is posted in the wrong location. It seems necessary that appended years disambiguate when two identically-titled works are linked in the same navigational template, but for films with entirely unique titles they serve only to embiggen the navboxes and provide little value. For an example, see Template:Journey to the West. There is only one article titled Monkey King vs. Er Lang Shen or Saiyuki: Requiem. The release date can be found in the infobox or lede or on-hover preview and does not need to pad the navigational template. Similarly, there is only one animated film adaptation of Journey to the West titled Nobody, so the year is superfluous and does not distinguish it from any other adaptation of Journey to the West. TPI81AF (talk) 23:13, 3 August 2026 (UTC)
- However, there are various films titled Nobody, so you can't just list the title and hope for the best. More generally, some films don't need disambiguation by year, but others do. Including the year only in the latter cases would be confusing to readers and hard to maintain, since you'd have to constantly check whether years are actually needed or not. Including the year in all cases is clearer, easier, and more robust. Gawaon (talk) 02:27, 4 August 2026 (UTC)
- In the context of the Navigational template titled Journey to the West under Films > Animated there is no question as to which film Nobody will link to. Including the year in only cases where it is needed already happens with every other form of media. Films are not so exceptional to warrant the clutter. TPI81AF (talk) 15:08, 4 August 2026 (UTC)
- Absent any confirmed guideline instructions, I don't see a problem with including the year by default for all the adaptations. It's a tiny bit of text relative to the entirety of the template/navbox. Including it for all the adaptations has some benefits. It gives a sense of the breadth of adaptations. It breaks up the blue links which provides some contrast and makes it easier to click on the desired title. I realize MOS:SOB does not apply to navboxes but we should be considerate of accessibility and UI/UX where feasible. Aesthetically, it provides some nice symmetry. —Myceteae🍄🟫 (talk) 15:54, 4 August 2026 (UTC)
- The problem is that adding an extra 6 characters of text for every one of the hundreds of links included results in the navbox too closely resembling the Star Wars opening crawl, requiring dozens of seconds to transit via scrolling and occupying half the length of the article. TPI81AF (talk) 16:01, 4 August 2026 (UTC)
- But navboxes like Template:Journey to the West are already so massive that they require a lot of scrolling regardless. On balance, I find that breaking up the links improves readability and navigability, especially on small screens where scrolling is already necessary. —Myceteae🍄🟫 (talk) 16:57, 4 August 2026 (UTC)
- The problem is that adding an extra 6 characters of text for every one of the hundreds of links included results in the navbox too closely resembling the Star Wars opening crawl, requiring dozens of seconds to transit via scrolling and occupying half the length of the article. TPI81AF (talk) 16:01, 4 August 2026 (UTC)
- If this is covered by any aspect of the MOS, I'd expect to find it in MOS:FILM. pburka (talk) 18:18, 4 August 2026 (UTC)
- Unfortunately, that part of the MOS seems to be primarily concerning articles on films and has but a footnote regarding navigational templates, linking to a page that does not offer any guidance as to whether the presence or absence of years next to film links in navboxes is preferred. TPI81AF (talk) 18:32, 4 August 2026 (UTC)
Examples at Strong national ties to a topic
Why do we have a random list of examples at § Strong national ties to a topic? A MOS shouldn't be used to give examples of things, I propose we keep one or two and remove the rest. FaviFake (talk) 21:13, 8 August 2026 (UTC)
- Eh, I don't see a problem. The list gives us representative examples of different kinds of of topics (peoples/ethnic groups, populated places, buildings, events, government/military institutions) and multiple varieties of English to highlight that British and American aren't the only standards. You're probably right that we could get the same point across with fewer examples but I don't think anything would be gained. I also disagree with the basic premise,
A MOS shouldn't be used to give examples of things
. Sometimes no example is needed, sometimes the examples are excessive, and sometimes having too many is actually problematic but I find the list here more helpful than not. —Myceteae🍄🟫 (talk) 21:25, 8 August 2026 (UTC) - Examples can be very effective in a manual of style. Given that ENGVAR is a frequent topic of dispute, providing examples here seems particularly valuable. It looks to me like we have one example per accepted variant of English. I do think the examples could be made more useful by finding some less obvious topics with TIES (six of the twelve examples are cities). pburka (talk) 21:26, 8 August 2026 (UTC)
- If it isn't obvious it's not a case for TIES. TIES should be used only when it's extremely obvious. --Trovatore (talk) 21:30, 8 August 2026 (UTC)
- I don't mean that the ties shouldn't be obvious. I mean that cities, structures or events within the country are the most obvious examples of strong national ties, and therefore the least useful to editors. That Vancouver has strong ties to Canada is so obvious as to be uninformative. More interesting examples might include CANDU reactor or "American Woman". pburka (talk) 21:43, 8 August 2026 (UTC)
- I'm concerned that anything beyond the blatantly obvious is going to encourage editors to search for national ties. CANDU has "Canada" right in the name so that's kind of a one-off; there aren't many things like that. I'm not really convinced that American Woman needs to be in Canadian English just because the band was Canadian; in practice I think it probably either would be or you could get consensus to change it on the talk page (remember TIES isn't needed if you can get a local consensus), but I don't see any need to pull it into the TIES orbit. For the examples I would stick with locations in an English-speaking country, persons who were nationals of a single English-speaking country and never lived in another one, laws of an English-speaking country, stuff like that. Also we should emphasize that there are no TIES to countries other than English-speaking countries. --Trovatore (talk) 21:59, 8 August 2026 (UTC)
- I don't mean that the ties shouldn't be obvious. I mean that cities, structures or events within the country are the most obvious examples of strong national ties, and therefore the least useful to editors. That Vancouver has strong ties to Canada is so obvious as to be uninformative. More interesting examples might include CANDU reactor or "American Woman". pburka (talk) 21:43, 8 August 2026 (UTC)
- If it isn't obvious it's not a case for TIES. TIES should be used only when it's extremely obvious. --Trovatore (talk) 21:30, 8 August 2026 (UTC)
- I tend to agree with FaviFake that this list is a bit long. I suppose the point is to make sure we don't leave anyone out, but I don't know that that's in scope for a style manual. The thing we should really emphasize here is that you should never strain to find national ties. If it's not blatantly obvious, go with the main rule, which is RETAIN. --Trovatore (talk) 21:34, 8 August 2026 (UTC)
- MOS:TIES is very short, even including the list of examples. Possibly a few of them could be cut, but considering that it's so short already, I don't see much need to do so. Gawaon (talk) 02:21, 9 August 2026 (UTC)
- I think it's out of proportion to the importance of the guideline. TIES is a little carveout; we shouldn't overemphasize it. Honestly I'd be good with eliminating it entirely. --Trovatore (talk) 02:24, 9 August 2026 (UTC)
- That's your opinion, but I kinda doubt you'll get consensus on it. And I fail to see how we could even try to evaluate the "importance" claim. As I see it, the MOS isn't divided into "important" and "unimportant" parts; everything it says is equally relevant. Gawaon (talk) 04:06, 9 August 2026 (UTC)
- In my 20 years of editing there have been only 2 things constant - people complaining about spelling and people complaining about date formats. In both cases it always comes down to preference of local dialects and custom rather than right vs wrong. WP:TIES is not really liked by anybody but has far more traction than any other proposal. Anything we can do to make it clearer for new (or ignorant or stubborn) editors is a good thing. Stepho talk 04:57, 9 August 2026 (UTC)
- More traction than RETAIN? Not sure I buy that. The thing is that RETAIN could apply to any article, whereas TIES is a narrow carveout for a minority of articles. If it were up to me we'd just go with straight RETAIN, which would be simpler. It would admittedly give strange results in a few cases, but those could be corrected by getting a consensus on the talk page; TIES is a way to short-circuit the consensus-gathering process and isn't really needed. --Trovatore (talk) 05:53, 9 August 2026 (UTC)
- I see your point - although I think of TIES and RETAIN as 2 sides of the same coin. Ie, choose British vs US when one clearly dominates over the other and retain for all other situations (including no ties, weak ties, ties to both, conflicting ties, etc). Stepho talk 14:03, 9 August 2026 (UTC)
- Agreed. TIES let's us avoid many protracted and contentious discussions about which ENGVAR to use, and guides editors towards choosing the appropriate variety when creating new pages. pburka (talk) 15:28, 9 August 2026 (UTC)
- It has some value as long as it stays tightly circumscribed to cases where it's absolutely obvious. The problem is that the borderline is unclear, and there's a temptation to use it in cases where it doesn't apply (say, to a device because it was invented by an American, or to a bird that spends more time in the US than in Canada, or to bio of an Italian because when Italians do use English they're more likely to use British spelling). Trying to elaborate a list of cases where it doesn't apply could easily just make the problem worse, as editors argue about the legalisms there. On the other hand RETAIN is a nice simple rule, applies to everything, and you can fix anything glaringly strange by just talking about it. --Trovatore (talk) 15:36, 9 August 2026 (UTC)
- Without TIES, there'd be no basis for ever changing the ENGVAR. pburka (talk) 15:52, 9 August 2026 (UTC)
- I agree that TIES is important and has a fairly limited scope. Borderline cases will always exist. The fact that it is a narrow carve-out and may be seen as being at odds with other provisions of the MOS and ENGVAR specifically is a reason why it should be highlighted, and not de-emphasized. I find that having multiple examples, even with some repetition of, e.g., cities, drives home the point that the scope is narrow and applies to all national varieties of English. —Myceteae🍄🟫 (talk) 17:29, 9 August 2026 (UTC)
- It has some value as long as it stays tightly circumscribed to cases where it's absolutely obvious. The problem is that the borderline is unclear, and there's a temptation to use it in cases where it doesn't apply (say, to a device because it was invented by an American, or to a bird that spends more time in the US than in Canada, or to bio of an Italian because when Italians do use English they're more likely to use British spelling). Trying to elaborate a list of cases where it doesn't apply could easily just make the problem worse, as editors argue about the legalisms there. On the other hand RETAIN is a nice simple rule, applies to everything, and you can fix anything glaringly strange by just talking about it. --Trovatore (talk) 15:36, 9 August 2026 (UTC)
- Agreed. TIES let's us avoid many protracted and contentious discussions about which ENGVAR to use, and guides editors towards choosing the appropriate variety when creating new pages. pburka (talk) 15:28, 9 August 2026 (UTC)
- I see your point - although I think of TIES and RETAIN as 2 sides of the same coin. Ie, choose British vs US when one clearly dominates over the other and retain for all other situations (including no ties, weak ties, ties to both, conflicting ties, etc). Stepho talk 14:03, 9 August 2026 (UTC)
- More traction than RETAIN? Not sure I buy that. The thing is that RETAIN could apply to any article, whereas TIES is a narrow carveout for a minority of articles. If it were up to me we'd just go with straight RETAIN, which would be simpler. It would admittedly give strange results in a few cases, but those could be corrected by getting a consensus on the talk page; TIES is a way to short-circuit the consensus-gathering process and isn't really needed. --Trovatore (talk) 05:53, 9 August 2026 (UTC)
- In my 20 years of editing there have been only 2 things constant - people complaining about spelling and people complaining about date formats. In both cases it always comes down to preference of local dialects and custom rather than right vs wrong. WP:TIES is not really liked by anybody but has far more traction than any other proposal. Anything we can do to make it clearer for new (or ignorant or stubborn) editors is a good thing. Stepho talk 04:57, 9 August 2026 (UTC)
- That's your opinion, but I kinda doubt you'll get consensus on it. And I fail to see how we could even try to evaluate the "importance" claim. As I see it, the MOS isn't divided into "important" and "unimportant" parts; everything it says is equally relevant. Gawaon (talk) 04:06, 9 August 2026 (UTC)
- I think it's out of proportion to the importance of the guideline. TIES is a little carveout; we shouldn't overemphasize it. Honestly I'd be good with eliminating it entirely. --Trovatore (talk) 02:24, 9 August 2026 (UTC)
- MOS:TIES is very short, even including the list of examples. Possibly a few of them could be cut, but considering that it's so short already, I don't see much need to do so. Gawaon (talk) 02:21, 9 August 2026 (UTC)
"A Ukrainian" or "An Ukrainian"?
Is there a preference for one form or the other? The main page currently has a caption that includes "A Ukrainian". My search of MOS and MOS talk didn't show a previous discussion about this. I believe that "An Ukrainian" is correct and "A Ukrainian" is incorrect, but both seem to be used in external media. Thanks, ༄ᨒ𖠰 Pine (✉) 01:35, 16 August 2026 (UTC)
- Would "an university" be correct? Nurg (talk) 01:42, 16 August 2026 (UTC)
- It's the sound that dictates it, not the letter. The word doesn't begin with a vowel sound, even though it begins with a vowel. ~2026-42636-56 (talk) 02:02, 16 August 2026 (UTC)
off-topic thread about "an historical" |
|---|
|
- "A" is correct per the pronunciation, as everyone else has said. Per Google Ngram an Ukranian is used but is rare in comparison to a Ukrainian. —Myceteae🍄🟫 (talk) 02:14, 16 August 2026 (UTC)
The MoS isn't here to explain basic English grammar. The correct usage is a Ukrainian, but there is no need for this to appear in the manual; it's up to editors to clean up after anyone who makes a mistake. --Trovatore (talk) 02:16, 16 August 2026 (UTC)
Indentation of formulas
The advice at MOS:INDENT cannot be implemented exactly as described. See discussion at Help talk:Displaying a formula#Indentation rules. ~Kvng (talk) 15:00, 16 August 2026 (UTC)
- I was partially wrong about technical problems with
<math display="block">; the problem is only in certain preview rendering. However, the discussion I've linked does not appear to indicate a consensus to use this technique in preference to the colon indentation. ~Kvng (talk) 14:27, 19 August 2026 (UTC)
"...retain 'U.S.' in American or Canadian English articles..."
@MapReader: I respectfully disagree with the reasoning in your revert here. I suspect that you are approaching it from a propositional-logic perspective instead of set theory. We want the reader to do something in American English articles and in Canadian English articles
, which is shortened to in American and Canadian English articles
. Its a union. Obviously no article should be declared as American and Canadian simultaneously. — voidxor 15:14, 16 August 2026 (UTC)
- I agree with MapReader's revert. Normal English language usage isn't required or expected to adhere to formal logic conventions. There is no reasonable interpretation of "American or Canadian" that could possibly mean anything other than what we all agree this is intended to mean. Trying to "fix" it for not complying with some paradign of formal logic looks like a solution in search of a problem. ~2026-40817-33 (talk) 22:04, 16 August 2026 (UTC)
- I prefer
and
here but I also don't think it matters. There is no serious likelihood of misinterpretation here. There is also no difference in outcome if it were misinterpreted. —Myceteae🍄🟫 (talk) 22:08, 16 August 2026 (UTC) - Both versions are correct. Encyclopedic writing isn't the same as formal logic. pburka (talk) 22:26, 16 August 2026 (UTC)
- I'm not a grammarian so I risk making a fool of myself. For,
in American English articles and in Canadian English articles
, voidxor would be correct. But the original short version, parsed as English> articles"}},"i":0}}]}' id="mwArg"/><<American or Canadian> English> articles
, is fine. On the other hand, voidxor's change seems wrong whichever way it's parsed. English> articles"}},"i":0}}]}' id="mwAro"/><<American and Canadian> English> articles
would be wrong (assuming articles are one or the other). articles"}},"i":0}}]}' id="mwArw"/>American and <Canadian English> articles
would be wrong because the text is about American English articles, not American articles per se. articles"}},"i":0}}]}' id="mwAr4"/><American and Canadian English> articles
would be wrong for the same reason. Nurg (talk) 03:10, 17 August 2026 (UTC)
- The change could also be taken to advise editors "You should retain U.S. in Canadian English articles in which it is already established, or in American English articles in which it is already established, but not both", since "or" is (or can be inferred to be) an XOR, because otherwise either "and/or" or "A or B, or both" (that is, OR) would be explicitly used, and neither was. Anyway, it was OK before, the change is also OK, but per stare decisis we should avoid roiling the text for no gain, especially on rules pages. My 2p. Herostratus (talk) 03:51, 17 August 2026 (UTC)
- I agree we should just leave whatever the long-standing version was since both are functionally equivalent. The fact that either one could theoretically be read to support an absurd misinterpretation is not a compelling reason to make a change. As always, if there is evidence of recurring disputes about the meaning we can revisit this. I can't fault MOS editors too much for wordsmithing and dwelling on minutiae but I think we can let this one go. —Myceteae🍄🟫 (talk) 04:14, 17 August 2026 (UTC)
- To clarify, the reason for my change was one of correctness, as stated in my edit summary, not that it
could theoretically be read to support an absurd misinterpretation
. That's why I said "obviously" above. If everybody wants to maintain the status quo because there's no misinterpretation concern, that's fine, but my original interpretation was that we're referring to "article group 1" and "article group 2", taken together. - Thanks everybody for your thoughtfulness and input. — voidxor 14:21, 17 August 2026 (UTC)
- Yes, and we're referring to any article that's in group 1 or in group 2. That works too, and just as well. Gawaon (talk) 15:08, 17 August 2026 (UTC)
- But what is "correct"? I know my initial reply was a bit flippant in tone (for which I am sorry), but the fundamental point is this: the English language is (very often) not logical. There are countless conventions in English that are used to mean things that they would not mean if one were to apply formal logic rules to them.
- That does not make them incorrect. Every system has its own conventions and what's correct in one is often wrong in another and vice versa. The word "or" can be used in many versatile ways in English, and it the overlap with "and" is large.
- We could go down a very deep rabbit hole analysing this if we wanted to, and it's tempting, but it's not likely to be constructive. Far simpler is just to accept that some things in any given language, no matter how seemingly illogical they may be, are. nevertheless correct, for no other reason than that the users of that language have agreed they're correct, and leave it at that. ~2026-40817-33 (talk) 16:49, 17 August 2026 (UTC)
- To clarify, the reason for my change was one of correctness, as stated in my edit summary, not that it
- I agree we should just leave whatever the long-standing version was since both are functionally equivalent. The fact that either one could theoretically be read to support an absurd misinterpretation is not a compelling reason to make a change. As always, if there is evidence of recurring disputes about the meaning we can revisit this. I can't fault MOS editors too much for wordsmithing and dwelling on minutiae but I think we can let this one go. —Myceteae🍄🟫 (talk) 04:14, 17 August 2026 (UTC)
- The change could also be taken to advise editors "You should retain U.S. in Canadian English articles in which it is already established, or in American English articles in which it is already established, but not both", since "or" is (or can be inferred to be) an XOR, because otherwise either "and/or" or "A or B, or both" (that is, OR) would be explicitly used, and neither was. Anyway, it was OK before, the change is also OK, but per stare decisis we should avoid roiling the text for no gain, especially on rules pages. My 2p. Herostratus (talk) 03:51, 17 August 2026 (UTC)
- We actually want the reader to do something in articles where the ‘U.S.’ format “is already established”, that are written in either American or Canadian English, but not any other sort of English (and not otherwise). Anyone reading the current wording can see that is what it means. MapReader (talk) 05:02, 17 August 2026 (UTC)
ayurveda or Ayurveda?
Style of templates
Most of the issues discussed in the MOS relate to the rendered text, either content or appearance. Are there any guidelines for wikitext, e.g., compact versus a separate line for each parameter, alignment of equal signs? Is there a requirement to retain and be consistent with existing markup style? I ask because the style can affect ease of editing. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:49, 21 August 2026 (UTC)
- The MoS is mainly for readers. The underlying markup normally should not matter, if the end result is the same. What I object to is where some people reformat the markup of an infobox so that all the equals signs have exactly one space before and after, and at some later point, somebody else adds in a varying number of spaces so that all are in the same vertical alignment. --Redrose64 🌹 (talk) 20:34, 21 August 2026 (UTC)
- Guidance on markup, wikitext, etc. is beyond the scope of the MOS, except, of course, where it is relevant the output on the page. There may be some essays or advice pages that recommend best practices or discuss important considerations. We should be considerate of the next person who will come along to edit after us but we should not try to enforce conformity in wikitext when it does not alter the rendered text (or other content). —Myceteae🍄🟫 (talk) 22:50, 21 August 2026 (UTC)
Plurals
I feel the MOS:PLURALS section isn't comprehensive. More could be said there.
The article Agreement in the English language gives some more information:
In British English, collective nouns may take either singular or plural verb and pronoun forms.
Singular forms are used when the emphasis is on the group as a whole.
The committee has postponed its meeting until next week.In these cases which is also used as the relative pronoun.
The band, which was formed in the 1980s, gained international fame.
Plural forms are used when the emphasis is on the individual members.
The committee were arguing among themselves during the session.In those cases who is often used as the relative pronoun.
The band, who have been performing together for decades, released a new album.
The article American and British English grammatical differences also gives some new information:
With exceptions such as usage in The New York Times, the names of sports teams are usually treated as plurals even if the form of the name is singular.
Proper nouns that are plural in form take a plural verb in both AmE and BrE; for example, The Beatles are a well-known band; The Diamondbacks are the champions, with one major exception: in American English, the United States is almost universally used with a singular verb.
This Cambridge article also provides new information.
I used bold type to mark the information that could be added to MOS:PLURALS. Sadly, I am not allowed to edit the page myself, so I ask someone else to do it. Many thanks in adavance ~2026-45660-53 (talk) 21:11, 21 August 2026 (UTC)
- Generally we try to avoid offering grammar advice (although quite a bit has crept in). I'm not sure any of these need to be in the manual of style; they're general rules for good writing, and, as you imply, anyone looking for more info can read the relevant articles in our encyclopedia. pburka (talk) 21:43, 21 August 2026 (UTC)
- I agree with pburka. MOS:PLURALS mostly covers MOS:ENGVAR issues that editors need to be aware of since most people are used to reading and writing in one primary variety of English. MOS:PLURALS already covers collective nouns, including specific mentions sports teams, without going into a lot of detail. I think it's better to keep it simple and just highlight the common patterns and key examples that come up frequently in editing. Rules that are (near) universal (e.g., The Beatles are) shouldn't need to be addressed in the house style guide, although articles are expected to conform with standard conventions. Some of these finer points (the committee is vs. the committee are) are good to be aware of but I'm not sure what the MOS would have to say about them. We have one sentence that addresses the variation within BrE and I don't think it makes sense to try to explain the nuances and rhetorical differences. —Myceteae🍄🟫 (talk) 00:05, 22 August 2026 (UTC)


