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 19:20, 13 November 2012 editMarie Paradox (talk | contribs)Extended confirmed users640 edits Request for comment: The current wording should be retained← Previous edit Latest revision as of 15:52, 26 December 2024 edit undoCewbot (talk | contribs)Bots7,307,510 editsm Maintain {{WPBS}}: 2 WikiProject templates. (Fix Category:WikiProject banners with redundant class parameter)Tag: Talk banner shell conversion 
Line 1: Line 1:
{{Talk header |WT:MOS |search=no }}
{{Mbox
{{FAQ|quickedit=no|collapsed=no}}
| type = content
{{Round in circles|search=yes}}
| image = ]
{{User:HBC Archive Indexerbot/OptIn
| text= This page (along with all other MOS pages and ]) is subject to ] ]. See ]
|target=Misplaced Pages talk:Manual of Style/Archive index

|mask=Misplaced Pages talk:Manual of Style/Archive <#>
] and ] are subject to ] as a unit, one ] per editor on either the MOS page or its talk page ''per 24 hour period'', until 15 January, 2013.
|leading_zeros=0
{{#switch: {{NAMESPACE}}
|indexhere=yes
| {{ns:0}} = ]<!-- Template:Article probation -->
}}
| {{ns:Template}} = ]
{{Section sizes}}
}}
{{WikiProject banner shell |1=
{{WikiProject Manual of Style}}
{{Misplaced Pages Help Project|importance=Top}}
}} }}
{{shortcuts|WT:MOS}}
{{MOS/R}}
{{tmbox|small=yes|text=For a list of suggested abbreviations for referring to style guides , see ].}}
{{User:MiszaBot/config {{User:MiszaBot/config
|algo = old(30d)
|archiveheader = {{aan}}
|archive = Misplaced Pages talk:Manual of Style/Archive %(counter)d
|maxarchivesize = 200K
|counter = 133 |counter = 228
|maxarchivesize = 900K
|algo = old(7d)
|archiveheader = {{Automatic archive navigator}}
|archive = Misplaced Pages talk:Manual of Style/Archive %(counter)d
|minthreadstoarchive = 1
|minthreadsleft = 4
}} }}
]
{{archives|auto=short|search=yes|bot=MiszaBot II|age=7}}
__TOC__
{{clear right}}
{{stb}}


==Style discussions elsewhere==
== Three corrections ==
<!-- START PIN -->{{Pin message}}<!-- ] 06:15, 18 June 2029 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1876457735}}<!-- END PIN -->
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===
<!-- ] 06:57, 12 November 2012 (UTC) -->
(newest on top)
Please comment if there are any questions. ] (]) 19:11, 7 October 2012 (UTC)
<!--
Don't add threads that are on the same page as this list.
Capitalization-specific entries should go in the corresponding section at the top of:
Misplaced Pages talk:Manual of Style/Capital letters
-->
* ] – Plural possessive ] question
* ]
* ] – 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 />
It appears that the example "the Uganda–Tanzania War; the Roman–Syrian War; the east–west runway; the Lincoln–Douglas debates; a carbon–carbon bond" while not commenting that it is a little long (do we really need so many examples?), is in need of two corrections; in the first example, "the Uganda–Tanzania War", war should not be capitalized (see google book search), and it should be "but not {{!xt|the Roman–Syrian War}} (as Roman-Syrian War is a proper name)". The article at ] should also be moved, to ], and if it is a proper name, a better example used, and it be moved to Uganda-Tanzania War. <s>(already moved)</s> ] (]) 23:08, 27 September 2012 (UTC)
'''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 />
*'''Comment.''' I have reverted Apteva's undiscussed move of ], which was apparently done to prove a point here and not in the interest of the article itself.<br>This section attracted no comment before Apteva elevated it to an RFC, probably because Apteva is pushing on proper names, en dashes, and hyphens at several forums at the same time&nbsp;– including an RM, now closed as not moved, for the long-settled ]. I have explicitly said, on this talkpage and elsewhere, that general issues with WP:MOS guidelines should be raised ''as'' general issues, right here. Not at several locations, and not as particular sparring points. It seems to me that this RFC is yet another waste of time. I comment on one detail only: yes, obviously many examples are needed in the guideline. Even more than we have now, perhaps. Some editors are still refusing to accept the principle it is based on as consensual; and Apteva, for example, is playing hard by appeal to inconsequential differences among the present examples. If any element of the long and meticulous community consultation on dashes in 2011 needs review, let it be done in an orderly and informed way. Some recommended background reading for those interested: the article ], most of which is now accurate. (It needs a move to ].)<br><font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 21:48, 7 October 2012 (UTC)
'''Capitalization-specific:'''
*:It was a correct move. Uganda–Tanzania war is not a proper noun and is not capitalized. Nor was it undiscussed. The date and time in the above discussion shows that it was pointed out on September 27 that it should be moved, and that it was not moved until October 5 (and a check of the edit history will show that I noted that it had been moved when I opened the RfC on October 7). Clearly plenty of time and some for anyone to disagree with the proposal. Seeing none, I took it as approval, not an unusual response. Should an RM to move proper noun come to my attention I would object. And I think that would be the consensus. The word phrase "proper noun" did not enter use until about 1890. The dictionary, if it contains "proper name", defines it as proper noun. The two terms are interchangeable. I have called for an RfC because I am not going to get into an edit war over the Revert. In the BRD cycle, after R comes D. There had been no response, so I am asking for a response. I do not believe that a review of a clearly embarrassing discussion needs to be reviewed. Proper names use hyphens and our MOS says so. 10,000 books use a hyphen and maybe a 100 use something else. Case closed. I would like to remind everyone to focus on the issue, not the editor, though. WP is never an authority on anything, proper nouns included. WP articles can never be used as a RS. ] (]) 02:40, 8 October 2012 (UTC)
{{Excerpt| Misplaced Pages talk:Manual of Style/Capital letters|Current|subsections=no}}
:::These topics have already been the focus of much long and pointless argumentation that wasted the time of multiple editors, time that could have been spent elsewhere, like in creating content. I don't understand the point of reopening these discussions so soon after they have finally and painfully been settled by consensus. --] (]) 08:03, 8 October 2012 (UTC)
}}
::Congratulations to Noetica, the ] article has just been cited by no less an authority than ] at ]. --] (]) 08:09, 8 October 2012 (UTC)
::::There are still improvements that are needed - fix the misleading and incorrect examples. If someone wants to argue that proper nouns are not capitalized or that sentences do not need periods, not questions of course, then certainly their time is better spent elsewhere, but if someone insists that Roman-Syrian War is spelled with an endash they will have a very hard time supporting that premise. Is War capitalized in "Uganda-Tanzania War"? Possibly, but if it is the punctuation is a hyphen and not an appropriate example of where to use an endash. If war is not capitalized, Uganda–Tanzania war is an example of where an endash is used, and the capitalization needs to be fixed. In both cases the current article needs to be moved - either to Uganda-Tanzania War or to Uganda–Tanzania war. There are always people who misspell things, and use incorrect punctuation, and that is why there is an edit tab and a move option. ] (]) 03:49, 9 October 2012 (UTC)
===Comet Hale-Bopp===
This example: "Comet Hale–Bopp or just Hale–Bopp (discovered by Hale and Bopp)" needs to be removed because used either with or without the word "Comet" this is still a proper noun and therefore uses a hyphen, as supported by the thousands of reliable sources that use this punctuation. According to Google Books there are 31,900 sources, the overwhelming majority of which use a hyphen. It is not even close. ] (]) 22:47, 9 October 2012 (UTC)
:Nonsense. Many of those reliable sources do use the en dash, which confirms that it is simply a styling choice. The fact that many sources have a style that substitutes hyphens in the traditional role of the en dash, and that the Google books OCR can't tell the difference, does not mean that WP needs to adopt that style. There's nothing special or unique about Hale–Bopp here. Your concept of "proper noun, therefore hyphen" is unsupportable hallucination. ] (]) 01:01, 10 October 2012 (UTC)
::Not nonsense at all. There are ''some'' sources that do use en dash, but if there were ''many'', as in ''many more than use hyphen'', then statistically at least one would have appeared in the first ten. Out of the first 100 how many use hyphen? Out of the first 1,000 how many? Google books has 32,900 to look through. I strongly disagree with the supposition that an OCR can not tell the difference as there are a huge number of occurrences in google books of both endashes where they are appropriate and em dashes where they are appropriate. While it is far easier to do a text search, I am completely confident in my assessment that there are no endashes in the first 10 results that I obtained. As was pointed out before, any suggestion of "many" needs to also include "out of how many", as saying there are 432 examples of using Hale-Bopp with an endash sounds impressive until you find out, say, that that was out of 32,000, with 29,000 using a hyphen and 3,000 using a space, just as a made up example. Proper noun hyphen is not fiction. It is in our MOS and I really have yet to see any example of a proper noun that does not use a hyphen. I am ''not'' saying they do not exist. I can certainly imagine that if someone named Hale-Bopp and someone named Lennard-Jones discovered a comet it could be called the "Hale-Bopp–Lennard-Jones Comet, to distinguish between one discovered by Hale and someone named Bopp-Lennard-Jones, or by one person named Hale-Bopp-Lennard and one named Jones. Normally exceptions to rules are pretty easy to find. It is academic to find them, but still interesting, and I really have not seen one. One editor perhaps looked for examples of endashes in WP article titles and came up with two that are not proper nouns and two that are using incorrect punctuation on WP. Since when has WP ever been considered a reliable source? ] (]) 04:27, 10 October 2012 (UTC)
:::Nonsense. Several of them DO in fact appear in the first page of 10 hits on Google Book Search (with previews). You need to actually look at the previews to see how they are styled, as the OCR does not distinguish hyphen from en dash usually (and sometimes it sees en dashes as em dashes—I was going to say like , but it turns out that one really did get typeset with an em dash, due to some amateur typographer's blunder). If en dashes do show up sometimes in snippets, in probably from books that they got electronically, as with , where you can tell they got it electronically because if you zoom way in the letters aren't blurry or pixelated; they're being rendered from text. The same effect is often seen in Google Scholar, where papers with en dashes often show up as hyphen, but not always; in spite of that, nearly half show up on the with en dash. It's not an usual style like you're making it out to be. ] (]) 05:33, 10 October 2012 (UTC)
::::Am I hearing an echo? 5/20 is a long way from "nearly half". It is 3 to 1 in favor of using a hyphen. Which is correct based on that information? Clearly a hyphen. ] (]) 06:35, 10 October 2012 (UTC)


===Concluded===
For now I have changed "Comet" to comet, per p. 48 of the New Oxford Dictionary for Scientific Writers and Editors, and per our article on the comet, which does not capitalize the word comet - hence an endash is correct as it is not treated as a proper noun. There is an open RM to move the page to Comet Hale-Bopp, treating it as a proper noun. Sources clearly favor proper noun status. Halley's comet, on the other hand, does not favor proper noun status and can also be corrected. ] (]) 16:28, 11 October 2012 (UTC)
{{collapse top|left=y|title=Extended content}}
:Please see ]: "The policies, guidelines, and process pages themselves are not part of the encyclopedia proper. Consequently, they do not generally need to conform with the content standards. It is therefore not necessary to provide reliable sources to verify Misplaced Pages's administrative pages, or to phrase Misplaced Pages procedures or principles in a neutral manner, or to cite an outside authority in determining Misplaced Pages's editorial practices. Instead, the content of these pages is controlled by community-wide consensus, and the style should emphasize clarity, directness, and usefulness to other editors."
<!--Please put newer additions at the top, by order of closure. -->
:The "New Oxford Dictionary for Scientific Writers and Editors" does not have any authority over Misplaced Pages. The Misplaced Pages house style for comets is here: ].
* ] – Use en dash not hyphen in four paired names? ''Result:'' Yes.
:--] (]) 18:22, 11 October 2012 (UTC)
* ] – 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.
::Irrelevant. The name we have chosen is "comet" not "Comet". Using "Comet" gives it proper noun status, and it becomes Comet Hale-Bopp, with a hyphen, not an endash. the section referenced says to use the common name, and if none, give it proper noun status (how generous). The example, Comet Hyakutake, is littered with references that use comet and ones that use Comet. ] (]) 18:53, 11 October 2012 (UTC)
** 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.
::: IMHO, recalling high school grammar classes might be of help here. Is the word "comet" a part of the name, or it just reiterates what the name is about? In other words, can we leave "comet" out without loss of meaning? Does ''the (c/C)omet Halley-Bopp'' resemble ''the "New York Times" newspaper'' and ''a McDonald's restaurant'', or, rather, ''The Wall Street Journal'' and ''the White House''?
* ] – 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.
::: To my feeling, that particular space object is called ''Halley's Comet'', and another one is called ''Hale-Bopp Comet''. Since the names of space objects (planets, stars, comets, galaxies, constellations, etc.) are always capitalised (e.g., Mars, Jupiter, Neptune, Aldebaran, Vega, Milky Way, Sun, etc., etc.) , the word "comet" should also be capitalised in all the instances, since it is an inseparable part of that object's name. Rules as to dash/hyphen should apply accordingly. <span style="font-family: 'Candara', sans-serif; font-weight: bold; text-shadow: #AAAAFF 0.2em 0.2em 0.1em; class: texhtml">]</span> 19:52, 11 October 2012 (UTC)
* ] – ]: "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.
:::: Of course ''Comet Hale-Bopp'' (however hyphenated) is a proper noun. ''All'' names are proper nouns. Some sources may choose not to capitalize it; that's a style decision (a poor one in my view, but style rather than grammar). But even in those sources, it's still a proper noun &mdash; that's a grammatical rather than stylistic category. --] (]) 20:29, 11 October 2012 (UTC)
* ] – 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.
:::::That may be obvious to any number of people, but it is not obvious to the people who write ], or Articles as in scientific articles published elsewhere. In both cases the spelling of the dictionary is used. Why would we write a style guide that no one was using? Style guides should follow what we are doing, not make up rules that no one uses. I suggest that Comet should be changed to comet in ] to agree with common use. We use sun and moon when 99.9+% (probably a lot more 9s for sun than moon) of the time we actually mean Sun and Moon, and it is ridiculous to capitalize it, and not done in common practice. Our style guides need to follow common practice, not introduce peculiarities. ] (]) 21:04, 11 October 2012 (UTC)
* ] – 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 ].
:::::: Your reference to "common use" seems misguided: ''Sun'' and ''Moon'' are always capitalised when used as names of celestial bodies (i.e., not in ''sun lotion'', ''sunbathing'', ''moonlight'', etc.); so are Earth, Mercury, etc. As to your removal of capitalisation in "Comet", I would thus suggest you refrain from making edits that deliberately violate ]. Any such changes should be reverted. <span style="font-family: 'Candara', sans-serif; font-weight: bold; text-shadow: #AAAAFF 0.2em 0.2em 0.1em; class: texhtml">]</span> 21:44, 11 October 2012 (UTC)
* ] – 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.
::::::::Speaking only for myself, I am ''not'' making any edits that violate the MOS. The MOS says that proper names use hyphens, so I am moving articles that are proper nouns and use an endash, like, for example, Mexican-American War and Spanish-American War. Doing that brings them into compliance with the MOS. I am removing the examples in the MOS that are not in compliance with the MOS. The MOS says that proper nouns use hyphens, and has three examples that are proper nouns yet use an endash. One of them, comet Hale–Bopp, is not capitalized in our article, is not capitalized in a respected dictionary, and yet is capitalized as an example in our MOS. What's up with that? What I do need to do, though, is politely ask editors to read the section of the MOS on hyphens and note that there actually are places they are used - like in proper nouns. We all need to get on the same page here though, and if someone can show me 10,000 books that use an endash in Mexican-American War, and that there are less than use a hyphen, by all means that is what we also should use. But no matter how some editors came to the conclusion that Mexican-American War should have been spelled with an endash so they are going to use one, if in fact that is not a reasonable decision, it needs to be re-opened. In case no one has noticed, out of 4 million articles, there are some that have errors, and that is where I would prefer to spend my time. Fixing errors - like the spelling of Mexican-American War. ] (]) 02:27, 12 October 2012 (UTC)
* ] – ] (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 ].
::::::: shows about 50% capitalize "Comet". ] (]) 23:57, 11 October 2012 (UTC)
* ] – 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.
::::::::True. But how many dictionaries capitalize Halley's comet or comet Hale–Bopp? ] (]) 02:27, 12 October 2012 (UTC)
* ] (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".
::::::::: on the OneLook list capitalize the "C". Some capitalize it inconsistently. None on my list uncapitalize it consistently, although comes closest. ] (]) 04:51, 12 October 2012 (UTC)
** Related: See numerous previous deadname-related and more general GENDERID discussions listed below.
:::::::::But now I found elsewhere. ] (]) 05:07, 12 October 2012 (UTC)
* ] – Proposal to merge a "guideline in all but name" into MoS. (Jan. 2024) ''Result:'' consensus to promote to a guideline (after some significant revisions).
The dictionary link for Comet Hale-Bopp is amusing - links to WP with a hyphen, even though the article uses an endash, as of 2011 - "05:05, 26 January 2011‎ CWenger (talk | contribs)‎ . . (31 bytes) (+31)‎ . . (moved Comet Hale-Bopp to Comet Hale–Bopp: MOS:ENDASH #1, comet discovered by Hale and Bopp)".
* ] – Peripherally related to ] and ]. (Jan. 2024) ''Result:'' Consensus to increase to 250px.
* ] – ] 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.
** ] – Abortive, unclear RfC that resolved nothing. (May–Sep. 2023) ''Result:'' unanimously opposed.
* ] – 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.
** Discussion re-opened at ] (Nov. 2024). Changed to lowercase ; we'll see if that sticks.
* ] – 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.
* ] – 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.
* ] – 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).
* ] – On ] and whether to add another example to it. (Oct. 2023) ''Result'': Discussion archived without a clear conclusion.
* ] – 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.
* ] – Use an en dash instead of a hyphen? ''Result'': Withdrawn
*] – 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 ].
* ] – 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.
* ] – 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.
* ] – 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 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.
* ] – 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.
* ] – 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).
* ] – 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".
* ] – 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".
* ] – ] / ] and Northern Ireland again. (Sep.–Oct. 2023) ''Result:'' No formal closure, but near-unanimous consensus against using national flags as ethnicity symbols.
* ] – 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).
* ] – ] 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).
* ] – 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.
** ] – Above question was raised at a specific article as a "local consensus" matter. (Aug.–Sep. 2023) ''Result:'' unanimous opposition to 24-hour time.
* ] – 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".
* ] – 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.
* ] – 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 ].
** 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 ].
** ] – Proposal to move the MoS material into WP:BLP. (Aug. 2023) ''Result:'' Procedurally closed as "premature".
* ] – 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.
* ] 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.
* ] – 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.
* ] – 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.
** ] – 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}}


== ] and ranges ==
We found 3 dictionaries with English definitions that include the word comet Hale-Bopp:
Click on the first link on a line below to go directly to a page where "comet Hale-Bopp" is defined.


{{U|Amaury}} is ] that DATECOMMA does not apply to a range (expressed in prose): that {{!xt|from October 12, 2012 to September 25, 2015.}} is right and {{xt|from October 12, 2012, to September 25, 2015.}} is wrong. That is nonsensical. The year is still a parenthetical; it is still required to be bounded by a punctuation pair. Notably, ] includes a greentext example showing correct DATECOMMA applied to a range: {{xt|between October 6, 1997, and May 20, 2002.}}
General dictionaries General (1 matching dictionary)


Their argument
:Comet Hale-Bopp: Misplaced Pages, the 💕
{{tqb|{{tq|January 1, 2023,–January 1, 2024}} would be incorrect, which means {{tq|January 1, 2024, to January 1, 2024}} is also incorrect. It's still a date range, just written out instead of en-dashed. {{tq|January 1, 2023–January 1, 2024}} and {{tq|January 1, 2023 to January 1, 2024}} are equivalent.}}
is inconsistent with MOS. ] is clear:
:{{tq|Do not mix en dashes with ''between'' or ''from''.}}
:{{xt|from 450 to 500 people}}, not {{!xt|from 450–500 people}}
This means an en dash and "to" are ''not'' equivalent or interchangeable in Amaury's argued example. {{!xt|January 1, 2023,–January 1, 2024}} is incorrect only because DATECOMMA already obviates the closing comma when the year is {{tq|followed by other punctuation}}, i.e., the en dash.


Is there an exception to DATECOMMA for written-out ranges? ] (]) 12:27, 8 November 2024 (UTC)


:, a second comma after the year in a range. ] (]) 13:10, 8 November 2024 (UTC)
Computing dictionaries Computing (1 matching dictionary)
::A minor ]. EEng: {{tq|do what feels best}}. SMcCandlish: {{tq|No, there is no exception}}. ] (]) 13:29, 8 November 2024 (UTC)
:::Well I guess it makes sense to ping the previous participants then. @], @], @]. ] (]) 14:28, 8 November 2024 (UTC)
::The ] requires it: {{tq|The dates of September 11, 1993, to June 12, 1994, were erroneous.}} ] (]) 13:48, 8 November 2024 (UTC)
*Reading ], I would think it's apparently standard to use an en dash, such as {{tq|January 1, 2023 – January 1, 2024}}, possibly to avoid this exact issue. Personally I don't see why DATECOMMA wouldn't apply when an en dash isn't used, but I'm not an expert, so clarity on the MOS pages could be beneficial. ] (]) 13:21, 8 November 2024 (UTC)
*:Use of endash for ranges isn't standard, if by "standard" you mean "preferred over ''to''"; either is ok in general, the choice depending on a combination of context or preference. ]] 18:15, 8 November 2024 (UTC)
*While Amaury's argument is complete nonsense, the idea that ''2015'' in {{tq|{{nobr|May 5, 2015}}}} is a "parenthetical" is something even worse: pompous nonsense.{{refn|1=Additional pomposity can be achieved by claiming that ''2015'' is an "appositive".}} If that were so, then people in England would write {{tq|We set {{nobr|25 May, 2015,}} as the deadline}}, which they don't (and they can be pretty pompous, so that's saying a lot) or in America they'd write {{tq|He left on {{nobr|May 5, 2015<big>,.</big>}}}}{{nbsp}}(<=={{nbsp}}with a comma AND a period at the end there) and they don't do that either (despite being crazy in other regards, as recent events demonstrate). The comma's present in {{tq|{{nobr|May 5, 2015}}}} because setting digits cheek-by-jowl (as in {{tq|{{nobr|May 5 2015}}}}) would be confusing and error-prone.
:I'm generally a prescriptivist, but when it comes to comma usage, there are way too many fussbudgets (including otherwise sensible and respected style guides) still insisting that they be used in all kinds of places that great-grandpa might have used them ({{tq|Tomorrow, we will leave}}) but where no sensible person today would use them under normal circumstances. Things change, and one big change over the last 200 to 300 years is a lightening up on commas. I realize I'm in the minority here, but when I read this "parenthetical/appositive" nonsense I cannot remain silent. ]] 18:15, 8 November 2024 (UTC)
{{reflist}}
::] does in any case refer only to MDY dates, not to DMY dates. ] (]) 20:54, 8 November 2024 (UTC)
:::That's part of my point. If commas are supposed to act as "parentheticals" around the year, then we'd be putting commas around the year in DMY dates as well as in MDY dates. ]] 21:22, 8 November 2024 (UTC)
::::I mean, it could just be that the MDY style contingent has decided it's a parenthetical, and the DMY style contingent has decided it's not. ] (]) 21:28, 8 November 2024 (UTC)
:::::Plus, in DMY years, since there are no commas ''before'' the year, the question of whether to put some ''around'' it cannot even arrive. ] (]) 08:20, 9 November 2024 (UTC)
*Forgot to mention: This issue entered my radar because I noticed Amaury is engaged in a tedious revert battle with a seeming IP sock who loves adding range DATECOMMAs (e.g., ], ], ]). If DATECOMMA applies to ranges, then this uninspiring back-and-forth can take a rest as the changes are {{tq|]}}. ] (]) 20:57, 8 November 2024 (UTC)
*:I mean... I don't think those edits are incorrect personally. ] (]) 21:15, 8 November 2024 (UTC)
]
:::Sad to say, under MOS as it stands, the IP's changes are correct. I just think it's stupid to bother. ]] 21:25, 8 November 2024 (UTC)
:::And see ]. ]] 19:10, 10 November 2024 (UTC)
::::{{tq|I don't buy into the "OhButIfWeDon'tThereWillBeEndlessArgumentOnEachArticle" reasoning}}
::::See, we're well past the "there ''might'' be argument" stage. The ]-]-]-], ]-]-] ] began long ago.
::::Also, as I said at the outset, MOS already includes greentext confirmation of a range datecomma: {{xt|between October 6, 1997, and May 20, 2002.}} There is no "new rule"; however, as Hey man im josh says, additional {{tq|clarity on the MOS pages could be beneficial}}.
::::Ping priors {{U|Geraldo Perez}} {{U|MPFitz1968}} {{U|YoungForever}} {{U|Mz7}} {{U|HandsomeFella}}, IJBall is no longer around. ] (]) 00:33, 11 November 2024 (UTC)
::::+{{U|JohnFromPinckney}} ] (]) 00:47, 11 November 2024 (UTC)
*MLA style: {{tq|The exhibit ran from June 2, 1995, to April 4, 1996, in New York.}}
:AP style: {{tq|between Feb. 1, 2021, and Feb. 22, 2023, the...}}
:When asked if {{!xt|from November 3, 2021 to November 30, 2022.}} needs a comma, APA, AMA, Microsoft, and Apple guides would all also {{tq|tell you to use that second comma}}; {{tq|the year is parenthetical ... this usage is relatively straightforward}}. ] (]) 01:45, 10 November 2024 (UTC)
:Amaury (if their view has been correctly described by the OP) is just flat-out wrong. Bracketing commas {{em|always}} come in pairs (in WP writing, even if some journalistic style guides like to drop the second ones); unless: A) the second one has been replaced by some other punctuation in the sentence such as a semicolon, or a terminal period/full stop or question mark; or B) the second one would come at the end of a sentence fragment that doesn't take terminal punctuation, such as a table header or image caption, in which case no punctuation is used there at all, obviously.
:Yes: {{xt|from October 12, 2012, to September 25, 2015.}}
:Yes: {{xt|moved from Los Gatos, California, to Reno, Nevada, in 2021}}
:No: {{!xt|from October 12, 2012 to September 25, 2015.}}
:No: {{!xt|moved from Los Gatos, California to Reno, Nevada in 2021}}
: Point A above is important. {{!xt|January 1, 2023,–January 1, 2024}} should be {{!xt|January 1, 2023&nbsp;– January 1, 2024}} specifically because the second comma bracketing "2023" has been replaced by alternative punctuation (en dash, and a spaced one in this case because the elements on either side of it are complex not single-string; see ]). But this has no implications of any kind with regard to the spelled out version {{xt|January 1, 2024, to January 1, 2024}}. That is, the argument "{{tqb|{{tq|January 1, 2023,–January 1, 2024}} would be incorrect, which means {{tq|January 1, 2024, to January 1, 2024}} is also incorrect}}" is nonsensical, a confusion of two different but superficially somewhat similar things to which different rules apply. It's like writing "''I is hungry'' is ungrammatical, thus ''She is hungry'' must also be ungrammatical."<!--
--><p>Anyway, there is nothing even faintly new about this discussion. This is pure rehash of long-settled questions and has introduced no new argument, evidence, or other material to consider. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 00:41, 12 November 2024 (UTC)</p>
::{{tq|Bracketing commas always come in pairs }}{{snd}}Sure, ''if'' they're "bracketing"; you're just taking for granted that they are. I say that the commas in {{nobr|''September 5, 2017''}} and {{nobr|''Los Angeles, California''}} aren't part of any "bracketing", but rather are just separators -- lonely, workaday, unpaired, non-bracketing separators. ]] 07:35, 12 November 2024 (UTC)
:::That's not the view of the MOS, though. ] (]) 09:56, 12 November 2024 (UTC)
::::MOS doesn't take a position on the theoretical bases of the stylistic practices it recommends; it just recommends. ]] 22:34, 12 November 2024 (UTC)
:::They're defined as bracketing commas by our MoS (and by basic linguistic logic<sup>&#91;]&#93;</sup>). There really isn't anything else under discussion here (and should not be). Style discussions on WP keep getting lost way out in the weeds with people's tempers flaring because they try to bring in external "rules", and personal subjective preferences, and ] (by a prescriptivist non-linguist) two generations ago, and how people at their job prefer to write, and what some third-party style guide they like better says instead, and etc. It's all just distracting and confusing noise. Cf. ]. This page doesn't exist for debating how you wished academic writing worked, or why some MoS line item would be subjectively better your preferred way. If you can't make a strongly defensible case for an objective improvement to consistency and comprehensibility for readers, then ]. Its value is in its stability, its concision compared to other style guides, its consistency (especially strong avoidance of making exceptions that are not effectively {{em|required}} by all of mainstream writing practice), and its focus on reader understanding of the material above any traditionalist, prescriptivist, nationalistic, or "expedientist" sentiments.<!--
--><p>Our punctuation system works perfectly fine on this particular comma-usage question, and is engineered for clarity. It serves that purpose well; the comma-avoidant alternative would not, and rather would make for many confusing constructions, for no gain of any objective kind. WP's style also agrees with the majority of practice in academic style guides and publications using them. So, to propose a change to this would require a really overwhelming case for doing so, based on real evidence of the superiority (somehow) of the alternative and proof that most of the style guides that are influential on MoS (not journalism and governmentese and fiction-writing ones) had changed on this question. Once in a while that happens (e.g., dropping of both the commas around "Jr." and "Sr."; increased acceptance of singular-''they''; avoidance of ''he/him/his'' as generic; etc.). WP eventually adopts such provable changes in English usage patterns, after they have become well-established in contemporary academic writing and the style guides for it. That's not happening with regard to this matter and is not likely to happen.</p><!--
--><p><span id="NoteOfFooting"><sup></sup></span> In more detail: They serve a parenthesizing function, by which what is between the commas is a {{lang|la|post hoc}} clarifying modifier of what precedes it, and can often be omitted in a clearer context. That makes it parethetical by definition. In "We are hiring Anne, Bob, and Carol", these commas are not bracketing (parethesizing); no element of this can be removed without a loss of significant information or a grammatical problem (regardless of context). In "Her son, Daniel, is coming over for dinner tonight" and "They left Portland, Oregon, in 2004", all of these commas bracket parenthetical constructions which are necessary only in specific contexts. If you already know the son's name, you don't need to be told it; if you are in Oregon, you probably won't need the state specified (unless Maine was just now under discussion).</p><!--
--><p>In a particular context, something of this form might have all its parts become non-removable in a specific sentence (e.g., if I tell you "I'm going on vacation starting November 20", you probably do not need the year included; but the year is usually needed for more distant times, e.g. in "Mark Twain died on April 21, 1910, in Redding, Connecticut" you do need the year, except perhaps in a paragraph all about the events of 1910). But the underlying grammatical {{em|form}} is still parenthetical. We would not write an incidentally, contextually non-optional case in an inconsistent format. That would be very confusing for readers and editors alike. We know it would be confusing because a rather similar (and not particularly useful) distinction has unfortunately solidified in Modern English, with "Her son Daniel is coming over" conveying a different meaning (there is more than one son) from "Her son, Daniel, is coming over" (there is only one son). Various readers and even experienced editors often have trouble with this and get it wrong, but we need to get it right because this is universal across English dialects and registers ("Her son, Daniel is coming over", with only one comma, is erroneous in all of them, regardless which meaning was intended). By contrast, there is no dialect or register in which "The company was founded in Houston, Texas on January 3, 2015 by Chris O'Blivion" is required; it's simply a "save every character-space possible" preference of certain publishers' house styles. WP is not among them because it is harder to parse correctly without re-reading after all the comma-killing. I.e., we have an objective reason of reader comprehensibility to not write that lazy way. There are lots and lots of sloppy things done in journalese, bureaucatese, and marketingese that WP doesn't do, for good reasons. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 03:16, 13 November 2024 (UTC)</p>
::::I'm certainly not going to read all that (and I imagine few will), but please help me ... Is there anywhere in there where you explain why the same reasoning doesn't apply to DMY dates i.e. if the year is a "''post hoc'' clarifying modifier", why do DMY folks write {{nobr|''5 May 2015 was clear''}} instead of {{nobr|''5 May, 2015, was clear''}}? ]] 04:48, 13 November 2024 (UTC)
:::::In all seriousness, Sandy, I'd really be interested to hear your answer on this. But please, keep it under 10,000 words. ]] 18:07, 14 November 2024 (UTC)
::::::Says the one with the longest user-talk page across all WMF projects, LOL. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 21:35, 14 November 2024 (UTC)
:::::::But then, my talk page isn't all one post. ]] 22:45, 14 November 2024 (UTC)
:::::It's purely convention. Human language isn't a programming language and is not entirely logical or consistent. The "5 May 2015" format simply doesn't use commas {{em|at all}} (not in much of any professional writing, anyway). It's not WP's role to invent styles that are virtually non-existent in external reality, though where competing styles do exist in our register of writing ("May 5, 2015, was clear" vs. "May 5, 2015 was clear"; or "5 May 2015 was clear" vs. "5th May 2015 was clear" vs. "the 5th of May 2015 was clear"), we do have an interest in normalizing to the version that makes the most sense for our technical and reader needs (thus much of MoS, especially ]). Various clearly parenthetical constructions also only optionally take commas (but in pairs), and the shorter they are the less likely we are to use those commas in modern writing ("They moved, in 2015, to Bremen" vs. "They moved in 2015 to Bremen"). Parentheticals are often also punctuated with round brackets (thus their other name, parentheses) or with dashes, simply as alternative conventions with a bit of difference in emphasis level. But all of these also come in pairs when used as parenthesizing punctuation.<!--
--><p>What's being sought here is an inconsistent variance from this pairing pattern if and only if the marks used happen to be commas instead of something else, {{em|and}} only when the content in question is a date or a place. That's a complicated and unnecessary rule that ]. There is no reason to do it, because writing "May 5, 2015 was clear" isn't a style required or conventionalized in any dialect or register of English (simply a very optional hyper-expediency approach), it has significant costs to reader comprehensibility, and it's directly inconsistent with all other use of bracketing commas (no one with any sense would write "They moved, in 2015 to Bremen" – it takes either no commas or two). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 21:35, 14 November 2024 (UTC)</p>
::::::{{tq|It's purely convention}}{{snd}}Thank you. So if you want to argue that good usage has or has not adopted New Convention B in addition to (or in replacement of) Old Convention A, that's fine. But all this stuff about bracketing and appositives is just smoke and mirrors.{{pb}}And as for MOSBLOAT, in point of fact loosening up on this issue would be achieved by simply dropping everything in the ''Comments'' column in the date formats table:
::::::{| class="wikitable"
|+ Acceptable date formats
|-
! style="width:40pt;"<!--undersized width specification means actual column width determined by widest word/unbreakable string in the column-->| General use
! style="width:40pt;"| {{nowrap|Only in limited situations<br />where brevity is helpful}}{{efn|name=brevity|1=For use in tables, infoboxes, references, etc. Only certain citation styles use abbreviated date formats. By default, Misplaced Pages does not abbreviate dates. ]}}
! Comments<!--no width specification means this column will pick up all remaining horizontal width-->
|-
| {{xt|2{{nbsp}}September 2001}}
| {{xt|2{{nbsp}}Sep 2001}}
| {{anchor|DMYCOMMA|DMY COMMA|dmy comma}} A comma doesn't follow the year unless otherwise required by context: {{unordered list| {{xt|The 5 May 1922 meeting was cancelled.}} | {{xt|Except Jones, who left London on 5 March 1847, every delegate attended the signing.}} }}
|-
| {{xt|September{{nbsp}}2, 2001}}
| {{xt|Sep{{nbsp}}2, 2001}}
| {{anchor|MDYCOMMA|MDY COMMA|mdy comma}} A comma follows the year unless ]: {{unordered list| {{xt|The weather on March 12, 2005, was clear and warm.}} | {{xt|Everyone remembers July{{nbsp}}20, 1969{{snd}}when humans first landed on the Moon. }} }}
|}
::::::So that would be a definite deflation, not bloat. ]] 22:45, 14 November 2024 (UTC)
:::::::It would also lo{{s|o}}se useful information, though. Many people know the conventions mentioned in the comments already, but not everybody does. ] (]) 08:39, 15 November 2024 (UTC)
::::::::If you mean "lose" information, that's not a problem. Unlike articles, our behind-the-scenes guidelines don't aspire to teach readers / editors general knowledge. ]] 15:28, 16 November 2024 (UTC)
:::::::::Not general, just what's needed to successfully edit Misplaced Pages. Which apparently includes these rules for comma placement, otherwise this discussion wouldn't have started. ] (]) 15:53, 16 November 2024 (UTC)
:::::::That EEng, by his own admission, has refused to read the argument presented, explains why he did not understand it. His lack of understanding doesn't mystically make the argument wrong. And the fact that a practice exists in English by convention does not somehow make it devoid of logic or reason, much less of practical effect. Most of the workings of our language, spoken and written, have logic and practicality to them (some eroded a bit by language change), yet {{em|all}} of our language also exists as it does by convention. EEng has somehow confused "It is this way by convention" for "It has no reason, thus can be undone or replaced with impunity". They are not equivalent. EEng asked why the "12 March 2005" format lacks commas, and the answer is that it is not conventional to include them in that format. (There are many, especially numeric, formats of things that are typographically done particular ways, not always consistent with other approaches to conveying essentially the same information. Most of them even have alternatives that some individuals like better, yet ] has in virtually every case settled on the single conventionalized one that is most clear.) This "no commas" fact of DMY format has no implications of any kind for commas in any other format, nor (to get to the heart of the present matter) for why, when one comma is placed before the year in "March 12, 2005" MDY format, a second one follows (unless replaced by an alternative, like a sentence-ending "."). These are all entirely severable questions, so it is not cogent to seize upon one's inference in regard to the answer to one of these questions as dispositive in any way with regard to the handling of any other.<!--
--><p>{{tq|Unlike articles, our behind-the-scenes guidelines don't aspire to teach readers / editors general knowledge}}: That's correct; they exist to ensure that our editors produce material of maximum intelligibility and other usability for readers (and secondarily to stop editors fighting with each other over trivia). The proposal to write "On March 12, 2005 Elbonian troops invaded Narnia" is inimical to that goal, by introducing confusingly ambiguous syntax (the more complex the sentence the harder it becomes to figure out WTF the sentence structure even is when half the bracketing commas go missing, but even this simplistic example is hopelessly broken). Another way of putting this is that context {{em|always}} requires that second comma (or obviating alternative) because the inclusion of the first comma has the result that for some subset of readers every such construction lacking the second will be syntactically and often enough semantically confusing (generally because commas serve multiple purposes in English).</p><!--
-->Finally, there is a tension between making MoS concise and making it both understandable and serving its dual purposes of improving WP readability and reducing editorial conflict. We know from long history that our editors for years got into confused, confusing, and angry pissing matches about date formatting, with resultant chaos in mainspace. (Those date-format disputes are in fact why MoS is a ] in the first place.) So, removing the column of clarity about when to use commas with dates is the last thing we should do, since it would be {{em|guaranteed}} to cause a recurrence of conflict and confusion about what to do with dates. MoS resurrecting anew any long-settled "style war" is the opposite of its goal. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 11:46, 21 November 2024 (UTC)</p>
:Look, I'm writing a book right now, so I just don't have time to read other people's book-length posts. It's not that big a deal, my friend. We can pick this up another day, say, 20 months from now. ]] 16:35, 27 November 2024 (UTC)
{{notelist-talk}}


== Retain or remove citation indicators in quoted text? ==
:Comet Hale-Bopp, Hale-Bopp, Comet: Encyclopedia


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)


: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)
Slang dictionaries Slang (1 matching dictionary)
::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)
:::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)


== MOS:NOTLATIN and the Americanist phonetic notation ==
:Comet Hale-Bopp: Urban Dictionary


Hello, per the discussion at ], I thought it may be best to start a discussion here. We have come to a bit of a stand-still regarding the status of ] (NAPA). Per the discussion, several languages in the Pacific Northwest Coast use Americanist Phonetic Notation and as it stands, it is recognized as a non-Latin script in the system. The challenge is that there exists no recognized romanization system for NAPA, per NOTLATIN’s requirement for romanization of non-Latin scripts, nor is there an incentive to do so.
I checked to see if it was just copying the punctuation used in the search entry, and replaced the hyphen with an endash and got:


In typical usage beyond Misplaced Pages, words in Northwest Coast languages rendered in NAPA are typically left as-is, with no romanization, or with a transliteration if there so exists a historical example. However, those transliterations are few and far between, and are often inconsistent as they differ author to author. It would not be a sustainable system, because those words only constitute a small portion of the lexicon.
Sorry, no dictionaries indexed in the selected category contain the exact phrase comet Hale–Bopp.
] (]) 15:59, 15 October 2012 (UTC)


My question is whether NAPA should/would be recognized as a Latin script for the purposes of WP:NOTLATIN. NAPA derives heavily from Latin script, with the exception of a few Greek letters. Those letters represent various sounds, and each one serves a specific purpose. If it is not recognized as a Latin script, what would be the best course of action to allow various words to conform with WP:NOTLATIN, since there is no existing romanization system, and any generated romanization therefore would mostly be in violation of ]. Any insight on this would be greatly appreciated. ] (]) 19:53, 25 November 2024 (UTC)
*You might want to check s.t. other than a dict, such as ''Cometary Science after Hale–Bopp'' (Böhnhardt, Combi, Kidger, & Schulz, eds, Springer 2003), which uses the en dash in numerous papers and research notes, such as ''The 1995–2002 Long-Term Monitoring of Comet C/1995 O1 (Hale–Bopp) at Radio Wavelength; Large-Scale Structures in Comet Hale–Bopp; Modelling of Shape Changes of the Nuclei of Comets C/1995 O1 Hale–Bopp and 46P/Wirtanen Caused by Water Ice Sublimation; Observations of Rotating Jets of Carbon Monoxide in Comet Hale–Bopp with the IRAM Interferometer; From Hale–Bopp's Activity to Properties of its Nucleus; The Shadow of Comet Hale–Bopp in Lyman–Alpha, 73P/Schwassmann–Wachmann 3 – One Orbit after Break-Up; Nitrogen Sulfide in Comets Hyakutake (C/1996 B2) and Hale–Bopp (C/1995 O1)'', etc. These are proceedings of the International Astronomical Union (IAU) Colloquium No. 186 "Cometary Science after Hale–Bopp" (Tenerife, Jan. 2002), which followed the First International Conference on Comet Hale–Bopp in Jan. 1998. There are other, similar uses, such as 4015/Wilson–Harrington, 55P/Tempel–Tuttle, the Kuiper–Edgeworth (K–E) belt, the Hertz–Knudsen relationship, and the Stefan–Boltzmann constant. They even use the dash for Hale–Bopp in their references, though I suspect that if we followed up, we'd find that many were published with a hyphen. That is, they punctuate according to their in-house MOS, which is s.t. people here have been arguing we're not allowed to do (esp. in article titles, claiming it violates COMMONNAME). — ] (]) 18:19, 15 October 2012 (UTC)
:*(edit conflict) Comment. Hale-Bopp carries a hyphen because the ] says that it's spelled with a hyphen. Hyphenated surnames have the hyphen replaced with a space, like ], discovered by ], or cut in half, like ] (<s>1968d</s> C/1968 Q1), discovered by Bally-Urban and Clayton. Some people had already moved a couple of featured comet articles via RM. Kwami (who is posting right above me by pure chance) then moved dozens of comet articles to dashed articles, then proposed "Hale-Bopp" for the MOS draft as an example of a dash names. He didn't mention that all comet articles were hyphenated only a few weeks ago, or that he had moved dozens of himself a couple of days ago without discussion. Months later I realized the problem and I tried to correct it, but ]. Now Kwami has been desyosped for making massive moves against consensus. Maybe it would be time to discuss comet hyphens again..... Or should I wait until Noetica is topic banned for stonewalling and edit warring? --] (]) 18:45, 15 October 2012 (UTC)
:::And Enric Naval posts pictures of cats he's killed on his user page. If you can provide a source for the IAU rule, great, but that would simply be their in-house style. We don't copy the in-house styles of our sources any more than they do, as the result would be chaotic. Punctuation varies from source to source, and is even adapted in references and quotations.
:::The IAU convention, BTW, is similar to typewriter hyphenation. It's because astronomers send the IAU telegrams of their discoveries, and telegrams can't handle dashes. — ] (]) 19:14, 15 October 2012 (UTC)
::::The IAU has , not a ''style'' guideline. It's the only body that can name comets, and its naming decisions are internationally accepted. --] (]) 11:29, 16 October 2012 (UTC)
:::::Valuable link. Although I can't help an impression that the document deals more with naming than with typography. I wouldn't be surprised if its authors did not understand a difference between a hyphen and a dash. Astronomers hardly ever are typesetters... <span style="font-family: 'Candara', sans-serif; font-weight: bold; text-shadow: #AAAAFF 0.2em 0.2em 0.1em; class: texhtml">]</span> 12:06, 16 October 2012 (UTC)
::::::What it says is that spaces or hyphens are used: "each individual name is to be separated by a hyphen", and it is recommended that no more than two names be included. If someone has a hyphenated name that hyphen is replaced with a space or one of the two names only used. So that eliminates the ambiguity of Hale-Lennard-Jones - it would be either Hale-Lennard Jones or Hale-Lennard or Hale-Jones. ] (]) 14:54, 16 October 2012 (UTC)
::::And the comet names were always announced in . The telegrams were coded and illegible, and they never contained any comet name. --] (]) 11:41, 16 October 2012 (UTC)
:::::I don't know whether this has to be a joke or what. This is a printout of a French-language news release '''from 1920''' regarding the position of an observed new planet. Nothing about comets, naming, etc. See, basic knowledge of French prevents being misled by comments like yours. <span style="font-family: 'Candara', sans-serif; font-weight: bold; text-shadow: #AAAAFF 0.2em 0.2em 0.1em; class: texhtml">]</span> 12:02, 16 October 2012 (UTC)
::::::The IAU circulars communicate the discovery of ''all'' types of astronomical bodies: stars, asteroids, minor planets, comets, etc. as well as observations of interest, corrections, etc. Here you have the printed IAU circulars announcing and and . More recent version are available by subscription. As you can see, the official names have always been announced in printed circulars, which don't have any restriction for diacritics, umlauts, dashes, scientific symbols, etc. Decades before the circulars started, they were announced in printed journal '']'', which also didn't have any restriction in characters. Telegrams didn't play any role in name announcements, they were just for quick announcements of discoveries. At discovery time comets only had a provisional designation like 1944b (second comet discovered in 1944). --] (]) 16:27, 16 October 2012 (UTC)
I am not sure about the coded and illegible part. The IAU recently, though, asserted using capital letters for planets, etc., but it is not clear if that extends to comets. Hale-Bopp for example could simply be certified as being "the comet Hale-Bopp", which provides no insight into capitalization of comet. The examples given were Solar System and Earth's equator.

It was noted that the naming of all planets so far has long predated the existence of the IAU. I think that rather than naming things they standardize names and certify them, and are an arbitor, but they do not make up the names, or sell names.{{quote|The IAU frequently receives requests from individuals who want to buy stars or name stars after other persons. Some commercial enterprises purport to offer such services for a fee. However, such "names" have no formal or official validity whatever.}}
Based on the survey of google book results below it is clear that the endash conclusion in 2011 took an extreme minority viewpoint and put the MOS in conflict with WP:TITLE. I suggest that it be reversed in light of new information, and that the examples of wars and comets with endash be removed from the MOS and replaced with hyphens. Whether the use of hyphens will remain dominant or, like Kiev could be replaced with a new spelling remains to be seen. WP is not a crystal ball and does not try to reflect what people should be doing or what they might be doing but simply what they are doing. Just as Kiev remains the overwhelming spelling in common usage, Comet Hale-Bopp (with a hyphen) is the dominant spelling for the comet Hale-Bopp (correctly not capitalized when preceded by the), along with airports and wars which have achieved proper name status and if there are any other names with endash or hyphen they, like Comet Hale-Bopp can be tested to see if they use an endash or a hyphen in common usage, but the MOS does not need to pretend that endash rules apply inside names, because that is not the interpretation of the vast majority of book editors. Should that change, clearly WP would eventually reflect that change as well, but certainly can not be expected to ''precede'' that change. To do so would be ]. ] (]) 13:49, 16 October 2012 (UTC)
:The IAU decides who were the original discoverers and in which order they made the discovery, and the spelling of the comet name (the thing with modifying the hyphenated surnames). The IAU also fixates the transliterations of foreign names so they are spelled in only one way by everyone, although I can only give a example for a Moon crater(1). The IAU can ignore suggestions, see what happened to ]. If you disagree with a naming decision you can only appeal to the IAU itself. Most importantly, you can't assign arbitrary names to comes that you discovered yourself, the IAU will decide the name for you whether you like or not.

:(1) . The IAU has fixated the transliteration of "]", which is named after a Russian rocket scientist. You could drop the last "i" and still have a valid transliteration of the guy's name from the Russian language, but then it wouldn't be the crater's correct name. The IAU standardized all Moon crater names in 1975, and it only accepts names of dead people, except for Apollo astronauts; some old names were retained, others were changed . In 2008 the ] probe mapped Mercury, and the IAU made rules for the names of it surface features: the biggest basin received a unique name, cliffs were named after famous ships, and craters were named after "'deceased artists, musicians, painters, and authors who have made outstanding or fundamental contributions to their field and have been recognized as art historically significant figures for more than 50 years.''". The IAU approved names for each feature and then published official maps.. The IAU can pull this stuff because it's the naming authority in astronomy matters.
{{quote|1=Q: Who is legally responsible for naming objects in the sky? <br><br>

A: The IAU is the internationally recognized authority for naming celestial bodies and surface features on them. And names are not sold, but assigned according to internationally accepted rules. "", IAU's FAQ}}

{{quote|1=(...) rules established by the IAU, which emerged as the arbiter of planetary names and coordinate systems during the early years of space exploration. Back then, standardization helped to prevent the Solar System from being plastered with conflicting sets of names used by Soviet and US scientists. These days, the tensions are less nationalistic and more interdisciplinary: a dust-up between the geologists who tend to lead planetary missions and the astronomers who comprise much of the IAU. “Why should I let astronomers name things just because they’re on another planet?” asks Mike Malin, a geologist and principal investigator for the mast camera on NASA’s Curiosity rover mission, which has generated its own conflict with the IAU over the naming of a feature at its Martian landing site. "". ''Nature'' 22 August 2012}}

{{quote|1=To avoid further disputes as proud pioneers sought to thank benefactors, curry favour or merely indulge themselves, the IAU went on to establish working groups to set rules and conventions for nomenclature.<br><br>,

Procedures now make sure that mountains on Mercury are named with words for 'hot' in various languages, canyons on Venus christened after goddesses and small craters on Mars twinned with villages on Earth. Just last month, a 39-kilometre-wide Martian crater was named Moanda, after a town in Gabon. "". ''Nature'' 22 August 2012}}

{{quote|1=By that time, tiny P4 should have a real name. "We're tossing around some ideas," says Showalter, "but the name has to come out of Greek mythology associated with Hades and the underworld." That's according to the International Astronomical Union (IAU), which formally approves the names of heavenly objects — and which has strict and sometimes arcane guidelines for what's permitted. Underworld myths are the rule for moons of Pluto; for moons of Uranus, it must be characters from the works of Shakespeare and Alexander Pope — specifically Pope's poem "The Rape of the Lock." That required Showalter to learn the verses well. "I'm the discoverer of two moons of Uranus," he says. "We named them Cupid and Mab."<br><br>

The IAU is also responsible for the decision in 2006 to demote tiny Pluto, just one-half the size of Earth's moon, to the status of dwarf planet. "" ''Time'', Science section, 25 July 2011}}

{{quote|1=So who's in charge of naming solar system objects that are discovered now? Since its organization in 1919, the International Astronomical Union (IAU) has been in charge of naming all celestial objects. When an astronomer discovers an object, or wants to name a surface feature, they can submit a suggestion to the IAU, and the IAU either approves it or suggests a different name. Since we don't think there are any undiscovered planets, the IAU focuses on the naming of moons, surface features, asteroids, and comets and has websites about naming conventions for each. "" Astronomy department of Cornell university. }}

{{quote|1=The only official body which can give names to astronomical objects is the International Astronomical Union (IAU). (...) All official names have to be adopted by the IAU. There are certain rules which have to be followed in the official names allocated to different types of object; some of these are outlined below. (...) Comets. Comets are named after their discoverers. (...) In 1994, the International Astronomical Union updated their mechanism for naming comets (...) For more information on comet designations, please visit the International Astronomy Union website (...) "" ]}}

:So, is it clear now that the IAU's naming guidelines are not an "in-house style"? And that the IAU is the only body with the power of ''naming'' astronomical stuff and defining the exact spelling of each name? --] (]) 22:59, 17 October 2012 (UTC)
::The words "The MoS presents Misplaced Pages's house style" need to be nixed too. WP is not a publishing house and does not have a house style. WP is not a monolithic organization under the command of one person, even though some editors would prefer that. There are many styles that are appropriate, and the MOS explains what some of them are. It is not either inclusive nor exclusive. Editors refer to it for suggestions, but use their own common sense in applying what it says. Britannica, on the other hand, is a publishing house, and does have a house style. The words "house style" are not common language and have no reason for being used, even if we were a monolithic organization, and even if we did have a "house style", which we do not. ] (]) 17:08, 18 October 2012 (UTC)
:::Let's not expand the scope of this section so much, or we will get nothing done. We were talking about comet names: the capital "c" in "Comet", the hyphens, and the proper name status. --] (]) 18:02, 18 October 2012 (UTC)


{{od}} Above, Enric Naval ignores the difference between naming and styling, and between official names and common names. The IAU has a brief style guide in which they "recommend" capitalization of names of individual astronomical objects (just as many other organizations have style guides that recommend capitalizing the important items in their respective fields). "The IAU formally recommends that the initial letters of the names of individual astronomical objects should be printed as capitals" as their says, referencing their which clarifies that this is "in IAU publications". If they have a recommendation for how the general public should choose to style the names, I'm not sure where it is. And if they have info that says "comet" should come before or after the name, I'm not seeing that, either; it's clear that in common names, Halley's comet is more common the comet Halley, but others go the other way. Does IAU control this? I don't think so. Do they have an opinion on en dashes? Like many style guides, theirs doesn't say anything about that. ] (]) 17:45, 18 October 2012 (UTC)

:(I'll comment on hyphens. I won't comment on comet/Comet.) The IAU's comet ''naming'' guideline, not ''styling'' and not an in-house style, says that discoverer names are separated by hyphens. And says to remove hyphens from hyphenated surnames to avoid confusions with said hyphens, like ], discovered by Singer-Brewster, or drop part of the name hyphenated surname, like ], discovered by Bally-Urban and Clayton. Thus, these compounded names are not built with standard English rules, they are built with IAU's naming rules, which give explicit instructions for using hyphens and spaces to separate the name in a manner that doesn't cause any confusion about how many discoverers the comet has. (Thus, it's not necessary to use dashes to separate surnames, because there is no possible confusion with any hyphenated surname in ''any'' comet name, past or future.) --] (]) 18:02, 18 October 2012 (UTC)
::First a clarification. The IAU is not referring to an internal guideline about how they should internally recommend capitalizing or recommend using spaces and hyphens - they are the final arbitrator as to what the "official" name of a comet or planet is. They use those guidelines in helping them make those decisions, and they publish their answers. Bally-Urban was certainly asked would you like to use Bally or Urban because you can not use both. Singer-Brewster could have been asked, but the guideline permits using up to two names. Some names go on . Secondly while there is a difference between the official name and the common name of many things, in neither case do comets use a hyphen. Common usage is tested, as it was here, by checking as many sources as possible and determining the most common usage. Scholarly sources could tend to prefer the official name, but not necessarily. Common names could tend to prefer comet Halley or Halley's comet, or Halley's Comet. It is not clear whether the IAU is even specifying whether comet goes before or after the name and is simply addressing the variable portion of the name - the word planet is not a part of the name planet Earth, why would comet be part of the name comet Hale-Bopp? It is completely acceptable, in context, to use Hale-Bopp. The dominant convention though, is clear, for most comets, it comes first. But the MOS is not the place for establishing title rules. That domain is at ], which has, like the MOS, 70 subpages for assistance. ] (]) 19:29, 18 October 2012 (UTC)
:::WP doesn't care what IAU wants to do stylistically. ]. IAU allegedly asserting that its stylistic decision to favor hyphens over dashes (I would bet good money they did not in fact draw any such distinction, and are only drawing a distinction between using a space and using a dash that they have misnamed a hyphen, because they're astronomers, not grammarians; Apteva's own post of 14:54, 16 October 2012 (UTC) supports my view here) is actually a {{em|naming}} matter not a {{em|style}} matter is simply an alleged assertion and not one that WP is magically bound to recognize when it defies common sense and conflicts with our business as usual of creating an encyclopedia. — <font face="Trebuchet MS">''']''' &nbsp; <span style="white-space:nowrap;">] ɖ∘¿<font color="red">¤</font>þ </span>&nbsp; <small>]</small></font> 22:15, 21 October 2012 (UTC)
::::Did you read all the quotes I posted above? The IAU has a ''naming'' guideline, not ''styling''. It decides the names ''and'' how they are written, and how foreign names are transliterated from other languages. I have seen several sources explaining that comet names use hyphens, and how hyphenated surnames need to have the hyphens removed so they don't conflict with the other hyphens. I have never seen any source saying that the IAU really meant to use dashes and not hyphens. --] (]) 13:28, 23 October 2012 (UTC)

::::I still don't see any argument beyond "IAU only sets the styling", which is patently incorrect according to multiple reliable sources, and "IAU meant a dash", which is not supported by any reliable source and directly contradicts a few of them that make explicit mention of this rule. So, are we going to remove Hale-Bopp as an example of a compounded name in English. Maybe we should rename all counterexamples lik the airport names:
::::* ] → ]
::::--] (]) 13:20, 30 October 2012 (UTC)
:::::The fact that Hale–Bopp is so often found with en dash in sources, including astronomy journals, is strong evidence that the IAU naming guidelines are not being interpreted as styling guidelines in either astronomical or general publications. ] (]) 18:07, 30 October 2012 (UTC)
::::::I looked at the first 50 results in google books, and only 3 use a dash. Even if you discard books that use wikipedia material, self-published books, uncheckable books, and books from suspicious publishers, there is only a tiny minority of books that choose to use a dash, 3 versus 40. Google news also show a supermajority of hyphens. I think that this is much stronger evidence that astronomical and general publications actually look at the IAU when they make style decisions. And, yes, you can find as many isolated examples as you want, but they are still a tiny minority when you look at the whole of publications. --] (]) 18:52, 2 November 2012 (UTC)

== Modification to MOS:IDENTITY ==

<!-- ] 22:31, 14 November 2012 (UTC) -->
A few weeks ago, there was a proposal at ] to modify the wording of MOS:IDENTITY, specifically Point 2; the archived discussion is . It gained some traction, but it died down without any kind of resolution, so I want to raise it again. The specific change being sought is;

{{xt|"Any person whose gender might be questioned should be referred to by the gendered nouns, pronouns, and possessive adjectives that reflect that person's gender at the time of notability as reflected within the prevalence of mainstream ]. Identity changes thereafter should be dealt with chronologically but should always follow the conventions used with prevalence in mainstream sources."}}

Instead of copying over the rationale, the link to the archive shows Berean Hunter's rationale, and other examples are provided in the thread. If people think this would be better discussed elsewhere, that's fine, but since the waters at VPP have been tested this seems like the most logical place. ] (]) 17:49, 4 October 2012 (UTC)
:I made a similar proposal back in May ]. I agree with Blade that we need to follow what mainstream sources say rather than get ahead of these sources by making a judgment based on an individual's statements. ] (]) 18:11, 4 October 2012 (UTC)
::Does this mean we'll have to change ]?? ] (]) 18:40, 4 October 2012 (UTC)
:::Yeah, it would. ] (]) 18:46, 4 October 2012 (UTC)
::::What would the template's words have to change to?? ] (]) 18:48, 4 October 2012 (UTC)
:::::Hadn't thought about it... that'll obviously need some work. ] (]) 18:55, 4 October 2012 (UTC)

Can you clear up the '''exact''' meaning of this proposed rule?? Is it any similar to the following:

''Trans women who are notable for being trans women should be referred to as she/her. However, trans women notable primarily for an event before the operation of surgery for a reason that has nothing to do with being transsexual should be referred to as he/him as if they were cisgender men''. ] (]) 22:29, 4 October 2012 (UTC)
:Almost. The first sentence is right, but the idea is to refer to, say, ] as "he" when he was identifying as Tom Gabel and "she" after coming out in public as a she. Make sense? ] (]) 00:10, 5 October 2012 (UTC)
::You mean, we should assume that trans women '''actually were men''', not women trapped in men's bodies, before the operation?? ] (]) 00:13, 5 October 2012 (UTC)
:::To couch it in less loaded, more policy-based language, it's to avoid outright misleading revisionist history such as "she captained her tennis team at Horace Mann" (in the article on ]); specifics are in the linked VPP conversation. We at Misplaced Pages aren't here to play psychologists and pass judgment on whether or not they were ''really'' men or just women all along, we're here to report facts; in the cases of Grace and Richards, among others, they were notable under different names and sexes and our articles should reflect that. And this also works the other way too; the article on ] should be treated the same (and as of writing is actually a good example of what I'm shooting for). ] (]) 01:34, 5 October 2012 (UTC)
::::''Notable under different names and sexes''?? This phrase actually '''does''' imply the statement I was asking above whether we should assume. ] (]) 19:14, 10 October 2012 (UTC)
:::::The sex the person was commonly believed to be at the time. I think this is a slam-dunk. We do not &mdash; we must not &mdash; take a position on whether a person's "real" sex is. The choice to retroactively apply a sex change to previous notable events is nothing short of advocacy of a particular point of view; it must stop. --] (]) 20:02, 10 October 2012 (UTC)
::::::And likewise the choice to refer to people by the genders to which they were misassigned at birth is also advocacy of a point of view -- it's a claim that the person writing the article knows better than the subject what their name and gender are. ] (]) 01:12, 27 October 2012 (UTC)
:::::::In the case where we have the person saying "I am gender X, I have always been gender X, and things were misreported by the media". I agree with you. We rarely have such a statement. Quite often the person THEMSELVES represented themselves as the other gender at times in the past. Saying they did not is a lie, and unenclyclopedic, regardless of what they may have felt. ] (]) 01:43, 27 October 2012 (UTC)
::::::::In the case of ], we have someone who actively sought to be and maintain a public image as a man; rewriting the article to state otherwise (as some people attempted to do before someone hacked out a temporary solution) is downright inaccurate. ] (]) 02:21, 27 October 2012 (UTC)
This section can be archived, just like any section of a talk page. I remember from 2004-2006 the "Georgia moving poll" which was wasn't archived for a long time. (It was at ]; now it's in an archive.) Can we put this discussion in a similar area so that it won't be archived too quickly?? ] (]) 17:00, 11 October 2012 (UTC)
:Not sure... anyone familiar with this talkpage have suggestions? ] (]) 22:15, 11 October 2012 (UTC)
::Think I've got it... now on with the discussion. ] (]) 22:31, 15 October 2012 (UTC)
:::I support this change. This issue is also coming up in ] article as Larry/Lana has now come out after transitioning male->female. Obviously most notable for events when she was identified explicitly as male "The Wachowski Brothers" etc. However, renewed notability with the recent release of Cloud Atlas where she is doing interviews etc as Lana. General lede/summary information should use the prefered gender/name. However, historical information should use the gender used by that person at the time, as reported in reliable sources. it is ] to assume we know what they considered their gender in the past; ] to assume they considered themselves "trapped" etc, unless they have explicitly said so. Not everyone's LBGT path is the same. The guidance provided in the current MOS leads to innacurate information - the given example of "He gave birth->He became a parent" in particular is a loss of precision unacceptable for an encyclopdia. There are a multitude of ways to become a parent (father, give birth, adopt, just take responsibility for, etc) and removing a factual statement because the gender doesnt make sense is inaccurate. ] (]) 16:18, 25 October 2012 (UTC)
::::Perhaps we can add something to say prefer neutral language wherever possible where the historical information disagrees with current preference, or add qualifying statements such as "John so and so, who prior to their gender transition identifed as Jane, gave birth" etc. ] (]) 16:36, 25 October 2012 (UTC)

:We should keep the current rule, in which we use the individual's most recent preferred pronoun. If a source from 1986 says that singer Crystal Zing was born in Nashville, but Zing later digs up her birth certificate and finds out that she was really born in Memphis and only grew up in Nashville, then we should no continue to say that she was born in Nashville, even though an otherwise reliable source says that she was. That source was wrong. It is the same idea with people who undergo gender transition, like L. Wachowski. The sources (like most of the rest of the world) made a good-faith mistake in referring to Wachowski as male. More accurate information has come to light showing that Wachowski is female. ] (]) 00:32, 26 October 2012 (UTC)

::You are making an assumption that you know that Wachowski considered themselves female at that point in the past (and in this case when they explicitly identified themselves repeatedly as "Wachowski Brothers". Not everyone who is trans has felt that way their entire life. You might not claim Zing was born in Nashville. But you might say that she SAID she was born in Nashville until X, which was true before the birth certificate, and will be true forever. To say that they always claimed to be born in Memphis is inaccurate. ] (]) 01:07, 26 October 2012 (UTC)

:::Not everyone who is trans has not felt that way their entire life. If our aim is to respect trans people's subjective experiences, shouldn't we allow for the possibility that some trans people will make statements along the lines of, "I have always been a woman," and respect that when they do? On a related note, while it is necessarily the case that trans people found their identities before being public about them, it is not necessarily the case that the prevalence of "mainstream, reliable sources" will reflect their identities in a timely manner. Indeed in the case of some trans people -- I have in mind certain historical figures and trans people whose only mention in mainstream media is in obituaries in which they have been misgendered -- this will never happen. -- ] (]) 02:38, 26 October 2012 (UTC)
::::This is an encyclopedia, not an LGBT publication; we don't rewrite history to pretend peoples' previous names/identities didn't exist. Just as we don't refer to ] (I can't believe I'm using him as an example for anything) by his stage name until he himself used it, so we should do the same here. It's one thing when someone wasn't notable at all before transitioning (c.f. ], which is completely fine), articles on these people wouldn't be affected. However, in extreme cases we get articles like ]; due to the current rule, the article is misleading and almost unreadable. We're referring to Palmer as "she" 35 ''years'' before Palmer transitioned. Palmer is almost exclusively notable for having played in Jethro Tull, and through that entire period was known as David Palmer; to pretend otherwise is 1. outright advocacy for a particular point of view on the matter (the ''only'' places I've ever heard Palmer referred to as a she while with Jethro Tull are LGBT publications and Misplaced Pages) and 2. misinforms our readers, because no one would have referred to Palmer as a she during that period. At ] people have at least managed to hack out a decent solution for the time being; however, the same problem described above exists with the Renée Richards article and is spectacularly bad at ]; the proposed wording would be able to resolve that. ] (]) 03:57, 26 October 2012 (UTC)
:::::Agree with Blade. It's an encyclopedia not an exercise in making people feel good about themselves. Otherwise any person with a biography on here could complain that they're not happy about the section concerning their adultery, massive fraud, or the murder of half a dozen people and we should remove it because it offends them and they say that they don't feel they ever really killed all those people, it was the voices in their head. The encylcopedia should reflect the history as it is, Lana Wachowski can have felt like a woman since she was born but she identified herself as male, went by male monikers, filed credits for films as Larry Wachowski or The Wachowski Brothers, filled out forms as a male, that is the reality of the situation. I raed the above link to Laura Jane Grace and an IP on there actually advocated removing all mention whatsoever of the name Tom Gabel and retroactively modifying the history of the person as if there was never a man named Tom Gabel in existence. It's ridiculous over sensitivity and not what the place is about, otherwise that album cover with the underage girl on it would have been removed quite sharpish. ] (]) 22:10, 27 October 2012 (UTC)
::::::], if the problem is that some people want to remove all ''mention'' of the name -- not merely every instance in which the name is used to ''refer'' to Laura -- then why not deal with that problem? Why not explain to the user what "refers to" means and that nothing in the MOS forbids wording such as, "Laura Jane Grace, whom people used to call . . . ." In ] the problem is almost the opposite; I have been trying to remove every instance in which Lana's old name is used to refer to her while retaining mere mentions of her old name, but another editor insists on referring to her by her old name. To prevent future violations of this sort should we revise the MOS to say that all mentions of trans people's former names is forbidden? (And, just to be clear, I am definitely not proposing this.) I do not see how that would be more overkill than what you are suggesting. -- ] (]) 13:55, 28 October 2012 (UTC)
:::::], when have I ever advocated "rewrit"ing "history"? There is no reason we cannot acknowledge people's previous names while still referring to them in accordance with their new names, e.g., "John, whose name used to be Jane, lived with his parents in Wyoming until 1983." (This is exactly the sort of solution I have time and time again said I would support regarding ].) While editors may not refer to Eminem as Eminem while writing about his past, we do frequently refer to ] as Twain, even while talking about his ]. We cannot avoid "outright advocacy" by writing articles as though a trans person is, say, Jane one day and John the next; that is a not very subtle suggestion that the correct view of trans people is a particular view that real people have advocated. This is an encyclopedia -- not an anti-LGBT publication. -- ] (]) 13:55, 28 October 2012 (UTC)
:::::::(Note; only a response to the section addressed to me) The names aren't an issue; it has been worked out that we use the proper nouns publicly in use at the time period being written about (in addition to Laura, The Wachowskis and ] are written this way), and MOS:IDENTITY contains nothing suggesting otherwise. A better non-transgender comparison is ], as unlike Eminem or Twain he actually did change his name. We avoid advocacy by doing exactly the same with gendered pronouns. To use the Renée Richards example, the early life section is actively misleading; contrary to what the pronouns in the article state, Raskind was ''not'' attending a girl's school and captaining the girl's tennis team (Horace Mann at that time separated boys and girls, but then as now was one school, parenthetical added 16:46, 28 October 2012 (UTC)). It's not anti-LGBT to do what I'm suggesting, it's accurately documenting peoples' lives. ] (]) 15:27, 28 October 2012 (UTC)
::::::::The Renée Richards example is a false analogy. If she was in a class intended for boys, it was inaccurate to say she was in a class intended for girls. However, there is nothing inaccurate about using names or pronouns based on one's current situation. That is why we can say that someone named Isabella was born on such and such a day, even if Isabella did not have a name until some time after she was born. Indeed this is the pervasive practice in such situations. If there is disagreement over whether, say, a trans woman really was a woman, the only neutral, natural way to handle it is to call her by the currently used pronoun; it is only when we start calling her by anything else that we take a side in the matter.
::::::::Incidentally, the proposal, though being offered as neutral, is advocating more than I have suggested above. The proposal does not take all reliable sources into consideration; it simply privileges some sources (i.e. mainstream media sources that were written at the time) over others (e.g. mainsteam media sources that were written after the fact, the style guides of the same mainstream media sources, revised birth certificates, and genetic or neurological research that shows that trans people have had their genders from birth). If the proposal were to go into effect, we could not even take retractions written after the time of notability. Do I need to explain why painting ourselves into a corner like this is a bad idea?
::::::::-- ] (]) 16:04, 29 October 2012 (UTC)
:::::::::There are two problems with this. One, how do we deal with the fact that Richards has records under the name Richard Raskind as a male tennis player? The current approach makes the entire Early life section seem to contradict itself. Secondly, I'll once again point to the Dee Palmer article as evidence why the current one-size-fits-all approach breaks down. As I've pointed out above, the article right now makes no sense (anecdotally confirmed by both people I've asked IRL to attempt to read it and by someone at ], which I'm sure you've seen) because we're going back 40 years to retroactively change someone's sex; Palmer was known as David through the entire time he was playing in Jethro Tull. The goal here is to remove these instances where articles are being left unreadable because of this. I've asked in a couple venues for some fresh input, so hopefully we can get a few people; I'm not sure whether or not this is RfC-worthy, but we can certainly do that if people think it's warranted. ] (]) 22:23, 5 November 2012 (UTC)
::::::::::I am not advocating an all-or-nothing approach, though that is exactly what the proposal above is. If Kim's old name was Tim and Tim is a notable name for whatever reason, then we can include sentences along the lines of, "Kim, whose name used to be Tim, left her small town at the age of 23." This gives the reader all the information they need about Kim's name without ''referring to'' Kim as Tim. Looking at the "Early Life" section of the Renée Richards article as it currently stands, I do not see what the problem is. I must confess that I have not collected anecdata myself, but I suspect that if I asked the people in the circles I run in whether the section makes sense, at least 90% would say yes. If anyone does not understand why Richards would say she was raised a "boy", the mention of her old name provides a clue. And if readers have trouble understanding an article that is naturally, accurately, and sensitively worded, shouldn't our approach be to give them the information they need to understand it instead of protecting them from the aspects of reality that challenge people's worldview? -- ] (]) 05:47, 7 November 2012 (UTC)
:::There is no entirely neutral way of dealing with the issue of gendered pronouns for transgender individuals. If we refer to a male-to-female individual as "he," then we are taking a position. If we refer to a male-to-female individual as "she," then we are taking a position. If we switch back and forth, we're taking a position (and we look stupid). Because these three options are roughly equal with respect to politics, we should choose the person's most recent preferred pronoun because, unlike the other two options, it is polite.
:::What that does not involve, however, is revisionist history. Referring to Lara Wachowski as "she" does not make the assertion that she was born with female genitalia, only that she is properly referred to by a female pronoun. The way to prevent the readers from misunderstanding is to clearly refer to Lara Wachowski as a transgendered person by saying "Lara Wachowski, then Larry Wachowski," or "Lara Wachowski, who would undergo gender transition at the age of ..." Any biographical article that that does not acknowledge a person's gender transition clearly needs to be rewritten in the first place. Whatever the politics of the matter, it's an important and relevant part of a person's life, at least as important as what school he or she attended or whom he or she married.
:::In this way, referring to a male-to-female individual as "she" while saying that she went to a single-gender school is not misleading so long as the article either 1. states that this is a male-to-female transgender individual or 2. refers to the school as an all-boys school. ] (]) 16:10, 28 October 2012 (UTC)

===Request for comment===
{{rfc|style|rfcid=2DB7E15}}
Should the above proposed change MOS:IDENTITY Point 2 be instituted, or should the current wording be retained? ] (]) 18:24, 12 November 2012 (UTC)

I think my view is pretty much evident from the above, and hopefully we can get some more input from an RfC. ] (]) 18:24, 12 November 2012 (UTC)

:'''The current wording should be retained''' for the following reasons:
:# It is common, if not usual, to refer to a person at any point in the past using the referential words that currently refer to them. People, including Misplaced Pages's editors, refer to El Greco as El Greco, even when writing about the artist's childhood. Similarly, though there is a time when it is acceptable to say, "It's a girl!", we would not say, "It was born in 1983," when talking about someone who is currently an adult. People often flout the common practice when they are being sensationalistic (e.g. "He's a she!") or when they are exercising poetic license (e.g. "Cassius Clay was born in Louisville . . . Muhammad Ali was born in Miami"). Whatever the merits of these styles of writing elsewhere, it does not fit an encyclopedic tone.
:# Referring to someone using the words that currently refer never suggests anything about what terms were appropriate in the past (see Point 1). On the other hand, using different pronouns does indicate that they were the right pronouns in the past, even though some people view trans people as always having been the genders they currently identify with, and we might not know how trans people identified in the past. This raises questions regarding ] and sensitivity.
:# The proposed change is incoherent. If it were adopted, how would editors handle sentences like "] has been a director since 1995"? This concerns a period that begins at a time when the media referred to Lana as "he" and ends at a time when they referred to her as "she". According to the proposed edit, we must therefore refer to Lana as both "he" and "she".
:# The adoption of the proposed change would allow or even require editors to refer to trans people using phrases like "he-turned-she" (as the ''New York Post'' once did). This is unwieldy and insensitive.
:# As I argued above, the proposed change would put unreasonable limits on what would be considered reliable sources.
:# The proposed edit would require us to disregard the recommendations of trans advocacy groups.
:As far as I can see, the only widely agreed upon rationale for making the proposed change seems to be that it would eliminate confusion. There are already people who have been making edits along the lines of what the proposed change would require, and I personally find the fruits of their good faith edits to be more confusing than the text they are trying to fix. In any case, there are better ways to reduce confusion. If the problem is that some readers are not acquainted with trans people's new pronouns, the current MOS allows us to use a wide range of methods to indicate how the person was once identified (e.g. "John, formerly known as Jane, was born in 1983"). If the problem is that readers do not understand trans people, the current MOS does not forbid us from linking to pages (], ], etc.) that will help them understand.
:At this point the only relevant change I would like to see made to the MOS would be to make it explicit that trans people should be referred to using not only the pronouns but also the names by which they are currently identified.
:-- ] (]) 19:19, 13 November 2012 (UTC)

== Supply of professional editors ==

In the interest of maintaining a supply of available Wikipedians with professional skill and experience in editing, I bring attention to these categories.
*] includes ] and ] and ].
*] includes ] and ], which includes ] and ] and ].
*Also, ] (version of ) includes 12 editors: ] and ] and ] and ] and ] and ] and ] and ] and ] and ] and ] and ]. <br>
I have started the page "]", a copy of which is reproduced below.

This is a list of '''list of professional editors who have edited Misplaced Pages'''.

{|class="wikitable sortable"
! Editor
! Sex
! Lifespan
! Nationality
! User information
! Activity status
|-
| ] || M || 1954– || American || {{User6b|Kbanderson}} || Inactive
|-
| ] || M || 1956– || American || {{User6b|Peppetters}} ||
|-
| ] || M || 1946– || English || {{User6b|Ramsey Campbell}} ||
|-
| ] || F || 1962– || American || {{User6b|Pleasantville}} ||
|-
| ] || M || 1963– || Welsh || {{User6b|Mikedash}} ||
|-
| ] || M || || American || {{User6b|Scarpia}} ||
|-
| ] || M || 1949– || British || {{User6b|Henry Hardy}} ||
|-
| ] || M || 1959– || American || {{User6b|Pnh}} ||
|-
| ] || M || || British || {{User6b|Ptolemyphil}} ||
|-
| ] || M || 1944– || Dutch || {{User6b|Lambert Meertens}} ||
|-
| ] || M || 1957– || American || {{User6b|Sheldon Rampton}} ||
|-
| ] || M || 1970– || American || {{User6b|Jsnell}} ||
|}


:Sounds Latin enough to me. ] (]) 11:52, 26 November 2024 (UTC)
]
] <br>
—] (]) 20:29, 1 November 2012 (UTC)


::Agree. The concept of a "romanisation" of NAPA doesn't make sense to me. In fact, NAPA in some ways strikingly resembles romanisation schemes for Cyrillic, and Cyrillic variants that have been used to transcribe or write down previously unwritten languages, so much that in the past I've wondered if UPA and NAPA originally ''arose'' as romanisations of Cyrillic-based transcriptions. --] (]) 01:26, 10 December 2024 (UTC)
:This is just crazy. If you want a "supply" of professional editors, ask for volunteers. This list is useless. ] (]) 21:34, 1 November 2012 (UTC)


== Stale advice: slashes have been line-breaks since 2005 (Unicode 4.1.0) ==
:I don't know about crazy, but certainly seems pointless. Is it presumed that "professional editors" are more likely to step forward if they can have their name in a list? Or is it to make easier for Wikipedians to find these professional editors? I suspect that would tend to deter them from stepping forward. I question whether these individuals have indicated willingness to be "available" (have they been asked?); this could be deemed a form of ]. That some of these users are red-linked shows that they are ''not'' so available. This effort seems very poorly conceived. ~ ] (]) 00:11, 2 November 2012 (UTC)


{{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."
::The main purpose of the list is to make it easier for Wikipedians to find these professional editors. I do not understand how or why it would deter them from stepping forward. If the list constitutes an infringement of the policy at ], then does not ] do likewise? In either case, I did not intend any malice. If I behaved improperly by assembling the information, then please forgive me.
::—] (]) 01:35, 2 November 2012 (UTC)


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 .
:::What ] are you actually imagining for how Wikipedians might use this list? Are you imagining we might email them and ask them for help editing, or professional opinions, or what? ] - ] 10:39, 2 November 2012 (UTC)


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)
::::I am visualizing those editors contributing from their expertise to the extent of their ability and willingness to do so. That might involve (1) answering questions, (2) contributing to discussions, (3) applying the MOS guidelines, or even (4) becoming participants in ] (]). Also, they might (5) initiate discussions or (6) directly edit the guidelines.
::::—] (]) 19:49, 2 November 2012 (UTC)
:::::I'm a professional proofreader. If you want me to do something, you can just ask.
:::::I guess there's a little ego buzz on being on a pro list, but is there any verification system? ] (]) 02:24, 3 November 2012 (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. ] (]) 02:45, 14 December 2024 (UTC)
::::::Yes. Someone can volunteer, or even be asked if they might volunteer. But simply extracting and then posting a list ''inviting'' people to ask for help (where there is no indication that tese people have actually volunteered) seems tantamount to harassment. (] doesn't invite people to contact them.) That some of these users we are being directed to are red-linked really undercuts the intended utility. ~ ] (]) 20:59, 3 November 2012 (UTC)


== Placement of composition/description/synopsis/plot sections ==
:::::::The act of asking another person for help is not, in itself, harassment. I suppose that a typical human being both asks and is asked for help of various kinds frequently.
:::::::According to ] (version of ), a "'''userbox''' (commonly abbreviated as '''UBX''') is a small colored ] ... designed to appear only on a Wikipedian's ] as a communicative notice about the user, in order to directly (or even indirectly) help Wikipedians collaborate more effectively on articles."
:::::::The act of posting the list is not an act of asking for help. Also, the list is not inviting anyone to ask for help.
:::::::—] (]) 01:15, 4 November 2012 (UTC)


It has been loosely implied that I am an incorrigible, MOS recidivist who should either be placed in wiki-jail or released on my own recognizance and given an MOS ankle monitor and watched closely for compliance. This is because I have consistently used older styles of article writing where descriptions of the subject (art, film, literature, etc.) are ''not'' placed in section 1, but elsewhere, sometimes even in section 2 or section 3. There are many reasons as to why I did (or continue to do) this, mostly having to do with different types of narrative structures unique to each topic.
::::::::I don't think that asking someone for help is harassment, but this could end up being like telemarketers who call all the time for the editors on the list.
::::::::Is there a way to create a list of people who have put an "I'm an editor; ask me for help!" userbox on their talk page? Could such a list be automated? If this is possible, then it would be possible to expand it to lists of chemistry experts, comic book lore experts, Hungarian history experts, etc. for use in specialized articles. So long as it's voluntary and controlled by the editors in question, it could be a very good thing. ] (]) 02:38, 10 November 2012 (UTC)


Clearly, the film project has taken a strong stance against this, and I believe the vast majority of film articles are required to have the plot section in the section 1 position. However, I do remember that in the deep past, documentary films were often exempt from this, and would often find the synopsis sections in other positions. This was also true for older non-fiction articles until recently, for example '']'', where the synopsis appears below the background section in section 2, not 1. The same can be said for many different FA art articles, where the composition or description section appears in places other than section 1. Examples are many, including '']'' and '']''. '']'' is more interesting, where the description section is much, much farther down.
:::::::::The editors at ] might be able to answer those questions.
:::::::::—] (]) 03:27, 10 November 2012 (UTC)
:::::::::Also, there is ].
:::::::::—] (]) 16:32, 10 November 2012 (UTC)


In my mind, this was an acceptable interpretation of "one style or format is acceptable under the MoS" until recently, however, I believe this has fallen out of favor since about 2018 or so (as far as I can tell), and things have become much more rigid, and unlike Old Misplaced Pages culture, you can't do things differently anymore. My reading of this is that description sections in any form are now unofficially required to be in the section 1 position. In other words, if I write a new article right now and place the description of the topic anywhere but section 1, should I be reverted according to MOS practices (across all WikiProjects), or is there room for flexible interpretations across the project in different disciplines?
== Sentence case in section headings ==


As an example, in articles about paintings, I am partial to headings that reflect a Lead (0), Background (1), Development (2), and Description (3) structure, in that order. This has recently caused minor friction in other parts of the project with editors who dislike or disagree with me placing the description so far down. I would appreciate some additional insight into whether my practice is acceptable under the MOS. Thank you. ] (]) 20:30, 27 November 2024 (UTC)
There is an active discussion at ] (version of ). <br>
—] (]) 15:22, 4 November 2012 (UTC)


:] suggests Plot follows immediately after the lead, but "the structure and ordering may vary between film articles". Not sure about paintings. ] (]) 05:46, 28 November 2024 (UTC)
== Another use for hyphens? ==


==Input needed on disagreement over where the lifespan goes in relation to a baronetcy or a peerage title==
At ] we find a project guideline for formatting shortened airport names in destinations listings:
] 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:
:4. Differentiate between multiple airports in one city using "-" (eg "London-Heathrow", not "London Heathrow").
:''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:
I've been taking out a lot of hyphens in listings, where the links went to airports with spaces in their titles, like ], since I hadn't heard of this use of hyphens in WP (though I've seen it in various sources that list flights this way – rarely, per ). Any opinions on this? Is it an example of some more general use that we should represent in the MOS? Or is it a bad idea? ] (]) 04:44, 7 November 2012 (UTC)
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.
:A lot like Guinea-Bissau in the non-attributive usage. Not sure about attributive ''London Heathrow Airport'', though. — ] (]) 08:21, 7 November 2012 (UTC)
::I don't think it's like that at all. Guinea-Bissau is a name, estabilshed, well recognized. London-Heathrow is a made-up construction to abbreviate London Heathrow Airport, or to disambiguate the city destination when there are multiple airports, in certain compact contexts. It's quite hard to find in sources, deviating as it does from the established name. ] (]) 16:55, 7 November 2012 (UTC)
:::The Chicago House Manual of Style (15th ed.) has a painful seven-page-long description of the general patterns of hyphen use. This one likely comes under this type: "'''noun + noun, two functions''': ''nurse-practitioner'', ''city-state'', ''city-state'' governance'. (Both noun and adjective forms are always hyphenated.)" (7.90, p. 303, emphases in original). I would say "London-Heathrow" has two nouns with different functions, and so needs the hyphen when used standalone. ] (]) 17:44, 7 November 2012 (UTC)
::::Found it: . This is 16th, which clarifies those examples as "noun + noun, two functions (both nouns equal)". It's not clear if it applies to two different or unequal functions like city-disambiguator. ] (]) 01:18, 8 November 2012 (UTC)
:::::I think the way CHMOS uses it, for a noun-noun combination one either has "first noun modifies second noun" or "both nouns equal." From the context, looks like their definition of "both nouns equal" is essentially "first noun not modifying second noun." ] (]) 01:47, 8 November 2012 (UTC)
::::::Yes, perhaps that's all they mean. Still, I don't see how it supports inserting the hyphen into noun–noun compounds that are normally set open in more complete noun phrases. ] (]) 21:12, 8 November 2012 (UTC)
:::Yes, Guinea-Bissau is also "a made-up construction", just like Congo-Brazzaville. (Funny no-one ever says "China-Taipei", though.) — ] (]) 22:23, 7 November 2012 (UTC)
::::OK, but Guinea-Bissau was made up and accepted outside of WP, and I'm asking about what appear more like novel compounds made up for WP destination listings, which are not entity names. ] (]) 01:18, 8 November 2012 (UTC)


So here we are. I'd like input from the project, and I'm sure Muéro would like that too.
Most of these hyphenated destination listings are piped to more proper airport names. But in a few cases, the odd hyphenation has been used in the actual airport article titles. These seem to be almost always a bad idea, with a space being more sensible as well as more common in sources. So I've moved some of those. In other cases, sources seem to support the idea of a dash, so I've done that in a few cases. Are there cases where a hyphen is really the right answer? Still not clear. But where it's clearly not the right answer, is it OK to use it for a short form in destination tables? Is this a common convention? Why did the airport project adopt it? Still wondering... ] (]) 05:22, 10 November 2012 (UTC)


The discussion originated on ], but I'm copying it here, and closing it there, while notifying them.
For example, consider these airports in Italy: ] (see ) and ] (see ). The former appears variously in sources with space, with slash, with hyphen (including many copied from wikipedia), and with spaced hyphen. The slash and spaced hyphen strongly suggest an en dash in WP style. I don't find it in any English language books not copied from wikipedia, but in Italian books it appears with space, slash, or parens, never hyphen. So I'd go for space, knowing that the dash is sometimes annoying to some editors. In the case of Perugia San Francesco d'Assisi – Umbria International Airport, there's clearly at least one dash needed if we're going to connect so many alternative name and location parts into a title, so I'd be inclined to move it to the name, ], or the location-based name ]. But maybe that's not right. In the ] it's called "Perugia: San Francesco Airport"; so maybe ]? In destination talbes, it's just Perugia, which is fine. ] (]) 05:50, 10 November 2012 (UTC)


===The discussion on Muéro's talk page===
== Linking to categories ==
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've added a link to ], in a "see also" section of ]; but that's not very elegant. Is there a preferred way of making such links? Should I format it as, say, ]? The template we use to link to the related Commons category is much nicer; do we, or should we, have a template for linking to our own categories? <span class="vcard"><span class="fn">]</span> (<span class="nickname">Pigsonthewing</span>); ]; ]</span> 12:05, 7 November 2012 (UTC)


Thank you. ] (]) 15:50, 25 November 2024 (UTC)
== Allowable minimal change per MoS quote ==


: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)
* Per ]: "Trivial spelling or typographical errors should be silently corrected ... a few purely typographical elements of quoted text should be adapted to English Misplaced Pages's conventions without comment. This practice of conforming typographical styling to a publication's own 'house style' is universal."


::Hello again.
* According to the CMOS (16th edition), this type of change is acceptable. The point of "minimal change" is to retain the wording, not the syntax or typography. According to the CMOS: "Although in a direct quotation the wording should be reproduced exactly ... changes are generally permissable to make a passage fit into the syntax and typography of the surrounding text." (p.621), "the initial letter can be changed to a capital or a lowercase letter" (p.622), "words in full capitals can be set in lowercase, if that is the preferred style for the surrounding text" (p.622). From page 624 of the CMOS: "Changing capitalisation to suit syntax: Aside from proper nouns and some of the words derived from them, words in English publications are normally lowercased unless they begin a sentence. To suit this requirement, the first word in a quoted passage must often be adjusted to conform to the surrounding text." "Initial capital or lowercase: "When a quotation introduced midsentence forms a syntatical part of the sentence, it begins with a lowercase even if the original begins with a capital."


::Thank you for your understanding. Re: your latest edits, you're now leaving a comma in place that shouldn't be there.
* From the ''New York Times'' Style guide: "The Times does adjust spelling, punctuation, capitalisation, and abbreviations within a quotation for consistent style." (p.281)


Nathaniel Charles Jacob Rothschild, 4th Baron Rothschild, (29 April 1936 – 26 February 2024),
* From ''New Hart's Rules'' (Oxford): 9.1 General Principles: "While the wording of the quoted text should be faithfully reproduced, the extent to which the precise form of the original source is replicated will vary with context and editorial preference." (p.152) Further, 9.3.4 Typography states: "A quotation is not a facsimile, and in most contexts it is not necessary to reproduce the exact typography of the original." (p.160)
^ ^ ^
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.
* '''Question'''. - Is it an acceptable typographical/stylistic change to alter capitalisation of "The Beatles" in a direct quote so as to conform to our "house style", i.e "the Beatles"? ~ ] <sup>(]|])</sup> 00:10, 8 November 2012 (UTC)


::Cheers.
::I would say yes, but this is something we never got into in detail. BTW, when CMOS says "syntax", they don't mean ]. — ] (]) 00:50, 8 November 2012 (UTC)


::] (]) 17:52, 25 November 2024 (UTC)
::I think you have misrepresented CMOS regarding "the Beatles" vs "The Beatles" in a quoted bit of running prose. CMOS allows for the following:
:::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)
::*{{xt|] said, "the Beatles will go on and on."}}
::In this example, the entirety of Harrison's complete sentence, "The Beatles will go on and on," has been changed only by knocking the initial capital 'T' down to lower case. Because the "The" was at the beginning of the sentence, CMOS assumes that Harrison would have made it lower case in running prose. The CMOS stands opposed to your position regarding the case in which a writer purposely puts a capital 'T' in running prose; the guideline says to keep true to the original typographical style as much as possible. This much, I think, is possible for us to follow. ] (]) 00:52, 8 November 2012 (UTC)
::: I don't think the CMOS cares one iota about what Harrison wanted, this has to do with maintaining a consistent "house style". I'm also not seeing where the CMOS prescribes the ''exact'' reproduction of quoted material. Can you point me to where it says this? Publishers adapt prose to their house style, so why wouldn't we? At any rate, ''our'' MoS says: "a few purely typographical elements of quoted text should be adapted to English Misplaced Pages's conventions without comment", why do you think this does not apply? What have I misrepresented IYO? ~ ] <sup>(]|])</sup> 01:04, 8 November 2012 (UTC)


====Step by step====
* Binksternet, would you agree that the current Misplaced Pages "house style" is "the Beatles"? ~ ] <sup>(]|])</sup> 01:06, 8 November 2012 (UTC)
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:
::]. — ] (]) 02:05, 8 November 2012 (UTC)
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.
:::GabeMc, my 15th edition CMOS says: "''Syntactic and typographical considerations''. Although in a direct quotation the wording, spelling, capitalization, and internal punctuation of the original should be reproduced exactly, the following changes are generally permissible to make the passage fit into the syntax and typography of the surrounding text." This is why I think CMOS endorses the odd/awkward capital in a direct quote embedded in running prose. Yes, the Misplaced Pages house style is now "the Beatles" in running prose. ] (]) 03:25, 8 November 2012 (UTC)
:::: Binksternet, the same section in my 16th edition states: "13.7 Permissable changes to punctuation, capitalisation, and spelling. Although in a direct quotation the wording should be reproduced exactly, the following changes are generally permissible to make the passage fit into the syntax and typography of the surrounding text." (p.621) So, it would seem the CMOS editors have made a significant substantive alteration to the text of the 15th edition. Do you now agree that the latest version of the CMOS supports my assertion that "t"s should be brought in-line with our house style, "the Beatles", and not reproduced as a facsimile. ~ ] <sup>(]|])</sup> 03:42, 8 November 2012 (UTC)
:::::I acknowledge that CMOS has had a change of heart on the matter, from the 15th to the 16th edition. The fact that there have been two different practices recently advocated by CMOS weakens the argument. ] (]) 05:27, 8 November 2012 (UTC)
:::::: Does it weaken the argument more than this strengthens it? Also, the 15th edition of the ''CMOS'' is 7 years old, while the 16th is 3. Shouldn't we be using the most recently updated version as our guide, and not an outdated one?
::::::* From the ''New York Times Style Guide'': "The Times does adjust spelling, punctuation, capitalisation, and abbreviations within a quotation for consistent style." (p.281)
::::::* From ''New Hart's Rules'' (Oxford): 9.1 General Principles: "While the wording of the quoted text should be faithfully reproduced, the extent to which the precise form of the original source is replicated will vary with context and editorial preference." (p.152) Further, 9.3.4 Typography states: "A quotation is not a facsimile, and in most contexts it is not necessary to reproduce the exact typography of the original." (p.160) ~ ] <sup>(]|])</sup> 05:31, 8 November 2012 (UTC)


Now, let's add the life span. Where do we add it? Before punctuation.
::The flightier sources (fansites, etc.) use a capital T in "The Beatles," but the more professional sites say "the Beatles." The impression that I get is that the fansites are trying to aggrandize the band and playing fast and loose with English (which is pretty loose, I'll grant) to do so. I'd go with yes, it is acceptable to correct the capitalization and use a lowercase t. ''However'', Beatles fans have made such a ruckus about it that you should wear asbestos clothing while doing so. (To translate said joke into action, yes, use a lowercase T when inserting text, but expect to be reverted by a fan. Don't change it back unless you're prepared for a long fuss on the talk page.) ] (]) 03:50, 9 November 2012 (UTC)
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?


] (]) 23:04, 25 November 2024 (UTC)
GabeMc has been systematically misquoting, ripping out of context and cherry-picking the material he quotes from the ''Chicago Manual of Style'' and ''Hart's Rules''.
# GabeMc purports to quote the following: {{tq|"Although in a direct quotation the wording should be reproduced exactly ... changes are generally permissable to make a passage fit into the syntax and typography of the surrounding text.}} The ellipsis in the middle is highly distorting. What the CMOS actually says at that point is (emphasis mine): {{tq|Although in a direct quotation the wording should be reproduced exactly, '''the following changes''' are generally permissible to make a passage fit into the syntax and typography of the surrounding text}}. GabeMc has conveniently glossed over the fact that the CMOS is here presenting an exhaustive list of well-defined exceptions, rather than delivering a general blanket endorsement of whatever minor changes an editor might decide upon, as his quote makes it appear. Needless to say, none of the limited classes of exception actually listed after this sentence apply to the "the/The" Beatles case.
# GabeMc purports to quote: {{tq|the initial letter can be changed to a capital or a lowercase letter}}. He omits the fact that the actual passage in the CMOS further points to some following sections ({{tq|(see 13.13–16)}}), and those sections make it abundantly clear that they refer exclusively to cases such as the following: (13.14): {{tq|When a quotation introduced midsentence forms a syntactical part of the sentence, it begins with a lowercase letter even if the original begins with a capital}} (the CMOS goes on to provide examples such as {{tq|Benjamin Franklin admonishes us to “plough deep while sluggards sleep.”}} This is exclusively about the use of capitalization to mark beginnings of sentences.
# GabeMc quotes, purportedly from p. 622 of the print version of the 16th edition of CMOS (the same page as the one of quote #1): {{tq|words in full capitals can be set in lowercase, if that is the preferred style for the surrounding text}}. I have no access to the print version but only to the online version, same 16th edition, and I cannot find that quotation in that context at all. What I do find is something else entirely (emphasis mine): {{tq|Words in full capitals in the original may be set '''in small caps''', if that is the preferred style for the surrounding text.}} This, too, points to another section for more details, which makes it clear that it refers exclusively to matters such as "<span style="font-variant:small-caps;">nasa</span>" rather than "NASA". Gabe, did you accidentally misquote, or does the print edition have different text than the online edition?
#:In any case, nothing in the CMOS has any bearing on the non-trivial issue of the use of capitalization to mark proper nouns. This is not a matter of trivial typographical style but a matter of orthography, and as such far beyond anything the CMOS section contemplates.
# GabeMc purports to quote from ''Hart's Rules'' (Oxford UP), p.152 the following: {{tq|While the wording of the quoted text should be faithfully reproduced, the extent to which the precise form of the original source is replicated will vary with context and editorial preference}}. Again, he makes this sound as if it was a blanket endorsement of whatever orthographic changes an editor prefers. He conveniently leaves out the following on p.157: {{tq|In quotations from printed sources the spelling, capitalization, and punctuation should normally follow the original.}} This, as in CMOS, is again followed by a limited, exhaustive set of well-defined exceptions (p.158). Among them are the same two allowances for changes to capitalization: the initial letter of a whole quotation changed to integrate it into the surrounding syntax, and changes to words printed in all-capitals.
# GabeMc further purports to quote from p.160: {{tq|A quotation is not a facsimile, and in most contexts it is not necessary to reproduce the exact typography of the original}}. He conveniently leaves out the context: this is the section about "typography", and the next sentence makes it unmistakeably clear that it deals only with issues such as "change of font, bold type, underscoring, ornaments, and the exact layout of the text". This clearly does not include issues of ''orthography'' such as capitalization, because those have been dealt with in a preceding separate chapter ("spelling, capitalization, and punctuation")
#: Again, there is nothing even remotely hinting at the possibility of a non-trivial orthographic change like the one he proposes.
# GabeMc also quotes from the ''New York Times'' style guide: {{tq|The Times does adjust spelling, punctuation, capitalisation, and abbreviations within a quotation for consistent style}}. I have no access to the full text of this guide here, but from what I gather, this statement is from the context of a discussion of journalistic quoting of ''spoken language''. I see no indication that it has any bearing on how to deal with written sources.
GabeMc needs to stop misusing these quotations for his "the" crusade. If he continues trying to change quoted text in Beatles articles, or continues using these blatant mis-quotations of guidelines in support of doing so, I'm quite prepared to block him for disruption. ] ] 12:12, 11 November 2012 (UTC)
::Thank you for looking up the various style guides to see the full context. It is wrong for anybody to misrepresent a style guide in order to push a personal preference that is not intended by the style guide. ] (]) 14:51, 11 November 2012 (UTC)
:::That is a very good rebuttal of GabeMc's misleading quotations. However, it is still acceptable to change a capital t to a lowercase t when the direct article is capitalized in error, as in "The Beatles." The question is whether or not an tag is required. ] (]) 20:44, 11 November 2012 (UTC)
:::: Oh please, let's not start this again all over now. Capitalized "The"s in sources about the Beatles are not "errors"; they are a conscious and systematic orthographic choice made by a substantial portion of the reliable, carefully edited literature (albeit not the majority usage, and not the usage recommended by most style guides). Come on people, we just had a months-long decision process debating all these things to death. ] ] 21:12, 11 November 2012 (UTC)
::::: Brad does not decide for the entire Misplaced Pages project what ''is'' and what ''isn't'' an orthographical error. ~ ] <sup>(]|])</sup> 21:56, 11 November 2012 (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. ]<sup>(]/])</sup> 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:
:* Fut.Perf., on your above point number 1: "GabeMc has conveniently glossed over the fact that the CMOS is here presenting an exhaustive list of well-defined exceptions", one of those well-defined exceptions is "2. The initial letter may be changed to a capital or to a lowercase letter." Another is "5. Obvious typographic errors may be corrected silently." ~ ] <sup>(]|])</sup> 22:28, 11 November 2012 (UTC)
... {{xt|Joseph Smith bequeathed the manor to his nephew, John Doe, 1st Baron Doe (1801–1881).}}
:* On your above point number 2: "This is exclusively about the use of capitalization to mark beginnings of sentences." What? It pertains to mid-sentence use of quoted material with caps. ~ ] <sup>(]|])</sup> 22:28, 11 November 2012 (UTC)
:* On your above point number 3: You: " ... the non-trivial issue of the use of capitalization to mark proper nouns". 1) Why have you declared an unpronouncable orthographical alteration non-trivial? Under what authority? 2) '''Correction'''. - "the" is an article of speech, not a proper noun as you stated above.
:* On your above point number 4: You seem to be confusing ''wording'' with orthography, two very differnet things. Per "and changes to words printed in all-capitals" It actually says: "Text that is printed in full caps may be rationalised to upper and lowercase (or caps and small caps)". Also, on page 159, 9.3 Styling of Quoted Text, 9.3.2 Interpolation and correction: "In some contexts editorial policy may allow the correction of trivial errors in the original, judging it more important to transmit the content of the quoted matter than to reproduce its exact form."
:* On your above point number 5: I think an unneeded capital intended to glorify the band constitutes an "ornament".
:* On your above point number 6: ]. ~ ] <sup>(]|])</sup> 22:28, 11 November 2012 (UTC)


::You wouldn't place the parenthetical outside the sentence like this, would you?
* From a review of Ian MacDonald's book in (UK): So, did "the largest network of teachers in the world" make an orthographic error when adapting the Copland quote from MacDonald's "house style" to their own? ~ ] <sup>(]|])</sup> 01:51, 12 November 2012 (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.)
== Typographical conformity ==
::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've copy edited this section, putting the bullet on caps at top, cutting excess verbiage, etc. However, there are some more substantial changes we might want from the style guide quoted above:
:::"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. ]<sup>(]/])</sup> 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 ] 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)
: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>
:# 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."
:# 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.)
:# 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.
:# 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>
:#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).
:#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.
:#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).
: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)


== Any objections to extending MOS:TIES to all nations and regions? ==
*"The Times does adjust spelling, punctuation, capitalisation, and abbreviations within a quotation for consistent style."


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.
I don't know what they mean by "spelling". Is this just typos, or do they change UK to US spelling? Would we want to do the same in an article that otherwise uses the opposite tradition?


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?
Where the MOS would advise against using abbreviations, should we expand abbreviations within a quotation?


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)
— ] (]) 01:33, 8 November 2012 (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. --] (]) 06:52, 14 December 2024 (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.
::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)
: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 ==
*As I understand it, changing varieties of spelling in a quote or title is a no-no generally (although I notice my daily newspaper changes the z to s in ''World Health Organization'', which is pretty radical). On the other matters, I personally favour the more interventionist approach. Noetica has thought through the logic of this more than I have, I think. ] ] 02:41, 8 November 2012 (UTC)


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.
::I can imagine that altering the national variety of spelling could lead to all sorts of havoc on WP, with the articles going back and forth.
::So, add a note on expanding abbreviations? — ] (]) 07:15, 8 November 2012 (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, ]?
:::Because of the English Misplaced Pages's identity as a multi-variety publication, I would go with not changing the variety of English within direct quotations.
:::The newspaper should not be changing the z to an s in "World Health Organization" or any other proper noun. ] (]) 03:54, 9 November 2012 (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)
::::Will note that explicitly, just in case. — ] (]) 19:49, 9 November 2012 (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. —] (]) 20:52, 16 December 2024 (UTC)
== Headers that begin with a numeral: capital letter for text? ==


::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.
Should we use an initial text capital in headers such as the following which start with numbers?
::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)
*'''1964: Research continues'''
: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)
*'''1964 – Research continues'''
::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".
*'''11:00 a.m. – First report'''
::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)
:::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)
::::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)
: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 ==
Or should these be lower case?
*'''1964: research continues'''
*'''1964 – research continues'''
*'''11:00 a.m. – first report'''


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:
This is something of an extension of the question about whether to capitalize following a colon. I think that in the case of a header, the initial capitalization should be preferred even if it is not preferred in running prose. ] (]) 16:16, 8 November 2012 (UTC)
:I agree that the initial capitalization should be used. ] <span style="color: #999;">// ] // ] //</span> 17:38, 8 November 2012 (UTC)
:I think it's different if there's a colon or dash; for instance, "research" would be left uncapitalized in:
:*'''1964 research'''
:just like in running prose. And perhaps the recommendation should be to avoid numeral+colon or numeral+dash beginnings for sections. -- ] (]) 19:06, 8 November 2012 (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.
:According to ] (version of ), "he provisions in ] (above) generally apply to section headings as well (for example, headings are in sentence case, not title case)."
* 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.
:{{lookfrom|2012 A}}, {{lookfrom|2012 a}}, {{lookfrom|2012 c}}, {{lookfrom|2012 e}}, {{lookfrom|2012 f}}, {{lookfrom|2012 i}}, {{lookfrom|2012 m}}, {{lookfrom|2012 n}}, {{lookfrom|2012 p}}, {{lookfrom|2012 r}}, {{lookfrom|2012 s}}, {{lookfrom|2012 t}}
:—] (]) 19:49, 8 November 2012 (UTC)


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


* Length: should inline videos be shorter where possible? Does this apply to audio clips?
* The Misplaced Pages MoS currently says: ]
* 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)
* According to ''New Hart's Rules'', "The word following a colon is not capitalised in British English (unless it is a proper name of course)." (p.74)
*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:
* According to the ''CMOS'', "6.61 ''Lowercase of capital letter after a colon.'' When a colon is used within a sentence ... the first word following the colon is lowercased."(16th edition, p.327) Also, 8.1 "Chicago's preference is for the 'down' style ... sparing use of capitals." (16th edition, p.387) ~ ] <sup>(]|])</sup> 22:29, 8 November 2012 (UTC)


* '''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.
* According to the ''New York Times'' style guide, "Ordinarily lowercase the word after a colon." (p.73) ~ ] <sup>(]|])</sup> 02:10, 9 November 2012 (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.
* '''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.
::I think that the MOS suggests avoiding unnecesary caps, and not capitalizing in headings things that would not be capitalized in text, with the exception of the first letter. I don't see a good case for that exception being pushed to after a number. ] (]) 04:21, 9 November 2012 (UTC)
: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 ].
::: <s>I agree, an initial capital should be used following a colon preceded by a numeral.</s> ~ ] <sup>(]|])</sup> 06:15, 9 November 2012 (UTC)
:Not sure the "Sourcing" point needs to be made, as this is explained in detail for images generally.
::::I think you mean you disagree with me then. ] (]) 04:09, 10 November 2012 (UTC)
: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 guess I was confused by your comment, I thought you were saying that Binksternet was correct and I was not. I've heard this both ways depending on who you ask, or who . So, was I correct or incorrect in lowercasing the first letter following a colon in header? ~ ] <sup>(]|])</sup> 23:09, 11 November 2012 (UTC)
: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)
::: Perhaps a bullet point should be added to clarify this, as there is no obvious indication (TMK) in our MoS as it currently stands. ~ ] <sup>(]|])</sup> 23:08, 9 November 2012 (UTC)
:::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 ] ==
:What ] is required or recommended for the first letter in the subheading at ] (version of )?
:—] (]) 17:55, 10 November 2012 (UTC)
::It shouldn't be capitalised, like '''1964 research''' above. Usual running-prose lower case. ] (]) 14:13, 11 November 2012 (UTC)
::: Rothorpe, would you say the same for '''1964: research'''? ~ ] <sup>(]|])</sup> 04:58, 12 November 2012 (UTC)
::Not as a bullet point, no, as it's no longer adjective followed by noun: the colon balances the two parts ('''1964: Research'''), so the second is a sentence fragment, or title in its own right. But I've often noticed people using caps after colons mid-sentence, which normally they shouldn't. ] (]) 14:59, 12 November 2012 (UTC)
::: How about as a section header? Ala: '''1964: research'''. How do you stand on this issue? ~ ] <sup>(]|])</sup> 22:45, 12 November 2012 (UTC)
::Section header is what I meant, indeed. Capital after colon, new sentence. ] (]) 01:15, 13 November 2012 (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)
== ] regarding ticker symbols in article leads ==
: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? ==
Hi. I've started an ] regarding ticker symbols in article leads: ]. Please weigh in! --] (]) 15:13, 9 November 2012 (UTC)


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)
== new point ==


: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)
Added ]. Technical formatting rather than style, so feel free to move elsewhere as appropriate. — ] (]) 19:41, 9 November 2012 (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)


== Formatting of captions == == 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 ==
Regarding ], a stand alone sentence in signage, such as a solitary stand alone sentence as a caption of an image, should not have a period on the end of it. This is a solid design principle that no amount of prescriptive grammar can do anything helpful to refute. Who has authority to clarify this point in above cited MOS section? If no reasonable explanation why I am not right is give, in due course I will do it myself. It is quite simply a shockingly rude design gaff to clutter a beautiful page with a misplaced period. I am sure there is hope that Misplaced Pages will rise above that. Please give this some thought and comment. Thank you! :-) -] (]) 23:52, 11 November 2012 (UTC)


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.
:If you change that long-standing guideline, change ], ], and ] to be consistent with your change to ]. ] (]) 03:33, 12 November 2012 (UTC)


# {{xt|Mumumu Inc. is a company ...}}
:Say what? Complete sentences should not have periods at the end if they are captions? Can you point out any publications that follow such a style? Or guides that recommend such a style? If so, then we can start to look at whether it would be a good move for WP to go that way. ] (]) 03:38, 12 November 2012 (UTC)
# {{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)
:Rogerhc has {{diff|User talk:PartTimeGnome|prev|522561606|asked me to comment here}}. To give some brief context for everyone else, I directed them to this section of the MoS last night with a few edit summaries where I had undone their edits ({{diff|Template:Registered Editor Userbox|prev|522554524|example}}). I am unsure why Rogerhc feels so strongly that a sentence used as a caption should not end in a period. My personal view is that they should. Aesthetically, I see nothing distasteful about a period. I do not see why a sentence in a caption should be punctuated differently from a sentence in the main article body. If I read a complete sentence without any terminating punctuation, I feel something is missing.
*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)
:Searching the archives, it seems that between January 2006 and October 2006, Rogerhc's way was the standard on Misplaced Pages. The current rule was introduced on 4 October 2006 with these diffs: {{diff|Misplaced Pages:Manual of Style|prev|79409662}} {{diff|Misplaced Pages:Manual of Style/Captions|prev|79409473}}. The discussion of this change is at ], which includes a quote from the ''Chicago Manual of Style'' on the subject. – ''']''' <span style="font-size:79%;">(]&#160;&#124; ])</span> 22:27, 12 November 2012 (UTC)
*:Is that the cool way of saying that you don't think it is one? ] (]) 06:46, 26 December 2024 (UTC)
::I've added a link to that discussion to the ], to save anyone else the search. – ''']''' <span style="font-size:79%;">(]&#160;&#124; ])</span> 23:06, 12 November 2012 (UTC)
*There is a length discussion ay ]. --] &#x1F98C; (]) 09:42, 26 December 2024 (UTC)
:I'm not clear on the what the objection here is. It says that, if the caption is a sentence, it should end with a period. If it is not a sentence, it should not end with a period. This makes perfect sense to me. Practically, I think most captions are not sentences, and would therefore not contain the supposedly "ugly" period. <font color="red">—&#91;</font>](])<font color="red">&#93;—</font> 22:40, 12 November 2012 (UTC)
*:@] thank you so much for your link and oh dear it really is long. ] (]) 13:56, 26 December 2024 (UTC)
::It definitely appears that in its short lifetime, the idea of having no period at the end of a one-sentence caption found approximately zero support in discussion. My question remains unanswered: does any publication that we know of use or recommend such a style? Until we get a positive answer, it's not even worth talking about. ] (]) 22:44, 12 November 2012 (UTC)

Latest revision as of 15:52, 26 December 2024

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, 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,098
Write first occurrences in full 609 609
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,922
Apostrophes 2,184 2,184
Quotation marks 394 13,597
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,325 1,325
Brackets and parentheses 3,366 4,571
Brackets and linking 1,205 1,205
Ellipses 2,939 2,939
Commas 4,862 8,058
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 921 16,146
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,886 1,886
Currencies 1,637 1,637
Units of measurement 2,739 2,739
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,213
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,356 2,356
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,808 226,808
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:
    2023
    2022
    2021

    MOS:DATECOMMA and ranges

    Amaury is insistent that DATECOMMA does not apply to a range (expressed in prose): that from October 12, 2012 to September 25, 2015. is right and from October 12, 2012, to September 25, 2015. is wrong. That is nonsensical. The year is still a parenthetical; it is still required to be bounded by a punctuation pair. Notably, MOS itself includes a greentext example showing correct DATECOMMA applied to a range: between October 6, 1997, and May 20, 2002.

    Their argument

    January 1, 2023,–January 1, 2024 would be incorrect, which means January 1, 2024, to January 1, 2024 is also incorrect. It's still a date range, just written out instead of en-dashed. January 1, 2023–January 1, 2024 and January 1, 2023 to January 1, 2024 are equivalent.

    is inconsistent with MOS. MOS:RANGE is clear:

    Do not mix en dashes with between or from.
    from 450 to 500 people, not from 450–500 people

    This means an en dash and "to" are not equivalent or interchangeable in Amaury's argued example. January 1, 2023,–January 1, 2024 is incorrect only because DATECOMMA already obviates the closing comma when the year is followed by other punctuation, i.e., the en dash.

    Is there an exception to DATECOMMA for written-out ranges? Hyphenation Expert (talk) 12:27, 8 November 2024 (UTC)

    Chicago Manual agrees, a second comma after the year in a range. Hyphenation Expert (talk) 13:10, 8 November 2024 (UTC)
    A minor prior discussion. EEng: do what feels best. SMcCandlish: No, there is no exception. Hyphenation Expert (talk) 13:29, 8 November 2024 (UTC)
    Well I guess it makes sense to ping the previous participants then. @C.Fred, @SMcCandlish, @EEng. Hey man im josh (talk) 14:28, 8 November 2024 (UTC)
    The USGPO requires it: The dates of September 11, 1993, to June 12, 1994, were erroneous. Hyphenation Expert (talk) 13:48, 8 November 2024 (UTC)
    • Reading MOS:DATERANGE, I would think it's apparently standard to use an en dash, such as January 1, 2023 – January 1, 2024, possibly to avoid this exact issue. Personally I don't see why DATECOMMA wouldn't apply when an en dash isn't used, but I'm not an expert, so clarity on the MOS pages could be beneficial. Hey man im josh (talk) 13:21, 8 November 2024 (UTC)
      Use of endash for ranges isn't standard, if by "standard" you mean "preferred over to"; either is ok in general, the choice depending on a combination of context or preference. EEng 18:15, 8 November 2024 (UTC)
    • While Amaury's argument is complete nonsense, the idea that 2015 in May 5, 2015 is a "parenthetical" is something even worse: pompous nonsense. If that were so, then people in England would write We set 25 May, 2015, as the deadline, which they don't (and they can be pretty pompous, so that's saying a lot) or in America they'd write He left on May 5, 2015,. (<== with a comma AND a period at the end there) and they don't do that either (despite being crazy in other regards, as recent events demonstrate). The comma's present in May 5, 2015 because setting digits cheek-by-jowl (as in May 5 2015) would be confusing and error-prone.
    I'm generally a prescriptivist, but when it comes to comma usage, there are way too many fussbudgets (including otherwise sensible and respected style guides) still insisting that they be used in all kinds of places that great-grandpa might have used them (Tomorrow, we will leave) but where no sensible person today would use them under normal circumstances. Things change, and one big change over the last 200 to 300 years is a lightening up on commas. I realize I'm in the minority here, but when I read this "parenthetical/appositive" nonsense I cannot remain silent. EEng 18:15, 8 November 2024 (UTC)
    1. Additional pomposity can be achieved by claiming that 2015 is an "appositive".
    MOS:DATECOMMA does in any case refer only to MDY dates, not to DMY dates. Gawaon (talk) 20:54, 8 November 2024 (UTC)
    That's part of my point. If commas are supposed to act as "parentheticals" around the year, then we'd be putting commas around the year in DMY dates as well as in MDY dates. EEng 21:22, 8 November 2024 (UTC)
    I mean, it could just be that the MDY style contingent has decided it's a parenthetical, and the DMY style contingent has decided it's not. Hyphenation Expert (talk) 21:28, 8 November 2024 (UTC)
    Plus, in DMY years, since there are no commas before the year, the question of whether to put some around it cannot even arrive. Gawaon (talk) 08:20, 9 November 2024 (UTC)
    "When technically minded folk with a penchant for order, consistency, and control get caught up in the zeal of a systematization crusade, un­pleas­ant­ness can result." – A Fellow Editor
    Sad to say, under MOS as it stands, the IP's changes are correct. I just think it's stupid to bother. EEng 21:25, 8 November 2024 (UTC)
    And see WP:If MOS doesn't need a rule on something, then it needs to not have a rule on that thing#For want of a comma, the clause was lost aka Why every goddam thing needn't be micromanaged in a rule. EEng 19:10, 10 November 2024 (UTC)
    I don't buy into the "OhButIfWeDon'tThereWillBeEndlessArgumentOnEachArticle" reasoning
    See, we're well past the "there might be argument" stage. The re-pet-i-tive, pro-tract-ed arguing began long ago.
    Also, as I said at the outset, MOS already includes greentext confirmation of a range datecomma: between October 6, 1997, and May 20, 2002. There is no "new rule"; however, as Hey man im josh says, additional clarity on the MOS pages could be beneficial.
    Ping priors Geraldo Perez MPFitz1968 YoungForever Mz7 HandsomeFella, IJBall is no longer around. Hyphenation Expert (talk) 00:33, 11 November 2024 (UTC)
    +JohnFromPinckney Hyphenation Expert (talk) 00:47, 11 November 2024 (UTC)
    • MLA style: The exhibit ran from June 2, 1995, to April 4, 1996, in New York.
    AP style: between Feb. 1, 2021, and Feb. 22, 2023, the...
    When asked if from November 3, 2021 to November 30, 2022. needs a comma, CMOS adds APA, AMA, Microsoft, and Apple guides would all also tell you to use that second comma; the year is parenthetical ... this usage is relatively straightforward. Hyphenation Expert (talk) 01:45, 10 November 2024 (UTC)
    Amaury (if their view has been correctly described by the OP) is just flat-out wrong. Bracketing commas always come in pairs (in WP writing, even if some journalistic style guides like to drop the second ones); unless: A) the second one has been replaced by some other punctuation in the sentence such as a semicolon, or a terminal period/full stop or question mark; or B) the second one would come at the end of a sentence fragment that doesn't take terminal punctuation, such as a table header or image caption, in which case no punctuation is used there at all, obviously.
    Yes: from October 12, 2012, to September 25, 2015.
    Yes: moved from Los Gatos, California, to Reno, Nevada, in 2021
    No: from October 12, 2012 to September 25, 2015.
    No: moved from Los Gatos, California to Reno, Nevada in 2021
    Point A above is important. January 1, 2023,–January 1, 2024 should be January 1, 2023 – January 1, 2024 specifically because the second comma bracketing "2023" has been replaced by alternative punctuation (en dash, and a spaced one in this case because the elements on either side of it are complex not single-string; see MOS:DASH). But this has no implications of any kind with regard to the spelled out version January 1, 2024, to January 1, 2024. That is, the argument "

    January 1, 2023,–January 1, 2024 would be incorrect, which means January 1, 2024, to January 1, 2024 is also incorrect

    " is nonsensical, a confusion of two different but superficially somewhat similar things to which different rules apply. It's like writing "I is hungry is ungrammatical, thus She is hungry must also be ungrammatical."

    Anyway, there is nothing even faintly new about this discussion. This is pure rehash of long-settled questions and has introduced no new argument, evidence, or other material to consider.  — SMcCandlish ¢ 😼  00:41, 12 November 2024 (UTC)

    Bracketing commas always come in pairs  – Sure, if they're "bracketing"; you're just taking for granted that they are. I say that the commas in September 5, 2017 and Los Angeles, California aren't part of any "bracketing", but rather are just separators -- lonely, workaday, unpaired, non-bracketing separators. EEng 07:35, 12 November 2024 (UTC)
    That's not the view of the MOS, though. Gawaon (talk) 09:56, 12 November 2024 (UTC)
    MOS doesn't take a position on the theoretical bases of the stylistic practices it recommends; it just recommends. EEng 22:34, 12 November 2024 (UTC)
    They're defined as bracketing commas by our MoS (and by basic linguistic logic). There really isn't anything else under discussion here (and should not be). Style discussions on WP keep getting lost way out in the weeds with people's tempers flaring because they try to bring in external "rules", and personal subjective preferences, and what they were taught in middle school (by a prescriptivist non-linguist) two generations ago, and how people at their job prefer to write, and what some third-party style guide they like better says instead, and etc. It's all just distracting and confusing noise. Cf. WP:NOT#FORUM. This page doesn't exist for debating how you wished academic writing worked, or why some MoS line item would be subjectively better your preferred way. If you can't make a strongly defensible case for an objective improvement to consistency and comprehensibility for readers, then MoS definitely should not be changed to suit your whims. Its value is in its stability, its concision compared to other style guides, its consistency (especially strong avoidance of making exceptions that are not effectively required by all of mainstream writing practice), and its focus on reader understanding of the material above any traditionalist, prescriptivist, nationalistic, or "expedientist" sentiments.

    Our punctuation system works perfectly fine on this particular comma-usage question, and is engineered for clarity. It serves that purpose well; the comma-avoidant alternative would not, and rather would make for many confusing constructions, for no gain of any objective kind. WP's style also agrees with the majority of practice in academic style guides and publications using them. So, to propose a change to this would require a really overwhelming case for doing so, based on real evidence of the superiority (somehow) of the alternative and proof that most of the style guides that are influential on MoS (not journalism and governmentese and fiction-writing ones) had changed on this question. Once in a while that happens (e.g., dropping of both the commas around "Jr." and "Sr."; increased acceptance of singular-they; avoidance of he/him/his as generic; etc.). WP eventually adopts such provable changes in English usage patterns, after they have become well-established in contemporary academic writing and the style guides for it. That's not happening with regard to this matter and is not likely to happen.

    In more detail: They serve a parenthesizing function, by which what is between the commas is a post hoc clarifying modifier of what precedes it, and can often be omitted in a clearer context. That makes it parethetical by definition. In "We are hiring Anne, Bob, and Carol", these commas are not bracketing (parethesizing); no element of this can be removed without a loss of significant information or a grammatical problem (regardless of context). In "Her son, Daniel, is coming over for dinner tonight" and "They left Portland, Oregon, in 2004", all of these commas bracket parenthetical constructions which are necessary only in specific contexts. If you already know the son's name, you don't need to be told it; if you are in Oregon, you probably won't need the state specified (unless Maine was just now under discussion).

    In a particular context, something of this form might have all its parts become non-removable in a specific sentence (e.g., if I tell you "I'm going on vacation starting November 20", you probably do not need the year included; but the year is usually needed for more distant times, e.g. in "Mark Twain died on April 21, 1910, in Redding, Connecticut" you do need the year, except perhaps in a paragraph all about the events of 1910). But the underlying grammatical form is still parenthetical. We would not write an incidentally, contextually non-optional case in an inconsistent format. That would be very confusing for readers and editors alike. We know it would be confusing because a rather similar (and not particularly useful) distinction has unfortunately solidified in Modern English, with "Her son Daniel is coming over" conveying a different meaning (there is more than one son) from "Her son, Daniel, is coming over" (there is only one son). Various readers and even experienced editors often have trouble with this and get it wrong, but we need to get it right because this is universal across English dialects and registers ("Her son, Daniel is coming over", with only one comma, is erroneous in all of them, regardless which meaning was intended). By contrast, there is no dialect or register in which "The company was founded in Houston, Texas on January 3, 2015 by Chris O'Blivion" is required; it's simply a "save every character-space possible" preference of certain publishers' house styles. WP is not among them because it is harder to parse correctly without re-reading after all the comma-killing. I.e., we have an objective reason of reader comprehensibility to not write that lazy way. There are lots and lots of sloppy things done in journalese, bureaucatese, and marketingese that WP doesn't do, for good reasons.  — SMcCandlish ¢ 😼  03:16, 13 November 2024 (UTC)

    I'm certainly not going to read all that (and I imagine few will), but please help me ... Is there anywhere in there where you explain why the same reasoning doesn't apply to DMY dates i.e. if the year is a "post hoc clarifying modifier", why do DMY folks write 5 May 2015 was clear instead of 5 May, 2015, was clear? EEng 04:48, 13 November 2024 (UTC)
    In all seriousness, Sandy, I'd really be interested to hear your answer on this. But please, keep it under 10,000 words. EEng 18:07, 14 November 2024 (UTC)
    Says the one with the longest user-talk page across all WMF projects, LOL.  — SMcCandlish ¢ 😼  21:35, 14 November 2024 (UTC)
    But then, my talk page isn't all one post. EEng 22:45, 14 November 2024 (UTC)
    It's purely convention. Human language isn't a programming language and is not entirely logical or consistent. The "5 May 2015" format simply doesn't use commas at all (not in much of any professional writing, anyway). It's not WP's role to invent styles that are virtually non-existent in external reality, though where competing styles do exist in our register of writing ("May 5, 2015, was clear" vs. "May 5, 2015 was clear"; or "5 May 2015 was clear" vs. "5th May 2015 was clear" vs. "the 5th of May 2015 was clear"), we do have an interest in normalizing to the version that makes the most sense for our technical and reader needs (thus much of MoS, especially MOS:NUM). Various clearly parenthetical constructions also only optionally take commas (but in pairs), and the shorter they are the less likely we are to use those commas in modern writing ("They moved, in 2015, to Bremen" vs. "They moved in 2015 to Bremen"). Parentheticals are often also punctuated with round brackets (thus their other name, parentheses) or with dashes, simply as alternative conventions with a bit of difference in emphasis level. But all of these also come in pairs when used as parenthesizing punctuation.

    What's being sought here is an inconsistent variance from this pairing pattern if and only if the marks used happen to be commas instead of something else, and only when the content in question is a date or a place. That's a complicated and unnecessary rule that MoS not only doesn't need but affirmatively should not have. There is no reason to do it, because writing "May 5, 2015 was clear" isn't a style required or conventionalized in any dialect or register of English (simply a very optional hyper-expediency approach), it has significant costs to reader comprehensibility, and it's directly inconsistent with all other use of bracketing commas (no one with any sense would write "They moved, in 2015 to Bremen" – it takes either no commas or two).  — SMcCandlish ¢ 😼  21:35, 14 November 2024 (UTC)

    It's purely convention – Thank you. So if you want to argue that good usage has or has not adopted New Convention B in addition to (or in replacement of) Old Convention A, that's fine. But all this stuff about bracketing and appositives is just smoke and mirrors.And as for MOSBLOAT, in point of fact loosening up on this issue would be achieved by simply dropping everything in the Comments column in the date formats table:
    Acceptable date formats
    General use Only in limited situations
    where brevity is helpful
    Comments
    2 September 2001 2 Sep 2001 A comma doesn't follow the year unless otherwise required by context:
    • The 5 May 1922 meeting was cancelled.
    • Except Jones, who left London on 5 March 1847, every delegate attended the signing.
    September 2, 2001 Sep 2, 2001 A comma follows the year unless other punctuation obviates it:
    • The weather on March 12, 2005, was clear and warm.
    • Everyone remembers July 20, 1969 – when humans first landed on the Moon.
    So that would be a definite deflation, not bloat. EEng 22:45, 14 November 2024 (UTC)
    It would also loose useful information, though. Many people know the conventions mentioned in the comments already, but not everybody does. Gawaon (talk) 08:39, 15 November 2024 (UTC)
    If you mean "lose" information, that's not a problem. Unlike articles, our behind-the-scenes guidelines don't aspire to teach readers / editors general knowledge. EEng 15:28, 16 November 2024 (UTC)
    Not general, just what's needed to successfully edit Misplaced Pages. Which apparently includes these rules for comma placement, otherwise this discussion wouldn't have started. Gawaon (talk) 15:53, 16 November 2024 (UTC)
    That EEng, by his own admission, has refused to read the argument presented, explains why he did not understand it. His lack of understanding doesn't mystically make the argument wrong. And the fact that a practice exists in English by convention does not somehow make it devoid of logic or reason, much less of practical effect. Most of the workings of our language, spoken and written, have logic and practicality to them (some eroded a bit by language change), yet all of our language also exists as it does by convention. EEng has somehow confused "It is this way by convention" for "It has no reason, thus can be undone or replaced with impunity". They are not equivalent. EEng asked why the "12 March 2005" format lacks commas, and the answer is that it is not conventional to include them in that format. (There are many, especially numeric, formats of things that are typographically done particular ways, not always consistent with other approaches to conveying essentially the same information. Most of them even have alternatives that some individuals like better, yet MOS:NUM has in virtually every case settled on the single conventionalized one that is most clear.) This "no commas" fact of DMY format has no implications of any kind for commas in any other format, nor (to get to the heart of the present matter) for why, when one comma is placed before the year in "March 12, 2005" MDY format, a second one follows (unless replaced by an alternative, like a sentence-ending "."). These are all entirely severable questions, so it is not cogent to seize upon one's inference in regard to the answer to one of these questions as dispositive in any way with regard to the handling of any other.

    Unlike articles, our behind-the-scenes guidelines don't aspire to teach readers / editors general knowledge: That's correct; they exist to ensure that our editors produce material of maximum intelligibility and other usability for readers (and secondarily to stop editors fighting with each other over trivia). The proposal to write "On March 12, 2005 Elbonian troops invaded Narnia" is inimical to that goal, by introducing confusingly ambiguous syntax (the more complex the sentence the harder it becomes to figure out WTF the sentence structure even is when half the bracketing commas go missing, but even this simplistic example is hopelessly broken). Another way of putting this is that context always requires that second comma (or obviating alternative) because the inclusion of the first comma has the result that for some subset of readers every such construction lacking the second will be syntactically and often enough semantically confusing (generally because commas serve multiple purposes in English).

    Finally, there is a tension between making MoS concise and making it both understandable and serving its dual purposes of improving WP readability and reducing editorial conflict. We know from long history that our editors for years got into confused, confusing, and angry pissing matches about date formatting, with resultant chaos in mainspace. (Those date-format disputes are in fact why MoS is a WP:CTOP in the first place.) So, removing the column of clarity about when to use commas with dates is the last thing we should do, since it would be guaranteed to cause a recurrence of conflict and confusion about what to do with dates. MoS resurrecting anew any long-settled "style war" is the opposite of its goal.  — SMcCandlish ¢ 😼  11:46, 21 November 2024 (UTC)

    Look, I'm writing a book right now, so I just don't have time to read other people's book-length posts. It's not that big a deal, my friend. We can pick this up another day, say, 20 months from now. EEng 16:35, 27 November 2024 (UTC)

    Notes

    1. For use in tables, infoboxes, references, etc. Only certain citation styles use abbreviated date formats. By default, Misplaced Pages does not abbreviate dates. Use a consistent citation style within any one article.

    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)

    MOS:NOTLATIN and the Americanist phonetic notation

    Hello, per the discussion at Template:Did you know nominations/Muthkwey, I thought it may be best to start a discussion here. We have come to a bit of a stand-still regarding the status of Americanist phonetic notation (NAPA). Per the discussion, several languages in the Pacific Northwest Coast use Americanist Phonetic Notation and as it stands, it is recognized as a non-Latin script in the system. The challenge is that there exists no recognized romanization system for NAPA, per NOTLATIN’s requirement for romanization of non-Latin scripts, nor is there an incentive to do so.

    In typical usage beyond Misplaced Pages, words in Northwest Coast languages rendered in NAPA are typically left as-is, with no romanization, or with a transliteration if there so exists a historical example. However, those transliterations are few and far between, and are often inconsistent as they differ author to author. It would not be a sustainable system, because those words only constitute a small portion of the lexicon.

    My question is whether NAPA should/would be recognized as a Latin script for the purposes of WP:NOTLATIN. NAPA derives heavily from Latin script, with the exception of a few Greek letters. Those letters represent various sounds, and each one serves a specific purpose. If it is not recognized as a Latin script, what would be the best course of action to allow various words to conform with WP:NOTLATIN, since there is no existing romanization system, and any generated romanization therefore would mostly be in violation of WP:OR. Any insight on this would be greatly appreciated. Ornithoptera (talk) 19:53, 25 November 2024 (UTC)

    Sounds Latin enough to me. Gawaon (talk) 11:52, 26 November 2024 (UTC)
    Agree. The concept of a "romanisation" of NAPA doesn't make sense to me. In fact, NAPA in some ways strikingly resembles romanisation schemes for Cyrillic, and Cyrillic variants that have been used to transcribe or write down previously unwritten languages, so much that in the past I've wondered if UPA and NAPA originally arose as romanisations of Cyrillic-based transcriptions. --Florian Blaschke (talk) 01:26, 10 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)

    Placement of composition/description/synopsis/plot sections

    It has been loosely implied that I am an incorrigible, MOS recidivist who should either be placed in wiki-jail or released on my own recognizance and given an MOS ankle monitor and watched closely for compliance. This is because I have consistently used older styles of article writing where descriptions of the subject (art, film, literature, etc.) are not placed in section 1, but elsewhere, sometimes even in section 2 or section 3. There are many reasons as to why I did (or continue to do) this, mostly having to do with different types of narrative structures unique to each topic.

    Clearly, the film project has taken a strong stance against this, and I believe the vast majority of film articles are required to have the plot section in the section 1 position. However, I do remember that in the deep past, documentary films were often exempt from this, and would often find the synopsis sections in other positions. This was also true for older non-fiction articles until recently, for example The World Without Us, where the synopsis appears below the background section in section 2, not 1. The same can be said for many different FA art articles, where the composition or description section appears in places other than section 1. Examples are many, including Portrait of Maria Portinari and Portrait of Mariana of Austria. Portrait of Monsieur Bertin is more interesting, where the description section is much, much farther down.

    In my mind, this was an acceptable interpretation of "one style or format is acceptable under the MoS" until recently, however, I believe this has fallen out of favor since about 2018 or so (as far as I can tell), and things have become much more rigid, and unlike Old Misplaced Pages culture, you can't do things differently anymore. My reading of this is that description sections in any form are now unofficially required to be in the section 1 position. In other words, if I write a new article right now and place the description of the topic anywhere but section 1, should I be reverted according to MOS practices (across all WikiProjects), or is there room for flexible interpretations across the project in different disciplines?

    As an example, in articles about paintings, I am partial to headings that reflect a Lead (0), Background (1), Development (2), and Description (3) structure, in that order. This has recently caused minor friction in other parts of the project with editors who dislike or disagree with me placing the description so far down. I would appreciate some additional insight into whether my practice is acceptable under the MOS. Thank you. Viriditas (talk) 20:30, 27 November 2024 (UTC)

    MOS:FILM suggests Plot follows immediately after the lead, but "the structure and ordering may vary between film articles". Not sure about paintings. Nikkimaria (talk) 05:46, 28 November 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)

    Categories: