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. Not all Web browsers find curly quotes when users type straight quotes in search strings.
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 page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp
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.
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.
Talk:Second Italo-Ethiopian War#Flags in the infobox – a MOS:FLAGICONS matter (Nov.–Dec. 2024) Result: No formal closure, but article has been stable for a while with flag icons in the infobox, whether or not this conforms with the relevant guideline. This is the opposite of the result at "Battle of Tory Island", below.
Various simultaneously executed RMs by the same proponent all concluded against the desired over-stylizations (usually ALL-CAPS) – some by affirmative consensus against, some by no consensus to move.
Talk:Shays's Rebellion#Requested move 27 April 2024 – MOS:POSS: "Shays'" or "Shays's"? Result: "Shays's". No objective rationale was presented for an exception to the guideline, and evidence shows "Shays's" common in source material even if "Shays'" is also common, especially in older sources.
Template talk:Infobox university/Archive 23#Type – Should multiple entries be formatted as a list or a single phrase? (Apr.–May 2024) Result: 4:1 against proposed change to a list format; alternative idea at end neither accepted nor rejected.
Wikipedia talk:Image use policy/Archive 16#Collages in infoboxes – Primarily on a recent habit of military-conflict articles having collages of 4, 6, or even more images in their infobox. (Mar.–May 2024) Result: No formal closure, but a clear consensus against this practice; image galleries (when appropriate at all per WP:GALLERY) belong in the article body.
Wikipedia:Requests for comment/Names of deceased trans people (moved from WP:VPPOL) – Yet another round of this long-term, multi-RfC process. Consensus about "deadnames" seemed possible this time but was mostly elusive. (Dec. 2023 – Jan. 2024) Result: no consensus to change the wording of MOS:GENDERID based on this proposal; consensus against changing "should be included" to "may be included".
Related: See numerous previous deadname-related and more general GENDERID discussions listed below.
Wikipedia talk:Article titles/Archive 61#Request for comment on the relationship between WP:CRITERIA and WP:TITLEFORMAT – has stylistic implications (punctuation, leading "The", etc.) despite not being intrinsically an MoS matter (Nov. 2024) Result: "There is consensus that WP:TITLEFORMAT does not take precedence over WP:CRITERIA. Editors should continue to balance all relevant guidelines and policies when determining article titles, without giving inherent precedence to either section."
Wikipedia talk:Manual of Style/Accessibility/Archive 16#Making redundant table captions screen-reader-only – About use of {{sronly}} around table captions (which are primarily for screen readers) to hide them from the usual non-screen-reader view, only when their content repeats what is in the table headers. (Nov.–Dec. 2023) Result: Archived without firm resolion. As there was but one opposer of the idea, there is no consensus against doing this. If more opposition arose or some reason, open an RfC about it.
Wikipedia talk:Manual of Style/Trademarks#Minor consolidation merge – To merge a line-item (about stylization of stage/pen names) out of MOS:INITIALS (where the one of the examples is only semi-pertinent anyway) and into MOS:TM, leaving behind a cross-reference to MOS:TM from MOS:NAMES. (Nov.–Dec. 2023) Result: Because of some things that apply to personal not corporate names, this ended up not being practical; intead the MOS:BIO material was cleaned up and cross-references between the two MOS sections was improved; description at: Wikipedia talk:Manual of Style/Biography#Minor overhauling. No objections or other issues have come up.
Wikipedia talk:Manual of Style/Dates and numbers#MOS style for odds – About changing MOS:RATIOS to specify a format (new or otherwise) for betting-odds ratios. (Oct.–Dec. 2023) Result: No formal closure, but apparent general agreement that the : style for ratios in general applies to odds ratio in particular like the rest, and MOS:RATIOS updated to say this.
Wikipedia:Village pump (policy)/Archive 187#Proposed change MOS:TERRORIST – On how WP uses terms like "terrorist/terrorism" and "freedom fighter", specifically to add a requirement "these words should only be used in quotations or referencing third-party use of the term". (Oct. 2023) Result: "nearly unanimously opposed".
Talk:2023 Hawaii wildfires/Archive 2#Use of Hawaiian symbols in names – Involves MOS:HAWAII and could have implications for what the guideline says due to wildfire news bringing many more editorial eyes to that page than to WT:MOSHAWAII. (Aug.–Sep. 2023) Result: Archived without closure or any clear consensus; the general gist seems to be that the state of Hawaii is named Hawaii, the island is named Hawaiʻi, and diacritics (ʻokina and kahakō) should not be suppressed in the more localized names (and the US Geological Survey, which sets official placenames, along with the Hawaiʻi Board on Geographic Names, which basically tells USGS what to do in Hawaii/Hawaiʻi, both agree).
Talk:Bayes' theorem#Requested move 23 August 2023 – MOS:POSS stuff. (Aug. 2023) Result: Not moved. Lots of invalid arguments, and confused attempt to pit WP:COMMONAME against MoS (COMMONNAME is not a style policy, never has been one, and never will be; every proposal to incorporate a style matter into a policy has failed).
Wikipedia:Help desk/Archives/2023 August 5#Hyphen vs. En dash usage (Wikidata)? and d:Wikidata:Project chat/Archive/2023/08#Hyphen vs. En dash to separate years of birth/death? – Relating to concordance between wikidata descriptions and enwiki "short description". (Aug. 2023) Result: Good summary: "as long as you choose a comprehensible form, your edits are fine. However, you should not change existing descriptions for stylistic reasons, and also not to unify desriptions for a given set of items"; also observations that various languages, e.g. Spanish, do not use an en dash for this purpose. So, Wikidata will not be changing away from hyphen as default, and any desire to have WD material, like automatically provided short descriptions, will have to do that change on our end.
Talk:SAG-AFTRA#Requested move 20 July 2023 – move to SAG–AFTRA like AFL–CIO, or is there a reason to hyphenate as SAG-AFTRA? (July 2023) Result: Not moved. The closer actually misunderstood the guideline wording badly, and this has created a WP:CONSISTENT policy failure with titles of other such entities including AFL–CIO, and the Famous Players-Lasky decision covered just below. This probably needs to be re-done.
Talk:Famous Players-Lasky#Requested move 24 June 2023 – proposal to use dash instead of hyphen. (June–July 2023) Result: Use the dash per MOS:DASH; a followup RM to add "Corporation" to the title rejected that idea despite WP:NCCORP supporting it, one of several recent RM incidents suggesting that at least some portions of the page do not enjoy consensus.
Wikipedia:Village pump (policy)/Archive 182#RFC: MOS:GENDERID and the deadnames of deceased trans and nonbinary persons – Primarily about "When should Wikipedia articles include the former name of a deceased trans or nonbinary person who was not notable prior to transitioning?" (May–June 2023) Result: "there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. Also, there is clear consensus that a former name is not automatically of encyclopedic interest. Where, exactly, the lines of encyclopedic interest and avoiding confusion are is not simple or clear and will likely need discussion on individual articles, although there is definitely space for more guidance in the MOS". This has let to a lot of follow-on discussion and dispute.
Talk:1925 Tri-State tornado#Requested move 26 December 2024 – Was this the "1925 Tri-State tornado" or "Great Tri-State Tornado" or something else? (closed, then close withdrawn and reopened after a move review, then closed and voluntarily reopened again, then closed again, then another move review, which was closed as "moot" when a parallel RM was closed.)
Talk:Washington (tree)#Requested move 30 April 2025 (18 articles) – if renamed to "[Something] tree", should "tree" be capitalized? Result: Moved to uppercase as nominated, but no clear consensus established on the capitalization
Talk:Fall of Saigon/Archive 1#Names section and capitalisation – capitalisation of Vietnamese language names and capitalisation of their English translations? Result: Archived after comments observing inconsistency, so generally suggesting sentence case for terms in Vietnamese and capitalization for translated named days (e.g. "Liberation Day") in English
Talk:Xkcd#Requested move 29 March 2025 – Should something different be done about the way this article tries to put its title in all-lowercase? Result: Not moved.
Talk:Tri-State tornado outbreak#Requested move 18 December 2024 – Was this a "Tri-State tornado outbreak" or a "tri-state tornado outbreak"? Result: Year added ("1925 Tri-State tornado outbreak"), but no explicit conclusion was expressed about capitalization (an initial move to lowercase was changed by the closer to uppercase the next day), then a move review was opened; closed as "endorse".
The linked discussion has converged on the following consensus: I'd also support spelling out on first mention in each section (with brackets: so "Alzheimer's Disease (AD)") on first mention in each section, and then abbreviating thereafter.
I think the suggestion to re-introduce abbreviations in each section of longer articles (on a case-by-case basis) would be a good addition to MOS:1STABBR. Lots of articles would get easier to follow that way.
I would also second this – readers often go to one section of the article without reading the others, especially for longer articles. GnocchiFan (talk) 18:51, 29 May 2025 (UTC)[reply]
Launches and landings are events that take place in a time zone on Earth, and MOS:TIMEZONE gives "priority to the place at which the event had its most significant effects." Previous editors have suggested using local time for Earth-based events (e.g., launches and landings) and UTC for events in space, which is aligned with the MoS.
The Manual of Style has precedence, and "participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope."
I was hoping that some more experienced editors can give some clarity on how we should handle this issue. Thank you in advance for your responses. -- RickyCourtney (talk) 22:47, 28 April 2025 (UTC)[reply]
To provide additional context, my understanding of MOS:TIMEZONE for Earth-based events (e.g., launches and landings) is to prioritize where the event took place with the local time zone and add UTC for dates and times in the infobox and/or first use in the article.
Effectively, the difference in interpretations is the local time zone first or second. For example:
The mention of precedence was based on my understanding that the WikiProject cannot override the MoS based on local consensus, which is an additional reason I addressed this.
While it’s true that a few articles are listed with launch local time first, the majority are listed with UTC first. That includes all the Apollo mission articles (most of which passed the rigorous Featured Article review process), all Soyuz mission articles (which don’t even list local time), and the majority of the Space Shuttle mission articles (many of which took off in one time zone and landed in another, further complicating what is “local time”). -- RickyCourtney (talk) 01:46, 29 April 2025 (UTC)[reply]
There is WP:OTHERCONTENT with UTC listed first, but that alone is not a reason to prefer it especially when this matter didn't reach broad, explicit consensus in the past (plus after further examination WP:CCC). The other content does indicate that editors have determined a local time zone, and the MoS guideline is to prioritize it.
I don't think local time is that complicated. If launch and landing have a different local time zone, they are both used for their respective event along with UTC. Space Shuttle mission articles, such as STS-40 and STS-48 (two random picks), and Artemis I are examples of articles that take this approach. Redraiderengineer (talk) 02:47, 29 April 2025 (UTC)[reply]
I'd support adding an exception to the global style manual for spaceflight launches and landings: These should give UTC first and local time in parantheses. UTC is the most sensible when thinking about a space mission of which launch is only one part. However, local time is also relevant (e.g. night/day), so it should be given in parantheses. Perhaps an RfC is in order? Joe vom Titan (talk) 19:31, 29 April 2025 (UTC)[reply]
Do you count bold via ''' as markup? Which would violate "Not be wrapped in markup, which may break their display and cause other accessibility issues." Stepho talk12:03, 10 May 2025 (UTC)[reply]
It is markup (both wiki markup and HTML markup), but we do allow italics. Strictly, comments are markup and we often see things like CO2 in headings – which is markup added via a template! The sentence that you quote would make more sense without having the comma. Not all markup in headings causes problems. However, bolded text is a rather specific problem, so I feel we should add something explicit that covers it — GhostInTheMachinetalk to me12:58, 10 May 2025 (UTC)[reply]
Consider keeping romanizations in running text confirmation
Given I saw only mild apprehension at ensuring we don't accidentally incite sprees of rabid gnoming, and not concerns over the substance of my suggestion as I had it in my head, I'll courtesy ping folks and maybe splice this in if there's still no objection. Courtesy ping @David Eppstein, NebY, Michael Aurel, and Chipmunkdavis:
Be mindful that text in non-Latin scripts can interrupt the flow for readers who are unable to decipher it. When provided in running text, consider keeping non-Latin terms inside parentheses, while allowing the associated romanization or translation outside the parentheses to be read as a natural part of the surrounding sentence.
As a general rule for any kind of guidance on specific cases like this, I wonder if there is a conventional order, as in, do we do guidance first followed by justification, or justification first as you have it above? Adding an example sentence to the mix, I seem to think it is often 'G, E [,J]' (with J often left out) but I may be mistaken. If so, we might have:
When including text in non-Latin script in running text, consider keeping it inside parentheses just after the romanized equivalent:
The English word epic comes from [...] the Ancient Greek adjective epikos (ἐπικός), from epos (ἔπος), 'word, story, poem'.
This allows the reader to read the English text outside the parentheses in a natural way.
No doubt the wording could be further improved, but this is easier to grasp for me, as when reading a guideline, I want to consider what it is telling me, then I want an example to see what they are talking about, and at that point, I start to wonder why, and then comes the justification, feeling just like the coda on a musical piece and sewing it all together. Or, maybe I am dreaming, but that's how it feels to me. (As a further, albeit quite minor point, this allows the explanation to end at the original indent position, which seems to provide a more orderly transition to whatever topic the next paragraph is about if there is no section heading above it.) Mathglot (talk) 18:56, 18 May 2025 (UTC)[reply]
Talk:Remember Monday#IS or ARE debate is probably a problem for multiple bands' pages, and Wikipedia's Manual Of Style should address it somewhere, but if it's already there, i don't know how to find it. A trio performs as Remember Monday, a British band. One edit summary i found claims that British English would say Remember Monday are a girl group rather than Remember Monday is a girl group, to which i say: [citation needed].
(Funny thing: "A trio performs", "The trio performs", and "The trio perform" all seem all right to my American English ears, but "A trio perform" seems wrong. Logic protests.)
It has been my impression that British English (BrE) uses are here and American English (AmE) uses is. Garner's Modern English Usage largely confirms this but does complicate the matter. You can read the full entry on this here with a Wikipedia Library login. Garner notes that BrE is more likely to use 'the plural (are, in this case) here and AmE is more likely to use the singular (is) but neither is universal and there are cases where AmE will use the plural to emphasize the members of a group. Garner calls for consistency within a piece of writing but notes that even edited, published sources are not always consistent. Here is an excerpt:
Apart from the desire for consistency, there is little “right” and “wrong” on this subject: collective nouns sometimes take a singular verb and sometimes a plural one. The trend in AmE is to regard the collective noun as expressing a unit; hence, the singular is the usual form. When the individuals in the collection or group receive the emphasis, the plural verb is acceptable <the Freudian school were not wholly in error>. But generally in AmE, collective nounstake singular verbs, as in the jury finds, the panel is, the committee believes, the board has decided, etc.
The usage note Choosing Agreeable Verbs for Collective Nouns from Christian Science Monitor also discusses the two approaches. I don't think our MOS should dictate a universal rule but I would mostly treat this as an ENGVAR issue and aim for consistency within a single article, while allowing for some flexibility in particular use cases. Curious what experienced style-guiders think. --MYCETEAE 🍄🟫—talk21:52, 18 May 2025 (UTC)[reply]
Thanks for the replies. i'm sure MOS:ENGVAR prevails, but apparently i didn't examine it closely enough: the Wikipedia:Manual of Style#National varieties of English section links to (and thus includes by implication) MOS:PLURALS, which does describe the grammatically acceptable use of notional agreement... without naming or linking to the notional agreement page, which maybe it should.
This is an odd one. My initial instinct was that an en dash should be used, not a hyphen, but upon double-checking MOS:DASH, I'm not so sure. Although we normally use an en dash in compounds when the connection might otherwise be expressed with to, versus, and, or between, this is not connecting two place names like Minneapolis–Saint Paul but rather repeating the same place name twice (unless the second "New York" refers to the state, which would be an odd use of a hyphen or dash, but I couldn't find information on the origins of the name in the article or online). Use an en dash for the names of two or more entities in an attributive compound would seem to support the use of an en dash, but again, it is technically the same entity and I'm not confident this classifies as an "attributive compound". We could also easily shorten the name to New York-New York (and probably should, per WP:CONCISE and WP:COMMONNAME), in which case, we are advised to use a hyphen in compounded proper names of single entities. I guess it just looks strange to use a hyphen because we usually use an en dash when applying a prefix or suffix to a compound that itself includes a space, but this isn't a prefix. This reads like New / York-New / York rather than New York / – / New York, and "York" obviously doesn't modify "New". Thoughts? InfiniteNexus (talk) 21:53, 23 May 2025 (UTC)[reply]
How do independent sources that discuss this hotel/casino present the name? Do they “correct” the dash, or consider it “part of the name” and leave it. I would especially be interested in exploring sources that we trust to usually get stylization right - to see if they make an exception in this case. Blueboar (talk) 22:40, 23 May 2025 (UTC)[reply]
Should we be looking to third-party sources for this? Many sources don't use en dashes at all in accordance with whatever style guide they follow (e.g. AP); we have our own style guide. So I don't think this is a matter of COMMONNAME. In any case, a cursory search on Google Books shows wild inconsistency, ranging from spaces to commas to slashes (and many false positives). InfiniteNexus (talk) 22:51, 23 May 2025 (UTC)[reply]
I think you have answered my question - since we don’t see other sources making an exception to their own style guides for it, then neither should we. Blueboar (talk) 00:24, 24 May 2025 (UTC)[reply]
When I said "many sources don't use en dashes at all", I was not referring to this instance in particular, I meant in general. Some style guides do not use en dashes in any scenario, including cases where our style guide would call for them. InfiniteNexus (talk) 00:34, 24 May 2025 (UTC)[reply]
Never look to sources on style issues. Sources are for facts, not style. External style guides can influence our MoS, but they are only one of multiple factors to be considered. Any mention of style guides should be in the context of proposed changes to our MoS, not individual cases. ―Mandruss☎ IMO. 00:38, 24 May 2025 (UTC)[reply]
That said, damn the hotel owners for unnecessarily creating such a conundrum for Wikipedia's MoS wonks. "New York Hotel and Casino" would have done just fine, and readers could just deal with any ambiguity between that and Sydney's New York Hotel. I'd be inclined to use the hyphen and call it a day; it's just not that critical. ―Mandruss☎ IMO. 01:01, 24 May 2025 (UTC)[reply]
hello! i was wondering if there's a specified order for templates on the talk page? it seems a bit haphazard article-to-article and i can't find any reference to policy about it. is it safe to assume that since it doesn't tend to matter that much there's no interest in it?--Plifal (talk) 08:36, 27 May 2025 (UTC)[reply]
