Wikipedia talk:Manual of Style

Style discussions elsewhere
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.

Current
(newest on top)


 * Wikipedia talk:Manual of Style/Biography – Should British peers use their peerage title in place of their name in infoboxes?
 * Talk:Shays' Rebellion – Apply MOS:POSS and add an s?
 * Template_talk:Infobox_university – Should multiple entries be formatted as a list or a single phrase?
 * Talk:Sino-Soviet border conflict – Do flags in this infobox serve a "useful purpose" per MOS:INFOBOXFLAGS or are they primarily decorative and should be removed?
 * Wikipedia talk:Image use policy
 * Wikipedia_talk:Featured_list_candidates – Lead length of Days Of the Year (DOY) articles (Feb. 2024)
 * Wikipedia talk:Manual of Style/Medicine-related articles – On Asperger syndrome vs. Asperger's syndrome, etc. (Jan. 2024)
 * Requests for comment/Names of deceased trans people (moved from WP:VPPOL) – Yet another round of this long-term, multi-RfC process. Consensus seems possible this time. (Dec. 2023 – Jan. 2024)
 * Village pump (policy) – Proposal to merge a "guideline in all but name" into MoS. (Jan. 2024)
 * Village pump (proposals) – Peripherally related to MOS:IMAGES and MOS:ACCESS. (Jan. 2024)
 * Wikipedia talk:Naming conventions (companies) – Involves MOS:TM (plus WP:COMMONNAME, WP:OFFICIALNAME. Covers more than thread name implies, including that guideline not having substantive revision since 2009. (Dec. 2023 – Jan. 2024)
 * Wikipedia talk:Manual of Style/Biography – MOS:JOBTITLES has long been considered too complicated and hard to follow. This is not an RfC but drafting toward one; input has stalled out over the holidays, and needs to resume. (Dec. 2023 – Jan. 2024)
 * Wikipedia talk:Manual of Style/China- and Chinese-related articles – Involves MOS:FOREIGN, MOS:SINGLE, MOS:ALLCAPS, MOS:BOLD. Still unresolved. (Oct.2023 – Jan. 2024)
 * Wikipedia talk:Manual of Style/Writing about fiction – Involves MOS:WAF, MOS:INITIALS, MOS:TM, MOS:ACRO, WP:OFFICIALNAME, etc. Still unresolved, but there seems to be no appetite for diverging from MOS:INITIALS. (Oct. 2023 – Jan. 2024)
 * Wikipedia talk:Manual of Style/Islam-related articles – Involves MOS:HONORIFIC, MOS:DOCTCAPS, WP:NPOV, WP:CHERRYPICKING, etc. Still unresolved, though consensus seems to be forming in one direction. (Sep. 2023 – Jan. 2024)
 * Help talk:Table – 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/Tables – Specifically in tables, possibly elsewhere. MOS:UNITNAMES (at the table "General guidelines on use of units") has an example of existing use that is being challenged, and material at Help:Table is also at issue. Still unresolved. (Dec. 2023)
 * Wikipedia talk:Manual of Style/Accessibility – About use of around table captions (which are primarily for screen readers) to hide them from the usual non-screen-reader view when their content repeats what is in the table headers. Still unresolved, too little input; probably needs to be RfCed. (Nov.–Dec. 2023)

Capitalization-specific:

Concluded

 * Wikipedia talk:WikiProject Linguistics – Involves MOS:ALLCAPS. Result: Thinly attended, but there does seem to be a linguistics standard to render lexical sets in, so this has been accounted for and added to the exception lists at MOS:ALLCAPS (since our articles are consistently doing it).
 * Wikipedia talk:Manual of Style/Words to watch – On MOS:EUPHEMISMS and whether to add another example to it. Result: Discussion archived to Wikipedia talk:Manual of Style/Words to watch/Archive 14 without a clear conclusion
 * Wikipedia talk:Manual of Style/Korea-related articles – On use of a template to link Korean characters to Wiktionary (Jan. 2024). Result: general consensus to not do that excessive linking; and a bot request made to clean it up.
 * Talk:Mercedes-Benz – Use an en dash instead of a hyphen? Result: Withdrawn
 * Pākehā settlers move review – Move review on Pākehā settlers vs. European settlers in New Zealand, related to WP:COMMONALITY, WP:TIES, WP:CONSISTENT, WP:RECOGNIZABILITY (Feb. 2024). There were many steps in this process but ultimately Pākehā settlers was moved to European settlers in New Zealand.
 * Wikipedia talk:Manual of Style/Titles of works – To treat word-substitutions ("U" for "You", "❤️" for "Heart", "..." for elided wording), as "words" for the purposes of a particular line-item about title-case treatment. Result: Done, with unanimous support. (Dec. 2023 – Jan. 2024)
 * Wikipedia talk:Manual of Style/Trademarks – 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. No objections or other issues have come up. (Nov.–Dec. 2023)
 * Village pump (policy) – Proposal to add something to MOS:NUM. Result: "no consensus as to whether or how to standardize ISBNs or whether to subject them to a CITEVAR-like rule .... The closest thing we have to a consensus here is that spaces (option 4) should not be used." (Oct.–Dec. 2023)
 * Wikipedia talk:Manual of Style/Dates and numbers – 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 talk:Naming conventions (Ukrainian places) – Primarily a matter of article title, but there are related issues such as capitalisation. Result: basically stalled out, without resolution/action. Specific revision proposal is needed. (Nov. 2023)
 * Wikipedia talk:Manual of Style/Television – Also involves MOS:NUMERALS. RfC on "season 3, episode 7" vs. "season three, episode seven" styles (and probably also "seventh season" vs. "7th season", etc.). Result: "season and episode numbers should be expressed as numerals in tables, headings, and article body" (revision of a previous, less clear close). (Oct.–Nov. 2023)
 * Village pump (policy)/Archive 187 – 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)
 * Wikipedia talk:Manual of Style/Capital letters – Involves MOS:TITLES, WP:AT, etc. Result: "rough consensus to allow for lowercase or capital letters after dashes or colons in article titles, section titles, and list items". (Sep.–Oct. 2023)
 * Talk:Ulster Scots people – MOS:FLAGS / MOS:IMAGERELEVANCE and Northern Ireland again. Result: No formal closure, but near-unanimous consensus against using national flags as ethnicity symbols. (Sep.–Oct. 2023)
 * Talk:2023 Hawaii wildfires/Archive 2 – 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 – 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 talk:WikiProject Military history/Archive 171 – Wikiproject propsal to change MOS:TIME or MOS:MILFORMAT. Result: wrong venue, and to the extent people commented on using 24-hour time, it was mostly opposed. (Aug. 2023)
 * Talk:Franklin–Nashville campaign – Above question was raised at a specific article as a "local consensus" matter. Result: unanimous opposition to 24-hour time. (Aug.–Sep. 2023)
 * Village pump (idea lab)/Archive 50 – Follow-up to "unfruitful" discussions at WT:MOSMUSIC, etc. Result: No formal closure; general agreement basically boils down to "write clearly and don't confuse or over-simplify with an adjective". (Aug. 2023)
 * Wikipedia talk:WikiProject Military history/Archive 171 – Wikiproject proposal to change rank abbreviations (to NATO style) in MOS:COMMONABBR. Result: no formal closure, but overwhelming consensus to stick with MoS and ignore NATO preferences. (Aug. 2023)
 * Wikipedia talk:Manual of Style/Biography/2023 archive – And some alternative ideas, including merger into WP:BLP. Result: No formal closure, and the idea was mostly opposed, with no effect but returning all of the shortcuts (MOS:GENDERID, MOS:GID, MOS:DEADNAME, WP:GENDERBLP, MOS:NB) that someone changed to point to the WP:Manual of Style/Gender identity essay to now point back to the real guideline at WP:Manual of Style/Biography. The essay has been retooled to be an exegesis of the guideline, though attempts at WP:POLICYFORKing are likely to continue, as this is one of our most hotbed internal topics. See also the guideline Manual of Style, and the essays WP:Gender-neutral language and WP:Gender-neutral language in Wikipedia policies. (Aug. 2023)
 * Village pump (policy)/Archive 186 – Proposal to move the MoS material into WP:BLP. Result: Procedurally closed as "premature". (Aug. 2023)
 * Talk:Lutheran Church–Missouri Synod – Should the en dash have spaces around it; should it be an em dash? Result: moved to spaced en dash.
 * Help desk/Archives/2023 August 5 and d:Wikidata:Project chat/Archive/2023/08 – 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:Decatur & Eastern Illinois Railroad and Talk:Central Maine & Quebec Railway – Use "&" or "and"? (see MOS:&). Result: Follow MOS:&; the essay WP:WikiProject Trains/Style advice conflicting with the guideline and with WP:COMMONNAME policy was noted, and this WP:ADVICEFORK was fixed in Jan. 2024. The second of these actually closed as "no consensus" because the WP:NAC who closed it did not know of WP:CONLEVEL policy and incorrectly treated policy- and guideline-based arguments as no stronger than those based on a contrary essay.
 * Village pump (policy)/Archive 184 – Some re-wording proposals, and even a suggestion to remove the language entirely. Result: No formal closure, and did not result in wording changes, though a re-do might come to such a conclusion. (July 2023)
 * Talk:SAG-AFTRA – 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:2023 SAG-AFTRA strike – ditto. Result: Procedurally closed as a WP:TALKFORK of the RM above.
 * Talk:Famous Players-Lasky – 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)
 * Village pump (policy)/Archive 185 – Proposal to change MOS:DEADNAME that "encyclopaedic significance of the deadname [be] established through in-depth analysis or discussion of the name in high quality sources, or if they were notable prior to transitioning". Result: "no clear consensus". (June–July 2023)
 * Village pump (policy)/Archive 182 – 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/Abbreviations/Archive 2 – Proposal to move section to naming-convention guideline. Result: no pro or con input; re-opened (Jan. 2024) on main MoS page. (June 2023)
 * Wikipedia talk:Manual of Style/Icons/Archive 17 – essential information, or icon cruft? Result: "There is consensus against inclusion of rank icons." (Mar.–Apr. 2023)
 * Wikipedia talk:WikiProject Boxing/Archive 10 – involves MOS:MISCSHORT and MOS:TIES. Result: no consensus to use "v"; continue to use "vs." or "vs" as suits the MOS:ENGVAR of the article. (Feb.–Mar. 2023)
 * Wikipedia talk:Manual of Style/Infoboxes – Result: no consensus. (Dec. 2022 – Feb. 2023)
 * Wikipedia talk:WikiProject Fraternities and Sororities/Archive 8 – Should an external style guide be used in place of WP:MOS in chapter lists (e.g. List of Alpha Phi Alpha chapters)? Result: Insufficient input to reach a consensus. Needs to be RfCed. (Jan.–Feb. 2023)
 * Wikipedia talk:Manual of Style/Dates and numbers/Archive 162 – Open discussion as to whether decimalized years should be used in personal biographies. Result: discussion archived; majority felt that decimalized years are not standard in biographical prose and should be limited to a statistical/mathematical context. (Jan. 2023)
 * Talk:Proto-Indo-European homeland/Archive 2 – another MOS:BCE question. Result: use BCE. (Oct. 2022 – Jan. 2023)
 * Talk:Blue cone monochromacy – should a clarifying hyphen be used? Result: moved to Blue-cone monochromacy.
 * Wikipedia talk:Organizing disambiguation pages by subject area – proposal to elevate essay to guideline status; possibly merge to MOS:DAB. Result: proposal succeeded; page moved to Manual of Style/Organizing disambiguation pages by subject area. (Nov.–Dec. 2022)
 * Wikipedia talk:Manual of Style/Icons/Archive 17 – essential information, or icon cruft? Result: No formal closure, or certain resolution, but generally (on the policy/guideline merits) against the flag usage. (Oct.–Dec. 2022)
 * Wikipedia talk:Manual of Style/Linking/Archive 21 – followup to a TfD. Result: Wasn't formally closed, but there is a WP:SNOW result that the answer to "Should hatnote links to Simple English Wikipedia be discouraged?" is "yes". (Oct.–Dec. 2022)
 * Wikipedia talk:Manual of Style/Biography – 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)
 * Wikipedia talk:Manual of Style/Icons/Archive 17 – Should subnational flags be used in such tables? Result: Archived without a clear resolution. (Oct. 2022)
 * Talk:Arthur Joseph Lewis, Jr. – bring recent articles into alignment with MOS:JR? Result: articles moved to remove comma. (Oct. 2022)
 * Talk:Staffordshire Bull Terrier/Archive 5 – Two quotes were removed, should they remain in the article? Result: no formal closure, but clear consensus against inclusion. (Sep.–Oct. 2022)
 * Wikipedia talk:WikiProject Biology/Archive 13 – Result: the scientific name in the lead should be boldfaced per MOS:BOLDSYN. (Sep. 2022)
 * Talk:Winston-Salem, North Carolina – 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/Archive 21 – archived without any resolution to change anything (Apr.–June 2022)
 * Wikipedia talk:Manual of Style/Words to watch/Archive 13 – also involves WP:NPOV and related concerns. Archived without any resolution to change anything, but was widely opposed. (Feb.–March 2022)
 * Wikipedia talk:Manual of Style/Trivia sections – Result: "rough consensus that this guideline and MOS:POPCULT do not currently apply to articles and stand-alone lists" (as summarized by the nominator); followup discussion considered merging some MOS:POPCULT material into WP:NOT, but that would be a policy-change proposal to discuss at WT:NOT, and a suggestion to develop a content guideline on encycloepedic relevance, but neither has happened. (Dec. 2021 – March 2022)
 * Bots/Requests for approval/SdkbBot 3 – fixes MOS:CONSECUTIVE errors. Result: approved (Feb. 2022)
 * Wikipedia talk:Manual of Style/Linking – 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)
 * Village pump (technical)/Archive 194 – Result: inconclusive discussion (December 2021).
 * Wikipedia talk:Manual of Style/Text formatting – Result: no formal closure; majority against changing infobox display (Nov.–Dec. 2021).
 * Wikipedia talk:Manual of Style/Text formatting – Result: inconclusive discussion (Oct.–Dec. 2021)
 * Talk:Rolling block – "rolling block action" vs. "rolling-block action", and "Remington Rolling Block breech" vs. "Remington rolling-block breech". Result: inconclusive discussion (May–Dec. 2021).
 * Wikipedia talk:Manual of Style/Archive 222 – a MOS:HYPHEN and WP:CONSISTENT matter (April 2021); began as Talk:Virtual reality headset
 * Wikipedia talk:Manual of Style/Legal – regarding MOS guidance for articles about "law by jurisdiction" (March 2021)
 * Wikipedia talk:Manual of Style/Tables – regarding potentially conflicting table-related guidelines (March 2021)
 * Village pump (proposals) – about parameter names like url-status vs. urlstatus; not strictly an MoS matter, but likely of interest to MoS regulars (February 2021 – April 2021)
 * Wikipedia talk:Manual of Style/Lists – On whether and how to abbreviate "References" as a table column heading (October 2020)
 * Talk:Vandana Shiva – RfC on the application of WP:ENGVAR / WP:TIES. Result: clear consensus that the specific article should be written in Indian English.
 * Wikipedia talk:Manual of Style/Biography/2021_archive – Clarifying our deadname policy for biographies of deceased individuals. Result: no consensus for a change after lengthy discussion and closure by panel of three. Closers recommended considering a subsequent RfC with narrowed question.
 * Template talk:Infobox person/Archive 36 – MOS:BADITALICS? (May 2021). Result: seemingly withdrawn by OP after realizing that "Non-latin scripts should never be bolded or italicised per MOS:BADITALICS".
 * Template talk:Infobox racing driver (May 2021). Result: MOS:FLAG edited during discussion, resulting in confusion, no consensus possible => withdrawn by OP.
 * Wikipedia talk:Manual of Style/Images/Archive 10 – clarifying the status of collages as the infobox / lead image (May 2021). Result: archived without resolution.
 * Talk:Love On Top – 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.
 * Wikipedia talk:Manual of Style/Captions/Archive 2 – do we have a guideline about centering captions? or should we? (April 2021). Result: archived without resolution.
 * Wikipedia talk:Manual of Style/Icons/Archive 16 – about using personal coats of arms as stand-ins for national or military flags (April 2021). Result: Language added to proscribe use of coats of arms in infoboxes in place of flags.
 * Talk:Action of the Cockcroft – a style issue? or grammar? (April 2021) – Rewritten to avoid the impasse.
 * Talk:Woman on Top – 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."

Reconsider ellipsis vs … preference
{{notice| Summary ( as of 16:22, 22 April 2024 (UTC)) Tonymetz 💬 }} Support for … $(status quo)$is widespread now. The decision to prefer ... over … was made 15-20 years ago when unicode support was nascent.
 * 1) motion to decide on ellipsis & curly quotes together -- ⛔declined by consensus.
 * 2) decision on favoring   over {... — 🟨pending.
 * 3) suggestion: a bot to replace ... with … should be simple even over 100k + articles
 * 4) motion to keep ...$(unicode ellipsis, U+2026)$:
 * 5) keep ... because it is easier to type
 * 6) keep because it renders more nicely
 * 7) suggestion to avoid mixing styles
 * 8) a motion to use a template instead (see below) and move style debate over to the template implementation

Benefits of … $(unicode ellipsis)$ Tonymetz 💬  18:01, 16 April 2024 (UTC)
 * 1) More accessible  screen readers can read "ellipsis" properly
 * 2) more compact & readable. Better line breaks
 * 3) renders with better fidelity using font glyph
 * 4) scales better when zooming & with high-DPI devices like mobile phones
 * 5) easier to parse (distinct unicode representation for character)


 * If we discuss this, we need to discuss the use of typographical quotation marks too! Gawaon (talk) 18:23, 16 April 2024 (UTC)
 * 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 does not.  Remsense  诉  18:36, 16 April 2024 (UTC)
 * Fair enough. We also use en dash (–) and friends, after all. Gawaon (talk) 20:05, 16 April 2024 (UTC)
 * 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)
 * I know! Let's have an RfC on whether they should be discussed together! EEng 15:11, 21 April 2024 (UTC)
 * 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)
 * 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.
 * Personally I think option 1. would be fine, while 2. daunts me a bit because of the size of the required changes. Gawaon (talk) 07:39, 17 April 2024 (UTC)
 * While I'm not opposed on principle, I doubt implementing this change across thousands of articles would be feasible. InfiniteNexus (talk) 23:48, 20 April 2024 (UTC)
 * Well, option 1 wouldn't have to be "implemented", it would just be an option for editors to choose from now on. Gawaon (talk) 06:06, 21 April 2024 (UTC)
 * Bad idea. The point of an MoS is to be as consistent as possible. And changes 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)
 * Oppose any "use whichever style you want" option. Gonnym (talk) 11:24, 21 April 2024 (UTC)
 * 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 &#124; ⌨ 11:48, 21 April 2024 (UTC)
 * 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)
 * My preference would be to create templates for such things as ellipses and in-line quote and relegate the style arguments to the talk pages of those templates. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:55, 22 April 2024 (UTC)
 * 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)
 * 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)
 * There's a 200% chance this will happen, because at least two bot operators will try it. Remsense  诉  07:17, 21 May 2024 (UTC)
 * Isn't that a matter that should be addressed at WP:BRFA? Graham11 (talk) 17:10, 21 May 2024 (UTC)
 * 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)
 * 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)
 * 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)
 * Have you considered asking at WT:WPACCESS? -- Red rose64 &#x1f339; (talk) 21:50, 21 May 2024 (UTC)
 * I just brought it up at Wikipedia talk:WikiProject Accessibility SchreiberBike &#124; ⌨ — Preceding undated comment added 23:02, 21 May 2024‎ (UTC)
 * I think we should be ok with either. There doesn't need to be consistency for this. —Th e DJ (talk • contribs) 07:21, 20 June 2024 (UTC)

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 ( koa v f ) ❤T☮C☺M☯ 23:07, 21 May 2024 (UTC)
 * 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)
 * 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.) EEng 13:59, 22 May 2024 (UTC)
 * Bold of you to write "Graham's" on this talk page! JoelleJay (talk) 00:35, 12 June 2024 (UTC)
 * Something like that always happens when I'm being a smartass. EEng 08:55, 12 June 2024 (UTC)
 * Graham's law says that the rate of hot air escaping from a talk page discussion is inversely proportional to the square root of the weight of the arguments contained within. Hawkeye7  (discuss)  03:54, 12 June 2024 (UTC)}
 * Graham's law says that the rate of hot air escaping from a talk page discussion is inversely proportional to the square root of the weight of the arguments contained within. Hawkeye7  (discuss)  03:54, 12 June 2024 (UTC)}

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)

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)
 * 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 &#124; ⌨ 20:46, 20 June 2024 (UTC)

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) 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)


 * 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)
 * Pointless distinction, since monospaced font is what most users will get in the editing window.  — SMcCandlish ☏ ¢ 😼  16:32, 13 July 2024 (UTC)

Change "foreign-language" to "non-English language"?
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)


 * Agree. “Foreign” presupposes where the reader is, which isn’t appropriate for an international encyclopaedia. MapReader (talk) 07:08, 3 May 2024 (UTC)
 * 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)
 * 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)
 * It’s not exactly an English language - but it’s also not exactly a non-English language. BilledMammal (talk) 08:52, 3 May 2024 (UTC)
 * 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)
 * Don't fix what ain't broke. Foreign is fine as we all know it means a language other than English. Masterhatch (talk) 08:48, 3 May 2024 (UTC)
 * 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)
 * 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)
 * 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)
 * Agreed for all the reasons you've provided. "Non-English languages" is fine enough to me. –  Primium  (talk) 23:14, 13 June 2024 (UTC)

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)

Parenthetical plural(s)?
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): Remsense 诉  09:46, 31 May 2024 (UTC)
 * 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.
 * They are ugly.
 * WP:MOSBLOAT. Have you found yourself wasting time debating this point with other editors -- time that would be saved by a new MOS provision? E<b style="color:blue;">Eng</b> 16:07, 31 May 2024 (UTC)
 * 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)
 * At least in the example given, the construction is worse than ugly: when posting thread is plain ungrammatical. --Florian Blaschke (talk) 20:52, 20 June 2024 (UTC)
 * That's my bad. Remsense  诉  20:15, 28 June 2024 (UTC)
 * I personally nuke these on sight and I can't recall even once getting any pushback for it. Primergrey (talk) 20:12, 28 June 2024 (UTC)
 * Same here. If we felt a need to mention it, it could be a single short sentence at MOS:AND/OR, but per EEng it doesn't seem necessary to do so at all.  — SMcCandlish ☏ ¢ 😼  04:40, 13 July 2024 (UTC)

Citations within quotes?
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. ""

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?

I found this at Lynn Conway, the quote that starts with "By taking this job". GA-RT-22 (talk) 16:23, 12 June 2024 (UTC)
 * WP:SAYWHEREYOUGOTIT - just cite A Great Book by Joe Sixpack, with page number. -- Red rose64 &#x1f339; (talk) 18:58, 12 June 2024 (UTC)
 * Exactly what I need. Thanks! GA-RT-22 (talk) 20:20, 12 June 2024 (UTC)
 * 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)

Citations are not part of the quoted material. They go at the end of the introductory material immediately before the block quotation, never 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.:

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 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)

Should orthographical variations be mentioned in place names
Title, should orthographical variants be included when place names are given? Traumnovelle (talk) 07:11, 19 June 2024 (UTC)


 * 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)
 * 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)
 * If ultimately attested in RS, I think this is worth mentioning, maybe in a footnote. Remsense  诉  07:35, 19 June 2024 (UTC)
 * 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)
 * It is mentioned in a reliable source as being used by a minority/officially. But reliable sources continue to use standard orthography. Traumnovelle (talk) 07:12, 13 July 2024 (UTC)
 * Well, an "official" claim that cannot be independently verified at all is just as unencyclopedic, I would think.  — SMcCandlish ☏ ¢ 😼  16:36, 13 July 2024 (UTC)
 * I removed it based on discussion on here. Traumnovelle (talk) 21:13, 13 July 2024 (UTC)
 * Can you give an example of what you're asking about? Largoplazo (talk) 10:23, 19 June 2024 (UTC)
 * The example is in my other comment. Traumnovelle (talk) 19:52, 19 June 2024 (UTC)
 * 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)

Indentation
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). — SMcCandlish ☏ ¢ 😼  05:23, 13 July 2024 (UTC)
 * What do you mean by "first-line indentation"? <b style="color:red;">E</b><b style="color:blue;">Eng</b> 17:21, 20 June 2024 (UTC)
 * Lewis Carroll - Alice's Adventures in Wonderland.djvu I suspect that refers to a common practice in printed books where the first line of a paragraph is indented by one or two em. -- Red rose64 &#x1f339; (talk) 20:40, 21 June 2024 (UTC)
 * Not really relevant for Wikipedia, though, it seems. Gawaon (talk) 20:58, 21 June 2024 (UTC)
 * That's a correct suspicion - see 's edit here, for example. Davidships (talk) 00:01, 22 June 2024 (UTC)
 * 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 . 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 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  (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  instead of manual markup. Sixth, for semantic emphasis, use  not   (MOS:EMPH).

Semi-protected edit request on 20 June 2024
A$ is similar to 'As'. So, change A$ to AU$. 70.22.248.187 (talk) 17:30, 20 June 2024 (UTC)
 * Red information icon with gradient background.svg 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)

Improvement to advice about embedded section anchors
I just made this edit to MOS section to add this explanatory note (name="many links") to the portion targeted by MOS:SECTIONANCHOR:
 * To find out how many inlinks there are to the old section title and what articles have them, you can execute this advanced search this advanced search, changing to the name of the article, and  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. Thanks, Mathglot (talk) 23:13, 26 June 2024 (UTC)


 * 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)
 * This would be better handled in its own section. Please see WP:VPT. Thanks, Mathglot (talk) 02:42, 28 June 2024 (UTC)
 * Look great, thanks! Better than my usual method, clicking through every page of the "What links here?" results and Ctrl-F-ing the old section title. Firefangledfeathers (talk / contribs) 11:55, 27 June 2024 (UTC)
 * Good info! Thanks for researching, documenting, and pinging. Quiddity (talk) 03:52, 28 June 2024 (UTC)

Note: updated the advanced search link ( new link ) to also handle templated links like slink, Further, Main, etc., without making it longer or scarier-looking. Mathglot (talk) 01:44, 28 June 2024 (UTC)


 * @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)
 * 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  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)
 * I meant that the link included, 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  is not* doing anything, try for example, searching for   vs without the   (but with all namespaces selected).
 * Edit: *It is doing something, if you select all namespaces it ignores them and searches only in article space. Hm. – 2804:F1...A9:64C1 (talk) 04:36, 28 June 2024 (UTC)
 * 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  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 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)
 * It has links outside of mainspace, that's why I said to remove the :all and select all namespaces. – 2804:F1...A9:64C1 (talk) 04:45, 28 June 2024 (UTC)
 * Thanks for that; I must've been assuming the wrong functionality for ; 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)
 * Ah, I found it, it is . – 2804:F1...A9:64C1 (talk) 04:56, 28 June 2024 (UTC)
 * Oops, of course it is; the colon goes at the end in every search term, don't know how that happened. Will go fix that. Mathglot (talk) 04:58, 28 June 2024 (UTC)
 * Okay, colon is in the right place now; try "Banana" again. Mathglot (talk) 05:04, 28 June 2024 (UTC)
 * It works, behaviour is consistent now, thank you, and for the info :). – 2804:F1...A9:64C1 (talk) 05:12, 28 June 2024 (UTC)
 * Thanks for your efforts, which have helped improve it. Mathglot (talk) 06:04, 28 June 2024 (UTC)

I made this edit based on recent observation. Correct me if I'm wrong. Biogeographist (talk) 20:57, 28 June 2024 (UTC)
 * 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)
 * There is also Database reports/Broken section anchors that could be checked, though only afterwards (and with up to one month's delay). Gawaon (talk) 21:16, 28 June 2024 (UTC)

Working out the best cross-namespace way to do this will be good, as would including advice about it somewhere. I would suggest making this be a "Help:" page or a section at a pre-existing one, and then cross-referencing it from MoS, rather than making it part of MoS (how to search for links of various sorts is not an MoS matter in and of itself). After it is worked out, using it to fix all links to MoS and other guideline and policy sections, and then removing no-longer-needed anchor tags and anchor spans inside headings in these pages would be a boon. — SMcCandlish ☏ ¢ 😼  05:27, 13 July 2024 (UTC)

Use of em dashes to join place names in naming electoral districts
Please see this discussion about the use of em dashes to join place names in naming Canadian electoral districts. – Jonesey95 (talk) 18:27, 27 June 2024 (UTC)

What tense should be used in articles about obsolete computers?
MOS:TENSE says:

"By default, write articles in the present tense..." and "Generally, use past tense only for past events, and for subjects that are dead or no longer meaningfully exist."

The page gives an example: "The PDP-10 is a mainframe computer family manufactured by Digital Equipment Corporation from 1966 into the 1980s."

There is a big discrepancy concerning tense in articles about old computers (Vintage computer). One issue is if they "meaningfully exist". Consider some one-of-a-kind computers:


 * The IAS machine is intact and exists in the collection of the Smithsonian (I saw it on display in 1967), but it is no longer on display and doesn't work.
 * ENIAC - all (or almost all) of the parts of ENIAC exist, but they are spread out among several museums and displays (I've seem most of the parts.)
 * Whirlwind I - a few parts still exist.
 * BINAC - I don't think any of this computer still exists.

Then there are computers of which many were made. There are several non-working examples (e.g. UNIVAC I) in museums (Computer History Museum and others). There are even a few working examples. The Living Computers: Museum + Labs had quite a few computers that were made decades ago and are still working.

Anyhow, I'm looking for guidelines about what tense should be used. Most of the articles use past tense for these old computers. Bubba73 You talkin' to me? 01:21, 28 June 2024 (UTC)

FWIW, the car articles are equally inconsistent. Ford Model T and Ford Model A (1903–04) use present tense. DeSoto (automobile), Imperial (automobile), and Plymouth (automobile) all use past tense. RoySmith (talk) 01:42, 28 June 2024 (UTC) :The above is not a technical question, AFAICT. Wikipedia talk:Manual of Style is probably the right venue for this inquiry. – Jonesey95 (talk) 06:15, 28 June 2024 (UTC)


 * OK, I'll move it when I have time. Bubba73 You talkin' to me? 15:41, 28 June 2024 (UTC)
 * If there's even one existing working example the guidance is pretty clear. Use present tense. There's even a strong case for non-working examples if their historic value is "meaningful" enough, but that's not so cut and dry. Primergrey (talk) 18:17, 28 June 2024 (UTC)
 * And regarding the automobile articles, the Ford ones are about models that do exist. The others are about companies that do not. Primergrey (talk) 18:21, 28 June 2024 (UTC)
 * For computers, I'd say that "no longer meaningfully exist" should be interpreted as "no working exemplars exist". If a running computer exists somewhere, its article should be in present tense, otherwise past tense. Indefatigable (talk) 18:18, 28 June 2024 (UTC)
 * It isn't always easy to tell if there is a running example somewhere. And when there is, they are usually in a collection to demonstrate it - it is not doing productive work anymore.  Bubba73 You talkin' to me? 21:33, 28 June 2024 (UTC)
 * Does it have to be doing productive work? Various sorts of steam engines are lovingly restored, maintained and displayed in all their gleaming, puffing glory; each one definitely exists though few are doing anything productive. NebY (talk) 00:59, 29 June 2024 (UTC)
 * Good point. If it is working, then it "meaningfully exists".  Bubba73 You talkin' to me? 01:28, 29 June 2024 (UTC)
 * The oldest computers had little concept of the time of day. But more recent models came to depend more and more on time of day. Many of these middle-aged computers still "work" but won't work correctly because Y2K messed them up and rather than fix them, they were retired. Perhaps the most widespread examples are (were?) the earlier members of the IBM PC line. So they only work if you lie about the date. Jc3s5h (talk) 13:39, 29 June 2024 (UTC)
 * Sometimes people only work if you lie about the date they'll be paid (or how much, their prospects and working conditions, what you'll do to their families, that sort of thing). NebY (talk) 16:35, 29 June 2024 (UTC)
 * It depends on what the meaning of is is. Mathglot (talk) 22:02, 28 June 2024 (UTC)
 * Or it depends of what the meaning of meaningful is. Bubba73 You talkin' to me? 01:29, 29 June 2024 (UTC)

And, as an example, the page uses present tense for the family of PDP-10 computers manufactured from 1966 to the 1980s. It is very unlikely that any particular one of them is still running and doing productive work, but the recently closed Living Computer Museum had five working ones. Bubba73 You talkin' to me? 00:51, 29 June 2024 (UTC)


 * Size and power costs make it unlikely that historical computers are doing productive work. But if I can go to a museum and see a complete one, even in a non-working state then I would definitely say that computer "is". Same for mostly complete (say 80-90%) machines. Less than that gets murky. Parts spread over different locations is probably "was" but may be gathered back into a (near) whole machine again. But there isn't any real consequence of getting this wrong. So, I'd just say that any machine physically near complete (say 80% or better) in a single location, working or not is a computer still in existence and anything else is no longer in existence. For the borderline cases, flip a coin and move on with life.  Stepho  talk 02:07, 29 June 2024 (UTC)
 * Something like the GE-200 series, I have no idea if one still exists. Bubba73 You talkin' to me? 02:32, 29 June 2024 (UTC)
 * Most often the name of a computer refers to the definition of its architecture. There are no "PDP-10" computers, but there are the KA-10, KI-10, etc. But there are books that describe the architecture of the PDP-10, and those books exist. Some architectures never existed. The general rule is that events (in the past) are past tense. Computers were designed, introduced, sold, rented, and such, in the past. Note, for example, that Shakespeare's plays are present tense, even though he is dead, and even though one might not be being performed. Since the written form exists, they should be present tense. And if the documentation for a computer architecture exists, it should be present tense. If no processors exist, and no documentation exists, it could be less obvious. But best then to just write in terms of an event. The Burroughs B5500 was designed and sold by the Burroughs corporation. That works even if none exist. Gah4 (talk) 02:39, 29 June 2024 (UTC)
 * Published works are treated under their own special guideline; they are not general cases from which to extrapolate.  — SMcCandlish ☏ ¢ 😼  07:02, 13 July 2024 (UTC)
 * Generally, use present tense, since the machines almost always still exist somewhere in operating form. We should only use past tense for something totally defunct or no longer meaningfully existent. For some of the examples given above, like BINAC and some other defunct unique machines, past tense would be appropriate.  — SMcCandlish ☏ ¢ 😼  07:04, 13 July 2024 (UTC)

Ref quotes with inline citations
Over at the article Dysgenics, recently removed a quote from within a reference, leaving the edit summary AFAIK not allowable as there are incomplete citations in the quote. Here is the complete quote: "Since the nineteenth century, a 'race deterioration' has been repeatedly predicted as a result of the excessive multiplication of less gifted people (Galton 1869; see also Fig. 9.1). Nevertheless, the educational and qualification level of people in the industrialized countries has risen strongly. The fact that the 'test intelligence' has also significantly increased (Flynn 2013), is difficult to explain for supporters of the dysgenic thesis: they suspect that the 'phenotypic intelligence' has increased for environmental reasons, while the 'genotypic quality' secretly decreases (Lynn 1996, p. 111). There is neither evidence nor proof for this theory."

I reverted with the edit summary What policy is that? This quote is clearly helpful to the reader. And Biohistorian15 reverted my revert with the summary https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Quotations does not seem to suggest it. If it is relevant, you should rewrite it in your own words.

I tried to engage on the talk page, suggesting for instance that we might replace the incomplete inline citations with ellipses, but was met with insistence that this quote be paraphrased, despite the fact that we do not (as far as I'm aware) paraphrase within refs.

So my question to the community is whether the best practice in a case like this would be to

1) include the quote as written,

2) include the quote but replace inline citations with ellipses,

3) exclude the quote altogether,

or 4) something else entirely.

Thanks! Generalrelative (talk) 18:45, 29 June 2024 (UTC)


 * I can't judge whether the quote is useful in general, but assuming it is, I would suggest option 2 (replace the inline citations with ellipses). Gawaon (talk) 19:45, 29 June 2024 (UTC)


 * Another option is to write "(citations omitted)" outside of the quote. Compared to using ellipses, this has the advantage of making it clear that the quoted sentences were sequential in the original, with no important statements omitted and no deceptive juxtapositions created. It also lets readers know that citations are available to be chased down if needed. Jruderman (talk) 01:06, 2 July 2024 (UTC)
 * I like that idea. Thank you! Generalrelative (talk) 12:57, 2 July 2024 (UTC)
 * I went to make this change but ran into two snags. First, the template automatically puts quote marks around the entire   parameter. This is suboptimal, but I guess we can write "[citations omitted]" (with square brackets) if it has to be inside the quote marks. The second problem is that WP:FOOTQUOTE calls for exact quotations, so I'm now less certain that leaving out the citations is within policy. Nevertheless, I still think this is the clearest way to present the quote, so I'll probably make this change in a few days unless this discussion moves in another direction. Jruderman (talk) 07:04, 3 July 2024 (UTC)
 * You could put it in square brackets after the page number. However, it's also my understanding that any omission needs to be marked using an ellipsis (both following our own conventions and common style guides), so you'll need these ellipses regardless of whether or not you add that comment. Frankly, since we're writing for a general audience and few to none readers will care for the reason of the omission anyway, I'd tend to just use the ellipses without further explanation. Gawaon (talk) 07:47, 3 July 2024 (UTC)
 * You guys are worrying too much. No ellipses needed. See this CMOS FAQ. (which also disposes of the "It also lets readers know that citations are available to be chased down if needed" argument as well, appealing as that one is.)  <b style="color:red;">E</b><b style="color:blue;">Eng</b> 08:14, 3 July 2024 (UTC)
 * A point in support of the "No ellipses needed" position: we're only having this discussion because we're quoting a book written with in-text citation style. If it had been written using footnote style, omitting the footnote numbers would be uncontroversial. Jruderman (talk) 08:42, 3 July 2024 (UTC)
 * The FAQ entry refers only to footnotes, though. Footnotes are generally omitted, since in fact, there is no good way to NOT omit them. In-text citations are a different thing though. Yes, it's kinda ironical that these need to be treated differently even though the difference is ultimately just one of layout, but there you go. Footnotes can be omitted without comment, parenthetical notes (whether or not they contain literature references or anything else) need an ellipsis to mark the omission. I have yet to see a style guide, CMOS included, that would say anything else. Gawaon (talk) 10:19, 3 July 2024 (UTC)
 * parenthetical notes (whether or not they contain literature references or anything else) need an ellipsis – Disagree. If we're quoting source S1, which has parentheticals which do nothing beyond citing sources Sx, Sy, and Sz, and Sx,y,z themselves are not part of what S1 is discussing (S1 weighing their relative reliability, for example), then the parentheticals can be silently dopped. Adding (citations omitted) after the quotation (or putting that in our own footnote citation to S1) might or might not be a good idea depending on subtle considerations.
 * Let me point something out. If S1 simply read:
 * The sun is very big, but the moon is not as big (Smith, 1999).
 * We'd quote that without the parenthetical with no twinge of conscious. But we're apparently having this conversation because S1 reads ...
 * The sun is very big (Jones 1995) but the moon is not as big (Smith, 1999).
 * Why is it a sin to remove Jones silently but OK to remove Smith silently? <b style="color:red;">E</b><b style="color:blue;">Eng</b> 13:28, 3 July 2024 (UTC)
 * I agree it's a good practice to silently omit inline citations in quotations, but I think there is enough doubt and diverse practice in the editor community that it would be good to include something in the "Manual of Style". Jc3s5h (talk) 13:36, 3 July 2024 (UTC)
 * The "sin" thing is a rhetorical question, right? Ellipses at the start or end of a quote generally aren't needed, because nobody will assume that the original starts/ends there. But omissions in the middle are marked, that's what's  is for. Of course, depending on how you quote, you won't need any ellipsis, for example, writing Current consensus is that "the sun is very big", while "the moon is not as big". would be perfectly fine. Gawaon (talk) 15:42, 3 July 2024 (UTC)
 * An ellipsis shows where something of the author's text has been omitted. A parenthetical citation isn't that, any more than a superscript note number is. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 17:37, 3 July 2024 (UTC)
 * Just like we aren't bound to preserve typographical styles in sources (MOS:CONFORM), I don't think we should be bound by citation styles. Jruderman (talk) 11:01, 3 July 2024 (UTC)
 * I don't think we're even talking about the possibility of including the full citation in a quote, especially if using the quote parameter of one of the citation templates. I think we're talking about whether we can silently omit a footnote number or parenthetical citation, while omitting the full bibliographic entry.
 * A topic for another day would be what if the author quotes one of the same sources that's cited by the Wikipedia article? Jc3s5h (talk) 16:08, 3 July 2024 (UTC)
 * Footnote numbers can be silently omitted, we have already established that and I don't think there's disagreement on that front. Omitting citations in parenthesis will require either an ellipsis or maybe an "citation(s) omitted" after the quotation or page number. Either option seems acceptable, but personally I'd point out that even several ellipses will be shorter than a "citation(s) omitted" comment. Gawaon (talk) 16:44, 3 July 2024 (UTC)
 * I'd prefer ["citation(s) omitted]" because ellipsis leave the reader wondering if what was omitted might have changed the meaning. Of course, if you don't read the source yourself, you're still trusting the editor to copy correctly. Jc3s5h (talk) 17:10, 3 July 2024 (UTC)
 * Exactly. Also, the "citations omitted" can be relegated to our citation, thus. That should make everyone happy. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 17:37, 3 July 2024 (UTC)
 * Fair enough, though omitting something in such a way that it significantly changes the meaning is not allowed by any citation style. Gawaon (talk) 18:04, 3 July 2024 (UTC)
 * Well DUH, of course. But I think what Jc3s5h more means is, ellipses signal that something of substance was omitted -- some detail not germane to the purposes of our article, for example -- so the interested reader can go chase that down in the original if he wants. How disappointing to find that it's just a parenthetical citation -- something which, if the publisher had a different house style for calling out citations (superscript numbers, for example), would have been omitted in complete silence. When you quote someone it's assumed you're not necessarily reproducing all the citational apparatus your source relied on -- your reader will have to go to your source in order to find out exactly what that is. It's not part of the source's words in the same way that, well, their words are. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 20:11, 3 July 2024 (UTC)
 * I really like your solution, EEng. I'm going to implement this. We'll see if the editor who originally removed the quote feels the need to drag this out further Generalrelative (talk) 20:46, 3 July 2024 (UTC)
 * Tend to agree. However, I would not get in a big dispute with someone about replacing the inline citations with ellipses. What we don't want, either way, is to include inline citations in quoted material if we are not informing the reader of the details of those cited sources. Sometimes it is actually better to do exactly that, with something like  (or using one of the multi-source citation templates). This is most important in cases such as: a) the source being cited is not from a known subject-matter expert, but is relying on sources that are and which are ultimately of more in-depth importance to citation-checking readers; b) the source being cited is summarizing a debate and we care more about the sides in that debate and who is behind them than in the summary of them; or c) the citations behind the material are ones we are already using for other purposes in the same article (in which case we would better secondarily cite them in that compound ciation with  or one of its variants, instead of repeating the entire citations).  — SMcCandlish ☏ ¢ 😼  06:59, 13 July 2024 (UTC)



"Modern-day Israel" vs. "Palestine" when only for reader geographical reference
While doing recent changes patrol, I recently saw a drive-by IP edit changing a page that referred to a historical place as being in "modern-day Israel" to say "occupied Palestine" that I wasn't sure how to respond to. Someone else reverted it, and while that was probably the most straightforward and reasonable response, it did get me thinking, and I've poked around in the MOS itself and the archives here without much luck: has there ever been any sort of discussion on the appropriate terminology to use between modern-day Israel/present-day Israel/etc. and Palestine, as in the geographical region, when the description is a purely geographic one to describe to the reader where something was or is?  Kinsio  ( talk  ★  contribs ) 14:34, 30 June 2024 (UTC)

