Misplaced Pages

talk:Manual of Style: Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 06:09, 14 May 2019 editRoy McCoy (talk | contribs)Extended confirmed users1,587 edits thanked SM for answering consensus question; requested retraction of derogatory misstatements← Previous edit Latest revision as of 12:28, 9 January 2025 edit undoLowercase sigmabot III (talk | contribs)Bots, Template editors2,302,385 editsm Archiving 1 discussion(s) to Misplaced Pages talk:Manual of Style/Archive 228) (bot 
Line 1: Line 1:
{{Talk header|WT:MOS|noarchive=yes|search=no}} {{Talk header |WT:MOS |search=no }}
{{Ds/talk notice|mos|long}}
{{FAQ|quickedit=no|collapsed=no}} {{FAQ|quickedit=no|collapsed=no}}
{{Round in circles|search=yes}} {{Round in circles|search=yes}}
{{Tmbox|text=For a list of suggested abbreviations for referring to external style guides (''The Chicago Manual of Style'', for example) see ].}}

{{User:MiszaBot/config
|archiveheader = {{aan}}
|maxarchivesize = 200K
|counter = 213
|algo = old(14d)
|archive = Misplaced Pages talk:Manual of Style/Archive %(counter)d
}}
{{User:HBC Archive Indexerbot/OptIn {{User:HBC Archive Indexerbot/OptIn
|target=Misplaced Pages talk:Manual of Style/Archive index |target=Misplaced Pages talk:Manual of Style/Archive index
|mask=Misplaced Pages talk:Manual of Style/Archive <#> |mask=Misplaced Pages talk:Manual of Style/Archive <#>
|leading_zeros=0 |leading_zeros=0
|indexhere=yes}} |indexhere=yes
}}
{{Section sizes}}
{{WikiProject banner shell |1=
{{WikiProject Manual of Style}} {{WikiProject Manual of Style}}
{{Misplaced Pages Help Project|importance=Top}}
{{Archives |auto=short |index=/Archive index |bot=lowercase sigmabot III |age=14 |box-width=23em |search-width=30}}
}}
{{User:MiszaBot/config
|algo = old(30d)
|archive = Misplaced Pages talk:Manual of Style/Archive %(counter)d
|counter = 228
|maxarchivesize = 900K
|archiveheader = {{Automatic archive navigator}}
|minthreadstoarchive = 1
|minthreadsleft = 4
}}
]
__TOC__
{{clear right}}
{{stb}}


==Style discussions elsewhere == ==Style discussions elsewhere==
<!-- ] 06:53, 11 February 2029 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1865487200}} <!-- START PIN -->{{Pin message}}<!-- ] 06:15, 18 June 2029 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1876457735}}<!-- END PIN -->
Add new items at top of list; move to ''Concluded'' when decided and summarize conclusion. Comment at them if interested. Please keep this section at the top of the page. 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=== ===Current===
(newest on top) (newest on top)
<!--
<!--Don't add threads that are on the same page as this list.-->
Don't add threads that are on the same page as this list.
* ] – Downcase "we trust", since it's neither a composition title nor a trademark or a proper name? ] (]) 03:56, 13 May 2019 (UTC)
Capitalization-specific entries should go in the corresponding section at the top of:
* ] – ] → {{no redirect|Chairperson}}. Another try with one target. Related discussion: ].
Misplaced Pages talk:Manual of Style/Capital letters
* ] – A ] and ] question. Initially passed in favor of "organization". Reopened by request.
-->
*{{section link|Talk:And Then There Were None#RfC: And Then There Were None and racial language}} – A ] question. <small>] (they/them) (]/]) 02:06, 9 April 2019 (UTC)</small>
* ] - A ]/] question
* ] – If/when to use a style like "Smith, TK" in citation instead of "Smith, T. K." to match the rest of the article.
* ] – Plural possessive ] question
* ] – proposal to merge in a handful of points from ] essay, or mark the latter historical or rejected.
* ]
* ] – to use policy-based material on "Christ" found in an essay but more useful in a guideline. (Nov. 2024)
* ] – Has stylistic implications (punctuation, leading "The", etc.) despite not being intrisically an MoS matter. (Nov. 2024)
* ] - use of flag icons in infobox per ] (Sep.–Nov. 2024) – See also prior ].
<!--Please put newer entries at the top.-->

{{block indent|1=<nowiki />
'''Pretty stale but not "concluded":'''
* RfC needed on issue raised at ] (June–July 2004, archived without resolution). Presently, the royalty/nobility wikiprojects have imposed putting British peerage titles in place of names in biographical infoboxes, against ], ], and the template's documentation. Either the community will accept this as a best practice and the guidelines changed to accomodate it, or it should be undone and the infobox used consistently and as-intended.
* A ] revision RfC needs to be drafted, based on ] (Dec. 2023 – Jan. 2024, archived without resolution). JOBTITLES remains a point of confusion and conflict, which the guidelines are supposed to prevent not cause.
* ] – Involves ] (plus ], ], ]). Covers more than thread name implies. (Dec. 2023 – Jan. 2024) ''Result:'' Stalled without resolution; at least 3 options identified which should be put to an RfC.
* ] – Involves ], ], ], ], etc. (Sep. 2023 –) ''Result:'' Still unresolved, though consensus seems to lean toward permitting lower-case "prophet" when needed for disambiguation, but no agreement yet on specific guideline wording.
* ] – Specifically in tables, possibly elsewhere. ] (at the table "General guidelines on use of units") has an example of existing use that is being challenged, and material at ] is also at issue. (Dec. 2023 –) ''Result:'' Still unresolved.
* ] – Help page is conflicting with ] and ] on a technical point. (Aug. 2023 – Jan. 2024) ''Result:'' No objection to fixing it, and a suggestion to just do it ]ly, but the work actually has to be done.
<!--Please put newer entries at the top.-->
}}<!-- end of block indent -->

{{block indent|1=<nowiki />
'''Capitalization-specific:'''
{{Excerpt| Misplaced Pages talk:Manual of Style/Capital letters|Current|subsections=no}}
}}


===Concluded=== ===Concluded===
{{collapse top}} {{collapse top|left=y|title=Extended content}}
<!--We don't actually care what order they go in here, since it's old news. It's easier as newest on top, by order of closure. --> <!--Please put newer additions at the top, by order of closure. -->
* ] – Use en dash not hyphen in four paired names? ''Result:'' Yes.
* ] – Perennial dispute about putting website titles in {{para|publisher}} or {{para|via}} just to avoid italicizing them in citation template output. Archived.
* ] – In short, should we use odd-ball stylization of band names and the like to match their marketing? (July–Aug. 2024) ''Result:'' No formal closure, but a clear consensus against this idea, and against the underlying "conflict" premise; the proponent simply did not understand the policy.
* ] – Discussion about using decorative template, {{tlx|redacted content}}, to simulate the appearance of blacked-out material in censored documents, e.g. {{redacted content|text={{white|'''CENSORED'''}}}}. Archived.
** Various simultaneously executed RMs by the same proponent all concluded against the desired over-stylizations (usually ALL-CAPS) – some by affirmative consensus against, some by no consensus to move.
* ] – Proposal to undo two recent moves that went against ]. Moved to add space.
* ] – Should British peers use their peerage title in place of their name in infoboxes? (June–July 2004) ''Result:'' archived without resolution. This needs to be RfCed.
* ] – a ] matter, about military commanders. Consensus against using flag icons.
* ] – ]: "Shays'" or "Shays's"? ''Result:'' "Shays's". No objective rationale was presented for an exception to the guideline, and evidence shows "Shays's" common in source material even if "Shays'" is also common, especially in older sources.
* ] – ] → {{no redirect|NGHTCRWLRS (album)}} – For consistency with band title. Not moved, per consensus. See also ].
* ] – Should multiple entries be formatted as a list or a single phrase? (Apr.–May 2024) ''Result:'' 4:1 against proposed change to a list format; alternative idea at end neither accepted nor rejected.
* ] – a ] case of text-on-color luminosity and contrast. Some ] struggles. Closed: no consensus for any action.
* ] – Do flags in this infobox serve a "useful purpose" per ] or are they primarily decorative and should be removed? (Apr.–May 2004) ''Result:'' 3:1 against inclusion; the 1 did not read or understand the entire guideline. See also later ].
*] – A proper name, or not? Moved to Efficiency movement.
* ] – Primarily on a recent habit of military-conflict articles having collages of 4, 6, or even more images in their infobox. (Mar.–May 2024) ''Result:'' No formal closure, but a clear consensus against this practice; image galleries (when appropriate at all per ]) belong in the article body.
* ] – Some suggestions include ], and ]. A ] matter, in part. No consensus to move to a specific title. A majority favored abandoning "Chairman", however. In a move review (]), the closure was endorsed. A new RM was then initiated: ].
* ] – ] (and ]) in "day of year" (DoY) article candidates for "featured list". (Feb. 2024) ''Result:'' No formal closure, and little clear consensus other than that ] / ] apply, as does ].
* ] – ], from vs. From. No consensus to move. Exception to guidelines favoring lowercase prepositions.
* ] – On ] vs. ], etc. (Jan. 2024) ''Result:'' No clear consensus reached; a great deal of sourcing is provided, but there's a feeling that real-world usage varies considerably on a case-by-case basis, so ] might invididually trump ]. Worth revisiting in a few years to see whether source usage has shifted.
* ] (was <s>]</s>) – Proposal to move a band title from ALLCAPS style. Closed as not moved. Note: The previous discussion was ], a misplaced RM discussion, to move the title to ALLCAPS because the author prefers it.
* ] (moved from WP:VPPOL) – Yet another round of this long-term, multi-RfC process. Consensus about "deadnames" seemed possible this time but was mostly elusive. (Dec. 2023 – Jan. 2024) ''Result:'' no consensus to change the wording of MOS:GENDERID based on this proposal; consensus against changing "should be included" to "may be included".
* ] – ] matter of "SpaceX landing zones" or "SpaceX Landing Zones". No consensus to move.
** Related: See numerous previous deadname-related and more general GENDERID discussions listed below.
* ] – proposal to move this page to be a subpage of ], or just merge them. Not moved, as not strictly related to MOS and linking.
* ] – Proposal to merge a "guideline in all but name" into MoS. (Jan. 2024) ''Result:'' consensus to promote to a guideline (after some significant revisions).
* ], ], and ] – typical diacritics case. All 3 moved as common name, without diacritic.
* ] – Peripherally related to ] and ]. (Jan. 2024) ''Result:'' Consensus to increase to 250px.
* ] – a ] question. Moved to ].
* ] – ] has long been considered too complicated and hard to follow. (Dec. 2023 – Jan. 2024) ''Result:'' input stalled out over the holidays, then it was archived without resolution.
* ] – Multi-page RM, mostly ], plus some ] and ] issues. Moved to titles with unspaced en dash.
** ] – Abortive, unclear RfC that resolved nothing. (May–Sep. 2023) ''Result:'' unanimously opposed.
* ] – mostly a merge discussion, also involves ] and ] matters. Closed: Further discussion required.
* ] – Involves ], ], ], ]. (Oct.2023 – Jan. 2024) ''Result:'' Archived without closure. There does not seem to be a compelling reason for this ALL-CAPS behavior in the template/module, but it was still happening in Nov. 2024.
* ] – Weird mismatched comma and two or three unnecessary disambiguators? Moved to ].
** Discussion re-opened at ] (Nov. 2024). Changed to lowercase ; we'll see if that sticks.
* ] – Non-English language-formatting template diverging from what ] says about linguistic glosses and literal translations. Resolved.
* ] – Involves ], ], ], ], ], etc. (Oct. 2023 – Jan. 2024) ''Result:'' No formal closure, but there seems to be no appetite for diverging from ], and the OP commingled unrelated cases like stagenames of real people.
* ] – Bracketing commas again. No consensus to move.
* ] – About use of {{tlx|sronly}} around table captions (which are primarily for screen readers) to hide them from the usual non-screen-reader view, only when their content repeats what is in the table headers. (Nov.–Dec. 2023) ''Result'': Archived without firm resolion. As there was but one opposer of the idea, there is no consensus against doing this. If more opposition arose or some reason, open an RfC about it.
* ] – a typical ] RM discussion. Moved to lowercase.
* ] – Involves ]. (Oct. 2023 – Feb. 2024) ''Result:'' Thinly attended, but there does seem to be a linguistics standard to render ]s in {{sc2|smallcaps}}, so this has been accounted for and added to the exception lists at ] (since our articles are consistently doing it based on that sourcing).
* ] – ] / ] cases (unusual in being about lowercase rather than over-capitalization). Closed in favor of ''Fairy Gone'', per MOS:TITLES.
* ] – On ] and whether to add another example to it. (Oct. 2023) ''Result'': Discussion archived without a clear conclusion.
* ] – Reagan's version, versus arbitrary caps. Closed as "no consensus".
* ] – 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.
* ] – ] question about capping Philosophy in this title of an appendix. Closed in favor of "Kantian Philosophy" per TITLECAPS.
* ] – Use an en dash instead of a hyphen? ''Result'': Withdrawn
* ] – typical diacritics-related RM. Closed in favor of not stripping diacritics.
*] – Move review on Pākehā settlers vs. European settlers in New Zealand, related to ], ], ], ] (Feb. 2024). ''Result:'' There were many steps in this process but ultimately ] was moved to ].
* ] and ] – a ] question, same on both. Close in favor of the en dash.
* ] – To treat word-substitutions ("U" for "You", "❤️" for "Heart", {{nowrap|"..."}} for elided wording), as "words" for the purposes of a particular line-item about title-case treatment. (Dec. 2023 – Jan. 2024) ''Result:'' Done, with unanimous support.
* ] – hyphen, en dash, or otherwise? ] close against using an en dash here, as a misunderstanding of ]
* ] – 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 ], leaving behind a cross-reference to MOS:TM from ]. (Nov.–Dec. 2023) ''Result:'' Because of some things that apply to personal not corporate names, this ended up not being practical; intead the MOS:BIO material was cleaned up and cross-references between the two MOS sections was improved; description at: ]. No objections or other issues have come up.
* ] – Dispute over both whether to use American English and whether to impose American-style MDY (or even ISO YMD) dates. Closed with: "There is consensus to prefer no particular style. Where there is dispute, the principles of MOS:RETAIN and MOS:DATERET should be followed."
* ] – Proposal to add something to ]. (Oct.–Dec. 2023) ''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."
* ] – about ] application; closed as consensus not to move per ], and a recommendation to revisit ]. –&nbsp;Move review at ] endorsed the original closure.
* ] – About changing ] to specify a format (new or otherwise) for betting-odds ratios. (Oct.–Dec. 2023) ''Result:'' No formal closure, but apparent general agreement that the <code>:</code> style for ratios in general applies to odds ratio in particular like the rest, and MOS:RATIOS updated to say this.
* ] and ] – '''lowercase''' command and service module; "lunar module" is less certain –&nbsp;see compromise at ].
* ] – Primarily a matter of article title, but there are related issues such as capitalisation. (Nov. 2023) ''Result:'' basically stalled out, without resolution/action. Specific revision proposal is needed.
* ] – Treat HYFLEX as an acronym: allcaps.
* ] – Also involves ]. RfC on "season 3, episode 7" vs. "season three, episode seven" styles (and probably also "seventh season" vs. "7th season", etc.). (Oct.–Nov. 2023) ''Result:'' "season and episode numbers should be expressed as numerals in tables, headings, and article body" (revision of a previous, less clear close).
* ] – in which the proposed title ] may have an issue with respect to ] – No consensus for proposed move, no consensus for alternate title
* ] – On how WP uses terms like "terrorist/terrorism" and "freedom fighter", specifically to add a requirement "these words should only be used in quotations or referencing third-party use of the term". (Oct. 2023) ''Result:'' "nearly unanimously opposed".
* ] – Capitalization as if an acronym but it is not one; speedily closed as successful move to "Oz".
* ] – Involves ], ], etc. (Sep.–Oct. 2023) ''Result:'' "rough consensus to allow for lowercase or capital letters after dashes or colons in article titles, section titles, and list items".
* ] – Closed as consensus against a prescriptive set of citation styles.
* ] – ] / ] and Northern Ireland again. (Sep.–Oct. 2023) ''Result:'' No formal closure, but near-unanimous consensus against using national flags as ethnicity symbols.
* ] –&nbsp;two-article ''subway'' capitalization issue. Concluded to use lowercase "subway" per guidelines and sources.
* ] – Involves ] and could have implications for what the guideline says due to wildfire news bringing many more editorial eyes to that page than to ]. (Aug.–Sep. 2023) ''Result:'' Archived without closure or any clear consensus; the general gist seems to be that the state of Hawaii is named Hawaii, the island is named Hawaiʻi, and diacritics (] and ]) 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).
* ] – Title has been discussed previously, but not for capitalization. – Left capitalized.
* ] – ] stuff. (Aug. 2023) ''Result:'' Not moved. Lots of invalid arguments, and confused attempt to pit ] 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).
** Move review at ] endorsed the original closure.
* ] – Wikiproject propsal to change ] or ]. (Aug. 2023) ''Result:'' wrong venue, and to the extent people commented on using 24-hour time, it was mostly opposed.
* ] – about ALLCAPS in titles in infoboxes to mimic station signs; archived with a general consensus: use standard English orthography, not stylization for its own sake.
** ] – Above question was raised at a specific article as a "local consensus" matter. (Aug.–Sep. 2023) ''Result:'' unanimous opposition to 24-hour time.
* ] – Closed as "rough consensus to leave this up to editor discretion".
* ] – Follow-up to "unfruitful" discussions at ], etc. (Aug. 2023) ''Result:'' No formal closure; general agreement basically boils down to "write clearly and don't confuse or over-simplify with an adjective".
* ] – RfC on 85%, 100%, or other font size. Could affect many articles, though only in a small way. Closed as "no consensus".
* ] – Wikiproject proposal to change rank abbreviations (to NATO style) in ]. (Aug. 2023) ''Result:'' no formal closure, but overwhelming consensus to stick with MoS and ignore NATO preferences.
** ] – Gist: Is "OFM Cap FSA Scot FRHistS" five post-nominals, or three? (Hint: it's three.) – Closed without resolution, when the "parent" RfC was closed as "no consensus".
* ] – And some alternative ideas, including merger into ]. (Aug. 2023) ''Result:'' No formal closure, and the idea was mostly opposed, with no effect but returning all of the shortcuts (], ], ], ], ]) that someone changed to point to the ] essay to now point back to the real guideline at ].
* ] – Proposal to lowercase mid-sentence use of such terms, except in proper names. Broadly supported. Doesn't look like the expansion has been done yet.
** The essay has since been retooled to be an exegesis of the guideline, though attempts at ]ing are likely to continue, as this is one of our most hotbed internal topics. See also the guideline ], and the essays ] and ].
* ] – Whether to mimic (or make special note of) all-lower-case song titles on album covers, track listings, etc. – Generally NO.
* ] – RfC with wide potential impact (several thousand articles): Closed as "retain the current capitalization for the titling of standardized breeds on Misplaced Pages"; ] updated to implement this. ** ] – Proposal to move the MoS material into WP:BLP. (Aug. 2023) ''Result:'' Procedurally closed as "premature".
* ] – multi-page RM primarily about diacritics (Sámi vs. Sami vs. Saami) – Closed as "No consensus to move to this or any other title." * ] – Should the en dash have spaces around it; should it be an em dash? ''Result:'' moved to spaced en dash.
* ] and ] – Relating to concordance between wikidata descriptions and enwiki "short description". (Aug. 2023) ''Result:'' Good summary: "as long as you choose a comprehensible form, your edits are fine. However, you should not change existing descriptions for stylistic reasons, and also not to unify desriptions for a given set of items"; also observations that various languages, e.g. Spanish, do not use an en dash for this purpose. So, Wikidata will not be changing away from hyphen as default, and any desire to have WD material, like automatically provided short descriptions, will have to do that change on our end.
* ] – In short: should ] agree with ]? – Closed as "No consensus (whatsoever) emerged in this discussion!"
* ] and ] – Use "&" or "and"? (see ]). ''Result:'' Follow ]; the essay ] conflicting with the guideline and with ] policy was noted, and this ] was fixed in Jan. 2024. The second of these actually closed as "no consensus" because the ] who closed it did not know of ] policy and incorrectly treated policy- and guideline-based arguments as no stronger than those based on a contrary essay.
* ] – Change ] to allow capitalization of four-letter prepositions in titles. – Closed: 'Apply our five-letter rule except when a significant majority of current, reliable sources that are independent of the subject consistently capitalize, in the title of a specific work, a word that is frequently not a preposition, as in "Like" and "Past". Continue to lower-case common four-letter (or shorter) prepositions like "into" and "from".' ] updated to reflect this .
* ] – Some re-wording proposals, and even a suggestion to remove the language entirely. (July 2023) ''Result:'' No formal closure, and did not result in wording changes, though a re-do might come to such a conclusion.
* ] - In names, how should special non-English "Roman-ish" alphabetic letters be displayed? – Fun discussion didn't go anywhere
* ] – move to ] like ], or is there a reason to hyphenate as ]? (July 2023) ''Result:'' Not moved. The closer actually misunderstood the guideline wording badly, and this has created a ] 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.
* ] – about ] and where it applies. – Closed "There's a strong consensus that nothing needs to be settled and the concerned guidelines are already perfect. Exceptions may be evaluated on a case-by-case basis."
** ] – ditto. ''Result:'' Procedurally closed as a ] of the RM above.
* ] –&nbsp;proposal to use dash instead of hyphen. (June–July 2023) ''Result:'' Use the dash per ]; a followup RM to add "Corporation" to the title rejected that idea despite ] supporting it, one of several recent RM incidents suggesting that at least some portions of the page do not enjoy consensus.
* ] – Proposal to change ] that "encyclopaedic significance of the deadname established through in-depth analysis or discussion of the name in high quality sources, or if they were notable prior to transitioning". (June–July 2023) ''Result:'' "no clear consensus".
* ] – Primarily about "When should Misplaced Pages articles include the former name of a deceased trans or nonbinary person who was not notable prior to transitioning?" (May–June 2023) ''Result:'' "there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. Also, there is clear consensus that a former name is not automatically of encyclopedic interest. Where, exactly, the lines of encyclopedic interest and avoiding confusion are is not simple or clear and will likely need discussion on individual articles, although there is definitely space for more guidance in the MOS". This has let to a lot of follow-on discussion and dispute.
* ] – Proposal to move section to naming-convention guideline. (June 2023) ''Result:'' no pro or con input; re-opened (Jan. 2024) on main MoS page.
* ] – Proposal to make anti-deadnaming rules apply to the long-deceased as well. (Apr.–May 2023) ''Result:'' No consensus to remove ''living'', so "the ''living'' qualifier, shall remain in place". The May–June 2023 RfC above was an outgrowth of this discussion.
* ] – essential information, or icon cruft? (Mar.–Apr. 2023) ''Result:'' "There is consensus against inclusion of rank icons."
* ] – involves ] and ]. (Feb.–Mar. 2023) ''Result:'' no consensus to use "v"; continue to use "vs." or "vs" as suits the ] of the article.
* ] – Should an external style guide be used in place of ] in chapter lists (e.g. ])? (Jan.–Feb. 2023) ''Result:'' Insufficient input to reach a consensus. Needs to be RfCed. But the {{lang|la|status quo}} default principle is that a lack of consensus to create an exception to general rules does not result in such an exception.
* ] – Open discussion as to whether decimalized years should be used in personal biographies. (Jan. 2023) ''Result:'' discussion archived; majority felt that decimalized years are not standard in biographical prose and should be limited to a statistical/mathematical context.
<!--Please put newer entries at the top.-->
{{block indent|1=<nowiki />
{{Excerpt| Misplaced Pages talk:Manual of Style/Capital letters|Concluded|subsections=no}}
}}
{{collapse bottom}} {{collapse bottom}}


== Retain or remove citation indicators in quoted text? ==
== An amusement park with a ] theme is... ==


Is it acceptable to remove citation indicators – ¹ or (Gorgon, 1993) – that appear within quoted text (this would be to improve readability). I'm not referring to citing quoted material, but to citation marks ''within'' quoted material. Thanks! ] (]) 12:18, 25 November 2024 (UTC)
* A ] themed amusement park?
* A ]-themed amusement park?
* A ]-themed amusement park?
This is for the ] page. --] (]) 16:16, 15 April 2019 (UTC)
* The form without hyphens is clear, and I do not see a compelling reason to hyphenate. It could also be rewritten to avoid the question: "An amusement park with a ] theme" (also the title of this discussion). ] (]) 16:34, 15 April 2019 (UTC)
* I could read the non-hypened form as a themed amusement part under the brand name "Noah's Ark". I think the second with the single hyphen is correct, but yes, as Jmar points out, rewording is much easier to do. --] (]) 16:39, 15 April 2019 (UTC)
*Yes, the day has come that we can combine hyphens with creationism. Now if we can only drag in ] somehow, we'll have achieved Nirvana. In the meantime, it pains me to say that none of the above is correct. An ndash is needed. Watch. Nothing up my sleeves...
::A ]{{ndash}}themed amusement park
:See ]. The idea is that we want a bit more distance between ''Ark'' and ''themed'' than hyphen gives, because we don't want those two binding too closely to the exclusion of ''Noah's''. ]] 16:52, 15 April 2019 (UTC)
::That's reasonable. At the moment I don't see that covered under the section on hyphens. A reference there to the dash discussion would be good. ] (]) 17:16, 15 April 2019 (UTC)
:::I just tried something along those lines, but the mass of dash-and-hyphen{{ndash}}related (or maybe ''dash and hyphen{{ndash}}related'' or ''dash- and hyphen-related'') material is just too crushing. I barely escaped with my life. ]] 17:51, 15 April 2019 (UTC)
:::::I added an ndash to the article. Thanks! --] (]) 12:15, 16 April 2019 (UTC)
::::{{u|EEng}}, the important thing is: it's definitely ''dash- and hyphen-related'' and not ''dash and hyphen–related'' unless you're referring to the Dash and Hyphen pub. (I never go there, the atmosphere is too uptight.) <span style="white-space:nowrap;">]&thinsp;<span style="display:inline-block;position:relative;transform:rotate(45deg);bottom:-.57em;">]</span></span> 21:08, 19 April 2019 (UTC)
:::::I feel there's a colonoscopy pun in there somewhere, but it's just not gelling. ]] 21:31, 19 April 2019 (UTC)
::::::That's because your pun account is in a rears. This being MOS, I would suggest you start with semicolonoscopy puns. Then you can move up to innuendos. --] (]) 22:00, 19 April 2019 (UTC)
:::::::Wow, you're good. Your contribution has been . ]] 02:52, 20 April 2019 (UTC)
::{{u|EEng}}: "The idea is that we want a bit more distance between ''Ark'' and ''themed'' than hyphen gives, because we don't want those two binding too closely to the exclusion of ''Noah's''." This is precisely correct. I've always had the problem, however, of regarding the en dash as somewhat too wide for such purposes. I generally don't like it in number ranges either, for example, though I don't have anything against the character concerned's being a bit visibly wider than a hyphen. I've found this perceived excess of width to be particularly noticeable in bibliographies, where I've sometimes thought the en dash makes the page ranges stick out too much visually (and where I've occasionally revolted and used hyphens, with no one ever complaining in consequence). I was thinking today that in addition to the hyphen and the en dash, I'd like to have a c dash or an e dash, either of which would be about halfway between a hyphen and an en dash widthwise. It hit me as odd that while printers have always had a variety of spaces at their disposal (InDesign's Insert White Space menu shows, for example: Em Space, En Space, Nonbreaking Space, Nonbreaking Space , Hair Space, Sixth Space, Thin Space, Quarter Space, Third Space, Punctuation Space, Figure Space and Flush Space), the hyphen/dash options have been remarkably meager (in InDesign, besides the normal and discretionary/nonbreaking hyphens: Em Dash, En Dash, and that's it). Where I went from there in this fanciful digression was to see if I could modify the width of characters in Misplaced Pages, but ] offered no method for this. I thought of changing the en-dash font, but that wasn't a very appealing idea, and before I got around to possibly trying it another thought came to me that seemed interesting and amusing enough to post here, though I don't suppose it will have any practical consequences. Namely... one of the problems I may have with the en dash is that it's customarily used, spaced, as the long dash. So if it looks like a long dash, that's actually what it is, at least in text using the en rather than the em as long dash. So if it's been commonly thought that the em is too wide and that the solution for this is to space the narrower en... why not similarly use a spaced hyphen if or when the en is thought to be too wide? One wouldn't want much of a space, of course, and it might not seem or be perfectly logical in an example such as the one here, but I'm still going to have a crack at it and post what I get. Here it is, hyphenated with a hair space – A Noah's Ark{{hsp}}-{{hsp}}themed amusement park – and with a thin space – A Noah's Ark&thinsp;-&thinsp;themed amusement park. I like it with a hair space myself. Comments welcome but not expected. –] (]) 05:10, 5 May 2019 (UTC)
:::Roy, you say "I've always had the problem of regarding the en dash as somewhat too wide for such purposes". This is entirely your problem, or your font's problem perhaps. In most fonts, the difference is not so striking, but personally I prefer a font where the difference can't be missed (though it's been so long since I picked a font some place that I can no longer find where that was or what font it was; maybe I'm hallucinating). Also, the MOS does not recommend an en dash for this purpose, so it's not really an issue. Also, all the sources just use "Noah's Ark-themed", so I wouldn't be looking for ways to improve on something where our MOS and all sources are already aligned. ] (]) 05:49, 5 May 2019 (UTC)
::::I didn't know it, {{u|Dicklyon}}, but you're right: it is entirely my problem. I googled "en dash is too wide" to see how many othere people shared my feeling on this, and there were ''no'' finds on it – not a single one. It's not a font thing, as I don't remember having ever encountered a font that didn't have a noticeable width difference between a hyphen and an en dash, though I suppose they may exist. So thanks for leading me to the realization that I'm surprisedly alone on this, and also for informing me that en dashes aren't recommended on Misplaced Pages for number ranges. As long as we're at that part or its neighborhood of the MoS, I just now changed the heading "Multi-hyphenated items" to "Multi-word hyphenated items" in accordance with the text, as there are not always multiple hyphens in such constructions. I was tempted as well to replace or delete the first example there ("{{xt|a four-CD soundtrack album}} may be easier to read as {{xt|a soundtrack album of four CDs}}"), since I sense no problem at all with the first variant and in fact find it easier to read than the second. If someone agrees with me (with this en-dash Google non-find I no longer have any confidence about people's agreeing with me, except on the nonnecessity of commas following short introductory prepositional phrases), they can maybe do something about the existing example. –] (]) 19:26, 5 May 2019 (UTC)
:::::En dashes certainly ''are'' recommended in number ranges; but not in Xx Xx-themed. You can see different relative widths in some fonts at ]. ] (]) 01:06, 6 May 2019 (UTC)
::::::You're right again, {{u|Dicklyon}}. Actually I quite noticed "In ranges that might otherwise be expressed with to or through", but I somehow missed "ranges of numbers" and got the idea that this was more in relation to non-numerical expressions. Thanks on the fonts – maybe I will have an occasion to switch fonts in WP at some point, then. Or maybe, perhaps more likely, I won't. –] (]) 05:48, 7 May 2019 (UTC)
:::Spaced hyphen is logical and visually appealing, but ] currently forbids it. Might be worth a discussion of its own. ] (]) 08:41, 5 May 2019 (UTC)
::::Thanks also, {{u|Jmar67}} – not only for supporting my esthetic consideration, but also for relieving me of any imaginable temptation to act on it. I now see the proscription you're referring to, however ("A hyphen is never followed or preceded by a space, except "), which supposably means word spaces and might thus be taken as not applying to the distinctly different hair spaces. But I'm not going to take that up and I doubt anyone else will either, so I don't think a separate discussion is called for at this point. Thanks for the suggestion, though. –] (]) 19:26, 5 May 2019 (UTC)
:::::Spaced hyphen has one universal meaning: "I didn't know how to make a dash". It has no place in proper typography. ] (]) 01:06, 6 May 2019 (UTC)
::::::I don't think you're right here though, {{u|Dicklyon|Dick}}. (I just now realized your name is probably Dick Lyon. I thought it was one of those classical-type names: DICleon, like Anacreon etc.) You're mixing apples and oranges. A hair space is a small spatial adjustment; I was explicitly not suggesting a full-width word space such as used around en dashes. You really don't need to tell me about (word) spaces around hyphens. –] (]) 05:48, 7 May 2019 (UTC)
:::::::Got it. But I don't think there's ever a call for any amount of space around a hyphen. Let me know if you find otherwise. ] (]) 20:35, 7 May 2019 (UTC)


:Yes. References to footnotes are usually silently omitted, as they are not a part of the text flow anyway. ] (]) 11:52, 26 November 2024 (UTC)
:"Noah's Ark-themed". This is already covered at ] (don't inject hyphens into a proper name being used adjectivally). But constructions with no hyphen are ambiguous. E.g. "A Noah's Ark themed amusement park" seems to suggest a "themed amusement park", which certainly sounds like a real thing, owned by a company called Noah's Ark (check trademark registrations and you'll find that there are many). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:18, 29 April 2019 (UTC)
:: That’s ugly. —] (]) 06:04, 5 May 2019 (UTC) ::Thanks. Is this addressed in the MoS? I couldn't find mention ]. This would seem a common situation when citing academic sources. ] (]) 15:58, 26 November 2024 (UTC)
:::Tell that to the authors of the most world's English-language style guides. This is simply how hyphens are used with proper names. It's not like MoS just made this up. It's normal English. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 21:52, 7 May 2019 (UTC) :::I added it while doing some other cleanup. It's entirely normal to silently (not with "...") remove inline citations from quoted material, since WP isn't providing the source info, and to the reader it will be just be frustrating (they'll go looking for "Smith 1997" or whatever, and not find it). If our article is also citing the same source, then linking the quoted citation to our citation might be useful, but shouldn't be seen as manadatory. A general principle of quotation (inline or block) is to only quote what is pertinent, what is contextually necessary for our purposes; otherwise we're wandering into over-quotation which is both poor writing and apt to be a copyright issue unless the source is public-domain. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 13:55, 11 December 2024 (UTC)
::::Thanks. Your addition is helpful and doesn't seem to overcomplicate things. I realized the primary aim with quoted material is not to forensically reproduce it from the source (as I'd kinda been doing), it's to accurately represent the meaning as it appears in the full context of the source. Which makes minor silent adjustments for readability fine, provided meaning is strictly preserved – comprehension and judgement are of course required. ] (]) 17:06, 11 December 2024 (UTC)
* A '']'' themed amusement park? ] (]) 06:04, 5 May 2019 (UTC)
*:Not a use of italics ] would sanction. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 21:52, 7 May 2019 (UTC)


== Stale advice: slashes have been line-breaks since 2005 (Unicode 4.1.0) ==
== Numbering officeholders in infoboxes ==


{{alink|Slashes (strokes)}} says "On the other hand, if two long words are connected by an unspaced slash, an {{tl|wbr}} added after the slash will allow a linebreak at that point."
Relevant RfC for any concerned: ]


I've recently tweaked a couple of articles doing this, and realized that my browser will allow breaks after slashes without any special markup. This is part of the . Looking into the archives, it was added to support breaking URLs between and .
== Deleted sentence at Punctuation inside or outside / Proposed reordering at Names and titles ==


It's been 19 years. Do we still need this advice? I ask because ''some'' parts of WP are aggressively backward-compatible: {{tl|wbr}} still expands to <code>&lt;wbr/>&amp;#8203;</code> since apparently IE7 and earlier don't support <code>&lt;wbr/></code>. But I seriously doubt that WP is ''consistently'' backward-compatible; I'm sure there are lots of more recent edits where the editors didn't see a problem with long /-separated lists on their browsers and didn't do anything tricky. ] (]) 17:20, 26 November 2024 (UTC)
Greetings.


:Look at Good articles (or former Good articles) from years ago they read like they do now and it just shows that the Manual of Style will stay exactly the same as it has been for 18 years unfortunately. ] (]) 02:45, 14 December 2024 (UTC)
I almost boldly changed


==Input needed on disagreement over where the lifespan goes in relation to a baronetcy or a peerage title==
''"Life", Anaïs Nin wrote, "shrinks or expands in proportion to one's courage."''
] and I disagree on where the lifespan goes in relation to a name that includes a baronetcy or a peerage title. It started with Muéro removing honorifics from the lead of several articles on peers (many of which I have on my watchlist), following the recently changed guidelines at ]. This is not controversial, but in their edits, he also removed a comma unrelated to the honorifics, but called for by ] ("''Don't let other punctuation distract you from the need for a comma, especially when the comma collides with a bracket or parenthesis''").


I pointed this out to them, and they acknowledged the error, but then they instead started to leave another comma in place, a comma that was required by the now obsolete guideline. I can't find the guideline in the history of this article, but it went something like this:
to
:''For people with a baronetcy or a peerage, the post-nominals should be separated from each other, <u>and from the name</u>, by a comma, for consistency's sake.'' (my underscore)


That is the comma Muéro left in place, and the result was this:
''"Life," Anaïs Nin wrote, "shrinks or expands in proportion to one's courage."''
John Doe, 1st Baron Doe, (1 January 1801 – 31 December 1881), was a Whig politician ...


I pointed out to Muéro that this is also wrong, and that punctuation rarely – if ever – precedes a parenthetical expression. But they are adamant that it should be there.
at Quotation Marks > Punctuation before quotations, in accordance with the style I had always seen, I thought even in British publications. I don't remember what stopped me from making this change, but whatever it was I was very surprised – and very pleasantly – to see that what I now see is termed "logical quotation" is now standard in Misplaced Pages. Despite the change I was about to make, I have for decades been an active proponent of what I would normally call British usage on this, which is both more logical and more attractive. Hooray Misplaced Pages.


So here we are. I'd like input from the project, and I'm sure Muéro would like that too.
The topics I am here raising, however, are not that but rather (1) my deletion – I hope not too bold – of a sentence in the subchapter Punctuation inside or outside, and (2) a proposed reordering in the subchapter Names and titles.


The discussion originated on ], but I'm copying it here, and closing it there, while notifying them.
(1) When I noticed there was no sample given for the sentence "A question should always end with a question mark", I first added one:


===The discussion on Muéro's talk page===
''Marlin asked Dory, "Can you read?"''
Hello.


Thank you for your contributions. Regarding your edit of ], and similar edits removing postnoms per the new guidelines, please don't remove the comma '''''after''''' the parenthetical birth–death expression. It's supposed to be there per ]: "''Don't let other punctuation distract you from the need for a comma, especially when the comma collides with a bracket or parenthesis''".
I immediately had doubts about this, however. It wasn't really a question, but a declarative sentence quoting a question – and if I changed it to a question I wouldn't be sure how to punctuate it in approved Misplaced Pages style. Would that be


Thank you. ] (]) 15:50, 25 November 2024 (UTC)
''Did Marlin ask Dory, "Can you read?"''


:Ah, good catch. I can't wait for the day when nobility titles are also excluded entirely, which would make that comma unnecessary anyway. ]<sup>(]/])</sup> 15:58, 25 November 2024 (UTC)
or


::Hello again.
''Did Marlin ask Dory, "Can you read?"?''


::Thank you for your understanding. Re: your latest edits, you're now leaving a comma in place that shouldn't be there.
Someone please tell me, thanks – though it seems fairly clear that the question needs two question marks in order to conform to the sentence it's supposed to illustrate.


Nathaniel Charles Jacob Rothschild, 4th Baron Rothschild, (29 April 1936 – 26 February 2024),
What finally made me desist with trying to provide another sample, however, was not so much this problem but rather that there was no clause following the quote and I didn't know how to provide one, or even if the sentence without a sample necessarily referred to a quote with a following clause or not. So I deleted both my previously placed sample and the sentence, noting:
^ ^ ^
A B C


::Commas A and C are paired, comma B should be removed along with the postnoms that followed it. Commas rarely precede parentheses.
''"Deleted previously added sample, plus the sentence "A question should always end with a question mark." pending provision of an appropriate sample, or perhaps new paragraph with same. Otherwise others than myself will be confused.''


::Cheers.
What I think I've done, then, is to prompt an improvement without having made or specified it myself. It may, however, be unnecessary to do anything more here at all, since "A question should always end with a question mark" may be taken as something rather obvious that neither belongs at this particular place nor merits a separate paragraph elsewhere.


::] (]) 17:52, 25 November 2024 (UTC)
(2) Continuing to check out the MoS, I noticed that the list item "and the section you are reading now." under Names and titles seemed out of place and should appear at the end rather than in the middle of the list. I tried to change this but couldn't, so I'm now suggesting that someone here who's able to do that make the change (assuming it can be changed by someone, as I suppose it can).
:::I don't think that makes sense. If someone doesn't have a nobility/royalty title, there is no comma before or after the life span. When adding the nobility/royalty title, the pair of commas should go before and after the nobility/royalty title. Why, when adding the nobility/royalty title, would the life span get looped into the comma pair? ]<sup>(]/])</sup> 17:56, 25 November 2024 (UTC)


====Step by step====
Thanks.
I think it makes perfect sense. You don't put a parenthetical expression '''''after''''' punctuation, do you?
Let me take this step by step. Normally, the first sentence would be something like this:
John Doe was a Whig politician ...


Now let's add that he was a peer:
] (]) 23:56, 19 April 2019 (UTC)
John Doe, 1st Baron Doe, was a Whig politician ...
:{{ping|Roy McCoy}} This is all old news and covered many times before. WP has used LQ since the early 2000s. Briefly: Don't double-up punctuation except in unusual circumstances. Thus {{tq|Did Marlin ask Dory, "Can you read?"}} An example of a special circumstance is literal string quotation: {{tq|The newspaper misquoted Smith as stating "I am to resign.", but Smith's actual announcement phrased this as a question, "I am to resign?".}} Thus, when quoting a question in a non-question sentence, the quoted and quoting sentence have separate terminal punctuation. There's no need to do this when quoting a question inside another question and they both end on the same word. Similarly, if you quote someone saying "I'm tired, and sore, and upset, etc.", and your sentence ends there, do: {{tq|He said, "I'm tired, and sore, and upset, etc."}}, not {{!xt|"I'm tired, and sore, and upset, etc.".}} PS: Some British news publications also use typesetters' punctuation (commas and periods/stops inside, no matter what). This is not recommended by British style guides (other than the house styles of some newspapers of course). I did an analysis of this stuff a few years ago, and it turns out there are at least 12 different British quotation punctuation styles among major publishers in the UK. They shake out to very similar to LQ, and very similar to TQ, with various intergrading based on special "rules" made up by particular publishers, and they're generally not compatible with each other. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 18:21, 29 April 2019 (UTC)
^ ^
::Thank you {{u|SMcCandlish}} for your interesting and enlightening comments in response to my questions. My MoS revisions have apparently been left alone, and there doesn't seem to be anything that needs to be done further in regard to them on my account. I would say the deletion of "A question should always end with a question mark" is the less dubious in light of the sample given by you ("Did Marlin ask Dory, "Can you read?"), which is a question but ends with a quote mark rather than a question mark. (I deleted your opening single quote there, by the way.) There has however been no reply as yet to my second concern, which was the incorrect ordering of "and the section you are reading now" under Quotation marks > Names and titles. Can this be corrected? Thanks again. –] (]) 05:01, 30 April 2019 (UTC)
A B
::: I'm sure it'll get ironed out. People making undiscussed {{em|substantive}} changes to MoS usually does get reverted, just not always immediately. What the actual "rules" are should not change without being certain it's what the community supports, since any such change has the potential to affect innumerable articles, especially the more general the point is. PS: the "and the section you are reading now" thing is not an error. Look at the list more closely. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 18:05, 30 April 2019 (UTC)
The commas A and B are paired, i.e. the "parenthetical" title is set off at both ends (unless when there is other punctuation, like at the end of sentence). Let's see what happens without the closing (second) comma:
::::I took another look at my MoS edits (mostly minor – I didn't change any rules), and I think they're okay. {{u|EEng}} reverted one of them, so I suppose he reviewed the others as well. I was going to re-add the "Principal Skinner" text I deleted on April 20, though as a separate item and reworked:
John Doe, 1st Baron Doe was a Whig politician ...
:::::If matter is added or modified editorially at the beginning of a sentence for clarity, it is usually placed in square brackets:<br />" already told me that", he objected.<br />This is preferable to the following, which is likely to be unclear:<br />"He already told me that", he objected.<br />Consider, however, an addition rather than a replacement of text:<br />"He already told me that", he objected.
::::This is better than what was there before, but I finally didn't add it because it seemed to have noticeably too little to do with the sentences subtopic.
::::As for the list, I have looked at it again and it still looks wrong, whether you say it's not an error or not. The line with "and" announces the last item of the series in which it appears, and it ends with a period that furthers this announcement. The following two lines thus appear to be out of order. I call this incorrect. Even if it's somehow technically correct, it's still inelegant, unclear and confusing, and I continue to think it should be emended somehow. –] (]) 01:55, 2 May 2019 (UTC)
:::::I don't disagree with the advice, but it's very partial, and it's a lot of verbiage stating the obvious. This doesn't have anything to do with {{em|beginnings}} of sentences in particular, nor even sentences at all, but any quoted material and editorial change to it. And the case of moving the change out of the quotation is missing. And these examples do not pertain to encyclopedic writing (it's more of the "Dory and Nemo" type of stuff we need to replace). Maybe:
::::::If matter is editorially added to or modified in quoted material for clarity, it should be in square brackets or moved outside the quotation:<br />{{xt|" has pledged to continue the probusiness policies of her predecessor".}}<br />{{xt|"She has pledged to continue the probusiness policies of her predecessor".}}<br />{{xt|Laura Chinchilla "has pledged to continue the probusiness policies of her predecessor".}}
:::::As for the list we've been talking about, here's a hint: It's about the pages, about <code>/</code> versus the displayed <code>&sect;</code> (or <code>#</code> in the actual section links). The error you think you see is illusory. The "and" is the end of a sub-list of ] sections, in a larger, containing list of MoS pages and subpages. I.e., it's the same structure as "I like donkeys; elephants; <u>snakes, turtles, and lizards</u>; and ferrets."<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 08:12, 2 May 2019 (UTC)
::::::What do you mean, "very partial"? You informed me that "People making undiscussed ''substantive'' changes to MoS usually does get reverted ". This was the only such change I made, so I felt I needed to take another look at it in light of your comment. I don't think I was "very partial" at all, particularly given that I was trying to re-add what I had – apparently correctly, if it was so obvious – deleted before. (And if it was so obvious, why hadn't you or someone else already deleted or moved it?) Moreover, I wrote only two sentences on this aside from the revised samples, which is hardly verbose. My original suggestion was that the deleted text, if restored, should be moved to a different location. You apparently concur with that, so why don't you go ahead and do it (though preferably with "pro-business" rather than "probusiness", the latter not reflecting the word's pronunciation).
::::::I'm also wondering why you found it necessary to change <nowiki><br> to <br /></nowiki> in the sample text, when the former apparently does the same thing and is even approved by Misplaced Pages ("The <nowiki><br> or <br /></nowiki> tags are used for a single forced line break." https://en.wikipedia.org/Help:Line-break_handling). I see that only <nowiki><br /> and {{Break}}</nowiki> are mentioned at https://en.wikipedia.org/Wikipedia:Line_breaks_usage, but if "The MediaWiki software converts valid forms like <nowiki><br>, <br/>, and <br > to <br /></nowiki>", then why not let it do that? Perhaps your penchant for unnecessary commas extends to word spaces and slashes as well.
::::::Finally, your technical justification of the apparent disorder in the list does not detract from the validity of what I've been saying about it. "Even if it's somehow technically correct, it's still inelegant, unclear and confusing, and I continue to think it should be emended somehow." And apparently it has been: someone's gone in and fixed it so that the period previously in the middle (which wasn't a semicolon as in your "I like donkeys" sentence) has disappeared. That's an improvement, whether I'm credited with having suggested it or not. –] (]) 17:09, 2 May 2019 (UTC)
:::::::I think this has run its course; you seem to be coming up with disagreements just to have them, predicated on a completely unrelated discussion below. Quickly: What I meant by "very partial" is immediately apparent from everything I wrote after that, especially the scope-expanded revised text I supplied, and explained in detail. I changed to {{tag|br|s}} because the lack of the <code>/</code> screws up the wikitext syntax highlighter; the fix is well within ]. The fact that you still think there's "apparent disorder" in the list, even after the reason for the order has been made clear to you, and no one in the entire history of WP but you has had this "issue" with it, and I even edited it to get rid of "and" for you so this circular back-and-forth would stop, isn't something I care to deal with any further. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 08:39, 4 May 2019 (UTC)
:::::::: Two improvements have been made at my suggestion, which is all I was interested in and so there is nothing essential to discuss further. You did not, however, explain what you meant by "very partial", which in fact was not immediately apparent from everything you wrote after that. It still doesn't seem apparent, however many times I read it. I also didn't understand how the lack of the slash screws up the wikitext syntax highlighter, though I now find your recent explanation of this at ]. This means I've suggested yet a third improvement, so it's not clear why you should be haughty or disrespectful.<br />As for the punctuation itself, the one thing that stayed in my mind following this discussion (which otherwise I'd forgotten, having been reminded of it now only by its appearance somehow in my screen) was the sample question {{tq|1=Did Marlin ask Dory, "Can you read?"}}. While I fully agreed and still agree that a second question mark there looks bad and isn't needed, I still had the nagging feeling that logic – which is what logical quotation is about, right? – nonetheless demanded the second punctuation mark, i.e. one for the main question and one for the quoted question. "Don't double up punctuation except in unusual circumstances" seems like a pretty good rule that covers this fairly well, though it's not clear to me that this shouldn't also extend to {{tq|The newspaper misquoted Smith as stating "I am to resign.", but Smith's actual announcement phrased this as a question, "I am to resign?".}}, (triple punctuation!) as I don't immediately see why the quote-ending period is necessary (unless solely for the purpose of illustration here and it actually isn't). Admittedly it doesn't look as bad as two question marks, but it still looks a bit odd, and unnecessarily. I'm honestly not looking for disagreement here, by the way, and I'm sure you can understand the point. Doubled punctuation marks look odd and can be skipped, but it still doesn't seem to me that this is perfectly logical. –] (]) 00:34, 11 May 2019 (UTC)


If the commas aren't paired, the sentence reads "1st Baron Doe was a Whig politician", and "John Doe" is left dangling at the start of the sentence.
== Another capitalization question ==


Now, let's add the life span. Where do we add it? Before punctuation.
The following is the current lead of the article ]:
John Doe, 1st Baron Doe (1 January 1801 – 31 December 1881), was a Whig politician ...
<blockquote>
^ ^
'''James Buchanan''' (<!--{{IPAc-en|'|b|V|k|æ|n|@|n}}, also -->{{IPAc-en|b|juː|ˈ|k|æ|n|ən}}; April 23, 1791{{spaced ndash}}June 1, 1868) was the 15th ] (1857–1861), serving immediately prior to the ]. A member of the ], he was the 17th ] and had served in the ] and ] before becoming president.
A B
</blockquote>
The commas A and B are still paired. See?
Note that "president" is lowercased (twice) but "Secretary of State" is not. The general convention on articles on U.S. presidents is to indicate the ordinal rank in this form, with "president" in lowercase. However, in this example there is a capitalization conflict with "Secretary of State". Three other articles (], ], ]) also use "president" but "Secretary of State". The articles ] and ] treat it as a proper noun in the U.S. context and consistently capitalize it.
<p>Is this lead MOS-compliant with respect to capitalization of these titles? ] (]) 11:23, 23 April 2019 (UTC)
:No. Should be lower-case. It's capitalized in a construction like "Secretary of State Buchanan" (fused to the name), or in a reference to the position as such and without a modifier ("Mike Pompeo is US Secretary of State, since April 26, 2018"). Even that second case isn't really necessary, but we seem to be doing it. E.g., we have ] (modified, as a plural, thus a common noun), and ] as an unmodified title being the subject itself. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 18:08, 29 April 2019 (UTC)


] (]) 23:04, 25 November 2024 (UTC)
== Translating political party names ==


:The nobility title is a nonessential appositive. Commas go before and after a nonessential appositive. I'm assuming you don't consider the lifespan, which is never set off by commas in a Misplaced Pages article, to be a part of the same nonessential appositive somehow, right? If it's not included in the nobility title nonessential appositive, then it goes outside the commas. ]<sup>(]/])</sup> 00:04, 26 November 2024 (UTC)
Hi. Titles for articles about Swedish political parties differ a lot when it comes to language. For example, the articles for ] and ] are written in English while articles for ] and ] are written in Swedish. What is the appropriate way to deal with political parties from non-English speaking countries? Should they have translated titles or not? I can see a problem with translating every time, names of parties such as ] and ] cannot be translated accurately translated well into English (the translated name for Landsbygdspartiet Oberoende is "Countryside Party Independent", Enhet would translate simply as "Unit"). And that brings us yet another question, how much freedom do translators have? Landsbygdspartiet Oberoende's literal translation sounds awkward, so would it be okay to rename it to, say, Independent Countryside Party just because it reads better? ] (]) 16:42, 24 April 2019 (UTC)
:What do other, reliable English Language sources do ''outside'' of Misplaced Pages? --]] 17:12, 24 April 2019 (UTC)
::These are smaller parties which are rarely, if ever, mentioned in English-language media. ] (]) 17:31, 24 April 2019 (UTC)
:::I find that hard to believe. took all of two seconds. There's a half dozen English-language news sources covering local Swedish issues there, a modicum of effort searching those should turn something up to establish correct usage. --]] 23:39, 24 April 2019 (UTC)
::::I'm not saying that there aren't English-language Swedish news sources, I'm perfectly aware that they exist and I have looked for mentions of these parties in the ones I know of. But as I said, these are *very* small parties with less than 1% of the vote, so I think it's perfectly understandable that they aren't mentioned in The Local. ] (]) 09:13, 25 April 2019 (UTC)
:::If there aren't many English sources that cover a party name, it may be preferable to just leave it in its original language - if there's not an obvious translation then no one is going to be searching for the English name anyway. The is a good source for English names of most European parties and a good number of OECD countries. also has reasonably good coverage. I couldn't find ] in either dataset but it looks ] reference them as the "Independent Rural Party". That translation would make a lot more sense, especially since they appear to be similar to agrarian parties like the ]. ]<sup> ]</sup> 01:05, 25 April 2019 (UTC)
::::I'll check those out, thanks! ] (]) 09:13, 25 April 2019 (UTC)


::No, it doesn't. Sure, the lifespan parenthetical isn't part of the appositive, but neither are the commas, which is demonstrated by the fact that at, if the name and title occurred at the end of a sentence, there wouldn't be a comma; there would be a period/full stop:
==Requested move==
... {{xt|Joseph Smith bequeathed the manor to his nephew, John Doe, 1st Baron Doe (1801–1881).}}
<div class="boilerplate" style="background-color: #efe; margin: 2em 0 0 0; padding: 0 10px 0 10px; border: 1px dotted #aaa;"><!-- Template:RM top -->
:''The following is a closed discussion of a ]. <span style="color:red">'''Please do not modify it.'''</span> Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a ] after discussing it on the closer's talk page. No further edits should be made to this section. ''


::You wouldn't place the parenthetical outside the sentence like this, would you?
The result of the move request was: '''not moved'''. There is a definite consensus ''against'' the proposed requested move. <small>(])</small> <span style="font-family:'Trebuchet MS',Geneva,sans-serif">] (] <span style="color:#fac">桜</span> ])</span> 11:16, 2 May 2019 (UTC)
... {{!xt|Joseph Smith bequeathed the manor to his nephew, John Doe, 1st Baron Doe. (1801–1881)}}
----


::Ergo: normal rules apply, which is that punctuation doesn't precede a parenthetical. (The exception being when there is a complete sentence inside the parentheses, in which case punctuation occurs both at the end of the preceding sentence, i.e. before the parenthetical, and before the closing parenthetical, as shown here.)
] → {{no redirect|Misplaced Pages:Manual of style}} – As pointed out by my dear colleague ], the so-called "Manual of Style" does not actually follow its own recommendations. We do not capitalize common nouns in titles at Misplaced Pages, and "style" is a common noun. This is our '''manual of style''', not some hoity-toity "Manual" of some high-falluting "Style".
::Commas go before and after an appositive (unless there is other punctuation), but that does not necessarily mean immediately after.


::] (]) 10:29, 26 November 2024 (UTC)
I am serious, if a bit facetious. This title is wrong and has no reason to be capitalized. ] ] 00:27, 25 April 2019 (UTC)
:::"Punctuation doesn't precede a parenthetical" is not a rule at all. It's just something you made up.
*'''Waste of time''' The Manual of Style applies only to articles, not project space. What a waste of time. ]] 00:31, 25 April 2019 (UTC)
:::If the parenthetical were being applied to the nobility title, then the parenthetical should go within the commas that set off the nobility title. But the parenthetical is being applied to the actual name of the person, which came before the nonessential appositive that is set off by commas.
*:Nobody made you comment! ] ] 00:43, 25 April 2019 (UTC)
:::If you dislike the placement of the nobility title between the name and the lifespan parenthetical, I wouldn't disagree. I'd happily remove the nobility title entirely from the lead sentence (or heck, the whole article). Or put the lifespan parenthetical first, and then the nobility title. But wherever the nobility appositive is being stuck, it gets set off by commas. That's the rule. ]<sup>(]/])</sup> 13:38, 26 November 2024 (UTC)
*::No, but the opening of this thread "made" me come to see what it's about. Next you'll want '']'' -> ''Arbitration committee''. The main MOS page has literally 150 subpages and 600 redirects pointing to it and on top of that there are (easily) a thousand, if not ''thousands'', of redirects and shortcuts pointing to the subpages. All of those would need to be moved and updated, and inevitably some links in old discussions will be permanently broken through some slipup -- all just to scratch someone's obsessive-compulsive itch. ]] 02:28, 25 April 2019 (UTC)
:::This one is simple: a comma is ''never'' placed immediately before other punctuation. Instead it's placed ''after'' them or, in case or semicolons and periods, omitted altogether. While ] doesn't say so quite explicitly (supposedly treating it as one of these common sense things that everybody already knows?), it gives an example of how to do it correctly: "Burke and Wills, fed by locals (on beans, fish, and ngardu), survived for a few months." (With the second parenthetical comma ''after'' the closing bracket.) So, by analogy, "John Doe, 1st Baron Doe (1 January 1801 – 31 December 1881), was a Whig politician" is indeed correct. ] (]) 08:58, 28 November 2024 (UTC)
*:::As a member of the ] I have to say that looking for improvement in writing style is not a waste of time. Many of us spend some time changing capitalization in articles. But tiny errors in style do add up and in my humble opinion it is a kind of unwarranted conformism and even outright insulting to state trying to fix such things is a waste of time or a compulsive itch. ] (]) 18:19, 25 April 2019 (UTC)
:Concur with the OP and with Gawaon on the typographical point; we don't use a comma right before a round-bracketed parenthetical, nor does much of anyone else in the world. One might make an argument that "logically", in the way a computer program would approach logic, there should or could be one there, and this is the direction Muéro has been going, but human language does not operate on such a basis, being a matter of convention combined with expediency, not a matter of a JSON-like syntax in which a comma that really should not be needed to parse the material must be present anyway or the operation will fail.<p>That said, we do have several interrelating issues in play in this titles and post-noms sector that are worth cataloguing and considering in some detail:</p>
*:::::The "unwarranted conformism" here is the overworrying about this tiny "error". I'm all for fixing things, but not where the cost far outweighs the benefit, as here. ]] 19:07, 25 April 2019 (UTC)
:# Something like "Xerxes Youill Zounds, Grand Poobah of Elbonia–Brobdingnag (3 May 1571 – 24 July 1644), was ..." is {{em|always}} indicating the life-span dates. If there is a need to specify the duration of a peerage, including a change in titles, that should be done in plain English in the article body, and is not going to be lead-sentence or even lead-section material. It's body material, like "Upon the death of his father, Zounds became 3rd poobah of Elbonia on 12 December 1629. He was elevated to 1st grand poobah of Elbonia–Brobdingnag on 20 June 1639 by High King Korki IX of Kerblachistan. Zounds was also the bishop of Lilliput from ca. 1630 to 14 February 1633, when he was defrocked by the archbishop of Elbonia."
*::::I'll second that. Asserting opponents' mental disorders is never a useful or even intelligent argument and has no place in civil discourse. Too bad the community tolerates it. &#8213;]&nbsp;] 18:57, 25 April 2019 (UTC)
:# As an anti-classist myself, I still have to observe/concede that "don't include any titles or post-noms because they are classist" is not a viable position. WP is ], and when any such title or honor (whether earned or hereditary or otherwise) is pertinent to a notable article subject, it should be covered, more prominently the more important it is within the context of their notability. (See below for an idea toward suppressing lead inclusion when not related to notability at all but a late-coming add-on to the pile of someone's life aachievements.)
*:::::That's crazy -- it's no different than saying "That's crazy." ]] 19:05, 25 April 2019 (UTC)
:# There's a been a very long-standing {{lang|la|de facto}} consensus to always include peerage titles {{em|and}} important post-nominals (but not academic or professional titles or post nominals like "Dr" or "PhD", or guild/union stuff like "]", "]") in the lead sentence. Virtually every applicable article has been written this way.
*::::::You're wrong, it's distinctly different. But even "That's crazy" is a pointless non-argument; the only meaningful part is why you feel it's crazy, so the "That's crazy" preface could and should be omitted. &#8213;]&nbsp;] 19:10, 25 April 2019 (UTC)
:# A recent-ish RfC (I seem to have lost the link to it – help me out?) with probably much too low a turnout upended part of this, and now has us remove the post-nominals from the lead {{em|sentence}}. This has not sat well, and actually introduces some writing problems that the RfC participants did not anticipate. For example, WP does not, except in an article on the subject being abbreviated, introduce an acronym/initialism unless it is going to be re-used later in the same article. But if our bio subject's investiture as a ] is covered in the body only, the point at which this is done has no need to a "KCB" appearing at that point, since "KCB" is used as a post-nominal not otherwise and would not be re-used later in the article; the result is that the "KCB" that applies to this person has no logical place to go in the article any longer, since it was actually only pertinent in the lead sentence, attached to the person's name. We could do something very awkward like state that this knighthood entitles/entitled this person to use "Sir" or "Dame" and the post-nominal "KCB", but this sort of blather would have to be repeated throughout many thousands of articles, and was already very concisely conveyed by the original lead sentence without having to spell it out and micro-] the bio article with detailia about how a particular order's nomenclatural rules operate. Simply showing rather than telling was better.<p>So, this really should be re-RfCed, at a higher-profile venue like ] so we are certain that the community at large really wants to impose this lead rule change and its problems all in the name of shaving a few characters off the lead sentence. "The postnoms will be in the infobox anyway" isn't the (or an) answer, since not all bios have infoboxes, and there is staunch resistance to adding them in many cases. A potential compromise might be to not include postnoms in lead sentence but in an infobox when one is present and has a parameter for it.</p>
*:::::::It's shorthand for "Your contribution to the discussion seems, at least to this observer, to be severely lacking in the validity of either its premises or its reasoning. You are strongly encouraged to revisit it in light of this commentary." But saying, "That's crazy" saves a lot of time. ]] 19:24, 25 April 2019 (UTC)
:#Even without revisiting that with a better RfC, the present wording at ] is daft: "post-nominal letters may be included in the main body of the article, but not in the lead sentence of the article". This has already lead to dispute about whether it means post-noms are banned from the entire lead or only the literal lead sentence, because it only addresses the lead sentence and the post-lead-section article body. The correct answer (if you look at the RfC discussion and the alleged consensus arising from it) is that this should instead read something like "post-nominal letters may be included, but not in the lead sentence of the article"; there was no consenus to ban them from the entire lead section. However, this runs into the problem above: Because post-nominal letters are used directly with full names, and generally only upon first introduction, there effectively is no practical place for them, in the lead section or in the article body, other than the lead sentence (except arguably in an infobox if it's there and has a place for this information).
*::::::::Equally vacuous: "Your contribution to the discussion seems, at least to this observer, to be severely lacking in the validity of either its premises or its reasoning. You are strongly encouraged to revisit it in light of this commentary." Again, nobody cares that it seems that way to you, what's meaningful is why you feel that way; i.e., your counter-argument. Examples of other pointless cruft: "Nonsense." {{emdash}} "That's the most ridiculous thing I've ever heard." {{emdash}} "I'm shocked/saddened/disappointed that" &#8213;]&nbsp;] 20:34, 25 April 2019 (UTC)
:#Next, there's a misapprehension here (evidenced in the beginning of this thread) that this anti-postnom RfC result somehow also means to remove peerage and nobility titles from the lead. It does not. They are a different category of thing and were not addressed in that RfC. It is possible that a consensus might be reached to remove peerage titles when they are not pertinent to the subject's notability (e.g. that would have been the case with ] had he remained an actor/director/producer only and not taken a seat in the House of Lords). There are also many life baronetcies created late in the life of the recipients and to little public awareness; a case can be made to exclude them from the lead sentence and probably from the entire lead section. But this is something for a consensus discussion on an article-by-article basis, or for a new RfC if we wanted a categoric rule of some kind about it.
*:::::::::That's silly. Often the simple realization that a fellow editor finds your position startling is all that's needed. Or it can act as an intensifier introducing a more substantive comment, as indeed I've used such characterizations in this thread. Now stop being so serious. Jeesh. ]] 21:04, 25 April 2019 (UTC)
:#A side issue is that some parties from the nobility and peerage wikiprojects have, by ] behavior, programmatically usurped the {{para|name}} parameter of {{tlx|infobox person}} and its offshoots, abusing it to hold the peerage title, when that really belongs in {{para|postnom}} since it is in fact post-nominal (it's just not a post-nominal abbreviation). See ] for the typical absurd result. Because this has been done to thousands and thousands of articles and involves yet another "wikiproject rebellion" against the norms of the entire rest of the project, I suspect this is probably best addressed with another WP:VPPOL RfC so there can be no doubt about the community consensus level of the result (which will obviously be to stop having our infobox blatantly lie to our readers that Margaret Thatcher's {{em|name}} is "The Baroness Thatcher". For the Thatcher case, the obvious solution is: {{para|name|Margaret Hilda Thatcher}}{{para|honorific_suffix|Baroness Thatcher&lt;br /&gt;{{tlp|Post-nominals|country{{=}}GBR|size{{=}}100%|LG|OM|DStJ|PC|FRS|HonFRSC}} }}, and this is what agrees with the lead of the article. (Note lack of "The" before "Baroness".)</p><p>These infoboxes are also failing ] by including honorific {{em|salutation}} phrases like "The Right Honorourable" that are not part of the name in any sense, but used when writing a letter to such a person or when introducing them as speaker, and so on; that sort of information does not belong in a bio article (much less thousands of them robotically) but in an article on forms-of-address etiquette and probably again in the article on the title (baronet or whatever the case may be).
* '''Support'''. Not because I really care about capitalisation edge cases, but because I believe that consistency is good for everyone most importantly the newcomers. The MOS should be consistent with its own advice. —] (]) 00:32, 25 April 2019 (UTC)
:There are probably other issues to address, but this is a lot already. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 13:42, 11 December 2024 (UTC)
*:I should point out that I summoned you, which could technically be "canvassing". Anyone looking to count votes could discount this one to be "fair" ] ] 00:44, 25 April 2019 (UTC)
*:: It’s ok. Consensus decision making is based on strength of opinions, not vote counting. I obviously wholly share your opinion given in your nomination. Be to create some independence of argument I emphasise the importance of consistency. I do not mention that I enjoy the kick to the shins for the high-falluting grandstanding perception that the MOS carries. Not that I dislike the MOS, it is essential, but should not be taken so seriously. —] (]) 01:07, 25 April 2019 (UTC)
*:::All the more reason not to robotically apply it here, ignoring all the trouble that doing so will cause. ]] 19:05, 25 April 2019 (UTC)
*'''Oppose''' <s>Comment</s> Could a case be made for using ] since the MoS is essentially a guidebook rather than a single article? (I'm also tempted to oppose on pure ] grounds: I think Mos looks lamer than MoS, and I don't think it really matters since this isn't article space). Edit: I'm changing my !vote to '''oppose''': I agree with Jayron32 that WP:BROKE applies here. ]] 16:06, 25 April 2019 (UTC)
*: ] is well accepted as an abbreviation for ]. ] will continue to function as a redirect to ]. —] (]) 02:04, 25 April 2019 (UTC)
*: I too fall in the position that the MOS is a long work (inb4 EEng with some sarcastic image about how lengthy it is ), for which we typically capitalize significant words. --] (]) 13:24, 25 April 2019 (UTC)
*'''Support'''—On this occasion I have to go against the view of the excellent EEng. For years, en.WP has been in harmony with CMOS, the Oxford Style Guide, and many other authorities, in telling us to minimise unnecessary caps. So we do, largely. It's weird that the title of our style guide clashes with this. ] ] 02:40, 25 April 2019 (UTC)
*:So why doesn't the Oxford Style Guide call itself the "Oxford style guide", or CMOS call itself "Cmos"? --<span style="box-shadow:2px 2px 6px #999">]]</span> 03:14, 25 April 2019 (UTC)
*:::] ] (]) 03:23, 25 April 2019 (UTC)
*::That's a pretty good catch, but to be fair, those are proper names, while the title of our style guide isn't because ... well, for some reason that escapes me. I'd be totally with this change if we were starting from scratch. But there are so many things that really need doing around this joint, and this will no doubt cause all kinds of headaches we're not thinking of -- minor headaches probably, but unnecessary ones for sure. Perhaps we can let the current form of title be a constant reminder that MOS does not apply to MOS (something that comes up now and then, as when someone demands that it be regularized to use either BrEng or AmEng, instead of continuing to display the shocking promiscuity in which it currently indulges). ]] 03:26, 25 April 2019 (UTC)
]]}}]]
]&nbsp;]}}]]
]]}}]]
*'''Oppose''', MOS reduced to Mos? The continuous upper-case lower-case MOS discussions finally turned upon MOS itself, like a wandering bird coming back to its birthplace to roost? In these hallowed halls common sense should prevail, so per EEng, who speaks truth-to-lower(case). ] (]) 02:53, 25 April 2019 (UTC)
**No, abbreviations in English are almost always capitalised. Our own advice, echoed elsewhere, is not to cap the initials of expanded forms of abbreviations just because the abbrevation comprises caps. ] ] 06:48, 25 April 2019 (UTC)
* Every time you use "]" to refer to anything other than complementary metal–oxide–semiconductors an electronics engineer cries. If you don't want salty tears corroding your PC, please don't do that. --] (]) 03:24, 25 April 2019 (UTC)
*:Surely you mean "an electronics engineer is shocked"? <small>Hyphen{{ndash}}dash warriors, please open a separate thread. ]] 03:27, 25 April 2019 (UTC)</small>'
*::I have launched an investigation into this horrific case of dash abuse at ]. —] (]) 13:25, 26 April 2019 (UTC)
*::::<small>Weeps quietly. ]] 18:22, 26 April 2019 (UTC)</small>
*:Speaking of shocked, I don't see how an EE can make such a bastardized plural of complementary metal–oxide–semiconductor, as if CMOSs was meaningful. CMOS probably says not to do that. ] (]) 05:32, 25 April 2019 (UTC)
* '''Oppose''' along the lines expressed by gnu57. The title could be simply ]. But "Manual of Style" gives it the status of an online ''work'' within WP. It is thus a proper name and must be rendered as such. ] (]) 05:31, 25 April 2019 (UTC)
* '''Oppose''' for the same reasons given by Jmar67, EEng, and Randy Kryn. --] (]) 05:42, 25 April 2019 (UTC)
*<Small>Comment: I'm staying out of this one but have popped some popcorn. 🍿 ] (they/them) (]/]) 06:06, 25 April 2019 (UTC)</small>
*'''Support, but prefer ]''' for consistency with other policy and guideline pages that use sentence case. This is a guideline, and thinking of it as a "manual" feels overindulgent. Would we create something like ']' or ']'? "Manual" also make it sounds like something that belongs in the ] Those that think of this like an "online work within WP" or want to create a "Manual" could transwiki it to ] and make it so. -- ] ] 08:20, 25 April 2019 (UTC)
*:] is a widely-used term outside Misplaced Pages, unlike your other examples. The opening paragraph of that article says it's a set of standards and says nothing about physical form or structure. If Misplaced Pages actually used ours like manuals of style{{emdash}}i.e. in-house ones, not style guides like <s>CMOS</s> <u>CMoS</u>{{emdash}}are generally used outside Misplaced Pages, "Manual of style" would be the obvious choice. Since we don't, it seems misleading and unhelpful. But we are both far outside this discussion's scope, predictably. &#8213;]&nbsp;] 08:59, 25 April 2019 (UTC)
*:: An ''internal'' document would normally be referred to as a "style guide" or "style manual". The phrase "manual of style" is used more for how-to guides meant for general consumption - notably and predominantly the ''Chicago Manual of Style''. showing that "style guide" would be the most popular of these phrases, and "Manual of Style" quite rare when you subtract the CMoS from results. For Misplaced Pages internal purposes though, ] would be sufficient. -- ] ] 12:11, 25 April 2019 (UTC)
*'''Oppose''' - I initially assumed I would support this move, but on this subject suggests a "consistently capitalized in a substantial majority of independent, reliable sources" and that the current capitalisation is therefore the correct one per ]. Also, per {{u|EEng}}, there is a distinct ] issue here. I suggest this be speedy closed fairly soon. &nbsp;&mdash;&nbsp;] (]) 09:22, 25 April 2019 (UTC)
*:Per , subtracting CMoS from "Manual of Style" reduces the difference to statistical insignificance, especially considering the likelihood of a few other accidentals. &#8213;]&nbsp;] 09:32, 25 April 2019 (UTC)
*'''Oppose''' per ], ], etc. --]] 13:55, 25 April 2019 (UTC)
*'''Support'''. Why not. —]&nbsp;(]&nbsp;&#124;&nbsp;]) 14:33, 25 April 2019 (UTC)
* '''Support instead ] '''. The current is broken. It does not follow its own advice. It self-asserts the singularity of a “Manual of Style”. “Misplaced Pages’s Manual of Style” would nicely, unambiguously, state with emphasis that manuals of styles exist, and this one is Misplaced Pages’s, and this one unambiguously has its unique composition title. Claims of a title change affecting shortcuts or having other affects are not true. —] (]) 02:38, 26 April 2019 (UTC)
*'''Oppose'''. I consider it to be a proper noun, ''The Misplaced Pages Manual of Style'', analogous to '']''. ] (]) 02:53, 26 April 2019 (UTC)
*'''Oppose''': The MoS is a creative work. The Misplaced Pages guidance for the capitalization of the titles of creative works is found at ], and the title follows that convention. —] (]) 13:04, 26 April 2019 (UTC)
** Only a MOS:CT enthusiast will appreciate the logic of what you just said. For the conversant, it is convoluted. For the newcomer, it is quite opaque. Again, broad understanding of the MOS is BROKE. If barriers can be reduced, they should be. —] (]) 13:25, 26 April 2019 (UTC)
*'''Oppose'''. As others have pointed out, it's not <em>a</em> manual of style, it's <em>the</em> Misplaced Pages Manual of Style. ] (]) 13:38, 26 April 2019 (UTC)
*'''Oppose'''. Per EEng, fixes nothing -- waste of time and efforts of all of us. --]<sup>(])</sup> 16:38, 26 April 2019 (UTC)
*'''Oppose''': Waste of time, ''Manual of {{xt|S}}tyle'' looks better. --] <sup>(] &ndash; ])</sup> 19:45, 26 April 2019 (UTC)
*'''Oppose'''. It is normal for a specific example of a manual of style (lower case) to be titled something like "Podunk Manual of Style" (title case). Ours fits into that pattern, so there is nothing wrong to fix. And as others have already stated, trying to fix this would introduce more problems than the zero that it solves. —] (]) 20:02, 26 April 2019 (UTC)
*'''Neutral''': In my view, the guideline title could be interpreted either as a title name of the published work ('''''Manual of Style''''') or a common noun phrase ('''manual of style'''), so I don't mind changing it to align with the naming conventions guidelines' title format (e.g. ], ]). For this aspect, I agree with {{u|EEng}}, quote "{{tq|I'd be totally with this change if we were starting from scratch.}}" But if the name change causes more trouble than what it would ever benefit, then don't change it. Sounds simple, right, my fellow Wikipedians? —] (]) 23:56, 26 April 2019 (UTC)
*'''Oppose'''. Per many of the previous arguments against. ] (]) 17:14, 28 April 2019 (UTC)
*'''Oppose''': This is a creative work. We call it Misplaced Pages:Manual of Style because of the conventions of Misplaced Pages, but it could stand alone as ''The Misplaced Pages Manual of Style'' and be capitalized as a creative work. Alternatively it could be listed as Misplaced Pages:Style. <span style="background-color:#EEF6FD"><span class="nowrap">&nbsp;]&#124;]</span></span> 00:15, 29 April 2019 (UTC)
*'''Oppose''' per much of the above. It's a proper name of a specific work (albeit an internal one), thus is perfectly compliant with ]. WP uses sentence case for encyclopedia article titles, but this rule doesn't apply to other namespaces. We tend to go lower-case on them (even with ] pages, but those are also not akin to published works. MoS is essentially a book in wiki form, though not intended as general writing advice for the entire world. Anyway, I would instead suggest some counter-cleanup, like moving all "WP:WikiProject foo bar" (or the really confusing ones, "WP:WikiProject Foo bar") to "WP:WikiProject Foo Bar" as proper names. Or at least move them all to have a consistent format one way or the other. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 18:05, 29 April 2019 (UTC); revised 21:50, 29 April 2019 (UTC)
*'''Oppose''' - wow, I haven't added my opinion in the quest to find consensus like this in a long time. The MoS only applies to the main space, not the project space. ] (]) 08:09, 30 April 2019 (UTC)
*:And if you read some of these arguments, you can see why it sometimes doesn't even apply in mainspace. Sheesh. ] (]) 03:19, 2 May 2019 (UTC)
----
:''The above discussion is preserved as an archive of a ]. <b style="color:red">Please do not modify it.</b> Subsequent comments should be made in a new section on this ] or in a ]. No further edits should be made to this section.''<!-- Template:RM bottom --></div>

== Page header not displaying in mobile view ==

I use the mobile view almost exclusively. After a recent edit to this talk page's header by another user, I realized that the desktop view displays a header that I do not see in the mobile view. Does anyone using mobile remember seeing a header displayed here? It does seem like there used to be one. ] (]) 00:14, 27 April 2019 (UTC)
* I use desktop, iPad, iPhone landscape and iPhone portrait. There have been a lot of silent changes in display by Misplaced Pages software over the last year, with some crazy things briefly oblong the way. Problems seem to get fixed faster than I can understand the problem I experienced. I think things are quite good at the moment. —] (]) 04:21, 28 April 2019 (UTC)
* And what do you mean by "header"? Are you talking about section headings? Templates at the top of the page? If the latter, various {{tag|div}} CSS classes have suppressed display in the mobile view. E.g., if you go to ] in mobile, you'll find a heading for the noticeboard archives but no actual archive links available, until you switch to the desktop view. This isn't really ideal, but it's also not really an MoS matter. More a MediaWiki developers + ] regulars matter. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 21:53, 29 April 2019 (UTC)
*: Yes, I mean the set of templates shown at the top of the talk page. This is not related to the style-related content of the MOS but rather to the talk page itself. The Help Desk referred me to VPT, but I wanted to get feedback here first. ] (]) 01:23, 30 April 2019 (UTC)
*::Right then. Definitely a VPT matter, since this is all about how the mobile version is coded, and how our CSS is coded to work with it. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 18:02, 30 April 2019 (UTC)

== Spaces before unit symbols ==
{{Moved discussion to|Talk:35mm movie film#Requested move 28 April 2019}}
] says to use non-breaking spaces before unit symbols (as in "35&nbsp;mm"). But some editors have recently moved pages to squeeze the space out of the title, as in ] and ], because that unspaced form has become somewhat more common in popular sources in recent decades. This seems like the usual COMMONSTYLE fallacy to me. Shouldn't we try to be more consistent than that, in following the use recommended by standards organizations and our own MOS like we do almost everywhere else in WP? Is 35mm in some way special about this? ] (]) 02:31, 28 April 2019 (UTC)
:Absolutely. We've followed the International Standards Organisation for a long time now. It sets the most authoritative, consistent, logical, and respected standards. ] ] 02:34, 28 April 2019 (UTC)
]
:: Don’t go overboard. Most units (not %, not degrees Celsius) should for sure have a nonbreaking space. But sometimes a measurement transforms into a name. “400-35mm film” is a leading example. The name is derived from a millimetre measurement, but it became a name. —] (]) 04:18, 28 April 2019 (UTC)
:::Cases where units don't get spaces are enumerated at ]. It doesn't apply to mm. I'm not asking about things like the Canon lens names (e.g. ]), but when the film width is a simple measurement as in ] and ], we should respect the conventions. ] (]) 05:29, 28 April 2019 (UTC)
:::And I've never heard of "400-35mm film". What is that the name of? Or do you mean an ISO 400 35 mm film, such as ]? ] (]) 05:33, 28 April 2019 (UTC)
:::: Yes. Although it is quite a distant memory needing to specify 35mm. My first camera used a smaller width film that became hard to find. 100 and 400 were the standard choices. The 35mm film memories are mixed with things like 18-55mm lenses. It was very common for the space before the unit to be lost when a measurement in millimetres was not the point. —] (]) 07:17, 28 April 2019 (UTC)
:::::I recall seeing 100m used in articles on sprint and swimming races. No one objected when I moved them to ISO spacing. ] ] 11:33, 28 April 2019 (UTC)
:::::: I wouldn’t expect it. In a 100m sprint, 100 metres the measurement is kind of central. Less so an 18-50mm lens, but I can’t see why someone would be upset. Was Dicklyon concerned about this: ]? It is a bit odd, section titled “RfC”, but not. Midstream, the “RfC” driver makes actions. —] (]) 11:49, 28 April 2019 (UTC)
:::::::I'm not upset, just trying to call attention to an error that was made and move things along in a consistent direction. I don't think your fragmental memories of photographic terminology are particularly relevant here. It's a measurement in SI units, and treating it oddly just obfuscates that. The opinions at that discussion do not seem to have been voiced with our own MOS in mind (nobody mentioned it), just a scan of some popular sources. The spaced version remains very common, too, and there's no reason given to treat this case differently from others. ] (]) 18:58, 28 April 2019 (UTC)
:::::::: I must have had a ] cartridge camera. I have some of the thin negative strips. The purpose of scratching out these memory fragments is for me an attempt to find any remote reason for “35mm” to be a name, and I do not find a reason. Spaced versions and non spaced versions exist without any apparent meaningful distinction, I think it is just a style issue. —] (]) 12:30, 30 April 2019 (UTC)
:::::::I'll start an RM when I get a chance, and link it here. ] (]) 19:04, 28 April 2019 (UTC)
:::::::By the way, I find it hard to imagine that your first camera used a smaller film width than 35 mm. There was no format like that that I know of in the last 70 years, except for toy and spy cameras such as the ], and the 1972 ]. More likely if you're an old guy like me you started with size 127 or 120 roll film or 35 mm, or a 70 mm size 116 roll film, which is actually what I started with using a very old camera. ] (]) 19:11, 28 April 2019 (UTC)
Here: ]. ] (]) 19:30, 28 April 2019 (UTC)
:Yes, move them back to properly include the spaces. This can be done speedily via ]. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 18:02, 29 April 2019 (UTC)

== "Decorative quotations" again ==

Some while back we had an RfC here, to consistently recommend use of {{tlx|quote}} or the {{tag|blockquote}} element for block quotations, and deprecate the use of decorative quotation framing devices (colored boxes, giant quotation marks, etc.), which are a ] style, and to also remove support for use of pull quotes at all in main space.

I didn't notice at the time but {{U|Herostratus}} misread the RfC results and rewrote the template documentation to basically say the opposite of what the conclusion was: . Several of the things that version said are flat-out incorrect.

I've belatedly fixed this to reflect both the RfC results and what MoS and other pages say about this stuff:

Herostratus has reverted this with the ] "Liked it better before", and then cited ], but it was Herostratus who actually made the undiscussed major changes in the first place. I've restored my version, as actually compliant with the RfC consensus and the guidelines. So, this seems to be an impasse. We can RfC this here if necessary (doing it at the template talk page is probably a waste of time since virtually no one watchlists it), but just a general discussion is probably enough to resolve the issue.

PS: That sounded grouchier than intended: I don't think Herostratus is "being bad" for not codifying something that agrees with the RfC and the relevant ] material, since ]. And some of my version might be better integrated directly into guidelines, though it's intended to address several forms of (very frequent) abuse of quotation templates, at the template's doc pages were it'll be seen (] emphasis, decoration for its own sake, confusing {{lang|la|non sequitur}} placement, over-quotation, using block quotes for very short quotations, mis-placement of citations inside the quoted material, etc.). <br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 18:02, 29 April 2019 (UTC); revised 23:30, 29 April 2019 (UTC)
:I agree that the type with the giant quotation marks looks darn awful, but I don't really see any problem with the judicious use of <nowiki>{{quote box}}</nowiki> for primary-source quotations. I think of them as akin to images+captions in that they offer specific examples or details related to the summary-style overview they run beside. Glancing over a few articles with the quote box template, ] provides relevant excerpts from his writing, ] includes pithy remarks of Chaplin on his own life events, placed at relevant junctures, and ] gives a fascinating first-hand account from a fighting ace. I agree that they can be hokey or misplaced (e.g., ], ], ]), but I don't think the tendency to misuse them justifies discouraging all use. Cheers, ]] 00:31, 30 April 2019 (UTC)
::I've said something along these lines myself. What we probably need is a fork of that template exclusively devoted to primary-source excerpts and documented as such, and named accordingly; and then to change the code of the original and its variants – abused literally thousands of times to "decorate" everyday block quotations – so that in mainspace they just emit the same code as {{tlx|Quote}}. And do the same thing to the "giant quotation marks" templates like {{tlx|Cquote}} and {{tlx|Rquote}} (other than they need no variant that does what they do in mainspace, for any reason). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 17:57, 30 April 2019 (UTC)
:::Well first of all ], could you point to the RfC you're referring to, thanks. I don't know where it is. ] (]) 12:03, 1 May 2019 (UTC)
::::You must know where it is since you cited it as the rationale for your major and counterfactual changes to the page in the first place. But others may not, so I'll dig it up later. I'm running late for something, and can't do it right now. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 13:44, 1 May 2019 (UTC)
:::::I don't know where it is, I can't remember everything, including exactly what's in it. If you have to "dig it up later", it sounds like you don't either, right off, so my question would be, when did you last read it? If it's not recently, how can you be so confident of what it says? ] (]) 15:45, 1 May 2019 (UTC)
::::::Please. I was not kidding; I really had to leave. See also ]; you're perfectly capable of looking in the handy WT:MOS archives at the top of this page by yourself. :-) I don't have time for this right now; real-life stuff takes precedence. Yes, I re-read it recently; that doesn't mean I have the archive page number memorized. Sheesh. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 20:00, 1 May 2019 (UTC)
{{od}}Well, of course; I wasn't demanding you do anything right away, was I? Take as long as you want, weeks or months if necessary... there's no hurry, and we want to get this right. And I mean you brought it up, you should provide the pointer. But OK whatever. I assume you're talking about this: ].

Well OK let's see. It is long, 148 KB. Well, the close was by jC37. He's an admin and wasn't involved, so that's fine. He wrote:

{{talkquote|While I understand there were several questions in the various headed discussions, there was much overlap, so I'm closing this all together.{{br}}{{br}}A few things to note:{{br}}{{br}}First, as this is a style question of ''format'' of quoting (which template to use, whether templates should be used, etc.), much of the discussion concerns ILIKETIT/IDONTLIKEIT comments.{{br}}{{br}}Second, albeit with some clear exceptions, guidelines are generally to reflect consensus and common practice, not the other way round.{{br}}{{br}} So while keeping the above in mind, '''use of quotes in articles using some form of template has consensus'''. Though there was discussion concerning what the appropriate styling should be (and whether more than one style - such as with or without a border-box, oversized quotation marks, shading, adjusted font size, etc.), and whether the templates should be merged or to remain separate - none had overall consensus. This close does not prevent a follow-up RFC on such styling. Once that is determined, then a followup to that would be implementation of how to address the current styistic usage in articles.{{br}}{{br}}There '''is consensus that "pull quotes" should be avoided in most cases, but should be left to editorial discretion'''. So the templates' "intended usage" should be edited to remove that usage as a suggested general example, as necessary.}}

So let's see: I edited {{tl|Quote/doc/boilerplate}}, which is transcluded into the documentation for various templates used for quotations in articles, viz. {{tl|Cquote}}, {{tl|Rquote}}, {{tl|Quote box}}, {{tl|Quote frame}}, and {{tl|Quote2}}). If I recall correctly, all of these templates were ostensibly, in their documentation, used for "pull quotes". {{tl|Quote/doc/boilerplate}} is ''not'' transcluded into the documentation for {{tl|Quote}}, which which was never intended or used for pull quotes, but only ever for regular quotes.

OK, so based on the RfC close the ''main'' thing we wanted to do is remove advice to use pull quotes? Right? The closer wrote "There is consensus that 'pull quotes' should be avoided in most cases, but should be left to editorial discretion. So the templates' 'intended usage' should be edited to remove that usage as a suggested general example, as necessary". OK so far?

So let's see.. to that end, here's what I did:

1) Removed thes two sentences from the beginning:

{{talkquote|"This template is meant for pull quotes, the visually distinctive repetition of text that is already present on the same page. In most cases, this is not appropriate for use in encyclopedia articles."}}
The first sentence was removed to follow the instruction "So the templates' 'intended usage' should be edited to remove that usage as a suggested general example". (I removed the second sentence because it not needed and lost its referent. You'd have to rewrite it to read "In most cases, pull quotes are not appropriate for use in encyclopedia articles", but with all other references to pull quotes removed, this would be confusing non sequiter. IMO. If for some reason you wanted the second sentence restored, we could talk about that, and where to put it.

2) Changed "pull quote" to just "quote" in three places:

{{talkquote|"Pull quotes work best when used with short sentences"-> "Quotes work best when used with short sentences; "For typical pull quotes..." -> "For typical quotes..."; and "For very short pull quotes..." -> "For very short quotes...".}}

That's it. The goal here was to change the text as little as possible, so as not to exceed the remit of the precise instructions given in the RfC close, which was to remove instructions saying or that pull quotes are something we implicitly recommend by providing these templates for them. Without ''dis''couraging them either.

To that end, I did not change the textbox at the top of {{tl|Quote/doc/boilerplate}} which says "This template should '''not be used''' for block quotations in article text" (emphasis in original), even though this makes the documentation kind of contradict itself. Which is mediocre, but I mean I was hoping to avoid another several years of fighting over this. '''I absolutely should have''' removed that text box. Because the close said

{{talkquote| Though there was discussion concerning what the appropriate styling should be (and whether more than one style - such as with or without a border-box, oversized quotation marks, shading, adjusted font size, etc.), and whether the templates should be merged or to remain separate - none had overall consensus.}}

Since there was no consensus that any one style was "right", obviously a large billboard admonishing editors to not use certain styles isn't appropriate. But whatever. I was bending over backwards to avoid more years of vexations litigation. Recognizing the ah politics of the situation, I believe that it'd take a whole nother RfC, probably taking tens of man-hours, several calendar weeks, and I suppose another 148 KB of text, to get the documentation all shipshape and Bristol fashion -- if it could even be done, which I'm not super confident of.

I mean, what honestly was I supposed to do. Nothing?

So, I mean... so far, I'm not super happy with recent events to far... besides kind of throwing shade on me, making ''me'' look up the location pertinent to the issue that that ''you'' were bringing up, adding like several paragraphs to {{tl|Quote/doc/boilerplate}} that are totally your own personal preferences (even tho this has been a fraught subject that has been extensively discussed in the past -- including the large RfC noted above -- and ignoring my ] rollback of your extensive changes and going to 2RR... it's not a good look, so far.

So, where do we want to go from here? If you don't want to just let it go, there're a number of next steps we could take. We want to be careful how these things are presented tho. "How should RfC close X actually be interpreted, that is, what precise changes with what precise wording should be made to what pages, since the closer did not specify these exactly" is a very difficult question to answer in a community discussion, I think. I suppose you could ask an admin at ] to review the RfC, interpret the close, and make such changes as are called for. Or probably other stuff. You could keep edit warring, then go to ], and if you frame it right and get lucky maybe you could "win" that way. You never know.

Or... if you want to have a new RfC on the merits of the case, I suppose you could... it's been a year and a half. I think it'd be wasteful and not change anything, but it's your prerogative I guess.

The one thing that I don't want to see is getting content questions mixed up with procedure questions. That's no good. As you can see, the one other editor that responded in this thread addressed the ''merits'' of the question, which is not what is wanted. We want to be real careful to avoid that. ] (]) 00:44, 3 May 2019 (UTC)
:There've actually been multiple discussions about this over the last few years (including followup to the one you found, which resulted in removal from MoS of all support for pull quotes in mainspace at all; but the on you found was itself a followup to one not long before that, and a heavily canvassed one at VPPOL, and a TfD thread, and various other things that all inter-related, until people got kind of worn out about it). Just coming from a WT:CS1 thread with a similar "buncha discussions back when" situation, I'm drawing the conclusion that its probably better to have a new discussion than do a he-said-she-said analysis on old ones. Even 6 months is sometimes enough for people to start making ] noises.<!--
--><p>I've taken "your version" of the template documentation in question as good faith (and no shade-throwing was intended, I just didn't find the ILIKEIT-themed revert summary appropriate). But it has serious problems, mostly caused by simply substituting "quotes" or "quotations" in place of "pull quotes". E.g., one of the results of that, "Quotes work best when used with short sentences, and at the start or end of a section, as a hint of or to help emphasize the section's content", is factually wrong on all three points contained within it, just for starters. It was arguably correct about ], but is entirely wrong about ]. It's almost certainly the direct cause of the sharp uptick in misuse of quotations. People are {{em|simulating}} ], using the same over-stylization/pointless decoration, and the same unhelpful, magzine-style placement, and unduly emphasizing tiny micro-quotes, all without any of the material otherwise being present in the article at all (real pull quotes repeat material that's inline in the main body). That is, the situation is now {{em|worse}} than it was before. I'm not sayhing "this is Herostratus's fault", but "that version of the doc cannot stand"; if anything, I blame myself for not noticing it and dealing with it much sooner.</p><!--
--><p>I'm not wedded to the exact wording of my version; as I said above, some of it may really need to move into the guidelines. But we also have a strong interest in having some kind of "these are the high points" summary consistently transcluded at all these templates' doc pages, because non-encyclopedic abuse (of many different kinds) of these templates is rampant, and the people using and misusing them are far more likely to read the template documentation than the guideline section. Guidelines are mainly references for gnomes doing {{lang|la|post hoc}} cleanup, while template documentation is how-to material for even the first-time user of the template. It's like the distinction between , versus the tool documentation available under the "Help" menu in the application itself.<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:25, 3 May 2019 (UTC); rev'd. 22:34, 3 May 2019 (UTC)</p>
:Well... I have mixed feelings about a further RfC... but maybe it's a good idea, and it's certainly your prerogative to start one if you like.

:OK, well, I'm not really up on the locations of the discussions previous to and subsequent to the RfC which I had to guess is the relevant one. If I guessed wrong, oh well, but if you're not going to provide links to what you ''are'' talking about, that's what it's going to be I guess.

:Yeah and my edit summary -- "Liked it better before, reverted ]. Make you case on the talk page and gain consensus for these changes please" -- seems pretty normal to me. BRD is pretty well established, and "liked it better before" seems to be a pretty normal motive. You don't often see "This is a definite improvement, reverted per WP:BRD". If it's too sporty for your taste, oh well. Can't please everyone. Anyway, I rolled your edits to {{tl|Quote/doc/boilerplate}} back a second time, so the ball's back in your court on that.

:I don't agree with much of anything you're saying here regarding content. I just don't, and there's no way to compel me to, I guess. Some other people also don't agree with your general take on this matter, which to my mind involves characterizing editors choosing to format things differently from your personal preference as engaging in "non-encyclopedic abuse" and "misuse", who need to be re-educated (and I suppose sanctioned if that doesn't take) and their contributions re-formatted. Asking people once again with the same arguments to agree with you on this is probably not going to change that, but you can try if you like. You never know, I guess. Fresh voices might. If you keep doing it for enough years or decades, you might hit the jackpot eventually, I guess. That's not my idea of how all this is supposed to work, but whatever.

:By the way you are apparently exercised about canvassing, mentioning it here and in the other other RfC. Canvassing can be an annoying problem sometimes, but there're templates and other ways to deal with that usually work, described at ]. Another way to counter canvassing is to advertise neutrally for extra eyes in a neutral venue. That's fine. Advertise on the Village Pump. That's a neutral venue. Advertise on Jimbo's talk page. That's a neutral venue. Make it a ] discussion if you like. Or anything else reasonable. ("People not agreeing with me" is not always the result of canvassing tho, I might point out.)

:Also it's appropriate to notify everyone who was involved in the previous RfCs and other related discussion, of course (as long as we notify everyone, and in a neutral manner).

:So anywayyyyy... it seems like the next discussion (unless I've missed any where this was already decided) would be:

:#Should there be only one allowed template for (non-inline) quotes?
:#And if so, what should that be?

:And settling that would to a long way toward settling the current bone of contention in this thread, namely what should be in the documentation for the template(s).

:Anyway, it will be very difficult to have have the these discussions, because of human nature. In the first, some editors are going to want to re-litigate whether there should be ''any'' quote template, and many editors will probably be of the mind "Yes, but only if it is my preferred template X" (and even if not, a lot discussion over what template(s) is best will certainly be mixed in, and other suggestions). This will probably result in a long discussion with various side streets taken, a great deal of time and energy spent, and a difficult close since reading thru and absorbing all the discussion sorting all the "Yes, but only if X" type opinions will be difficult. But difficult is not impossible tho.

:(Or, we could have one single RfC combining both these questions... that might be better, but would even more complicated to figure out a consensus, if any, so I dunno.)

:But I mean this seems the only realistic way forward. So let's do it, shall we?

:Let's just leave the template-doc text as it is for now (there's no hurry to get this right) and move on a new RfC(s) as suggested. Unless you can think of anything else.

:(I would point out that there's a good chance there'd be no consensus... that'd require either a supermajority in favor, which is vanishingly unlikely IMO, or clear preponderance of argument in favor, which is also vanishingly unlikely IMO since this is basically a question of personal opinion and preference (even if you personally think it's not). So, my preference would be to do ''nothing'' since, probably, scores of man-hours will be eaten up, with no change, and just leave things exactly as they were. But it looks like that's not going to fly with you.)

:So, your call. Ball's in your court. If you do want to start a new RfC, please be as clear and concise as possible on what, exactly, is being discussed, and what is not being discussed, thanks. I would recommend simply that it read "Shall only one template be allowed for quote boxes? Yes or no".

:Then, if it was me, parenthesized below that, maybe stuff to the effect of "''Which'' template(s) should be allowed isn't intended to be part of this discussion; that's a separate discussion for later and let's try to stay focused on the one simple question at hand please. Also, the question of whether ''any'' quote boxes should be allowed is not in play; that's been decided, and would be separate discussion to overturn. Here are links to previous discussion relating to this matter: ". I would also add a hidden section showing the possible formats in play (again, reminding that these are just to show which ones would likely be the pool from be "the one" is chosen, if it is to be just one. In my opinion there would be four, which would be {{tl|Quote}}, {{tl|Quote box}}, probably {{tl|Cquote}} I guess, and a replacement for the current {tl|Quote} that adds a light background and (maybe) reduces the font size a bit, which you suggested at the previous RfC and which was popular there.)

:If it was me, I would add something to the effect of "Keep in mind that if the consensus is 'Yes', the format chosen might be the one you like least; we're just trying here to establish the principle whether there should be just one format, or not." Or course now we're getting kind of wordy.r

:Anyway, ball's in your court, good luck and Godspeed. ] (]) 13:31, 4 May 2019 (UTC)
::OK, first let's see if we can pull together all the previous discussions on this general subject that we can find. Let's see... in chronological order, I get:
::*''']'''. 11 July 2006. (Also in Misplaced Pages talk:Manual of Style/Archive 60# for some reason.)
::*''']'''. 14 August 2006.
::*''']'''. 6 November 2006.
::*''']'''. 8 July 2008.
::*''']'''. 18 September 2011.
::*''']. 22 October 2011.
::*''']'''. 19 February 2015.
::*''']'''. 30 July 2015.
::*''']''', which we've just been discussing here. 20 August 2016. Formal RfC closed by a closer.
::*''']'''. 15 September 2016
::*''']'''. 21 September 2016.
::*''']'''. 11 November 2016 . This was a formal RfC with a closer.
::I'm sure there's more, but thats for now... you got any more? ] (]) 02:53, 10 May 2019 (UTC)
:::There are oodles more at other pages (article talk, VPPOL, TfD, template talk, etc.) Mapping it all out would look a lot like {{section link|User:SMcCandlish/Organism names on Misplaced Pages#Capitalization of common names of species – an eight-year, site-wide dispute}}; and like {{section link|User:SMcCandlish/Organism names on Misplaced Pages#Capitalization (and disambiguation) of breeds and cultivars}}. I'm skeptical it'd really be a useful exercise, as neither of those "catalogue of the entire dispute" lists ended up being very helpful, either to the ] RfC or to ]. In both cases, the issue mostly just got hashed out on its own merits again.<p>On that matter, "Should there be only one allowed template for (non-inline) quotes?" isn't actually the question. It's about the rendering, the formatting of the quotation and what effects this has. There could be 20 slight-variant templates that visually do the same thing (i.e. one quote style) plus divergent templates doing other quotation styles; or even one and only one non-inline quotation template but with 20 radically different output options, and we'd still have exact same issues to resolve. It's not about the number of templates, but about there being divergent styles, some of which have ] and other policy problems. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 03:28, 10 May 2019 (UTC)
::::Well, one thing you are talking about is parameters for quote templates, such as the background-color option for the quotebox template, is that right? What else do you mean by "output options"? Are you also talking about the manner in which quote templates are ''employed'', that is for instance, in one article many might be sprinkled liberally all thru the text, in another an extremely long quote is templated, in another a trivial quote is displayed, in another a quote might be highlighted for POV purposes, and so forth? ] (]) 17:09, 10 May 2019 (UTC)

==Commas==
{{Quote frame|Comma police<br>Arrest this girl<br>Her comma style<br>Is making me ill<br>''Burma-Shave''<br><small>] (they/them) (]/]) 22:56, 1 May 2019 (UTC)</small>|align=right}}
] {{right|-]]}} ]]
I've come across an editor who does very little except add commas in sentences like "In 2006, so-and-so did X". Unless this is an ENGVAR thing I'm not aware of, the sentences don't need a comma (and some style guides expressly advise against using it in these cases). If it's not an ENGVAR thing, I was just wondering was there any kind of policy to stop editors making small changes like this based on their personal preference. Cheers, ] ]] 20:50, 29 April 2019 (UTC)
: I think it might be an ENGVAR issue. I (American) prefer the comma in these situations because I learned to do it and feel a pause there when I read the sentence. Many articles where the comma is missing strike me as being BrE (not necessarily written by a native speaker). I usually refrain from inserting a comma in such cases, although the temptation is always there. ] (]) 21:28, 29 April 2019 (UTC)
::It's not an ENGVAR matter, it's a formal/academic style versus ] matter. You'll find that news publishers in the US and UK regularly drop the comma after short introductory phrases, because their primary concern is squeezing text to save space, while other publishers do that much less often (less often the more formal the publication is, and few things are more formal than an encyclopedia, which is an academic book by nature even if published online as a wiki). The few style guides that literally advise {{em|against}} such commas (rather than stating that they're optional) are news style guides, with very few exceptions. ] as a matter of policy. (It's part of what keeps us reading like an encyclopedia at all instead of dismal blog with too many cooks in the kitchen.)<!--
--><p>The comma should be used on WP for several reasons: 1) it's just clearer, especially for non-native English readers; 2) it's going to be clearer regardless of the exact construction (while "In 2016, they moved to Botswana." isn't going to melt anyone's brain, many intro phrases can lead to ambiguities that require re-reading the sentence a couple of times to get the meaning); and 3) it's going to remain clearer no matter what later editors do. That last is a key point: you have no idea what that line is going to say in 5 minutes or 5 months or 5 years, and it's quite likely that it's going to change. Especially because of the ] problem, these kinds of sentences actually change even more often than they might otherwise.</p><!--
--><p>In closing, see also MoS's admonition against editwarring over optional style matters. If someone wants to clarify our prose by including commas (grammatically correct ones, I mean), then you're not doing right in reverting them or picking a fight with them in some other way. Given the crappy state of much of our mainspace text, especially in articles on more obscure topics, an editor devoted to punctuation cleanup is no kind of problem, but a desirable ] doing tedious work most others don't find appealing. If it's a new-ish editor you're singling out, see also ]. And beware the problem that objecting to someone as a control freak is usually done by someone else acting as a control freak with a difference of opinion (]); WP is the obsessives' home away from home, remember. :-)<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:05, 29 April 2019 (UTC)</p>
::::Given that I was referring to the (p12), the claim that it's "a formal/academic style versus news-style matter" doesn't seem to be true. I'll assume it's a personal preference thing then. ] ]] 10:09, 30 April 2019 (UTC)
:::::Nope. This has been discussed before multiple times, too. The "University of Oxford Style Guide" is not the ''Oxford Guide to Style'', AKA ''Oxford Style Manual'', formerly ''Hart's Rules'', and now ''New Hart's Rules'' in current editions – the work intended as a guide book for general publishing, a British equivalent of ''The Chicago Manual of Style''. The "UOSG" is an internal memo for, and only for: "writing and formatting documents written by staff on behalf of the University (or one of its constituent departments etc). It is part of the University’s branding toolkit". Like all university and corporate ] sheets, it is written by the marketing department, using the marketing register and style of English, which is derived almost entirely from ] (plus extra bombast – note the overcapitalization). It is not a reliable source for anything to do with English in a formal/academic/encyclopedic register. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 17:47, 30 April 2019 (UTC)
:::Agreed. Absolutely ''not'' an ENGVAR issue. I'm British and I prefer the comma in my own writing, although it doesn't really bother me that much either way. -- ] (]) 08:05, 30 April 2019 (UTC)
:This topic has been on this talk page before, and within the past year. You might take a look through the archives to see what the discussion settled on then. --] (]) 02:05, 30 April 2019 (UTC)
::Thanks, I found ], which largely seems to conclude that the comma is not wrong but also not necessary, and that it's effectively a ]-type issue, so the editor doing this probably shouldn't be, especially after their edits were queried. Cheers, ] ]] 10:14, 30 April 2019 (UTC)
::: More recently, ]. <span style="color:red">—](])<span style="color:red">]—</span> 12:48, 30 April 2019 (UTC)
:::RETAIN applies to ENGVAR issues exclusively. This is about ''adding'' something to the article. If an editor were going around ''removing'' these commas, then there might be an issue. ] (]) 22:57, 30 April 2019 (UTC)
::::Yep, this isn't a RETAIN matter, but a ] policy one. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:57, 4 May 2019 (UTC)
*{{tq|an editor devoted to punctuation cleanup is no kind of problem, but a desirable ]}}{{snd}}If someone has a way to detect and fix comma splices, confusion between dependent and independent clauses, and the few other things like that which are genuine ''errors'' in comma placement, fine. But going about reducing comma placement to some anodyne least common denominator is not on. ]] 10:23, 30 April 2019 (UTC)
*:<small>Least ''comma'' denominator. <span style="white-space:nowrap;">]&thinsp;<span style="display:inline-block;position:relative;transform:rotate(45deg);bottom:-.57em;">]</span></span> 16:22, 30 April 2019 (UTC)</small>
*::<small>In the Old West men were shot for less. ]] 17:10, 30 April 2019 (UTC)</small>
*:I would agree per ] and MoS's own advice about trivial style changes that inserting these optional commas without doing anything else constructive isn't particularly helpful, as it hits watchlists for something not strictly necessary. But that's true of a lot of style cleanup. Gist: integrate such changes into a more substantive copyedit or other article improvement. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 18:10, 30 April 2019 (UTC)
*::{{tq|without doing anything else constructive}}{{snd}}with or without doing anything else, a blind, systematic insertion of these commas is not "cleanup". ]] 23:51, 1 May 2019 (UTC)
*::::I'll echo Dicklyon's point below that the editor about whom this thread was opened has not been identified nor their edits examined. We have no basis on which to judge whether their activity has been in the ] vein, or incompetent. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:38, 4 May 2019 (UTC)
:I'm with you, {{u|Number 57}}, and I don't buy {{u|SMcCandlish}}'s contention that the commas concerned are necessarily correct and should be used on WP. I was a career typesetter for both British and US American book publishers, and I clearly remember that the rule was always that ''short'' introductory prepositional phrases did ''not'' take the comma. I think McCandlish may be taking the rule that introductory phrases ''generally'' take the comma and extending it – inappropriately, I think – to cases like your "In 2006". A Google search on introductory prepositional phrases confirms this. "When an introductory prepositional phrase is very short (less than four words), the comma is usually optional. But if the phrase is longer than four words, use a comma." (https://www.grammarly.com/blog/commas-after-introductory-phrases/) "Use a comma in the following cases: After a long introductory prepositional phrase or more than one introductory prepositional phrase." (https://owl.purdue.edu/owl/general_writing/punctuation/commas/commas_after_introductions.html) "A comma may also set off a single prepositional phrase at the beginning to make the sentence clear. A comma is recommended after any introductory prepositional phrase of more than four words." (http://englishplus.com/grammar/00000074.htm) "It is permissible, even commonplace, to omit a comma after most brief introductory elements — a prepositional phrase, an adverb, or a noun phrase." (https://www.dailywritingtips.com/comma-after-introductory-phrases/) "DO use a comma: After an introductory prepositional phrase of more than four words." (http://writersrelief.com/2008/06/19/how-to-use-commas-after-introductory-phrases/) "You may omit the comma following a short introductory phrase: ''On Thursday the committee decided the dispute. In 1954 the Supreme Court desegregated the public schools.''" (https://www.grammar.com/commas-and-introductory-clauses-or-phrases/) "Rule: A short prepositional phrase that is a simple modifier takes no punctuation after it." (https://www.margieholdscourt.com/514/) These are the first finds that come up for me, with none excluded... but ''all'' of the finds following – to my surprise, actually – seem to be saying the same thing. In apparently every case, the comma is required only after a ''long'' prepositional phrase, generally of four words or more. I don't see any authority requiring a comma following "In ", and I accordingly regard such revisions in WP text as unjustified. –] (]) 16:08, 30 April 2019 (UTC)
::Absolutely right. It's sad to see how many people have been taught that English is some kind of programming language with rigid rules for everything. With a handful of exceptions (e.g. as mentioned in my post a little bit up from here) most comma usage is about rhythm and pacing. Drive-by "corrections" we do not need. ]] 17:16, 30 April 2019 (UTC)
::{{ec}} Nice ]. I never said anything about "necessarily correct". What I did say is that style guides treat the comma as optional for shorter phrases, and we have good reasons to opt to include it. I've laid out some of those reasons in detail, and you've done nothing to dispel them. The fact that you can find some publishers who prefer to opt to exclude it is completely meaningless. PS: Actually, none of those are publishers in any sense we'd care about; all are random writing-related blogs, except two that are universities spelling out how students should write in class papers (one just for a specific department). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span>
:::Excuse me {{u|SMcCandlish}}, but I know what a straw man is and I believe you're the one who's presenting one here. I didn't quote you literally, though you suggest that I did. In fact, however, you did essentially say that the commas we've been considering here are necessarily correct in the Misplaced Pages context, which is what we're dealing with: "The comma should be used on WP for several reasons". That's saying it's correct, and that it's necessarily correct in this context. My saying "necessarily correct" of course didn't mean and wasn't intended to mean that you said the comma is obligatory, as anyone can understand. If you're suggesting I meant otherwise, then you're obviously twisting my meaning. Anyway, you continue to maintain that the comma is necessarily correct also now, though you express this a bit more mildly: "we have good reasons to include it." I don't actually think your reasons are very good, and if I didn't refute them before it was possibly because I had already spent so much time documenting that the comma was considered unnecessary by an apparently very wide consensus, which in itself might be taken as an adequate refutation of your undocumented assertions. But if you want to challenge me, okay, I accept the challenge so let's continue. You didn't say that style guides "treat the comma as optional for shorter phrases" (and what they say is that the comma is omittable, not that it's includable), but rather: "The few style guides that literally advise ''against'' such commas (rather than stating that they're optional) are news style guides, with very few exceptions." This is clearly quite different, with only an oblique parenthetical suggestion that a majority of style guides concur with your opinion, which in fact they don't. As for my purportedly having "done nothing to dispel" your purportedly good reasons for including commas generally considered to be unnecessary, you're right in that I didn't address some of them. I didn't have to, as I presented detailed web documentation adequately refuting your main argument that "it's a formal/academic style versus news style matter" and that since the unnecessary comma conforms to the former rather than the latter it should appear in WP. {{u|Number_57}} questioned this and I do too, and at least here you don't document it at all. (I was actually thinking of editing a into your comment, but resisted the urge.) I see you've later come in claiming that the University of Oxford Style Guide represents news style rather than academic style – a dubious assertion on the face of it. And despite your implying that the "real", "academic" Oxford style favors your viewpoint, I've now discovered the "Oxford University Press / Academic Division / Guide for authors and editors / Oxford Paperback Reference" at http://www.oxfordreference.com/fileasset/files/QuickReference_AuthorGuidelines.pdf, which states quite explicitly: "Avoid the use of a comma after an introductory adverb, adverbial phrase, or subordinate clause, unless the sentence will be hard to parse without it: In 2000 the hospital took part in a trial involving alternative therapy for babies." It's funny you should accuse me of illogical argumentation, when it's so clearly yours that's defective. Your syllogism is: Misplaced Pages should follow academic style; academic style favors the use of commas following short prepositional phrases such as "In 2006"; therefore, such commas should be used in Misplaced Pages. But your neat distinction between academic and news styles is a bit dubious in any event (particularly as many guides cover both), and even if it does actually exist it isn't at all clear that academic style actually accords with your preference. I worked for the OUP in London and was offered a job with them as a compositor in Oxford, so you can't pull rank on me at least in regard to that institution. As for news publishers, you've presented zero evidence here that they "regularly drop the comma after short introductory phrases, because their primary concern is squeezing text to save space" – nor, for that matter, that academic publishers do otherwise. You didn't document what you actually said about style guides either. I'll get back to this, but I'm dealing with your initial comment in order in order not to miss anything and be criticized on that account. 1) You say the comma is "just clearer, especially for non-native English readers", but this isn't at all obvious and I don't accept it. Whether I can conclusively dispel the notion or not, everyone's reason for authorizing omission of the comma is that it ''doesn't'' make anything clearer – otherwise it wouldn't be considered unnecessary. 2) Your arguing on the basis of "In 2016, they moved to Botswana" is poor, and I ''can'' dispel this purported reason for institutionalizing the comma. Namely, "In 2016 they moved to Botswana" itself – and this is exactly the kind of sentence we're talking about – doesn't lead to any ambiguity whatsoever, so you're effectively arguing against your own point (unless one is prepared to admit oranges as apples, of course). Moreover, while the variation with the comma may not melt anyone's brain, it ''does'' trip the reader up with an unnecessary pause, which is also somewhat inhibiting. 3) Your last, "key" point is perhaps the most unfounded of all: "you have no idea what that line is going to say in 5 minutes or 5 months or 5 years, and it's quite likely that it's going to change." So what? You could say that about just about anything. And if it ''wasn't'' actually clearer with the comma (as others and I will maintain), then it's not going to be clearer later anyway. So having now covered what I missed before, let's get back to what I didn't miss. It's true that a majority of my first seven Google finds were bloggy. This doesn't mean, however, that the authors didn't base their prescriptions on authorities and common usage as well as on their own preferences. But you say two of the finds were academic, and however you may now pooh-pooh these, this still seems very strange for someone whose basic argument is that he thinks academic usage should be preferred. You also apparently ignored my observation that all of the subsequent finds were saying the same thing – and I did quickly look through the whole page of a hundred finds. So where are yours in defense of the unnecessary comma? I hope I've now sufficiently dispelled your arguments. –] (]) 05:54, 1 May 2019 (UTC)
::::I'm already running late for something but will try to address this in detail later; digging around in style guides is going to take a few hours. One stand-out point, however, to address right now is the idea "it ''does'' trip the reader up with an unnecessary pause". We've been over this many, many times in previous comma discussions. The idea that comma = pause is a falsehood that some people pick up from incompetent grammar school teachers. Pauses in spoken speech (and thus in some readers' "inside voice" while reading) fairly often coincide with comma placement, but very frequently do not, because commas are used for myriad purposes that have no relation to diction and speech rate. If someone mentally injects a pause at every comma they encounter, they have a bad mental habit they need to work on; it's not something WP needs to "write around" for them. Also, in a construction like "In 2011, the company moved to new headquarters in Bristol" actually {{em|does}} have a slight pause at that comma in most people's speech anyway, so your premise is faulty twice over. Another good reason to include the comma is that if it just "left to editor discretion" then the random editors will do it inconsistently not just in the same article but in back-to-back material; e.g., here's one I just fixed , one among uncountable examples. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 13:42, 1 May 2019 (UTC); diff added 02:10, 2 May 2019 (UTC)
:::::What's happened here is that I dispelled all your purported comma-favoring reasons in response to your challenge, and then you ran off implying that style guides would support your position and that you would provide evidence of this. But you haven't so far, and even if you do eventually manage to come up with one or a couple of respectable sources, it's going to be clear enough that you {{strikethrough|cherry-picked them}} chose them selectively – which you can't accuse me of doing since I simply transcribed all the Google finds that initially came up on the question, two of which you even granted to be from academic institutions (though I'm still wondering what the one for the specific course was). And then, again, all the finds following those, however authoritative or nonauthoritative, seemed to say the same thing. But I've been wanting to express my embarrassment at having leaned on consensus opinion and practice in defense of my position, as the truth is that I often tend to be indifferent to this. Perhaps the main case in point is logical quotation, which I steadfastly defended and practiced on my own for decades (thinking of it as "British style") before discovering that it had another name and that – to my great delight, and apparently largely to your credit – it was now standard policy on Misplaced Pages. And I think you should be similarly embarrassed, having written in ] in the subchapter entitled "Misplaced Pages is not bound by external style guides, anyway": "Where third-party stylebooks' grammar pronouncements conflict with our goals, our decision is clear: we ignore them, and promulgate our own internal rules, with Wikipedian rationales." In other words, you don't really care about style guides. When they conflict with what you want, you will ignore them and do as you see fit anyway. You said that yourself, so you might as well be honest about it. I'm largely the same way myself, though I've generally followed normal style when working for printers and publishers. The difference between us here is that the most common opinion is actually correct and I have it on my side, while yours is wrong in various aspects and unsupported by mainstream style, news or academic, your unsubstantiated claims to the contrary notwithstanding.
:::::One of the ways in which you are wrong on this issue is illustrated by your recent assertion: "The idea that comma = pause is a falsehood that some people pick up from incompetent grammar school teachers." This is nonsense, at least insofar as it implies that a comma is not accompanied by a pause and doesn't signal one. One might charitably assume that you're making an attempt at humor, though I fear you aren't. In any event you seem to refute yourself in the same paragraph, correctly asserting that "in a construction like 'In 2011, the company moved to new headquarters in Bristol' actually does have a slight pause at that comma in most people's speech". Indeed it does – because of the comma. "In 2011 the company moved" doesn't have the pause, and that's why it's so often preferred. ''Sometimes'' the pause is desired, whether speaking or writing, and ''then'' the comma is inserted – but not otherwise.
:::::I'll do the same thing I did the last time, submit this to a search, and presumably watch you pooh-pooh the results again because they probably won't conform to your preference. Or you can say (again with no substantiation) that all the sources picked this up from incompetent teachers. But let's see what we get anyway. Again, with no cherry-picking, here are the first, let's say, ten finds I get on <does a comma indicate a pause?> (i.e. without quotes).
::::::"A style guide dictates the use of commas , which is a vast and searchable topic here (I have referenced one of hundreds of cases). https://english.stackexchange.com/questions/199471/is-using-a-comma-as-a-pause-correct
::::::"So, use them : to denote a natural pause, such as if you were reading aloud" https://www.writing-skills.com/pause-for-commas
::::::"The first, and perhaps most common, use of commas is to show a pause." https://learningenglish.voanews.com/a/everyday-grammar-commas/3789406.html
::::::"If essential, use the comma, or, if you really want to draw attention to it, use the more powerful em dash." http://writersrelief.com/2012/07/20/halt-punctuate-adramatic-pause/
::::::"MYTH: You should add a comma wherever you pause. Where you pause or breathe in a sentence does not reliably indicate where a comma belongs. Different readers pause or breathe in different places." https://writingcenter.unc.edu/tips-and-tools/commas/ (You'll want to note this one.)
::::::"A useful rule of thumb is to place commas where one makes a pause in speech." http://site.uit.no/english/punctuation/rules-for-comma-usage/
::::::"Use punctuation (comma, ellipsis, dash) to indicate a pause or break. When you use commas or dashes to signal a pause in the middle of a sentence, be sure to use the same punctuation before and after the pause." https://www.biloxischools.net/cms/lib/MS01910473/Centricity/Domain/636/RCC%20LANG%2010.pdf
::::::"In a nutshell, the two main uses of the humble comma are: • to create rhythm (by indicating a pause) • to clarify meaning (by separating elements)" https://liminalpages.com/5-comma-rules-you-can-sometimes-break/
::::::"Em dashes are used to indicate a pause or an emphasis. They often take the place of many other punctuation marks, such as colons, commas, or parentheses." https://www.topcorrect.com/blog/using-the-em-dash-for-pause-emphasis-and-clarity/
::::::"In standard English punctuation systems, there are four primary pauses. In increasing order of pause length, they are: comma, semi-colon, colon and full stop (in US English: the period). Commas are the shortest pause and it's helpful to think of them as a fraction of a halt in the flow of the text." https://teaspoon-consulting.com/articles/commas.html
:::::Again, as before, it goes on. "The comma is a punctuation mark that indicates a slight break, pause, or transition." "Commas indicate a soft stop — really any kind of pause" "Use one comma before to indicate the beginning of the pause and one at the end to indicate the end of the pause." "When a sentence is spoken aloud, a comma often represents a pause, which in verbal conversation functions to clarify meaning." "The primary punctuation used for denoting any kind of pause in dialogue or narration are the ellipsis, em dash, and comma." "Commas mark a brief pause in the sentence, usually at a point where you would naturally pause if you were speaking rather than writing." Etc. etc. etc. etc. etc. etc. etc. I'm really beating a dead horse here. Commas signal pauses. If you say otherwise you're wrong (and I say that without a comma).
:::::As in your published statement that you don't care about style guides, you reveal yourself also when you say the inclusion of commas following short introductory phrases should not be left to editor discretion. In other words, you think they should be inserted at ''your'' discretion. Well, that's okay. I think they should be deleted at mine, so I guess we're essentially the same there. And I have to congratulate you for coming up with at least something legitimate, i.e. a case of your correcting an apparent inconsistency. I deny, however, that ''every'' short introductory phrase in an article must or must not be followed by a comma. As others have properly remarked, this will depend on individual situations and circumstances, such as (to mention a main example) the presence of other commas in the sentence. If one wants, a sentence, that reads, like this one, one can get it by always willy-nilly sticking in a bunch of commas in accordance with strict rules. But it's inadvisable and yields unfortunate results. You can make up cases of imagined ambiguity or lack of clarity all you want, and you can sometimes insert an appropriate comma. Your absolute insistence and general outlook on the issue are inappropriate, however, and I think this has been adequately demonstrated. –] (]) 04:44, 3 May 2019 (UTC)
::::::::Real life takes precedence over "argue with people on the Internet" stuff, always. Just because you posted something really lengthy does not mean you have "dispelled" my arguments. Citing a bunch more unreliable ]/] blogs, and internal ] sheets, does nothing to bolster your position, because WP's MoS is not based on such works. Pre-emptively accusing me of cherry-picking is blatant ] (especially given your own relianace on weak sources you dug up via Google, and zero citations to any references that pertain to MoS's wording). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:45, 3 May 2019 (UTC); rev'd. 01:37, 4 May 2019 (UTC)
::::::: "Commas indicate a soft stop — really any kind of pause" I can not, dare not, disagree, but how about this? The comma indicates where the writer might stop, perhaps mercifully leaving a ''period'', but lifts the pen in such as a way that you realise they are going to blather on about the same thing. A new sentence can be inserted to repeat an assertion, for example, to preface the same poorly sourced notion with smug clichéd statements like "One of the ways in which you are wrong on this issue …". ] 06:58, 3 May 2019 (UTC)
::::::::I think you could say there's always a degree of smugness in someone who's confident that he's right and that someone else is wrong, and if I'm smug – which perhaps I am – {{strikethrough|I'm hardly the only one here sharing that characteristic. You seem pretty smug yourself, and McCandlish is a poster child of smugness.}} I don't think I'm any more so than other people here. This doesn't seem to have too much to do with the topic of commas, however, and if someone is objectively wrong on that subject – saying for example that academic authorities generally favor their use following short introductory phrases, or that commas don't signal pauses – then it seems to me appropriate to say that somehow, and referring to ways in which the person is wrong seems to me to be an acceptable manner of so doing whether it's clichéd and suggests smugness or not. You don't seem to have added anything here but a slur and a clever absurdity. Congratulations for that, but it doesn't say much to the issue. I don't vouch for any old source that I happen to encounter in a Google find, and I've simply presented these as I found them. None of them are authoritative in and of themselves, but together they indicate a consensus opinion which in this case seems to be quite correct. Commas do indicate pauses, and if you say or think otherwise then, at least in this common view, you're wrong too. –] (]) 15:47, 3 May 2019 (UTC)
:::::::::This kind of finger-pointing isn't constructive (and see also the menacing ] notice atop this page – I tried to get it removed last year, and ArbCom refused). Everyone who is either opinionated but full crap, or well-read on a matter and certain of what they're talking about, is going to sound "smug" to someone who disagrees with them and is looking to pick a fight, so such labeling is pointless and inflammatory just to be inflammatory. We can tell who's making sense and who is not by the arguments and evidence they present (and the reliability of those sources, and the soundness of that reasoning); whether one is fond of their evinced personality and tone isn't substantive. PS: It also seems pointless to me to be accused of smugness, but to respond by pointing a "yeah, but he's even more smug" finger at someone else. That doesn't work when you're due for a spanking at age 5, and it doesn't work when you're in court at age 30 for a misdemeanor, so it shouldn't be expected to work here either. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 01:45, 4 May 2019 (UTC)
The fact is that a comma, in this context, ''can'' serve to clarify a given sentence. It will for some readers and won't for others. That makes it an improvement to an article and any revert of it ought to be policy-compliant. ] (]) 06:22, 1 May 2019 (UTC)
:It also can, and quite often does, serve no purpose at all other than to obstruct the flow of the text in which it appears. That's why its addition is not an improvement, and why it may be dispensed with when someone has nonetheless tried to impose it. I note you're arguing solely from personal opinion, and like McCandlish present nothing to support your assertion. –] (]) 06:40, 1 May 2019 (UTC)
::That a reversion of a useful addition ought to have a policy-compliant rationale is not simply my opinion. However, the idea that an edit is an improvement if some readers benefit from it ''is'' a personal opinion of mine and one also held by the majority of editors. ] (]) 12:25, 1 May 2019 (UTC)
::::No, the benefit to some readers must be ''debited by any detriment for other readers'', then found to be positive on balance. Including parenthetical pronunciation guides, or grade-school glosses, for big all words in articles would improve things for some readers, but be a severe detriment for many more. We therefore do not do that, despite it meeting your stated criterion of "some readers benefit". ]] 17:38, 1 May 2019 (UTC)
:::And any edit that results in ambiguity for some readers or a {{em|real}} impediment to reading, like requiring people to read a passage two or three times to makes sense of it, is quite objectively not an improvement. The presence of a comma that some individual would prefer not to be there in their own writing for personal preference reasons or just because it's what they were taught, is a not an impediment to reading of any kind, and is not objectively any kind of fault in the text. While I didn't elaborate on this, I will do briefly: Even our most common short introductory phrases, "In {{var|YYYY}}" dating constructions, are naturally ambiguous in many cases. Consider "In 1999 Congressional hearings", "In 2015 investigations of the allegations", "In 2018 championship playoffs", etc., etc. Worse is that the "kill every comma I think I can get away with" people are also apt to go beyond what even their comma-averse news style guides (and unreliable-source blogs) say about commas and short intro phrases, and consider the comma after {{em|those}} phrases optional too, when they certainly are not. I fix errors like "In 2018 championship playoffs Smith beat Jones again 3–2" very frequently (two commas are missing: "In 2018 championship playoffs, Smith beat Jones again, 3–2"). Worse still, {{var|YYYY}} patterns that are not dates can coincide with Western calendar years quite often: "In 1972 reported cases", "In 1492 incidents", etc. (This is also a reason to use commas inside such numbers, another comma that some editors keep wanting to editwar to remove; don't do it – we write "1,972 cases" for a good reason.) And this is just touching on a single type of example. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 13:42, 1 May 2019 (UTC)
{{od|3}}
I wouldn't write ''In 2015 investigations of the allegations''; I'd add the comma. But I'd write ''In 2015 he returned to England''. Just because some editors don't have the skill to differentiate those cases doesn't justify crucifying everyone else on the cross of commas, and reducing all our writing to foolproof stiltedness (stiltidity?). I want to quote here (slightly adapted) something said by {{U|Herostratus}} in a similar situation; the first and fourth points don't apply 100% here, but the other three sure do:

{{tq2|1=This is certainly something that should be left up to the individual editor, for various good reasons.
*One good reason is that... there is no one clear correct or better way.
*A second good reason is that adding another needless rule bogs down the MOS with more detail and makes it harder to learn and harder to use.
*A third good reason is that creating a rule means enforcement, it puts interactions about the matter into an enforcement mode where editors are playing rules cop with other editors and this is not as functional as peer-to-peer interactions.
*A fourth good reason is that there's zero evidence that it matters to the reader.
*A fifth good reason is that micromanaging editors to this level is demoralizing and not how you attract and nurture a staff of volunteer editors{{snd}}for instance we have a stupid micromanaging rule that I have to write "in June 1940" and not "in June of 1940" which is how I naturally write, and every stupid micromanaging rule like this is just another reason to just say screw it. As the Bible says "Thou shalt not muzzle the ox that treadeth out the corn" ({{bibleref2|1TIM|5:18|AKJV|1 Timothy 5:18}}, paraphrased from {{bibleref2|DEUT|25:4|AKJV|Deuteronomy 25:4}}) which updated means "Let the editor who did the actual work of looking up the refs and writing the friggen thing -- you know, the actual ''work of the project '' -- be at least allowed the satisfaction of presenting it as she thinks best, within reasonable constraints"...
This means different articles will do it differently. This annoys a certain type of editor. Oh well...}}

And from a series of posts, also by Herostratus, in a discussion of whether someone should be described as a "former American hockey player" or an "American former hockey player":

{{tq2|1=We don't have a rule for it, so its not your job to "fix" other editors' constructions to a format that pleases you personally. It's just roiling the text for no gain. (On the merits, English is a human language, not a programming language, and everyone understands what is meant by "former American hockey player".) Since there isn't a rule, I believe that the operative procedure is:
#Do what you think best, using your wit and sense for the English language.
#And give other editors the same courtesy. Do ''not'' change other editors constructions, and do not "correct" other editors to match your personal predelictions. It just leads to pointless roiling of the text, unnecessary bad feelings, and pointless sterile edit warring.

As for ''setting'' a rule, we could do that with an RfC, but I wouldn't recommend that, for a couple of reasons. One, it would probably be a lot of work ending in no consensus. Two, give editors a little room to breathe, shall we? We don't need to micromanage every possible clause construction. The project will survive if we write this two different ways....

I believe in letting the person who (after all) did the actual writing work be given a kind of ''stare decisis'' privilege in minor matters like this.}}

More at . ]] 17:38, 1 May 2019 (UTC)
::You're missing that "In 2015 investigations of the allegations" shouldn't have a comma in it. Actually, there are cases where it could. I guess the example wasn't complete enough to get the point across (because a construction like "In 2015, investigations of the allegations were concluded." is possible), though I think it should have been clear enough given the company of the other examples it was juxtaposed with. Anyway, I was addressing forms like "In 2015 investigations of the allegations, the accused were exonerated.", where ''2015'' is a modifier of ''investigations''. Your extensive quote of previous discussion doesn't work for me. E.g., "adding another needless rule bogs down the MOS with more detail and makes it harder to learn and harder to use" is something we both know we agree on, yet opening this up to "editorial discretion" a) leads to "style fights" like this (the secondary if not primary purpose of MoS is to curtail them), and b) the idea is based on "rules" that themselves are so damned complex they would lead directly to a big pile of the ] you and Herostratus object to. I'll be quoting ''NHR'' to prove that shortly. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:45, 3 May 2019 (UTC); rev'd. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 01:37, 4 May 2019 (UTC)
:You know, if anyone ''else'' ever wrote something like "...crucifying everyone else on the cross of commas", I would eagerly await whatever barbed admonition ] would (deservedly) heap upon such a hyperbolic mess. ] (]) 22:19, 1 May 2019 (UTC)
::People think it's so glamorous being me, but really it's quite a burden -- people expect perfection. I was going for a ] vibe but it didn't work out. I meant to revise but something distracted me and I guess I just saved. ]] 23:51, 1 May 2019 (UTC)
:::It would be less of a burden if you'd archive your talk page a bit. >;-) <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 02:08, 2 May 2019 (UTC)
::::I do. Imagine if I didn't! ]] 03:10, 2 May 2019 (UTC)
:::::Sorry, I had to go to therapy for a while after imaging that. The horror. The horror. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 01:37, 4 May 2019 (UTC)
This all seems kind of theoretical/hypothetical. Why not say who it's about and notify him of the discussion? ] (]) 03:14, 2 May 2019 (UTC)
:Well, it's one of those cyclical issues we go over; I don't think it really has much to do with who edited what, it's a "have a rule to reduce recurrent strife" vs. "have no rule because we hate rules" thing. I do a sourcing dump and analysis on this every few years, and will probably continue to do so until it finally settles out. Especially if the sourcing from the other site is primary-source blogs, and house-style sheets that have no relationship to encyclopedic writing. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 07:51, 4 May 2019 (UTC)
*As I've proposed before, maybe the best solution would be to print a line of commas across the top of the page and invite the reader to mentally insert them as she sees fit. ] (]) 13:05, 2 May 2019 (UTC)
*:Darn you. I was holding that one in reserve to quote in the next round . ]] 02:07, 3 May 2019 (UTC)
::Mental insertion? Sounds like something straight out of the ''Comma Sutra''. ] (]) 18:45, 3 May 2019 (UTC)
::Well, as Neal Sedaka said:
::{{talkquote|Comma, comma, down dooby doo down down}}
::Which -- provided you understand that correctly -- pretty much settles the issue, I'd say. ] (]) 21:54, 3 May 2019 (UTC)
*Comma usage is complex, and needs a set of tutorials for editors (too complex to include all of the issues in MoS). On the whole, English-language writers use commas poorly. "In 2015 investigations of the allegations"—could be ambiguous without. Do I need to disambiguate in reverse, to rule out the meaning of "2015 investigations", as opposed to the 2014 investigations? It's nothing to do with ENGVAR or the formality of the register, or whether it's academic text. IN BRIEF: weigh up the length of the sentence, the density of commas already in the sentence, and whether absence of a comma causes ambiguity. ] ] 02:44, 4 May 2019 (UTC)
*:One thing that struck me while combing through and quoting from the manuals cited in the subsection below was that the "too many commas" fears of editors are very vague and generalized, but rather unfounded. The kind of excessive comma use (often mimicking speech pauses and simultaneously also applying a comma in every case were one could possibly be used in any structurally similar circumstance for syntactic reasons) as is found in much early-20th-c. writing, isn't found in any modern style guides, and their specific rules about comma use actually rule most of them out. Writing "In March 2002, a provice-wide referendum was held about the curfew ordinance" does not actually encourage writing things like "In Elbonia, however, the police force, which operates as a division of the military, and is subordinate to it, and to its chain of command, are well-known, internationally, for physical abuses, and questionable arrests, of citizens, and also of tourists." No one writes like that in contemporary English, other that people too incompetent at the language (probably {{em|any}} language) to work effectively on this project to begin with. Anyway, I strongly agree with "Comma usage is complex, and needs a set of tutorials for editors"; that would be a great essay, along the lines of your own writing-better-articles tutorials which are still well-regarded. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:36, 4 May 2019 (UTC)

===Examine, on this question, the style guides on which MoS is itself based===
I've made the time to get back into this, and pore over these sources in great detail. There is no point citing a bunch of corporate/organizational house style sheets or unreliable UGC/SPS blog pages about commas, as was done above. These have no bearing at all on what MoS says or should say, or how to write an encyclopedia. What does actually matter are the major style guides that MoS is almost entirely based on (like 98% of it, just not the parts that are WP-specific technical matters and such, plus a tiny handful of points we pulled from ] because they addressed it in a more timely fashion; the only example I can think of is parts of ]). They're MoS's prime sources because they're the ones that have the reputation and impact to have markedly affected real-world writing, in the ] that pertains to encyclopedic writing. So, let's look at their relevant parts in detail:

* '']'' {{small|1=(2nd ed, ], 2002, pp. 117–123; a.k.a. ''Oxford Style Manual'' in a different printing with additional material from ''Oxford Dictionary for Writers and Editors''; the pagination for this material is also pp. 117–123 in that 2003 version, the one I recommend if you don't own it yet; also republished in abridged form in 2005 as ''New Hart's Rules'' 1st ed.; I've not checked the pagination in that copy, but it will differ)}}: This is the main non-US style guide on which MoS is based, and the most influential in 21st century British and Commonwealth publishing. Probably most importantly in all the ''OGS'' material on commas is something I quoted directly in the last round of this cyclical debate a couple of years ago:
{{collapse top|left=y|width=97%}}
It's in the subsection on the ], but {{em|all}} of it also applies to commas for introductory phrases – especially on WP, where the individual writer has no control over later editorial changes that may be confusing:<br />{{tq|1=Given that comma is sometimes necessary to prevent ambiguity, it is logical to impose it uniformly, so as to obviate the need to pause and gauge each enumeration on the likelihood of its being misunderstood—especially since that likelihood is often more obvious to the reader than the writer. ... Moreover, if one uses comma consistently, its intentional absence clarifies the sense instantly}}. This was then followed by an example pertaining to serial commas and when a construction just looks similar to a situation that might use one; but we can substitute an introductory-position example easily, like: "In 2015 investigations of the allegations, the accused were exonerated.", in which "2015" is a modifier of "investigations". The more consistently on WP the comma is used in a construction like "In 2015, investigations into the matter were concluded.", the more obvious is to our readers that the example before that one is not the same kind of construction; the more people do whatever the hell they feel like with introductory commas, the harder the reader of this site has to work to figure out the meaning of {{em|both}} kinds of sentences; they may have to re-read either of them twice to be sure.
{{collapse bottom}}
:''OGS'' has no subsection specifically about "short introductory phrases" as a class (because that's not really a thing – phrase position and length has little relationship to syntactic function and composition). But it does have much to say about cases that would qualify for the description, and many illustrations of them, throughout its long section on commas:
{{collapse top|left=y|width=97%}}
{{tq|1="Use the isolating comma to separate vocative expressions from the rest of the sentence: ''My son, give me thy heart.'' ... ''The question is, Can it be done?'' ...<br />Use commas as required to isolate interjections, reflexive questions, and brief comments: ''Yes, I'll come.'' ''Oh, how delightful!'' ...<br />Adverbial material, whether clauses, phrases, or single adverbs, obeys no single rule regarding commas, though the length of the material and what it modifies in the sentence regulates where commas are placed: ''The sermon over, the congregation filed out.'' ... ''Driving as they had been all night, they were relieved to see the sunrise'' ...<br />Adverbs and adverbial phrases that comment on the whole sentence, such as ''therefore'', ''perhaps'', ''of course'', are often enclosed in commas, but this is not a fixed rule. Sense may be altered by the comma's placement or presence. Consider the following: ... ''Again she refused to speak,'' (once more) ''Again, she refused to speak,'' (in addition) ...<br />Include a comma even where the structure does not absolutely require one, if necessary for clarification, to resolve ambiguity: ''With the police pursuing, the people shouted loudly.'' ''As the car pulled up, the demonstrators crowded round.'' ''Three miles on, the road gets better.'' ''However, much as I should like to I cannot agree.'' ...<br />There is usually no need for a comma in short sentences, and in longer ones where the meaning is clear: ''He was as scared of me as I of him. He turned and ran.'' ''I boiled the kettle and then made tea.'' ''Sarah loved him and he her.''"}} Note the complete lack in the last ("short"-related) rule of any example here like "In 2015 they moved to Bristol" or "In Pakistan traditional dishes are often spicier than in India." Notably, no such examples exist in the entire subchapter on commas; it's all left up to the grammar-specific rules and advice quoted here, without any regard to whether such a construction is "short" or "introductory", or has anything to do with dates or locations. {{small|1=This is because the entire notion comes from journalism, focused on dropping anything they can to save column space, and especially concerned with the first parts of paragraphs and sentences because of the that affect their bottom line. Neither are concerns that apply to Misplaced Pages (and ] anyway).}}
{{collapse bottom}}
:Oh, and just to address further the "commas = pauses" stuff:
{{collapse top|left=y|width=97%}}
{{tq|1="Do not introduce a comma between subject and verb, or verb and object—even after a long subject, where there would be a natural pause in speech, if only for breath: ''Those who have the largest incomes and who have amassed the greatest personal savings should be taxed most.''"}}</p>
{{collapse bottom}}
* '']'' {{small|(], 3rd ed., 2009)}}. This was the edition that most influenced MoS; I don't have my copy handy, but I have the expanded, internationalized ''Garner's Modern English Usage'' (4th ed., 2016, pp. 748–750), in which I don't detect any substantive changes to the relevant material (I recognize most of this wording, having been through this exact same debate half a dozen times before):
{{collapse top|left=y|width=97%}}
{{tq|1='The "close" style of punctuation results in fairly heavy uses of commas; the "open" style results in fairly light... some writers and editors went too far in omitting commas that would aid clarity. What follows is an explanation tending slightly toward the open style but with a steady view toward enhancing clarity.}} I nominate Garner for WMF's board of directors!
{{collapse bottom}}
:Importantly, he directly agrees with ''Oxford Guide to Style'':
{{collapse top|left=y|width=97%}}
Again addressing serial commas originally, we find that the reasoning is 100% applicable to intro-phrase commas, too:<br />{{tq|1='Whether to include comma has sparked many arguments. But it's easily answered in favor of inclusion because omitting may cause ambiguities, whereas including it never will.'}} He observes that newspaper journalists typically omit such commas simply as a "space-saving" device (and the "scare quotes" around that are his).
{{collapse bottom}}
:More specifically about intro-phrase commas:
{{collapse top|left=y|width=97%}}
{{tq|1='he comma separates most introductory matter from the main clause, often to prevent misunderstanding. The introductory matter may be a word (''Moreover,''), a phrase (''In the meantime,''), or a subordinate clause (''If everything goes as planned,''). Matter that is very short may not need this comma (''On Friday we leave for Florida''), but phrases of three or more words usually do–and even shortest subordinate clauses always do (''That said,''). On the other hand, a comma may prove helpful for clarity even with shorter phrases (''For now, we must assume the worst''). It may even be imperative (''Outside, the world goes on.''.'}} That last example is key; while Garner admits that some one- or two-word constructions might not need the comma (and illustrates only informal use), he's certain that it's absolutely necessary any time confusion could result even if the grammatical structure makes only one meaning possible (it is not possible for ''Outside the world goes on'' to mean anything different from ''Outside, the world goes on'', versus a construction like ''Outside the world, a realm of spirits existing is a possibility that has fascinated humans since prehistory.'' Garner is concerned not with the syntax but with wasted reader time, having to re-parse unclear constructions.
{{collapse bottom}}
:Other notes on ''Garner's'':
{{collapse top|left=y|width=97%}}
''Garner's'', like ''Oxford'', also calls for commas in various other situations that are sometimes introductory or sometimes mid-sentence or terminal:<br />{{tq|1='he comma marks the beginning and end of a parenthetical word or phrase, an appositive, or a nonrestrictive clause.... he comma separates a participial phrase, a verbless phrase, or a vocative....'}}; he rarely does consider some of these optional, but not ones we'd care about (e.g., antiquey ]s), and notes of course that appositives of the form ''His friend Janet'' do not take commas; all style guide agree on that. Both books, along with ''Chicago'' and ''Fowler's'', also consistently address comma usage not directly related to our question ('he comma separates adjectives that each qualify a noun in the same way.... he comma separates a direct quotation from its attribution....', and so on; I'm not getting into that stuff here for any of these sources, since it's off-topic.)
{{collapse bottom}}
:If there's any doubt as to Garner's view or meaning, he's put out another and more instructional volume, ''The Chicago Guide to Grammar Usage and Punctuation'' {{small|1=(2016, pp. 347–356 – no effect on MoS but relevant for interpreting Garner)}}:
{{collapse top|left=y|width=97%}}
{{tq|1='Use a comma after a transitional word oor phrase though not ''and'', ''but'', ''for'', ''so'', or ''yet''), an introductory phrase (especially a long one), or a subordinate clause that precedes an independent clause: ''Nevertheless, the conditions behind the kitchen door were suitable for a pigsty'' (George Orwell); "Aside from that remark, all our conversion was about personalities." (Theodore H. White) ...<br />Use a comma to set off a name, word, or phrase used as a vocative: "Mother, I have nothing particular to write about" (Walt Whitman) ....<br />Use a comma before a direct question contained within another sentence: ... "e must ask, Why do people no longer suffice?" (Sherry Turkle)....'}}<br />This advice is followed by a multi-page section named "Preventing Misused Commas", a list of rules that all begin with "Don't", and each of which has multiple examples. Not a single one of them supports the view that "In 1999 the company filed for bankruptcy." should not have a comma in it.
{{collapse bottom}}
:While Garner suggests that some such commas are sometimes optional, everything he advises about the matter (and everything he just writes, using commas himself in his own prose) leans the other direction for such cases. E.g. the very first sentence in that book ("Introduction", p. 1) is "In its usual sense, grammar is the set of rules governing how words are put together in sentences to communicate ideas–or the study of these rules." Note the comma after "sense", a comma various arguers above would drop for what seem to be ] reasons.
* '']'' {{small|(15th ed., 2003)}}. This edition most influenced early and key MoS provisions {{small|1=(though the 16th ed. came out far enough back to have also had a major impact on MoS's post-2010 development, sometimes retroactively versus what was ported from the 15th)}}:
{{collapse top|left=y|width=97%}}
{{tq|1='<nowiki />'''6.25 Introductory phrase with comma''' – An adverbial or participial phrase at the beginning of a sentence is usually followed by a comma, especially if a slight pause is intended. A single word or a very short introductory phrase does not require a comma except to avoid misreading. ''After reading the note, Henrietta turned pale.'' ''On the other hand, his vices could be considered virtues.'' ''Exhausted by the morning's work, she lay down for a nap.'' ....}}<br />For examples of necessity even with short intros, it gives: {{tq|1='<nowiki />''Before eating, the members of the committee met in the assembly room.'' ''To Anthony, Blake remained an enigma.''<nowiki />'}}<br />It gives an example, too, of when the comma might be omitted: {{tq|1='<nowiki />''On Tuesday he tried to see the mayor.''<nowiki />'}}<br />So it "permits" this dropping, but states no rule requiring it. That's consistent with everything I've said: style guides we care about treat it as optional, but are concerned about clarity, which is way more of a concern on WP than in usual writing, even formal writing.
{{collapse bottom}}
:If this ''Chicago'' approach seems remarkably consistent with ''Garner's'', it's because Bryan A. Garner has written the grammar and punctation chapters of ''Chicago'' since the early 1990s (though there are a few things its managing editors won't let him put in it, such as defaulting to use of the serial comma). The rest of the comma material thus obviously agrees with the equivalent material in ''Garner's'', and it's not pertinent to our question, being mostly mid-sentence uses. The 15th ed. did touch on a few other related matters, but they're covered better by the 16th, which I quote extensively below.</p>
* ''Chicago Manual of Style'' {{small|(16th ed., 2010)}}, also highly influential on MoS, abandoned the idea of addressing "introductory phrases with a comma" as all the same thing (which is linguistically unsound because where a phrase is in a sentence has little to do with the function it serves and the elements which compose it). The 16th ed. thus expanded the relevant advice along more precise grammatical lines (in quoting them, I elide matters and examples that cannot pertain to introductory phrases of any kind, or this would be three times longer):
{{collapse top|left=y|width=97%}}
{{tq|'<nowiki />'''6.25 Commas with ''however'', ''therefore'', ''indeed'', and so forth''' – Commas ... are traditionally used to set off adverbs such as ''however'', ''therefore'', and ''indeed'' ...: ... ''Indeed, not one test subject accurately predicted the amount of soup in the bowl.'' ...'''<br />6.30 Comma preceding main clause''' – A dependent clause that precedes a main clause should be followed by a comma: ''If you accept our conditions, we shall agree to the proposal.'' ...<br />'''6.35 Commas with introductory participial phrases''' – An introductory participial phrase should be set off by a comma unless the sentence is inverted and the phrase immediately precedes the verb: ''Exhilarated by the morning’s work, she skipped lunch and headed for the ocean.'' ''Failing in their quest, the team resolved to train harder in the off-season.'' But: ''Running along behind the wagon was the archduke himself!''<br />'''6.36 Commas with introductory adverbial phrases''' – An introductory adverbial phrase is often set off by a comma but need not be unless misreading is likely. Shorter adverbial phrases are less likely to merit a comma than longer ones. ''After reading the note, Henrietta turned pale.'' ''On the other hand, his vices could be considered virtues.'' ''After 1956 such complaints about poor fidelity became far less common.'' But: ''Before eating, the members of the committee met in the assembly room.'' ''To Anthony, Blake remained an enigma.''<br />'''6.37 Commas with ''oh'' and ''ah''<nowiki />''' – A comma usually follows an exclamatory ''oh'' or ''ah'' unless it is followed by an exclamation mark or forms part of a phrase (e.g., ''oh boy'', ''ah yes''). No comma follows vocative ''oh'' or (mainly poetic and largely archaic) ''O'' ...: ''Oh, you’re right!'' ''Ah, here we are at last!'' ''Oh no! Ah yes! Oh yeah?'' ''Oh mighty king!'' ''O wild West Wind ...''<br />'''6.38 Commas with direct address''' – A comma is used to set off names or words used in direct address ...: ''Ms. Jones, please come in.'' ''James, your order is ready.'' ... ''Hello, Ms. Philips''.<br />'''6.39 ''Yes,'' ''no,'' and the like''' A comma should follow an introductory ''yes'', ''no'', ''well'', and the like, except in certain instances more likely to be encountered in informal prose or dialogue: ''Yes, it is true that 78 percent of the subjects ate 50 percent more than they reported.'' ''No, neither scenario improved the subjects' accuracy.'' ''Well then, we shall have to take a vote.'' But: ''No you will not!''.'}}
{{collapse bottom}}
:What we have here, then, is a major style guide that obviously and overwhelmingly prefers commas for "short introductory phrases" of most kinds. It doesn't mandate or even directly advise, just permit and illustrate, dropping it after a very short construction of the "In 2015 he died in Paris" variety, but only if there's no chance of it being confusing.
{{collapse top|left=y|width=97%}}
As already discussed a bit higher up this thread, and in more detail below in the examination of ''NHR'' 2nd ed., it simply isn't the case that such a construction {{em|ever}} is devoid of ambiguity potential on WP, because it can be altered willy-nilly at any time by any other editor. The 16th ed. also explicitly agrees (at 6.18) with ''Oxford'' and ''Fowler's'' (by name) and "strongly recommends" use of the serial comma "since it prevents ambiguity". As already covered twice above, this rationale applies at Misplaced Pages to intro commas as well, even if it might not in the kinds of published-in-fixed-form writing that ''Chicago'' and the others have as their subject.
{{collapse bottom}}
:''Chicago'' 16th also hoses down the idea that commas in writing have anything to do with pauses in spoken English, or that commas which are optional should be omitted even if clarity may suffer:
{{collapse top|left=y|width=97%}}
{{tq|1='<nowiki />'''6.16 Use of the comma''' – The comma, aside from its technical uses in mathematical, bibliographical, and other contexts, indicates the smallest break in sentence structure. Especially in spoken contexts, it usually denotes a slight pause. In formal prose, however, logical considerations come first. Effective use of the comma involves good judgment, with ease of reading the end in view.'}} The 16th ed. also dropped the "if a slight pause is intended" line quoted above in the 15th, since it wouldn't be compatible with this approach.
{{collapse bottom}}
* '']'' {{small|1=(], ]; rev'd. 3rd ed. (2000); pp. 161–162)}}, the British equivalent of ''Garner's'' (both are usage dictionaries rather than sectional "rulebooks" like ''Oxford'' and ''Chicago''), and as heavily used by us in formulating MoS:
{{collapse top|left=y|width=97%}}
{{tq|1="Such adverbs as ''already'' and ''soon'' when used as the first word of a sentence are usually followed by a comma. So too with ''however'' and ''moreover'' ...: ''Already, prints and poster have turned anguished, passionate paintings into mere features of the décor''; ... ''Moreover, you were late home after school''; '' Soon, some inner compulsion erupts into the pretty pictures.''<br />A comma is sometimes needed in order to avoid ambiguity: ''In the valley below, the villages look very small'' (so that ''below'' is not taken to be a preposition) ..."}}.
{{collapse bottom}}
:Agrees with Ritter, Garner, and ''Chicago'':
{{collapse top|left=y|width=97%}}
Burchfield, though much less specific, is clearly in agreement with Ritter (which is to be expected given OUP's editorial cycles and practices with regard to these two style guides – each ''Fowler's'' edition is kept in pretty close synch with the contemporary edition of ''Oxford Guide to Style''/''New Hart's Rules''. Burchfield concurs with Garner as well as Ritter that dropping the serial comma is "unwise", because it often "would render the sentence ambiguous", which also applies on WP to commas in intro phrases as a class (and applies everywhere, even in static print, to many of them anyway).<!--
--><p>All three, plus ''Chicago'' (which is really Garner again) concede the optionality of certain commas but are concerned about ambiguity; there are times this "optional" converts to "mandatory" in their view, and the unpredictability of it is a problem on WP – they cannot be boiled down into a simple syntactic rule like many comma matters can (e.g. "Plainly parenthetic clauses, phrases, or single words require commas before and after them").</p>
{{collapse bottom}}<br />

Let's look at some additional works in passing, including a recent revision of what was ''Oxford Guide to Style'' (and ''New Hart's Rules'' 1st ed., in redacted form), since people are apt to want to rely on the newer edition, despite it having almost no impact on MoS's development, and being too recent to demonstrably have affected much real-world writing (plus it having serious flaws):
* '']'' {{small|(2nd ed, ], 2014, pp. 75–76)}}, most examples elided for concision:
{{collapse top|left=y|width=97%}}
{{tq|1="When a sentence is introduced by an adverb, adverbial phrase, or subordinate clause, this is often separated from the main clause with a comma.... This is not essential, however, if the introductory clause or phrase is a short one specifying time or location.... Indeed, the comma is best avoided here so as to prevent the text from appearing cluttered.<br />Use a comma when a preposition is used as an adverb....<br />If commas are omitted, be vigilant for ambiguities: ''In 2000 deaths involving MRSA in males increased by 66 per cent.'' Prefer ''In 2000, ...'' or recast the sentence. ...<br />When an adverb such as ''however'', ''moreover'', ''therefore'', or ''already'' begins a sentence it is usually followed by a comma ... not followed by a comma when it modifies an adjective or other adverb: ''However fast Achilles runs he will never reach the tortoise.''"}} (Most any other other style guide, including ''NHR'' 1st ed., would put a comma after "runs", which just highlights how divergent ''NHR'' 2nd ed. is.)<!--
--><p>This is {{em|very partial and narrow}} support for dropping this comma in certain circumstances. As with ''Chicago''<nowiki />'s penchant for exceptionalism, it forms too complicated a system for MoS to use and expect editors to follow; people already in this discussion right now want to drop commas that ''NHR'' says not to (i.e., inject more special rules) all the while crying ]. On Misplaced Pages, Waddingham's take is a recipe for dispute. The "time or location" idea ''NHR'' uses is (aside from being arbitrary and ungrounded in any linguistic principle of any kind) directly countermanded in the same material by an instruction to reinsert the comma any time ambiguity could result. The problem with YYYY constructions is that very frequently such ambiguity exists, but will not be detected by the writer (who has a specific idea of the meaning already in their mind). And the ambiguity exists in multiple forms, not just the one ''NHR'' illustrated; cf. my "In 2015 investigations of the allegations, the accused were exonerated." example.</p><!--
--><p>Worse, the premises on which ''NHR'' "comma skepticism" is based do not really apply here. WP necessarily prizes precision and absolutely certain communication of meaning more than subjective aesthetic quibbles like whether someone might think something looks "cluttered". WP is not in a typography and design awards competition; it's an encyclopedia, for all English readers, not just for journalists or fans of Waddingham. Also touched on above, the rationales in ''NHR'' are assuming a static document that is going to be written and published just the once, not perpetually subject to random change. In our editing environment, there is no guarantee against a short phrase becoming longer, a clear passage being made accidentally ambiguous, a simple time/location-only construction changed to include additional detail. The Ritter edition, like ''Garner's'' and the Burchfield ''Fowler's'', actually pre-figured this (albeit in a different section): using a optional comma as if not optional hedges against all such problems, while also making the text objectively clearer for more readers, and less clear for precisely zero readers.</p><!--
--><p>All this material in ''NHR'' is absent from earlier versions of the work, and was inserted in the 2nd ed. revisions along with a large number of other things (some of them self-contradictory from section to section and occasionally even on the same page, due to a rushed editing job) that were ported in directly from journalism style sheets (particularly those of '']'' and '']'', judging from the specifics of the changes). They're invasions of dubious and conflicting ] ideas into what had formerly been a solid and respected academic-publishing style book, to make it more of a least-common-denominator and everyday-letter-and-memo-writing work – that is, less encyclopedic in tone. The Waddingham edition actually often fails to be a style guide at all, and just throws up it hands, declaring that for this and that there are no standards and writers should just do what they feel like. It's a dismal failure, as I outlined in my Amazon review of it (the top-rated review to this date, and the only detailed one ).</p>
{{collapse bottom}}
* The above "journos took over" problem is also evidenced in the newest edition of ''Fowler's Dictionary of Modern English Usage'' {{small|(], 2015)}}, on which MoS also is {{em|not}} based and which has had no demonstrable real-world impact yet.
{{collapse top|left=y|width=97%}}
Due to the editorial synching of ''Fowler's'' to ''Oxford Style Guide''/''New Hart's Rules'', the Butterfield edition agrees with Waddingham, and injects a bunch of news-style stuff, and a lot of hand-wringing and doubt and "just do whatever" non-advice, into what was once a clear and certain academic and general-usage style guide. I'm not going to quote Butterfield in detail, as his material on this just summarizes Waddingham's, and is arguably even more wishy-washy. He has even more of a habit than the other editor of wandering into ] and suggesting that everything is optional, with this variation and that attested (somewhere), such that the work is not much of a style guide at all in parts. It's a fine approach for the external, aloof, social-scientific study of language, but basically useless in a manual of style, which is prescriptive by nature in what it advises, even if not (in post-Victorian times) in its rationales for the advice.
{{collapse bottom}}
* As far as I can tell on quick review, ''Chicago Manual of Style'' 17th ed. {{small|(2017)}} is consistent on this stuff with the 16th, though it is too new to have had any impact on English that we'd be able to detect anyway. The only effect I can recall it having on MoS to date is being partial evidence in two style RfCs (the ] one at ] was one, and I misremember what the other, more recent one was).
* Finally, another major style guide that {{em|has}} had major impact on MoS, specifically for technical matters (especially at ] and some science-related MoS subpages), is '']'' {{small|(mostly the 7th ed., 2006; the 8th came out in 2014)}}. However, we only use it for those technical matters, and on all basic grammar and punctuation questions, it explicitly defers to ''Chicago'' (from the same publisher) anyway.

'''In summary:'''
#The external style guides that actually matter for MoS purposes are, in the plurality, strongly in favor of commas with introductory phrases of all sorts, but treat a few as optional, with warnings about ambiguity and clarity.
#Given that WP text can never be guaranteed to have that clarity and lack that ambiguity due to the project's very nature – the text you're looking at in an article could change at any second – all those warnings apply on WP all the time at every article.
#We should thus generally use the optional commas as if not optional. They are {{em|never}} incorrect in any case in which they are optional, and it is not possible for adding one in such a case to make the material {{em|less}} clear. It is only possible for the omission/removal of one to make the material less clear for one subset of editors to satisfy the subjective aesthetic preferences of another subset.
#As is readily apparent from ''NHR'' 2nd ed. and ''Chicago'' 16th ed. bending over backwards to try to squeeze in some allowances for various commas being more optional, taking that tack requires a "ballooning" of the ruleset, to distinguish the numerous cases of syntactically mandatory commas from those declared optional, and additional rules to even say when that option should be exercised. Trying to account for this in ] would be precisely the kind of ] that pisses off editors about MoS and makes its points difficult to remember and follow.
#Yet saying nothing about it and leaving it to "editorial discretion" leads to circular and recurrent disputes like this (and editwars at articles, and flaming at their talk pages). We know from over 18 years experience that WP editors generally lack discretion when it comes to style peccadillos; we wouldn't need an MoS (or ], or numerous naming conventions pages, or ], etc.) if this were not the case. In point of fact, various normally reasonable editors are quite capable of "holy war" behavior over trivial style matters. "Say nothing" doesn't work when the matter is a perennial dispute; it's just MoS not doing its job because ].
#The obvious solution to the entire set of problems is to advise that syntactic commas sometimes treated as optional (when there's supposedly "no chance of confusion") in some forms of writing should be usually actually be used in WP writing.
<span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 07:51, 4 May 2019 (UTC)
*In the past, I have strongly disagreed (and continue to disagree) with ] on several other issues involving the Misplaced Pages Manual of Style. On this one, however, I fully concur in his cogent analysis as set forth above. Also, there is another style guide that prefers commas after short phrases at the beginning of a sentence. Section 4.52 of the ''California Style Manual'', 4th edition (2000) provides that "A comma is generally used after introductory participial, adverbial, or prepositional phrases, and after introductory dependent clauses." --] (]) 20:54, 4 May 2019 (UTC)
*:There are lots of house-style manuals like ''CSM'' that do, but I've intentionally avoided them, as not what the community has based MoS on, and not likely to affect it much if at all in later development, to the extent MoS actually needs any. Mostly it just needs copyedting, like replacement of non-encyclopedic-reading examples, and compression of rambling instructions. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 01:16, 5 May 2019 (UTC)
*: I don't like stating the obvious, particularly having been criticized recently here for so doing. I nonetheless feel a compulsion to point out that the cited section of the California manual in fact does ''not'' state a preference for commas after short phrases at the beginning of a sentence. "A comma is generally used after introductory participial, adverbial, or prepositional phrases, and after introductory dependent clauses." Nobody has argued to the contrary, and I think it's indisputable; a comma is indeed generally used after introductory phrases. The sentence says nothing about ''short'' introductory phrases, however, and that's what's at discussion here.
*: I was looking the other day to see what the Harvard University Press style policy on this might be (with a ] having originated at Harvard, I notice), and while I couldn't find one (I emailed them this morning, asking), I did find the following interesting and germane rule at the : "'''Commas''' As with all punctuation, clarity is the biggest rule. If a comma does not help make clear what is being said, it should not be there. If omitting a comma could lead to confusion or misinterpretation, then use the comma." I think this is clearly excellent. If anyone else finds it worthy of incorporation in the MoS, I hope they will support it.
::–] (]) 20:10, 6 May 2019 (UTC)
:::Typical Harvard elitists, expecting ''judgment'' to be used. ]] 06:21, 7 May 2019 (UTC)
::::Let's apply some: In no case does keeping the comma in "In 2013, similar laws were enacted in Queensland and Western Australia" not help make clear what is being said, while removing it will definitely lead to confusion (even if short-lived) for some subset of editors, so there's the answer. Same one I've been providing throughout. And when a source like the ''California Style Manual'' (a court-specific one, but I guess it seems reasonably well constructed) says to use the comma and doesn't make exceptions for short intro phrases, that cannot be magically transmuted into evidence in favor of comma-dropping for short intro phrases; it's concrete proof that the source is making no such exception. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:19, 7 May 2019 (UTC)
:::::The comma in your sentence doesn't make anything clearer, {{u|SMcCandlish}}, because what's being said is already totally clear without it. That's why the comma is unnecessary. Sticking it into the sentence adds nothing but an optional pause that may or may not be desired, but in any event isn't in any way obligatory in a sentence such as this one, where it is at best only tolerable and then only if there aren't other commas in the sentence leading to an undesirable halting jerkiness if the additional comma is retained. Its absence isn't going to "definitely" lead to confusion in anyone's mind. You supposably mean – or should mean – a subset of readers rather than of editors, though you repeat "editors" in another post. The California style manual here acquires your stamp of approval now that you've been blown out of the water on your other ones, which turn out not to support you at all. The ''CSM'' may uniquely appear to perhaps concur to some degree with your highly minority viewpoint, but in fact it does explicitly allow exceptions in its use of the qualifier "generally". It simply doesn't specify them. –] (]) 03:08, 8 May 2019 (UTC)
::::::{{em|Of course}} the comma makes the sentence clearer. It's the sole reason you do not have to read to somewhere between the middle and end of the sentence (which in many cases will be much longer), and possibly have to re-read it from the beginning, to be sure this even {{em|is}} that kind of construction at all, and not one of the sort "In 2013 similar laws enacted around the world, failure to comply with the statute is a misdemeanor; only 114 jurisdictions classified the crime as a felony." While that non-date number would be better with a comma in it, we can hardly depend on it being present given the nature of this discussion, a putsch to eliminate as many commas as possible regardless of the cost to clarity. And because using commas in numbers larger than 999 isn't mandatory anyway. We've already been over, several times in this thread, why the comma is clarifying, so I'm just going to cite ] and move on. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 05:13, 8 May 2019 (UTC)
::::::: This is gibberish, and straw-man gibberish at that. No one has proposed elimination of the comma in numbers like 2,013, and you know it. Bye-bye. –] (]) 07:23, 8 May 2019 (UTC)
::::::: I've now looked at ] and ] in general. I can thank you for the confirmation that you're threatening and trying to bully me, but otherwise the citation is inappropriate. The minority viewpoint here is yours, not mine. Believing that you have a valid point does not confer upon ''you'' the right to act as though your point must be accepted by the community – which is how you've been acting. Your viewpoint hasn't been accepted, there is no consensus in favor of your view, and you cannot claim that there is. I'm perfectly happy to let the matter drop if the discussion has actually run its course (despite there being more to be said on it, particularly in regard to current encyclopedic practice), but not if you're going to be claiming a nonexistent consensus in favor of your view on the issue of commas following short introductory phrases. I've established my claim of an virtually universal existent consensus on their nonnecessity, even using your own preferred authorities, and I can establish this even more firmly if necessary – unless you succeed in getting rid of me. I hope there isn't some mechanism at work here whereby you repel those who disagree with you and then claim consensus among those who remain, but I have the unpleasant sensation that something like that may be afoot. –] (]) 14:44, 8 May 2019 (UTC)
*Way, WAY TLDR. SM, that was absolutely nuts. We've reached the point at which at least one participant has left a DS notice for another participant so please let's just all take a breather. Someone let me know when diffs have been posted demonstrating that editors are wasting time debating this (on actual articles, not here at Talk:MOS). See ]. ]] 23:14, 4 May 2019 (UTC)
**I don't believe in "TL;DR" when it comes to source analysis; more information is better than less (and better than further mongering of subjective beliefs). This information is pertinent and my sources were demanded, so the demand has been answered in as-complete-as-is-relevant detail, which much elided. It is the nature of many style matters that many sources say a large number of detailed things about them. Editors who care about this seemingly never-ending dispute (which is entirely grounded in what sources say and which ones matter for our purposes) can review as much of it as they like; those who do not care can skip it and the entire thread. No one is strapped to a chair with their eyes propped open being forced to absorb the material. The DS notice has nothing to do with the substance of the discussion; when someone makes pre-emptive claims of bad faith about what someone might post before they've posted it, in a topic area covered by DS that were imposed specifically because of bad-faith-assumptive behavior in that topic area, delivery of a DS notice by someone is effectively mandatory. I and several others have tried to undo (both in general and as applied to MoS) this ] failure on ArbCom's part, and ArbCom will have none of it. The best we've been able to do is get the wording of the notice revised to sound less like a threat; I personally take pains these days to be clear that such notices are delivered as a bureaucratic requirement not an escalation. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 00:45, 5 May 2019 (UTC)
::PS: Just for you, I've subtopically collapse-boxed most of it. :-) <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 01:08, 5 May 2019 (UTC)
:::I'm still waiting for diffs showing article editors are wasting time on this issue. ]] 04:24, 5 May 2019 (UTC)
::::{{ping|Binyamin Mintz}} , I found it. Personally, I think the commas he added after short introductory adverbial phrases are fine, and sometimes do that myself (and I agree with SMcC that these "optional" commas should be encouraged for the reasons he enumerates). I'm more annoyed by Mintz's edits like removing the Oxford comma. Generally, I'd rather not see a comma-opinionated editor running open loop without some discussion. So I pinged him here. ] (]) 05:07, 5 May 2019 (UTC)
::::: Yeah, the serial comma should be retained for the same reason the intro-phrase comma should be (see quotes about it from major style guides in the section of such material I posted). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:19, 7 May 2019 (UTC)
::::::{{u|SMcCandlish}}'s sentence is ambiguous and needs clarification. The "it" refers not to the intro-phrase comma but rather to the serial comma. McCandlish conflates the two and has no support for his insistent contention that the most reliable and pertinent authorities support his view on the intro-phrase comma, the evidence being to the contrary. –] (]) 03:22, 8 May 2019 (UTC)
::::::: You're having (or faking) reading comprehension problems, both as to that sentence and as to what I've said about the serial comma material. Below, I appreciated your measured approach on May 7, but it has completely disappeared. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 17:27, 12 May 2019 (UTC)
I defend {{u|SMcCandlish}}'s having further written at length on the current comma issue, and I thank him for so doing. I have read his addition through with care, and I found it interesting, illuminating, and useful for the purpose of this discussion. I acknowledge that there are problems with its length. For one thing, people may not read it (as Eeng hasn't), and that's regrettable. I can recommend that everyone have a good look at it, but my recommendation may not count for much or suffice as a motivation. Also, I'll have to wade through it all again (no small task), and then have the problem of trying to formulate an adequate response that is sufficiently far shorter than his original exposition.<br />
I don't think the issue should be simply dropped at this point, though I'll grant that the recent discussion has had an unfortunate aspect or two. Since my talk page was published with mention of the DS notice placed on it, I'm entitled to comment on that. Briefly, I don't think for a minute that the notice was mandatory, SM's assertions notwithstanding. There are various negative terms by which I could characterize his placing it, but I'll refrain from using them here. I will say, at least, that aside from its being unnecessary (''etc.''), I found it uncivil per ]: "''Be careful with user warning templates'' . Be careful about issuing templated messages to editors you're currently involved in a dispute with, and exercise caution when using templated messages for newcomers (see ]). Consider using a personal message instead of, or in addition to, the templated message." I think this is fairly clear a case where a simple message, if anything, would have sufficed. There was no pattern of misbehavior on my part, his complaint being that I on a single occasion imputed bad faith to him in saying that I expected he would cherry-pick his sources. I regret using the term "cherry-picked" and I apologize for that, though I don't consider it an insult. I don't suppose he could or would have complained if I'd said I thought he would "selectively choose" his sources, as I should have if I was necessarily going to say something to this effect; but I wasn't aware that "cherry-picking" was such a loaded term. I've applied it to myself on various occasions, I'm sure everybody cherry-picks in one way or another, and it seems to me like a fairly normal thing to say. It's untrue that I was imputing bad faith by using the term, as the truth is quite to the contrary: I think SM is acting in exceptionally good faith, which is why I've taken him so seriously. There's of course more that could be said about all of this (that such notices are essentially threatening however they're worded, ''etc.''), but I promised to be brief. I'll just close by observing that SM apparently didn't cherry-pick at all in his extended posting. I suppose that's part of what made it so long... and illuminating. –] (]) 06:48, 7 May 2019 (UTC)
:::::I appreciate the measured response. This thread doesn't have the character of an RfC; it's an open-ended discussion and this is the kind of thread in which I tend to do a source analysis for that reason. This is material that might be referred to, in summary form, in a later, more circumspect discussion. It's a practice that's worked well, and in the long run actually reduces verbiage, because you can just do something like "Not according to ''Chicago''; see quoted material here" with a link to the longer source material (including with an added anchor directly to that part of it), instead of regurgitating the entire pile of material again at the new page. E.g., I used this technique to very good effect in the VPPOL RfC on breed capitalization by building an entire page of evidence and arguments collected from one side, and those from the other, plus links to every relevant prior thread, and then I just pointed RfC respondents to it as the backgrounder. If you object to ArbCom expecting that the DS notices like that one be delivered, please take that up at ] or ] (really – they won't change or just get rid of this bureaucracy, with its tendency to increase rather than decrease tension, if more people don't complain about it). The issue wasn't the phrase ''cherry-picking'' being "insulting", or we couldn't the have "]". It was that predicting pre-emptively that someone is going to do it is an assumption of bad faith. The point of the DS notice ArbCom made up wasn't that you're a baaad person who needs to get a "threat-tag", but rather that because any admin is empowered to apply discretionary sanctions in any DS topic area for something like that, anyone who crosses or gets near such a line (or even posts a lot in the topic area without getting near the line yet) should be {{em|aware}} of the DS. ArbCom's mantra about these things is they are not user-warnings for behavior and they do not imply wrongdoing, just are notices that one is in a danger zone. Myself, I want MoS to stop being classified as one. I leave more DS notices than the average MoS regular because they actually work in curtailing the boundary pushing. It's important because the more often editors do that here, without it being curtailed (and it was really bad several years ago), the more convinced ArbCom and the AE admins are that MoS is some "controversy hotspot" that they have to patrol and at which they have to whack people with sanctions. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 07:34, 7 May 2019 (UTC)
::::::{{ping|SMcCandlish}}You begin your tract by dismissing the common consensus on the issue of commas and short introductory phrases revealed by Google on the Internet. It was not and is not a matter of "citing a bunch of corporate/organizational house style sheets or unreliable UGC/SPS blog pages". It's just what comes up, virtually everywhere, from complete garbage sites (if such they actually are) on up. I was put on notice for saying essentially that you would presumably be selectively choosing your sources, but actually you had already done that and continue to do so now (though not in a dishonest manner). Not only do you openly dismiss everything that comes up on Google: you'll even pick up points from generally inappropriate (according to you) news style if, again according to you, it suits Misplaced Pages's and your purposes. But this isn't to say that respectable sources aren't respectable, so indeed, let's do look at their relevant parts in detail.<br />
::::::The first such source considered is the ]. We hear about editions and paginations of this authority, but... "OGS has no subsection specifically about "short introductory phrases" as a class". In other words, you've come up with nothing here, whatever you may say about syntactic function and composition. "It's in the subsection on the serial comma," but a series is not a short introductory phrase. If someone finds cogency in argumentation based on the assertion that something is something different than what it actually is – well, that surprises me, actually. I don't. I quite like what ''OGS'' says about the serial comma – "it is logical to impose it uniformly, so as to obviate the need to pause and gauge each enumeration on the likelihood of its being misunderstood" – and there is even more justification for an obligatory serial comma than that succinctly given here (though I've lightened up on this in recent years, as have others also). But it doesn't necessarily ''all'' apply to... I was going to say short introductory phrases, but I now notice you're talking about the general case as {{u|Coolcaesar}} was previously, and it's already been granted that commas are generally okay in the general case. The point, yet again, is that short phrases constitute an exception – or, if you prefer, very often constitute an exception – and this is... I almost dare to say universally acknowledged, as I still haven't seen anything to the contrary, i.e. dictating the comma following short introductory phrases. It isn't here, at least, or in anything previous in this discussion. What you're again throwing around here, cited from a previous discussion, is your small collection of hypothetical cases: future editings and "In 2015 investigations". I don't remember that you've even made up an example of the former, but in any event it's not actually a real-life concern.<br />
::::::I now join EEng's protest of your excessive lengthiness in that you cited much of the rest of ''OGS'''s section on commas, despite none of its having to do with the specific type of phrase under discussion. You seem to be either forgetting or ignoring that I, on the other hand, did come up with something Oxford has to say on the specific matter, officially and academically: "And despite your implying that the 'real', 'academic' Oxford style favors your viewpoint, I've now discovered the 'Oxford University Press / Academic Division / Guide for authors and editors / Oxford Paperback Reference' at http://www.oxfordreference.com/fileasset/files/QuickReference_AuthorGuidelines.pdf, which states quite explicitly: 'Avoid the use of a comma after an introductory adverb, adverbial phrase, or subordinate clause, unless the sentence will be hard to parse without it: In 2000 the hospital took part in a trial involving alternative therapy for babies.'" So what's happened here is that not only have you not provided any substantiation for your claim that academic authority demands the comma, but I have concretely established the opposite in at least one Oxford authority. So much for ''OGS''.<br />
::::::<br />
::::::Your second authority is Garner, whom you claim to have on your side ("I nominate Garner for WMF's board of directors!") but he isn't. He's "tending slightly toward the open style", not the close one, and again, a series is not an introductory phrase (I won't lengthen this by commenting on the differences, which are clear enough), and the same logic doesn't necessarily apply. Our eyebrows rise when we read further and see: "Matter that is very short may not need this comma (On Friday we leave for Florida), but phrases of three or more words usually do". In other words, pretty much exactly what everyone else other than you says, except sometimes it's four or five words rather than three – and even then he says "usually". Again, no one's arguing that a comma isn't needed when it's in fact needed, or that it isn't perfectly fine in your cited sentence, "In its usual sense, grammar is the set of rules " – though you're incorrectly implying we would drop it. So anyway, we now have your first two esteemed authorities favoring our side, not yours.<br />
::::::So we finally get to the ], my primary authority when I had my typesetting business for Boston and New York book publishers – so I'm familiar with it, thanks. And lo and behold: "An adverbial or participial phrase at the beginning of a sentence is ''usually'' followed by a comma, especially if a slight pause is intended. A single word or a very short introductory phrase does not require a comma except to avoid misreading."<br />
::::::Uh, what's that again? A single word or a very short introductory phrase doesn't require a comma except to avoid misreading? Isn't that, er...?<br />
::::::Come to think of it, this is quite probably where I picked up the notion that a short introductory phrase doesn't need a comma in the first place, since I didn't have any other authority than a book called ''Words Into Type''. I didn't need one, since everybody was going with Chicago. At any rate I think we can stop right there. I'll re-read through the rest of it but will try to refrain from further comment as much as necessary, as we've really reached an end here. You'd like to make the comma obligatory, but you'll never have the required consensus. I was afraid you might, since it seems to have been largely you who succeeded in implementing logical quotation, and that's why I've gotten involved in this to the extent that I have. But now it seems I don't have to worry about it, at least that much. Since basically you yourself have now (re-)established that the comma isn't required, you can't defend sticking it into articles either, or correctly assert that those who in certain cases omit it are editwarring, while those who insistently place it are doing so properly and grammatically and have the right of way, so to speak. As a matter of fact I will leave it at that at least for the moment, finally commenting just on one thing you have since added, that you "leave more DS notices than the average MoS regular because they actually work in curtailing the boundary pushing". This confirms my initial impression and justifies my reaction, which was possibly too measured. I think that in any case it's amazingly on the one hand to say you don't like and oppose the notice, but on the other hand be the only one who finds it appropriate or necessary and applies it, implying furthermore that some ''other'' person, an administrator, would come in here and single me out for sanctions. I just want to say that this hasn't influenced what I've written above or may write in the future. You're not going to bully or manipulate me, though I suppose you can continue to issue threats etc. ("see also the menacing WP:AC/DS notice atop this page") if you so deem fit. –] (]) 19:05, 7 May 2019 (UTC)
:::::::I don't have time to cover every point of this right now (and much of it's handwaving or rehash of material we've already covered, like the fact that Oxford's in-house "marketing about the university" stylesheet is irrelevant to encyclopedia writing and has no connection to Oxford U. Press style). Random stuff "revealed by Google on the Internet" isn't a "consensus" that WP cares about or ever will. We take sources on a case-by-case as to their contextual reliability; what you dug up generally isn't a reliable source at all (SPS/UGC), or isn't relevant to writing an encyclopedia (news style, marketing style), and hasn't been relevant to what our MoS says, or we would have drawn on those sources already. You seem to be crowing that you've found a smoking gun, but you have not: "A single word or a very short introductory phrase doesn't require a comma except to avoid misreading?" Been over this half a dozen times already: Any sentence like "In 2013, similar laws were enacted in Queensland and Western Australia" is going to be misread by some editors if you drop the comma, and we have no idea what form that sentence will have shifted to in a month or a year; meanwhile, it is not actually possible for adding the comma to lead to misreading, and doing so future-proofs the sentence a bit should it get expanded in ways that the original writer of it didn't anticipate. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:19, 7 May 2019 (UTC)
:::::::: If you don't have time to ''re''-cover every point of this (you already covered them before at length, and were refuted), I'm sure that's quite all right with everyone concerned. It certainly would be with me, as I'm getting a bit tired of hearing you continue to repeat the same inadequate and unconvincing arguments, and of having you vainly blow away everything I say. You still haven't understood, for example, that you've been totally debunked regarding Oxford, on which your pooh-poohing dismissal of my source is completely off-target. The document concerned is in fact a publication of the Oxford University Press itself, not simply of some branch of the university. It certainly does have a most intimate connection to OUP style, having been prepared "to help you to deliver the text of your work to Oxford University Press in a form that will ensure its smooth passage through the publication process." And for at least the third and hopefully last time, the Google searches merely established a consensus; no authority was claimed for the individual websites. If I similarly searched on "the shortest distance between two points is a straight line", you could pooh-pooh the consensus on that too, on the same grounds. If you in fact had any preferable authorities backing your comma view (I honestly expected you to have a few), then it might be different, but you don't. In fact I discovered several smoking guns, as you put it. Give it up. –] (]) 04:06, 8 May 2019 (UTC)
:::::::::: Let's take a vote: Who else here can't tell the difference between the style guides, written by language authorities like managing editors of the OED, etc., that Oxford University Press publishes for general usage and (in summary form for the journals it publishes), on the one hand; and one the other, the in-house stylesheet, written by marketing functionaries, for how Oxford U. employees should write about Oxford U.? Since you're not interested in further responses to the rest of your stufuf, I'll skip making any, especially since you recycling the same stuff over and over again, about sources already pointed out to be non-reliable or off-topic, while accusing me of recycling when I actually posted a new and detailed analysis of the sources from which almost all of MoS is built, is clearly not going to lead to a productive continued discussion. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 05:00, 8 May 2019 (UTC)
::::::::::: Are you blind?
::::::::::: http://www.oxfordreference.com/fileasset/files/QuickReference_AuthorGuidelines.pdf
::::::::::: "TO HELP YOU TO DELIVER THE TEXT OF YOUR WORK TO OXFORD UNIVERSITY PRESS IN A FORM THAT WILL ENSURE ITS SMOOTH PASSAGE THROUGH THE PUBLICATION PROCESS."
::::::::::: I don't know which Oxford publication you keep referring to, but it isn't the one I found and presented, which is OUP and has nothing to do with whatever you're talking about.
::::::::::: We know, in any event, what your idea of a productive continued discussion is: one that leads to your desired consensus that "We should generally use the optional commas as if not optional." I suppose it's imaginable that you ''might'' reach, or somehow be able to claim, such a consensus through bluffing with hollow arguments, nonexistent documentation and fictitious examples; but I doubt it. This is regrettable, as in fact I agree with you on the merit of having a workable policy. (" saying nothing about it and leaving it to 'editorial discretion' leads to circular and recurrent disputes like this (and editwars at articles, and flaming at their talk pages). 'Say nothing' doesn't work when the matter is a perennial dispute; it's just MoS not doing its job because it's hard.") But you've taken the wrong side, and in fact you seem to be blocking consensus by insisting on a minority viewpoint that will presumably remain a minority viewpoint. You don't seem to be able to realize what you've done. You claimed to have authoritative support for your position, but it turned out you didn't. This changes the game. The editors involved in this can now seek a working consensus, but around a normal contemporary norm rather than your idiosyncratic and rather discredited one. I'm not, by the way, the one who's "recycling the same stuff over and over again". That's you – though with the addition of your recent documentation showing that your authorities don't agree with you. If you want new from me, you'll get new from me; in fact I've found some stuff at britannica.com that I may be posting soon, and that's not all. We could also just drop it, as EEng suggests, and we're indeed not going to get anywhere as long as you're unwilling to compromise and actually attain a solution, but rather keep trying to shove your unconventional and unwanted commas down people's throats. If you have anything new to say that you think is useful and can find the time to say it, then okay, go ahead. But try to have a little more respect for differing viewpoints, and please don't keep repeating your same ineffectual arguments and false (or let's politely say dubious) assertions. –] (]) 07:03, 8 May 2019 (UTC)

It has been maintained that I cited an inappropriate Oxford source, the , though I did not. In fact this purportedly inappropriate style guide is actually excellent and multipurpose, as anyone examining it can see. But I cited a completely different OUP publication, the OUP Academic Division's , though this has yet be acknowledged. While looking further into OUP style tonight, I found its relevant comma policy in the 2014 ''New Hart's Rules'' – the top OUP authority itself, this time incontestably – at https://www.amazon.com/New-Harts-Rules-Oxford-Style/dp/0199570027/ref=sr_1_2?keywords=new+oxford+style+manual&qid=1557636758&s=books&sr=1-2. Fortunately the page concerned is in the "look inside" excerpt and anyone can see it there (p.{{thinsp}}75).<br />
:{{tq|4.3.3&emsp;'''After an introductory clause or adverb'''}}<br />
:{{tq|When a sentence is introduced by an adverb, adverbial phrase, or subordinate clause, this is often separated from the main clause with a comma:}}<br />
::{{tq|Despite being married with five children, he revelled in his reputation as a rake}}<br />
::{{tq|Surprisingly, Richard liked the idea}}<br />
:{{tq|This is not essential, however, if the introductory clause or phrase is a short one specifying time or location:}}<br />
::{{tq|In 2000 the hospital took part in a trial involving alternative therapy for babies}}<br />
::{{tq|Before his retirement he had been a mathematician and inventor}}<br />
:{{tq|Indeed, the comma is best avoided here so as to prevent the text from appearing cluttered.}}<br />
When I searched on a portion of this text in order not to have to type it over again, I discovered that it was exactly the same in the earlier edition of ''Hart's Rules'', except for a final sentence that was omitted in the later 2014 edition:<br />
:{{tq| the text from appearing cluttered. Whichever style is adopted should be implemented consistently throughout.}}<br />
This deletion may be interpreted as either a relaxation of the the requirement for consistency, or a change from recommendation to proscription. Perhaps it was both. In any event I intend to pick up where I left off in the middle of {{u|SMcCandlish}}'s treatise and finish my comments on that, probably before commencing the new thread I recently mentioned. I suspect its author may reply to my comments despite his claiming to have abandoned the discussion – which is his prerogative, though if he then wanted to remain in it I would expect him first to reply to the two matters still outstanding. –] (]) 06:42, 12 May 2019 (UTC)
::Already addressed this ; you're just proving my point for me, trying to rely on an internal memo of a publisher as if it is one of their public-facing works. It isn't. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 17:27, 12 May 2019 (UTC)

=== Relevant policy of ''Encyclopædia Britannica'' ===

An exposition of the relevant ''Encyclopædia Britannica'' comma policy is germane to this discussion. When I first went to ] the other day, I searched on "In 1776" and came up with the following: "The navy, taking its direction from the naval and marine committees of the Congress, was only occasionally effective. In 1776 it had 27 ships against Britain's 270 ...". I didn't know where to proceed from there, as it would take forever to search every year in modern history and I had no criterion on which to make a selection. It occurred to me, however, that I could limit a search to 2000-2019 only, which would cut the sample down, be doable relatively quickly, and ensure that what was found would not be from legacy entries of earlier editions, which might imaginably be punctuated in an outdated style and thus open to criticism and/or rejection on that account. So I started searching on "In 2000". The finds came up ten at a time, which made it awkward to copy them to a text file; so I stopped at 100 and decided to copy only the first 10 finds for each of the years following. A complete listing of the finds thus generated appears below. Thanks to {{u|SMcCandlish}} for demonstrating how to collapse lengthy text.
{{collapse top|left=y|width=97%}}
{{tq|1=In 2000 more than 600 indigenous bands or tribes were officially recognized by <br />Aboriginal flag. In 2000 she also won several Grand Prix titles ...<br />In 2000 the media were full of references to Globalization of the economy, <br />Colombia - Colombia in the 21st century: In 2000 the U.S. Congress approved a <br />again and was elected in 1995. In 2000 Fox ran for president on a platform that ...<br />fragments during the 1980s and '90s, but in 2000 this modest game show ...<br />…21st century, and in 2000 Ricardo Lagos of the CPD was elected the country's <br />first socialist president… Bachelet, Michelle. Michelle Bachelet. In 2000 Ricardo ...<br />In 2000 the Democratic Party joined with the New National Party and the Federal <br />from a party other than that controlling the national government, and in 2000 most<br />Also in 2000, in a move spearheaded by Libyan leader Colonel Muammar al-<br />In 2000 a Swiss foundation launched a campaign to determine the New Seven <br />election: On this day in 2000, the U.S. Supreme Court effectively awarded the ...<br />... to end the 1994 Rwandan genocide. In 2000 he became president of Rwanda. <br />In 2000 she was nominated as the SDP candidate for president. After topping the <br />In 2000 the BJD, in alliance with the BJP, won a large majority of seats in <br />In 1999 Forbes announced his candidacy for the nomination in 2000. Although <br />In 2000 von Trier released Dancer in the Dark, a melodrama that features <br />In 2000 the National Assembly rejected a constitutional amendment that would <br />In 2000 the PAN's candidate Vicente Fox won the presidential elections, ending <br />In 2000 he worked on the presidential campaign of his brother, George W. Bush, <br />In 2000 Leibovitz was among the first group of Americans to be designated a <br />As a result, in 2000 the PRI's presidential candidate was defeated by Vicente Fox <br />In 2000 Bondevik stepped down from the premiership after failing to win support <br />In 2000 George W. Bush's narrow 271–266 electoral college victory over Al Gore, <br />In 2000 iceberg B-15 broke off the Ross Ice Shelf with an initial length of 295 km (<br />In 2000 the Chicago Housing Authority (CHA) began demolishing Cabrini-Green <br />In 2000 George W. Bush's narrow 271–266 electoral college victory over Al Gore, <br />In 2000 the Chicago Housing Authority (CHA) began demolishing Cabrini-Green <br />In 2000 the Netherlands became the first country to legalize same-sex marriages; <br />In 1992 the Catholic Church finally admitted its error at the Inquisition, and in 2000<br />Pope John Paul II gave a formal apology for the trial of Galileo and other <br />In 2001, 19 militants associated with al-Qaeda staged the September 11 attacks <br />In 2003 Eberhard and Tarpenning teamed up again to launch Tesla Motors, a <br />In 2005 some 45 billion Text messages were expected to be sent by cellular <br />In 2005 Harvey and Bob left Miramax Films to form the Weinstein Company. The <br />In 2006 the Winter Games returned to Italy after a 50-year absence. Unlike the <br />In 2006 the Rwandan government implemented a significant administrative <br />In 2007, however, she admitted to using banned substances and subsequently <br />In 2008 the world economy faced its most dangerous Crisis since the Great<br />In 2008 the Olympic Games were held in China for the first time.<br />In 2012 London became the first city to host the modern Games three times, <br />In 2013 the Bolshoi Ballet was the subject of a worldwide media scandal that <br />Media). However, in 2014 the company's publishing division was spun off, and <br />In 2014 economic inequality was the central theme of many Economic and <br />Ukraine crisis: In 2014 Ukraine faced the greatest threat to its national security <br />The FIFA Corruption Scandal: In 2016 FIFA, the international governing body of <br />The 400th Anniversaries of Shakespeare and Cervantes: In 2016 the world took <br />The Meyerowitz Stories (New and Selected): Dustin Hoffman: In 2017 he starred <br />Logan: Hugh Jackman: In 2017 Jackman starred in Logan, the 10th film in which <br />yards, the Patriots were upset by the Eagles. In 2018 Brady passed for 4,355 <br />Backstabbing for Beginners: Ben Kingsley: In 2018 he starred in Backstabbing for <br />In 2019 he launched the Brexit Party. Farage was born into a prosperous family—<br />In 2019 the academy's website showed that the Board of Governors' president <br />Mary Ventura and the Ninth Kingdom: Sylvia Plath: In 2019 the story Mary <br />candid notes to her psychiatrist—appeared the following year. In 2019 the story…}}<br />
{{collapse bottom}}
These are 55 cases, in which post-intro commas appear only in the following four:<br />
{{tq|1=Also in 2000, in a move spearheaded by Libyan leader Colonel Muammar al-<br />
election: On this day in 2000, the U.S. Supreme Court effectively awarded the ...<br />
In 2001, 19 militants associated with al-Qaeda staged the September 11 attacks <br />
In 2007, however, she admitted to using banned substances and subsequently}} <br />
In the first of these cases, the comma is setting off an appositional phrase. In the second, the introductory phrase consists of five words. In the third, the comma separates figures. In the fourth, the comma sets off "however". This listing establishes that the ''Britannica'', a historically eminent English-language encyclopedic authority, consistently dispenses with commas following short introductory prepositional phrases of the form "In ". –] (]) 23:41, 8 May 2019 (UTC)
:There isn't any question, in anyone's mind, that some publishers prefer to drop this and other commas. We have reasons to not do so, already covered in detail above, the most obvious of which is that our text changes randomly, second by second, so we can never expect that a phrase will not be made longer, will not change to juxtapose numbers, will not be rewritten to be appositional, will not get an injection like "however", etc., etc. Because of some individual editors' hostility to commas, and some other editors' lack of writing experience, we cannot expect, however, that the commas that would become semantically mandatory in such situations would be included in the course of such edits (all our articles with missing necessary commas prove this), ergo we should include the optional ones as if non-option to "future-proof" the material and to make it clearer for more editors in its original form. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 00:39, 9 May 2019 (UTC)
::We read this now, but the opening comment of {{u|SMcCandlish}} in this discussion was the following: "It's not an ENGVAR matter, it's a formal/academic style versus news style matter. You'll find that news publishers in the US and UK regularly drop the comma after short introductory phrases, while other publishers do that much less often (less often the more formal the publication is, and few things are more formal than an encyclopedia, which is an academic book by nature even if published online as a wiki). WP is not written in news style as a matter of policy. (It's part of what keeps us reading like an encyclopedia at all instead of dismal blog with too many cooks in the kitchen.)" In other words, he was arguing that academic/encyclopedic style favors commas in sentences like "In 2006, so-and-so did X", {{u|Number 57}}'s original example, and that since Misplaced Pages should be written in academic/encyclopedic rather than news style, it too – like the encyclopedias, like the academic books – should favor the commas in such sentences. We note that McCandlish makes no suggestion that Britannica constitutes any sort of exception. It will not surprise him that other authoritative academic/encyclopedic publishers have published and continue to publish their texts without commas in such sentences, and he will always have this now-modified argument there at his side: ''some'' publishers may not be following what he previously characterized as normal academic/encyclopedic style (actually it may turn out to be closer to "all" than to "some", since publishers – unlike McCandlish – generally respect common norms rather than putting themselves above them), but "we're" not going to do that because... and then we get back into his again-repeated refrain, that some texts may change in the future in some way that may imaginably affect the readability of some articles in relation to the nonpresence of the introductory comma. I'm not sure this is even a specious argument. To be specious it would have to be at least superficially plausible, and I'm not sure this one qualifies in that regard. In any event I've already contested it and won't do so again on this occasion, particularly not wanting to repeat myself as he has largely done here (though now apparently having to change his tune regarding actual academic/encyclopedic practice). I remember a university course in which my professor talked about a situation where two people are standing in front of a white wall and one of them obstinately refuses to acknowledge that the wall is white. It doesn't matter how white the wall is or what the other person says, he still can't or won't see that the wall is white. It would appear to be futile to continue to argue with such a person in such a situation, particularly when – as someone advised me lately in regard to the current discussion – nobody else cares. With no one else indeed appearing to care (?), I won't say anything else now. But because ''I'' care – even if I've given up on McCandlish's ever moving an inch – I will continue to look into actual contemporary academic/encyclopedic practice. Such practice doesn't matter to McCandlish (whatever he claimed at first), but it should matter to Misplaced Pages. I may also take a closer look at some of the Britannica examples. –] (]) 05:24, 9 May 2019 (UTC)
::: I'm not sure if this is necessarily a pressing issue or should even be addressed in the MOS, although I would probably support SMcCandlish's position considering some of the analyses (and my personal preference of adding commas in such situations; I haven't read all of the discussion, though, so I don't know if my mind would be changed by the comments that I haven't read). I've noticed, however, that in some articles there are commas where there don't need to be any, as well as no commas where there should be commas <small>(e.g. something like " the main line continued west crossing Newland Avenue, and the NER's Hull to Cottingham Line before reaching " in ])</small>. I'm actually not sure if ] addresses this. ] (]) 14:08, 9 May 2019 (UTC)
:::{{ec}} Moving on to some meta-commentary about the entire thread and question: My operating assumption from the start is that MoS is not going to change position on this matter, to mandate either inclusion or exclusion of these commas, and I still predict that result, whether the discussion stops here or quadruples in length. None of the sources are against this comma universally, nor can any of them surmount the rationales for inclusion in this particular context; the very clarity/confusion exceptions they rely on apply more broadly here than in a newspaper or book or journal. They were not written to deal with text that is constantly and unpredictably changing. We have our own style guide for real reasons (and we do not add everything we can think of to it, since keeping it short and limited mostly to otherwise-intractable disputes is one of those reasons). My purpose in this has been to provide a logic- not preferences-based view of how to defuse sporadic conflict over this point {{em|without}} writing a new rule. My WP writing style uses more commas than I do otherwise; I regularly drop introductory and serial commas in informal contexts. Much of the genesis of pointless, cyclical MoS-related disputes is people having difficulty separating "How WP should be written" from "How I write memos at work", as if they are only capable of using one ] of English. We know they are not, and they need to stop campaigning. WP is not ] (nor is MoS, nor a particular article here) simply because it doesn't match one's personal habits.<p>{{em|WP content simply may be less or more clear for fewer or more readers, and we should always optimize for more+more not less+fewer in that analysis}}, especially if the cost is just a few additional punctuation marks that no sources at all consider to be actual errors.</p><p>I decline to respond to most of the above rehash and unnecessary personalization other than to observe again that the style guides that matter most for MoS purposes treat such commas as optional, advise including them if they improve clarity or can prevent misreading (which is effectively always the case at this site due to its nature and audience), and offer remarkably logical reasons to default to inclusion of serial commas, with rationales that turn out to be entirely applicable to introductory commas in our context as well. I never suggested that no academic source could ever be found that went another direction, only that habitual comma dropping is primarily a journalism and marketing practice. McCoy's own source list keeps mistaking such sources (e.g. Oxford internal marketing stuff) for academic ones anyway, or citing unreliable blogs, or turning to sources like ''Britannica'' which simply do things differently from WP in many ways and don't affect how WP writes. It's just kind of a ] cloud. I don't think I need to present a clearer or stronger case than I have because the light shines through that cloud anyway.<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 02:15, 10 May 2019 (UTC)</p>
::: <small>There are 1,124 commas in this section, including those in this sentence. ] (]) 14:08, 9 May 2019 (UTC)</small>
:::: <small>Which is entry XIV in this sequence: 8, 17, 32, 54, 57, 100, 145, 177, 320, 368, 512, 593, 945, 1124. Which is the sequence of numbers constructed thus: <math>x^y + y^x</math>. Oh no now there are ''']''' commas. Coincidence? ] (]) 23:15, 9 May 2019 (UTC)</small>
::::: <small>Coincidence? Pshah. It's clearly a {{em|conspiracy}}. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 02:15, 10 May 2019 (UTC)</small>
:::{{u|SMcCandlish}}: You talk about my rehashing, but look what you've been writing the last couple of days.<br />{{tq|1=(1) I don't have time to cover every point of this right now (and much of it's handwaving or rehash of material we've already covered, like the fact that Oxford's in-house "marketing about the university" stylesheet is irrelevant to encyclopedia writing and has no connection to Oxford U. Press style).<br />(2) Let's take a vote: Who else here can't tell the difference between the style guides, written by language authorities like managing editors of the OED, etc., that Oxford University Press publishes for general usage and (in summary form for the journals it publishes), on the one hand; and the other, the in-house stylesheet, written by marketing functionaries, for how Oxford U. employees should write about Oxford U.?<br />(3) McCoy's own source list keeps mistaking such sources (e.g. Oxford internal marketing stuff) for academic ones anyway}}<br />All of these repeated criticisms, on May 7, 8 and 10, respectively, follow my having clarified on May 1 that I was not talking about the previously referred to by {{u|Number 57}}, but rather the OUP Academic Division's , which you seem to have failed to look at despite its significance to the discussion and my calling attention to your error in regard to it several times.<br />It's also interesting that you now contradict yourself regarding what you wrote only a few days ago, with which I publicly expressed agreement:<br />{{tq|1=Yet saying nothing about and leaving it to "editorial discretion" leads to circular and recurrent disputes like this (and editwars at articles, and flaming at their talk pages). "Say nothing" doesn't work when the matter is a perennial dispute; it's just MoS not doing its job because ].}}<br />I do share your skepticism about the chances for consensus (though I almost came back on last night to add that I don't ''know'' you will never move an inch), but I continue to agree with your earlier statement, and in accordance with that am presently planning on starting a new thread in the interest of pursuing your previously stated goal.<br />Before I do, however, I would appreciate it if you would acknowledge the absence (or possibly claim the existence) of a present consensus on the issue. I would normally assume that this was clear and that there wasn't, given the continued absence of a related provision in the MoS and the lack of concrete conclusion in the two previous discussions (both of which I have now studied, having missed one of them before). I'm not sure now, however, because of several surprising things I've read today in ], such as that a majority isn't required for consensus ("discussion not voting"), that arguments are more important than numbers, that unchallenged edits suffice, etc. You have spoken at times as if you believed a consensus existed (also now, with your purported provision of "a logic- not preferences-based view of how to defuse sporadic conflict over this point ''without'' writing a new rule"), and your ] would seem to imply that you do.<br />So I'm asking you to (1) finally look at the OUP authors' and editors' guide, commenting if you feel like it but at least acknowledging that it isn't what you've been saying it is; and (2) respond to the question of whether or not you think a consensus on the current comma issue exists. Thank you. –] (]) 04:49, 10 May 2019 (UTC)
:::::If your view on this is not changing, and mine is not changing, further back-and-forth is a waste of everyone's time. Let's let others get a word in edge-wise. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 11:51, 11 May 2019 (UTC)
::::::Your edit comment "Meh" has been noted. My views on this have in fact been changing; it's been an enlightening discussion for me. Also, I have already been encouraging engagement from others – suggesting people read your recent treatise despite its length, nudging them with "With no one else indeed appearing to care (?)", etc. – so you don't need to tell me about letting other people get a word in edgewise. Nothing obliges you to respond to everything I say, and it would be better if you didn't if you're going to keep repeating deprecatory falsehoods such as the one about the Oxford style manual. But you've been requested to reply briefly to two reasonable and pertinent requests:<br />{{tq|So I'm asking you to (1) finally look at the OUP authors' and editors' guide, commenting if you feel like it but at least acknowledging that it isn't what you've been saying it is; and (2) respond to the question of whether or not you think a consensus on the current comma issue exists. Thank you.}}<br />Please do so. The guide is, again, rather than . Thank you. –] (]) 13:23, 11 May 2019 (UTC)
:::::::The OUP guide you're now relying on is primarily for journals. It is a tiny {{em|house style}} guide for one particular publisher. It does not magically trump the enormous style guides produced for general public use that also happen to come from the same academic publishing enterprise. You seem unaware that OUP publishes even for general public use multiple style guides that contradict each other in many way (e.g. ''Garner's Modern English Usage'', ''Fowler's Dictionary of Modern English Usage'', ''New Hart's Rules'', ''New Oxford Dictionary for Writers and Editors'', and various others besides. There is no such thing as one monolithic, unwavering style that "represents" OUP. They use one variant set of rules for their journals and I think it may also be applied to some of their non-fiction book publishing. They issue several sets of rules for much broader writing and publishing. Internally they have a completely different, marketing-based one for styling Oxford U.-related public messaging, and so on and so forth. There is no way around this problem. WP just couldn't give a damn about their internal house styles, of either kind. They are primary sources, for a specific extremely narrow internal context, have nothing to do with encyclopedic writing, and have not been used in any way whatsoever as a basis for WP's MoS, nor would they be.<p>What matters for our purposes are their publications that other publishers rely on (i.e., that are reputable, reliable sources): ''New Hart's'', ''Garner's'', ''Fowler's'', and (to the extent a simpler usage dictionary is helpful) ''NODWE''. Oxford's internal marketing guide is no more pertinent than that of Sony or the Minnesota Attorney General's Office. Oxford's house style for journals is not more pertinent that that of any other journal publisher on the planet. Neither of those house-style works are world-trusted sources on how to write English; they are nothing but internal documents telling specific individual working with Oxford what to do with documents emanating from or being submitted to the entity. They are business relationship matters, a form of memo or internal policy; they are not authoritative sources on English usage norms or best practices. I.e., they are directly equivalent to our own MoS and its relation to the wider world: MoS is not a general "how to write" guide for the public; it is only applicable to WP itself. I'm going to ignore the rest of this, since it's even more rehashy that this bit is.<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 17:23, 12 May 2019 (UTC)</p>
::::::::Whether consciously or unconsciously, you seem to be missing the point. It should still be possible to explain the matter to you, though this may require an effort at understanding on your part. You write about the "OUP guide now relying on" as if I had changed horses, but this only perpetuates your previous repeated assertion that I ever cited the other one in the first place (not, again, that there's anything necessarily wrong with that one, or that it actually presents a distinct and less appropriate Oxford style). So rather than correcting your previous derogatory misstatements, you've added a new one. I did invite you to comment on the authors' and editors' guide and you were welcome to do so, but you have presented your commentary instead of rather than in addition to the requested acknowledgement that I cited the authors and editors guide (which is for dictionaries rather than journals – you can't have looked at it very closely) and not the other one. It may seem like a minor point and perhaps it is, but since you repeated the false statement several times and in so doing imputed stupidity to me ("Let's take a vote: Who else here can't tell the difference "), I have to insist that you acknowledge the error. The only "rest of it" is that you "respond to the question of whether or not you think a consensus on the current comma issue exists". This is a yes-or-no question, and nobody requested or suggested a commentary from you on that. Just answer it, please. A simple yes or no will suffice. Thank you. –] (]) 22:10, 12 May 2019 (UTC)
:::::::::Oxford produces lots and lots of in-house style sheets, for various projects and parties. WE DON'T CARE. They are internal memoranda. They are not reliable sources advising the world how to write; they're internal policy documents for how to write about Oxford U. in marketing materials, how to style their online resources for students, how to format papers for Oxford journal submissions, how to write their dictionaries if you're on their dictionary stuff, what they expect for book manuscripts, etc., etc., etc. They are not what the world turns to for "How should I write in English?" advice. They are not what MoS is based on. They will never be what MoS is based on, any more than our copyright policy is based on that of Uni. Frakfurt, or our civility policy is based on the human resources manual at Microsoft. FFS. How can it possibly be this hard to get this point across? I've covered this in detail in user talk already, anyway. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 15:24, 13 May 2019 (UTC)
:::::::::: Though you have repeatedly stated you were leaving the discussion and moving on, you're still returning to it here. As I have stated on your talk page (where we're supposed to be working this out), I neither requested nor suggested further commentary from you on this issue. One of the two things I did request (again keeping it simple, owing to the apparent necessity of so doing) was a yes-or-no answer to the question of whether you think a consensus exists on the comma issue in question. I have explicitly stated, though couched in other words, that I don't want to have anything to do with you and that I will be happy to never request anything at all from you in the future. Speaking of three-month voluntary bans, I hereby declare a three-month voluntary ban on myself from personally engaging with you on Misplaced Pages, following the present resolution and assuming it's not going to be necessary to lodge a complaint. So here's your last {{u|SMcCandlish}} for at least three months, if then. At this moment, however, I'm still waiting for a straight answer to my straight question, which I previously characterized – correctly, I believe – as reasonable and pertinent. We can deal with the slander later, and that hopefully will be the end of it. Thank you. –] (]) 19:09, 13 May 2019 (UTC)
:::::::::: I have received no further response on the user talk page concerned, where ] was cited to me. Actually this article approves "a request to clarify something" (as opposed to "a demand to explain"), which my request for an answer to the question as to whether the person concerned felt that a consensus exists or not was and remains. I was also not badgering an editor to state the obvious, to restate what he already said (though he did), or to go into any detail. If anyone was bludgeoning I didn't feel it was me, but I read the rest of the article regardless. "Dealing with being accused of bludgeoning the process" sent me to ], which said it was rarely appropriate for inexperienced users to open new threads there. I'm inexperienced in regard to matters such as this one, so I again followed the given recommendation and was sent to ], which listed various inapplicable cases and sent me to ] if I was "just plain confused". I didn't feel particularly confused, so the alternative seemed to be "Or try dispute resolution." This led me to ], where I was sent down the page by "When it becomes too difficult or exhausting to maintain a civil discussion based on content, you should seriously consider going to an appropriate dispute resolution venue detailed below". This led me to ], where I read: "Third opinions is an excellent venue for small disputes involving only two editors." This sounded appropriate for this one, so I followed the link to ]. After an initial hesitation because this page started off by saying that 3O "is a means to request an outside opinion in a content or sourcing disagreement" and I wasn't immediately sure whether this was a content disagreement or not, I decided it was and continued to read. Somewhat to my surprise (though understandable where actual content disputes are concerned), it said: "Before making a request here, be sure that the issue has been thoroughly discussed on the article talk page." Did that mean I was supposed to discuss the issue(s) of my complaint here on the MoS talk page? I've concluded that though these haven't been discussed here – apparently nobody cares, as someone has aptly pointed out to me privately – the general dispute has been aired sufficiently, so I'll make a request for a third opinion at 3O. I was disturbed by the obligation to inform the other editor of my post there, because I'd just announced that I didn't intend to contact him further. I then remembered that this was assuming it wasn't going to be necessary to lodge a complaint, so it's okay for me to send him a notification (though an exception for such a case would also have been understandable and supposably permissible). So I'll notify the person concerned when I file the request. I'm very disappointed that all this is necessary, as however populated this page may be by colleagues of the other editor concerned, I still feel that at least someone should have called him out at least for his evasiveness and general rudeness, if not for his self-contradictions, dubious reasoning, false assertions, and acting as if he were speaking for everyone. Or maybe he's repulsed or otherwise eliminated everyone who disagrees with him, and actually is. I don't know. In any event I am still waiting for a clarification from him on whether or not he thinks a consensus on commas following short introductory phrases exists, and a retraction of his erroneous statements regarding myself and the Oxford style guides. Comments to my talk page are welcome and invited, thanks. My apologies for any bother. –] (]) 04:06, 14 May 2019 (UTC)
::::::::::: This is just more circular argument; please give it a rest. At some point you need to realize this is not productive. MoS isn't going to have a firm rule about this, in either direction, because it's not something editors fight about all the time, and there's no clear consensus one way or the other. PS: WP:3O will not take "cases" that are about internal matters like MoS, only a content dispute at a specific article (and wouldn't take one about this, anyway, since it's a subjective preferences matter, not a unilateral fact that can be settled with sourcing). There isn't a way for you to ] on this. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 05:05, 14 May 2019 (UTC)
:::::::::::: So there's no consensus. Thank you. I rescind my self-imposed ban on addressing you. Would you please now retract your derogatory misstatements regarding my purportedly having unintelligently cited an Oxford style guide that I did not cite. I may not ] on this; I understand that incivility complaints are infrequent and generally discouraged. But I still suspect you're going to have stand before someone and account for your uncivil behavior if you don't acknowledge what you repeatedly said and correct it. I've suggested on your talk page that you might have misunderstood or forgotten that it was {{u|Number 57}} and not I who cited the first guide mentioned, and I suggest you regard the matter with that possibility in mind rather than ignoring the substance of my complaint and posting yet another beside-the-point rant accusing me of rehashing old material – which I have not done – while repeating your own. My last post contained no circular argument whatever. It and the posts preceding related to the comma issue only tangentially, in regard to the consensus question that has now finally been answered. —] (]) 06:09, 14 May 2019 (UTC)


== Any objections to extending MOS:TIES to all nations and regions? ==
== National spellings of parts of titles ==


Currently ] qualifies itself to English-speaking nations. However, in an increasingly multicultural world with English emerging as the ], at minimum in the ], why qualify this part of the MoS like that, ESPECIALLY when it also impacts on ]? For example, the ] has 24 official languages, including English, and multilingualism is one of its founding principles.
What's the style guide's take on how to handle the first sentence of an article that includes a word spelled differently in the US and UK, where that spelling difference is trivial? ] opens with "Color (or colour) photography is ...", while ] says "Color television is ...". Which is preferred? --] (]) 07:55, 30 April 2019 (UTC)
:See ]. In the case of TV and photography there is no ], so ] applies. Although "color" jars somewhat, it is pretty obvious so possibly "or colour" is superfluous. It becomes more of an issue when the word itself changes such as "A railroad switch (AE), turnout, or points (BE) ...". ] (]) 08:11, 30 April 2019 (UTC)
: Personally I'd remove "(or colour)" as disrupting the readability of the lead (and insulting the intelligence), and if someone restored it, leave it alone—it's too trivial to fight over with someone who would actually fight over it. ]&nbsp;<span style="color: Red;">🍁</span>&nbsp;] 11:11, 30 April 2019 (UTC)


Would it not make sense to extend ] to nations (and regions) irrespective of whether they traditionally speak English or not? Because I can see how saying to someone that embraces multilingualism and values Europe's rich linguistic diversity wishing to contribute to an article on a topic with strong ties to their nation or region in the EU, where English is an official language, that in this case that tie doesn’t count (and someone else gets to decide) might be perceived as ... well ... rude and arrogant, which isn't just unnecessary but also unproductive. Would the article not benefit from including anyone with a strong tie to it?
== source substantiating latter part of sentence ==


I must note I would prefer if there was an established international variant, but I also find it practical not to have to waste time and effort trying to work out whether in a given article its meter or metre, organise or organize, or SI first and then imperial, or imperial first and then SI. Because getting it wrong just causes unnecessary consternation, especially if the article is inhabited by one or more "]s". ] (]) 06:41, 14 December 2024 (UTC)
Hi, this is probably another FAQ: I have a question regarding ]. I have a sentence like “Incredibly interesting topic, so &lt;claim A&gt; and &lt;claim B&gt;.” I have two sources, one supporting <claim A>, the other <claim B>, but neither of them support the whole sentence, so naturally I haven't placed my <code>&lt;ref&gt;</code> supporting &lt;claim B&gt; after the period. Yet ] reports a bug: A <code>&lt;ref&gt;</code> may not appear directly prior a punctuation mark. Am I wrong? Or should I just insert a <code>&lt;nowiki/&gt;</code> to avoid reporting? Of course I can split everything into two separate sentences, but then I had to re-reference the topic. -- ] (] <nowiki>|</nowiki> ]) 01:26, 1 May 2019 (UTC)
:I'm not in favor of this idea. TIES is an exceptional case that should be used only when it's very clear; the main rule is RETAIN.
:In this situation, by convention, the reference supports the nearest clauses to that reference, even if after the full stop. --] (]) 01:47, 1 May 2019 (UTC)
:In practice I think this proposal comes down to "don't use American English in articles about Europe". I don't agree with that. --] (]) 06:52, 14 December 2024 (UTC)
:: Right, placing it after the period does not imply it supports the whole sentence—only whatever comes beffore the ref but after the preceding cite (or {{tl|cn}} or whatever). So: {{orange|Curly Turkey is an editor at Misplaced Pages. He is ever-present<sup></sup>}} {{pink|and ever-annoying.<sup></sup>}} ]&nbsp;<span style="color: Red;">🍁</span>&nbsp;] 02:46, 1 May 2019 (UTC)
::{{reply to |Trovatore}} The proposal doesn’t suggest it no longer needs to be clear, nor that that main rule is no longer retain. It simply proposes that MORE voices are heard.
::: {{Aye}} Alright, I just assumed references occurring after the final period support the ''whole'' sentence, or at least the ''general'' notion conveyed in it. -- ] (] <nowiki>|</nowiki> ]) 10:12, 1 May 2019 (UTC)
::As for the “don’t use American English in Europe” bit ... that would then only happen if most voices then want that. The solution surely isn’t “but I don’t like that, so let’s exclude them from the set of voices allowed to speak”. Fear not, they may choose American, who knows. ] (]) 06:21, 23 December 2024 (UTC)
::Agreed in this case with CT, but there are cases where "<code>&lt;ref&gt;</code> may not appear directly prior a punctuation mark" and "placing it after the does not imply it supports the whole " are not true, as covered at ]. Virtually all cases of this are going to be brackets or dashes of one kind or another: {{tq|1=Curly Turkey is an editor at Misplaced Pages (where he is frequently hunted<sup></sup> despite being human and not actually a plump and juicy turkey<sup></sup>); he self-declares as a Canadian expatriate in Japan.<sup></sup>}} <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 08:17, 4 May 2019 (UTC)
:Also not in favor for the reasons cited by Trovatore. ] (]) 07:16, 14 December 2024 (UTC)
:I do object to this.
:Moreover, from what I understand it's a perennial suggestion, so I recommend perusing ], wherein I happen to embark on a journey from the exact wrong position all the way to the right one, filling your heart with hope for a better future as you follow my progress. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 07:23, 14 December 2024 (UTC)
::If it keeps coming up, perhaps there is something there.
::However, you do highlight its more complex than I originally thought, so back to the drawing board 🤔. ] (]) 06:24, 23 December 2024 (UTC)
:'''Not a chance.''' The purpose of MOS:TIES is entirely, only, solely about English-language dialects that exist at a more or less national level and in a formal ] suitable for encyclopedia writing. Under no circumstances would we accept an English pidgin/creole or some vaguely identifiable informal habits of English-as-a-second-language users in some country or region as a "variety of English" to accept for encyclopedia writing. If you encounter "Franglais", "Spanglish", "Deutchlish", etc., in any of our articles it should be normalized on the spot to whichever form of standardized English suits the subject best if there are strong ], or to the form that the article already most closely matches (British, American, Canadian, or some other dialect of a country with majority or official and large minority English usage in a formal register). Another way of looking at this: There is no strong tie between Finland and any form of English. Even the "Well, it at least shouldn't be American, but British, because the UK is part of Europe and the US is not" sort of argument fails, because there's more than one national dialect of English in Europe (Irish, for now, and probably Scottish if they have another independence referendum). If there's not a particular encyclopedia-appropriate variety/dialect of English in widespread use in a country, then that country by definition has no strong tie to any such particular variety. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 06:22, 23 December 2024 (UTC)
::{{reply to |SMcCandlish}} Thank you for stating very clearly and firmly that {{tq|the purpose of ] is entirely, only, solely about English-language dialects}}, because THAT means my primary concern of how it relates to ] is a non-issue!
::For the record, I did not, and still don’t, propose that “Franglais” and so on become accepted English variants. Because that would be insane, pointless and not useful. ] (]) 06:46, 23 December 2024 (UTC)
:::If this is something to do with promotion of ''crore'' and ''lakh'' in articles that pertain to India, there's already a big thread about that at ] (again), and last I looked the consensus wasn't really changing: they're permissible as secondary units, but always need to be converted because they don't mean anything to anyone outside India and parts of its immediate neighbors (and of course among first-gen Indic diaspora). Maybe the tide has shifted in that discussion; I last looked at it about a week ago. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 06:50, 23 December 2024 (UTC)
::::No. I wasn’t aware of that thread. ] (]) 06:52, 23 December 2024 (UTC)
::::The thread to which you refer is “RfC Indian numbering conventions”? ] (]) 06:59, 23 December 2024 (UTC)
::::I don’t think there is any real overlap with the “RfC Indian numbering conventions” thread.
::::I also think ] is a dog’s breakfast, but happy to leave it alone at this time.
::::Are there any objections then to apply the direction from {{u|SMcCandlish}} that {{tq|the purpose of ] is entirely, only, solely about English-language dialects}} to ] and decouple "respect the principle of 'strong national ties'" from MOS:TIES? For example, change it to "respect the underlying principle of strong national ties as also used in MOS:TIES but in a different context”, and then also qualify the following with ''only''?
::::*In non-scientific articles with strong ties to the United States only, the …
::::*In non-scientific articles with strong ties to the United Kingdom only, the …
::::*In all other articles, the …
::::] (]) 08:34, 23 December 2024 (UTC)
:::::Well, you're been so vague about why you are asking these things, what rationale you could have for making up a new rule or changing any existing one, without any reference to an ongoing and important on-site problem, that all one has been left with is guesswork based on encounters with extant or recent discussions that seem like they could be pertinent. "{{tq|Are there any objections}}"?: '''Yes.''', I can think of a number:
:::::#There is no clear rationale for what you're proposing, much less a consensus to do it. Substantive changes to policies and guidelines (]) need consensus or they will not be accepted (unless they, rarely, hit upon something that needed to adjusted and no one else noticed until now, which isn't the case here).
:::::#There are strong rationales against it, most obviously:
:::::#:A. Your implicit notion that units of measure have no connection to dialect (or "variety" as WP likes to say) is not correct.
:::::#:B. Even if it were, it'd be immaterial. The next implicit idea in your proposal (quite central to it really) is that if P&G page X reiterates a general principle from another, Y, and cites the latter for the explanation, such that X applies that principle to X's circumstances because they are reasonably analogous to Y's, that this somehow creates a ] rules-chain dependency in which every aspect of the context of the cited origin of the principle in Y must also be applicable to the citing circumstances of X. Nothing on Misplaced Pages works that way at all. Cf. ]: it's a mistake to try to interpret our P&G as essentially a legal system (or as something like a procedural programming language, or a chain of dependencies in building software from source code; more than one analogy works).
:::::#:C. Because of point B, and because of the guideline's current "where applicable" wording (which is there for a reason and meaningful), your first rewrite idea, of tacking on a bunch of "respect the underlying principle of strong national ties as also used in MOS:TIES but in a different context" verbiage it entirely superfluous. The two versions convey the same meaning, because it is already understood that the principle (not the detail-by-detail contextual specifics) of TIES is being applied at UNITS. This is the way our entire P&G system operates. It wouldn't really be possible for it to be any other way. If UNITS was literally just restating TIES, down to the specifics of exactly what TIES covers, then UNITS would be redundant (in this regard) with TIES, and its wording about this issue would've been deleted long ago and replaced with a simple cross-reference to TIES without further comment. The kind of exemplary and contextual more-than-crossreferencing done at UNITS is entirely normal. And important: an editor looking for "what to do about units" is unlikely to instead stumble upon "what to do about national-level usage disputes", and so would be unlikely to find the TIES principles and then be certain how to contextually apply them (if at all) to units, without being basically an expert in our style guide the way some Tolkien fans learn Elvish.
:::::#:D. The next bit of suggested rewriting is to inject "only" into two line items, but this change would have a nonsensical and undesirable result in two ways: It would make those items applicable under no circumstances to anywhere but the US and the UK, respectively (even to former UK colonies with English- and units-usage norms virtually indistinguishable from British in an encyclopedic ]); and it would necessitate (to fix that new problem) expanding that into a long list of every country with anything that WP would consider a "national variety of English" with pertinent unit-usage norms. The purpose of those two examples is {{em|as examples}} (not as an exhaustive list) of how to approach these matters. The examples were chosen because they settled previously recurrent disputes. So, what long-term, recurrent, serious problem can you point to that you think your changes would resolve? The examples are not there to serve as the beginning of an ever-growing rulebook to address every imaginable case with a new micro-topical line item to thump. The purpose of giving a general principle and providing some prominent examples is to obviate the need to have a pile of micro-rules. (MOS:NUM is already too detailed as it is.)
:::::# The long-term stability of these guidelines is very important, because even small but meaningful/operative changes to them can affect many thousands up to potentially millions of articles, for reasons that almost always resolve to trivial and subjective peccadilloes. That cascading-wave-of-unneeded-changes problem (and all the fighting the endless trivial tweaks would generate) is never more of a danger than when a national-level and frequent usage matter is at issue (and literally millions of our articles do have measures with units in them). See also ]: If MoS, after 20-odd years, doesn't already have a rule about something, then it needs to {{em|not}} have a rule about it, because it is not necessary for the project to do what it does successfully, and MoS is already way too long.
:::::# Your "I also think ] is a dog's breakfast, but happy to leave it alone at this time" approach does not bode well. Our policies and guidelines don't exist as hills to die on. The purpose of these style guidelines is (aside from the main one of producing intelligible and consistent content for our readers) {{em|dissuading}} style-warring behavior. Arriving with the idea that the rules are broken and that at some forthcoming time you're going to fix them is antithetical to their purpose and to the needs of the community. It largely doesn't matter {{em|what}} any particular line-item in MoS sets out (except when there is objectively a reader-clarity improvement offered by one option over another), only that it sets out, and long-term retains, {{em|something}} that addresses a recurrent dispute pattern and brings it mostly (hopefully entirely) to an end, and/or that it produces better content for our readers – even if that "something" is arbitrary or is a compromise that can't please everyone. Just as a word to the wise, ] (including TIES) is pretty much the hardest-fought consensus compromise reached in MoS's history, and is also one of the oldest and most stable, so if you think you're going to make serious changes to it, you are very mistaken. It's like going to Canada and declaring your mission is to undo the country's approach to French and English as official languages.
:::::This might all come off as harsh, but ], and the vast majority of proposals to change any P&G are off the mark. There are many devils in many details (thus the length of this), with a lot of nuanced interrelations between different rules (or advice or best practices or whatever you want to call them). Most of the real kinks were worked out long ago. Those that remain are subject to long-term dispute that hasn't produced a workable compromise. There is no such dispute about the material you want to change. And there are sometimes severe costs for making changes that are not vital to make.<!--
-->PS: I've tried hard to find a "yes" to put into this pile of "no", and there is one! Namely, your version is correct that the "scare quotes" around ''strong national ties'' shouldn't be there. I just went and removed them, so thanks for that. Otherwise, no element of your draft appears to be clearly an improvement. Here's the original wording: {{xt|The choice of primary units depends on the circumstances, and should respect the principle of ], where applicable}}. Here's yours (presumably also keeping the original's first 10 words and the link): {{!xt|respect the underlying principle of strong national ties as also used in ] but in a different context}}. Mentioning the other guideline by name is redundant with linking to it, and all our P&G pages are fairly (not entirely) consistent in, when practical, using plain English with links around pertinent terms rather than injecting page names. Mentioning it by shortcut in particular is "newbie-unfriendly" and wrongly presumes memorization of our shortcut strings. "Underlying" is a puff word and doesn't serve a concrete purpose in the sentence. (And underlying what? It has no clear downstream referent.) "As also used in" is more redundancy; if we're linking to TIES as the locus of the principle, it's already automatically understood that the principle is applied at the place we're linking to. "But in a different context" is a combination of redundancy with the implication of the link again, and quite odd wording: Why is there a "but" in this? (What it is contrasting against?) "Different" from what? Different in what way? And "context" is conceptually misused in this construction, in that the general principle at TIES is a meta-context, of all usage/style disputes pertaining to national-level English dialects, while use of units is a subset of that, a sub-context, not a conflicting/alternative context. Finally, unit usage is only {{em|sometimes}} a subset of the usage in a national variety of English, thus the original's "where applicable" – a key point that your version drops, despite it seeming to be central to the bee in your bonnet. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 11:54, 23 December 2024 (UTC)
::Introducing Scottish as an additional form of English would cause mayhem - or at least a shedload of future editing - here. We’ve already had a nationalist-driven push towards replacing ‘British’ with ‘English’ or ‘Scottish’ in bio articles, usually uncited and based purely on supposition or the subject’s birthplace. Fortunately, Scottish Independence appears to be receding as a prospect, at least in the short to medium term. ] (]) 07:48, 23 December 2024 (UTC)
:::I don't disagree (and we had a real template at {{tlx|Use Scottish English}} in 2013, with an attempt to re-create it in 2016). Several years ago, I tried to get rid of all the "Use {{var|Foo}} English", and related, templates declaring "national varieties" that, in reality, are completely indistinguishable from general British English {{em|in an encyclopedic register}}, and could all collectively be covered by a "Use Commonwealth English" template. ENGVAR only applies to national (not subnational) varieties, and only those dialects that exist in distinct forms and with a formal register (by definition: if you can't write encyclopedia-appropriate material in a dialect, then it doesn't belong in our articles for any reason, so ENGVAR cannot be used to "protect" it from edits). But nationalistic sentiments won out in the end, and we still have all that claptrap, with ridiculous results like articles being tagged with {{tlx|Use Jamaican English}}, {{tlx|Use Singaporean English}}, etc. (Likewise we have no use of American-splitoff variants, either, like "Use Guam English", etc.) Too many editors who should know better and should think just a tiny bit harder have utterly mistaken the purpose of these as something like "national pride" flags to put on articles, in a verging-on-] manner. These tags absolutely do not resolve to "write an article about Nigeria using colloquialisms and grammatical oddities found only in the informal speech and writing of English in Nigeria, which will be confusing to everyone else in the world". If someone tries that crap in response to such a template, rewrite the material per ] and ]. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 11:54, 23 December 2024 (UTC)


== MOS:NOTGALLERY ==
== Station names in ALLCAPS (redux) ==
Hi all


At another talk page, I was writing an explanation of why articles should not be swamped in a plethora of images, planning to cite ]. Fortunately for once I checked first and found that it is just an alias for ], not a statement that article spaces should not be mirrors of Commons.
We had ] as to whether it is legitimate for infoboxes in station articles to (a) style the top of the infobox with a mock version of the sign used by the rail company running the station, with colours, patterns etc. and (b) render the station name in the infobox in ALLCAPS if that's the style used by the rail company on its signage. The discussion seemed to lean towards depracating the practice, at least for ALLCAPS, for readability reasons. But the matter was never formally concluded and there are still lots of examples like ] where it's happening. Do we need a formal RFC or other mechanism to depracate this? Thanks &nbsp;&mdash;&nbsp;] (]) 12:04, 1 May 2019 (UTC)
:I think someone just needs to implement that already-existing guidance at ]? --] (]) 14:43, 1 May 2019 (UTC)


Given that the majority of visitors do so on mobile phones, is there a case for an explicit policy that says that curation is essential, ]?
::What is happening here is that the infobox template for MARC stations automatically formats the text “header” to match the signage... so it isn’t the article text that needs to be amended to bring this into sync with ALLCAPS, but the template. Alternatively (for those who prefer that the template follow the signage)... consider amending the template so it replaces the ''text'' header with an identical looking ''image'' of the signage. Our MOS rules do not apply to images. ] (]) 19:54, 3 May 2019 (UTC)
:::That's a lame idea that we already flushed, isn't it? ] (]) 05:08, 5 May 2019 (UTC)


Or would it be enough to change the target of NOTGALLERY to ] (which might need a little expansion because right now it just says {{tq|Images must be significant and relevant in the topic's context, not primarily decorative. They are often an important ] to understanding. When possible, find better images and improve captions instead of simply removing poor or inappropriate ones, especially on pages with few visuals. However, not every article needs images, and too many can be distracting.}} At least a reference to ]? (which is expressed in terms of word count, not megabytes, so would also need work). ] (]) 17:48, 16 December 2024 (UTC)
:Already deprecated by ] (we don't use all-uppercase except for acronyms, and a few really geeky technical things specified in detail there); and by ] (don't use CSS and Unicode tricks to simulate graphical effects in an attempt to ] around rules against misuse of decorative little images); and by ] (WP doesn't mimic logos and other stylization). This fails three guidelines at once and should just be reverted.<p>See also ] for essentially the same debate but in a different subject area (except worse, because it's happening inline in article text, not in an infobox).<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 07:58, 4 May 2019 (UTC)</p>


:I think IMAGEREL would be a better redirect target. I want this to point to guidance that images should be included selectively rather than overwhelming articles with images. NOTDB instead seems to be guidance that images should be relevant and accompanied by text, which is not enough to prevent big indiscriminate galleries. —] (]) 20:52, 16 December 2024 (UTC)
== "Let us consider" statements ==


::I've had second thoughts about this one. It is probably not wise to make NOTGALLERY an exception to the general rule that WP:NOTaaaaaaaa shortcuts all redirect to ]. So the better plan is to add a short sentence to the current target to say that {{tq|Misplaced Pages is not a database of images or a {{lang|fr|]}}; those are among the functions of ]. Image use in Misplaced Pages articles must comply with ].}} I will do that now.
There are about 300 articles containing "Let us consider" statements, such as ] ("To explain the mechanism, let us consider mixing red paint with yellow paint") and ] ("To elucidate, let us consider a family with two or more sons"; "Let us consider a family in which the mother died before the son was married"). I find this phrasing to be overly formal and unnecessarily wordy. I would like to go through these articles and, except for instances where the phrase is part of a quote, either remove the "let us" part and have sentences like the above merely read "To explain the mechanism, consider mixing red paint with yellow paint" or "Consider a family in which the mother died before the son was married", or remove the entire phrase and use a different construction, "To explain the mechanism, when mixing red paint with yellow paint..." or "In a family in which the mother died before the son was married..." to lead into the next concept. Since this would affect hundreds of articles, I would like to see if there is any disagreement with this plan of action. ] ] 13:36, 6 May 2019 (UTC)
::IMAGEREL needs some work too, to make it even more explicit that to bury an article in a mass of images is sure way to ensure that nobody reads it. --] (]) 10:43, 17 December 2024 (UTC)
* Some thoughts. It’s a style of writing. I think it is a little bit familiar to Japanese formal writing. I have seen argument that first person writing lends itself to easier clarity, and more natural active versus passive writing. “Let us consider” is first person plural active tense. It is not popular is modern western culture. Is it desirable to force the popular writing style on all articles? What if the sources use that style? This style is probably best avoided as it strongly implies a ], which should be avoided or minimised. —] (]) 13:49, 6 May 2019 (UTC)
:While some types of "galleries" should be avoided, articles on certain visual topics do benefit from many visual examples. I also do not think we should explicitly outlaw the ] model while allowing many other bibliographic lists. One size does not fit all, and such a change would need to be debated with the folks curating ] and those who work on visual topics. —] (]) 10:57, 17 December 2024 (UTC)
** It appears that the most prevalent use of this phrase is in articles relating to the hard sciences and complex mathematics, where publications often use certain phrases to introduce topics (for example, it is common in mathematical writing to introduce parameters by saying, "It is common knowledge that...", even if the thing being introduced is not exactly "common" knowledge). I think that is where these "let us consider" phrases tend to come from. ] ] 14:35, 6 May 2019 (UTC)
::Pending further discussion, I have removed the reference to ''catalogue raisonné'' from my amendment (so that it now reads simply {{tq|Misplaced Pages articles are not a repository of images: image use in Misplaced Pages articles must comply with ].}} to item 4, "Photographs or media files".
:In terms of succinct and direct writing which is part of concisely conveying information as an encyclopedia, I can’t think of a time when you’d want those phrases in an article, especially since you can cut it down to just “consider X” if you really want to introduce something in that manner. ] <sup><small>]</small></sup> 15:10, 6 May 2019 (UTC)
::I agree certainly that, in an article about an artist or an artistic movement, it is essential to illustrate the phases of their artistic development. That to me is clearly in keeping with IMAGEREL and wp:localconsensus can determine relevancy. But to include an image of <em>every</em> work in an artist's '']''? How is that a valid exception to NOTDB? (and likely a COPYVIO too). And why not show every putter manufactured by ACME Golf Inc? every locomotive made by ACME Rail Inc? every postage stamp (including all misprints) produced by the Austro-Hungarian empire? We have articles so swamped in pointless images that they have become essentially unusable to visitors on mobile. How does that make any sense? --] (]) 11:34, 17 December 2024 (UTC)
:This seems to relate to ]. ] ] <small>(earlier ''Boracay Bill'')</small> 15:15, 6 May 2019 (UTC)
:::I would definitely oppose including every work in an artist's oeuvre in an article on the ''artist'', but I want to make sure we do not outlaw ], where the images are perfectly encyclopaedic and just as relevant for identification as the images in ]. Tables in such long lists are often not great for small screens, but that is a separate issue from the number of images. Generally, lists are not the same as other articles in their use of images, so the rules should reflect that. —] (]) 12:25, 17 December 2024 (UTC)
:: Good point. Perhaps ] should be amended to specify avoiding constructions like "let us consider" (or even just "consider" statements). ] ] 16:55, 6 May 2019 (UTC)
::::I don't see a problem with that. Clearly the application of IMAGEREL should (and would) be different between a list article v a fairly broad concept article. To take your example, it would be entirely reasonable to include every image we have in the list article, provided that we use small thumbnails (upright=0.2); conversely (IMO) the bio article about Munch should be curated so that it has just one carefully chosen image to illustrate each phase of the development of his style , with maybe one or two especially notable examples that he did . Surely we don't want to replicate Commons? --] (]) 18:23, 17 December 2024 (UTC)
:Apart from being wordy, first person writing and writing that speaks directly to the reader like that doesn't fit the encyclopaedic tone. Nor does it seem appropriate for a collaboratively-written work. Speaking of which, when Misplaced Pages becomes self-aware enough to start speaking in "we" terms, I think it'll be time to find another hobby. :) ] (]) 16:05, 6 May 2019 (UTC)
:Please, let's not compromise the full extent of the encyclopedia by limiting what has always been one of its main features. Images and galleries define and describe just as much as text. That many choose to "read" Misplaced Pages on tinier gadgets should not dictate the coverage and image-styling of encyclopedic content articles. ] (]) 11:49, 17 December 2024 (UTC)
::The problem we have at the moment with some articles is what {{u|David Eppstein}} describes above as "big indiscriminate galleries" and rote copying of everything in Commons for no evident informative purpose, a form of ]. As IMAGEREL begins, "Images must be significant and relevant in the topic's context, not primarily decorative. They are often an important ] to understanding". Without curation, the information gets buried in the woodpile.
::I am not proposing a principle that we must minimise the number of images, period. My proposal is that we provide a policy basis that editors can use to say "that point is already adequately illustrated, another image adds nothing new" or "this article had become so bogged down in images that it no longer navigable". I am talking about edge cases here, in most articles it is not an issue. But some have become swamped in an uncritical replica of Commons. This is not to enable wikilawyering, it just makes it easier to explain the rationale. --] (]) 18:23, 17 December 2024 (UTC)
:::As an example of the sort of burying articles in galleries that I would object to, see ], where (at least in its ) four of its six sections are entirely image galleries (in some cases hidden in collapsed templates, with much of their content peripheral to the main article topic).
:::We do need wording that distinguishes this case from ], where the galleries are entirely appropriate, though. —] (]) 18:29, 17 December 2024 (UTC)
::::But as far as I can see, the List of paintings by Edvard Munch (and similar lists by artists) already complies with IMAGEREL, because the use of images in that article is ''proportionate and entirely relevant to that context''. Conversely, to put all those paintings in the Munch bio article as a giant gallery would not be proportionate (IMO).
::::So to focus this discussion, can anyone suggest another sentence we can use to amplify the point made in the opening sentence of IMAGEREL? ("Images must be significant and relevant in the topic's context, not primarily decorative. They are often an important illustrative aid to understanding".) How about
::::{{blockquote|Consequently, each image in an article should have a clear and unique illustrative purpose: for guidance, see ].}}
::::AFAICS, that responds to and respects both the Munch examples above. (FWIW, very few if any of the visual arts articles suffer from this swamping problem. The issue affects high profile articles like ].) ] (]) 11:29, 18 December 2024 (UTC)
:It is entirely enough that we have the ] shortcut. A proposal to retarget ] to that would almost certainly fail, because it's part of a very long-standing set of policy (not guideline) WP:NOT{{var|FOO}} shortcuts to sections of ], and such a change would both confuse editors today and render archived discussions of policy misleading. "Ain't broke; don't fix it." <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 06:10, 23 December 2024 (UTC)


== Audio video guidance ==
*We should replace all of the "let us consider" constructions with "for example" or similar replacement. All writing should avoid 1st and 2nd person constructions like these. --]] 17:06, 6 May 2019 (UTC)
**I prefer "Consider" to "Let us consider", but it is not generally possible to replace them by "For example". The typical use for me of "Consider" is to set up the preconditions for a math problem, like "Consider two points in the Euclidean plane, with integer coordinates. Then their distance is the square root of a ]." In this example, it could be rewritten as a single sentence, "When two points in the Euclidean plane have integer coordinates, then their distance is the square root of a ]." But that single sentence is long and grammatically complex. And this was only a short example; ] can be considerably longer. The use of "Consider" allows it to be broken into two shorter sentences, which are individually less ] and therefore easier to read. —] (]) 20:04, 6 May 2019 (UTC)


Hi there, I'm noting a lack of guidance for Audio video content, I've mentioned this at ]. It seems people just edit MOS rather than run through large discussions, but I'm reluctant to start plunging in before getting some help. Here is what i think is needed:
* It's already against ], as I understand it, though I wouldn't object to adding the example. I've found phrasing like that to be a good indicator of potential ]s. <span style="color:red">—](])<span style="color:red">]—</span> 01:24, 7 May 2019 (UTC)
*'''Update''': I have gone through the list and replaced every instance I could find of "let us consider" or "let's consider" that was not part of a quote with "consider", which is at least an improvement. That leaves about 250 articles containing "consider" statements, which might be looked at more carefully. ] ] 04:34, 7 May 2019 (UTC)
*:Those should just get removed or replaced, per ]. Some ] people have argued for an exception for maths material because it's use is common in maths textbooks, but that's not really a rationale, per ]; we don't write in that style to begin with. Any case of something like "Consider two points in the Euclidean plane, with integer coordinates. Then their distance is&nbsp;..." can be replaced with "Given two points in the Euclidean plane, with integer coordinates, their distance is&nbsp;..." which is less pedantic and more concise, as well as no longer a fourth-wall problem. Same with David Eppstein's other-way-around rewrite above; which to prefer would depend on what the material needs to emphasize in the context. Even in long cases that won't work as a single sentence, the instructional "Consider" can be written around some other way. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:27, 7 May 2019 (UTC)
*::Writing simple understandable sentences for technical subjects is more important than your pedantic adherence to certain overspecific grammatical rules. And if you are not a regular editor of mathematics articles, and don't have experience trying to write these things both non-technically and accurately, please stop making blanket statements that this construct is easily avoided. It is not. —] (]) 18:09, 9 May 2019 (UTC)
* For the most part, these are not examples of ] – it is not instructing the reader that they must take note. Rather, they are examples of the "author's we", marking a logical progression in an explanation, which is an acceptable encyclopaedic form, as stated at ], althugh it can usually be reworded if desired. I agree that "consider" is preferable to "let us consider" in most cases. ]] 23:22, 7 May 2019 (UTC)
** For our purposes, they're not distinguished; see also ]. Given that there are unlikely to be any cases that cannot be rewritten, just rewrite them. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 05:02, 8 May 2019 (UTC)
*** {{ping|SMcCandlish}} MOS:WE is exactly the same guideline section as I linked at MOS:PERSON above and it very much ''does not'' say it is the same as MOS:NOTED. MOS:WE explicitly states that the author's we ''is an exception'' to the injunction not to use personal pronouns and that this is an acceptable form. That is why the example text is in green, not in red. For our purposes, ''they are'' distinguished as far as the guidelines are concerned. ]] 10:17, 8 May 2019 (UTC)
****They are the same for our intent here in that they're undesirable. The section does not say it's an exception, it says it's best rewritten. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 22:21, 8 May 2019 (UTC)
***** You are clearly reading what you want hear, not what is actually written. {{xt|But some such forms are acceptable in certain figurative uses. For example:...The author's we found in scientific writing}}. Does that passage, or does it not, contain the word "acceptable"? {{xt|Often rephrasing using the passive voice is preferable}} says neither that the author's we is undesirable, nor that it must be removed. You are reinterpreting what it actually says to comply with your own opinion. ]] 23:27, 8 May 2019 (UTC)
****** And you're cherry-picking to selective quote what you like and ignore what argues against you. "Acceptable" (i.e. not against rules, not something you'll get in trouble for) doesn't mean "advisable", especially when what you elided says "Often rephrasing using the passive voice is preferable". The actual advice is in the opposite of your preferred direction. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 00:45, 9 May 2019 (UTC)
*It's maths language, to start with. Should be used judiciously, but there's a place for it. Under no circumstances should someone unilaterally sift through expunging every instance without careful judgement. ] ] 03:10, 8 May 2019 (UTC)
*:Yes, there is a place for it - in a maths textbook or lecture notes. I have used plenty of these myself in my time and very useful they are too, for a student if mathematics. Where it doesn't belong, though, is an encyclopedia. We should be describing the topics we have articles on, not attempting to teach them to our readers. The fact that large numbers of articles do it does not make it right. &nbsp;&mdash;&nbsp;] (]) 18:34, 9 May 2019 (UTC)
*One other concern - I have found that “let us consider” (and similar language) is often a red flag that the text is a copyright violation. Not always... but often enough that we should avoid it. ] (]) 12:00, 8 May 2019 (UTC)
*'Let us consider' is very math textbooky, but it's just a more formal way of saying things are conditional on the assumptions. "Let us consider ''n'' pairs of numbers" is just a more formal way of saying "Imagine you have ''n'' pairs of numbers" or "When you have ''n'' pairs of numbers" or "The following results assume you have ''n'' pairs of numbers". I don't really see the inherent problem with it, save for a bit of stuffiness that will be lost on the general population. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 19:16, 9 May 2019 (UTC)
*:Since there are other ways to do that (most commonly and succinctly, "Given ''n'' pairs of numbers,&nbsp;....") which are not presumption/instructional language aimed at the reader, I'm suggesting we should use those other ways. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 02:52, 10 May 2019 (UTC)
*::Your proposed replacement, besides leading to longer and more complex sentence structure, is problematic grammatically. A sentence that begins "Given X," can really only be followed by a noun phrase that is modified by "given" and describes to whom X was given. That whom is the reader, again in first person. So you can properly say something like that "Given ''n'' pairs of numbers forming the coordinates of points in the plane, consider their convex hull" and we're back where we started with "Consider". Or you can say "Given ''n'' pairs of numbers forming the coordinates of points in the plane, their convex hull is ..." and be wrong and confusing because it is incorrect that anybody is giving the pairs to the convex hull. —] (]) 04:21, 10 May 2019 (UTC)
*:::{{talkfact}}. I'm unaware of any dictionary or other source that defines the "Given {{var|X}}, then {{var|Y}}" construction that narrowly. You're obviously aware that words have multiple meanings and uses, and thus that "given" need not refer to something literally handed from one person to another like a gift or a payment. Regardless, the point is there that are ways to write about this stuff that do not use instructional language like "Consider ...". Another obvious one is "If , then ", and another is "When , then ". Give a minute or two, anyone could probably come up with ten more. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 12:43, 13 May 2019 (UTC)


* Something explaining that the guidance at ] applies to Audio-video content in most cases, eg regarding relevance, image quality, textual information, offensive images, placement, size, location, availability. Nearly all of the page is relevant, in fact.
== Scope of accessibility guidance ==
* The download advice might need to be different. Do videos or audio need a warning that they are large files? This is not assumed, it seems.


There is a case for some separate AV guidance, regarding:
One of the issues we regularly encounter is the unwarranted assumption that MOS only applies to articles, but that's simply not true. The MOS covers three broad areas: documenting conventions; guidance on functionality; and guidance on accessibility. It is reasonable to assume that the first, and probably the second, have their greatest applicability in mainspace, but there can be no doubt that the guidance the MOS gives to help make our encyclopedia accessible to all must apply to every page.


* Length: should inline videos be shorter where possible? Does this apply to audio clips?
I've to the lead to make that clearer, as this page takes precedence over its sub-pages. Please feel free to improve it. --] (]) 10:10, 9 May 2019 (UTC)
* Language: if audio or video is original language, should subtitled content be preferred rather than recording originals? Should songs be subtitled where possible? What are the requirements for validating translations (what are the relevant WP policies on translation of original source material that apply?)
* Rendition: historical accents and historical musical performances might be very rare. Should we say that modern standards are fine, in the absence of authentic reconstructions?
* Public domain renditions: if audio or video is a rendition of a public domain source, for example a work by Mozart, or a speech by Caesar, what are the requirements for source validation (these should reference WP's general guidelines, but these are mostly focused on secondary sources).


] ] 20:25, 16 December 2024 (UTC)
This has now been reverted with the edit summary {{tq|"(a) If this belongs anywhere, it belongs at MOS/Accessibility; (b) but there's a more serious problem: it's one thing to say that accessibility considerations apply everywhere (which is fine), but it's quite different to say that those are the RIGHT considerations for application outside of article space"}}
*Elsewhere, someone asked whether an RfC would be needed to add guidance on this topic. I think not -- while discussion will be needed on details, I can't see anyone objecting to clarifying that multimedia beyond everyday images should follow similar guidelines to those for image. The question is where to say that. We don't want to duplicate guidance on contextual significance etc., because that creates two things that need to be kept in sync. Probably the best thing is to expand MOS/Images to explicitly cover other multimedia. See BTW ], which has a ''contextual significance'' section. ]] 20:39, 16 December 2024 (UTC)
*:Thanks very much (and yes that was me!) I agree that MOS:Images would be best, especially to get this started.
*:The ''contextual significance'' contains much about in-copyright works. That is in general very helpful. In-copyright video samples feels like something rather complex that might need an RFC, and might be best parked until there is a little more in place. ] ] 20:49, 16 December 2024 (UTC)
*::@] Would it be helpful if I draft up something on ] and ask for feedback? ] ] 21:03, 16 December 2024 (UTC)
*:::I suggest you wait a while so that the experienced editors gathered here can lend their thoughts. After that, you might take the conversation back to Talk:MOS/Images, but since that page has 1/5 watchers of this one, and you've already put a pointer there to this thread here, it might be better to continue here as you begin to draft. There's no hurry to this, so the slower you take it, and the greater the extent to which others can get their thoughts in, the smoother it will go. (I'm afraid I'm really tied up IRL so the time I myslf can contribute is limited.) ]] 21:24, 16 December 2024 (UTC)
*::::Happy to wait. I made a stab at below, but I can wait for further thoughts / feedback here. What I've provided relates to historical source content, as most of the AV I've been dealing with falls into this category; I have guessed at some other considerations but it is currently narrower than it should be. ] ] 21:44, 16 December 2024 (UTC)


<blockquote>Audiovisual content can also be used for illustrative purposes. Most of the guidance on images above applies to audio visual content. Additionally, consider:
(a) It certainly does belong here. This page delineates the scope of the Manual of Style and this page claims to be authoritative. The scope of accessibility is universal, as disadvantaged and disabled readers and editors participate throughout the encyclopedia. The statement of scope is not something that can conveniently be ghettoised into a subsection of the MoS, and merely paying lip-service to accessibility is not an option in this day-and-age.


* '''Length''': inline videos or audio that is shorter will be easier for users to watch. Consider clipping long form content, and linking to the original on Commons, or elsewhere. Longer videos (eg, over 10 minutes) may be more suitable for links than inline video, unless they are highly relevant to the page's subject.
(b) If any of the guidance contained within ] is considered unsuitable for outside article space, then I'm unaware of it. Specific exceptions, if they exist, can be catered for in the appropriate sub-section, but in the absence of real examples of this purported "more serious problem", there is no good reason not to have a statement of scope in the lead of MoS. The paragraph should be restored. --] (]) 16:22, 9 May 2019 (UTC)
* '''Rendition''': historical accents and historical musical performances of content may be very rare. Modern renditions are fine, where authentic reconstructions are not available, and may be preferred, where there is uncertainty about the original performances.
:I don't disagree with the underlying point, though it would probably be better added as a footnote about MoS's scope. And the suggestion that much of MoS only applies to mainspace isn't true, as it applies to any reader-facing content, which also includes portals, templates transcluded into mainspace, category names and explanatory content atop category pages, etc., etc. In practice almost all of it is applied site-wide except in userspace and on talk pages. E.g., it's entirely normal to edit policy pages, template documentation, etc., to comply with MoS, but not to change other people's posts, or drive-by change a userspace essay. We used to have a footnote covering this, too, but someone keeps slow-editwarring it out. Need to restore that, since its presence reduces a lot of disputation. That said, the idea that ] should apply to every single page "no matter what" is bound to be controversial. Such a decision is outside MoS's own scope. I would think that it would need to appear in some policy or more general editing guideline, perhaps as a recommendation that what is said at MOS:ACCESS about encyclopedia content should also generally be applied to internal content as a courtesy to editors with accessibility needs, and leave it at that. But I'm not certain what the best page is for that. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 02:48, 10 May 2019 (UTC)
* '''Musical, poetic and literary content''': aesthetic considerations are higher for these kinds of content. Where possible, the performances should be considered good by other editors. Where editors find performances are poor, content should generally not be included.
* '''Language''': where audio or video is in the original language, subtitles should generally be preferred rather than translated versions, as this reflects the original more closely and text files are easier to correct than mistakes in audio-visual content. Where possible, songs should be subtitled. Original language versions should be made available where where possible for artistic content.
* '''Translations of subtitles''' should be verifiable, but as with other Misplaced Pages content, competent editors can create them. While academic translations are preferred, where subtitle translations are longer than 10-20 words, use of academic translations is likely to constitute copyright infringement. Here, a Wikipedian's translation should ideally be verifiable against an academic translation. (See ] for further guidance.)
* '''Public domain renditions''': if audio or video is a rendition of a public domain source, for example a work by Mozart, or a speech by Caesar, the original sources must be valid. The performance should be comparable and follow the original. Where possible, include links on media file pages so that editors can make checks.
* '''Sourcing''': as with images, sourcing of audio-visual content needs to be copyright compliant. Sources of CC video and audio can include Youtube, Flickr and CC search tools. Care should be taken to ensure the licensing claims appear to be valid.
* See also: ]</blockquote> ] ] 21:50, 16 December 2024 (UTC)


:The "Language" point is a bit unclear to me. Is it asking for subtitles to be in English or the original language? If the phrase "rather than translated versions" is referring to the spoken or written material, that seems to contradict the phrase "where audio or video is in the original language". Which is also a weird way to say it because the "original language" could be English. Given that this is English Misplaced Pages, an English version should be provided whether or not there is a non-English version.
== RfC on gendered nouns in spaceflight ==
:Subtitles should be provided for all videos with an audio track, to make them accessible for readers who cannot hear or find it difficult. There are additional guidelines at ].
:Not sure the "Sourcing" point needs to be made, as this is explained in detail for images generally.
:The "Length" point should probably link to the ] and point out the copyright issue when displaying here under fair use. It should say "video" not "videos" to be grammatical.
:I would drop the "Translations of subtitles" point and just link to ] for guidance on translations.
:The "Public domain renditions" point does not make any sense to me, and I would just drop it.
:I'm not sure whether the "Rendition" point needs to be made, but if it does, it's confusing. I think it's supposed to be recommending that historically accurate renditions of older works are preferred, if available. Maybe that's true, maybe it isn't, depending on what the purpose of inclusion in the article is. Might be better just to leave this point off; I don't see any similar guidance for audio samples of music. Page editors can decide which samples are best out of those available.
:Another point probably worth making is that a video should be considered an optional part of an article. In other words, any content vital to reader understanding should be included in the text and not be omitted on the assumption that reader will watch the video. Many readers will not be able to view video due to technical limitations, such as using a web browser that is not configured with a video player, or reading an article in another medium such as an app, paper printout, or text-to-speech system (including those who cannot see or find it difficult to read text). There is more specific guidance against putting text in images at ].
:It's fine for a video to re-explain something that's already explained in the text if having a moving image clarifies substantially, but it seems wasteful for embedded videos to effectively repeat or rephrase the text.
:-- ] (]) 22:49, 16 December 2024 (UTC)
::Thanks very much!
::* Regarding '''language''', this was meant to be about non-English content, think Bach or Mozart in German or Latin; or Goethe's poetry.
::* On '''Sourcing''', the section on images does not include YT, which is significant for CC video.
::* On '''translation''', the situation for subtitles is a bit different, as usually you cannot use academic in-copyright translations, so this mention is retained.
::* On '''public domain renditions''', this was the subject of a ]. Does that help? Take a file such as ]. There is some need for verification, even tho it is not being used as a citation? I've edited it for clarity.
::* On '''style of renditions''', this has come up a few times in discussion, including at the link above, where a user claimed only a Catholic priest could do a Latin audio recording; also at ] on LA Misplaced Pages about accents and delivery, preferring a modern standard over historical guesses. I figured the same principle might apply to say reading Shakespeare, or using 16th century instruments; it simply shouldn't be a consideration, but sometimes editors think it should be.
::* I've added the points on (1) text as images, (2) subtitles for EN content, (3) optionality of AV content
::'''VERSION 0.2'''
::Audiovisual content can also be used for illustrative purposes. Most of the guidance on images above applies to audio visual content. Importantly, audio-visual content should not be an essential part of a page, which is necessary to understand the whole. This is because not all readers will be able to download or access the content, for example because of technical limitations or relying on text to speech tools. With audio and video just as with any content, relevance is paramount; consult ] for further context. There must be a clear reason for including the content on the page.
::Additionally, consider:
::* '''Length''': inline videos or audio that is shorter will be easier for users to watch. Consider clipping long form content, and linking to the original on Commons, or elsewhere. Longer videos (eg, over 10 minutes) may be more suitable for links than inline video, unless they are highly relevant to the page's subject.
::* '''Rendition''': historical accents and historical musical performances are not required. Modern renditions of audio are acceptable. For example, there is no need to read Shakespeare with an Elizabethan pronunciation.
::* '''Musical, poetic and literary content''': aesthetic considerations are higher for these kinds of content. Where possible, the performances should be considered good by other editors. Where editors find performances are poor, content should generally not be included.
::* '''Subtitles for comprehension''': In English language videos, an English language subtitle track should always be provided for accessibility. See ] for more details.
::* '''Subtitles for translation''': where audio or video is originally in a non-English language, for example a Goethe poem, subtitles should generally be preferred over than translated audio, as this reflects the original more closely and text files are easier to correct than mistakes in audio-visual content. Where possible, songs should be subtitled. Original language versions should be made available where where possible for artistic content.
::* '''Translations of subtitles''' See ] for guidance. Note that longer subtitle sequences may need to be translated by Wikipedians rather than obtained from academic sources to avoid copyright infringement.
::* '''Embedding text''': As with images, rendered text should be avoided in video content. See ] for more information.
::* '''Public domain renditions''': if audio or video is a rendition of a public domain source, for example a work by Mozart, or a speech by Caesar, it must be possible to check the original scores or texts. An editor should be able to compare the performance with the original. Where possible, include links on media file pages so that editors can make checks.
::* '''Sourcing''': as with images, sourcing of audio-visual content needs to be copyright compliant. Sources of CC video and audio can include Youtube, Flickr and CC search tools. Care should be taken to ensure the licensing claims appear to be valid.
::* See also: ]


::] ] 23:32, 16 December 2024 (UTC)
{{rfc|style|rfcid=84E0F1F}}
:::This appears to be related to situations such as ], where a consisting of a person reading a letter aloud was included in an article, one example of a series of such edits. It is not clear to me that we need a bunch of guidelines about the best form for this sort of application because it is not clear that it is desirable to include such videos in the first place - the cart is being put before the horse. ] (]) 23:54, 16 December 2024 (UTC)
::::Yes, I certainly would like to clear up some of the misapprehensions that regretfully appeared in that discussion. It's a discussion I will deeply regret getting involved in for some time.
::::I'll be clear about the other discussions and examples of this content for context:
::::* ]; ] no debate and no questions occurred
::::* ]; no questions raised (I am the main editor for this page but plenty of people make edits)
::::* ]; ] as a link after discussion with editors
::::* ]; ] after discussion with editors
::::* ]; readings included; no discussion or objection
::::* ]; reading of his disputes with no objections raised
::::* ]; reading of his defence of Catholicism; posted and no objections raised
::::* ]; ]; no response yet
::::* ] and ]; early work added; an editor has asked me to check whether these are sufficiently relevant; I've agreed to do so and remove the videos if ] is not met.
::::@] I hope you can at least see that normally I try to be as collaborative as I can be. there's not much point going further into why that discussion became hard for me. However, policy is the place where we make guidelines to avoid disputes and lack of clarity.
::::What meets ] overrides any other consideration, to my mind so I have added that to the draft text. (''With audio and video just as with any content, relevance is paramount; consult ] for further context. There must be a clear reason for including the content on the page.'') ] ] 00:12, 17 December 2024 (UTC)
:::::As regards the other articles where there was no discussion, just because there was no dissent at the moment doesn't mean there wont be in the future. What happened at the Machiavelli article could just as easily happen in the other ones
:::::I am also asking you kindly to please stop making the issues with that RfC bigger than what they are. ] (]) 00:27, 17 December 2024 (UTC)
::::::We can take this discussion in two ways:
::::::* We can either construtively discuss the principles behind what video content should be allowable; or
::::::* We can decide that emotions are too high for it and pause it
::::::I do need this guidance, because there are divergences of opinion on some of the points, and it's important to me to be able to resolve them. But my guess is that if the three of us are just going to rehash the RFC discussion, then that would a terrible use of other people's time and energy. A break off would make sense, in my view. ] ] 00:41, 17 December 2024 (UTC)
:::::::No one's emotions are high but yours, judging by your rather relentless snipes against my character and the fact that you have so much as admitted it in the RfC. You have also stated that the RfC "needed to die" (quite strong words) when I gave you a chance to change your mind, and now you want to pause now that the discussion is nearing a close?
:::::::I do not get what you are trying to accomplish here, to be fair. ] (]) 00:47, 17 December 2024 (UTC)
:::::::It is not needed to rehash the RFC here, but I did feel that fresh eyes on this talk page should have enough context to understand what the proposal is about. ] (]) 00:48, 17 December 2024 (UTC)
::::::::Thanks, I appreciate that as a valid concern. Does the change regarding ] help, or do you feel more is needed? For context, other points raised in the RFC such as regarding the need to be able to validate translation is also included. ] ] 00:54, 17 December 2024 (UTC)
:::::I dropped the video from ]; it seemed like excessive detail. It's already on '']'' where it's a bit more appropriate. But even there, it seems like it violates the video equivalent of ]. Same for ] and ].
:::::I also posted that the video for ] should probably just be kept on Commons; there's already a general link to the topic there.
:::::I agree it's not clear that videos of performances of works should generally be included, so I would also be hesitant about specifying anything in particular about those. Uploaded videos cover a broad variety of subjects, including scientific phenomena, buildings, and specific events. -- ] (]) 03:22, 17 December 2024 (UTC)
::::::I would like to understand ] a bit more, especially regarding accessibility in particular, as this is certainly an overriding concern. What makes the text subtitle files inaccessible and not regarded as text? ] ] 09:09, 17 December 2024 (UTC)
:::::::Subtitles are, of course, text. They are less accessible than the text in an article because some readers will have technical or logistical difficulty watching video and thus reading subtitles or listening to audio narration. For readers that ''do'' watch a video (which presumably has an animation or something which illustrates the subject of the article in a way a still image cannot), it ''increases'' accessibility by allowing people who cannot hear or find it difficult to know what is being said or what sounds are happening in the video. -- ] (]) 15:37, 17 December 2024 (UTC)
:::] already says that for user-created diagrams, etc., a source for the underlying data must be included. To me, this applies straightforwardly to videos that are presenting public-domain content. A citation to the original work is kind of implied, but a reference to a specific version or even better an online copy, should suffice. YouTube videos that we're importing into Misplaced Pages as on-article videos are no different than diagrams or maps or explanatory videos uploaded by random Misplaced Pages or Commons users, assuming an appropriate copyright license. The reliability of YouTube is not really in question, any more than the reliability of any given Misplaced Pages editor is, when they are just repackaging information from a different underlying source in a more digestible way. That's different than citing a YouTube video as a reliable source for the information itself.
:::I'm not sure I have enough examples to make a guideline about video length. Ten minutes seems way too long for download on a mobile phone, and most videos I would expect to be under a minute. Perhaps there are exceptions, but I'd want to survey how videos are being used now. In the meantime, I would trim the 0.2 version down to reduce scope and reduce overlap with other pages and rephrase and retitle:
:::----
:::'''Video content (v. 0.3)'''
:::* The guidelines on this page also generally apply to videos.
:::* Many readers will not be able to play videos, because of technical limitations of their web browser, because they are seeing article content on a different web site or app, or because they are using a different medium, such as paper or text-to-speech system. Some readers cannot see or find it difficult. Videos should be used as a ''supplement'' to article material, to concisely illustrate the subject in a way that a still image or text cannot do. Videos should not replace article text, and articles should remain coherent and comprehensive when video playback is not available.
:::* Similar to ], for accessibility and file size reasons:
:::** Videos that simply show text should be replaced with text.
:::** Videos that simply show a sequence of still pictures should be replaced with an image gallery.
:::** Videos of text being read aloud should be replaced with text, or if the sound of words is being demonstrated, audio files (with the text being read in the file caption or in closed captioning).
:::** Videos of text and narration with should be converted to article text.
:::* The copyright and other guidelines on ] also apply to video samples.
:::* The policies on ] also generally apply to videos.
:::* Accessibility guidelines at ] apply.
:::----
:::-- ] (]) 03:56, 17 December 2024 (UTC)
::::] has additional suggestions; not sure if it's appropriate to link there from here. -- ] (]) 03:57, 17 December 2024 (UTC)
::::With your commentary, this makes a lot of sense. I would point out that there was a lot of heat generated over YT reliability in the aforementioned RFC, so it would be good to point that it can be used. YT is not mentioned as a source for images in the images section above; an alternative would be to add it there in the list of common sources, but that also seems odd. I know one can point to the archive discussion, but that is not generally available knowledge for anyone looking at the guidance in future. ] ] 09:14, 17 December 2024 (UTC)
:::::I added a clarifying note at ] for YouTube; hopefully this will not be controversial. -- ] (]) 02:44, 18 December 2024 (UTC)
::::::Unfortunately that has been . It might make more sense here, because this is about video as illustration, and there is ]. Perhaps it should be parallel advice to this, eg mentioning that YT has a search facility for CC content (and there isn't anything else AFAIK). ] ] 09:10, 18 December 2024 (UTC)
:::::::I started a discussion at ]. -- ] (]) 20:21, 18 December 2024 (UTC)
::::::::Thanks - quick observation that we have lost that the guidance for illustrative audio content would also generally derive from the images guidance. The music samples page linked is wholly focused on samples from copyrighted material; there is a lot of PD / CC music material on WP, especially for classical music. Sometimes this could do with subtitling, etc, care in positioning, checks for relevance, etc. ] ] 09:36, 19 December 2024 (UTC)
:::::::::OK, what are you suggesting? -- ] (]) 18:59, 19 December 2024 (UTC)
::::::::::I think, where appropriate, add audio, eg "The guidelines on this page also generally apply to videos and audio files"; maybe "where appropriate, for instance non-English language audio files should include subtitles". I'm not sure there is much else. ] ] 22:56, 19 December 2024 (UTC)
:::::::::::And where would you find that addition to be appropriate? -- ] (]) 02:37, 20 December 2024 (UTC)
::::::::::::I would amend the title to "Video and Audio content"; I would amend bullet one to "The guidelines on this page also generally apply to videos and audio files". Under "Similar to MOS:TEXTASIMAGES, for accessibility and file size reasons:" I would add "where appropriate, for instance non-English language audio files should include subtitles". The accessibility guidelines could move to be bullet two, in order that audio and video advice is at the top. ] ] 08:02, 20 December 2024 (UTC)
:::::::::::::It looks to me like hardly anything on ] applies to audio files, and it seems like the wrong place to go looking for style advice about them. -- ] (]) 22:52, 20 December 2024 (UTC)
::::::::::::::For example:
::::::::::::::* ]
::::::::::::::* ]
::::::::::::::* ]
::::::::::::::* ]
::::::::::::::* ]
::::::::::::::* ]
::::::::::::::* ] Uploading to commons, recording information about files, changes in editing and download size etc
::::::::::::::These seem pretty substantially helpful guidance to me, and pretty similar level of relevance as to video files. ] ] 09:10, 21 December 2024 (UTC)
:::::::::::::::Yeah, most of the material in those sections is not relevant to audio. I'd say if you feel strongly that guidance is needed for audio generally and not just music samples, we should create a new page. Editors shouldn't have to read through a whole page about images just to pick out the occasional tidbit on audio files, if they're only interested in the latter. -- ] (]) 20:32, 21 December 2024 (UTC)
::::::::::::::::I've posted the 0.3 draft for now, since that wouldn't be changed by adding an audio page somewhere else. -- ] (]) 20:46, 21 December 2024 (UTC)
::::::::::::::::Thanks for posting the v 0.3. On audio, I would think about this from a few user perspectives:
::::::::::::::::* There is currently no MOS advice at all on audio files and approaching general layout, pertinence, etc. What would the user do? Currently, MOS offers them nothing, so they must either guess or work off examples on other pages.
::::::::::::::::* If a user asks for advice, where would they be pointed? (my guess: ] as closest match.
::::::::::::::::IMO, it would be better to offer them something, even apologetically ("There is currently no detailed advice on MOS regarding use of audio files, but the basic principles of ] and some considerations at ] may be helpful.") This could be placed at a page relevant to other audio usage files, for example. ] ] 10:02, 22 December 2024 (UTC)
:::::::::::::::::Feel free to propose a draft if you like. It's also possible no particular guidance is needed, if people are able to figure this stuff out using common sense and regular editorial judgement, and if disputes arise, turn to the various policy and guideline pages on topics like due weight. -- ] (]) 21:56, 22 December 2024 (UTC)
:Given the small amount of material to include about this, and the redundancy that would be required with MOS:IMAGES if "MOS:VIDEOS" were its own page, and given the short nature of the audio samples MoS page, I think the most sensible approach is to merge all of this into a WP:Manual_of_Style/Images_and_multimedia page with a top MOS:MEDIA shortcut (which I'm surprised doesn't already exist as an internal disambiguation page), then MOS:IMAGES, etc., going to sections. We have too many separate MoS pages as it is, and this is an ideal merge of two of them and a proposed third. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 06:07, 23 December 2024 (UTC)
::Sure, that's a reasonable alternate approach. I think it would work if we put the things that apply across all three at the top, and then make it clear with section headers which those interested in a specific media type should look at without having to read inapplicable guidelines. -- ] (]) 08:22, 23 December 2024 (UTC)
::+1 to both of these observations. ] ] 09:04, 23 December 2024 (UTC)
::Yeps. If we hammer out a videos-related section, I'll be happy to do the work (most MoS merges and the like are done by me because I kind of have a database in my head of all the rules and how they interrelate, and 19 years of observing how misinterpretations, lawyering, and other problems can be avoided by careful wording. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 14:23, 23 December 2024 (UTC)
:::I think what we could agree on for videos has been added. -- ] (]) 00:27, 24 December 2024 (UTC)


== misleading text in ] ==
I propose copying NASA's style guidelines verbatim: "In general, all references to the space program should be non-gender-specific (e.g., human, piloted, unpiloted, robotic, as opposed to manned or unmanned). The exception to the rule is when referring to the Manned Spaceflight Center (also known as the Manned Spacecraft Center), the predecessor of Johnson Space Center in Houston, or to any other historical program name or official title that included “manned” (e.g., Associate Administrator for Manned Spaceflight)." '''<span style="background:#B1810B; padding:2px; border-style:solid; border-width:1px">]]</span>''' 19:15, 10 May 2019 (UTC)


The text on keyboard entry of dashes in {{slink|Misplaced Pages:Manual of Style|Dashes}} is misleading. The text {{tqq|or on a Windows keyboard }} implies a technique specific to windows when in fact it is valid for any OS. -- ] (]) 15:20, 18 December 2024 (UTC)
Previous discussions on the spaceflight WikiProject.
:True. What it should say: "on a Windows keyboard enter them manually as {{key press|Alt|0}} {{key press|1|5|0|chain=}} (on the numeric keypad) for en dash, and {{key press|Alt|0}} {{key press|1|5|1|chain=}} for em dash." -- ] (]) 16:02, 18 December 2024 (UTC)
::Wrong on two counts:
::# No. It should not say anything at all, per ].
::# And even if it does, those ]s are only valid for ] and related. They don't work if the user has a different default code page installed.
::Delete it completely. --] (]) 17:23, 18 December 2024 (UTC)
::::I doubt that NOTHOWTO is meant to apply to the MOS. It's surely helpful for editors and hence should stay, reworded if needed. ] (]) 08:26, 19 December 2024 (UTC)
:::::Gaewon is correct: NOTHOWTO applies to articles only. MOS is littered with how-to stuff, as is should where the ratio {{nobreak|<code>(editor confusion and time saved)/(])</code>}} seems sufficiently high. However, if this starts getting into weeds of code pages and such, it may be best to relegate the whole thing to ], with a pointer to that from MOS. ]] 20:28, 19 December 2024 (UTC)
::::::So why not simply recommend {{tl|mdash}}, {{tl|ndash}} and {{tl|snd}} rather than advise keyboard callisthenics? --] (]) 20:36, 19 December 2024 (UTC)
:::::::Yes, I have always advocated symbolic representations (templates such as you list, or html escapes such as &amp;mdash;) of the various dashes (and in some cases, even hyphens), rather than having them appear literally in the wikisource, so that editors can see at a glance that the right character is present. But even though ], I can't seem to get people on board with this. ]] 20:49, 19 December 2024 (UTC)
::::::::I am happy typing the dashes on my Apple keyboards but also happy with recommending the templates rather than giving keyboard-specific advice. What I would like to avoid is warring bands of gnomes going around changing unicode dashes to templated dashes and vice versa. —] (]) 21:31, 19 December 2024 (UTC)
::::::Edit conflict: yes, different route to the same answer. --] (]) 20:38, 19 December 2024 (UTC)
:::JMF's policy understanding {{em|is}} mistaken above. ] only applies to article content (and other reader-facing content, like portals and the front page features). If it applied to internal documentation, then we would have to delete the entire "Help:" namespace and about 95% what is in "Misplaced Pages:" namespace. However, the technical point JMF raised is entirely correct, and we should not be telling editors to use keyboard codes that will do the wrong thing (or nothing) if they don't happen to be using the "right" code page. To {{tq|1=simply recommend {{tl|mdash}}, {{tl|ndash}} and {{tl|snd}}}} is the sensible approach. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 06:02, 23 December 2024 (UTC)
::::Let's just direct people to ]. --] &#x1f339; (]) 23:00, 23 December 2024 (UTC)


== Is there a MOS guidance that applies to changing between common terms based on the name of the Wiki article? ==
*]
*]
*]


Do we have a guideline for dealing with different name, common names for the same thing (] vs ])? The target article, ], has used both names (changed in 2009 and 2022). Sources use both terms but I think the shorted "I4" is used more often in sources. I presume we would follow something like the MOS:ENGVAR where if there is no source preference we go with what the editors used first. Recently an editor, {{u|Kumboloi}}, made a number of good faith changes in linking articles from "inline-four" to "straight-four" to align external article text with the target article name. Is there a guide on this? How should this be handled? ] (]) 14:55, 22 December 2024 (UTC)
Recently, there have been edits back and forth changing manned to crewed (and vice versa), occasionally resulting in minor edit wars. It has been long enough since the last major discussion on this issue that we can have a fresh one. NASA's policy is to use crewed and uncrewed in lieu of manned and unmanned, except for historical usage (like ], ]).


:It's a policy, our ], which largely doubles as our policy on article titles. Generally, for a given thing there's no reason to use a different name in the prose of any other article than one would use in the article about the thing itself, if that makes sense.<span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 14:57, 22 December 2024 (UTC)
::I'm not sure where the naming convention says we should change article text in a case like this. The article in question indicates both names are common (''A straight-four engine (also referred to as an inline-four engine)''). This is also reflected in the two name changes over the years. I don't see where the naming convention says we should favor the target article name vs what the individual article sources are using. Consider a hypothetical, I'm created a Wiki article about the new "CarX". My RS source that says, "CarX uses an ''inline four engine''". Why would I not follow the source vs use the title of our straight four article? This is especially true if if the hyperlink is added later by a different editor. Also, until 2022 the title of the article was "inline". A consensus of 3 editors changed the article name. That's fine but the result is many changes to other articles. If a new consensus of 5 editors reverses the change do we flop back? I think it's less disruptive (makes articles more stable) if we avoid article text changes in cases like this. However, I am interested in knowing what guidance might apply here. ] (]) 15:52, 22 December 2024 (UTC)
::: I'm interested in understanding this. My motivation in making the edits came down to a suspicion that there was some type of penalty incurred by linking through a redirect page, or that the redirects imposed a maintenance overhead. I hadn't read the naming convention, but if there's no real reason to reduce the number of redirected links, and recognizing that the target page could just as easily be renamed again in the future, I'll stop doing these edits. (Personally, I prefer "inline" to "straight", but I can see how the renaming would help organize the associated pages.) Thanks. ] (]) 15:56, 22 December 2024 (UTC)
::::My reasoning is ] stresses how we are required to name things, as we are un all editorial decisions, based on WP:V and WP:NPOV (in many cases this boils down to the result of ]). It has provisions specific to the article title and not the body, but much of it is expressing how to apply V and NPOV in deciding what to call things.
::::If we take alternative names as such—e.g. that, all else being equal, we do take ''inline four'' and ''straight four'' to be synonyms, truly referring to the same thing for our purposes—it makes very little sense to "wall off" which names are used in a particular article, as there are no clear limits on how strictly this would have to be observed. Am I allowed to use any synonymous nouns, verbs, or adjectives in my synthesis that don't happen to appear in my three best sources? On the other hand, naming according to a generalized scope is surely more coherent for a hyperlinked encyclopedia providing tertiary analysis instead of merely refactoring and reshuffling the specific language of our secondary sources.
::::Of course exceptions abound, much of the time alternative names and redirects should be freely used according to syntactical and contextual concerns—but I believe this to be correct mindset to assume by default. I don't think any given article that uses ] needs to be changed. However, in cases like these, I feel it pays dividends to use terminology consistently between pages. If readers are encountering technical or domain specific language for the first time, we create the most helpful and coherent tertiary analysis for them if we zoom out a bit. It makes no sense to prefer '']'' to '']'' just because the book we're citing prefers the former—e.g., in an article about a specific battle, or a broad conceptual article not specific to the Sasanians—our deliberately preferring ''Sassanid'' simply does not aid the reader in becoming familiar with whatever additional context they're going to go to ] for in order to better understand our other article.
::::If I wake up and find this totally incoherent, I apologize. It's hard to speak clearly about naming and reference, though it's one of my favorite things to think about. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 16:49, 22 December 2024 (UTC)
::::] clearly says: "Piping links solely to avoid redirects is generally a time-wasting exercise that can actually be detrimental. It is almost never helpful to replace <syntaxhighlight lang="wikitext" inline>]</syntaxhighlight> with <syntaxhighlight lang="wikitext" inline>]</syntaxhighlight>." So if a link already leads to the correct article, but using an alternative name that redirects, that's ''absolutely fine'' and nothing more needs to be done. I realize that you're probably not talking about piping, but about changing the link text and link target together – but that too is unnecessary if the existing link target works fine (by redirecting). ] (]) 17:12, 22 December 2024 (UTC)
::::Kumboloi, thanks for that explanation. It reaffirms my believe that you were acting in good faith (I hope you took my revert that way as well). ] (]) 19:11, 22 December 2024 (UTC)
:I think there needs to be a good reason to not use the article title in text (and they do exist), and that can be discussed on a per-case basis at the relevant article (or other) talk page.—] (]) 17:19, 22 December 2024 (UTC)
::Agreed. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 17:21, 22 December 2024 (UTC)
:::Just so long as it is realized that THERE RATHER OFTEN IS A GOOD REASON! National language preferences for one thing. Busywork drive-by changes should be strongly discouraged. ] (]) 18:48, 22 December 2024 (UTC)
::::Goes without saying! <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 19:04, 22 December 2024 (UTC)
::::I just thought I'd drive by and agree with that. ]] 22:10, 22 December 2024 (UTC)
:The answer the the OP's question is "More or less ''yes''", in the form of ]. Remesense's idea above that article titles policy and its dependent naming-conventions guidelines and essays (which actually defer to MoS on style questions) somehow dictate in-article content. They absolutely do not, or we would simply merge them. However, agreement with the page title can actually qualify as a good reason for a text change under STYLEVAR a lot of time, such as when a old page title (and our mirroring of it in the text) was a misnomer, unhelpfully ambiguous, obsolete, or obscurantist. When such problems don't apply, then having more than one way to refer to the subject is a boon to editors and readers, since it allows us to write less repetitively. But the lead should almost always agree with the title, and start with the term/name in the title and secondarily provide any noteworthy alternative(s). Some exceptions of course apply, such as when a term/name in the title is a colloquialism and used for ] purposes in the title but is not the best way to introduce the first sentence (this is especially common at biographical articles, in which we often give the full "Elizabeth" or "Robert" name of someone more commonly called "Liz" or "Bobby" and given that way in the page title). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 03:28, 23 December 2024 (UTC)
::I think they must dictate in-article content to a degree at least—it would make no sense to use a particular name in the title and initial definition (I've been assuming congruence throughout, e.g. no disambiguators considered) and then never again. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 03:36, 23 December 2024 (UTC)
:::That's a correlation/causation mix-up. What you're talking about is just ] (to the point of "Don't be intentionally perverse as if with a goal of confusing readers as much as possible") and a matter of ]. It's not an element of title policy or of naming conventions, which do not address article content (except a few of the worst-written NC pages have a statement or two in them about body content that needs to move out of those pages; I've been cleaning those up as I run across them). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 14:18, 23 December 2024 (UTC)
::::I've been racking my brain trying to articulate exactly what I mean here, but I do not think it is <em>merely</em> correlative. Hopefully that is a useful thought inasmuch beyond just the trivial truth that the language one is exposed to affects the language they go on to use and think in terms of. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 19:32, 25 December 2024 (UTC)


== Legibility of thumbnails at default size ==
{{Moved discussion from|Misplaced Pages talk:Manual of Style/Images#Legibility of thumbnails at default size}}
]
]
I am surprised there is no direct statement along the lines of {{xt|If possible, the selection, placement, and sizing of images should allow readers to fully decipher what they are intended to illustrate; thumbnails should be legible with the default base size of 220px without requiring readers to expand them.}} It seems like much of the guidance has this as an unstated goal, but there are cases where it is slightly less intuitive that this is a principle that editors should heed. My one worry is hypothetical quibbling over what any given image is intended to illustrate—is the specific text written on a street sign important for illustrative purposes?—but I feel like that's totally explicable in each instance via editor discussion. It's clear that some appropriate images cannot be legible at thumbnail size in context, either because they are visually intricate or the placement context simply won't allow it, but it seems helpful to state that editors should make an attempt when it is possible. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 16:02, 21 December 2024 (UTC)
:{{ping|Remsense}} Can you give an example? ] (]) 16:39, 21 December 2024 (UTC)
::Clicked around until I found one: at ], it's not really possible for me to discern the field of figures as men sitting at desks rather than just noise. This image should be displayed at a slightly larger size, and maybe cropped a bit.
::Another class of examples is insignia and coats of arms, where arguably key details that would be legible in the original contexts are illegible at thumbnail sizes in infoboxes, especially in cases where there are especially elaborate versions that editors sometimes opt for out of a misplaced sense of completeness (I guess). <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 17:03, 21 December 2024 (UTC)
:::]
:::]
:::They're everywhere. ] (]) 21:23, 21 December 2024 (UTC)
::::That is something that gives me pause: this seems like a common-sense guideline to me, but either it's so obvious that it shouldn't be a guideline (?) or it's not nearly as obvious to others. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 21:48, 21 December 2024 (UTC)
:::::I've always found it odd that we don't have a minimum size recommendation. Can't tell you how many times I see collages or galleries that have teeny mini images that lack accessibility for all. <span style="font-weight:bold;color:darkblue">]</span>🍁 03:49, 22 December 2024 (UTC)
::::::It's a perfectly reasonable thing to do to print articles out (or otherwise have them in a format where the thumbnails are all you get), also. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 03:51, 22 December 2024 (UTC)
::::::I do worry my criterion above is too loosey-goosey to be a good guideline; I don't think there's a problem with speaking in terms of minimum size as such, maybe it's better getting the intended point across? <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 03:55, 22 December 2024 (UTC)
:::::::Definitely better getting the intended point across. If we try to impose a numeric min. size, people are going to argue about it until the end of fargin' time, based on the behavior of their preferred devices and browsers, and so on. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 03:17, 23 December 2024 (UTC); rev'd. 13:39, 23 December 2024 (UTC)
::::::::What do you think about the potential phrasing first presented—i.e. {{xt|if at all possible, what images are being used to illustrate should be fully legible when scaled according to the default base size}} <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 03:23, 23 December 2024 (UTC)
:::::::::Lots of unnecessary words. {{xt|When possible, images with text should be legible when ...}} I'm not sure what "according to" the default base size means. Is it really the {{em|default}} base size? Are more than handful of editors reading this going to understand what "base size" means? I thinking there must be a clearer way to get the point across, but the goal seems right. (Speaking of "getting the intended point across": ironically, my previous message had an extraneous word, "than", in it – in a position that reversed or at least badly confused my meaning, so I've removed it.) <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 13:39, 23 December 2024 (UTC)
::::::::::I'm not sure how to phrase it. It's not just images with text either, it's all images that are added but cannot actually be deciphered without expansion. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 04:40, 24 December 2024 (UTC)


== Commas around incorporated businesses' names ==
'''Issue'''


from looking at ], there isn't any guidance on how to deal with names with '']''. multiple articles do any of the following, either with no comma, a comma only before and a comma around the word.
Editors are interpreting ] differently, clarification is needed.


# {{xt|Mumumu Inc. is a company ...}}
'''Support/Oppose/Comments'''
# {{xt|Mumumu, Inc. is a company ...}}
# {{xt|Mumumu, Inc., is a company ...}}


I am aware that the commaless and comma style may coexist (sometimes in the same article!), however the second and third styles should likely be decided upon. ] (]) 01:09, 26 December 2024 (UTC)
*'''Support''' - while we do not have to follow NASA's style guide, I think it is well-written, logical, and easy to interpret. '''<span style="background:#B1810B; padding:2px; border-style:solid; border-width:1px">]]</span>''' 05:31, 10 May 2019 (UTC)
*Oh boy, oh boy, oh boy, oh boy, oh boy! I ''cannot wait'' for someone to say that ''Inc.'' is an "appositive", and therefore the commas have to come in pairs. ]] 01:20, 26 December 2024 (UTC)
*'''Support'''. This should be a simple, clear application of the first sentence of ], {{tq|Use gender-neutral language where this can be done with clarity and precision.}} The fact that this is NASA's policy should also be given significant weight, as this is the topic area NASA falls under. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288;]&nbsp;''<sup>(])</sup>&nbsp;'''''│''''' 05:51, 10 May 2019 (UTC)''</span>
*:Is that the cool way of saying that you don't think it is one? ] (]) 06:46, 26 December 2024 (UTC)
*'''Oppose''' broad changes per ] and ]. The terms are not always equivalent in meaning to the proposed alternatives, and so it fails the {{tq|clarity and precision}} clause in MOS:GNL. Usage of terms should be accurately aligned with whatever supporting sources exist per ]. We should explain that the various terms exist, and use them in the proper, sourced context. There is nothing inherently "gendered" about the term "manned", and . -- ] ] 06:28, 10 May 2019 (UTC)
*There is a lengthy discussion at ]. --] &#x1F98C; (]) 09:42, 26 December 2024 (UTC)
*'''Support''': I see no reason not to follow NASA's and ]'s guidance here. Regarding ]: Sticking to sources does not mean sticking to the exact word choices of sources: {{tq|Rewriting source material in your own words, while substantially retaining the meaning of the references, is not considered to be original research.}} ] (]) 07:08, 10 May 2019 (UTC)
*:@] thank you so much for your link and oh dear it really is long. ] (]) 13:56, 26 December 2024 (UTC)
*'''Support principle''', though this seems redundant to the existing advice in ]. Perhaps this RfC will provide sufficient clarification, such that no additions to the MoS will be necessary. NASA has prescribed gender-neutral language since at least 2006 (). {{U|Netoholic}} I'm puzzled as to how ] is relevant. ]<sup>(]•])</sup> 07:48, 10 May 2019 (UTC)
*'''Support''' I agree that this is redundant with ], which is fairly clear on this, but some people need the extra reminders. --]] 12:09, 10 May 2019 (UTC)
*'''Support''' What Jayron32 and Adrian J. Hunter said. I don't understand Netoholic's objections here. Also, while it's true that "she manned" is not unheard of, it's always been less common than "she piloted". Furthermore, if you swap in the male pronouns, you'll see that "he piloted" is also more prevalent: . ] ] 12:20, 10 May 2019 (UTC)
*: {{ping|Mackensen}} No direct comparison works because the terms mean different things, which is my point. To "pilot" means to assume direct control over the movement of a craft. To "crew" means to perform one of many roles associated with operating the craft. To "man" a craft could mean any of the above, or simply sitting within a craft and being largely a passenger, as was especially true with the early missions. Likewise, one can "man" many other things that cannot be crewed or piloted - think of the phrase: ''she 'manned' the front desk of the store''. This guidance will confuse people and cause them to use terms not supported by the sources. -- ] ] 14:29, 10 May 2019 (UTC)
*:: Sure, and I considered that. "Staffed" would be the direct replacement for "manned" in your hypothetical, though it's not applicable in this use case. The potential for confusion seems minimal, at best. Sidebar: while pilot involvement in the Mercury and Gemini missions was perhaps minimal compared to later missions, the pilots themselves were adamant that they were ''pilots'' who were ''piloting'' those spacecraft. You don't need "manned" to express any of these concepts. ] ] 14:35, 10 May 2019 (UTC)
*::: No, but you need to use whatever the secondary sources use as they are the ones that analyze what those men said, what NASA said, and what the general public expects from their language - hence ] policy. -- ] ] 14:38, 10 May 2019 (UTC)
*::::Misplaced Pages articles are not just giant quotes. WP:STICKTOSOURCE does not say we are required to only directly quote sources. The use of paraphase, synonyms, summarization, and rewriting in Misplaced Pages's own style and voice is expected and encouraged. --]] 14:41, 10 May 2019 (UTC)
*::::: These are not synonyms we're talking about. You are advocating for the changing of ''meaning'' without understanding the context of the terms in use. I have absolutely no problem with "crewed" - if that is was a source uses. But at present . -- ] ] 14:48, 10 May 2019 (UTC)
*::::::We have several clearly useful alternatives to "manned", and those alternatives are not confusing to native English speakers. Your insistance, over and over, that WP:STICKTOSOURCE means we must stick to the exact word that the source uses in all cases is not borne out in any other situation anywhere else on Misplaced Pages, and it feels like you are reaching to somehow use your own idiosyncratic understanding of a policy page as a means to invalidate a consensus, or to somehow innoculate against a developing consensus so that you can claim that "the one single policy I have cherry picked here to interpret in my own way to defend my position must be the only valid policy that applies AND the only valid interpretation of that policy" That's not how any of this works. You don't get to pick one "magic spell" policy that trumps all others, you don't get to invalidate the perspectives of other that don't agree with you ''merely because'' they don't agree with you, and you don't "win" in the face of a developing consensus merely because you repeat the same points over and over or refute everyone with the same thing over and over. You don't get extra "consensus points" by doing that. --]] 15:08, 10 May 2019 (UTC)
*'''Support''' It's a sensible clarification in line with ]. ] (]) 14:12, 10 May 2019 (UTC)
*'''Oppose'''. "Manned" {{em|is}} gender-neutral. &ndash;]&nbsp;(]&nbsp;&bull;&nbsp;]) 14:28, 10 May 2019 (UTC)
*:Asserting so doesn't mean it is so. ] disagrees with you. Where can I read, elsewhere, that your assertion has evidence to back it up? --]] 14:37, 10 May 2019 (UTC)
*::How is ]'s assertion any more valid than mine? See ]. &ndash;]&nbsp;(]&nbsp;&bull;&nbsp;]) 15:13, 10 May 2019 (UTC)
*:::] specifically notes many instances of avoiding the use of "man". You ''assert'' that it doesn't, and yet reading the article clearly shows it doing so. The actual evidence goes against your assertion. Also, see ]. We use words as they are used now, not as they were used at some point in the past. Today, sources consider "man" to be gendered as male. The fact that speakers in the past didn't used to has little to no bearing on the discussion. Lots of words meant different things in the past. We use words today as they are used today. --]] 15:19, 10 May 2019 (UTC)
*::::I'm not arguing based on etymology; that was merely the section link. I'm arguing based on the usage in that section. But GNL is incorrect in stating that "crewed" should be used instead of "manned". Should we say "Crew the machine guns!" rather than "Man the machine guns!"? &ndash;]&nbsp;(]&nbsp;&bull;&nbsp;]) 15:21, 10 May 2019 (UTC)
*:::::When would one ''ever'' write either the phrase "Crew the machine guns!" or "Man the machine guns!" in a Misplaced Pages article? That phrase should never appear, except as a direct quote. Under normal encyclopedic style, I can't see any reason to present a second-person command with an exclamation point. --]] 15:29, 10 May 2019 (UTC)
*::::::It was just an example to point out the fact that in this sense, it's not a gendered word any more than "history" is.
*:::::::What? I don't even know what you mean by that. Look, lets just sit back and watch consensus develop one way or the other here. Your arguments are becoming increasingly incomprehensible here, and ultimately I have wasted everyone's time by humoring you. You have voted. I have voted. Other people will vote. This ''entire'' side discussion has done, and will do, nothing towards generating a consensus. --]] 15:42, 10 May 2019 (UTC)
*::::::::I would have thought the reference was obvious in this context: "history" contrasted with *"herstory". —DIV (] (]) 02:27, 11 May 2019 (UTC))
*::::Also note that line in GNL was added just today; I've reverted the edit, and now GNL says nothing about "manned". &ndash;]&nbsp;(]&nbsp;&bull;&nbsp;]) 15:25, 10 May 2019 (UTC)
*::::: I never said ] used the example "manned". I said it contained information about avoiding "man" in situations analogous to this. --]] 15:28, 10 May 2019 (UTC)
*::::::In any case, to "man" a craft is not the same usage as using "man" as a suffix for occupational titles. And the article there is about documenting certain efforts and viewpoints; it does {{em|not}} provide advice on what should be done. &ndash;]&nbsp;(]&nbsp;&bull;&nbsp;]) 15:38, 10 May 2019 (UTC)
::::::::It's not the same, but do indicate that this usage of "manned" is gendered, and that's the category of language that ] applies to. ]<sup> ]</sup> 15:50, 10 May 2019 (UTC)
::::I hope you realize using the phrase "etymological fallacy" is, in itself, offensive and derogatory. You are trying to dismiss an idea you dislike by slapping a biases label on it. In fact, "manned" spaceflight is a term in common use. It is less universally used than it was a few decades ago, but it is still widely used. We are talking about which of the ''currently'' used terms is more appropriate. ] (]) 18:44, 11 May 2019 (UTC)
*'''Support''' If it works for NASA it will probably work quite adequately for us too. &middot; &middot; &middot; ] ]: 14:53, 10 May 2019 (UTC)
*'''Support''' - sensible direction. Evidently the advice of ] is not sufficient to prevent edit-warring in this topic, so it is necessary to explicitly adopt this style. ] (<sup>]</sup>/<sub>]</sub>) 15:18, 10 May 2019 (UTC)
*'''Support''' Consistent with existing ] guidance. If there's a specific use-case where "manned" has no English equivalent, then we can say it, but I sort of struggle to imagine a scenario where that's the case. This seems like an odd hill to die on. ]<sup> ]</sup> 15:40, 10 May 2019 (UTC)
* '''<s>Oppose</s>Support changing project pages''' Unless I am misinterpreting the intent here, the wording of MOS:GNL is sufficient. "Manned" is acceptable in established proper names. We can't include every organization's policy on gender-neutral language in the MOS. ] (]) 15:46, 10 May 2019 (UTC)
*:You'll note that the proposal includes a specific exemption for established proper names, and is not proposing changing those. --]] 15:49, 10 May 2019 (UTC)
*::We shouldn't need to say anything about terms in proper names. It should be clear that they are exempt. ] (]) 16:03, 10 May 2019 (UTC)
*:::That isn't the crux of the proposal though. The proposal is here because there is some clarification needed over the use of the terms "manned" and "unmanned" outside of proper noun situations. Some people feel those terms are gender neutral, or are otherwise not covered by MOS:GNL. This is specifically about adding clarifying language that such terms are covered by MOS:GNL and should be avoided here. When you stated "Unless I am misinterpreting the intent" it is clear you are. The purpose of the proposal is not to carve out the exceptions for proper names, it is to include language to explicitly note that "manned" is not gender-neutral. --]] 16:08, 10 May 2019 (UTC)
*::::]: I think a lot of the support !voters are agreeing with you that ] already covers this. When you say "oppose" are you saying you believe that "manned" should still be used even in cases where it is not part of a direct quote or a proper title? Or are you just saying you oppose changing the wording of GNL? (similar to Izno's !vote below) ]<sup> ]</sup> 16:18, 10 May 2019 (UTC)
*:::::Thanks. I am opposed to copying the NASA guideline verbatim into the MOS. I still don't understand what specific change to the MOS is being suggested and where. ] (]) 16:28, 10 May 2019 (UTC)
*::::::Thank you for your clarification. I understand what you're opposition is based on now. --]] 16:36, 10 May 2019 (UTC)
*'''Support''' Where there's a clearly supported gender neutral term, we should use it as per MOS:GNL. "Manned" may or may not once have been viewed as gender neutral, but language changes, and it isn't now, as NASA indicates. ] (]) 15:57, 10 May 2019 (UTC)
* '''Support principle''', '''oppose changing the main MOS page''' per the apparent duplication of intent. --] (]) 16:02, 10 May 2019 (UTC)
**Unless I'm misunderstanding, I don't think the nominator is proposing changing any guideline pages. That is, I read the question to be: "Should we make this change at various spaceflight pages?" not "Should we add this language to the MOS?" ] (]) 16:24, 10 May 2019 (UTC)
**:{{tq|I propose copying NASA's style guidelines verbatim}} I interpreted copying here to mean publishing a MOS which uses the text of NASA's guideline, i.e., as a MOS change. You could reasonably interpret the word copy to mean "use their guideline without changing ours", but again, not what I did. I think my interpretation is more reasonably. ;) --] (]) 16:39, 10 May 2019 (UTC)
**:::What misled me was that it was unclear where the cited NASA guideline would land, and I assumed it was the MOS. ] (]) 17:27, 10 May 2019 (UTC)
**::I want to have a clear interpretation of the Manual of Style that can be pointed to in future discussions that will hopefully end the edit wars. I thought perhaps a note like the Milhist one could be added, but whether it is or not I do not care. '''<span style="background:#B1810B; padding:2px; border-style:solid; border-width:1px">]]</span>''' 16:50, 10 May 2019 (UTC)
*'''Support''' NASA gets it right. ] (]) 16:08, 10 May 2019 (UTC)
*'''Support''' This sounds very sensible. Thanks. ] (]) 16:13, 10 May 2019 (UTC)
*'''Support''' I agree with NASA's convention here and I think Misplaced Pages should adopt it. ] <sub>]</sub> 16:22, 10 May 2019 (UTC)
*'''Support''' mostly per ]. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 16:23, 10 May 2019 (UTC)
*'''Support.''' If we do copy though, quote marks and cite, perhaps with intro: Misplaced Pages has adopted the following guidance: ] (]) 16:53, 10 May 2019 (UTC)
*'''Oppose without modification''' NASA is not the only space agency around, and they have not always used this standard. I think it would be confusing to have an article on, for example, the Russian space program with quotes about "manned" missions and text about "crewed" missions. The same thing would apply to historical NASA missions, such as Mercury or Apollo. If the original sources used the term "manned" the article should as well. I think that's consistent with Misplaced Pages guidelines on gender-neutral language, since being consistent would improve clarity. ] (]) 22:07, 10 May 2019 (UTC)
*:It is a good point that NASA is not the only space agency around. However the issue of 'mismatch' between quotations and surrounding article text is not a problem. Consider an article ], for example: there may be quotations in Latin, but that doesn't conflict with the article being written in English. There can be an article on ] that includes pejorative terms for specific people or groups of people within quotations, but which avoids those pejorative terms within the surrounding article text. —DIV (] (]) 02:44, 11 May 2019 (UTC))
* '''Support'''—Misplaced Pages should always strive for inclusive language where reasonable. ]&nbsp;<span style="color: Red;">🍁</span>&nbsp;] 22:22, 10 May 2019 (UTC)
*'''Support''' It's the right thing to do and the NASA policy means we have a good precedent to follow. The exception for historical terms is adequate. —] (]) 22:35, 10 May 2019 (UTC)
*'''Comment'''. It is not clear that "manned" is necessarily interpreted as a gendered verb. As evidence I propose the following scenario.<br> NASA sends an "unmanned shuttle" to the moon. When it lands the crew get out and perform a ].<br> I believe that everybody would interpret "unmanned" as a synonym of "uncrewed", and that nobody would leave open the option that an "unmanned shuttle" might have a crew who are all women (or perhaps even transgendered, intersex, ''etc.''). <br>Logically if "unmanned" is unambiguously a non-gendered synonym of "uncrewed", then "manned" ''should'' unambiguously be a non-gendered synonym of "crewed". Of course, logic might be lacking in reality....<br> —DIV (] (]) 02:36, 11 May 2019 (UTC))
:::The simple response is that "reliable sources say it is gendered". That said: means "to castrate". So it definitely is not an unambiguously non-gendered term. uses the term "'unmanned' singer" to refer to a ] vocalist. the "unmanned" to indicate Juliet's virginity and her lack of self-control. "Manned" is often use to refer to male and female crew members, but that doesn't make it genderless. It's like the term "mankind" in that sense. ]<sup> ]</sup> 21:00, 11 May 2019 (UTC)
::::I don't think it is sufficient to say a single source considers a word gendered. I think it takes evidence that a majority of people, or at least a large majority, consider it to be when used in the relevant context. In you examples of "manned" being used as a gendered word, they are (1) rather archaic usage, which I believe few modern speakers of English would use, and (2) using the word in a dramatically different context. Are you implying that, if a word is gendered, then all of its homonym are also gendered? That does not make sense to me. ] (]) 21:28, 11 May 2019 (UTC)
:::::My point was that can't exactly call a word "unambiguously genderless" when one of its dictionary definitions literally refers to removing someone's testicles. It's not just a single source. , , as well as the and style Guides all note the gendered connotation. We don't have any source for polling the majority of English speakers, and the whole issue is that terms like "manned" or "mankind" are implicitly gendered even when the speaker doesn't intend them that way. Our informal poll of Misplaced Pages editors shows a pretty clear consensus in favor of avoiding the term. ]<sup> ]</sup> 22:31, 11 May 2019 (UTC)
::::::It's hard to call anything about languages unambiguous. But if there are two completely unrelated dictionary definitions for a word, they are different words. Just because they are spelled the same way doesn't mean one is automatically a gendered word because the other clearly is. If I accepted that logic, I'd also have to agree an aircraft is a geometric construct, since those are both definitions of "plane". ] (]) 19:02, 12 May 2019 (UTC)
::::::What a novel theory: "if there are two completely unrelated dictionary definitions for a word, they are different words". Did you make that up, or find it somewhere in a discussion of what makes a word? And are you also suggesting that some uses of "manned" and "unmanned" are ''not'' related by referring to the root "man"? ] (]) 21:54, 12 May 2019 (UTC)


== An editing policy question ==
* '''Comment''' We might consider preserving the cited NASA guideline text and parts of this discussion in the article ]. ] (]) 03:43, 11 May 2019 (UTC)
* '''Support''' 'Man' and 'manned' are not gender neutral words as acknowledged by NASA and most modern style guidlines. Many of the opposes use logic along the lines of "well it's gender neutral to me" or "that's what was written in the source". The first argument is irrelevant, what matters is the gender neutrality to most english speakers. The second is inappropriate in this context, we do not use Shakespearian language to discuss the works of William Shakespeare, even if that is how they were originally written. --] (]) 11:50, 11 May 2019 (UTC)
:In fact, we may use Elizabethan words in discussing Shakespeare's works. Specifically if the work contains a word which is no longer in common use. It would cause confusion to quote the text and then substitute the modern, equivalent word in a discussion of the text's meaning.] (]) 18:44, 11 May 2019 (UTC)
*'''Support the point being added in our own wording, but not plagiarized.''' We do not rip off language, word-for-word, from other style guides. We certainly {{em|should}} give the same advice (reworded), because it is sensible and is consistent with ]. We should maybe omit "manned" as an example of gendered language, since there's obviously dispute about whether it qualifies. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 11:58, 11 May 2019 (UTC)
*: {{ping|SMcCandlish}} Since it's published by NASA, surely it's {{tl|PD-NASA}}? Thanks. ] (]) 19:17, 11 May 2019 (UTC)
*::Whether you can be prosecuted for stealing it has nothing to do with the principle of not just ripping it off. Beyond this obvious point, we do not want to set a precedent for directly quoting other style guides in our own. Our wording changes all the time to better suit our needs and the ability of our editorial pool to interpret and follow the rules as written and applied. Virtually nothing in MoS reads exactly as it did the first time it was written, because we cannot predict in advance what someone is going to try to ] a month or a year later, nor what adjustments have to be made to account for later changes to other ] pages. Another reason to not rip off other style manuals to the letter is that we can usually make the same effective rule more concisely, having had a lot of practice keeping our rules short for ] reasons. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 23:34, 11 May 2019 (UTC)
*'''Support''' per ]. ] <small><sup>]</sup></small> 22:43, 11 May 2019 (UTC)
*'''Oppose''' "copying NASA's style guidelines verbatim", but '''support''' the gist of the proposal, adopting guidance along those lines. ] (]) 21:57, 12 May 2019 (UTC)


When I read Wiki policy and guidance pages, I sometimes find ''shall'' used instead of ''will'' to indicate what must be done ''—'' for example, in the ] article, we find: "The more signs that are present, the more likely sockpuppetry is occurring, though no accusations '''shall''' be made unless, beyond a reasonable doubt, one is really certain."
== Use of ∞ (infinity) symbol for marriage in genealogy ==


Granted that ''shall'' is often used this way in government and judicial documents, I think it sounds somewhat at odds with the more user-friendly ambience Misplaced Pages has tried to create for editors. Besides, ''shall'' is not consistently applied throughout the policy and guidance pages ''—'' for example, in the same ] article, we find: ''"''The closing administrator '''will''' be required to follow the consensus, even if they personally disagree.''"''
At ], ∞ (infinity; U+221E) is used many times. I worked out that it means "marriage". This seems analogous to using * for "born" and † for "died" (disallowed at ]). Should these be replaced with "m." (and a note about it added to MoS, since there are many more articles in which it appears)?
:The ∞ is an improper substitute for the character ⚭ (U+26AD, "Marriage Symbol"). I agree with replacing it with ''m.'' (parallel with ''b.'' and ''d.''). ] (]) 11:42, 10 May 2019 (UTC)
::I'd be in favor of converting all of these to "m." or "married". Non-keyboard symbols should be used sparingly, and in cases where a perfectly acceptable letter exists, I'd go with that. --]] 12:08, 10 May 2019 (UTC)
:::The "Marriage Symbol" is two interlocking circles, for those who use a small text or an old screen! ] (]) 12:16, 10 May 2019 (UTC)
::::The marriage symbol is too small for me to make it out at my preferred text size and is anyway unfamiliar, so I would be quite happy to see it deprecated. Use of the infinity symbol as a substitute is even worse. "m." or "married" is clearer to me, and possibly to the majority of readers, which should be the main concern. &middot; &middot; &middot; ] ]: 14:58, 10 May 2019 (UTC)
::::: changed "m." to the infinity symbol. So it was that way at one time. ] (]) 22:36, 10 May 2019 (UTC)
There's also a line that is followed by "<Mass Town Birth Records></Virginia Marriage Records>", which also seems like a bad idea. Should they be turned into a reference, assuming it means those are sources. Any idea what the "/" is for? <span style="color:red">—](])<span style="color:red">]—</span> 11:02, 10 May 2019 (UTC)
:Reads as bad closing tags and just a misunderstanding of markup. ] <sup><small>]</small></sup> 18:49, 10 May 2019 (UTC)
:Appears to be a remnant of XML tagging in one of the sources. I see no reason to retain it. ] (]) 20:52, 10 May 2019 (UTC)
:It looks like it was added by {{Ping|DACC23}}. Maybe they have a good reason for why it's there? ] (]) 21:47, 10 May 2019 (UTC)
::I use the ∞ symbol often because I've seen it used in many other family trees and think its cleaner (and shorter) than the other options, but am happy to use {{kbd|m.}} or {{abbr|''m.''|married}} if that is what is preferred overall. 13:30, 11 May 2019 (UTC)
:::{{reply to|DACC23}} The question here was the tags. I have commented these out. ] (]) 13:56, 11 May 2019 (UTC)
:I think all of these should be spelled out per ]. Certainly the symbols are right out. —] (]) 22:36, 10 May 2019 (UTC)
I also support removing these symbols, and further suggest making use of ] for a result of {{abbr|''m.''|married}} <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288;]&nbsp;''<sup>(])</sup>&nbsp;'''''│''''' 04:20, 11 May 2019 (UTC)''</span>
:Definitely replace it. Even genealogists don't use that symbol (they typically use {{kbd|m.}} in running text or {{kbd|1={{=}}}} in a pedigree chart, since {{kbd|⚭}} is obscure and not found on anyone's keyboard). If we're going to use any abbreviation or symbol, it should be within ] guidelines (don't abbreviate without a good reason, like a cramped table in which horizontal space is at a premium, and either link to the meaning or use {{tlx|abbr}}, at first occurrence of any abbreviation). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 12:05, 11 May 2019 (UTC)
::I did the replace. Hopefully got it right. And hopefully anyone there who might care was already aware of this discussion and saw the error. ] (]) 02:29, 12 May 2019 (UTC)


— For the above reasons, wouldn't it be in Misplaced Pages's best interests to avoid using the conversationally archaic ''shall'' in these articles and replace it with ''will?''? I doubt that this would make editors with wrongdoing on their minds less likely to behave as desired.
*In this modern age it's amusing to see the symbol for "never-ending" being used to represent marriage; perhaps someone's idea of a joke. ]] 05:02, 12 May 2019 (UTC)
*: Sometimes it can seem that way. &middot; &middot; &middot; ] ]: 19:14, 12 May 2019 (UTC)


— But if the decision is made to continue "shalling," then for the sake of consistency couldn't a search-and-replace be done throughout the policy and guidance articles to replace ''will'' with ''shall'' where the word needs to indicate what must be done? ] (]) 16:53, 28 December 2024 (UTC)
== Ligatures ==


:It's fine, really. This is one of those things the MOS exists to obliquely neutralize—i.e. this is a pretty conjectural position and not worth getting into all-in or all-out discussions over. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 17:16, 28 December 2024 (UTC)
The (short) section on Ligatures in the MoS is much too hardline. While I respect/tolerate the 'house style' to avoid using ligatures when they are optional, it seems to leave no room even to ''mention'' alternative forms.
::“Obliquely neutralize” — there’s a new one for me! 😅
::I just thought it would help lighten the bureaucratic tone of these articles to dial down the legalese, as many editors feel increasingly on edge with all the rules and regulations they discover the more they wade into Misplaced Pages. ] (]) 17:31, 28 December 2024 (UTC)
:::Genuinely, I apologize that I can't talk normal when the situation would benefit from it. Take that how you will. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 17:32, 28 December 2024 (UTC)
::::Or shall. ]] 17:39, 28 December 2024 (UTC)
:::::😂 ] (]) 07:44, 30 December 2024 (UTC)
:::::{{small|Am losing the ] here, mate. ] (]) 12:34, 31 December 2024 (UTC)}}


:::Just be aware that you’ve entered the purview of a global encyclopedia, and that means you will encounter forms of English that aren’t necessarily common locally to wherever you live. ] (]) 17:57, 28 December 2024 (UTC)
For example, in the ] article we have the ridiculous situation of claiming
::::Is this one of those ] situations where we should stick to a limited number of ]s on a sliding scale (must > should > may)? --] &#x1F98C; (]) 18:42, 28 December 2024 (UTC)
:"<small>The plural of ''formula'' is spelt ''formulae'' (from the ]).<ref name="oxford">{{OED|formula}}</ref></small>"
::::@], Although I’m aware of different styles of English in different parts of the world, the ''shall/will'' issue I’ve raised here is more about how Misplaced Pages wants to show officially expected actions in particular situations.
Whereas actually the OED states (verbatim):
::::Not like , “Today I shall go to the beach” … but like, “Administrators shall hold discussions on the matter for one week before reaching a decision.” ] (]) 12:10, 30 December 2024 (UTC)
:"<small>Forms: Plural formulæ, formulas.</small>"
:::::Nevertheless, ‘shall’ is still reasonably common usage in formal, official or legal written texts, in the UK, in a way that I don’t think you can say for the US (but willing to be corrected…), and is not considered particularly user-unfriendly. Your observation to the contrary above is therefore pitched from the perspective of a particular Engvar, which was my original point. ] (]) 15:16, 30 December 2024 (UTC)
in which the ligature is specifically and deliberately used. The OED distinguishes three distinct spellings: "ae", "æ", and "e". <small>(Compare with {{OED|haematology}}, which is listed with the "ae" spelling, and the "e" spelling is given as an alternative form — but not the "æ" spelling. Yet within the definitions the ligature is carefully used to cite quotations from the publication ''Hæmatology''.)</small> So the WP article on ] is ''misquoting'' the OED article, possibly due to the excessively constrictive guidance in the MoS.
::::::@], you're probably right about "how official" ''shall'' sounds to UK and US readers of official documents. And frankly, that word is still used from time to time in official documents in the US, even though much more rarely these days''.'' Even so, here's a thought: if ''will'' would work equally well as ''shall'' in Misplaced Pages policy and guidance documents, why not use it consistently here so as to make "official stuff" sound a bit less bureaucratic but at the same time affirming of expected behavior?
::::::Though I'm American, I doubt that any of our UK cousins across the pond would feel affronted if Misplaced Pages consciously adopted ''will'' in its policy and guidelines. Wouldn't it simply be one more example of Misplaced Pages's intentions of providing as welcoming and user-friendly environment as possible in which to work, while in no way demeaning other varieties of writing?
::::::Alternatively, to avoid the whole ''shall/will'' issue, there are still other ways wording could be done. For example, instead of "Administrators shall hold discussions...,” we could say, "Administrators are to hold discussions ....” ] (]) 11:04, 31 December 2024 (UTC)
::::::::More rules about how rules should be written could be one step forward, two steps back. ]] 12:28, 31 December 2024 (UTC)
:::::::Onbiously, you're free to edit how you want, but as a general rule, surely it isn't WP's object, nor that of the MoS, to try and enforce general language preferences on our editors? ] (]) 11:41, 31 December 2024 (UTC)
:::::::: You state the onbious. ]] 12:28, 31 December 2024 (UTC)
::::::::Well, @], I think it’s time for me to gracefully bow out of the discussion now. My only Intent in making my suggestion was far from an attempt to ''enforce,'' though I see how it might be interpreted that way''.''
::::::::Instead, I was trying to make a case for a slight change in wording that seemed to me could help Misplaced Pages accomplish its very positive goal of creating an open, light, friendly ambience — just as seniors helping in the Teahouse and elsewhere are asked to do with those who ask questions. I know that as some editors get involved with Misplaced Pages, they come to feel weighed down by many rules and regulations and even become fearful they might make a slip and face serious consequences.
::::::::It was this I hoped my suggestion might help prevent in the long run, with the flip-side benefit of editor retention. ] (]) 12:37, 31 December 2024 (UTC)


==Discussion at ] (redux) ==
The MoS entry should be extended to state something like:<br>
]&nbsp;You are invited to join the discussion at ]. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 21:13, 29 December 2024 (UTC)<!-- ] -->
"'''Additionally, if a spelling of the article's subject sometimes includes (or historically included) a ligature, then ligatures can be used in lead sections (or in expositions on etymology/spelling) for the purpose of mentioning that fact.'''"


==Discussion on ] bio leads==
—DIV (] (]) 02:20, 11 May 2019 (UTC))
See ]. ] (]) 19:07, 1 January 2025 (UTC)
{{talkref}}
* '''Opposed''' to any change to this section. First off, no rules in MoS about how to write ever preclude mentioning and illustrating something when it is itself the topic. Basic common sense. Literally no one on Misplaced Pages is confused into thinking otherwise (I don't even think you are; I think you're using hyperbole to try to make your point, and it is backfiring). Second, the fact that the ''OED'' prefers to write with ligatures (and much of its text dates to the mid-20th century, when they were in much more common use) has nothing at all to do with whether WP's house style is to avoid them and should remain that way (it is, and it should). ''OED''<nowiki />'s house style is not WP house style. You say you respect that we have a house style, and then want to impose someone else's. So, nope. This also has no effect whatsoever on titles of works; cf. '']'', "]", '']'', etc., etc. If something quoted from ''OED'' is in fact being misquoted, then fix the quote, like we would with any other quote. While ] permits some {{em|trivial}} alterations for normalized text presentation, this isn't one of them (if ''OED''<nowiki />'s dictionarian position is in favor of the ''formulæ'' spelling, then that should be reported accurately). There is nothing wrong with the guideline; there's something wrong with a quote in one article. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 12:14, 11 May 2019 (UTC)


== Usage of historical place names in infoboxes ==
== ], most common punctuation error in WP? ==


Some feedback ] would be nice. Thanks --] (]) 19:34, 1 January 2025 (UTC)
It seems we have a ton of articles missing a matching comma after state, in lead sentences even, in constructs like "X in ] was a ...". ] and every style and grammar guide that I've looked at says this is an error, but lots of editors don't know, and a distressing number even argue that it's not an error (esp. in discussions of titles such as ]. Is there something we should be doing to make this more clear? Does anyone know why some people don't experience any pain on encountering such imbalances? ] (]) 15:40, 12 May 2019 (UTC)
:As usual, it's because some news-style manuals like to drop this comma, and people see that style if they read more news than other nonfiction, so they absorb it. I think the MoS material is plenty clear, but most editors never read it. MoS is primarily a {{lang|la|post hoc}} cleanup tool, and a means of settling disputes, not a "Now that you want to become an WP editor for the first time, please learn all of this" document. The average editor just writes in whatever way feels comfortable to them, and someone else cleans it up later. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 17:33, 12 May 2019 (UTC)
::I get that, and I don't mind doing the cleanup work. What seems odd, though, is the opposition that such work sometimes encounters, as in some recent RM discussions where nearly half the people argue that it's not wrong so don't fix it – when it's obviously wrong. ] (]) 17:45, 12 May 2019 (UTC)
:I can only speak for myself, but I suppose that the absence of a comma simply isn't regarded as an imbalance. I seem to recall having read somewhere recently that the state is treated as an appositive and hence the comma following, but it's possible to see the state as not an appositive at all, but rather as simply part of the address, the address constituting a whole. Such a missing comma may be seen as obviously wrong, but I think this is basically simply in regard to the accepted rule that it should be followed by a comma. I don't feel that the state is an appositive myself, and when I encounter phrases such as "He moved to Columbus, Ohio, in 1948", I find the suggested pause after "Ohio" unnecessary and rather irksome (as with short introductory prepositional phrases). What I would ''say'' would be more like "He moved to Columbus, Ohio in 1948", and if I don't pause it I don't see why I should punctuate it either. (Actually, to be truthful, what I would say would probably be even more like "He moved to Columbus Ohio in 1948", but I would never for a single second consider omitting the comma between the city and the state – though I would unhesitatingly in "Columbus OH" or "Columbus OH, USA.) Could we perhaps agree that however ''de rigueur'' the comma following the state may be, the comma between the city and the state is nonetheless more essential? If so, that might say something about perceived balance or imbalance. I've now tried to answer Dicklyon's question about how someone could regard this comma as unnecessary, and now I'm wondering if he regards its absence as obviously wrong for some reason other than the rule itself, and if so what that reason is. If he sees the state as an appositive, I don't. If he sees it as something else, I'm interested in what that is. –] (]) 00:37, 13 May 2019 (UTC)
:: I suspect that the form "city, state" derives from early postal conventions that called for separation in the interest of clarity and to avoid ambiguity. The commas involved have no "pause" function, in my opinion. I would not pause in speaking before or after the state. The state is normally included as a disambiguator, since identically named cities can exist in multiple states, or to clarify the location of a city that is not well known. For major cities (New York, Chicago) the state can be omitted. The idea of placing a comma after the state is to set off (enclose) it as a defining element (which Columbus?) and as such is an appositive form. It could just as well be enclosed in parentheses in normal prose, thus avoiding the comma question. ] (]) 01:27, 13 May 2019 (UTC)
:::The comma is no problem whether you pause a little or not at all. I'd be happy if we moved to no comma, as we've done with "Jr." (and as the post office now prefers for addresses on envelopes), but with just one when the text continues, it's really hard to see what the role of that comma is supposed to be. "He moved to Columbus, Ohio in 1948" just looks like a broken comma splice of some sort, with a pause between "He moved to Columbus" and "Ohio in 1948". All grammar guides say to not do that. Same with years in American style dates; I'd be happy to go to no comma, but with mismatched comma it's a glaring error, just like a mismatched open paren, as in "He move to Columbus (Ohio in 1948." ] (]) 01:31, 13 May 2019 (UTC)
:::::I wouldn’t put much stock in what the post office says (for our purposes): Canada Post, for example, deprecates ''all'' punctuation in addresses. I agree with {{U|Jmar67}} that the function of these commas is essentially parenthetical, so they should be paired. (BTW some Europeans, and French-Canadians as well, do normally use parenthesis symbols for the purpose.)—]]] 21:31, 13 May 2019 (UTC)
::::Yep. Commas that serve a bracketing function always come in pairs (or the second is replaced by some other punctuation). I don't think we'll be dropping these commas, because the real world isn't (as it has been with the commas in "Sammy Davis, Jr., was born in 1925."). So, the thing to do is just fix them when they're not paired. If you keep running into confused pushback, I would suggest putting together an information page that lays out all the style guide quotations; if you've already done the looking up, might as well just save it and give it a short cut, to curtail both the amount of time spent rehashing it, and the frequency with which people want to. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 06:22, 13 May 2019 (UTC)
: One of the most common fixes I make, and I never had someone revert it ... until ]&nbsp;<span style="color: Red;">🍁</span>&nbsp;] 22:43, 13 May 2019 (UTC)

Latest revision as of 12:28, 9 January 2025

This is the talk page for discussing improvements to the Manual of Style page.
Shortcut
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228Auto-archiving period: 30 days 
? faq page Frequently asked questions

Misplaced Pages's Manual of Style contains some conventions that differ from those in some other, well-known style guides and from what is often taught in schools. Misplaced Pages's editors have discussed these conventions in great detail and have reached consensus that these conventions serve our purposes best. New contributors are advised to check the FAQ and the archives to see if their concern has already been discussed.

Why does the Manual of Style recommend straight (keyboard-style) instead of curly (typographic) quotation marks and apostrophes (i.e., the characters " and ', instead of “, ”, ‘, and ’)‍? Users may only know how to type in straight quotes (such as " and ') when searching for text within a page or when editing. Not all Web browsers find curly quotes when users type straight quotes in search strings. Why does the Manual of Style recommend logical quotation? This system is preferred because Misplaced Pages, as an international and electronic encyclopedia, has specific needs better addressed by logical quotation than by the other styles, despite the tendency of externally published style guides to recommend the latter. These include the distinct typesetters' style (often called American, though not limited to the US), and the various British/Commonwealth styles, which are superficially similar to logical quotation but have some characteristics of typesetters' style. Logical quotation is more in keeping with the principle of minimal change to quotations, and is less prone to misquotation, ambiguity, and the introduction of errors in subsequent editing, than the alternatives. Logical quotation was adopted in 2005, and has been the subject of perennial debate that has not changed this consensus. Why does the Manual of Style differentiate the hyphen (-), en dash (–), em dash (—), and minus sign (−)? Appropriate use of hyphens and dashes is as much a part of literate, easy-to-read writing as are correct spelling and capitalization. The "Insert" editing tools directly below the Misplaced Pages editing window provide immediate access to all these characters. Why does the Manual of Style recommend apostrophe+s for singular possessive of names ending in s? Most modern style guides treat names ending with s just like other singular nouns when forming the possessive. The few that do not propose mutually contradictory alternatives. Numerous discussions have led to the current MoS guidance (see discussions of 2004, 2005, 2005, 2006, 2006, 2007, 2008, 2008, 2008, 2009, 2009, 2009, 2012, 2013, 2015, 2016, 2017, 2017, 2017 (the RfC establishing the present consensus), 2018, 2018, 2019, 2021, 2022). Why doesn't the Manual of Style always follow specialized practice? Although Misplaced Pages contains some highly technical content, it is written for a general audience. While specialized publications in a field, such as academic journals, are excellent sources for facts, they are not always the best sources for or examples of how to present those facts to non-experts. When adopting style recommendations from external sources, the Manual of Style incorporates a substantial number of practices from technical standards and field-specific academic style guides; however, Misplaced Pages defaults to preferring general-audience sources on style, especially when a specialized preference may conflict with most readers' expectations, and when different disciplines use conflicting styles.
Discussions on this page often lead to previous arguments being restated. Please read recent comments, look in the archives, and review the FAQ before commenting.
Section sizes
Section size for Misplaced Pages:Manual of Style (157 sections)
Section name Byte
count		 Section
total
(Top) 2,657 2,657
Retaining existing styles 2,787 2,787
Article titles, sections, and headings 137 12,678
Article titles 3,406 3,406
Section organization 4,752 4,752
Section headings 3,573 4,383
Heading-like material 810 810
National varieties of English 847 6,626
Consistency within articles 1,230 1,230
Opportunities for commonality 1,882 1,882
Strong national ties to a topic 1,414 1,414
Retaining the existing variety 1,253 1,253
Capital letters 648 18,724
Capitalization of The 984 984
Titles of works 1,232 1,232
Titles of people 780 780
Religions, deities, philosophies, doctrines 4,974 4,974
Calendar items 701 701
Animals, plants, and other organisms 5,616 5,616
Celestial bodies 1,249 1,249
Compass points 1,203 1,203
Proper names versus generic terms 1,337 1,337
Ligatures 495 495
Abbreviations 774 8,129
Write first occurrences in full 640 640
Plural forms 245 245
Punctuation and spacing 1,175 1,175
US and U.S. 1,918 1,918
Circa 279 279
Avoid unwarranted use 662 662
Do not invent 874 874
HTML tags and templates 383 383
Ampersand 1,179 1,179
Italics 105 6,366
Emphasis 1,133 1,133
Titles 572 572
Words as words 1,320 1,320
Non-English words 751 751
Scientific names 499 499
Quotations in italics 581 581
Italics within quotations 767 767
Effect on nearby punctuation 638 638
Quotations 1,355 16,636
Original wording 3,026 3,026
Point of view 1,234 1,234
Typographic conformity 5,818 5,818
Attribution 438 438
Quotations within quotations 94 94
Linking 483 483
Block quotations 3,049 3,049
Non-English quotations 1,139 1,139
Punctuation 203 76,952
Apostrophes 2,184 2,184
Quotation marks 394 13,595
Quotation characters 1,035 1,035
Double or single 1,234 1,234
For a quotation within a quotation 869 869
Article openings 729 729
Punctuation before quotations 2,023 2,023
Names and titles 1,331 1,331
Punctuation inside or outside 3,717 3,717
Quotation marks and external links 940 940
Quotation marks and internal links 1,323 1,323
Brackets and parentheses 3,366 4,571
Brackets and linking 1,205 1,205
Ellipses 2,939 2,939
Commas 4,876 8,072
Serial commas 3,196 3,196
Colons 1,868 1,868
Semicolons 3,331 5,721
Semicolon before "however" 2,390 2,390
Hyphens 9,985 9,985
Dashes 939 16,164
In article titles 759 759
In running text 2,195 12,352
In ranges that might otherwise be expressed with to or through 3,063 3,063
In compounds when the connection might otherwise be expressed with to, versus, and, or between 5,212 5,212
Instead of a hyphen, use an en dash when applying a prefix or suffix to a compound that itself includes a space, dash or hyphen 1,297 1,297
To separate parts of an item in a list 585 585
Other uses for en dashes 543 543
Other uses for em dashes 966 966
Other dashes 605 605
Slashes (strokes) 3,341 3,948
And/or 607 607
Symbols 595 595
Number (pound, hash) sign and numero 2,310 2,310
Terminal punctuation 737 737
Spacing 512 512
Consecutive punctuation marks 1,151 1,151
Punctuation and footnotes 2,179 2,179
Punctuation after formulae 218 218
Dates and time 361 5,083
Time of day 794 794
Dates 1,033 1,033
Months 323 323
Seasons 774 774
Years and longer periods 1,080 1,080
Current 718 718
Numbers 1,884 1,884
Currencies 1,637 1,637
Units of measurement 2,737 2,737
Common mathematical symbols 2,606 2,606
Grammar and usage 62 12,759
Possessives 158 1,918
Singular nouns 975 975
Plural nouns 523 523
Official names 262 262
Pronouns 104 5,804
First-person pronouns 1,494 1,494
Second-person pronouns 2,306 2,306
Third-person pronouns 1,900 1,900
Plurals 2,005 2,005
Verb tense 2,970 2,970
Vocabulary 98 22,675
Contractions 476 476
Gender-neutral language 1,692 1,692
Contested vocabulary 256 256
Instructional and presumptuous language 2,578 2,578
Subset terms 618 618
Identity 1,957 3,604
Gender identity 1,647 1,647
Non-English terms 301 8,016
Terms without common usage in English 1,547 1,547
Terms with common usage in English 400 400
Spelling and romanization 4,917 4,917
Other non-English concerns 851 851
Technical language 1,961 1,961
Geographical items 3,376 3,376
Media files 69 2,791
Images 313 313
Other media 181 181
Avoid using images to display text 884 884
Captions 526 1,344
Formatting of captions 818 818
Bulleted and numbered lists 1,552 1,552
Links 10 1,750
Wikilinks 1,411 1,411
External links 329 329
Miscellaneous 18 13,328
Keep markup simple 1,219 1,219
Formatting issues 1,016 2,981
Color coding 1,245 1,245
Indentation 720 720
Controlling line breaks 2,471 2,471
Scrolling lists and collapsible content 3,164 3,164
Invisible comments 1,554 2,817
How to add an invisible comment 1,263 1,263
Pronunciation 658 658
See also 1,199 4,870
Guidance 1,242 1,242
Tools 300 300
Other community standards 523 523
Guidelines within the Manual of Style 310 1,606
Names 1,296 1,296
Notes 24 24
References 28 28
Further reading 1,206 1,206
Total 226,980 226,980
This project page does not require a rating on Misplaced Pages's content assessment scale.
It is of interest to the following WikiProjects:
WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Misplaced Pages:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Misplaced Pages Manual of Style, and the article titles policy. Both areas are subjects of debate.
Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
Note icon
For information on Misplaced Pages's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Misplaced Pages policies of Misplaced Pages's policy and guideline documents is available, offering valuable insights and recommendations.
WikiProject iconMisplaced Pages Help Top‑importance
WikiProject iconThis page is within the scope of the Misplaced Pages Help Project, a collaborative effort to improve Misplaced Pages's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Misplaced Pages HelpWikipedia:Help ProjectTemplate:Misplaced Pages Help ProjectHelp
TopThis page has been rated as Top-importance on the project's importance scale.

Welcome to the MOS pit


    Style discussions elsewhere

    This section is pinned and will not be automatically archived.

    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)

    Pretty stale but not "concluded":

    Capitalization-specific:

    This section is an excerpt from Misplaced Pages talk:Manual of Style/Capital letters § Current.

    Move requests:

    Other discussions:

    Pretty stale but not "concluded":

    Concluded

    Extended content
    This section is an excerpt from Misplaced Pages talk:Manual of Style/Capital letters § Concluded.
    Capitalization-specific:
    2024
    2023
    2022
    2021

    Retain or remove citation indicators in quoted text?

    Is it acceptable to remove citation indicators – ¹ or (Gorgon, 1993) – that appear within quoted text (this would be to improve readability). I'm not referring to citing quoted material, but to citation marks within quoted material. Thanks! Tsavage (talk) 12:18, 25 November 2024 (UTC)

    Yes. References to footnotes are usually silently omitted, as they are not a part of the text flow anyway. Gawaon (talk) 11:52, 26 November 2024 (UTC)
    Thanks. Is this addressed in the MoS? I couldn't find mention MOS:QUOTE. This would seem a common situation when citing academic sources. Tsavage (talk) 15:58, 26 November 2024 (UTC)
    I added it while doing some other cleanup. It's entirely normal to silently (not with "...") remove inline citations from quoted material, since WP isn't providing the source info, and to the reader it will be just be frustrating (they'll go looking for "Smith 1997" or whatever, and not find it). If our article is also citing the same source, then linking the quoted citation to our citation might be useful, but shouldn't be seen as manadatory. A general principle of quotation (inline or block) is to only quote what is pertinent, what is contextually necessary for our purposes; otherwise we're wandering into over-quotation which is both poor writing and apt to be a copyright issue unless the source is public-domain.  — SMcCandlish ☏ ¢ 😼  13:55, 11 December 2024 (UTC)
    Thanks. Your addition is helpful and doesn't seem to overcomplicate things. I realized the primary aim with quoted material is not to forensically reproduce it from the source (as I'd kinda been doing), it's to accurately represent the meaning as it appears in the full context of the source. Which makes minor silent adjustments for readability fine, provided meaning is strictly preserved – comprehension and judgement are of course required. Tsavage (talk) 17:06, 11 December 2024 (UTC)

    Stale advice: slashes have been line-breaks since 2005 (Unicode 4.1.0)

    § Slashes (strokes) says "On the other hand, if two long words are connected by an unspaced slash, an {{wbr}} added after the slash will allow a linebreak at that point."

    I've recently tweaked a couple of articles doing this, and realized that my browser will allow breaks after slashes without any special markup. This is part of the current Unicode line-break algorithm. Looking into the archives, it was added to support breaking URLs between Unicode 4.0.1 (2004-03-30) and Unicode 4.1.0 (2005-08-29).

    It's been 19 years. Do we still need this advice? I ask because some parts of WP are aggressively backward-compatible: {{wbr}} still expands to <wbr/>&#8203; since apparently IE7 and earlier don't support <wbr/>. But I seriously doubt that WP is consistently backward-compatible; I'm sure there are lots of more recent edits where the editors didn't see a problem with long /-separated lists on their browsers and didn't do anything tricky. 97.102.205.224 (talk) 17:20, 26 November 2024 (UTC)

    Look at Good articles (or former Good articles) from years ago they read like they do now and it just shows that the Manual of Style will stay exactly the same as it has been for 18 years unfortunately. This0k (talk) 02:45, 14 December 2024 (UTC)

    Input needed on disagreement over where the lifespan goes in relation to a baronetcy or a peerage title

    Muéro and I disagree on where the lifespan goes in relation to a name that includes a baronetcy or a peerage title. It started with Muéro removing honorifics from the lead of several articles on peers (many of which I have on my watchlist), following the recently changed guidelines at WP:POSTNOM. This is not controversial, but in their edits, he also removed a comma unrelated to the honorifics, but called for by WP:COMMA ("Don't let other punctuation distract you from the need for a comma, especially when the comma collides with a bracket or parenthesis").

    I pointed this out to them, and they acknowledged the error, but then they instead started to leave another comma in place, a comma that was required by the now obsolete guideline. I can't find the guideline in the history of this article, but it went something like this:

    For people with a baronetcy or a peerage, the post-nominals should be separated from each other, and from the name, by a comma, for consistency's sake. (my underscore)

    That is the comma Muéro left in place, and the result was this: 

    John Doe, 1st Baron Doe, (1 January 1801 – 31 December 1881), was a Whig politician ...

    I pointed out to Muéro that this is also wrong, and that punctuation rarely – if ever – precedes a parenthetical expression. But they are adamant that it should be there.

    So here we are. I'd like input from the project, and I'm sure Muéro would like that too.

    The discussion originated on Muéro's talk page, but I'm copying it here, and closing it there, while notifying them.

    The discussion on Muéro's talk page

    Hello.

    Thank you for your contributions. Regarding your edit of Frederick Curzon, 7th Earl Howe, and similar edits removing postnoms per the new guidelines, please don't remove the comma after the parenthetical birth–death expression. It's supposed to be there per WP:COMMA: "Don't let other punctuation distract you from the need for a comma, especially when the comma collides with a bracket or parenthesis".

    Thank you. HandsomeFella (talk) 15:50, 25 November 2024 (UTC)

    Ah, good catch. I can't wait for the day when nobility titles are also excluded entirely, which would make that comma unnecessary anyway. Muéro 15:58, 25 November 2024 (UTC)
    Hello again.
    Thank you for your understanding. Re: your latest edits, you're now leaving a comma in place that shouldn't be there.
    Nathaniel Charles Jacob Rothschild, 4th Baron Rothschild, (29 April 1936 – 26 February 2024),
                                  ^                     ^                                   ^
                                  A                     B                                   C
    Commas A and C are paired, comma B should be removed along with the postnoms that followed it. Commas rarely precede parentheses.
    Cheers.
    HandsomeFella (talk) 17:52, 25 November 2024 (UTC)
    I don't think that makes sense. If someone doesn't have a nobility/royalty title, there is no comma before or after the life span. When adding the nobility/royalty title, the pair of commas should go before and after the nobility/royalty title. Why, when adding the nobility/royalty title, would the life span get looped into the comma pair? Muéro 17:56, 25 November 2024 (UTC)

    Step by step

    I think it makes perfect sense. You don't put a parenthetical expression after punctuation, do you? Let me take this step by step. Normally, the first sentence would be something like this: 

    John Doe was a Whig politician ...

    Now let's add that he was a peer: 

    John Doe, 1st Baron Doe, was a Whig politician ...
        ^              ^
        A              B

    The commas A and B are paired, i.e. the "parenthetical" title is set off at both ends (unless when there is other punctuation, like at the end of sentence). Let's see what happens without the closing (second) comma: 

    John Doe, 1st Baron Doe was a Whig politician ...

    If the commas aren't paired, the sentence reads "1st Baron Doe was a Whig politician", and "John Doe" is left dangling at the start of the sentence.

    Now, let's add the life span. Where do we add it? Before punctuation. 

    John Doe, 1st Baron Doe (1 January 1801 – 31 December 1881), was a Whig politician ...
        ^                                                  ^
        A                                                  B

    The commas A and B are still paired. See?

    HandsomeFella (talk) 23:04, 25 November 2024 (UTC)

    The nobility title is a nonessential appositive. Commas go before and after a nonessential appositive. I'm assuming you don't consider the lifespan, which is never set off by commas in a Misplaced Pages article, to be a part of the same nonessential appositive somehow, right? If it's not included in the nobility title nonessential appositive, then it goes outside the commas. Muéro 00:04, 26 November 2024 (UTC)
    No, it doesn't. Sure, the lifespan parenthetical isn't part of the appositive, but neither are the commas, which is demonstrated by the fact that at, if the name and title occurred at the end of a sentence, there wouldn't be a comma; there would be a period/full stop:
    ... Joseph Smith bequeathed the manor to his nephew, John Doe, 1st Baron Doe (1801–1881).
    You wouldn't place the parenthetical outside the sentence like this, would you?
    ... Joseph Smith bequeathed the manor to his nephew, John Doe, 1st Baron Doe. (1801–1881)
    Ergo: normal rules apply, which is that punctuation doesn't precede a parenthetical. (The exception being when there is a complete sentence inside the parentheses, in which case punctuation occurs both at the end of the preceding sentence, i.e. before the parenthetical, and before the closing parenthetical, as shown here.)
    Commas go before and after an appositive (unless there is other punctuation), but that does not necessarily mean immediately after.
    HandsomeFella (talk) 10:29, 26 November 2024 (UTC)
    "Punctuation doesn't precede a parenthetical" is not a rule at all. It's just something you made up.
    If the parenthetical were being applied to the nobility title, then the parenthetical should go within the commas that set off the nobility title. But the parenthetical is being applied to the actual name of the person, which came before the nonessential appositive that is set off by commas.
    If you dislike the placement of the nobility title between the name and the lifespan parenthetical, I wouldn't disagree. I'd happily remove the nobility title entirely from the lead sentence (or heck, the whole article). Or put the lifespan parenthetical first, and then the nobility title. But wherever the nobility appositive is being stuck, it gets set off by commas. That's the rule. Muéro 13:38, 26 November 2024 (UTC)
    This one is simple: a comma is never placed immediately before other punctuation. Instead it's placed after them or, in case or semicolons and periods, omitted altogether. While MOS:COMMA doesn't say so quite explicitly (supposedly treating it as one of these common sense things that everybody already knows?), it gives an example of how to do it correctly: "Burke and Wills, fed by locals (on beans, fish, and ngardu), survived for a few months." (With the second parenthetical comma after the closing bracket.) So, by analogy, "John Doe, 1st Baron Doe (1 January 1801 – 31 December 1881), was a Whig politician" is indeed correct. Gawaon (talk) 08:58, 28 November 2024 (UTC)
    Concur with the OP and with Gawaon on the typographical point; we don't use a comma right before a round-bracketed parenthetical, nor does much of anyone else in the world. One might make an argument that "logically", in the way a computer program would approach logic, there should or could be one there, and this is the direction Muéro has been going, but human language does not operate on such a basis, being a matter of convention combined with expediency, not a matter of a JSON-like syntax in which a comma that really should not be needed to parse the material must be present anyway or the operation will fail.

    That said, we do have several interrelating issues in play in this titles and post-noms sector that are worth cataloguing and considering in some detail:

    1. Something like "Xerxes Youill Zounds, Grand Poobah of Elbonia–Brobdingnag (3 May 1571 – 24 July 1644), was ..." is always indicating the life-span dates. If there is a need to specify the duration of a peerage, including a change in titles, that should be done in plain English in the article body, and is not going to be lead-sentence or even lead-section material. It's body material, like "Upon the death of his father, Zounds became 3rd poobah of Elbonia on 12 December 1629. He was elevated to 1st grand poobah of Elbonia–Brobdingnag on 20 June 1639 by High King Korki IX of Kerblachistan. Zounds was also the bishop of Lilliput from ca. 1630 to 14 February 1633, when he was defrocked by the archbishop of Elbonia."
    2. As an anti-classist myself, I still have to observe/concede that "don't include any titles or post-noms because they are classist" is not a viable position. WP is not a socio-political activism tool, and when any such title or honor (whether earned or hereditary or otherwise) is pertinent to a notable article subject, it should be covered, more prominently the more important it is within the context of their notability. (See below for an idea toward suppressing lead inclusion when not related to notability at all but a late-coming add-on to the pile of someone's life aachievements.)
    3. There's a been a very long-standing de facto consensus to always include peerage titles and important post-nominals (but not academic or professional titles or post nominals like "Dr" or "PhD", or guild/union stuff like "ASC", "PGA") in the lead sentence. Virtually every applicable article has been written this way.
    4. A recent-ish RfC (I seem to have lost the link to it – help me out?) with probably much too low a turnout upended part of this, and now has us remove the post-nominals from the lead sentence. This has not sat well, and actually introduces some writing problems that the RfC participants did not anticipate. For example, WP does not, except in an article on the subject being abbreviated, introduce an acronym/initialism unless it is going to be re-used later in the same article. But if our bio subject's investiture as a Knight Commander of the Order of the Bath is covered in the body only, the point at which this is done has no need to a "KCB" appearing at that point, since "KCB" is used as a post-nominal not otherwise and would not be re-used later in the article; the result is that the "KCB" that applies to this person has no logical place to go in the article any longer, since it was actually only pertinent in the lead sentence, attached to the person's name. We could do something very awkward like state that this knighthood entitles/entitled this person to use "Sir" or "Dame" and the post-nominal "KCB", but this sort of blather would have to be repeated throughout many thousands of articles, and was already very concisely conveyed by the original lead sentence without having to spell it out and micro-WP:COATRACK the bio article with detailia about how a particular order's nomenclatural rules operate. Simply showing rather than telling was better.

      So, this really should be re-RfCed, at a higher-profile venue like WP:VPPOL so we are certain that the community at large really wants to impose this lead rule change and its problems all in the name of shaving a few characters off the lead sentence. "The postnoms will be in the infobox anyway" isn't the (or an) answer, since not all bios have infoboxes, and there is staunch resistance to adding them in many cases. A potential compromise might be to not include postnoms in lead sentence but in an infobox when one is present and has a parameter for it.

    5. Even without revisiting that with a better RfC, the present wording at MOS:POSTNOM is daft: "post-nominal letters may be included in the main body of the article, but not in the lead sentence of the article". This has already lead to dispute about whether it means post-noms are banned from the entire lead or only the literal lead sentence, because it only addresses the lead sentence and the post-lead-section article body. The correct answer (if you look at the RfC discussion and the alleged consensus arising from it) is that this should instead read something like "post-nominal letters may be included, but not in the lead sentence of the article"; there was no consenus to ban them from the entire lead section. However, this runs into the problem above: Because post-nominal letters are used directly with full names, and generally only upon first introduction, there effectively is no practical place for them, in the lead section or in the article body, other than the lead sentence (except arguably in an infobox if it's there and has a place for this information).
    6. Next, there's a misapprehension here (evidenced in the beginning of this thread) that this anti-postnom RfC result somehow also means to remove peerage and nobility titles from the lead. It does not. They are a different category of thing and were not addressed in that RfC. It is possible that a consensus might be reached to remove peerage titles when they are not pertinent to the subject's notability (e.g. that would have been the case with Christopher Guest had he remained an actor/director/producer only and not taken a seat in the House of Lords). There are also many life baronetcies created late in the life of the recipients and to little public awareness; a case can be made to exclude them from the lead sentence and probably from the entire lead section. But this is something for a consensus discussion on an article-by-article basis, or for a new RfC if we wanted a categoric rule of some kind about it.
    7. A side issue is that some parties from the nobility and peerage wikiprojects have, by WP:FAITACCOMPLI behavior, programmatically usurped the |name= parameter of {{infobox person}} and its offshoots, abusing it to hold the peerage title, when that really belongs in |postnom= since it is in fact post-nominal (it's just not a post-nominal abbreviation). See Margaret Thatcher for the typical absurd result. Because this has been done to thousands and thousands of articles and involves yet another "wikiproject rebellion" against the norms of the entire rest of the project, I suspect this is probably best addressed with another WP:VPPOL RfC so there can be no doubt about the community consensus level of the result (which will obviously be to stop having our infobox blatantly lie to our readers that Margaret Thatcher's name is "The Baroness Thatcher". For the Thatcher case, the obvious solution is: |name=Margaret Hilda Thatcher|honorific_suffix=Baroness Thatcher<br />{{Post-nominals|country=GBR|size=100%|LG|OM|DStJ|PC|FRS|HonFRSC}} , and this is what agrees with the lead of the article. (Note lack of "The" before "Baroness".)

      These infoboxes are also failing MOS:HONORIFIC by including honorific salutation phrases like "The Right Honorourable" that are not part of the name in any sense, but used when writing a letter to such a person or when introducing them as speaker, and so on; that sort of information does not belong in a bio article (much less thousands of them robotically) but in an article on forms-of-address etiquette and probably again in the article on the title (baronet or whatever the case may be).

    There are probably other issues to address, but this is a lot already.  — SMcCandlish ☏ ¢ 😼  13:42, 11 December 2024 (UTC)

    Any objections to extending MOS:TIES to all nations and regions?

    Currently MOS:TIES qualifies itself to English-speaking nations. However, in an increasingly multicultural world with English emerging as the lingua franca, at minimum in the Western world, why qualify this part of the MoS like that, ESPECIALLY when it also impacts on MOS:UNIT? For example, the European Union has 24 official languages, including English, and multilingualism is one of its founding principles.

    Would it not make sense to extend MOS:TIES to nations (and regions) irrespective of whether they traditionally speak English or not? Because I can see how saying to someone that embraces multilingualism and values Europe's rich linguistic diversity wishing to contribute to an article on a topic with strong ties to their nation or region in the EU, where English is an official language, that in this case that tie doesn’t count (and someone else gets to decide) might be perceived as ... well ... rude and arrogant, which isn't just unnecessary but also unproductive. Would the article not benefit from including anyone with a strong tie to it?

    I must note I would prefer if there was an established international variant, but I also find it practical not to have to waste time and effort trying to work out whether in a given article its meter or metre, organise or organize, or SI first and then imperial, or imperial first and then SI. Because getting it wrong just causes unnecessary consternation, especially if the article is inhabited by one or more "Shelobs". Elrondil (talk) 06:41, 14 December 2024 (UTC)

    I'm not in favor of this idea. TIES is an exceptional case that should be used only when it's very clear; the main rule is RETAIN.
    In practice I think this proposal comes down to "don't use American English in articles about Europe". I don't agree with that. --Trovatore (talk) 06:52, 14 December 2024 (UTC)
    @Trovatore: The proposal doesn’t suggest it no longer needs to be clear, nor that that main rule is no longer retain. It simply proposes that MORE voices are heard.
    As for the “don’t use American English in Europe” bit ... that would then only happen if most voices then want that. The solution surely isn’t “but I don’t like that, so let’s exclude them from the set of voices allowed to speak”. Fear not, they may choose American, who knows. Elrondil (talk) 06:21, 23 December 2024 (UTC)
    Also not in favor for the reasons cited by Trovatore. Doremo (talk) 07:16, 14 December 2024 (UTC)
    I do object to this.
    Moreover, from what I understand it's a perennial suggestion, so I recommend perusing the last major flare-up of it from June, wherein I happen to embark on a journey from the exact wrong position all the way to the right one, filling your heart with hope for a better future as you follow my progress. Remsense ‥ 论 07:23, 14 December 2024 (UTC)
    If it keeps coming up, perhaps there is something there.
    However, you do highlight its more complex than I originally thought, so back to the drawing board 🤔. Elrondil (talk) 06:24, 23 December 2024 (UTC)
    Not a chance. The purpose of MOS:TIES is entirely, only, solely about English-language dialects that exist at a more or less national level and in a formal register suitable for encyclopedia writing. Under no circumstances would we accept an English pidgin/creole or some vaguely identifiable informal habits of English-as-a-second-language users in some country or region as a "variety of English" to accept for encyclopedia writing. If you encounter "Franglais", "Spanglish", "Deutchlish", etc., in any of our articles it should be normalized on the spot to whichever form of standardized English suits the subject best if there are strong MOS:TIES, or to the form that the article already most closely matches (British, American, Canadian, or some other dialect of a country with majority or official and large minority English usage in a formal register). Another way of looking at this: There is no strong tie between Finland and any form of English. Even the "Well, it at least shouldn't be American, but British, because the UK is part of Europe and the US is not" sort of argument fails, because there's more than one national dialect of English in Europe (Irish, for now, and probably Scottish if they have another independence referendum). If there's not a particular encyclopedia-appropriate variety/dialect of English in widespread use in a country, then that country by definition has no strong tie to any such particular variety.  — SMcCandlish ☏ ¢ 😼  06:22, 23 December 2024 (UTC)
    @SMcCandlish: Thank you for stating very clearly and firmly that the purpose of MOS:TIES is entirely, only, solely about English-language dialects, because THAT means my primary concern of how it relates to MOS:UNIT is a non-issue!
    For the record, I did not, and still don’t, propose that “Franglais” and so on become accepted English variants. Because that would be insane, pointless and not useful. Elrondil (talk) 06:46, 23 December 2024 (UTC)
    If this is something to do with promotion of crore and lakh in articles that pertain to India, there's already a big thread about that at WT:MOSNUM (again), and last I looked the consensus wasn't really changing: they're permissible as secondary units, but always need to be converted because they don't mean anything to anyone outside India and parts of its immediate neighbors (and of course among first-gen Indic diaspora). Maybe the tide has shifted in that discussion; I last looked at it about a week ago.  — SMcCandlish ☏ ¢ 😼  06:50, 23 December 2024 (UTC)
    No. I wasn’t aware of that thread. Elrondil (talk) 06:52, 23 December 2024 (UTC)
    The thread to which you refer is “RfC Indian numbering conventions”? Elrondil (talk) 06:59, 23 December 2024 (UTC)
    I don’t think there is any real overlap with the “RfC Indian numbering conventions” thread.
    I also think MOS:TIES is a dog’s breakfast, but happy to leave it alone at this time.
    Are there any objections then to apply the direction from SMcCandlish that the purpose of MOS:TIES is entirely, only, solely about English-language dialects to MOS:UNITS and decouple "respect the principle of 'strong national ties'" from MOS:TIES? For example, change it to "respect the underlying principle of strong national ties as also used in MOS:TIES but in a different context”, and then also qualify the following with only?
    • In non-scientific articles with strong ties to the United States only, the …
    • In non-scientific articles with strong ties to the United Kingdom only, the …
    • In all other articles, the …
    Elrondil (talk) 08:34, 23 December 2024 (UTC)
    Well, you're been so vague about why you are asking these things, what rationale you could have for making up a new rule or changing any existing one, without any reference to an ongoing and important on-site problem, that all one has been left with is guesswork based on encounters with extant or recent discussions that seem like they could be pertinent. "Are there any objections"?: Yes., I can think of a number:
    1. There is no clear rationale for what you're proposing, much less a consensus to do it. Substantive changes to policies and guidelines (WP:P&G) need consensus or they will not be accepted (unless they, rarely, hit upon something that needed to adjusted and no one else noticed until now, which isn't the case here).
    2. There are strong rationales against it, most obviously:
      A. Your implicit notion that units of measure have no connection to dialect (or "variety" as WP likes to say) is not correct.
      B. Even if it were, it'd be immaterial. The next implicit idea in your proposal (quite central to it really) is that if P&G page X reiterates a general principle from another, Y, and cites the latter for the explanation, such that X applies that principle to X's circumstances because they are reasonably analogous to Y's, that this somehow creates a bureaucratic rules-chain dependency in which every aspect of the context of the cited origin of the principle in Y must also be applicable to the citing circumstances of X. Nothing on Misplaced Pages works that way at all. Cf. WP:WIKILAWYER: it's a mistake to try to interpret our P&G as essentially a legal system (or as something like a procedural programming language, or a chain of dependencies in building software from source code; more than one analogy works).
      C. Because of point B, and because of the guideline's current "where applicable" wording (which is there for a reason and meaningful), your first rewrite idea, of tacking on a bunch of "respect the underlying principle of strong national ties as also used in MOS:TIES but in a different context" verbiage it entirely superfluous. The two versions convey the same meaning, because it is already understood that the principle (not the detail-by-detail contextual specifics) of TIES is being applied at UNITS. This is the way our entire P&G system operates. It wouldn't really be possible for it to be any other way. If UNITS was literally just restating TIES, down to the specifics of exactly what TIES covers, then UNITS would be redundant (in this regard) with TIES, and its wording about this issue would've been deleted long ago and replaced with a simple cross-reference to TIES without further comment. The kind of exemplary and contextual more-than-crossreferencing done at UNITS is entirely normal. And important: an editor looking for "what to do about units" is unlikely to instead stumble upon "what to do about national-level usage disputes", and so would be unlikely to find the TIES principles and then be certain how to contextually apply them (if at all) to units, without being basically an expert in our style guide the way some Tolkien fans learn Elvish.
      D. The next bit of suggested rewriting is to inject "only" into two line items, but this change would have a nonsensical and undesirable result in two ways: It would make those items applicable under no circumstances to anywhere but the US and the UK, respectively (even to former UK colonies with English- and units-usage norms virtually indistinguishable from British in an encyclopedic register); and it would necessitate (to fix that new problem) expanding that into a long list of every country with anything that WP would consider a "national variety of English" with pertinent unit-usage norms. The purpose of those two examples is as examples (not as an exhaustive list) of how to approach these matters. The examples were chosen because they settled previously recurrent disputes. So, what long-term, recurrent, serious problem can you point to that you think your changes would resolve? The examples are not there to serve as the beginning of an ever-growing rulebook to address every imaginable case with a new micro-topical line item to thump. The purpose of giving a general principle and providing some prominent examples is to obviate the need to have a pile of micro-rules. (MOS:NUM is already too detailed as it is.)
    3. The long-term stability of these guidelines is very important, because even small but meaningful/operative changes to them can affect many thousands up to potentially millions of articles, for reasons that almost always resolve to trivial and subjective peccadilloes. That cascading-wave-of-unneeded-changes problem (and all the fighting the endless trivial tweaks would generate) is never more of a danger than when a national-level and frequent usage matter is at issue (and literally millions of our articles do have measures with units in them). See also WP:MOSBLOAT: If MoS, after 20-odd years, doesn't already have a rule about something, then it needs to not have a rule about it, because it is not necessary for the project to do what it does successfully, and MoS is already way too long.
    4. Your "I also think MOS:TIES is a dog's breakfast, but happy to leave it alone at this time" approach does not bode well. Our policies and guidelines don't exist as hills to die on. The purpose of these style guidelines is (aside from the main one of producing intelligible and consistent content for our readers) dissuading style-warring behavior. Arriving with the idea that the rules are broken and that at some forthcoming time you're going to fix them is antithetical to their purpose and to the needs of the community. It largely doesn't matter what any particular line-item in MoS sets out (except when there is objectively a reader-clarity improvement offered by one option over another), only that it sets out, and long-term retains, something that addresses a recurrent dispute pattern and brings it mostly (hopefully entirely) to an end, and/or that it produces better content for our readers – even if that "something" is arbitrary or is a compromise that can't please everyone. Just as a word to the wise, MOS:ENGVAR (including TIES) is pretty much the hardest-fought consensus compromise reached in MoS's history, and is also one of the oldest and most stable, so if you think you're going to make serious changes to it, you are very mistaken. It's like going to Canada and declaring your mission is to undo the country's approach to French and English as official languages.
    This might all come off as harsh, but WP:Policy writing is hard, and the vast majority of proposals to change any P&G are off the mark. There are many devils in many details (thus the length of this), with a lot of nuanced interrelations between different rules (or advice or best practices or whatever you want to call them). Most of the real kinks were worked out long ago. Those that remain are subject to long-term dispute that hasn't produced a workable compromise. There is no such dispute about the material you want to change. And there are sometimes severe costs for making changes that are not vital to make.PS: I've tried hard to find a "yes" to put into this pile of "no", and there is one! Namely, your version is correct that the "scare quotes" around strong national ties shouldn't be there. I just went and removed them, so thanks for that. Otherwise, no element of your draft appears to be clearly an improvement. Here's the original wording: The choice of primary units depends on the circumstances, and should respect the principle of strong national ties, where applicable. Here's yours (presumably also keeping the original's first 10 words and the link): respect the underlying principle of strong national ties as also used in MOS:TIES but in a different context. Mentioning the other guideline by name is redundant with linking to it, and all our P&G pages are fairly (not entirely) consistent in, when practical, using plain English with links around pertinent terms rather than injecting page names. Mentioning it by shortcut in particular is "newbie-unfriendly" and wrongly presumes memorization of our shortcut strings. "Underlying" is a puff word and doesn't serve a concrete purpose in the sentence. (And underlying what? It has no clear downstream referent.) "As also used in" is more redundancy; if we're linking to TIES as the locus of the principle, it's already automatically understood that the principle is applied at the place we're linking to. "But in a different context" is a combination of redundancy with the implication of the link again, and quite odd wording: Why is there a "but" in this? (What it is contrasting against?) "Different" from what? Different in what way? And "context" is conceptually misused in this construction, in that the general principle at TIES is a meta-context, of all usage/style disputes pertaining to national-level English dialects, while use of units is a subset of that, a sub-context, not a conflicting/alternative context. Finally, unit usage is only sometimes a subset of the usage in a national variety of English, thus the original's "where applicable" – a key point that your version drops, despite it seeming to be central to the bee in your bonnet.  — SMcCandlish ☏ ¢ 😼  11:54, 23 December 2024 (UTC)
    Introducing Scottish as an additional form of English would cause mayhem - or at least a shedload of future editing - here. We’ve already had a nationalist-driven push towards replacing ‘British’ with ‘English’ or ‘Scottish’ in bio articles, usually uncited and based purely on supposition or the subject’s birthplace. Fortunately, Scottish Independence appears to be receding as a prospect, at least in the short to medium term. MapReader (talk) 07:48, 23 December 2024 (UTC)
    I don't disagree (and we had a real template at {{Use Scottish English}} in 2013, with an attempt to re-create it in 2016). Several years ago, I tried to get rid of all the "Use Foo English", and related, templates declaring "national varieties" that, in reality, are completely indistinguishable from general British English in an encyclopedic register, and could all collectively be covered by a "Use Commonwealth English" template. ENGVAR only applies to national (not subnational) varieties, and only those dialects that exist in distinct forms and with a formal register (by definition: if you can't write encyclopedia-appropriate material in a dialect, then it doesn't belong in our articles for any reason, so ENGVAR cannot be used to "protect" it from edits). But nationalistic sentiments won out in the end, and we still have all that claptrap, with ridiculous results like articles being tagged with {{Use Jamaican English}}, {{Use Singaporean English}}, etc. (Likewise we have no use of American-splitoff variants, either, like "Use Guam English", etc.) Too many editors who should know better and should think just a tiny bit harder have utterly mistaken the purpose of these as something like "national pride" flags to put on articles, in a verging-on-WP:OWN manner. These tags absolutely do not resolve to "write an article about Nigeria using colloquialisms and grammatical oddities found only in the informal speech and writing of English in Nigeria, which will be confusing to everyone else in the world". If someone tries that crap in response to such a template, rewrite the material per MOS:COMMONALITY and MOS:TONE.  — SMcCandlish ☏ ¢ 😼  11:54, 23 December 2024 (UTC)

    MOS:NOTGALLERY

    At another talk page, I was writing an explanation of why articles should not be swamped in a plethora of images, planning to cite MOS:NOTGALLERY. Fortunately for once I checked first and found that it is just an alias for WP:NOTDB, not a statement that article spaces should not be mirrors of Commons.

    Given that the majority of visitors do so on mobile phones, is there a case for an explicit policy that says that curation is essential, less is more?

    Or would it be enough to change the target of NOTGALLERY to MOS:IMAGEREL (which might need a little expansion because right now it just says Images must be significant and relevant in the topic's context, not primarily decorative. They are often an important illustrative aid to understanding. When possible, find better images and improve captions instead of simply removing poor or inappropriate ones, especially on pages with few visuals. However, not every article needs images, and too many can be distracting. At least a reference to WP:ARTICLESIZE? (which is expressed in terms of word count, not megabytes, so would also need work). 𝕁𝕄𝔽 (talk) 17:48, 16 December 2024 (UTC)

    I think IMAGEREL would be a better redirect target. I want this to point to guidance that images should be included selectively rather than overwhelming articles with images. NOTDB instead seems to be guidance that images should be relevant and accompanied by text, which is not enough to prevent big indiscriminate galleries. —David Eppstein (talk) 20:52, 16 December 2024 (UTC)
    I've had second thoughts about this one. It is probably not wise to make NOTGALLERY an exception to the general rule that WP:NOTaaaaaaaa shortcuts all redirect to WP:Misplaced Pages is not. So the better plan is to add a short sentence to the current target to say that Misplaced Pages is not a database of images or a catalogue raisonné; those are among the functions of Wikimedia Commons. Image use in Misplaced Pages articles must comply with MOS:IMAGEREL. I will do that now.
    IMAGEREL needs some work too, to make it even more explicit that to bury an article in a mass of images is sure way to ensure that nobody reads it. --𝕁𝕄𝔽 (talk) 10:43, 17 December 2024 (UTC)
    While some types of "galleries" should be avoided, articles on certain visual topics do benefit from many visual examples. I also do not think we should explicitly outlaw the catalogue raisonné model while allowing many other bibliographic lists. One size does not fit all, and such a change would need to be debated with the folks curating WP:NOT and those who work on visual topics. —Kusma (talk) 10:57, 17 December 2024 (UTC)
    Pending further discussion, I have removed the reference to catalogue raisonné from my amendment (so that it now reads simply Misplaced Pages articles are not a repository of images: image use in Misplaced Pages articles must comply with MOS:IMAGEREL. to item 4, "Photographs or media files".
    I agree certainly that, in an article about an artist or an artistic movement, it is essential to illustrate the phases of their artistic development. That to me is clearly in keeping with IMAGEREL and wp:localconsensus can determine relevancy. But to include an image of every work in an artist's oeuvre? How is that a valid exception to NOTDB? (and likely a COPYVIO too). And why not show every putter manufactured by ACME Golf Inc? every locomotive made by ACME Rail Inc? every postage stamp (including all misprints) produced by the Austro-Hungarian empire? We have articles so swamped in pointless images that they have become essentially unusable to visitors on mobile. How does that make any sense? --𝕁𝕄𝔽 (talk) 11:34, 17 December 2024 (UTC)
    I would definitely oppose including every work in an artist's oeuvre in an article on the artist, but I want to make sure we do not outlaw List of paintings by Edvard Munch, where the images are perfectly encyclopaedic and just as relevant for identification as the images in List of members of the 19th Bundestag. Tables in such long lists are often not great for small screens, but that is a separate issue from the number of images. Generally, lists are not the same as other articles in their use of images, so the rules should reflect that. —Kusma (talk) 12:25, 17 December 2024 (UTC)
    I don't see a problem with that. Clearly the application of IMAGEREL should (and would) be different between a list article v a fairly broad concept article. To take your example, it would be entirely reasonable to include every image we have in the list article, provided that we use small thumbnails (upright=0.2); conversely (IMO) the bio article about Munch should be curated so that it has just one carefully chosen image to illustrate each phase of the development of his style , with maybe one or two especially notable examples that he did . Surely we don't want to replicate Commons? --𝕁𝕄𝔽 (talk) 18:23, 17 December 2024 (UTC)
    Please, let's not compromise the full extent of the encyclopedia by limiting what has always been one of its main features. Images and galleries define and describe just as much as text. That many choose to "read" Misplaced Pages on tinier gadgets should not dictate the coverage and image-styling of encyclopedic content articles. Randy Kryn (talk) 11:49, 17 December 2024 (UTC)
    The problem we have at the moment with some articles is what David Eppstein describes above as "big indiscriminate galleries" and rote copying of everything in Commons for no evident informative purpose, a form of visual clutter. As IMAGEREL begins, "Images must be significant and relevant in the topic's context, not primarily decorative. They are often an important illustrative aid to understanding". Without curation, the information gets buried in the woodpile.
    I am not proposing a principle that we must minimise the number of images, period. My proposal is that we provide a policy basis that editors can use to say "that point is already adequately illustrated, another image adds nothing new" or "this article had become so bogged down in images that it no longer navigable". I am talking about edge cases here, in most articles it is not an issue. But some have become swamped in an uncritical replica of Commons. This is not to enable wikilawyering, it just makes it easier to explain the rationale. --𝕁𝕄𝔽 (talk) 18:23, 17 December 2024 (UTC)
    As an example of the sort of burying articles in galleries that I would object to, see hexagonal prism, where (at least in its current version) four of its six sections are entirely image galleries (in some cases hidden in collapsed templates, with much of their content peripheral to the main article topic).
    We do need wording that distinguishes this case from List of paintings by Edvard Munch, where the galleries are entirely appropriate, though. —David Eppstein (talk) 18:29, 17 December 2024 (UTC)
    But as far as I can see, the List of paintings by Edvard Munch (and similar lists by artists) already complies with IMAGEREL, because the use of images in that article is proportionate and entirely relevant to that context. Conversely, to put all those paintings in the Munch bio article as a giant gallery would not be proportionate (IMO).
    So to focus this discussion, can anyone suggest another sentence we can use to amplify the point made in the opening sentence of IMAGEREL? ("Images must be significant and relevant in the topic's context, not primarily decorative. They are often an important illustrative aid to understanding".) How about

    Consequently, each image in an article should have a clear and unique illustrative purpose: for guidance, see less is more.

    AFAICS, that responds to and respects both the Munch examples above. (FWIW, very few if any of the visual arts articles suffer from this swamping problem. The issue affects high profile articles like Swastika.) 𝕁𝕄𝔽 (talk) 11:29, 18 December 2024 (UTC)
    It is entirely enough that we have the MOS:IMAGEREL shortcut. A proposal to retarget WP:NOTGALLERY to that would almost certainly fail, because it's part of a very long-standing set of policy (not guideline) WP:NOTFOO shortcuts to sections of WP:NOT, and such a change would both confuse editors today and render archived discussions of policy misleading. "Ain't broke; don't fix it."  — SMcCandlish ☏ ¢ 😼  06:10, 23 December 2024 (UTC)

    Audio video guidance

    Hi there, I'm noting a lack of guidance for Audio video content, I've mentioned this at Wikipedia_talk:Manual_of_Style/Images. It seems people just edit MOS rather than run through large discussions, but I'm reluctant to start plunging in before getting some help. Here is what i think is needed:

    • Something explaining that the guidance at Misplaced Pages:Manual of Style/Images applies to Audio-video content in most cases, eg regarding relevance, image quality, textual information, offensive images, placement, size, location, availability. Nearly all of the page is relevant, in fact.
    • The download advice might need to be different. Do videos or audio need a warning that they are large files? This is not assumed, it seems.

    There is a case for some separate AV guidance, regarding:

    • Length: should inline videos be shorter where possible? Does this apply to audio clips?
    • Language: if audio or video is original language, should subtitled content be preferred rather than recording originals? Should songs be subtitled where possible? What are the requirements for validating translations (what are the relevant WP policies on translation of original source material that apply?)
    • Rendition: historical accents and historical musical performances might be very rare. Should we say that modern standards are fine, in the absence of authentic reconstructions?
    • Public domain renditions: if audio or video is a rendition of a public domain source, for example a work by Mozart, or a speech by Caesar, what are the requirements for source validation (these should reference WP's general guidelines, but these are mostly focused on secondary sources).

    Jim Killock (talk) 20:25, 16 December 2024 (UTC)

    • Elsewhere, someone asked whether an RfC would be needed to add guidance on this topic. I think not -- while discussion will be needed on details, I can't see anyone objecting to clarifying that multimedia beyond everyday images should follow similar guidelines to those for image. The question is where to say that. We don't want to duplicate guidance on contextual significance etc., because that creates two things that need to be kept in sync. Probably the best thing is to expand MOS/Images to explicitly cover other multimedia. See BTW Misplaced Pages:Manual_of_Style/Music_samples, which has a contextual significance section. EEng 20:39, 16 December 2024 (UTC)
      Thanks very much (and yes that was me!) I agree that MOS:Images would be best, especially to get this started.
      The contextual significance contains much about in-copyright works. That is in general very helpful. In-copyright video samples feels like something rather complex that might need an RFC, and might be best parked until there is a little more in place. Jim Killock (talk) 20:49, 16 December 2024 (UTC)
      @EEng Would it be helpful if I draft up something on Wikipedia_talk:Manual_of_Style/Images and ask for feedback? Jim Killock (talk) 21:03, 16 December 2024 (UTC)
      I suggest you wait a while so that the experienced editors gathered here can lend their thoughts. After that, you might take the conversation back to Talk:MOS/Images, but since that page has 1/5 watchers of this one, and you've already put a pointer there to this thread here, it might be better to continue here as you begin to draft. There's no hurry to this, so the slower you take it, and the greater the extent to which others can get their thoughts in, the smoother it will go. (I'm afraid I'm really tied up IRL so the time I myslf can contribute is limited.) EEng 21:24, 16 December 2024 (UTC)
      Happy to wait. I made a stab at below, but I can wait for further thoughts / feedback here. What I've provided relates to historical source content, as most of the AV I've been dealing with falls into this category; I have guessed at some other considerations but it is currently narrower than it should be. Jim Killock (talk) 21:44, 16 December 2024 (UTC)

    Audiovisual content can also be used for illustrative purposes. Most of the guidance on images above applies to audio visual content. Additionally, consider:

    • Length: inline videos or audio that is shorter will be easier for users to watch. Consider clipping long form content, and linking to the original on Commons, or elsewhere. Longer videos (eg, over 10 minutes) may be more suitable for links than inline video, unless they are highly relevant to the page's subject.
    • Rendition: historical accents and historical musical performances of content may be very rare. Modern renditions are fine, where authentic reconstructions are not available, and may be preferred, where there is uncertainty about the original performances.
    • Musical, poetic and literary content: aesthetic considerations are higher for these kinds of content. Where possible, the performances should be considered good by other editors. Where editors find performances are poor, content should generally not be included.
    • Language: where audio or video is in the original language, subtitles should generally be preferred rather than translated versions, as this reflects the original more closely and text files are easier to correct than mistakes in audio-visual content. Where possible, songs should be subtitled. Original language versions should be made available where where possible for artistic content.
    • Translations of subtitles should be verifiable, but as with other Misplaced Pages content, competent editors can create them. While academic translations are preferred, where subtitle translations are longer than 10-20 words, use of academic translations is likely to constitute copyright infringement. Here, a Wikipedian's translation should ideally be verifiable against an academic translation. (See Non-English sources for further guidance.)
    • Public domain renditions: if audio or video is a rendition of a public domain source, for example a work by Mozart, or a speech by Caesar, the original sources must be valid. The performance should be comparable and follow the original. Where possible, include links on media file pages so that editors can make checks.
    • Sourcing: as with images, sourcing of audio-visual content needs to be copyright compliant. Sources of CC video and audio can include Youtube, Flickr and CC search tools. Care should be taken to ensure the licensing claims appear to be valid.
    • See also: Misplaced Pages:Manual of Style/Music samples

    Jim Killock (talk) 21:50, 16 December 2024 (UTC)

    The "Language" point is a bit unclear to me. Is it asking for subtitles to be in English or the original language? If the phrase "rather than translated versions" is referring to the spoken or written material, that seems to contradict the phrase "where audio or video is in the original language". Which is also a weird way to say it because the "original language" could be English. Given that this is English Misplaced Pages, an English version should be provided whether or not there is a non-English version.
    Subtitles should be provided for all videos with an audio track, to make them accessible for readers who cannot hear or find it difficult. There are additional guidelines at MOS:ANIMATION.
    Not sure the "Sourcing" point needs to be made, as this is explained in detail for images generally.
    The "Length" point should probably link to the Misplaced Pages:Manual of Style/Music samples and point out the copyright issue when displaying here under fair use. It should say "video" not "videos" to be grammatical.
    I would drop the "Translations of subtitles" point and just link to WP:NONENG for guidance on translations.
    The "Public domain renditions" point does not make any sense to me, and I would just drop it.
    I'm not sure whether the "Rendition" point needs to be made, but if it does, it's confusing. I think it's supposed to be recommending that historically accurate renditions of older works are preferred, if available. Maybe that's true, maybe it isn't, depending on what the purpose of inclusion in the article is. Might be better just to leave this point off; I don't see any similar guidance for audio samples of music. Page editors can decide which samples are best out of those available.
    Another point probably worth making is that a video should be considered an optional part of an article. In other words, any content vital to reader understanding should be included in the text and not be omitted on the assumption that reader will watch the video. Many readers will not be able to view video due to technical limitations, such as using a web browser that is not configured with a video player, or reading an article in another medium such as an app, paper printout, or text-to-speech system (including those who cannot see or find it difficult to read text). There is more specific guidance against putting text in images at MOS:TEXTASIMAGES.
    It's fine for a video to re-explain something that's already explained in the text if having a moving image clarifies substantially, but it seems wasteful for embedded videos to effectively repeat or rephrase the text.
    -- Beland (talk) 22:49, 16 December 2024 (UTC)
    Thanks very much!
    • Regarding language, this was meant to be about non-English content, think Bach or Mozart in German or Latin; or Goethe's poetry.
    • On Sourcing, the section on images does not include YT, which is significant for CC video.
    • On translation, the situation for subtitles is a bit different, as usually you cannot use academic in-copyright translations, so this mention is retained.
    • On public domain renditions, this was the subject of a long and unclear discussion recently. Does that help? Take a file such as File:Queen Elizabeth I's Reprimand of an Insolent Polish Ambassador..webm. There is some need for verification, even tho it is not being used as a citation? I've edited it for clarity.
    • On style of renditions, this has come up a few times in discussion, including at the link above, where a user claimed only a Catholic priest could do a Latin audio recording; also at a parallel discussion on LA Misplaced Pages about accents and delivery, preferring a modern standard over historical guesses. I figured the same principle might apply to say reading Shakespeare, or using 16th century instruments; it simply shouldn't be a consideration, but sometimes editors think it should be.
    • I've added the points on (1) text as images, (2) subtitles for EN content, (3) optionality of AV content
    VERSION 0.2
    Audiovisual content can also be used for illustrative purposes. Most of the guidance on images above applies to audio visual content. Importantly, audio-visual content should not be an essential part of a page, which is necessary to understand the whole. This is because not all readers will be able to download or access the content, for example because of technical limitations or relying on text to speech tools. With audio and video just as with any content, relevance is paramount; consult WP:DUE for further context. There must be a clear reason for including the content on the page.
    Additionally, consider:
    • Length: inline videos or audio that is shorter will be easier for users to watch. Consider clipping long form content, and linking to the original on Commons, or elsewhere. Longer videos (eg, over 10 minutes) may be more suitable for links than inline video, unless they are highly relevant to the page's subject.
    • Rendition: historical accents and historical musical performances are not required. Modern renditions of audio are acceptable. For example, there is no need to read Shakespeare with an Elizabethan pronunciation.
    • Musical, poetic and literary content: aesthetic considerations are higher for these kinds of content. Where possible, the performances should be considered good by other editors. Where editors find performances are poor, content should generally not be included.
    • Subtitles for comprehension: In English language videos, an English language subtitle track should always be provided for accessibility. See MOS:ANIMATION for more details.
    • Subtitles for translation: where audio or video is originally in a non-English language, for example a Goethe poem, subtitles should generally be preferred over than translated audio, as this reflects the original more closely and text files are easier to correct than mistakes in audio-visual content. Where possible, songs should be subtitled. Original language versions should be made available where where possible for artistic content.
    • Translations of subtitles See Non-English sources for guidance. Note that longer subtitle sequences may need to be translated by Wikipedians rather than obtained from academic sources to avoid copyright infringement.
    • Embedding text: As with images, rendered text should be avoided in video content. See MOS:TEXTASIMAGES for more information.
    • Public domain renditions: if audio or video is a rendition of a public domain source, for example a work by Mozart, or a speech by Caesar, it must be possible to check the original scores or texts. An editor should be able to compare the performance with the original. Where possible, include links on media file pages so that editors can make checks.
    • Sourcing: as with images, sourcing of audio-visual content needs to be copyright compliant. Sources of CC video and audio can include Youtube, Flickr and CC search tools. Care should be taken to ensure the licensing claims appear to be valid.
    • See also: Misplaced Pages:Manual of Style/Music samples
    Jim Killock (talk) 23:32, 16 December 2024 (UTC)
    This appears to be related to situations such as Talk:Niccolò_Machiavelli#RFC_on_video_inclusion, where a video consisting of a person reading a letter aloud was included in an article, one example of a series of such edits. It is not clear to me that we need a bunch of guidelines about the best form for this sort of application because it is not clear that it is desirable to include such videos in the first place - the cart is being put before the horse. MrOllie (talk) 23:54, 16 December 2024 (UTC)
    Yes, I certainly would like to clear up some of the misapprehensions that regretfully appeared in that discussion. It's a discussion I will deeply regret getting involved in for some time.
    I'll be clear about the other discussions and examples of this content for context:
    @MrOllie I hope you can at least see that normally I try to be as collaborative as I can be. there's not much point going further into why that discussion became hard for me. However, policy is the place where we make guidelines to avoid disputes and lack of clarity.
    What meets WP:DUE overrides any other consideration, to my mind so I have added that to the draft text. (With audio and video just as with any content, relevance is paramount; consult WP:DUE for further context. There must be a clear reason for including the content on the page.) Jim Killock (talk) 00:12, 17 December 2024 (UTC)
    As regards the other articles where there was no discussion, just because there was no dissent at the moment doesn't mean there wont be in the future. What happened at the Machiavelli article could just as easily happen in the other ones
    I am also asking you kindly to please stop making the issues with that RfC bigger than what they are. Plasticwonder (talk) 00:27, 17 December 2024 (UTC)
    We can take this discussion in two ways:
    • We can either construtively discuss the principles behind what video content should be allowable; or
    • We can decide that emotions are too high for it and pause it
    I do need this guidance, because there are divergences of opinion on some of the points, and it's important to me to be able to resolve them. But my guess is that if the three of us are just going to rehash the RFC discussion, then that would a terrible use of other people's time and energy. A break off would make sense, in my view. Jim Killock (talk) 00:41, 17 December 2024 (UTC)
    No one's emotions are high but yours, judging by your rather relentless snipes against my character and the fact that you have so much as admitted it in the RfC. You have also stated that the RfC "needed to die" (quite strong words) when I gave you a chance to change your mind, and now you want to pause now that the discussion is nearing a close?
    I do not get what you are trying to accomplish here, to be fair. Plasticwonder (talk) 00:47, 17 December 2024 (UTC)
    It is not needed to rehash the RFC here, but I did feel that fresh eyes on this talk page should have enough context to understand what the proposal is about. MrOllie (talk) 00:48, 17 December 2024 (UTC)
    Thanks, I appreciate that as a valid concern. Does the change regarding WP:DUE help, or do you feel more is needed? For context, other points raised in the RFC such as regarding the need to be able to validate translation is also included. Jim Killock (talk) 00:54, 17 December 2024 (UTC)
    I dropped the video from Henry VIII; it seemed like excessive detail. It's already on Defence of the Seven Sacraments where it's a bit more appropriate. But even there, it seems like it violates the video equivalent of MOS:TEXTASIMAGES. Same for Martin Luther and On the Bondage of the Will.
    I also posted that the video for Elizabeth I should probably just be kept on Commons; there's already a general link to the topic there.
    I agree it's not clear that videos of performances of works should generally be included, so I would also be hesitant about specifying anything in particular about those. Uploaded videos cover a broad variety of subjects, including scientific phenomena, buildings, and specific events. -- Beland (talk) 03:22, 17 December 2024 (UTC)
    I would like to understand MOS:TEXTASIMAGES a bit more, especially regarding accessibility in particular, as this is certainly an overriding concern. What makes the text subtitle files inaccessible and not regarded as text? Jim Killock (talk) 09:09, 17 December 2024 (UTC)
    Subtitles are, of course, text. They are less accessible than the text in an article because some readers will have technical or logistical difficulty watching video and thus reading subtitles or listening to audio narration. For readers that do watch a video (which presumably has an animation or something which illustrates the subject of the article in a way a still image cannot), it increases accessibility by allowing people who cannot hear or find it difficult to know what is being said or what sounds are happening in the video. -- Beland (talk) 15:37, 17 December 2024 (UTC)
    Misplaced Pages:Image use policy already says that for user-created diagrams, etc., a source for the underlying data must be included. To me, this applies straightforwardly to videos that are presenting public-domain content. A citation to the original work is kind of implied, but a reference to a specific version or even better an online copy, should suffice. YouTube videos that we're importing into Misplaced Pages as on-article videos are no different than diagrams or maps or explanatory videos uploaded by random Misplaced Pages or Commons users, assuming an appropriate copyright license. The reliability of YouTube is not really in question, any more than the reliability of any given Misplaced Pages editor is, when they are just repackaging information from a different underlying source in a more digestible way. That's different than citing a YouTube video as a reliable source for the information itself.
    I'm not sure I have enough examples to make a guideline about video length. Ten minutes seems way too long for download on a mobile phone, and most videos I would expect to be under a minute. Perhaps there are exceptions, but I'd want to survey how videos are being used now. In the meantime, I would trim the 0.2 version down to reduce scope and reduce overlap with other pages and rephrase and retitle:
    ----
    Video content (v. 0.3)
    • The guidelines on this page also generally apply to videos.
    • Many readers will not be able to play videos, because of technical limitations of their web browser, because they are seeing article content on a different web site or app, or because they are using a different medium, such as paper or text-to-speech system. Some readers cannot see or find it difficult. Videos should be used as a supplement to article material, to concisely illustrate the subject in a way that a still image or text cannot do. Videos should not replace article text, and articles should remain coherent and comprehensive when video playback is not available.
    • Similar to MOS:TEXTASIMAGES, for accessibility and file size reasons:
      • Videos that simply show text should be replaced with text.
      • Videos that simply show a sequence of still pictures should be replaced with an image gallery.
      • Videos of text being read aloud should be replaced with text, or if the sound of words is being demonstrated, audio files (with the text being read in the file caption or in closed captioning).
      • Videos of text and narration with should be converted to article text.
    • The copyright and other guidelines on Misplaced Pages:Manual of Style/Music samples also apply to video samples.
    • The policies on Misplaced Pages:Image use policy also generally apply to videos.
    • Accessibility guidelines at MOS:ANIMATION apply.
    ----
    -- Beland (talk) 03:56, 17 December 2024 (UTC)
    Misplaced Pages:Videos has additional suggestions; not sure if it's appropriate to link there from here. -- Beland (talk) 03:57, 17 December 2024 (UTC)
    With your commentary, this makes a lot of sense. I would point out that there was a lot of heat generated over YT reliability in the aforementioned RFC, so it would be good to point that it can be used. YT is not mentioned as a source for images in the images section above; an alternative would be to add it there in the list of common sources, but that also seems odd. I know one can point to the archive discussion, but that is not generally available knowledge for anyone looking at the guidance in future. Jim Killock (talk) 09:14, 17 December 2024 (UTC)
    I added a clarifying note at Misplaced Pages:Reliable sources/Perennial sources for YouTube; hopefully this will not be controversial. -- Beland (talk) 02:44, 18 December 2024 (UTC)
    Unfortunately that has been reverted as "unnecessary". It might make more sense here, because this is about video as illustration, and there is parallel advice for images above about CC content sources. Perhaps it should be parallel advice to this, eg mentioning that YT has a search facility for CC content (and there isn't anything else AFAIK). Jim Killock (talk) 09:10, 18 December 2024 (UTC)
    I started a discussion at Misplaced Pages talk:Reliable sources/Perennial sources#Imported YouTube videos. -- Beland (talk) 20:21, 18 December 2024 (UTC)
    Thanks - quick observation that we have lost that the guidance for illustrative audio content would also generally derive from the images guidance. The music samples page linked is wholly focused on samples from copyrighted material; there is a lot of PD / CC music material on WP, especially for classical music. Sometimes this could do with subtitling, etc, care in positioning, checks for relevance, etc. Jim Killock (talk) 09:36, 19 December 2024 (UTC)
    OK, what are you suggesting? -- Beland (talk) 18:59, 19 December 2024 (UTC)
    I think, where appropriate, add audio, eg "The guidelines on this page also generally apply to videos and audio files"; maybe "where appropriate, for instance non-English language audio files should include subtitles". I'm not sure there is much else. Jim Killock (talk) 22:56, 19 December 2024 (UTC)
    And where would you find that addition to be appropriate? -- Beland (talk) 02:37, 20 December 2024 (UTC)
    I would amend the title to "Video and Audio content"; I would amend bullet one to "The guidelines on this page also generally apply to videos and audio files". Under "Similar to MOS:TEXTASIMAGES, for accessibility and file size reasons:" I would add "where appropriate, for instance non-English language audio files should include subtitles". The accessibility guidelines could move to be bullet two, in order that audio and video advice is at the top. Jim Killock (talk) 08:02, 20 December 2024 (UTC)
    It looks to me like hardly anything on Misplaced Pages:Manual of Style/Images applies to audio files, and it seems like the wrong place to go looking for style advice about them. -- Beland (talk) 22:52, 20 December 2024 (UTC)
    For example:
    These seem pretty substantially helpful guidance to me, and pretty similar level of relevance as to video files. Jim Killock (talk) 09:10, 21 December 2024 (UTC)
    Yeah, most of the material in those sections is not relevant to audio. I'd say if you feel strongly that guidance is needed for audio generally and not just music samples, we should create a new page. Editors shouldn't have to read through a whole page about images just to pick out the occasional tidbit on audio files, if they're only interested in the latter. -- Beland (talk) 20:32, 21 December 2024 (UTC)
    I've posted the 0.3 draft for now, since that wouldn't be changed by adding an audio page somewhere else. -- Beland (talk) 20:46, 21 December 2024 (UTC)
    Thanks for posting the v 0.3. On audio, I would think about this from a few user perspectives:
    • There is currently no MOS advice at all on audio files and approaching general layout, pertinence, etc. What would the user do? Currently, MOS offers them nothing, so they must either guess or work off examples on other pages.
    • If a user asks for advice, where would they be pointed? (my guess: MOS:Images as closest match.
    IMO, it would be better to offer them something, even apologetically ("There is currently no detailed advice on MOS regarding use of audio files, but the basic principles of WP:DUE and some considerations at MOS:Images may be helpful.") This could be placed at a page relevant to other audio usage files, for example. Jim Killock (talk) 10:02, 22 December 2024 (UTC)
    Feel free to propose a draft if you like. It's also possible no particular guidance is needed, if people are able to figure this stuff out using common sense and regular editorial judgement, and if disputes arise, turn to the various policy and guideline pages on topics like due weight. -- Beland (talk) 21:56, 22 December 2024 (UTC)
    Given the small amount of material to include about this, and the redundancy that would be required with MOS:IMAGES if "MOS:VIDEOS" were its own page, and given the short nature of the audio samples MoS page, I think the most sensible approach is to merge all of this into a WP:Manual_of_Style/Images_and_multimedia page with a top MOS:MEDIA shortcut (which I'm surprised doesn't already exist as an internal disambiguation page), then MOS:IMAGES, etc., going to sections. We have too many separate MoS pages as it is, and this is an ideal merge of two of them and a proposed third.  — SMcCandlish ☏ ¢ 😼  06:07, 23 December 2024 (UTC)
    Sure, that's a reasonable alternate approach. I think it would work if we put the things that apply across all three at the top, and then make it clear with section headers which those interested in a specific media type should look at without having to read inapplicable guidelines. -- Beland (talk) 08:22, 23 December 2024 (UTC)
    +1 to both of these observations. Jim Killock (talk) 09:04, 23 December 2024 (UTC)
    Yeps. If we hammer out a videos-related section, I'll be happy to do the work (most MoS merges and the like are done by me because I kind of have a database in my head of all the rules and how they interrelate, and 19 years of observing how misinterpretations, lawyering, and other problems can be avoided by careful wording.  — SMcCandlish ☏ ¢ 😼  14:23, 23 December 2024 (UTC)
    I think what we could agree on for videos has been added. -- Beland (talk) 00:27, 24 December 2024 (UTC)

    misleading text in Misplaced Pages:Manual of Style#Dashes

    The text on keyboard entry of dashes in Misplaced Pages:Manual of Style § Dashes is misleading. The text or on a Windows keyboard implies a technique specific to windows when in fact it is valid for any OS. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:20, 18 December 2024 (UTC)

    True. What it should say: "on a Windows keyboard enter them manually as Alt+0 150 (on the numeric keypad) for en dash, and Alt+0 151 for em dash." -- Michael Bednarek (talk) 16:02, 18 December 2024 (UTC)
    Wrong on two counts:
    1. No. It should not say anything at all, per WP:NOTHOWTO.
    2. And even if it does, those alt codes are only valid for code page 1252 and related. They don't work if the user has a different default code page installed.
    Delete it completely. --𝕁𝕄𝔽 (talk) 17:23, 18 December 2024 (UTC)
    I doubt that NOTHOWTO is meant to apply to the MOS. It's surely helpful for editors and hence should stay, reworded if needed. Gawaon (talk) 08:26, 19 December 2024 (UTC)
    Gaewon is correct: NOTHOWTO applies to articles only. MOS is littered with how-to stuff, as is should where the ratio (editor confusion and time saved)/(WP:MOSBLOAT) seems sufficiently high. However, if this starts getting into weeds of code pages and such, it may be best to relegate the whole thing to WP:How to make dashes, with a pointer to that from MOS. EEng 20:28, 19 December 2024 (UTC)
    So why not simply recommend {{mdash}}, {{ndash}} and {{snd}} rather than advise keyboard callisthenics? --𝕁𝕄𝔽 (talk) 20:36, 19 December 2024 (UTC)
    Yes, I have always advocated symbolic representations (templates such as you list, or html escapes such as &mdash;) of the various dashes (and in some cases, even hyphens), rather than having them appear literally in the wikisource, so that editors can see at a glance that the right character is present. But even though EEng is pretty much always right, I can't seem to get people on board with this. EEng 20:49, 19 December 2024 (UTC)
    I am happy typing the dashes on my Apple keyboards but also happy with recommending the templates rather than giving keyboard-specific advice. What I would like to avoid is warring bands of gnomes going around changing unicode dashes to templated dashes and vice versa. —David Eppstein (talk) 21:31, 19 December 2024 (UTC)
    Edit conflict: yes, different route to the same answer. --𝕁𝕄𝔽 (talk) 20:38, 19 December 2024 (UTC)
    JMF's policy understanding is mistaken above. WP:NOTHOWTO only applies to article content (and other reader-facing content, like portals and the front page features). If it applied to internal documentation, then we would have to delete the entire "Help:" namespace and about 95% what is in "Misplaced Pages:" namespace. However, the technical point JMF raised is entirely correct, and we should not be telling editors to use keyboard codes that will do the wrong thing (or nothing) if they don't happen to be using the "right" code page. To simply recommend {{mdash}}, {{ndash}} and {{snd}} is the sensible approach.  — SMcCandlish ☏ ¢ 😼  06:02, 23 December 2024 (UTC)
    Let's just direct people to Misplaced Pages:How to make dashes. --Redrose64 🌹 (talk) 23:00, 23 December 2024 (UTC)

    Is there a MOS guidance that applies to changing between common terms based on the name of the Wiki article?

    Do we have a guideline for dealing with different name, common names for the same thing (Inline-four engine vs Straight-four engine)? The target article, Straight-four engine, has used both names (changed in 2009 and 2022). Sources use both terms but I think the shorted "I4" is used more often in sources. I presume we would follow something like the MOS:ENGVAR where if there is no source preference we go with what the editors used first. Recently an editor, Kumboloi, made a number of good faith changes in linking articles from "inline-four" to "straight-four" to align external article text with the target article name. Is there a guide on this? How should this be handled? Springee (talk) 14:55, 22 December 2024 (UTC)

    It's a policy, our naming conventions policy, which largely doubles as our policy on article titles. Generally, for a given thing there's no reason to use a different name in the prose of any other article than one would use in the article about the thing itself, if that makes sense.Remsense ‥ 论 14:57, 22 December 2024 (UTC)
    I'm not sure where the naming convention says we should change article text in a case like this. The article in question indicates both names are common (A straight-four engine (also referred to as an inline-four engine)). This is also reflected in the two name changes over the years. I don't see where the naming convention says we should favor the target article name vs what the individual article sources are using. Consider a hypothetical, I'm created a Wiki article about the new "CarX". My RS source that says, "CarX uses an inline four engine". Why would I not follow the source vs use the title of our straight four article? This is especially true if if the hyperlink is added later by a different editor. Also, until 2022 the title of the article was "inline". A consensus of 3 editors changed the article name. That's fine but the result is many changes to other articles. If a new consensus of 5 editors reverses the change do we flop back? I think it's less disruptive (makes articles more stable) if we avoid article text changes in cases like this. However, I am interested in knowing what guidance might apply here. Springee (talk) 15:52, 22 December 2024 (UTC)
    I'm interested in understanding this. My motivation in making the edits came down to a suspicion that there was some type of penalty incurred by linking through a redirect page, or that the redirects imposed a maintenance overhead. I hadn't read the naming convention, but if there's no real reason to reduce the number of redirected links, and recognizing that the target page could just as easily be renamed again in the future, I'll stop doing these edits. (Personally, I prefer "inline" to "straight", but I can see how the renaming would help organize the associated pages.) Thanks. Kumboloi (talk) 15:56, 22 December 2024 (UTC)
    My reasoning is WP:NC stresses how we are required to name things, as we are un all editorial decisions, based on WP:V and WP:NPOV (in many cases this boils down to the result of WP:COMMONNAME). It has provisions specific to the article title and not the body, but much of it is expressing how to apply V and NPOV in deciding what to call things.
    If we take alternative names as such—e.g. that, all else being equal, we do take inline four and straight four to be synonyms, truly referring to the same thing for our purposes—it makes very little sense to "wall off" which names are used in a particular article, as there are no clear limits on how strictly this would have to be observed. Am I allowed to use any synonymous nouns, verbs, or adjectives in my synthesis that don't happen to appear in my three best sources? On the other hand, naming according to a generalized scope is surely more coherent for a hyperlinked encyclopedia providing tertiary analysis instead of merely refactoring and reshuffling the specific language of our secondary sources.
    Of course exceptions abound, much of the time alternative names and redirects should be freely used according to syntactical and contextual concerns—but I believe this to be correct mindset to assume by default. I don't think any given article that uses First World War needs to be changed. However, in cases like these, I feel it pays dividends to use terminology consistently between pages. If readers are encountering technical or domain specific language for the first time, we create the most helpful and coherent tertiary analysis for them if we zoom out a bit. It makes no sense to prefer Sassanid to Sasanian just because the book we're citing prefers the former—e.g., in an article about a specific battle, or a broad conceptual article not specific to the Sasanians—our deliberately preferring Sassanid simply does not aid the reader in becoming familiar with whatever additional context they're going to go to Sasanian Empire for in order to better understand our other article.
    If I wake up and find this totally incoherent, I apologize. It's hard to speak clearly about naming and reference, though it's one of my favorite things to think about. Remsense ‥ 论 16:49, 22 December 2024 (UTC)
    WP:NOTBROKEN clearly says: "Piping links solely to avoid redirects is generally a time-wasting exercise that can actually be detrimental. It is almost never helpful to replace ] with ]." So if a link already leads to the correct article, but using an alternative name that redirects, that's absolutely fine and nothing more needs to be done. I realize that you're probably not talking about piping, but about changing the link text and link target together – but that too is unnecessary if the existing link target works fine (by redirecting). Gawaon (talk) 17:12, 22 December 2024 (UTC)
    Kumboloi, thanks for that explanation. It reaffirms my believe that you were acting in good faith (I hope you took my revert that way as well). Springee (talk) 19:11, 22 December 2024 (UTC)
    I think there needs to be a good reason to not use the article title in text (and they do exist), and that can be discussed on a per-case basis at the relevant article (or other) talk page.—Bagumba (talk) 17:19, 22 December 2024 (UTC)
    Agreed. Remsense ‥ 论 17:21, 22 December 2024 (UTC)
    Just so long as it is realized that THERE RATHER OFTEN IS A GOOD REASON! National language preferences for one thing. Busywork drive-by changes should be strongly discouraged. Johnbod (talk) 18:48, 22 December 2024 (UTC)
    Goes without saying! Remsense ‥ 论 19:04, 22 December 2024 (UTC)
    I just thought I'd drive by and agree with that. EEng 22:10, 22 December 2024 (UTC)
    The answer the the OP's question is "More or less yes", in the form of MOS:STYLEVAR. Remesense's idea above that article titles policy and its dependent naming-conventions guidelines and essays (which actually defer to MoS on style questions) somehow dictate in-article content. They absolutely do not, or we would simply merge them. However, agreement with the page title can actually qualify as a good reason for a text change under STYLEVAR a lot of time, such as when a old page title (and our mirroring of it in the text) was a misnomer, unhelpfully ambiguous, obsolete, or obscurantist. When such problems don't apply, then having more than one way to refer to the subject is a boon to editors and readers, since it allows us to write less repetitively. But the lead should almost always agree with the title, and start with the term/name in the title and secondarily provide any noteworthy alternative(s). Some exceptions of course apply, such as when a term/name in the title is a colloquialism and used for WP:COMMONNAME purposes in the title but is not the best way to introduce the first sentence (this is especially common at biographical articles, in which we often give the full "Elizabeth" or "Robert" name of someone more commonly called "Liz" or "Bobby" and given that way in the page title).  — SMcCandlish ☏ ¢ 😼  03:28, 23 December 2024 (UTC)
    I think they must dictate in-article content to a degree at least—it would make no sense to use a particular name in the title and initial definition (I've been assuming congruence throughout, e.g. no disambiguators considered) and then never again. Remsense ‥ 论 03:36, 23 December 2024 (UTC)
    That's a correlation/causation mix-up. What you're talking about is just WP:Common sense (to the point of "Don't be intentionally perverse as if with a goal of confusing readers as much as possible") and a matter of MOS:BETTER. It's not an element of title policy or of naming conventions, which do not address article content (except a few of the worst-written NC pages have a statement or two in them about body content that needs to move out of those pages; I've been cleaning those up as I run across them).  — SMcCandlish ☏ ¢ 😼  14:18, 23 December 2024 (UTC)
    I've been racking my brain trying to articulate exactly what I mean here, but I do not think it is merely correlative. Hopefully that is a useful thought inasmuch beyond just the trivial truth that the language one is exposed to affects the language they go on to use and think in terms of. Remsense ‥ 论 19:32, 25 December 2024 (UTC)

    Legibility of thumbnails at default size

    Moved from Misplaced Pages talk:Manual of Style/Images § Legibility of thumbnails at default size
    Noisy haze at 220px
    Noisy haze at 165px

    I am surprised there is no direct statement along the lines of If possible, the selection, placement, and sizing of images should allow readers to fully decipher what they are intended to illustrate; thumbnails should be legible with the default base size of 220px without requiring readers to expand them. It seems like much of the guidance has this as an unstated goal, but there are cases where it is slightly less intuitive that this is a principle that editors should heed. My one worry is hypothetical quibbling over what any given image is intended to illustrate—is the specific text written on a street sign important for illustrative purposes?—but I feel like that's totally explicable in each instance via editor discussion. It's clear that some appropriate images cannot be legible at thumbnail size in context, either because they are visually intricate or the placement context simply won't allow it, but it seems helpful to state that editors should make an attempt when it is possible. Remsense ‥ 论 16:02, 21 December 2024 (UTC)

    @Remsense: Can you give an example? Magnolia677 (talk) 16:39, 21 December 2024 (UTC)
    Clicked around until I found one: at Crony capitalism#In sections of an economy, it's not really possible for me to discern the field of figures as men sitting at desks rather than just noise. This image should be displayed at a slightly larger size, and maybe cropped a bit.
    Another class of examples is insignia and coats of arms, where arguably key details that would be legible in the original contexts are illegible at thumbnail sizes in infoboxes, especially in cases where there are especially elaborate versions that editors sometimes opt for out of a misplaced sense of completeness (I guess). Remsense ‥ 论 17:03, 21 December 2024 (UTC)
    They're everywhere. Magnolia677 (talk) 21:23, 21 December 2024 (UTC)
    That is something that gives me pause: this seems like a common-sense guideline to me, but either it's so obvious that it shouldn't be a guideline (?) or it's not nearly as obvious to others. Remsense ‥ 论 21:48, 21 December 2024 (UTC)
    I've always found it odd that we don't have a minimum size recommendation. Can't tell you how many times I see collages or galleries that have teeny mini images that lack accessibility for all. Moxy🍁 03:49, 22 December 2024 (UTC)
    It's a perfectly reasonable thing to do to print articles out (or otherwise have them in a format where the thumbnails are all you get), also. Remsense ‥ 论 03:51, 22 December 2024 (UTC)
    I do worry my criterion above is too loosey-goosey to be a good guideline; I don't think there's a problem with speaking in terms of minimum size as such, maybe it's better getting the intended point across? Remsense ‥ 论 03:55, 22 December 2024 (UTC)
    Definitely better getting the intended point across. If we try to impose a numeric min. size, people are going to argue about it until the end of fargin' time, based on the behavior of their preferred devices and browsers, and so on.  — SMcCandlish ☏ ¢ 😼  03:17, 23 December 2024 (UTC); rev'd. 13:39, 23 December 2024 (UTC)
    What do you think about the potential phrasing first presented—i.e. if at all possible, what images are being used to illustrate should be fully legible when scaled according to the default base size Remsense ‥ 论 03:23, 23 December 2024 (UTC)
    Lots of unnecessary words. When possible, images with text should be legible when ... I'm not sure what "according to" the default base size means. Is it really the default base size? Are more than handful of editors reading this going to understand what "base size" means? I thinking there must be a clearer way to get the point across, but the goal seems right. (Speaking of "getting the intended point across": ironically, my previous message had an extraneous word, "than", in it – in a position that reversed or at least badly confused my meaning, so I've removed it.)  — SMcCandlish ☏ ¢ 😼  13:39, 23 December 2024 (UTC)
    I'm not sure how to phrase it. It's not just images with text either, it's all images that are added but cannot actually be deciphered without expansion. Remsense ‥ 论 04:40, 24 December 2024 (UTC)

    Commas around incorporated businesses' names

    from looking at MOS:COMMA, there isn't any guidance on how to deal with names with Inc.. multiple articles do any of the following, either with no comma, a comma only before and a comma around the word.

    1. Mumumu Inc. is a company ...
    2. Mumumu, Inc. is a company ...
    3. Mumumu, Inc., is a company ...

    I am aware that the commaless and comma style may coexist (sometimes in the same article!), however the second and third styles should likely be decided upon. Juwan (talk) 01:09, 26 December 2024 (UTC)

    An editing policy question

    When I read Wiki policy and guidance pages, I sometimes find shall used instead of will to indicate what must be done — for example, in the Signs of Sockpuppetry article, we find: "The more signs that are present, the more likely sockpuppetry is occurring, though no accusations shall be made unless, beyond a reasonable doubt, one is really certain."

    Granted that shall is often used this way in government and judicial documents, I think it sounds somewhat at odds with the more user-friendly ambience Misplaced Pages has tried to create for editors. Besides, shall is not consistently applied throughout the policy and guidance pages — for example, in the same Signs of Sockpuppetry article, we find: "The closing administrator will be required to follow the consensus, even if they personally disagree."

    — For the above reasons, wouldn't it be in Misplaced Pages's best interests to avoid using the conversationally archaic shall in these articles and replace it with will?? I doubt that this would make editors with wrongdoing on their minds less likely to behave as desired.

    — But if the decision is made to continue "shalling," then for the sake of consistency couldn't a search-and-replace be done throughout the policy and guidance articles to replace will with shall where the word needs to indicate what must be done? Augnablik (talk) 16:53, 28 December 2024 (UTC)

    It's fine, really. This is one of those things the MOS exists to obliquely neutralize—i.e. this is a pretty conjectural position and not worth getting into all-in or all-out discussions over. Remsense ‥ 论 17:16, 28 December 2024 (UTC)
    “Obliquely neutralize” — there’s a new one for me! 😅
    I just thought it would help lighten the bureaucratic tone of these articles to dial down the legalese, as many editors feel increasingly on edge with all the rules and regulations they discover the more they wade into Misplaced Pages. Augnablik (talk) 17:31, 28 December 2024 (UTC)
    Genuinely, I apologize that I can't talk normal when the situation would benefit from it. Take that how you will. Remsense ‥ 论 17:32, 28 December 2024 (UTC)
    Or shall. EEng 17:39, 28 December 2024 (UTC)
    😂 Augnablik (talk) 07:44, 30 December 2024 (UTC)
    Am losing the will to live here, mate. Martinevans123 (talk) 12:34, 31 December 2024 (UTC)
    Just be aware that you’ve entered the purview of a global encyclopedia, and that means you will encounter forms of English that aren’t necessarily common locally to wherever you live. MapReader (talk) 17:57, 28 December 2024 (UTC)
    Is this one of those rfc:2119 situations where we should stick to a limited number of modal verbs on a sliding scale (must > should > may)? --Redrose64 🦌 (talk) 18:42, 28 December 2024 (UTC)
    @MapReader, Although I’m aware of different styles of English in different parts of the world, the shall/will issue I’ve raised here is more about how Misplaced Pages wants to show officially expected actions in particular situations.
    Not like , “Today I shall go to the beach” … but like, “Administrators shall hold discussions on the matter for one week before reaching a decision.” Augnablik (talk) 12:10, 30 December 2024 (UTC)
    Nevertheless, ‘shall’ is still reasonably common usage in formal, official or legal written texts, in the UK, in a way that I don’t think you can say for the US (but willing to be corrected…), and is not considered particularly user-unfriendly. Your observation to the contrary above is therefore pitched from the perspective of a particular Engvar, which was my original point. MapReader (talk) 15:16, 30 December 2024 (UTC)
    @MapReader, you're probably right about "how official" shall sounds to UK and US readers of official documents. And frankly, that word is still used from time to time in official documents in the US, even though much more rarely these days. Even so, here's a thought: if will would work equally well as shall in Misplaced Pages policy and guidance documents, why not use it consistently here so as to make "official stuff" sound a bit less bureaucratic but at the same time affirming of expected behavior?
    Though I'm American, I doubt that any of our UK cousins across the pond would feel affronted if Misplaced Pages consciously adopted will in its policy and guidelines. Wouldn't it simply be one more example of Misplaced Pages's intentions of providing as welcoming and user-friendly environment as possible in which to work, while in no way demeaning other varieties of writing?
    Alternatively, to avoid the whole shall/will issue, there are still other ways wording could be done. For example, instead of "Administrators shall hold discussions...,” we could say, "Administrators are to hold discussions ....” Augnablik (talk) 11:04, 31 December 2024 (UTC)
    More rules about how rules should be written could be one step forward, two steps back. EEng 12:28, 31 December 2024 (UTC)
    Onbiously, you're free to edit how you want, but as a general rule, surely it isn't WP's object, nor that of the MoS, to try and enforce general language preferences on our editors? MapReader (talk) 11:41, 31 December 2024 (UTC)
    You state the onbious. EEng 12:28, 31 December 2024 (UTC)
    Well, @MapReader, I think it’s time for me to gracefully bow out of the discussion now. My only Intent in making my suggestion was far from an attempt to enforce, though I see how it might be interpreted that way.
    Instead, I was trying to make a case for a slight change in wording that seemed to me could help Misplaced Pages accomplish its very positive goal of creating an open, light, friendly ambience — just as seniors helping in the Teahouse and elsewhere are asked to do with those who ask questions. I know that as some editors get involved with Misplaced Pages, they come to feel weighed down by many rules and regulations and even become fearful they might make a slip and face serious consequences.
    It was this I hoped my suggestion might help prevent in the long run, with the flip-side benefit of editor retention. Augnablik (talk) 12:37, 31 December 2024 (UTC)

    Discussion at Archimedes § MOS:'S (redux)

     You are invited to join the discussion at Archimedes § MOS:'S. Remsense ‥ 论 21:13, 29 December 2024 (UTC)

    Discussion on American football bio leads

    See here. ~WikiOriginal-9~ (talk) 19:07, 1 January 2025 (UTC)

    Usage of historical place names in infoboxes

    Some feedback here would be nice. Thanks --Flominator (talk) 19:34, 1 January 2025 (UTC)

    Categories: