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 may fall under the contentious topics procedure and be given additional attention, as it may be closely associated to the article titles policy and capitalisation. 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
Latest comment: 4 months ago1 comment1 person in discussion
This section is pinned and will not be automatically archiveduntil 13:00, 2 June 2046 (UTC).
Add a link to new discussions at top of list and indicate what kind of discussion it is (move request, RfC, open discussion, deletion discussion, etc.). Follow the links to participate, if interested. Move to Concluded when decided, and summarize conclusion. Please keep this section at the top of the page.
Talk:Fun (band)#RfC on article tense – RfC (June–July 2025) on whether to refer to an inactive, but not apparently disbanded band in the present or past tense. Result: Modest participation discussion stalled, no conclusion.
RfC needed on issue raised at Wikipedia talk:Manual of Style/Biography/2024 archive#British peer titles in infoboxes (June–July 2004, archived without resolution). Presently, the royalty/nobility wikiprojects have imposed putting British peerage titles in place of names in biographical infoboxes, against MOS:BIO, MOS:INFOBOX, and the template's documentation. Either the community will accept this as a best practice and the guidelines changed to accomodate it, or it should be undone and the infobox used consistently and as-intended.
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:NEPTUNE#Requested move 23 April 2026 – is the all-caps a sufficient clue of which topic this refers to? Result: Yes, all-caps deemed sufficient to distinguish this ocean observatory from other topics
Talk:Bo En#Requested move 27 April 2026 – use all-lowercase for this artist's performing name? Result: Renamed to conventional artist name (not the stage name)
Talk:BOL4#Requested move 27 March 2026 – lowercase this musical duo name to "Bol4"? Result: Caps retained; it's not a word, and most sources seem to use all-caps
Talk:ROTS#Requested move 17 March 2026 – remove all-caps from the name of this disambiguation page? Result: Yes; only one topic uses all-caps, so that form is not ambiguous
Talk:Where is Thumbkin#Requested move 13 March 2026 – lowercase "thumbkin"? Result: No change of capitalization (lowercase "is" as an incipit, uppercase "Thumbkin" as a proper name personification), question mark added
Talk:The States#Requested move 17 February 2026 – move disambiguation page to lowercase and/or redirect "The States" to a primary topic? Result: Redirected both uppercase and lowercase to United States as primary topic; "(disambiguation)" added to disambiguation page
Talk:Nrx#Requested move 12 January 2026 – use all-caps for this disambiguation page name? Result: Uppercase, as nearly all listed topics are uppercased abbreviations
Talk:Major Labels#Requested move 27 July 2025 – is it sufficiently clear that this is an article about a book rather than a group of companies? Result: Not moved; title is suitable for a published work
Talk:Niviarsiat#Requested move 25 July 2025 – should either "Northeast Greenland" or "Southern Greenland" start with a capital letter? Result: The capitalization question is not relevant to the chosen titles
Talk:Blair Babe#Requested move 4 July 2025 – lowercase "Babe" or "Babes"? Result: uppercase retained (not the primary focus of the discussion and not commented on in the closing remarks)
Talk:F1NN5TER#Capitalization – Should the online persona be called "F1NN5TER", "F1nn5ter" or "Finnster"? Result: Discussion started 24 March 2024 went stale after comments on 4 April 2024 suggesting "F1NN5TER" to be the usual form
Talk:Fullbore target rifle#Major rework – Is it too risky to ask people who are carrying firearms to use lowercase? Result: lowercase "rifle" in most contexts, and other fixes
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".
Latest comment: 3 days ago4 comments2 people in discussion
I recently proposed a bot task for fixing approximately 82,000 instances on Wikipedia of commas being erroneously italicized after italicized terms (see, for instance, the comma after Pulse Weeklyhere; additional details are at the BRFA). One editor objected that the task is too minor to be worth doing by bot, so a BAG suggested I inquire here about whether or not there is consensus to proceed. Do you all consider this an error that'd be worth fixing by bot? Sdkbtalk06:01, 13 April 2026 (UTC)Reply
Because it's an AWB bot, it can be run alongside the general fixes set, so often the comma fix will not be the only change the bot makes.
My overall view is that, while it's certainly not the most earth-shattering change to a page, it is an improvement, and it's clearly in compliance with WP:COSMETICBOT because it changes the output HTML of the page. It is something that I occasionally notice as a reader. I'd like to get further input to establish a consensus about whether we can proceed. Cheers, Sdkbtalk01:11, 11 June 2026 (UTC)Reply
My understanding of Engvar in such cases is that the article should use the first identifiable variety of English. There is no exception for the article name if it's not a proper noun. If the first variety can be identified as American English then the page should not have been retitled with a British spelling, and vice versa. Dgp4004 (talk) 10:49, 21 May 2026 (UTC)Reply
Looking back to the page creation, it used the American spelling of 'defense' in the article body on creation:
Therefore, the article is in American English and the article title should conform to that (if the word 'defense' is indeed needed in the title), unless it can be shown that editors made a decision to change the English variety to British English or similar. Reading the talk page discussion you link to, I can see that some editors make a case for changing the variety to British English, as is their right. But unless they can achieve a consensus then it must remain in American English. Dgp4004 (talk) 10:55, 21 May 2026 (UTC)Reply
Oh scratch that! Apologies, I should have read the history fully. If the page adopted British English twenty years ago and nobody challenged or reverted it then I think that has to be considered a new consensus. The onus is now on the advocates of American spelling to make the case for changing to American spelling. But in the absence of such a consensus then the article should remain in British English, including the title. Dgp4004 (talk) 11:10, 21 May 2026 (UTC)Reply
Yes, if the same spelling was fairly consistently used for 20 years or so, that's a clear case of EDITCON, so changing it to anything else now would require talk page consensus. Gawaon (talk) 15:02, 21 May 2026 (UTC)Reply
Out of curiosity, is there a rule of thumb for how many years have to elapse before a new consensus is considered to be achieved? Dayshade (talk) 17:53, 22 May 2026 (UTC)Reply
No, and of course "consensus" in these cases is normally humbug - "nobody noticing or bothering to complain" is more like it. Johnbod (talk) 18:15, 22 May 2026 (UTC)Reply
Latest comment: 5 days ago12 comments8 people in discussion
According to MOS:QWQ, we should alternate between double and single quotation marks for nested quotes. However, what should be done if there are contractions within a nested quote? Example:
"He said to me, 'We don't need it' "
Contractions shouldn't be used in article writing, except for literal quotes (MOS:N'T). Should this edge-case contraction be changed to full writing (per MOS:CONFORM perhaps), or should it stay as above example since most readers would not find this confusing anyway? — TheThomanski|t|c|please ping me if you want me to respond!09:46, 8 June 2026 (UTC)Reply Edit: Y'all are being really passive agressive here, clearly it's not obvious if I make a topic about this. — TheThomanski|t|c|please ping me if you want me to respond!15:05, 8 June 2026 (UTC)Reply
Expanding a contraction in a quotation is out of the question. As you say "most readers would not find this confusing", so this seems like a solution in search of a problem. EEng10:42, 8 June 2026 (UTC)Reply
No new guidance is required. Contractions and quotations are unrelated topics. But perhaps this is another argument in favor of revisiting our guidance on curly quotes. pburka (talk) 14:58, 8 June 2026 (UTC)Reply
Re: "clearly it's not obvious if I make a topic about this"
Has this issue come up in a real article, or is this purely hypothetical? Both nested quotes and contractions are pretty rare on Wikipedia. We don't need rules for every possible obscure situation.
You also said "most readers would not find this confusing", so it seems like you're not confised by it.
It's generally easier to follow a conversation if you add new comments in the thread instead of editing your existing contributions.
Also re "clearly it's not obvious if I make a topic about this": what else could one do with contractions within a quote, whether nested or not? I don't get it. The only possible issue I see is whether MOS:CONFORM allows replacing contractions with the full form (it doesn't), but that's unrelated to nesting. Gawaon (talk) 15:34, 8 June 2026 (UTC)Reply
Re your addendum calling contributors "passive aggressive" and protesting "clearly it's not obvious": I was inclined to leap to your support ("It's obvious", "Clearly", etc. are usually unhelpful responses to someone who didn't find it obvious or clear) but then noticed that nobody had, up to that point, written that it was obvious. I see only people answering your question with conviction. Largoplazo (talk) 16:19, 8 June 2026 (UTC)Reply
The guidance should remain as-is and should not be adjusted for contractions. This is the normal convention and most readers will not be confused by it. Perhaps it slows reading occasionally but I didn't find the example you shared problematic even when I was primed to look for it. If usage in a particular case is especially problematic then the content can be reworked but I would not make a general recommendation to avoid contractions in nested quotes or to follow some special approach. Alternative approaches like brackets—"He said to me, 'We [do not] need it'"—are more jarring and more likely to slow readers down or distract them.—Myceteae🌈 (talk) 21:08, 8 June 2026 (UTC)Reply
I agree with the others. As a software developer I'm sensitive to the ambiguity of double or single quotes in each language in their uses as both string delimiters and punctuation within strings and the need to escape special characters when used for their conventional purpose, but I don't experience it that way when reading text. Largoplazo (talk) 21:15, 8 June 2026 (UTC)Reply
It looks as if OP wanted advice on a peculiarity they found in two articles, received it and dealt with the matter appropriately.NebY (talk) 21:22, 8 June 2026 (UTC)Reply
"Never put a space before a comma, semicolon, colon, period, question mark, or exclamation mark"
Latest comment: 4 days ago22 comments7 people in discussion
This sentence in MOS:SPACING was changed earlier today: the qualifier "In normal text" was removed. I added it back, but was reverted. There are legitimate reasons to put a space before these punctuation marks in technical topics, such as source code (a? b: c) or ratios (cement: sand: gravel). @FaviFake and Gawaon: FYI. pburka (talk) 15:39, 8 June 2026 (UTC)Reply
As is said in my edit summary, no reasonable person would ever read that sentence and think it also prohibits using a space in source code or mathematical formulae. It is just an unnecessary qualifier, as Gawaon said. There are hundreds of other provisions in the MOS which obviously don't apply to technical topics. FaviFake (talk) 15:42, 8 June 2026 (UTC)Reply
That's fair (I hadn't noticed your intermediate version and edit comment before), but we do make explicit exceptions for technical usage elsewhere in the same section (e.g. "Except in technical usage (a 3:1 ratio), no sentence should contain multiple colons, ...."). This seems a bit inconsistent. pburka (talk) 15:53, 8 June 2026 (UTC)Reply
Lots and lots of people lacking your acute powers of reason edit Wikipedia. And then they come and complain about things like "User:Jojojojo874523 wrote a? b: c but the Manual of Style says not to put spaces in front of question marks and colons". If it were tremendously burdensome to have the words "in normal text", we'd have to weigh the pros and cons, but I see the presence of those words as involving zero burden. Alternatively, it could read "when used as punctuation" to distinguish that case from the use of those symbols as operators, but that seems unnecessarily technical and I'm not sure whether it buys any advantage over "in normal text". Largoplazo (talk) 16:07, 8 June 2026 (UTC)Reply
involving zero burden When I read it, I thought: "Wait, if this says to only do it in normal text, does that mean the rest of the paragraph also applies non non-normal text?" And of course the answer is no, because you can and should use multiple spaces in source code excepts, for clarity and indentation. So should we add that disclaimer to the first paragraph as well? (The answer is, of course, no) FaviFake (talk) 16:55, 8 June 2026 (UTC)Reply
So put a note at the top of the Punctuation section or the top of the page. I don't see what you find so terrible about it. Simply thinking it's unnecessary doesn't equate to expressing such revulsion over it. Largoplazo (talk) 18:06, 8 June 2026 (UTC)Reply
I removed "in prose" because I found it unnecessary and ambiguous – some people consider lists and headings not to be prose, yet the rule still applies to them. I also agree with FaviFake that much of what the MOS says doesn't apply to source-code examples, but we rarely state that explicitly, so why make an exception here? Common sense applies. Gawaon (talk) 18:07, 8 June 2026 (UTC)Reply
Exactly.
New content added to this page should directly address a persistently recurring style issue
The "In normal text" proviso predates the "New content added to this page" proviso. See , for example. Therefore, we aren't talking about adding new content to this page, we're merely talking about moving existing content to the proper level at which it applies, to address your observation that it's applicable to much more than the level it's at. Largoplazo (talk) 18:51, 8 June 2026 (UTC)Reply
Another reason to do this in text that is not "normal text": Standard French orthography uses spaces before;:!? and so this is needed in quotations of French text. —David Eppstein (talk) 18:32, 8 June 2026 (UTC)Reply
It is text. It is not text that the guidance about avoiding spaces before colons should apply to. Therefore, the guidance should continue to include some kind of qualifier like "in normal text" so that exceptional cases like this continue to be allowed. —David Eppstein (talk) 18:37, 8 June 2026 (UTC)Reply
That example is copied from the MOS. I presume it means that you could have several ratios in a sentence without violating the "multiple colons" rule. But the important things is that it explicitly says "Except in technical usage...". pburka (talk) 20:11, 8 June 2026 (UTC)Reply
@Largoplazo: you mean the part of MOS:CONFORM that says "follow the rules for correct punctuation in that language"? That appears to be in contradiction to the updated guidance which says to use English punctuation rules and admits no exception. We should not have contradictions in our guidelines. The qualification that permits these exceptions should remain. —David Eppstein (talk) 20:21, 8 June 2026 (UTC)Reply
MOS:CONFORM says to adjust punctuation except in the case of nested quotations in another language, in the bullet point David Eppstein quotes above. "Normal" is a squishy qualifier but could reasonably be read as excluding special cases like these nested non-English quotations. —Myceteae🌈 (talk) 20:48, 8 June 2026 (UTC)Reply
I prefer it with "in normal text". Removing this was not an improvement. We can argue about whether it was strictly necessary or goes without saying that there are exceptions, or whether there is a better way to account for the exceptions that are already understood to be allowed. But I've not seen any evidence that removing it better reflects the intended scope of the guidance or provides clarification that resolves any disputes. —Myceteae🌈 (talk) 21:22, 8 June 2026 (UTC)Reply
I'm not opposed to restoring "in normal text", though I consider it unnecessary. I was and remain opposed to changing it to "in prose", since the rule also applies to places that often aren't considered prose (headings, lists, captions, poetry, etc.). Gawaon (talk) 07:12, 9 June 2026 (UTC)Reply