Notified: Wikipedia talk:WikiProject Palestine, Wikipedia talk:WikiProject Geography, Wikipedia talk:WikiProject Asia, Wikipedia talk:WikiProject Jewish history, Wikipedia talk:WikiProject Israel, Wikipedia talk:WikiProject Ottoman Empire, Wikipedia talk:WikiProject British Empire, Wikipedia talk:WikiProject Limited recognition. Reason: Participants may have specific experience editing relevant articles. Kinsio ( talk  ★  contribs ) 15:59, 30 June 2024 (UTC)
 * I'd say that when it comes to describing the geographic location, modern-day Israel / modern-day West Bank / modern-day Gaza Strip (or similar) are the straightforward terms to use, depending on which one it is. Palestine as a unified territory existed only from 1920 to 1948 (Mandatory Palestine), so using the term to refer to anything earlier than that would be an anachronism. Gawaon (talk) 15:05, 30 June 2024 (UTC)
 * A further complication is that both the Mandate of Palestine and Syria Palaestina encompass territory East of the Jordan. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:17, 30 June 2024 (UTC)
 * We do have guidelines for some of that region, Naming conventions (West Bank), the formation of which was monitored by WP:ARBCOM. NebY (talk) 15:28, 30 June 2024 (UTC)
 * (and cc ): I guess I'm not quite articulating clearly what I'm asking here. I get that the modern-day forms are the most straightforward. I guess what I'm really wondering is, would describing something (with no particular reason to be associated with a particular present-day state as such) as located in Palestine, clarifying perhaps with a link to Palestine (region), be considered something to avoid? That's how I refer to things colloquially and I'm not sure if that'd be considered a potential issue in an article.  Kinsio  ( talk  ★  contribs ) 15:32, 30 June 2024 (UTC)
 * I would say that you should avoid ambiguity. Use wording that makes it clear whether you are including land East of the Jordan and whether you are including land in present-day Israel. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:45, 30 June 2024 (UTC)
 * I agree with this. It is unlikely it provides much clarity to readers, as even if they do know about the geographical usage of Palestine that doesn't mean they expect it to be the default meaning. 'Geographic areas' which stem from historical polities tend to cause these issues with ambiguity when modern polities take the older name. Macedonia (region) is another example that still causes political disputes today. CMD (talk) 15:54, 30 June 2024 (UTC)
 * "Modern-day X"/"Present-day X" are not uncommon phrases. I don't think there is anything particularly unique about application (or not) to Israel/Palestine (although considerations regarding borders may add complications as they do in some other parts of the world). Troy for example, states it is "an ancient city located in present-day Hisarlık, Turkey." CMD (talk) 15:10, 30 June 2024 (UTC)


 * Not to be draconian, but I think it's worthwhile to make sure @Kinsio is aware that since the Arab–Israeli conflict has been designated as a contentious topic subject to active sanctions, generally non–extended confirmed users are restricted to suggesting specific changes to articles in their discussions relating to the subject on-site. I'm not saying that should be imposed here, I just feel it's worth making aware. Remsense  诉  18:30, 30 June 2024 (UTC)
 * I'm so close to making my signature something like  Kinsio  is XC, I promise, you guys  . This keeps happening, I guess people are willing to click on contribs to see my account is new but not on talk to see the notice about this I put there. I'm even the one who put that ECR warning at the beginning of this section 😭  Kinsio  ( talk  ★  contribs ) 18:59, 30 June 2024 (UTC)
 * Apologies! Remsense  诉  19:08, 30 June 2024 (UTC)
 * It's fine, I know it's not intentional haha. I think I did come up with a way that makes sense to draw attention to this in my signature though, do you think this will help?  Kinsio  (talk ★ contribs ★ rights) 19:24, 30 June 2024 (UTC)

Re Kinsio's would describing something (with no particular reason to be associated with a particular present-day state as such) as located in Palestine, clarifying perhaps with a link to Palestine (region), be considered something to avoid?: If you want to refer to the time and place of Mandatory Palestine, use that name and link. I think Palestine without adornment is too ambiguous. I think for before then, the name to use is Ottoman Syria. —David Eppstein (talk) 16:35, 30 June 2024 (UTC)
 * Ottoman Syria is not a good designation for the later Ottoman period. From the 1880s onwards the Vilayet of Syria was all east of the Jordan River. For at least a century before that, "Palestine" was the most common designation in European sources. It's true that "Syria" was also used, but the extent of "Syria" was much broader, approximately what would be called the Levant today, and "Palestine" was the southern part, as in this 1794 map. Also see Jacotin's 1799 map, published 1818. A correct designation is "Ottoman Palestine", but the "Ottoman" part is redundant as there was no Palestine apart from the Ottoman one.  Zerotalk 07:44, 1 July 2024 (UTC)
 * Mandatory Palestine. Gonnym (talk) 08:16, 1 July 2024 (UTC)
 * I'd add a "citation needed" to the claim that "For at least a century before that, "Palestine" was the most common designation in European sources." And even if true, how relevant would it be? I'd say that the locally used name is more relevant than what people in other countries used. Hence, in addition to the "modern-day" equivalents, it's probably most reasonable to use the official Ottoman designations for the Ottoman area. Gawaon (talk) 08:53, 1 July 2024 (UTC)
 * Actually we are supposed to use common English names where available. That's why articles have "Rome" and not "Roma". Go to Google Books and search for "Palestine" in the 19th century. 18th century too. Also try "Palästina" for German sources (which is what the Zionist movement called it). Also try "Syria and Palestine" and "Palestine and Syria" to check if they were considered equivalent. (Most times Palestine was considered a part of Syria, but often they were considered separate.) Zerotalk 13:10, 1 July 2024 (UTC)
 * Maybe just go by what (scholarly) sources say? If they say located in what is today Israel, then go with that and if it says in Palestine then that and wikilink appropriately, Palestine or Palestine or Palestine. Ottoman Palestine is quite common in sources. Also fairly common is Roman Palestine (Syria Palaestina) One phrase that can cause trouble is "historic(al) Palestine", might be as well to avoid that. Selfstudier (talk) 10:16, 1 July 2024 (UTC)
 * Yes, Roman Palestine should be fine for the 2nd to 4th centuries, and Judaea for the time before that. Though both of these are quite long back. Gawaon (talk) 10:27, 1 July 2024 (UTC)

Recent harmful changes
I noticed that some long-standing wording was recently changed by User:Remsense, without any clear motivation to do so and without any consensus established to make the changes. The most relevant diff is this. I find the revised text to be much less clear and much less useful. I suggest that the change be reverted. Other edits by the same editor may also be questionable.

Another harmful change was made by User:Altenmann, not a native speaker of English but nevertheless one who feels confident enough to declare that there is "no such thing" as using "she" generically. They removed the text again, which seems purely disruptive. This relevant information should be restored to the article.

Thanks. 217.198.133.44 (talk) 08:29, 7 July 2024 (UTC)


 * If any of my edits are not evident improvements, I apologize and agree they should be reverted. I've taken care not to make trifling changes, only those that present the guidelines cleanly and concisely without changing their meaning. Some word choices may require explanation on my part, but intrinsically is saying a lot about the content of topics, while necessarily only concerns the process of describing them, which seems more appropriate. Remsense  诉  13:44, 7 July 2024 (UTC)
 * Honestly, they are more wordy and not really an improvement. Good edits to the MoS, except for those that are specifically intending to introduce a new guideline, almost invariably reduce the number of characters. MapReader (talk) 15:08, 7 July 2024 (UTC)
 * Agreed. Most of my other edits to MoS pages are in line with this, but I couldn't quite figure out how to rephrase this one in fewer characters in the moment. Remsense  诉  15:09, 7 July 2024 (UTC)
 * Concerning removal of generic she, which is coded as generic she, I think the explanation at the target wikilink is inadequate and we should do better if we are to retain this language. generic she is a redirect to Gender neutrality in languages with gendered third-person pronouns#Generic she which dumps the reader at the "Generic he" section because "Generic she" is an anchor for that subsection. Upon reading the article, it is a struggle to find anything about generic she. Jc3s5h (talk) 17:29, 7 July 2024 (UTC)
 * My apologies about generic she: the wikilink was misleading; I merely requested reliable source about generic she. Of course I am nonnative speaker, so I wanted to read about "generic she" and found that the wikilink "generic she" does not lead to the information about it. Now I fixed the wikilink "generic she". - Altenmann >talk 17:36, 7 July 2024 (UTC)
 * The article section to which generic she redirects needs to be updated to account for activistic writing in which traditional/obsolete "generic he" is intentionally replaced with an equal-but-opposite "generic she" just to make a point. This is actually quite common among a certain set of leftist writers over the last generation or so, and should be accounted for. However, it's not something WP should ever be doing in its own voice. Just use gender-neutralized sentence structures (often simply converting to a plural form is sufficient, in enabling a generic they/them/their construction).  — SMcCandlish ☏ ¢ 😼  07:23, 13 July 2024 (UTC)
 * Or just by using the generic singular they/them/their. Gawaon (talk) 07:46, 13 July 2024 (UTC)
 * Too many (mostly older) editors and readers disagree with using that if it can practically be avoided (i.e., if you do that, someone will probably change it later). And it usually can be avoided, with virtually no effort, when not writing about trans/enby subjects. There is no reason to write "For this conference, an author will have their paper peer-reviewed twice" when "For this conference, authors will have their papers peer-reviewed twice" will do better (as will a number of other alternatives like "All papers are peer-reviewed twice before being approved for this conference", etc., etc.). The rewritten versions will not make any reader mentally rebel in mid-sentence, unlike the singular-they version. WP is not a platform for advocacy or enforcement of any still-in-progress language change / usage shift, especially one that is heavily politicized in the real world.  — SMcCandlish ☏ ¢ 😼  17:38, 13 July 2024 (UTC)

Hyphenation
We're discussing the wording of a sentence in Wikipedians on its talk page. (Y'all come, if you want, but that's not my question for you.)

