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: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".
Talk:Bolognese School#Requested move 26 July 2024 (14 articles) – Lowercase school for "schools" of artistic styles of painting that are not the names of actual institutions? Result: Lowercase except two that were found frequently uppercased in sources
Talk:War of 1812/Archive_29#Capitalisation of "house" and "senate" – as stand-alone terms in prose. Result: Not a formally closed discussion. In summary, shortened forms of names for institutions are not capitalized unless they are "a shorter but still specific form", not just a single generic word. The material at MOS:INSTITUTIONS probably could be clarified on the question, as this isn't the first time the matter has come up.
Talk:Hurricane Alley#Requested move 11 July 2024 – Call this the "Main Development Region" or "Main development region"? Result: "Main Development Region" without prejudice against considering "Main development region"; new RM opened.
Talk:Popverse#Redirect templates – Should the "avoided double redirect" tag to applied on a correctly capitalized redirect when there's a similar but miscapitalized redirect? Or should only the miscapitalized one be so tagged? Result – Removed tag from correctly capitalized Popverse as inappropriate, and left it on PopVerse which is miscapitalized.
Talk:IMP.#Requested move 9 June 2024 – All-caps for this shortened form of "Impactors"? Result: All-caps retained since sources seem to do that.
Talk:Pied-Noir#Lowercase – Lowercase "Pied-Noir" (or use "Pied-noir" or "Pieds-Noirs" or "Pieds-noirs" or "pieds-noirs")? Result: Lowercase "noirs", leaning lowercase for "pieds" as well.
Talk:Toy boy#Requested move 17 December 2023 – Should lowercase indicate a boy that is a toy rather than the title of some published works? Result: Yes; disambiguation moved to uppercase.
WT:WikiProject Freemasonry#Capitalization – Where do we draw the line of capitalization of offices and such in Freemasonry? Result: Some say just follow MOS:OFFICE, others want to follow Freemasonry's conventions. No clear consensus.
Talk:NTV Plus#Requested move 15 September 2023 – Is all-caps an appropriate distinction between Russian and Nepali TV channels? Result: No; use ordinary title case for proper name, not all-caps.
Talk:Sangaku#Capitalization: is the article title just an ordinary Japanese word borrowed into English, or a proper noun? (note – while the discussion was not formally closed, all instances are now in lowercase
Talk:Welsh Revolt#Requested move 30 July 2023 – Initially Welsh Revolt → Glyndŵr Rebellion but subsequently a question of capitalising the second word in any choice. Result: Lowercase "rebellion".
Talk:In Search of...#Requested move 10 October 2022 – Should the "of..." become "Of..." because it is the last word of the title? (a two-article RM) Result: Retain lowercase since truncation of a longer title is implied.
Talk:Lost Decades#Requested move 7 July 2022 – Lowercase "Decades", among other issues? Result: Not moved. The closer commented about primary topic status but did not comment about capitalization.
User talk:Snickers2686#MOS:JOBTITLES – "until [JOBTITLES is] applied consistently, which it isn't in this set of articles, then to me, it doesn't apply at all". – judges generally lowercased
Talk:National Historic Landmark#Requested move 18 January 2022 – Multimove to lowercase for "National Historic [Capitalized singular]", "National [Capitalized plural]", and "List of Historic [Capitalized plural]"? Result: Withdrawn after near-unanimous opposition to the central principle based on the linguistic concept of a proper name, noting consistent capitalization in sources.
Talk:g-force#Requested move 7 January 2022 – "g-force" or "G-force"? Result: RM procedurally closed (made no difference) and usage in article prose already changed to "g-force".
2021
RMs on capitalization of "Attorneys" and "Ambassadors" (or rephrasing to avoid the plural formal title): – all downcased
WT:AT#RFC on dash-separated titles for sports events 2 January 2022 – Capping of "Men's Singles" and "women's doubles"? Result: No consensus to ban dashes, no consensus on capitalization; consensus that capitalization should be worked out at WikiProject Tennis.
MOS:ZH has a guideline that Chinese characters should not appear in running text, proposing that readers only comfortable with the Latin script should generally be able to read sentences aloud (omitting any parenthetical call-outs) without hiccups:
My only worry is that those with little exposure to either the topic at hand or to language studies in general may not intuit that the native form is just that, if it is not given clear preeminence.
Typically this may be lessened when forms appear in native–romanization order early, e.g. with the translated title topic in the lead sentence? Remsense ‥ 论15:58, 31 March 2025 (UTC)[reply]
I kind of expect Chinese to have transliteration first, potentially followed by characters, but I also expect Ancient Greek to have Greek alphabet first, possibly followed by a transliteration. Allowing Greek script but not Chinese script in the text may of course just reflect the bias of my somewhat classical education (and I kind of expect educated people to know Greek letters but not Chinese characters), but I would not want to have a rule that dictates we need to do it in the same way for all languages when this goes too much against scholarly convention. Consistency is always only local (if everything on Wikipedia follows the same rules it is usually inconsistent with the way everybody else uses the same words), so I do not value it very much. —Kusma (talk) 20:29, 31 March 2025 (UTC)[reply]
I searched for a Greek example as a deliberate steelman, picking the least dissimilar non-Latin script. If anyone wants evidence in the wild I'll go find it, but also picture Russian, Hebrew, Arabic, Tamil etc. in your mind's eye.
Essentially, I find myself making this fix across many articles. It often seems to read more amiably, even in Greek. Remsense ‥ 论22:06, 31 March 2025 (UTC)[reply]
It's hard to see any justification for transliteration not coming first. This is about basic accessibility for the vast majority of English-language readers. I'd go as far as saying the answer should be obvious to us all.DeCausa (talk) 22:16, 31 March 2025 (UTC)[reply]
Let the person making the sentence do what she thinks best. Nobody notices or cares if its done differently in different articles and neither is objecectively better. (Internal consistency within an article is different, but that is covered by the rule "For any debatable construction, if there is a consistent version used in the article, follow it" or whatever, which I assume we have such a rule or we had better have. Since the reader doesn't care or even notice, any rule about this particular issue would be solving a problem that doesn't exist, and just gives editors overly concerned about consistency justification for going around changing it to no gain. Herostratus (talk) 02:11, 3 April 2025 (UTC)[reply]
I wouldn't've posted this barring the thesis that is there is a meaningful distinction, suggested by the fact that people generally read linearly, and interruptions of unfamiliar/functionally illegible elements in running text aggregate to make reading more difficult. If you don't think there's anything to that, that's fine, but I would appreciate acknowledgement that I'm not merely seeking to make more work for editors to do. Remsense ‥ 论02:27, 3 April 2025 (UTC)[reply]
Fwiw I agree with Remsense; I think this is a problem that exists and that Latin script text should be preferred when possible. It's functionally a de facto rule already imo; putting non-Latin text first is an exception rather than the norm. I've seen few cases where non-Latin first could be justifiable. seefooddiet (talk) 03:18, 3 April 2025 (UTC)[reply]
This might be in conflict with MOS:FOREIGNEQUIV; the example given there is is of a name that's fairly similar in anglicised form and when transliterated but some of our articles have greater differences, so we go from Rhodes to Helen of Troy to Metropolitan Cathedral of Athens.
Even if it only applied to text after the first sentence, it might affect a lot of articles and peeve a number of editors when applied, so I'd suggest advertising it fairly widely and more clearly than the brief non-canvassingly neutral note I put at WT:CGR,[2] which I fear might not have made sense to anyone. Maybe an RFC? NebY (talk) 18:30, 3 April 2025 (UTC)[reply]
I think that, specifically in the case of Greek etymologies of English words (example Icosahedron), it would be incorrect and misleading to state the transliteration as the root of the word, with a parenthetical gloss stating the actual form of the root. We should state the root itself in running text in Greek script with a Latin-script gloss. —David Eppstein (talk) 19:17, 3 April 2025 (UTC)[reply]
It would be awkward to formulate this rule with any cut-out, though it seems clearly incorrect if this were the case with, say, Hebrew. If people feel likewise I'm happy to drop this idea. Remsense ‥ 论19:30, 3 April 2025 (UTC)[reply]
Hebrew characters in running text are an absolute requirement for some mathematics articles like continuum hypothesis. Greek characters in running text are similarly required for articles like pi and golden ratio. In these cases, the characters are mathematical notation rather than parts of words, but they are still non-Latin-script characters in running text. —David Eppstein (talk) 21:03, 3 April 2025 (UTC)[reply]
Well, of course. Maybe I didn't articulate my position clearly enough, but those cases are clearly entirely outside the bounds of what I mean to suggest. Remsense ‥ 论21:11, 3 April 2025 (UTC)[reply]
I generally place the transliteration first when mentioning Greek words in running text, for the reason you've stated (reading without hiccups). I'm not necessarily sure that it should be explicitly recommended, though, and there are at least a few cases where I think having the Greek text first would be preferable. Stating, for example, that "the Greeks inscribed [insert transliteration here] on a tablet from ..." wouldn't be all that accurate, and particularly for more crude inscriptions the shapes of the letters might be important. Having the Greek text first would also be the better choice in a discussion of an ancient Greek manuscript's degeneration, or for illustrating a lacuna in a manuscript, and I could see that in some etymology sections editors might want to use the Greek text first. This isn't to say that it's not good advice in general (it is), but I suspect there might be more exceptions than initially thought, and editors in niche areas might find that such a guideline (if too absolute or all-encompassing) might be a source of irritation. – Michael Aurel (talk) 05:24, 4 April 2025 (UTC)[reply]
Maybe something as simple as Be mindful of the potential for non-Latin scripts to interrupt the flow of reading for those who are unable to decipher them. In running text, consider placing the native non-Latin terms inside parentheses when they are needed, with a corresponding romanization or translation placed outside the parentheses and forming part of the sentence. That's too wordy as a first pass, but I wanted to at least concretize a tad. Remsense ‥ 论05:45, 4 April 2025 (UTC)[reply]
Michael Aurel's exception examples are ones where the actual form of the written word is relevant, I would expect them to apply for Hebrew, Chinese, and other languages too. CMD (talk) 06:49, 4 April 2025 (UTC)[reply]
If we do want to add something about this (and I wouldn't say I have strong feelings on whether or not we should), then a passage along those lines seems fairly sensible. – Michael Aurel (talk) 15:48, 4 April 2025 (UTC)[reply]
That was my thought. I spent a lot of time hammering out this prose, and still am never quite sure when to use dashes versus colons in articles where a lot of statements qualified by lists are made. I guess I have a clearer sense not to use a colon when it would look this strange. Remsense ‥ 论22:53, 9 April 2025 (UTC)[reply]
I just realized that I avoid colons, except when introducing a list. Don't know if it's the influence of some childhood teacher or what, but using them between two independent clauses just reads wrong to me. I mean, I know it isn't technically wrong, just somewhere through the years I absorbed a disapproval of them. My personal quirk, I guess. Schazjmd(talk)23:27, 9 April 2025 (UTC)[reply]
Unable to justify colons, I am left largely to use dashes, which I have previously feared I overuse. In these instances, semicolons don't read as connecting the two thoughts strongly enough—in dense, technical prose, those more explicit logical connections seem pretty conducive to easing reader comprehension. Remsense ‥ 论23:33, 9 April 2025 (UTC)[reply]
I agree that it matches MOS:COLON, but in my experience, lower-case is commonly used in such cases even when a complete sentence follows. So I would tend to make the "start it with a capital letter" rule optional for such cases. Gawaon (talk) 15:28, 10 April 2025 (UTC)[reply]
Remsense, I would disagree regarding the capitalisation after the colon in the example in some cases. As a general rule, shorter sentences are a more readable style. If it is indeed a complete sentence after a colon, it should probably be written as a separate sentence. Cinderella157 (talk) 23:51, 10 April 2025 (UTC)[reply]
I think that many of those sentences where the dash is used could be split into a separate sentence following the dash (ie omit the dash). An exception would be where the dash is followed by for example. Just my thoughts. To your initial question, I would only cap after a colon where it was a complete sentence as a quote or perhaps: [T]he quote can be treated as if it were a complete sentence even if it was part of a longer sentence in the original text but end with a period or elipses as appropriate.Cinderella157 (talk) 02:07, 11 April 2025 (UTC)[reply]
Judging by Fowler (4th ed.), this is something which varies between British and American English: Note that in British English the word following a colon is not in capitals (unless it is a proper name), but in American English it is capitalized if it introduces a grammatically complete sentence. I live in a country where British English is predominant, and I wouldn't ever use a capital letter after a colon (except when needed for other reasons). – Michael Aurel (talk) 06:18, 11 April 2025 (UTC)[reply]
Procedural close: per several people below, the framing here will make it very difficult to determine consensus. Feel free to revert me if you like, but I strongly suggest starting a new RfC without simply inaccurate claims like Consensus is currently to treat the threshold for such as about 90%. Extraordinary Writ (talk) 17:10, 13 April 2025 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
For multiword page titles, one should leave the second and subsequent words in lowercase unless the title phrase is a proper name that would always occur capitalized, even mid-sentence. (Consensus is currently to treat the threshold for such as about 90%.)
For multiword page titles, one should consider what sources use, particularly midsentence. If a substantial majority of sources (defined as about [depends on option]) leave the title capitalized, the title phrase can be considered a proper name in most cases. If that substantial majority is not reached, leave the second and subsequent words in lowercase.
Support, ideally option C or D as proposer. My reasoning is explained at this village pump thread. I originally supported a more radical version (instead of 70%/two-thirds, 51%), but the comments there and at the original discussion have persuaded me to adopt a more moderate stance with a greater chance of passing. TL;DR: Ignoring the vast majority of sources to uphold some editors' interpretation of grammar rules goes against the fundamental principles of Wikipedia. 🐔ChicdatBawk to me!10:43, 13 April 2025 (UTC)[reply]
It ignores the majority of sources. If four out of five sources use uppercase, we use lowercase. This goes against our core principle of following the sources. 🐔ChicdatBawk to me!12:04, 13 April 2025 (UTC)[reply]
Oppose: There are no circumstances under which a word or phrase should be treated as a proper noun/phrase in a title but not in body text. Any guidance as to whether to treat something as proper, including consensus thresholds, ought to be at MOS:CAPS, more specifically at MOS:PROPERNAMES, not MOS:NCCAPS. Largoplazo (talk) 12:05, 13 April 2025 (UTC)[reply]
Bad RfC per Gawaon, there isn't any "status quo" 90–95% threshold in the relevant policies. Beyond that, Oppose having separate thresholds for title and body (which would only lead to inconsistencies), although I wouldn't be opposed to a RfC establishing a slightly lower threshold for both. Chaotic Enby (talk · contribs) 12:24, 13 April 2025 (UTC)[reply]
^ This. The RfC based on so many wrong premises, not least of which is setting an arbitrary numerical threshold for something that shouldn't use one. It ought to be called off ASAP. Toadspike[Talk]14:47, 13 April 2025 (UTC)[reply]
Oppose. Our MOS often incorporates best practice as seen in other style guides or in some sources, but like any style guide which provides a degree of consistency in publications, it has to dare to settle on choices which some will see as arbitrary or going against common practice elsewhere. We don't use the same spelling, units of measurement or representation of numerical values as our sources, switching from paragraph to paragraph or article to article; we follow our own MOS. This saves us from considering whether the sources are RS for style as well as content – this proposal would have us counting antique sources with modern ones, tabloid newspapers with academic journals, and British English with American and Indian. TL;DR: Wikipedia presents content in its own way, and that's fundamental. NebY (talk) 13:22, 13 April 2025 (UTC)[reply]
Oppose: First there absolutely should not be different criteria for capitalization in article titles than in running text (except for the first letter). It invites a mess and would be a major change which would benefit no one. Second, Wikipedia style is to capitalize for proper names and acronyms. That is the style we've chosen and as determining exactly what is a proper name is difficult, we use other sources as a guide to determine what is and is not a proper name. We don't just follow other publications' capitalization because other sources capitalize for other reasons. Many capitalize all headings or article titles. Many capitalize for importance in a topic area. Many sources capitalize for no apparent reason. I see no reason for change. SchreiberBike | ⌨ 17:14, 13 April 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Do they actually make the person seem more important? I suppose they might, depending on the reader. Is it important to an encyclopedic article? My guess is it would depend on the context, but this is not really my field of interest or expertise. A basic rule of thumb might be "If you can wikilink it you can mention it, if not, have a good reason why it is worth mentioning". Cheers, · · · Peter Southwood(talk): 07:58, 14 April 2025 (UTC)[reply]
In some instances I think the notability of the award and the award giver is collapsed into a single basis for notability, such that there should not be separate articles on the two. If there is an article on an award giver that substantially mentions the awards that they give (which is probably the case with some film critics organizations that give film awards), I think that would suffice. BD2412T21:04, 13 April 2025 (UTC)[reply]
I really could use some context. The only more fully expressed questions underlying yours that I can come up with would belong at WP:N instead of here. Largoplazo (talk) 21:11, 13 April 2025 (UTC)[reply]
An example:"In 1981, They Came Before Columbus received the "Clarence L. Holte Literary Prize". Sertima was inducted into the "Rutgers African-American Alumni Hall of Fame" in 2004. "
I guess I can see how the question might be suitable here, if the question is whether to mention the award in an article about a person whose notability is established through other criteria. It just made me think of cases I've frequently encountered where a list of awards seems to be the article creator's basis for imputing signficance/notability, yet none of the awards are notable. That's why I had WP:N in mind. Largoplazo (talk) 11:57, 14 April 2025 (UTC)[reply]
If this is a question about triva/cruft, then as a general rule they should be avoided. However, it is easy imagine how a non-notable honor/award (being awarded a scholarship?) might play a significant role in someone's life, and thus be worth a mention in a biography. Does Aurelian being named Restitutor Orientis count as an honor? What seems important is that the honor/award is remarked upon as significant by secondary sources. Sources from the subject or the award body shouldn't mean much. CMD (talk) 07:23, 14 April 2025 (UTC)[reply]
I am pretty confident that in the last 10 years we had a centralized discussion that awards and honors (not just film) should be notable (not necessarily a standalone page, just being able to show that the general body of those awards could be documented with non-primary sources), as it was creating excessive fluff on some bio and other creative work pages to include every no-name award. Unfortunately, I can't find it easily. Masem (t) 12:16, 14 April 2025 (UTC)[reply]
So maybe work towards making it a guideline? I know I, clearly mistakenly, remove awards etc if they don't have their own article or very clear notability. Doug Wellertalk15:24, 14 April 2025 (UTC)[reply]