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, 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 articles
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 articles
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.
Help talk:Table#Indenting tables – Help page is conflicting with MOS:DLIST and MOS:ACCESS on a technical point. No objection to fixing it, and a suggestion to just do it WP:BOLDly, but the work actually has to be done. (Aug. 2023 –Jan. 2024)
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. 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. (Nov.–Dec. 2023)
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. 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. (Oct.–Dec. 2023)
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". Result: "nearly unanimously opposed". (Oct. 2023)
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. 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). (Aug.–Sep. 2023)
Talk:Bayes' theorem#Requested move 23 August 2023 – MOS:POSS stuff. 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). (Aug. 2023)
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". 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. (Aug. 2023)
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? 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. (July 2023)
Talk:Famous Players-Lasky#Requested move 24 June 2023 – proposal to use dash instead of hyphen. 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. (June–July 2023)
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?" 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. (May–June 2023)
Wikipedia talk:Manual of Style/Biography#2022_archive#Neopronouns RfC (moved) – several options were under discussion, including singular they, using neo-pronouns like xie, always referring to subject by surname, etc. Result: strong consensus to use singular they for subjects who use neopronouns. (Oct.–Nov. 2022)
Talk:Winston-Salem, North Carolina#RfC about Info Box – involves MOS:INFOBOX and MOS:ICONS and should be a broader discussion than just about this single article. Summary: about 50% of our US city articles include highway signs in the infobox, which is very inconsistent. Result: Near-unanimous agreement to remove them, though this does not appear to have resulted in changes at other articles and probably should. (June–Sep. 2022)
Wikipedia talk:Manual of Style/Linking#RfC on self-linking within article prose – Result: "There is a consensus that self-links within prose should be allowed and that linking should be based on editorial discretion." This is about linking to one section of an article from another section of the same article. (Nov. 2021 – Jan. 2022)
Talk:Rolling block#Case and hyphen – "rolling block action" vs. "rolling-block action", and "Remington Rolling Block breech" vs. "Remington rolling-block breech". Result: inconclusive discussion (May–Dec. 2021).
Talk:Love On Top#Requested move 25 April 2021 – Revisiting whether to capitalize the first word of a compound preposition even when that word is a short preposition; MOS:5LETTER might need a revision. Result: No consensus, not moved.
Talk:Woman on Top#Requested move 6 April 2021 – Multiple proposals like "Receiving partner on top", "On top (sex)", etc., motivated by gender and language-reform advocacy views. Result: essentially a WP:SNOW: "not moved, and with a reception likely to strongly discourage near-future requests. ... Consensus in this discussion is strongly in the direction that any such move would be OR/SYNTH violating article title policies."
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.
Support for … (unicode ellipsis, U+2026) is widespread now. The decision to prefer ... over …[1] was made 15-20 years ago when unicode support was nascent.[2]
Benefits of … (unicode ellipsis)
More accessible — screen readers can read "ellipsis" properly
more compact & readable. Better line breaks
renders with better fidelity using font glyph
scales better when zooming & with high-DPI devices like mobile phones
easier to parse (distinct unicode representation for character)
Eh, I'm not so sure about that. Curly quotes have drawbacks (e.g. being 'keyed', being more frequent to the degree where I would argue the extra byte substantially increases page sizes on average) that U+2026…HORIZONTAL ELLIPSIS does not. Remsense诉18:36, 16 April 2024 (UTC)[reply]
I agree with Gawaon's 1st sentiment that curly quotation marks/apostrophes should be discussed in the same vein as ellipses. Both deal with the distinction of ASCII representation vs. extended character maps. I don't think that their multi-byte effect on increased page size is of any concern. -- Michael Bednarek (talk) 04:49, 17 April 2024 (UTC)[reply]
The big BIG advantage of requiring straight quotes and period ... ellipses is that it doesn't allow yet another gratuitous style variation for gnomes to slow-war over. It looks fine, it works, it contributes to having a clean readable style instead of a fussy special-character-elaborated one. Why get rid of those advantages? —David Eppstein (talk) 06:57, 17 April 2024 (UTC)[reply]
Though I said the opposite above, I think it might indeed make most sense to limit this to the ellipsis issue for now, since it would be a relatively small change – much smaller than changing the rules for quotes and apostrophes. So if this is changed now, the quote issue could possibly be reconsidered in a year or two, then taking into account the experience with the ellipsis change.
For the ellipsis, there are two possibilities:
Allowing both ... and … as equally valid options. Very easy change, but with the disadvantage that usage in any given page could then be mixed, annoying the typographically aware. Though the visible difference between ... and … is small (much smaller than "quotes" vs. “quotes”, I'd say – in fact, in our standard font I can hardly see it), so that shouldn't matter very much. Also, to prevent "slow-warring", we could make the rule that changing ... to … is allowed, but changing in the opposite direction is not. In that way, pages would slowly evolved in the typographically correct direction.
Requiring, from now on, that … is used, and deprecating ..., just like MOS:DASH has deprecated the use of single or double hyphens instead of dashes. This would ensure that there is a single standard all pages are meant to adhere to, so totally eliminating the risk of edit warring. The disadvantage, of course, is that there are 100,000s of pages (at least) that currently don't adhere to that standard. I suppose a bot could help with that change, but it would still be a giant task to bring them in adherence.
Bad idea. The point of an MoS is to be as consistent as possible. And changes would have to be implemented regardless; if you don't do anything, AWB, bots, and other automated tools will just continue changing them. InfiniteNexus (talk) 06:10, 21 April 2024 (UTC)[reply]
I have no real preference for one or the other, but I oppose the change. It wouldn't be too much work for a bot to change all of one to another. Still I see no reason to mess with what's been working. Actually, I do prefer the three dots. Anyone can type ... and the … requires a bit more effort, and … displays differently depending on the font used, so sometimes looks odd. Mixed use looks sloppy and I really want to avoid that. SchreiberBike | ⌨ 11:48, 21 April 2024 (UTC)[reply]
I'm wary of creating yet another challenge for new editors who want to do the right thing – we want to keep them. NebY (talk) 14:26, 21 April 2024 (UTC)[reply]
I would support mandating the unicode ellipsis. Adding this to the MOS wouldn't create any burden to new users – gnomes would simply bring articles into conformity over time. Graham11 (talk) 03:36, 21 May 2024 (UTC)[reply]
More likely some bot operator is going to get it into their head that this must be done immediately!!1! and make our watchlists unusable for several days while they crank through all the Wikipedia articles at a rate of several per second. How about let's don't. —David Eppstein (talk) 07:16, 21 May 2024 (UTC)[reply]
If the Unicode ellipsis is better for screenreaders, we should go for it. Just add an ellipsis option to the usual dash scripts. —Kusma (talk) 19:28, 21 May 2024 (UTC)[reply]
Is there any more reason to believe that it is better for screenreaders than to believe that it is worse for screenreaders? One could equally well write, if it is worse for screenreaders, then we should continue to eschew it. —David Eppstein (talk) 20:03, 21 May 2024 (UTC)[reply]
On a quick Google, I have found some accessibility blogs that advocate use of the ellipsis character over three dots. I have no idea how important it is in practice. —Kusma (talk) 20:19, 21 May 2024 (UTC)[reply]
Require semantically/typographically correct ellipsis per accessibility issues. Allow someone to type in three periods for convenience, but keep it deprecated and have semi-automated tools and bots change this as long as they are making other changes as well. Change all page and category titles as well with redirects from three dots. ―Justin (koavf)❤T☮C☺M☯23:07, 21 May 2024 (UTC)[reply]
As a screen reader user, I've never heard of these accessibility issues ... screen readers can read three dots fine. It really doesn't need a mass change here. Graham87 (talk) 07:54, 22 May 2024 (UTC)[reply]
How mean of you. You've just taken away some gnome's purpose in life. (For those playing along at home, we've now got two Graham's Grahams in the conversation.) EEng13:59, 22 May 2024 (UTC)[reply]
Usually happens to me on Facebook. I'll correct some glaring typo in a meme-post, only to misspell or mispunctuate something in my own comment, and of course suffer a dogpile of derision! — SMcCandlish☏¢ 😼 17:45, 13 July 2024 (UTC)[reply]
Oppose any change - three dots is fine and easier to write. Then again, if it's not onerous to make a bot that turns every instance of ... into … after every single edit that includes ..., I'm not going to lose any sleep over it. BoldGnome (talk) 02:57, 12 June 2024 (UTC)[reply]
Notes
^ In some cases the obvious name is already taken, e.g.,
Allow either ... or …. I agree with the (minor) advantages of using the unicode character, but changing it everywhere seems like a huge waste of time and effort. We should just be agnostic about it, IMO. Nosferattus (talk) 18:14, 20 June 2024 (UTC)[reply]
The problem with "allow either" is that in some fonts they look very different from each other. Having "..." and "…" near each other looks pretty bad to me. SchreiberBike | ⌨ 20:46, 20 June 2024 (UTC)[reply]
The … glyph is virtually illegible to many of us with poor eyesight, and offers zero advantages of any kind. It's not something easily typed, it saves no space/bandwidth that we actually need saved, it will not be consitently treated in searches, and it is vastly worse for legibility. It also doesn't look consistent in all typefaces when combined with .: …. It really has nothing going for it at all. Just because the Unicode Consortium for its own internal reasons decided to create a codepoint for something doesn't make it magically the best thing for WP to use for its own purposes. — SMcCandlish☏¢ 😼 06:26, 13 July 2024 (UTC)[reply] PS: The "more accessible" claim could be "something going for it", but if and only if there is actual proof that screen readers have some kind of problem with "..." (the three periods version). I've never encountered any evidence to suggest this, much less any to suggest that the pre-composed "…" character is superior in this regard, but that's a question for which the MOS:ACCESS regulars should be consulted. — SMcCandlish☏¢ 😼 17:49, 13 July 2024 (UTC)[reply]
When you say "virtually illegible", you mean in monospace fonts, right? In other fonts, … and ... should (and do) mostly look fairly similar. Gawaon (talk) 07:24, 13 July 2024 (UTC)[reply]
Change "foreign-language" to "non-English language"?[edit]
Of course "foreign-language" is a common adjective to mean "in a language other than English" and that's fine, but it also looks a bit odd in the guidelines of an international internet encyclopedia? "non-English language" is clunkier I'll admit, but it's also more precise in a way that seemingly doesn't cost much. Should we consider changing it on policy and guideline pages?
(I'm fairly sure it shouldn't be non–English language or non-English-language even as an adjective, right? Those both look ridiculous.)Remsense诉05:28, 3 May 2024 (UTC)[reply]
My concern is that "non-English" might exclude the English-based creoles like Nigerian Pidgin; we should treat these creoles as we would treat any other non-English language, as English speakers tend to be unable to understand them. BilledMammal (talk) 08:28, 3 May 2024 (UTC)[reply]
I think it is fairly safe to say that no one would have this as their public definition of "English language", right? Remsense诉08:37, 3 May 2024 (UTC)[reply]
Right, so how does "foreign language" do better with that ambiguity? I would think it does worse. There's no definite boundaries between any two lects you can define. Remsense诉08:54, 3 May 2024 (UTC)[reply]
I would agree if it were a big deal to fix. Plus, it is a little bit broken—we all know what a lot of words *should* mean, but that doesn't mean we can't seek to further improve our word choices. Remsense诉08:50, 3 May 2024 (UTC)[reply]
Agree. 'Foreign' is not necessarily the same as non-English even when you assume the reader/editor is in a country where English is the most commonly spoken language. Many countries where English is the norm were colonised and had/have indigenous languages of their own, which would be odd to call 'foreign'. FropFrop (talk) 09:04, 18 May 2024 (UTC)[reply]
You aren't wrong. We can simplify most of this, avoiding "non-English language". In this main MoS page, nearly all uses of "foreign" are either to qualify a noun other than "language" ("foreign words", "foreign text") or in the adjectival "foreign-language" to qualify a noun. In the former cases, just replace "foreign" with "non-English". In the latter, replace "foreign-language" with "non-English", omitting "language". A couple of cases are tricky because they link to sections currently titled "Foreign languages" on other MoS pages. Those can be dealt with in turn but is there anything objectionable about my proposal to make the first round of substitutions forthwith? Even to the extent that I could argue that, pragmatically, readers will know what we mean, "non-English" is better.
Finally, for the noun phrase "foreign language(s)", "language(s) other than English" seems more natural than "non-English language(s)". Largoplazo (talk) 11:43, 18 May 2024 (UTC)[reply]
Given that there is clearly a general consensus here to move away from the politico-geographic, not linguistic, term "foreign", I will edit this and related material to effectuate the change. This will also involve creating shortcuts that don't use "FOREIGN", and requires conforming edits to a bunch of other pages that touch on the same sort of material, or which make reference to these sections by name. I have about half of it done in other browser tabs, but I also have a wicked cold right now, so my attention and patience are a little drained. Give it a bit of time. — SMcCandlish☏¢ 😼 04:20, 13 July 2024 (UTC)[reply]
It seems that the particular constructions referred to as "parenthetical plurals" by style guides—e.g. when posting thread(s),—have never been discussed here before, which is a bit shocking. Here's a quick pitch for why we should consider explicitly deprecating their use in article(s):
They are almost entirely useless, and usually do not clarify any ambiguity. This is the case for WP:AND/OR but stronger. Use of a plural form to indicate "any number of" is usually completely fine, and when it's not there's usually a broader problem with the structure of your sentence.
Something something, brackets can create problems for wikitext, somehow.
While neither AMA nor Chicago explicitly disallow parenthetical plurals, they both firmly suggest that you should never have to use them.
WP:MOSBLOAT. Have you found yourself wasting time debating this point with other editors -- time that would be saved by a new MOS provision? EEng16:07, 31 May 2024 (UTC)[reply]
I see it considerably often, but you're totally right in that no one's ever actually insisted as to require a guideline enshrining consensus. Remsense诉16:17, 31 May 2024 (UTC)[reply]
This is a bit confusing, so let me try to give an example.
Suppose we have a book, A Great Book by Joe Sixpack, that says something like this:
The sky is blue.[15]
Then at the end of the book is a list of sources, including one for footnote 15. Let's call this "The Original Source". So we have a book by Sixpack that cites "The Original Source".
Now we want to quote from A Great Book in a Wikipedia article. And we do so like this, preserving not just the quote, but Sixpack's source citation too:
In his book A Great Book, Sixpack says that "The sky is blue.[1]"[2]
I find this awkward and unnecessary. I would leave out the citation to "The Original Source". Verifiability is still preserved, because a curious reader can look up Sixpack and from there find The Original Source. Does this seem right?
Redrose64 is right, of course, but it's also true that (a) you might as well look at Original Source to see if it meets our own standards (it usually will, if A Great Book is published by a good publisher), and (b) if it's easy to access Original Source it's worth taking a look at that too. At least once that I recall I've found that Joe Sixpack misinterpreted Original Source. Mike Christie (talk - contribs - library) 20:57, 12 June 2024 (UTC)[reply]
Citations are not part of the quoted material. They go at the end of the introductory material immediately before the block quotation, never inside the quotation. This is one of the most common formatting errors on Wikipedia.
In the constructed example above, we have no reason to block-quote some other person saying that the orignal source said something; either the intermediary source is reliable enough, or it is not. If it is, the usual method of doing this is to indicate what original source the intermediary source is quoting, simply to help the reader assess the source's reliability for themself, and to help them find the original if they don't have access to the intermediary (which may be paywalled or otherwise non-easy to get at). But if a block quotation is needed, it will be of the original material, not someone claming that the original material exists. E.g.:
This approach will revolutionize developmentally appropriate models across content areas, by means of synergizing bottom-up inquiry across cognitive and affective domains, through which we will evolve brain-compatible paradigms throughout multiple modalities.
However, Persson's assessment has been challenged by Ann N. Tety and D. Prezenz,[4] according to whom ....
In the above, if we had access to Una Persson's original publication, there would be no reason to cite the A. Humon intermediary source at all. But for some material (e.g. obscure journals not indexed on sites we have access to through The Wikipedia Library, sometimes intermediate-source citations are the best that we can do, at least for now.
PS: For a block quotation that lacks any kind of introductory material to which to attach the citation, the {{blockquote}} template provides some sourcing parameters that will put attribution after the block quote. But this should almost never be done in an actual encyclopedia article. Just create introductory material to provide context. Injecting context-free big quotations is virtually always a WP:NPOV problem, serving to promote some particular author's viewpoint unduly and without any clear reason that the reader can intuit. The main exception is when quoting notable speeches of famed orators like MLK in an article section about the speech, or key lyrics from a song at the song's article, that sort of thing, where the context is already clear. The template's attribution/source parameters should not be redundantly used along with a regular citation, nor used in lieu of one. (Some editors have a bad habit of assuming that if a template supports the possibility of doing something that it should or must be done.) — SMcCandlish☏¢ 😼 05:07, 13 July 2024 (UTC)[reply]
^Humon, A. (2024). A Critical Appraisal of the Philosophy of Una Persson. Some Damn Press. p. 123. Quoting: Persson, Una (1959). "The Epistemology of intra-disciplinary approaches to pseudo-Manichaeanism". Proceedings of the Obfustcatory Omphaloskepsis Society. 12 (2): 12–13.
I think it has to depend on the history of the orthographies in question. For one particular case, MOS:ZH says that alternate/historical romanizations of Chinese place names generally shouldn't be used, even if they appear as a part of other proper names: e.g. Tsingtao Brewery Co., Ltd. is located in Qingdao, Shandong.Remsense诉07:22, 19 June 2024 (UTC)[reply]
It's not historical but it isn't commonly used outside of a minority group essentially. It's Pokeno, which instead of using a macron is sometimes spelt as Pookeno but I can't find any reliable source that actually uses this spelling. Mayhap it is more akin to dialectal variations. Traumnovelle (talk) 07:30, 19 June 2024 (UTC)[reply]
And "I can't find any reliable source that actually uses this spelling" already indicates that we should not mention it. "Some rando on the Internet spells it funny" is not something we ever need to contemplate encyclopedically. — SMcCandlish☏¢ 😼 07:10, 13 July 2024 (UTC)[reply]
Sometimes, if they have been widely used historically or are widely used now? From a MoS point of view, I guess that means we should not have a general rule. Better figure out what works best for each article. —Kusma (talk) 16:48, 13 July 2024 (UTC)[reply]
This week I took a long time to learn how to enable a first-line indentation and I would like to float the possibility of improving the sentence under 'Indentation' which cites two templates to enable other editors to learn how to use them more quickly. Would anyone be willing to mentor me if I tried to improve it to achieve this objective? For the record, I should disclose that I am new to templates.John Desmond (talk) 15:09, 20 June 2024 (UTC) .[reply]
Some of my friends, yesterday I suspect that John Desmond refers to a common practice in printed books where the first line of a paragraph is indented by one or two em. --Redrose64 🌹 (talk) 20:40, 21 June 2024 (UTC)[reply]
Yep. The only reason to ever do this is when illustrating the original layout of something, as an end in itself, e.g. in an article about this history of document formatting; or when preserving the exact formatting of a poem that was written with an unusual whitespace structure on purpose. To do the latter, use <poem> markup. To just do the former, to the first line without regard to formatting of subquent lines in the rest of the paragraph, start the paragraph with {{in5}}. But this should certainly not be done to cause first-line-indented paragraphs in general WP prose; it simply is not WP style.
PS: That edit by John Desmond was also wrongheaded in several other ways. First off, block quotations (which also, on WP, do not take first-line indentation) should be marked up with {{blockquote}} (MOS:BQ), not list markup (abuse of list markup to get visual indentation is covered at MOS:LIST and MOS:ACCESS). Second, block quotations do not take quotation marks (MOS:BQ). Third, shorter quotations that are done inline instead of as blocks, and which do take quotation marks, do not take single-quotes but double (MOS:QUOTEMARKS). Fourth, editorial additions like "[Emphasis in the original.]" take square not round brackets (MOS:QUOTE), but for a block quote are better done as part of the introductory clause rather than part of the block quote, when this is feasible. Fifth, use {{sic}} instead of manual markup. Sixth, for semantic emphasis, use {{em}} not ''bare italics'' (MOS:EMPH). — SMcCandlish☏¢ 😼 05:23, 13 July 2024 (UTC)[reply]
To find out how many inlinks there are to the old section title and what articles have them, you can execute this advanced searchthis advanced search, changing article to the name of the article, and oldsection to the old section title. If there are only a small number of links to the old section title, it's better to just update them..
I recently noticed that a bunch of users have added unneeded embedded section anchors after renaming a section header, presumably because they don't know how to find out if there are any articles that link to the old section title or not, and if so, how many of them there are. Imho, embedded section anchors should only be added when necessary, as they create squirrely wikicode which may mystify other editors, or discourage them from making further changes to the section header which may be warranted. To reduce the scope of this issue, increase transparency about section inlinks, and limit the number of unneeded embedded anchors being created especially when there are no incoming links at all (a good proportion of them), I added the note. (A secondary problem, much less serious imho, is users using the problematic, unsubsted version identified at MOS:SECTIONANCHOR as resulting in undesirable behavior.)
I would appreciate additional eyeballs on this note, both the wording as well as any comments on the generic advanced search terms. I am aware that the search doesn't include everything (notably, will not find links from articles using {{slink}} to target it) or exclude (nowiki's, html comments) but I am trying to keep the input search term field simple-looking enough that a user unfamiliar with advanced search won't be afraid to try it, so it's kind of a balancing act how complex to make it. That said, if there's anything egregiously missing or wrong with it, or if it can be significantly improved without degrading usability, please do comment, or just adjust it. Adding @PrimeHunter, Sdkb, Trialpears, Qwerfjkl, Colin M, Quiddity, and Rjjiii:. Thanks, Mathglot (talk) 23:13, 26 June 2024 (UTC)[reply]
Thanks for adding this tip! Marginally related, is there some way to find all broken section anchors pointing to some article? I would find that extremely helpful in order to improve the integration of a page that has underdone a lot of reorganization over time so that this method of looking for broken section links by name is not practical. Gawaon (talk) 06:08, 27 June 2024 (UTC)[reply]
@Mathglot: If you go to the link and then change the terms to what you want before clicking search it finds all links to that section in articles, but if you edit the link and go to it directly, it searches in all pages. Is that fine? – 2804:F1...A9:64C1 (talk) 03:51, 28 June 2024 (UTC)[reply]
Not entirely sure I understand; are you trying to draw a distinction between searching only articles (i.e., main space) and searching all namespaces (articles, Talk pages, User pages, Wikipedia project pages and so on)? If so, we can do that by adding search term :all and perhaps we should. I've updated the search link in the explanatory note to search all namespaces, pending any objections or other comments on this aspect of it. Mathglot (talk) 04:07, 28 June 2024 (UTC)[reply]
I meant that the link included profile=all, so editing the link itself would result in searching all pages (any namespace), but going to the link and then editing the terms and clicking search would result in searching only in articles.
Anyways, now the :all is not* doing anything, try for example, searching for :all linksto:"Banana" insource:/[[|]Banana\#/ vs without the :all (but with all namespaces selected).
(edit conflict) The problem is not in the link, but in your example. If you choose an article name which has no links outside mainspace, like Banana, then the correct behavior is that there is no difference with or without the :all search term. Try an example like "Vichy France" which has some inlinks from mainspace, as well as other namespaces.
Secondly, although that will actually work correctly, even without a section name, this whole issue is part of the clarification of section § Section headings in the MOS, so really applies more to that case. For that, you can try examples like "Vichy France#Collaborationnistes". (ec) Mathglot (talk) 04:42, 28 June 2024 (UTC)[reply]
Thanks for that; I must've been assuming the wrong functionality for :all; I need to look at that again. Your workaround works, but should be doable without it, assuming there is a search prefix or pseudo-term that activates that; let me check. If you know what it is, please post it. Mathglot (talk) 04:51, 28 June 2024 (UTC)[reply]
Adding that sentence about searching redirects as well looks like an improvement to me. Even if there's a way to do that via advanced search (instead of What links here), Cirrus doesn't support alternation, so you can't have the union of two searches in one query, afaik; plus, that might get into "too complex" territory even if we could, so I think your approach is the right one, here. Thanks, Mathglot (talk) 21:17, 28 June 2024 (UTC)
Not done: A change of this magnitude would require consensus and affect a significant number of articles. GSK (talk • edits) 17:58, 20 June 2024 (UTC)