It started off as "higher-volume experienced editors", which is correct. It is presently "more-experienced editors". I wouldn't (in American English) put a hyphen there, but is it actually wrong, or just unnecessary? WhatamIdoing (talk) 23:11, 7 July 2024 (UTC)
 * Well it depends on whether you want editors with more experience to join or if you just want some additional old lags. [As in "ten more-experienced editors" v "ten more ... experienced editors"]. That do? --𝕁𝕄𝔽 (talk) 23:43, 7 July 2024 (UTC)
 * JMF is correct. That particular sort of hyphen is sometimes unnecessary, but only if the meaning could not be altered or become ambiguous by its removal. There are many constructions in which such ambiguity will exist for at least some readers, so the hyphen should be retainined in such cases, or the entire construction rewritten. "I prefer a more flavo[u]rful soup than plain chicken stock" needs no hyphen after "more" because no ambiguity is plausible. In "I would prefer to have more-flavo[u]rful soups in my diet", the version with no hyphen will mean (to many if not most readers) "I would prefer to have more soups in my diet, and that they be flavo[u]rful", while the version with the hyphen means (to everyone) "I would prefer that the soups in my diet were more flavo[u]rful".  — SMcCandlish ☏ ¢ 😼  06:44, 13 July 2024 (UTC)

Articles referring to themselves
Is there any policy relating to articles referring to themselves in prose? Such as "This article is about…"? ꧁ Zanahary ꧂ 00:13, 8 July 2024 (UTC)


 * I don’t think we have a policy about it… but I would say it is poor writing. Try to reword. Blueboar (talk) 00:35, 8 July 2024 (UTC)
 * Do you have any convenient way to avoid self-reference in situations where an article describes multiple notational conventions and then goes on to say that our article uses one particular choice of these notations? For that matter, would you care to describe how our standard wording on hatnotes and disambiguation page footers ("This disambiguation page lists...") might be rewritten to avoid self-reference, and why such a rewrite would be an improvement? —David Eppstein (talk) 00:43, 8 July 2024 (UTC)
 * Maybe I’m misreading your tone David Eppstein, but I am only asking a question, because I don’t know its answer.
 * Disambiguation pages are already self-referential, since their titles refer to their natures as pages. Articles are typically not. Antisemitism's early footnote about "anti-Semitism" may be an example for your question, if I understand it correctly. ꧁ Zanahary ꧂ 01:00, 8 July 2024 (UTC)
 * "The International Holocaust Remembrance Alliance has stated that the spelling without hyphenation is preferred, because the spelling with hyphenation implies that "Semitism" is a valid concept"?
 * How is that a reference to the Wikipedia article? WhatamIdoing (talk) 01:33, 8 July 2024 (UTC)
 * I’m saying that it is not. It explains the choice of notation among some options without referring to the article. ꧁ Zanahary ꧂ 02:51, 8 July 2024 (UTC)
 * As an example for the question Do you have any convenient way to avoid self-reference in situations where an article describes multiple notational conventions and then goes on to say that our article uses one particular choice of these notations?. The reason for the article’s choice is implied without saying “This article uses…” ꧁ Zanahary ꧂ 02:52, 8 July 2024 (UTC)
 * The article's choice may be entirely arbitrary, but still a choice must be made for consistency. It is often better to inform readers what choice has been made than to let them guess. An example: in dihedral group (a technical concept in mathematics), there are two different common and standard notations, where the notation D6 would mean one group to geometers and a different group to algebraists. (It's not a good situation but we can't change it.) Unlike your hyphenation example, if you just see the notation D6 without an explanation, there is no way of telling which convention it uses. We have to use one, so we tell the readers which one we are using. The sentence saying so begins "This article uses the geometric convention".
 * As for tone: this thread had the tone of encouraging rules-warriors to chime in and strictly forbid all uses of self-reference, even in such cases. I wanted to provide a counterpoint. —David Eppstein (talk) 06:06, 8 July 2024 (UTC)
 * MOS:LEAD discourages certain forms of self-reference, though not all. Nikkimaria (talk) 04:04, 8 July 2024 (UTC)
 * Do you have a quotation? I looked and can’t find the relevant guideline. ꧁ Zanahary ꧂ 04:12, 8 July 2024 (UTC)
 * "If the article title is merely descriptive—such as Electrical characteristics of dynamic loudspeakers—the title does not need to appear verbatim in the main text. Similarly, if the page is a list, do not introduce the list as "This is a list of X" or "This list of Xs.....Avoid constructions like "[Subject] refers to..." or "...is a word for..." ". Nikkimaria (talk) 04:24, 8 July 2024 (UTC)
 * A bit of caution: if an article is about a word, then "...is a word for..." or "...is a word for...", etc. is almost always inavoidable. Schlemiel, Oy vey, Mazel tov... (unless forced to jump artificial hoops) - Altenmann >talk 06:40, 8 July 2024 (UTC)

To comment on this entire thread at once: This is generally covered at WP:SELFREF. More specifically, we make use of explicit selfrefs, of the "this article" sort, pretty often. E.g., they are virtually required by WP:LISTCRITERIA for explaining the inclusion criteria of a non-exhaustive list. Many of them in non-list articles can be avoided by sensible writing, but not all of them can, and that is okay. Cross-reference selfrefs like "See X" or "covered in &sect; SectionName" or "illustrated below" or whatever, can often be avoided by using contextually embedded links, but not always, and that's also okay. They should be marked up with (shortcuts  or ) if they go from one article to another, or with  (short form: ) if within the same article. Next, if it's helpful to say "below" or "above", then do it, though often just contextually linking to a section or anchor obviates that. Anyone who feels the urge to radically restructure an article by moving entire sections around has an affirmative duty to reread the article again and make sure they've not made a hash of it. But we should not use "left" or "right" in reference to content blocks, because rendering positions of such elements can change due to browser behavior, especially on mobile devices. PS: "X is a word for Y" it not almost unavoidable in articles about terminology. Various other constructions often work much better, though they may differ widely by context, e.g.: "X, in archaeology, is the principle that Y"; "X is a French loan-word that in English usage conveys Y, though literally meaning 'Z' in French"; "X is a neologism coined in 2013 by Jay Randome Bloggeur to mock the socio-political stances of Y"; and so on. — SMcCandlish ☏ ¢ 😼  17:22, 13 July 2024 (UTC)
 * Anyone see a way to avoid this self-ref? <b style="color:red;">E</b><b style="color:blue;">Eng</b> 10:55, 8 July 2024 (UTC)
 * I don't feel there's any problem with an explanatory footnote explaining something about the article, just as hatnotes do. It's just the textthe actual articlethat shouldn't. Largoplazo (talk) 21:21, 8 July 2024 (UTC)
 * In that particular case, the best place was a footnote because the issue is worth noting but uncontroversial, but I'm not sure that's always the case. I can imagine a situation in which it's necessary to surface the issue to the reader more openly, and then mention as an aside that the remainder of the article adopts the such-and-such convention. And that might be best done in the text. I don't see why it's such a big deal. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 23:04, 8 July 2024 (UTC)
 * The simple way to avoid that selfref would be to just delete the closing "this article follows Macmillan[M]: 122n15  in correcting those dates, each of which carries this annotation". Since all the dates in question bear this footnote, and the footnote explains the situation, that closing bit is not strictly necessary. However, it's actually clearer with it present, and such clarifying selfrefs are not verboten in the first place.  — SMcCandlish ☏ ¢ 😼  17:22, 13 July 2024 (UTC)
 * Thing is, not all dates in the article are adjusted, because most don't need adjusting. So the purpose of the note, and its closing, to tell that reader how he can determine which specific dates were adjusted i.e. it's those that carry the note. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 21:10, 13 July 2024 (UTC)
 * To me that seems like hatnote material. Largoplazo (talk) 11:11, 14 July 2024 (UTC)
 * @EEng, I think the confusion comes from people thinking that SELFREF goes well beyond what it actually says. SELFREF says not to write "This Wikipedia article discusses...", but the prohibition is on including the word Wikipedia.  SELFREF directly says that articles may refer to themselves; they just can't refer to Wikipedia.  "This article discusses..." is acceptable, and so is the footnote that you link.   This section of SELFREF has a little blue box that says:
 * ✅ This article discusses...
 * This Wikipedia article discusses...
 * A plain old "This article" is officially endorsed by the style guideline. [User:WhatamIdoing|WhatamIdoing]] (talk) 18:43, 13 July 2024 (UTC)
 * WP:SELFREF Largoplazo (talk) 11:04, 8 July 2024 (UTC)
 * Another place I find problems with that is when articles say something like "As described in the previous paragraph..." or "As in the illustration at right...". Well, of course, articles can be edited, so if someone changes the previous paragraph or the image, stuff like that will become nonsensical, and whoever does that edit might not know to update or remove those references to whatever they're editing. Seraphimblade Talk to me 02:41, 9 July 2024 (UTC)
 * MOS:SEEIMAGE applies; it was originally written because of accessibility concerns, but mobiles and other narrow-screen devices have shown us that images might not be displayed where they were expected to be. -- Red rose64 &#x1f339; (talk) 07:40, 9 July 2024 (UTC)
 * I think this is a case where it's more heuristic than anything: there's absolutely nothing wrong in itself with having "see §XYZ" in running text; however, if one really feels the need to include that, there might be a deeper problem with the piece's structure. Remsense  诉  02:55, 9 July 2024 (UTC)

