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.
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]
How do you feel about the current revision? I mostly replaced the problem colons with dashes, but also a semicolons and some splits into separate sentences. Remsense ‥ 论00:16, 11 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]
RfC on NCCAPS capitalization threshold
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%.)
Proposed wording
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.
Option A: Status quo; 90–95% capitalized.
Option B: 75–80% capitalized.
Option C: 2/3–70% capitalized.
Option D: 60% capitalized.
Discussion
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]
Animal pronouns
Does the manual of style say anyting about pronouns for individual animals? Should we use 'it' or 'he/she'? I've had a look at a few featured articles (Laika, Easy Jet (horse) and Knut (polar bear)) which all use he/she pronouns but can't find anything on the manual of style or something. ―Panamitsu(talk)02:51, 14 April 2025 (UTC)[reply]
From English personal pronouns: Animals are often referred to as it, but he and she are sometimes used for animals when the animal's sex is known and is of interest, particularly for higher animals, especially pets and other domesticated animals. -- Michael Bednarek (talk) 03:31, 14 April 2025 (UTC)[reply]
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.
Proposal to clarify which MOS guidelines apply to citations
Presently guidance that clearly applies to citations is scattered among "Citing sources", "Manual of Style", subpages of "Manual of Style", and a host of guidance that might or might not apply to citations. When I think of any printed style guide I've ever seen, including "APA Style" and The Chicago Manual of Style, the table of contents makes clear it that there are separate parts, or chapters, to address citation style; the style used for everything but citations is addressed in different parts or chapters. I believe Wikipedia should do the same, and designate "Citing sources" as the primary home for citation guidance. Other pages that contain citation guidance should be listed within "Citing sources".
I also suggest that "Citing sources" be added to the "Manual of Style" (MoS) sidebar within the "Manual of Style".
I suggest accomplishing this by adding the following section:
Citations
Ordinarily, information about placing and formatting citations, and the content of citations, is found in the "Citing sources" guideline, as well as information about tools to assist with citations. That guideline states that
Editors expect to find information about citation format and style in "Citing sources" and should not be expected to be aware of citation guidance contained in this guideline, or in subpages of this guideline (for example, "Manual of Style/Legal"). Whenever guidance in this guideline or subpages of this guideline about citations exists, that page should be listed in the "Citation style" section of "Citing sources".
I don't think the last proposed paragraph is needed. If citation guidance is going to be centralized in one page (which can branch out to others), then any contravening guidance should be removed from other locations. Backlinks from other pages to the central page can be added. isaacl (talk) 17:20, 22 April 2025 (UTC)[reply]
Without the last paragraph, there isn't a clear statement that the guidance is centralized. Can you suggest alternative wording? Jc3s5h (talk) 19:56, 28 April 2025 (UTC)[reply]
To respond more specifically to the proposal above:
"Ordinarily", editors expect to find citation-specific content in WP:CITE and some general, widely applicable style advice (e.g., "avoid all-numeric date formats other than YYYY-MM-DD"). "Ordinarily", editors do not expect to find detailed information about style questions (e.g., MOS:FRAC, which rarely comes up in a citation, but which still applies if it does.)
It is generally true that editors "should not be expected to be aware of" just about anything in the MOS, but that doesn't mean that the MOS doesn't exist or doesn't apply. About three-quarter million registered editors make 1+ edits each year. WP:MOS gets about a quarter million page views each year. Ergo, an actual majority of editors aren't reading WP:MOS. But "should not be expected to be aware of" doesn't mean that you're exempt from it; if you do your best to communicate about the source, and someone else invokes "OBSCURESTYLERULE § EXTREMELYRARE" and fixes it for you, then that's fine. There shouldn't be any sort of games about whether the MOS page says that it applies to citations, or if the WP:CITE page officially lists that MOS page in a designated section. WhatamIdoing (talk) 19:33, 23 April 2025 (UTC)[reply]
I agree with WhatamIdoing; their list of examples of MOS guidelines that apply to citations without specifically mentioning citations pointed out that a huge portion (maybe most?) of the MOS would need to be mentioned as applying to citations. I think it is enough to just point out that the MOS as a whole exists and should be followed in citations to the degree applicable, as we now do. Yeah, our pages are organized differently than other style manuals, but they are not crowdsourcing their rules from a worldwide community of volunteers.
I have definitely found some places where cross-references are needed between specific guidelines that conflict or need to be kept in sync, and added them. There's probably room for improvement, though I know too much about the MOS to figure out what confuses newcomers the most. (Suggestions welcome.)
I also agree it's fine and historically nearly ubiquitous that editors ignorant of the MOS make additions to articles and other editors come by and tidy it into compliance. I actually work a lot on automating this process as well as spell check, and I think we are improving our quality as time goes on. Simply the act of bringing existing contributions into compliance can also help a lot; most people just copy the style of what they see already written, and if that's already MOS-compliant they don't need to do a lot of MOS research to know what to do in most cases. (That's probably an argument for adopting a single house citation style.) -- Beland (talk) 01:21, 24 April 2025 (UTC)[reply]
The status quo is good enough: At Wikipedia:Citing Sources#Citation style we find the text: "citations within any given article should follow a consistent style, and applicable Wikipedia style guidelines should be followed." This implies that the entire style guide applies, notwithstanding obvious exceptions. Adding a long list of links to sections of the style guide will only serve to confuse, create more conflict and keep editors busy updating that list. A comprehensive list will cover like half the style guide, as WhatamIdoing illustrated here. In principle it might be sensible to link to particularly relevant sections of the style guide but IMHO the one link to MOS:ALLCAPS in Wikipedia:Citing Sources#Citation style is sufficient. I do not buy the argument that people who edit citations don't need to check the style guide. After all, people who edit citations typically also edit the prose which should ideally adhere to the style guide. An extra set of style rules for citations is the last thing we need. Joe vom Titan (talk) 18:58, 29 April 2025 (UTC)[reply]
My take: 99% of the time, no one will object (or care) if you edit an article to comply with an MOS. However, that leaves the 1% where someone does. When someone objects, my advice is to back off a bit … find out why they are objecting, and discuss it with them. Remember that all of our MOS pages start with a disclaimer that says “occasional exceptions may apply”. Blueboar (talk) 13:56, 24 April 2025 (UTC)[reply]
Am I the only one that was taught the opposite of what the manual of style currently says about spacing around dashes? I was taught that there is no spacing around an n-dash (e.g., "pages 1–20"), but that there are spaces around an m-dash — as is demonstrated here. I ain't no English teacher, so I'll yield to anyone with that sort of certificate, but the current text of the manual of style seems mighty backwards to me. —Quantling (talk | contribs) 14:01, 22 April 2025 (UTC)[reply]
To be clear, yes, the MOS is correct, but no, it does not concur (agree) with what Quantling says they've been taught, which I've never heard anyone say. Carlstak (talk) 05:54, 29 April 2025 (UTC)[reply]
Nevertheless, it is of course also correct that no spaces are used around en dashes in ranges just as "pages 1–20". Just to state the obvious. Gawaon (talk) 15:52, 22 April 2025 (UTC)[reply]
Ah, it appears that I was taught the method used by The New York Times — spaces around an m-dash, which is used for breaks in sentences, but no spaces around an n-dash, which is used for ranges. But other publishers, including Wikipedia, have chosen differently, at least in some cases. I guess that I will have to adapt. —Quantling (talk | contribs) 17:21, 22 April 2025 (UTC)[reply]
While folks are here, could I ask really quick as regards ENGVAR considerations? Per Talk:Isidore of Seville (courtesy ping User:Carlstak)—apparently there's a notion that spaced en dashes are preferred over em dashes in BrE? I wasn't aware of this, but am not sure to what extent this is considered the case onwiki or off. Remsense ‥ 论05:45, 28 April 2025 (UTC)[reply]
Personally I hate the closed em-space style because it looks more like it is joining things (like hyphens do) rather than separating them. But that's just a personal opinion. Stepho talk06:53, 28 April 2025 (UTC)[reply]
Cards on the table, I started editing used to em dashes and have since come to distinctly prefer spaced en dashes, but I'm the one here that wasn't convinced there was any ENGVAR distinction at play (therefore generally falling back on MOS:VAR). Remsense ‥ 论06:58, 28 April 2025 (UTC)[reply]
Fowler and Burchfield were printed in the UK, bur spurred by your remark, I inspected a few more related books, and found that Brandreth's Pears Book of Words does use spaced en dashes and no em dashes, so it seems there are no absolutes either way. Nor does the Canadian Bringhurst's exhortations in a book printed in the US against Victorian aesthetics clarify the matter of BrE vs AmE. I think following our own style guide is the most sensible way for our writing. -- Michael Bednarek (talk) 01:36, 29 April 2025 (UTC)[reply]
FWIW I agree but I wanted to make sure I wasn't conceited by posting this—per MOS:COMMONALITY, famously a "key" through which one may unlock the entire text according to mainstream MOS hermeneutics—the last thing we want is to enshrine another necessary difference for editors to worry about, instead of allowing it to be commonly acceptable, if we don't absolutely have to. I still fail to see any evidence that we have to. Remsense ‥ 论01:44, 29 April 2025 (UTC)[reply]
My "notion" was derived from the Oxford University Style Guide, which I've cited directly below this comment. I should think we would use British Style guides to guide our editing in an article written in British English. Given the dictum to use the en dash "in a pair... surrounded by spaces" by the OU Style Guide, it seems odd that The New Hart's Rules: The Oxford Style Guide says:
"The en rule (US en dash) (–)... Many British publishers use an en rule with space either side as a parenthetical dash, but Oxford and most US publishers use an em rule."
and:
"The em rule (US em dash) (—)... Oxford and most US publishers use a closed-up em rule as a parenthetical dash; other British publishers use the en rule with space either side."
Therefore, I must concede that either usage would be acceptable in an article written in British English, Remsense, and the choice should be determined by the established style of the article. Looking back through the revision history of the Isidore of Seville article, it seems that em dashes are used for parenthetical dashes. So I yield the point, at least concerning that particular article.
As to the OP's question, regarding spacing around n-dashes and m-dashes, see The New Hart's Rules: The Oxford Style Guide quote directly above. Carlstak (talk) 05:50, 29 April 2025 (UTC)[reply]
Why African-American culture but not Middle-Eastern cuisine?
MOS:HYPHEN at point #3, bullet one instructs editors to never insert a hyphen into a proper name with the example Middle Eastern cuisine, not Middle-Eastern cuisine. African American is a proper name but the practice on Wikipedia is to hyphenate when this is used as a modifier, Cf. African AmericansbutAfrican-American culture. Is this covered somewhere in the MOS, and is this appropriate? African American is not really a case of MOS:DUALNATIONALITIES. African American culture seems more like Middle Eastern cuisine than Italian-Swiss newspaper but there may be a subtle distinction I can't quite put my finger on.
The current (18t) edition of The Chicago Manual of Style acknowledges that this has been subject to debate and makes allowances for author or publisher preference here but ultimately advises against hyphenating terms like African American because hyphenation does not aid in comprehension. (8.40: Compound nationalities; see also 8.39 where African American culture is used as an example, and further examples at 7.96 – subscription required). --MYCETEAE 🍄🟫—talk15:11, 22 April 2025 (UTC)[reply]
In "African American", "African" is an adjective, as can be discerned by comparing it to "Polish American" (not "Pole American"). So it's comparable to "high speed" > "high-speed chase" or "big box" > "big-box store", in which hyphens are used. I don't see why the capital letters would lead to a different linking punctuation mark to be prescribed. Largoplazo (talk) 16:14, 22 April 2025 (UTC)[reply]
Middle is also an adjective, with a secondary meaning/function as a noun. Its function in Middle East(ern) seems akin to its use as an adjective in middle seat or middle house in the row, except that eastern is also an adjective. The distinction I read in the MOS is that Middle East(ern) is a proper name, high speed is not. The Merriam-Webster entry for middle raises another example where middle can be part of proper names, in the names of historical language varieties like Middle Dutch. We wouldn't write the Middle-Dutch pronunciation of [X] or the Old-English word for [X]. We might write about a Swiss-German newspaper but notthe Swiss-German language. I analyze the first example as combining two proper adjectives (Swiss and German) into a compound modifier (Swiss-German), while in the second example Swiss German is a distinct proper name. --MYCETEAE 🍄🟫—talk18:11, 22 April 2025 (UTC)[reply]
"African American" and "Middle Eastern" are simply not analagous. One can speak of a multitude of people as African Americans but not as Middle Easterns. The morpheme tree (ignoring the morphemic breakdown of "African" itself) in the first case is African + (America + -an), not (African America) + -an, whereas in the second case it's (Middle + East) + -ern, not Middle + (East + -ern). Largoplazo (talk) 16:16, 24 April 2025 (UTC)[reply]
Thank you. I do see a difference that rationalizes African-American although I'm not convinced it is best. Curious if you would prefer Middle-East peace over the unhyphenated form. Or Han-Chinese people, Native-American religion? --MYCETEAE 🍄🟫—talk16:46, 24 April 2025 (UTC)[reply]
Also, your analysis treats African and American as two separate proper adjectives forming a compound modifier. However, African American is a distinct, two-word proper noun or adjective that is usually not hyphenated. In addition to Chicago, AP, MLA, APA, Merriam-Webster, Dictionary.com, and even OED use the unhyphenated form. How do we know when to derive a style from first principles following your analysis vs. when to follow MOS:HYPHEN's guidance against hyphenating proper names or widespread common usage and guidance against hyphenation? --MYCETEAE 🍄🟫—talk21:23, 24 April 2025 (UTC)[reply]
The only analysis in my previous comment is that "African American" and "Middle Eastern" are different constructions so they need to be considered separately, in contrast to your remark that African American culture seems more like Middle Eastern cuisine. They aren't, they're quite different. Largoplazo (talk) 22:05, 24 April 2025 (UTC)[reply]
Suppose there were an internet provider called High Speed. When referring to the company, we would write She upgraded her High Speed internet servicenotShe upgraded her High-Speed internet service because High Speed is a proper name. Just as when referring to Quantum Fiber, you would not write They pay for Quantum-Fiber internet. We also do not always hyphenate other commonly recognizable compounds, for example High school diploma, Parkland high school shooting, NBA high school draftees. And while you could probably find instances where sources do hyphenate those, for the shooting, we would never write Marjory-Stoneman-Douglas-High-School shooting because the school is a proper name. --MYCETEAE 🍄🟫—talk15:15, 24 April 2025 (UTC)[reply]
Thank you, I always forget about Wikipedia Library. This is a great resource. The section on phrasal adjectives has a "Proper nouns" section which states: "When a name is used attributively as a phrasal adjective, it ordinarily remains unhyphenated." Garner's does not hyphenate in phrases like Middle Eastern country and American Indian people when they appear in the text, even though these contain phrasal adjectives. Is the policy on African-American a special exception to the proper nouns rule or does it rely on another rule, stated elsewhere or left unstated, such as a rule like Largoplazo's based on how the adjective is constructed? If it's based on how the adjective is constructed, then American Indian appears to be an exception, perhaps to avoid confusion with Indian-American or because American Indians do not have dual ancestry. --MYCETEAE 🍄🟫—talk23:12, 27 April 2025 (UTC)[reply]
Because of the difference between combining nouns (use hyphen) and combining adjectives (don't). Maybe this illustration will clear it up:
Three dashing guys walk into a bar to discuss hyphens: one African, one American, and one African-American.
Three guys walk into a bar: one Middle, one Eastern, and one Middle Eastern.
Middle, Eastern, African, and American are all adjectives and all except for Eastern can also be nouns. I should clarify, I do understand that African-American is an acceptable variant. Wikipedia appears to be in the minority in preferring the hyphenated form. I see that there are different approaches that rationalize this form. I appreciate your contribution – it's an interesting example that highlights how these words can be looked at differently as nouns or adjectives and how that can impact a decision around this minor spelling/punctuation variant. --MYCETEAE 🍄🟫—talk04:00, 28 April 2025 (UTC)[reply]
Dates and times on Spaceflight articles
Hello, I was looking to get some clarity on how we should handle dates and times on Spaceflight pages.
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]
Proposal: expand the scope of ELNO to include "Further reading"
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]