Tense of verbs referring to current, ongoing events
Greetings, all. The Manual of Style contains this direction: "By default, write articles in the present tense, including those covering works of fiction and products or works that have been discontinued. Generally, use past tense only for past events, and for subjects that are dead or no longer meaningfully exist."

Yet, a number of biographical articles about living peopleuse the present perfect tense when referring to persons currently serving in various capacities of public life. E.g. "George has served since July 10, 2024," which, at the very least creates confusion between an ongoing situation and a past one.

I propose we move to the use of the present perfect continuous tense (also known as the present perfect progressive tense), which would result in a clear and unambiguous presentation:

"George has been serving since July, 10 2024."

Opinions? -The Gnome (talk) The Gnome (talk) 09:48, 10 July 2024 (UTC)
 * Personally, I think the first option reads much better than the second. Not confusing or ambiguous in any way. Perfectly normal English. No idea if this is a WP:ENGVAR issue, but that's certainly what I'd write (I write in British English). -- Necrothesp (talk) 12:33, 10 July 2024 (UTC)
 * I write in American English and I agree that for the example provided, "has served" is preferable to "has been serving". Either would be acceptable, but I don't see a reason to encourage the latter, nor do I see how the former is ambiguous. If it was a past situation, would it not be, "George served from July 10, 2024 until..."? DonIago (talk) 14:01, 10 July 2024 (UTC)
 * What do you mean "it reads much better"? This is not about aesthetics, but about clarity. We're talking about current, ongoing events, exactly what the relevant MoS section is about. "Have [verb in past tense]" is unnecessarily ambiguous. Simple present would suffice. But since it has through some back handed way become the norm to use "has served" for people in public life, a turn  that smells of puffery, as well, I'm suggesting something simple and sensible. It's a compromise between the simple present tense and the peacock. -The Gnome (talk) 16:57, 10 July 2024 (UTC)
 * "Has served" is not in the past tense and creates no ambiguity. Someone who has served in a position since February is unambiguously still in that position. There is no need to change "has served" to "has been serving", and parsimony weighs against it. AlsoWukai (talk) 18:28, 10 July 2024 (UTC)
 * I really have no idea why you think there is a lack of clarity or any puffery in "has served", which is completely normal English. Mystifying. -- Necrothesp (talk) 09:38, 11 July 2024 (UTC)


 * While we're talking specifically about "persons currently serving in various capacities of public life", how about dropping the whole "serving" idea entirely? It's meaningless excess:
 * "George has been serving as chairman of Globcorp since 2014" --> "George has been chairman of Globcorp since 2014"
 * "George has served as chairman" --> "George has been chairman"
 * "He served as" --> "He was"
 * "He serves as" --> "He is"
 * See the brilliant and justly celebrated essay WP:AREYOUBEINGSERVED. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 15:07, 10 July 2024 (UTC)
 * Plus one to that — it adds nothing except a deferential tone. Popcornfud (talk) 16:04, 10 July 2024 (UTC)
 * Agree. I could not support more strongly the entire elimination of the verb "to serve" in all these cases, which are the ones that gave cause for this submission. "Keith Starmer is the prime minister." No deference, no confusion. -The Gnome (talk) 16:57, 10 July 2024 (UTC)
 * And remember ... "To serve man ... It's a cookbook!" <b style="color:red;">E</b><b style="color:blue;">Eng</b> 19:16, 10 July 2024 (UTC)
 * This is serving as a reasonable response to me! DonIago (talk) 19:56, 10 July 2024 (UTC)
 * Bon appétit! Gawaon (talk) 20:24, 10 July 2024 (UTC)


 * This is addressed at Manual of Style/Dates and numbers (MOS:CURRENT), which begins Except on pages that are inherently time-sensitive and updated regularly and has among its examples "not she is the current director but she became director on 1 January 2024". Manual of Style/Words to watch has the example The information that "The current president, Alberto Fernández, took office in 2019", or "Alberto Fernández has been president since 2019", is better rendered "Alberto Fernández became president in 2019". Saying that George was appointed, elected, took office or merely became foo on 10 July 2024 will remain correct even when George eventually suffers termination or promotion, and works without any value-laden terms such as "serve" or "tyrannise". NebY (talk) 13:56, 11 July 2024 (UTC)
 * All great points. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 20:49, 11 July 2024 (UTC)
 * I wholeheartedly agree with all the points you made, NebY. -The Gnome (talk) 18:13, 12 July 2024 (UTC)
 * I concur also. At some point, we probably do need to directly address the "served as" language in particular, because disputation about this has been frequently recurrent for many years (i.e., it passes the WP:MOSBLOAT test). But it's something that belongs in MOS:WTW, not the main MOS page or MOS:BIO, because it's not a general editing principle, really, but a trivial matter of a particular biased and unhelpful wording choice.  — SMcCandlish ☏ ¢ 😼  16:56, 13 July 2024 (UTC)
 * The Gnome, were you perhaps thinking that "present tense" in this rule meant "specifically and exclusively the simple present"? It doesn't.  Any present-tense form is acceptable under this rule.  That means you can – when appropriate to the content – use the simple present, present perfect, present continuous, or present perfect continuous and still be in compliance with this rule.  Perhaps a more accurate rule would be "use the verb tense that accurately reflects time; do not say that 'He is born in the 19th century' or that 'He will be born in the 19th century'; also, do not say that 'Algebra was a branch of mathematics', as if that's not still true at the present time."  We aren't trying to restrict brilliant prose with this rule; we're trying to get people not to use the present tense for long-dead people or the past tense for still-living ones.  WhatamIdoing (talk) 18:57, 13 July 2024 (UTC)
 * The mere fact that you are, rightfully, trying to clarify the application of the proper tense shows that interpreting the "meaning" of the term "present tense" leads to speculation. There is no endorsement of "any" present-tense form; if it were so, the definition would be different, i.e. "any present-tense form." All we have is simply "present tense," which leads to the simple present-tense.
 * Nonetheless, interesting proposals have been submitted above that could allow us to escape the vagueness. What do you think? -The Gnome (talk) 20:09, 13 July 2024 (UTC)
 * For reasons already given above by others, several of these present variants are not desirable because they lead to "and this continues to the present moment" implications which may not actually be true except in an article that is being very actively edited on a daily basis. And the WP:MOSBLOAT sniff test is not passed by verbiage like WhatamIdoing suggested; editors are not actually likely to write something like "is born in the 19th century" or "will be born in the 19th century", so we have no reason to include such example verbiage in this guideline (in fact, we have a clear rationale to exclude it). No one seems to be confused by the meaning of this section other than one editor, and other editors here have already clarified to that person what the meaning really is, so there is no actual problem to resolve.  — SMcCandlish ☏ ¢ 😼  02:55, 14 July 2024 (UTC)
 * I have added wikilinks to Present tense and Past tense to reduce the risk of confusion about what these terms means. I agree that otherwise the text of the section doesn't need to be changed. However, maybe the examples could be extended to include a few cases of the present perfect and other non-simple tense forms? Gawaon (talk) 04:09, 14 July 2024 (UTC)
 * My comment is I don't see what the problem is. Use present tense the mos says, and so why the complaint when the present tense is used? Perfect simple or perfect continuous would be decided by the context, but they are both present tenses. Roger 8 Roger (talk) 05:26, 14 July 2024 (UTC)
 * I agree with that. My point was that the examples in MOS:TENSE use the simple present six times and the simple past four times (if I counted correctly). Other variants such as perfect or continuous/progressive forms aren't used at all. Adding a few reasonable examples of their usage wouldn't hurt. Gawaon (talk) 06:28, 14 July 2024 (UTC)
 * By default, write articles in the present tense applies most of all to the opening of an article, as the examples demonstrate. It doesn't mean we write the whole article in the present tense. Elsewhere we have The Ford Model T is an automobile that was produced ..., and our BLPs are almost entirely in the past tense after the initial "<Subject> is". NebY (talk) 11:31, 14 July 2024 (UTC)


 * Would the participants in this discussion find worthwhile a Request for Comments on the issue? I'm thinking that the matter of the peacock verbiage, e.g. "served," which was pointed out here, is important enough to lend support to an RfC. -The Gnome (talk) 15:10, 19 July 2024 (UTC)

Can we add this to WP:LANGVAR
This comes up all the time with association football. Can we put it in to formalize that articles written in Canadian, American, or Australian English will use "Soccer" while those in British English will use "football". I see it changed back and forth so often, so while it technically is covered through LANGVAR, having it listed as a specific example can make it cut and dry. RedPatch (talk) 17:58, 17 July 2024 (UTC)


 * The problem is that Wikipedia is an international encyclopaedia with an international audience. When I (Australian) think of "football" I think of Australian rules football. Australians from some other states think of rugby. Americans think of grid iron. Brits think of association football. We are all utterly convinced that our local name is the correct name and that the others are all wrong. So, calling it "football" is simply not feasible.  Stepho  talk 21:44, 17 July 2024 (UTC)
 * Names for association football has a fairly good overview. While I agree that this is a MOS:ENGVAR issue, the MOS doesn't generally take a stance on the usage of individual ENGVAR-specific words and I don't think we should start here. Gawaon (talk) 22:10, 17 July 2024 (UTC)