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 editNext edit →Content deleted Content addedVisualWikitext
Revision as of 12:52, 4 August 2011 editKotniski (talk | contribs)Autopatrolled, Pending changes reviewers, Rollbackers40,317 edits →Spaces in "XXX – United States relations": proposal at Talk:Afghanistan – United States relations← Previous edit Revision as of 12:27, 25 December 2024 edit undoLowercase sigmabot III (talk | contribs)Bots, Template editors2,292,502 editsm Archiving 1 discussion(s) to Misplaced Pages talk:Manual of Style/Archive 228) (botNext edit →
Line 1: Line 1:
{{Talk header |WT:MOS |search=no }}
{{Skip to talk}}
{{FAQ|quickedit=no|collapsed=no}}
{{Talkheader|WT:MOS}}
{{Round in circles|canvassing=yes}} {{Round in circles|search=yes}}
{{User:HBC Archive Indexerbot/OptIn
{{FAQ}}
|target=Misplaced Pages talk:Manual of Style/Archive index
{{MOS/R}}
|mask=Misplaced Pages talk:Manual of Style/Archive <#>
{{WPMOS}}
|leading_zeros=0
{{tmbox
|indexhere=yes
|type=notice
}}
|text={{hidden
{{Section sizes}}
|header=Suggested abbreviations for referring to style guides
{{WikiProject banner shell |class=A |1=
|content={{User:Noetica/StyleGuideAbbreviations1}}
{{WikiProject Manual of Style}}
}}
{{Misplaced Pages Help Project|importance=Top}}
}} }}
{{User:MiszaBot/config {{User:MiszaBot/config
|algo = old(30d)
|archiveheader = {{aan}}
|archive = Misplaced Pages talk:Manual of Style/Archive %(counter)d
|maxarchivesize = 500K
|counter = 124 |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
}} }}
]
{{Misplaced Pages talk:Manual of Style/Archive Box}}
__TOC__
{{auto archiving notice|bot=MiszaBot|age=7|small=yes|dounreplied=yes}}
{{clear right}}
{{stb}}


==Style discussions elsewhere==
== Logical punctuation ==
<!-- 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===
I just learned today about the Misplaced Pages style convention for ], per ] and ]. Could someone please explain the logic behind this rule?
(newest on top)
<!--
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 />
Why is the American-based Misplaced Pages using British punctuation rules? Not only does America have a significantly larger population size (which leads one to logically infer that it also has many more writing professionals), but the American style for commas and quotation marks is also endorsed by the Modern Language Association, the Associated Press, and I believe several other notable organizations (but I don't want to assume and be incorrect).
'''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 />
Correct me if I'm wrong, but the way I see it, we've adopted an uncommon rule -- I had no idea that this comma philosophy even existed -- when I think it's safe to say that a large portion of our writers and editors are Americans who are going to follow the American style, and we're going to have rampant inconsistency as a result.
'''Capitalization-specific:'''
{{Excerpt| Misplaced Pages talk:Manual of Style/Capital letters|Current|subsections=no}}
}}


===Concluded===
Perhaps my thoughts make me a close-minded American, but I just don't really see the logic behind it.--] (]) 16:17, 30 June 2011 (UTC)
{{collapse top|left=y|title=Extended content}}
<!--Please put newer additions at the top, by order of closure. -->
* ] – Use en dash not hyphen in four paired names? ''Result:'' Yes.
* ] – 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.
** 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.
* ] – 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.
* ] – ]: "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.
* ] – 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.
* ] – 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 ].
* ] – 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.
* ] – ] (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 ].
* ] – 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.
* ] (moved from WP:VPPOL) – Yet another round of this long-term, multi-RfC process. Consensus about "deadnames" seemed possible this time but was mostly elusive. (Dec. 2023 – Jan. 2024) ''Result:'' no consensus to change the wording of MOS:GENDERID based on this proposal; consensus against changing "should be included" to "may be included".
** Related: See numerous previous deadname-related and more general GENDERID discussions listed below.
* ] – Proposal to merge a "guideline in all but name" into MoS. (Jan. 2024) ''Result:'' consensus to promote to a guideline (after some significant revisions).
* ] – 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}}


== Should interactive content be included and, if so, where and how? ==
:As I said in response to your question on my talk page, logical punctuation has been part of the MOS since it was first put together in 2002. There are other things in the MOS that follow American convention over the British, such as the strong preference for the double quotation mark rather than the single.<br>
:In terms of grammar and spelling, by widespread consensus, any of the major national variants of English are acceptable in articles. This has also been in the MOS since the beginning. There are obvious caveats to this (the spelling needs to be consistent within the article, common ground should be sought where possible, words that would be confusing in other dialects should be avoided, etc.) and it's worked fairly well for the last nine years.] ]/] 16:38, 30 June 2011 (UTC)


{{body roundness index}}
::Sure, I'm not trying to question you at all, and I appreciate your help; I agree that it's best to follow the stylebook as long as that convention is a part of the stylebook, but I think it's also important to note that organizations bound by a stylebook (like the Associated Press) publish new versions. The AP publishes a new stylebook every year to make improvements and changes. I don't think tradition alone is a good reason to follow a rule.
{{Today/AD/SH/AH}}
I think this is a new topic, forgive me if not.


At ], ] wants to include an interactive calculator that they have developed, replicated here for your convenience. The concept is fairly simple: readers may enter their own height and waist-circumference and receive a calculation of their Waist-to-height ratio (and a related metric recently popular in the US, ]). It is not earth-shattering stuff, the math is straightford and the underlying algorithms are fully supported by ].
::I did review those articles, and I guess I sort of understand the desire to avoid changing an author's content, but can someone give me an example where it would be necessary or even beneficial to know that the author placed a comma or a period at the end of the quote? Do those ever add meaning? I can see it in poetic verse, maybe, but otherwise I can't think of a situation where that's important.


We already have dynamic content, such as the display of the Islamic and Hebrew calendar dates v today's Gregorian calendar date. I don't see any issue with that practice.
::I think it requires a decision between whether it's more important to know where the author placed his punctuation -- I honestly don't think that's important -- or for Misplaced Pages to be consistent. I think it's going to be a battle to be consistent if we stick with logical punctuation.--] (]) 16:43, 30 June 2011 (UTC)


So here are the questions:
:::Don't try comparing the population of the US to the UK. Many countries in the Commonwealth have English as an official language and many of those use "British" usage rules. For example, India has a lot more people than the US and English is an official language there. Just thoughts. --] (]) 18:04, 30 June 2011 (UTC)
# Should Misplaced Pages include interactive content?
::::Precisely. We already have agreement on this, at ]. ] <small>]</small> 18:11, 30 June 2011 (UTC)
# If so, how should it be presented?
::::I'm asking for details because I'm not very familiar with this convention, as I've pointed out. As a career writer and editor, I believe that it's best to question the logic behind the conventions that we use, and we should use those conventions that best preserve clarity and consistency. I used to manage a publication, and when a consensus of editors came to the conclusion that a convention needed to be changed, it was, effective immediately.
## Inline, without comment, so it appears to be just a static, illustrative example. As shown in in the section #Guidelines. It is, however, still interactive.
## In an independent section, as shown in , in the section #Calculator, with a line of text that explains what it is. ({{tq|This interactive calculator can calculate a waist{{ndash}}height ratio and ]. It accepts height and waist in ] or ]es.}}
##Something else?
# Is it a ] violation? .
# Are there other issues that arise? (For ex, is ] a show-stopper?)


::::I have pointed out my bias, and that is why I'm seeking outside input in this forum for discussion.--] (]) 18:47, 30 June 2011 (UTC) Personally I think it is a good idea (]) but I'm not sure how best to handle it. Comments? ] (]) 20:59, 2 November 2024 (UTC)
:See also ]. --] &#x1f339; (]) 23:23, 2 November 2024 (UTC)
:On the subject of accessibility - if the labels for interactive fields are created using the {{tl|calculator label}} template, it should mark in the HTML that that piece of text corresponds to that specific input button, which is something that screen readers should hopefully be able to take into account. I would recommend using {{tl|calculator label}} where possible when labeling fields, for better accessibility (It may not be possible if a label labels more than one widget). For the most part, I think it should be reasonably accessible most of the time, but i would love to hear feedback from accessibility experts, as I am definitely not one.
:One thing I would recommend is to test how any interactive content looks when printed. In some cases it looks fine as is, but in other cases it might be necessary to make specific fallback content. The template supports having fallback content for cases where js is disabled or during printing. ] (]) 17:22, 11 November 2024 (UTC)
=== Reply by Uwappa ===
Demo:
# Update the ] in ].
# The formula example values will 'magically update'.
# See the wikitext for what that takes to do. Look mum, no javascript!


No, it was not me who wanted a calculator, do not deserve any credits here, ] does, see ].
:Because this page was written by a small coterie of those who want to use it as a tool to make Everybody Do It MY Way.
# Yes, Misplaced Pages should have interactive content. It is 2024. The web has moved on from being previous century 'static' text and images. WP is more than an online version of a paper encyclopedia with text and images. I fail to see why the calendar example is relevant here. Please don't be amazed that it is possible to show dynamic content in 2024, like the current time, {{time}}.
# &nbsp;
## Calculations should be presented inline, just like current examples at: ], ], ], ].
## No, it does not accept just cm or inches. The Sandbox version does not ask you to input cm or inches, ]. It uniquely accepts any unit, unlike commercial BRI calculators. ]. You can use ] and while at it, please record the time it took you to do the usability test and compare it with commercial calculators. It does support Americans, British and others using ] by providing cm-> feet & inches conversions.
# No it is not a NOR violation as defined by ]. The only thing ] can do: calculations with numbers only. It yields just numbers, which include a simple ], with a value of 0 or 1: to hide or to show, that is the question. See ]. This show or hide is taken care of by standard CSS. Switch off CSS in your browser and see what goes on under the hood. A joke for the happy few that do understand ] and have a sense of humor: ] was wrong. ] is not a question in 2024, it evaluates to a constant, boolean value: true. Same logic at: ] That is not a question either. It is true.
# Security may be a concern to some. Is there some dangerous Javascript here? The answer was amazing for me: no. Look mum, no javascript in the wikicode. Current WP rules and guidelines suffice and apply, see ].
:] (]) 00:52, 3 November 2024 (UTC)


It is hard to tell from a distance what the reason for this post is.
:Logical punctuation has a minor advantage for some readers who do not realize that {{xt|,"}} and {{xt|."}} are compound signs in American punctuation - and who care about ''de minimis'' details; it has a significant disadvantage in that it is harder to do accurately, and impossible to proof-read.
To me this post is a waist of valuable time and should be withdrawn.


The current MOS applies well to:
:It would be a great improvement to the encyclopedia to acknowledge that there are two systems, that they both have advantages, and that articles may use either consistently.
* A fixed date, just text like 1 dec 2032
* A dynamic date, like now is {{CURRENTDATE}} using ]
:Pending agreement on this, we should at least mark that the present text is (as it has been every three months or so since its imposition) disputed. ] <small>]</small> 18:11, 30 June 2011 (UTC)
* A combination of the two, like it is now {{age in months||2032-12-01}} months till 1 dec 2032
* {{anchor|dateCalc}} A dynamic interactive version, using calculator with input fields asking for a month {{calculator|id=month|default=11|type=number|size=3|min=1|max=12}}, year {{calculator|id=year|default=2024|type=number|size=5|min=2024|max=2032}} and the result of a calculation: It is {{calculator|id=monthsTill1dec2032|default=97|type=plain|formula=12*2032+12-12*year-month}} till 1 dec 2032.


What is the problem here?
::I don't think we should look at it as a desire to impose control over other writers and editors. I suppose this "control" is a side effect of a stylebook, but that's not the end goal. The goal is to maintain consistency, which is the only way to achieve a professional product. And although inter-article consistency is definitely a must, best practice is really to maintain the same rules throughout the publication (i.e. all of Misplaced Pages). Whatever is decided, it really would be best to use it all the way throughout.
* It may be a case of ]. A bit of good old British humor might help.
* It may be ]. Help, this ] is too complex for me, I am just an editor of fixed text. I won't be able to do this kind of stuff! ] Same solution:
* It may be limited Math skills, leading to a false WP:OR claim. See ] and ]. Credits to user JMF for seeing the logic in


<math display="block">\text{BRI}=364.2-365.5\sqrt{1-\Big(\frac{\text{waist}}{\;\;\pi\;\;\times\;\,\text{height}}\Big)^2}</math>
::I think we're trying not to step on toes here, but there is such a thing as too much political correctness. When it interferes with the project's perceived professionalism, and hence its credibility (which is at stake), I think we need to get tough and get over our sensitivities.--] (]) 19:15, 30 June 2011 (UTC)
:::Oh, power shouldn't be the goal; but for a small and turbulent minority, it is.


with
:::Nor does MOS achieve professionalism by universal consistency: it doesn't do that now. See ]: we seek consistency within articles, as other publishers do within individual contributions to an anthology; but for some of the most notable differences in English (''favor''/''favour''; ''red, white and blue''/''red, white, and blue'') our guidance is for inconsistency.
<math display="block">\text{WHtR}=\frac{\text{waist}}{\text{height}}</math>


to get
:::Our road to professionalism is accuracy, verifiability, neutrality, clarity; achieving uniformity on quotation marks does little for these, and is at best false advertising without them. ] <small>]</small> 19:26, 30 June 2011 (UTC)
<math display="block">\text{BRI}=364.2-365.5\sqrt{1-\Big(\frac{\text{WHtR}}{\;\;\pi\;\;\,}\Big)^2}</math>
* It may be just a lack of knowledge, not knowing about ]. That is an easy one to solve, just go and read it
* It may be a problem with limited ]s or use of a small screen smartphone in stead of a large computer monitor. User JMF has replied with TMI to my posts several times. The easy solution would be to switch to a big monitor for more complex talk pages. For limited cognitive skills, I can only recommend to visit a medical expert, will not give medical advice ].
* Disclosure: My field of expertise is a form of psychology that seems unknown in the English speaking world: function psychology. The 'patient' in that science is not the human, it is the design object that causes man-thing interaction problems like: Help, I do not understand my computer and my computer does not understand me. The 'cure' is a redesign of the 'thing' e.g. the ]. Create a human efficient design that suits the qualities and limitations of the human eye, interpretation skills, memory, ability to think and take action (mostly with hands in computer interfaces). WP does not have an article yet on ] or ]. Being too involved in this field, it is not up to me to write such articles, ], ], ].


What I can do is to help WP and design excellent, human efficient interfaces.
::Um... does anyone else see the inconsistency of talking about achieving a "professional" product when everyone involved in creating it is a volunteer? As long as "anyone can edit" (which is a core concept behind Misplaced Pages) it is unrealistic to kid ourselves about achieving a professional product. Our goal is (and should be) to achieve the best ''amateur'' product that we can. ] (]) 23:00, 30 June 2011 (UTC)
All of you can help by evaluating results.
* Is the sandbox version human efficient? And please do not give a sh** about computer efficiency. No worries if computers do 'redundant' calculations to make humans more efficient.
* Is the sandbox calculator better or worse than commercial equivalents?
* I do not give a s*** about personal preferences and your 'solutions' based on personal preferences. Go and tell someone who cares. Just list the problems you encountered during the tests. The most valuable ones are when test subjects fail to reach the desired result.


Such usability tests are easy to do and can be fun. Kudos to user JMF who has done a usability test that were very insightful for me in the metric world and have lead to an excellent unit less solution for people using either metric or imperial units.
:::There's a very significant difference between "professional" and "professional standard". ] ] 23:11, 30 June 2011 (UTC)
::::Still, I don't think an article with major ]/]/] problems but a professional-looking style would be better than the same article with a crappy style. If anything, the latter is less likely to deceive readers. (This is why I don't usually copy-edit articles unless I have at least a vague idea of what they're talking about and know that what they say is at least vaguely plausible.) <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 23:51, 30 June 2011 (UTC)
:::::And both styles here are professional - they're used by professional proofreaders. ] <small>]</small> 23:59, 30 June 2011 (UTC)
::::::I was commenting on what Blueboar and Malleus Fatuorum said on a general level, not on this issue in particular. (FWIW, I prefer “logical” quotation myself, but I think both should be allowed, and if the article I'm editing uses traditional American quotation consistently, I leave that alone.) <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 00:10, 1 July 2011 (UTC)
::::::::Thank you.
::::::::But does it also hold as a general point? We are rarely dealing with a controversy between professional style and crappy style; we are dealing with points on which there are several professional styles, and some self-appointed maven wants everybody to use ''only'' his choice. (Sometimes his choice appears to be something he's made up, but that's another question; even then it's often a rational but unattested invention.) ] <small>]</small> 00:31, 1 July 2011 (UTC)
::::::I agree with you that both styles are equally professional. The majority of writing professionals, however, look for and expect pervasive consistency in any product. I don't think we should relegate the principle of consistency when it comes from the writing industry.--] (]) 03:59, 1 July 2011 (UTC)
:::::::We'vw already done so; on spelling, which is far more visible, we've actively rejected consistency; see ]. On other points where there are two reasonable and wisely used alternatives, we've abandoned it. We're a collaboration. ] <small>]</small> 23:43, 1 July 2011 (UTC)


Please join the fun, perform a usability test yourself at:
I'm an American, and I prefer logical punctuation... This isn't so much of a regional variation as it is a profession one, in my opinion. People in the sciences and engineering tend to use logical punctuation, whereas those in the humanities and the arts seem to prefer more traditional punctuation. Misplaced Pages has a fairly strong foundation in the tech world, so it really shouldn't be that surprising that we seem to prefer logical punctuation.<br/>—&nbsp;] <span style="font-variant:small-caps">(]&thinsp;&bull;&thinsp;])</span> 23:09, 30 June 2011 (UTC)
] <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding ] comment added by ] (] • ]) 07:24, 3 November 2024 (UTC)</small>
:Then use it, and let others do otherwise. ] <small>]</small> 23:59, 30 June 2011 (UTC)
::The American style guides were largely constrained by the ], and couldn't change away from the illogical style. Misplaced Pages had a "clean" start, and could get away with adopting its own practices, obviously within reason. It would have been silly to decide that three quote marks was the right way to do quotations. However, given that it is the English Misplaced Pages, rather than the American Misplaced Pages, when confronted with a choice between one rule that made sense, and another rule that made absolutely no sense, and had nothing going for it other that "that's the way we've always done it", deliberately chose to go with the logical rule.
::Works for me. If you are a professional writer not at Misplaced Pages, and want to continue using the illogical rule, go for it. I don't.--<font style="font-family:Monotype Corsiva; font-size:15px;">]]</font> 02:05, 1 July 2011 (UTC)


:{{rto|Uwappa}}, this discussion is about '''the principle''' of how best to handle interactive content on Misplaced Pages. The details of the first such example are not relevant to the discussion. If anyone wants the details, you have covered them extensively at the template talk page. ] (]) 07:49, 3 November 2024 (UTC)
:::I don't think the comma rule name calling is really necessary. All I did was ask for a justification, and as far as I see it, I still haven't really got one. Give me a specific justification for this rule aside from Misplaced Pages tradition and the (seeming) desire to deviate from American writing industry tradition simply because it was the tradition.
::Yes, I get the question. Do you understand my answer or is this TMI again for you?
::Did you notice the interactive date computations at ]? It would be a compliment if you missed it.
::Please go and inspect that bit of wikitext. Yes, it is really that simple to make interactive calculations!
::] (]) 08:02, 3 November 2024 (UTC)


To answer the OP's original numbered questions:
:::Thing #1: Just because it's called logical punctuation doesn't necessarily make it more logical than any other rule. You can label anything in the world "logical," but to assume that the label makes it logical is a fallacy. In fact, I see "logical" punctuation as very illogical from a copy editing perspective because it's impossible to maintain consistency, it's (nearly) impossible to check correct usage, and readers are going to perceive errors (real or imagined).


#WP should {{em|very selectively}} include interactive content, when doing so enriches the functional (]) utility of the site in ways compatible with WP's goals. It is correct that WP is more than a traditional paper encyclopedia, but it ].
:::Thing #2: Maybe this is just my perception, but I feel like we're fighting "the way we've always done it" because we can. Is that and should that be a goal of Misplaced Pages?
#I would suggest starting with sectional inclusion (or, for something small enough, use in a sidebar). We're already doing this with some limited "test-bed" ways, e.g. with interactive maps in infoboxes, and some manipulable 3D visualization objects, etc. But just dumping it directly inline is probably "too much, too soon". I could see that being feasible for certain kinds of things in 5–10 years, maybe, after both the user base and the editorial community got more used to it.
#Basic, objective calculation is not ]. The policy is explicit about that, and we already use it regularly (just mostly non-interactively), e.g. to provide age-at-death calculations, inflation conversions, etc.
#] always matters, but there are ways around most accessibility problems (especially in a table-based structure like the one used as the example). Some other kinds of content simply are not accessible, and there's nothing much to be done for it, but we don't ban them. E.g., a movable panorama image is of no use to a blind person; the best they get is alt text. What's key, though, is that important encyclopedic material, verus "extra" or "enrichment" or whatever add-ons, must not be inaccessible (and supplementary materials should be made as accessible as possible, even if this is challenging).


I would add that the example given here is probably a good one, as the interactive form actually helps one to understand how the calculations work, plus people are apt to want to try their own numbers in there for personal relevance reasons, and it's not pure entertainment/trivia but something meaningful to them. A counter example might be adding a pool table simulator to an article about a pool game; we have no reason to do this. However, I could envision us having an extremely limited interactive feature to illustrate specific principles like, say, "{{cuegloss|running}}" sidespin on the cue ball and its effect on angle away from a rail cushion versus the angle the ball had coming in. Right now, we can illustrate the effect with a fixed series of short animations or even static diagrams, but it might be more useful to have a widget that took user input and illustrated the results. But it should certainly not be a "mess around all day on a pool-sim video game" feature. I.e., no ability to zoom out into a full-size table and simulate arbitrary billiards actions. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 16:30, 24 November 2024 (UTC)
:::Thing #3: I would like to see more solid facts in this discussion. I don't have many; that's why I'm here.


:I think articles on algorithms and math topics might be a place where having step by step interactivity would be particularly useful. I just added an interactive "illustration" to the article and I was also experimenting with the ] (not used anywhere as of yet). ] (]) 00:13, 26 November 2024 (UTC)
:::I'm not trying to be inflammatory; given my background, I'm simply questioning a policy that I feel could be improved. Please consider my ideas.--] (]) 04:01, 1 July 2011 (UTC)


== ] and ranges ==
::::This is my understanding of why logical punctuation is superior (and has nothing to do with my nationality or the way I was taught in school): If the name of a song is in quotation marks (e.g. "Let It Be"), then in a list ("Let It Be", "Here Comes the Sun" and "Hey Jude") it makes more sense to put the comma outside the quotation marks because the comma is not part of the name of the song. In a quote: {{xt|John Smith stated that "there are not enough bananas".}} makes more sense if the full stop is not part of the quoted material, otherwise you are altering the quote. Logical punctuation is clearer and cannot be misunderstood, unlike the other system. In my opinion, logical punctuation also looks better. I can't see any advantages to illogical punctuation, unless you personally think it is more aesthetically pleasing, which isn't really important. ''']&nbsp;&#124;&nbsp;]''' 05:10, 1 July 2011 (UTC)


{{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.}}
:::::Thank you for trying to explain it. My initial point was about copy editing, though -- how would you like to try to copy edit logical punctuation? You would have to look up every single piece of quoted material to check for usage. That is so beyond practical that it's not even funny.


Their argument
:::::And aside from that "illogical punctuation" isn't illogical simply because the punctuation is inside of the quotation marks; commas don't come at the end of a complete string in English because that's inappropriate usage. And with your quote example, it's not really altering the content by putting a period inside because you can't pronounce the period symbol. It has no sound and no meaning. It is simply present in writing to establish and clarify syntax. There is no period in spoken language. By saying that it changed the quotation, we would have to think that he said "there are not enough bananas period." In which case, we would write that he said "there are not enough bananas PERIOD." The ." means "quote and sentence over; expect a new thought to come at you." It neither contributes to nor detracts anything from the content of the quoted material.
{{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)
:::::I think it would be best to stop arguing, however, which is most logical (because that could go on forever); we should rather argue which is most useful in practice. I think I have a valid, indisputable point on the copy editing.--] (]) 05:34, 1 July 2011 (UTC)
::::::::The difficulty of copy-editing is why the ''Chicago Manual of Style'' recommends against "logical" punctuation. ] <small>]</small> 23:43, 1 July 2011 (UTC)


:, a second comma after the year in a range. ] (]) 13:10, 8 November 2024 (UTC)
::::::I disagree. We could easily say that if someone writes ''John Smith stated that "there are not enough bananas".'' we would also need to check if ''there'' is part of the quote or not so it would be easier to just get rid of the quotation marks. However, that would be silly. Why bother checking whether the punctuation was part of the quote or not? Do it if you're putting the quote into the article, that's not hard, but why check if someone else was right? It doesn't really matter. Another distinction is made with logical punctuation in the case of a broken quote: ''"There are not enough bananas", stated John Smith, "We need to grow more".'' (I don't know if I followed all the MoS rules in that example but the point is about the punctuation). Putting the comma inside the quotation marks would imply that the comma separated the two statements in the original quote, which is incorrect. Another case is if a song contained a full stop: ''John Smith wrote the song "Full Stop.".'' Although that looks a little odd, I would say that is the correct way of writing it, since the first full stop is just part of the name, not the sentence punctuation. ''John Smith wrote the song "Full Stop.."'' looks a lot worse. ''']&nbsp;&#124;&nbsp;]''' 05:49, 1 July 2011 (UTC)
::A minor ]. EEng: {{tq|do what feels best}}. SMcCandlish: {{tq|No, there is no exception}}. ] (]) 13:29, 8 November 2024 (UTC)
::::::::Actually, in U.S. English, if the period was part of the song, you wouldn't need the second period. The one inside the quotation marks does double-duty. ] (]) 11:57, 1 July 2011 (UTC)
:::Well I guess it makes sense to ping the previous participants then. @], @], @]. ] (]) 14:28, 8 November 2024 (UTC)
OK, this is painful, but at this point I say let's agree to disagree on logic. That's going to become a circular argument. Let's talk about practice exclusively. Which is more practical? See my comments on copy editing. Accuracy and consistency are important, so if we're going to go with a style, we need to do our best to follow it or we might as well have no style at all. And in the publishing world, it is an editor's job to check areas where errors commonly pop up, and this would definitely be one of those areas. Who wants to be in charge of checking quoted material?
::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)
I'm willing to estimate that about 50 percent of editors don't even know about this MOS rule, so they're not going to know that they need to maintain original punctuation when they pull the quote. Who wants to go back and check the quotes, particularly those pulled from protected databases and hard copy-only resources?--] (]) 06:06, 1 July 2011 (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.
:Like I said, it really doesn't matter if the punctuation is slightly off with quotes. I'd rather have a logical system with some errors than an illogical system which is immune to errors because the system is to deliberately use what others would consider errors. ''']&nbsp;&#124;&nbsp;]''' 07:03, 1 July 2011 (UTC)
: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}}
JP07, you are right to think that this is strange. The bottom line is that WP:LQ is here solely because most of the contributors to this talk page just (WP:IDONTLIKEIT/WP:ILIKEIT) prefer it to American English punctuation. You're also right that many Wikipedians don't know about this rule. The fact that a disproportionate number of Wikipedians were programmers might also have something to do with it. There is exactly one time when British vs. American punctuation actually makes a non-aesthetic difference, and that's when dealing with raw data strings. (Type in "enter.doc/qr". etc.)
::] does in any case refer only to MDY dates, not to DMY dates. ] (]) 20:54, 8 November 2024 (UTC)
WP:LQ has been challenged many times. Some of its supporters claim that it is, as the MoS says, less prone to ambiguity and subsequent errors, but no one has ever provided even one example of American English causing even one error on Misplaced Pages, ever. This isn't because American punctuation isn't used here. It is. There are even front page that have used American punctuation on their big day.
:::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 don't know if you know this, but ''almost every single American English style guide'' treats American punctuation as correct and LQ as incorrect in formal American English writing. If WP: MoS were held to the same standards as regular articles, those for reliable sources and no original research, then WP:LQ would have been changed long ago.
I 100% support changing the Misplaced Pages punctuation policy to follow ENGVAR. Use British/LQ when it is correct to do so and, at the absolute least, allow correct American punctuation on articles that are on clearly American topics. ] (]) 11:55, 1 July 2011 (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)
:Yeah... thanks for the backup. I kind of gave up, though. I got tired of asking for justifications and getting the "logical"/"illogical" appellations and tradition. And I do think it is odd that the writing prescriptivism seems to be coming mostly from computer programmers, and from what I can tell (i.e. per user pages and comment content), those who do not have experience as professional writers. I don't quite understand that. I do completely understand why the period and comma placement is important in programming, as I have a programming background as well... but programming and writing are two totally different things. The human mind does not process syntactic symbols in the same way that a computer does. And yeah, that's about what I thought with the style guides. I'm most familiar with AP and MLA, so I didn't want to make any more assumptions, but I had never heard differently on comma/period placement until yesterday.
*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)
:I think this is a losing battle, though. Even if you win this one, there's ]. I think it's more important to take on the battle for consistency before taking on specific rules. It seems like non-writers typically don't find consistency valuable in their writing, but both expert writers and novices will notice a lack of consistency and will critique it. Strange.
]

:Maybe it's just me, but I would think it would be wise for the predominantly programmer-run project to seek out the advice of writers...--] (]) 12:33, 1 July 2011 (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)
::You would think IAR would apply, but nope. I actually got brought up on AN/I for using American punctuation in articles that already had it. If we can get enough people, though, we might be able to modify or replace WP:LQ with something more sensible. Maybe the pro-LQ crowd would accept just allowing American punctuation (as opposed to requiring it) on American-subject articles. ] (]) 12:49, 1 July 2011 (UTC)
::::{{tq|I don't buy into the "OhButIfWeDon'tThereWillBeEndlessArgumentOnEachArticle" reasoning}}
:::I've privately softened a little bit on this one over the years; but what I really can't abide by is "this," where the inclusion of the comma within the word-as-word or the quotation jars with its very obvious identity as part of the main sentence. Also, I'm concerned that within-article consistency really could be achieved if the guideline is looser. ] ] 14:16, 1 July 2011 (UTC)
::::See, we're well past the "there ''might'' be argument" stage. The ]-]-]-], ]-]-] ] began long ago.
::::Wow, Tony. I guess I shouldn't be surprised that a reasonable person can change his opinions over time by continual observation of the situation to which they are relevant. However, I'd like to say that what people do and don't find jarring is in the eye of the beholder. If anything, the use of American style in words-as-words situations is even ''less'' likely to cause real confusion than with quotes from sources. ] (]) 14:24, 1 July 2011 (UTC)
::::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}}.
::::::And we recommend presenting words-as-words in italics, which removes the problem; both systems recommend {{xt|''this'',}} because italics have no visible closing marker. ] <small>]</small> 23:30, 2 July 2011 (UTC)
::::Ping priors {{U|Geraldo Perez}} {{U|MPFitz1968}} {{U|YoungForever}} {{U|Mz7}} {{U|HandsomeFella}}, IJBall is no longer around. ] (]) 00:33, 11 November 2024 (UTC)
:::I wouldn't think that IAR would apply. Despite its name, it doesn't literally mean you can ignore any rule. I prefer to think of it as "yes, there's technically a rule that covers this, but when the rule was codified, they didn't really consider this situation, and had they considered it, they would have accepted that this situation is different. That might mean the general rule needs modification, or it might simply mean that this situation should be considered a one-off exception". However, when we have rules that squarely apply, and have been repeatedly discussed and consensus is that they do apply to this situation, you don't get to use IAR.--<font style="font-family:Monotype Corsiva; font-size:15px;">]]</font> 16:39, 1 July 2011 (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...}}
::::What I'm most concerned with is pervasive consistency. Most people who read Misplaced Pages will read more than one article. So if one article is consistent but there are multiple variants elsewhere, I see intra-article consistency as moot. But I appreciate your diplomacy.--] (]) 14:27, 1 July 2011 (UTC)
: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)
:::::I am of the opinion that inter-article consistency is not necessary or at least more trouble than it's worth on Misplaced Pages. To effect it, we'd have to go all the way, pick just one national variety of English and use it on every single article for punctuation, spelling and all other considerations. Choosing American English punctuation to the exclusion of British/LQ wouldn't solve our problem; it would just reverse it. ] (]) 14:45, 1 July 2011 (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.
::::::Yeah... J-school might have made me a stickler for consistency.--] (]) 14:50, 1 July 2011 (UTC)
:Yes: {{xt|from October 12, 2012, to September 25, 2015.}}
::::::::Always ignore the Manual of Style; everybody else does. But thanks for trying to fix it. ] <small>]</small> 23:43, 1 July 2011 (UTC)
:Yes: {{xt|moved from Los Gatos, California, to Reno, Nevada, in 2021}}
:::::::It would be nice to have inter-article consistency, but that would force us to say things like "The American flag is coloured red, white, and blue" or "The English flag is colored white and red". In a publication requiring editorial approval, that's possible and even preferable. On Misplaced Pages, it's untenable.
:No: {{!xt|from October 12, 2012 to September 25, 2015.}}
:::::::Regarding punctuation: I've never understood why anyone uses traditional American punctuation. I remember being in sixth grade and learning the rules for commas and periods in quotation marks, and I remember asking the teacher why in the world would we do ''that'', it makes no sense! I've since realized that it has its own internal logic (as PMAnderson noted, comma-quote and period-quote are always read together even though they are two glyphs), but I still don't like it (I don't think you shouldn't put glyphs between quotation marks unless those glyphs can be attributed to the source you are quoting). My own preference is to leave punctuation outside quotation marks. This has the same copyediting advantages as traditional American punctuation while, in my opinion at least, being more accurate and prettier.
:No: {{!xt|moved from Los Gatos, California to Reno, Nevada in 2021}}
:::::::I agree with you that so-called "logical quotation" offers huge copyediting difficulties, and the name isn't very good. It might be possible to change to the system I mentioned above where punctuation is always outside the quotation marks, since that's already quite similar to what the MoS requires (and in fact you sometimes see people moving punctuation outside the quotation marks in the mistaken belief that it's an MoS requirement). But you seem to be advocating traditional American punctuation, and I don't think the politics of that will work: The non-Americans will protest, the Americans aren't nationalist and traditionalist enough to think that the way they were taught in school is necessarily better, and the result will likely be no consensus. You certainly won't change this rule by bringing it up here, where it's been talked to death. If you really want to change it, then you'd need to start an RfC on this topic here and advertise it very widely to pull in editors who aren't MoS regulars; and you'd have to do a very good job of convincing them. ] (]) 17:54, 2 July 2011 (UTC)
: 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."<!--
:::::::::Yeah... I will actually receive an American license to teach English and journalism in August, and I am of the thought that some of the lacking nationalism in America has to do with the way that we teach the English language in schools. I have yet to decide whether more nationalism would be a good or a bad thing, but there seems to be a movement among language arts educators away from teaching grammar; they often explain this by saying that grammar instruction "doesn't improve writing skills." I would agree with this sentiment -- writing content will not improve with greater understanding of grammar rules, but perceived credibility among readers definitely gets a boost when you demonstrate a mastery of the English language, and sometimes grammar and punctuation are important for clarity (so I guess in those situations this knowledge would improve writing skills). An ability to follow grammar and punctuation rules is also necessary for anyone who is interested in pursuing a career in writing, and it also helps with a number of other careers where writing is used.
--><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>
:::::::::But I think we often characterize the English language as illogical and silly despite the fact that it really isn't, and this damages the relationship that Americans develop with their own tongue. True, it is a mutt of a tongue, and it is difficult for people of other languages to learn, but there is some logic behind every language rule. It would probably be a little more... unified if it wasn't for Roman, French, and Nordic invasions of England, but what can you do.--] (]) 11:31, 3 July 2011 (UTC)
::{{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)
::::::::::Oh, and on the nationalism, it doesn't help that America still doesn't have a legally recognized official tongue. --] (]) 11:52, 3 July 2011 (UTC)
:::That's not the view of the MOS, though. ] (]) 09:56, 12 November 2024 (UTC)
:::::::::::I have long thought that the movement away from teaching grammar was a terrible idea. I receive, on a regular basis, emails from people who ought to be able to write better but can't. It makes them look bad. I've often wondered why the movement away from grammar started. Do teachers not teach grammar because they genuinely believe that, say, not recognizing misplaced modifiers doesn't improve writing skills? (On the other hand, Norman Mailer got away with it in the infamous opening line of ''Harlot's Ghost''.) Is it because grammar is objective and doesn't allow the favoritism games that provide some with such perverse pleasure? I wonder if it's now because they don't know anything about grammar themselves.
::::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)
:::::::::::I agree that English isn't as illogical as it's made out to be. But I think that reputation is a symptom of the lack of English grammar instruction. English teachers will tell their students not to write in the passive voice, and they consider this a vitally important rule, but they can't give a precise description of what the passive voice is. If they could, they would realize at once how silly the rule is. I think more harm has been done to English grammar by reformers than by all the the invasions of England, because the reformers moved the emphasis away from how real people write and speak and placed it on trivialities like passive voice or ''which'' versus ''that''. Now all anyone knows are these incorrect trivialities, and they can't write a single clear sentence.
:::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.<!--
:::::::::::I'm ranting again... Oh, well. ] (]) 13:42, 3 July 2011 (UTC)
--><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><!--
:@Ozob: People use "aesthetic" punctuation because it's almost as easy as the system you outline ''and'' a large number of anglophones will understand it: all those who use it, and a large body of those who don't but have heard of it.
--><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)
:Ozob's punctuation would not be a bad system; it works oddly for quoting full paragraphs, where everything ''but the final period'' will be inside quotes; both existing systems tuck the closing period inside. ] <small>]</small> 22:19, 2 July 2011 (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)
::I would be behind an RFC, actually. There are several good reasons for removing the ban on American punctuation.
:::::::But then, my talk page isn't all one post. ]] 22:45, 14 November 2024 (UTC)
:::1. The overwhelming majority of reliable sources on American English actively prefer American punctuation for general writing&mdash;which is what encyclopedia articles are.
:::::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.<!--
:::2. The idea that American punctuation causes misquotation, ambiguity or errors in subsequent editing is original research.
--><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>
:::3. American punctuation is already used on Misplaced Pages, despite the ban, and has ''not'' been found to cause misquotation, ambiguity or errors in subsequent editing to any detectable extent. (Also original research, admitted.)
::::::{{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:
:::4. Taking 3 into account, the ban only serves to punish and insult writers trained to use American punctuation and to please people who (WP:IDONTLIKEIT) just don't like American punctuation or who (WP:NOTACRYSTALBALL) think that "this is where English is going," etc. If American English ever changes to the British/LQ style, we can just change the MoS then.
::::::{| class="wikitable"
:::5. Using punctuation that is correct relative to its context would make Misplaced Pages look more professional and precise.
|+ Acceptable date formats
:::6. ENGVAR is already a proven policy and it is reasonable to believe that extending it to punctuation would work well. ] (]) 03:02, 3 July 2011 (UTC)

::::I, too, think an RfC would be a good idea because our discussion here seems to be a bit cyclical.--] (]) 16:46, 4 July 2011 (UTC)

::I too would approve of extending ENGVAR to punctuation. I see no reason to mandate one punctuation style over another on a Misplaced Pages wide scale when ''both'' are valid and acceptable styles. ] (]) 13:37, 3 July 2011 (UTC)

::Though it’s not high on my list, I also would permit “aesthetic” punctuation here, and second Blueboar’s comment about ENGVAR; we could argue forever about which practice is better and get nowhere—AmE and BrE sometimes differ, and one is no better than the other. I would like ENGVAR to include a recommendation that the combination of grammar, spelling, and punctuation be at least plausible to one accustomed to the particular ENGVAR; in many cases, this would allow some flexibility (e.g., some British publishers such as OUP use unspaced em dashes, and the BBC web site uses “aesthetic” punctuation), but the combinations should not be such that a British reader of an article supposedly in BrE thinks “this is whacked”.
::Incidentally, I certainly have not found US technical publications to favor “logical” punctuation here. I guess it just depends on one’s field and the particular publications. ] (]) 04:12, 4 July 2011 (UTC)

It's funny to see its being called "aesthetic punctuation". It looks quite ugly to me but that's in the eye of the beholder. I would oppose a change to the guideline on this not just because I don't like it but because it changes the quote. ]<sub>&nbsp;]·]</sub> 08:46, 4 July 2011 (UTC)
:Jimp, in all the times we've debated this issue, no one has yet provided even one example of American punctuation ever changing even one quotation on Misplaced Pages. (There have been a few "it changes the quote if you also remove half the words," though.) In American English, the closing periods and commas are understood as part of the quotation process, just as "centre" is understood as being pronounced "sen-ter" rather than "sen-treh" in British spelling. Can you show me a time when American punctuation changed a quotation on Misplaced Pages? ] (]) 12:26, 4 July 2011 (UTC)

::It changes the quote only in terms of punctuation. Jim said "I like frogs." No, he didn't, he said "I like frogs". It's a very minor point but because American punctuation makes no distinction between punctuation that existed in the original quote and punctuation that was added by the next writer, it makes it ambiguous and against the general principle of not changing quotes. Yes, in nearly all cases it won't change the meaning and it will be completely understandable but it's an unnecessary change to a quote nonetheless. ''']&nbsp;&#124;&nbsp;]''' 14:56, 6 July 2011 (UTC)
::::::This page abandoned any principle of not changing quotes the moment it recommended changing the punctuation ''inside'' them. ] <small>]</small> 22:27, 20 July 2011 (UTC)
::::But because the final period or comma is understood to be part of the quotation process and not part of the quoted content, it is not the quoted content that is changed. In all the times we've discussed this, no one has ever brought up even one instance of an actual problem, confusion or misquotation that could be attributed to the use of American punctuation. We shouldn't go banning things because of imaginary problems. ] (]) 03:20, 7 July 2011 (UTC)
:::To be clear, when we speak of “American punctuation”, we should say ''North'' American punctuation, because Canadian practice follows that of the US. As for “the general principle” of not changing quotes, it’s application here is not a general principle in the US and Canada. ] (]) 00:37, 7 July 2011 (UTC)
::::I've looked around a little and I've found one or two sources on Canadian English that preferred the British form. It seems that Canada can go either way, though I'd like to see a reputable print source on the subject. ] (]) 03:20, 7 July 2011 (UTC)
:::::'']''. For the most part Canadian punctuation is similar to that in the US, though there are a few things that seem unique to Canada. Spelling is somewhat of a hybrid, but looks mainly British to me. ] (]) 04:25, 7 July 2011 (UTC)
:There are two types of quotation mark styles: traditional quoting and logical quoting. Neither one is "American rules" or "British rules". They are simply two different styles, both used in both places, it's just that one of them happens to be more common in America, and the other more common in Britain.
:As far as ''why'' logical quoting should be used? There are any number of reasons:

::1) Logical quoting has been used on Misplaced Pages since its inception.
::2) Logical quoting is simply ''logical''... it makes sense for quote marks to contain only that which is part of what is being quoted. It makes no sense to include in quotes punctuation that doesn't belong there.
::3) Since the dawn of the computer age, especially with the arrival of command-prompt-based operating systems such as DOS, logical quoting has become accepted as common practice in America, and, although it wouldn't be entirely accurate to say that traditional quoting has quite fallen out of favour yet, it looks like it is set to in the very near future.

:Reason #2 is really the only important, and the only ''necessary'', reason to use logical quoting. It couldn't make more sense. If something belongs in the quote marks, put it there; if it doesn't, don't. If you actually ''did'' ride on something called a "bicycle,", then, by all means, include the comma with it. But I don't know what a "bicycle," is.<span style="color:#CC0000">-=( </span>]]<span style="color:#120A8F">03:53, 13 July 2011 (UTC)</span><span style="color:#CC0000"> )=-</span>

:::The sources refer to them as "American" and "British." They might ''also'' have other names but yes, they really are American and British. Proponents of LQ might wish that I were making it up, but if I am, so are Chicago and these guys: .
:::1) Just because a mistake is long-standing doesn't mean it shouldn't be corrected. I strongly suspect that the preference for British/LQ was present on early Misplaced Pages because its founders were disproportionately people with programming backgrounds as opposed to writing backgrounds.
:::2) '''In the absence of any actual effect, "This is more logical" is just another way of saying, "I personally prefer this more."''' It might be more logical to spell "caught" as "kot," but it's both wrong and sloppy. Using punctuation that is correct relative to its context makes Misplaced Pages look precise and professional.
:::3) Maybe it's become common practice among computer programmers but not in general-audience writing, and Misplaced Pages is a general-audience publication.
:::I would be extremely surprised if you or any of our readers didn't know what a "bicycle," however it was punctuated, is. The real logical way to write is the way that will be understood and appreciated by one's readers. British and American styles are about the same with respect to being understood, and people tend to appreciate the style with which they are more familiar. ] (]) 11:16, 13 July 2011 (UTC)

::::According to Darkfrog24 "just because a mistake is long-standing doesn't mean it shouldn't be corrected", but it is not a mistake for a publication like Misplaced Pages to have its own manual of style which chooses among reasonable alternatives. So there is no mistake. Even if the conjecture that the founders were Americans with programming backgrounds who defied the style used by American professional writers is true, so what? It was their publication and they adopted a reasonable style. No consensus has formed to change the choice. ] (]) 12:14, 13 July 2011 (UTC)

:::::This isn't like the serial comma, where either way can be considered correct so long as the piece is consistent&mdash;and, if you'll notice, the MoS permits ''both'' these forms; it doesn't ban one or the other for arbitrary reasons. Almost every single source on American English says that placing periods and commas inside closing quotation marks is correct and placing them outside is incorrect. To use a type of punctuation that is incorrect relative to its context, and to require others to do so, is not reasonable. It's a mistake. That's actually the most polite of many words for what it is. Using British/LQ in articles that are supposed to be in American English is like spelling "caught" k-o-t. Yes, it's logical. Yes, it can look cool or trendy in the eyes of certain beholders. It's also wrong. ] (]) 15:18, 13 July 2011 (UTC)

::::::Spelling ''caught'' as "kot" makes no sense whatsoever to me since I pronounce "o" and "or" as different sounds but that's beside the point. Logical punctuation is not incorrect. It's only "incorrect" if a style guide recommends traditional punctuation but it's only "incorrect" for the sake of consistency rather than "correctness". However, to proponents of logical punctuation, traditional punctuation ''is'' incorrect for the constantly repeated reasons above. Our MoS has picked a system and for the sake of consistency we should stick to it. Besides, the MoS is only a guideline; it's not necessary to follow it. You can go around writing with illogical punctation if you want as long as you don't change punctuation that complies with this guideline. ''']&nbsp;&#124;&nbsp;]''' 10:56, 19 July 2011 (UTC)
:What you're saying about style guides is true, and the style guides all say that, in American English, placing periods and commas outside adjacent punctuation is incorrect. If the MoS does not require inter-article consistency for spelling or the serial comma, then why require it here?
:You know what? We should do this RfC. Unless someone can provide at least a couple of examples of American punctuation causing miquotations or errors&mdash;or let's make it easier, problems of any non-imaginary kind&mdash;on Misplaced Pages, not "it looks like it ''would'' cause misquotations" or "gosh it really looks funny," but "here's the page history; it caused this problem," then it should no longer be banned. ] (]) 12:30, 19 July 2011 (UTC)
::Agreed. ] <small>]</small> 22:27, 20 July 2011 (UTC)
:::You really are missing the point here: If the punctuation is not part of the quotation but is included inside the quotation marks, then it's a mis-quote. There are infinite examples of that. However, other than that minor punctuation difference, American punctuation does not cause errors. But it's not just quotes, it's the other things that quotation marks are used for, such as song names or just highlighting phrases. In those cases, including the punctuation inside the quotation marks is always wrong. ''']&nbsp;&#124;&nbsp;]''' 14:24, 24 July 2011 (UTC)
::::I'm not missing the point: It isn't a a misquotation. If there is over a hundred years of precedent that this is simply how the quotation process works, then tucked-in commas do not constitute a misquotation any more than, say, changing the font or placing the quoted material in another piece of writing does. Here's an example. Let's say that a book called ''Source Material'' includes the following sentence, which I wish to quote in an article.
::::::''Jean recited the poem "Awesome" for school.
::::Now, if I quote the whole sentence, the MoS and most style guides (American and British) allow me to change those double quotes to single, like this:
::::::The book ''Source Material'' says, "Jean recited the poem 'Awesome' for school."
::::Gasp! But the source didn't use single quotes! It used double! Nevertheless, the people who read this quoted sentence 1. aren't going to misunderstand the source's meaning and 2. aren't being told that the source ''did'' use single quotes. When a quote-within-a-quote is made, single and double quotation marks alternate, and that's true in British and American forms. It is understood that there is a quotation process and that it involves moving punctuation marks around. If it is okay to actually change something that is literally within the quote, then why wouldn't it be okay to use periods and commas as part of the process that integrates the quoted material with the rest of the paragraph?
::::With song titles and nicknames, I don't know where you're getting "always wrong" from. Almost every American style guide says that commas and periods belong inside the quotation marks. So when one is writing in American English, including the punctuation marks inside the quotation marks is right. When one is writing in British English, then it is wrong. Also, when dealing with song titles and words-as-words, there is even less chance of misinterpretation than when quoting sources. Therefore, there is even less reason to use British styles on articles that are supposed to be in American English.
::::As for "just highlighting phrases," sources on both formal American and formal British styles agree that quotation marks should not be used for emphasis.
::::Oh, and a few years ago, I tried "not following" the MoS and used American punctuation on American English articles. I got brought up on AN/I for it. The MoS needs to be changed so that no one can be punished for using correct punctuation. ] (]) 00:26, 25 July 2011 (UTC)

I don't mean to sound like a dick here, but the notion that words that use re or er interchangably have different pronunciations is utter nonsense. First off, it doesn't matter which English-speaking country one is from, such words are always pronounced as their North American counterparts. The schools I've been to and the one I'm currently attending have had lots of American students pass through and each of them has had no trouble pronouncing the words in their British spelling. Likewise, words where the "ash" is retained (æ) or substituted for "e" don't change pronunciation, especially if you use a different English variant it's common knowledge that variations in spelling don't mean variations in pronunciation. —<span style="font-family:trebuchet ms">'''] <sup>(] • ])</sup> • 4:55pm''' •</span> 06:55, 28 July 2011 (UTC)
:That's my point: that it's nonsense. The -tre spelling ''looks'' as though it would confuse people. Logically, it really ''should'' confuse people, but that does not actually happen. Similarly, even though some people feel that American punctuation would confuse people, that does not actually happen.
:The point I was trying to make with the example was that British spelling only creates the illusion of being illogical, but we don't ban it. American punctuation only creates the illusion of being illogical, so we shouldn't ban it unless someone can prove that it's not an illusion&mdash;but linking us to a real problem that American punctuation has caused, such as an error. ] (]) 12:57, 28 July 2011 (UTC)
::Anyone with more than an elementary grasp of the English language understands that it is illogical. As they say, "Live with it". What would be helpful is a routine mechanism for flagging which ENGVAR is ''first'' established in an article to prevent unnecessary squabbling.] <small>]</small> 13:30, 28 July 2011 (UTC)
:::We allow British spelling despite its lack of logic, because it works under actual use. We should do the same for American punctuation, because it works under actual use. ] (]) 13:07, 29 July 2011 (UTC)
Then what's your point, DF? Don't the current policies and guidelines relevant to English Variants already state, clearly, that whichever English variant was used at the time of the article's creation, should be the English variant to be used in subsequent edits to the article? Unless of course, the article's country of origin is different to the English variant used. Why start this RfC if this is already clearly stated? —<span style="font-family:trebuchet ms">'''] <sup>(] • ])</sup> • 2:34pm''' •</span> 04:34, 31 July 2011 (UTC)
:No, ] does not state that it applies to punctuation. It says: "No variant is inherently more correct than another. Cultural clashes over vocabulary, spelling, and grammar can be avoided by using the following four guidelines. (The accepted style of punctuation is covered in the ], above.)" I changed the link so it will work on the talk page. It leads to a section that includes ], which specifies "logical punctuation". And although the point has been disputed, several people including Darkfrog maintain that logical punctuation can be called British punctuation. That makes WP:LQ an explicit exception to WP:ENGVAR. ] (]) 04:58, 31 July 2011 (UTC)
:My point is that we should not be using British punctuation on articles that are ostensibly written in American English, or at the absolute least, we should ''allow'' people to use American English punctuation on those articles.
:People say that American punctuation is illogical, but no one has pointed out any case of it causing even one non-hypothetical problem on Misplaced Pages. I'm using British spelling as an example of something that is also illogical but does not cause problems under actual use. I'm citing it as a precedent. ] (]) 11:20, 31 July 2011 (UTC)

===RFC: Rationale behind the ban and majority vs. sources===
{{rfc|policy|rfcid=648A396}}Rationale for MoS's ban of American punctuation (]) may not be based on fact. Lift it? Implications for WP:Consensus.
:'''Details:''' The Misplaced Pages Manual of Style currently requires British/logical-style punctuation on all articles, giving as its reason that this system is more in keeping with the principle of minimal change and less prone to misquotation, ambiguity and errors in subsequent editing. However, no one seems to be able to cite even one incident of American-style punctuation causing any misquotation, ambiguity, error, confusion, or other problem on Misplaced Pages. A significant minority of contributors to the MoS talk page want the ban lifted unless such problems can be shown to occur under actual use (rather than hypothetically). (NOTE: Despite the ban, American punctuation is used in Misplaced Pages articles, so the absence of errors is not due to the absence of American punctuation.)
:'''Other concerns:''' British/logical punctuation is the personal preference of a clear majority of MoS contributors. However, American punctuation is required by the overwhelming majority of sources on how to write American English (style guides) and actually used by a less dramatic but still clear majority of sources written in American English. '''What are the implications for WP:Consensus when what most people want isn't what the sources say and do? What trumps what?'''
:'''What we're talking about:''' British and American English punctuation systems differ in the way they treat periods and commas that are next to closing quotation marks in the cases of short-form works, words-as-words and certain other types of phrases: ''Bruce Springsteen, nicknamed "The Boss," wrote "American Skin."''/''Shakespeare, nicknamed "The Bard", wrote "Love's Labour Lost".'' More details can be found at ]. ] (]) 02:41, 26 July 2011 (UTC)

::And now for stuff that I didn't think was neutral enough for the RFC notice proper. Reasons to lift the ban:
::* No one has cited any instance of American punctuation causing even one non-hypothetical problem on Misplaced Pages.
::* This rule already has low compliance on Misplaced Pages. Of the about 92 '''featured articles linked to the front page''' since early April, about 11 have used American punctuation exclusively or predominantly and 20 have used a mix of British/logical and American.
::* The overwhelming majority of American English style guides require American punctuation. We could literally save time by naming the ones that do not, and those are written for specialized types of writing, such as technical writing and computer programming. Most Misplaced Pages articles are neither.
::* Using punctuation that is correct relative to its context makes Misplaced Pages look precise, credible and professional.
::* We already allow actual changes to punctuation within quoted material for the sake of correctness: We change a source's double quotes to single when creating a quote-within a quote. (Jane said, "I like the play 'Othello.'") Like this, American punctuation is understood to be part of the quotation process.
::* WP:ENGVAR is a proven policy. We wouldn't have to reinvent the wheel to allow both British and American systems. We also have a history of allowing the use and omission of the serial comma and both Oxford and non-Oxford British spelling within British articles. We wouldn't have to reinvent the wheel to allow American English articles to have two allowable systems either.
::* British spelling is illogical, but we don't go banning that. It sure looks like "centre" ''would'' mislead people into thinking that the word is pronounced "sen-treh," but that alone isn't sufficient reason to insult British English writers by declaring their spelling system inferior and banning it.
::* American punctuation makes for smoother and easier copy editing.
::* American punctuation is easier to teach and learn.
::* Banning American punctuation by claiming that it causes problems that it does not cause is insulting to trained American English writers.
::* While the popularity of logical quotation might be reason enough to ''allow'' it on American English articles, it is not reason enough to ban the style that is already established as correct.
::* If British/logical punctuation ever becomes standard in American English, we can always change the MoS then.
::Okay, everyone. Let's remember that we're here because we all agree that correct punctuation is important to Misplaced Pages. Whatever else we may disagree on, we're together on that. ] (]) 02:43, 26 July 2011 (UTC)
*'''Question''' - @Darkfrog24: can you supply a link to the specific section of the MOS that discusses this ban of American style? --] (]) 03:46, 27 July 2011 (UTC)
**It doesn't use the word "American", but he means ]. ] (]) 04:34, 27 July 2011 (UTC)
**And I think that guidelines that aren't even used on the 3342 featured articles that editors use for bragging rights, then they surely aren't used on the {{NUMBEROFARTICLES}} articles that readers use to educate themselves. Such guidelines are prime candidates for trimming, because if we trimmed enough, it might induce people to read the rest of our endless manual and its subpages. ] (]) 04:45, 27 July 2011 (UTC)
:::As much as I want this rule replaced, we should probably acknowledge that explanations of both American and British styles would take up more space, not less, than the current WP:LQ. ] (]) 13:29, 27 July 2011 (UTC)
**DF, again you seem to reduce everything to this nationalistic thing. It's not "American" or "British" punctuation—there's a lot of crossover. And this is ''not'' ans American project. ] ] 05:13, 27 July 2011 (UTC)
:::Here are sources referring to British and American punctuation and "British" and "American": . The second one has a quote from the Chicago Manual of Style 15th ed., which also refers to these systems as American and British. That should satisfy everyone that I am not inventing an imaginary national difference. If you know of any sources that prove that they are not British and American, please provide them.
:::We should not replace British punctuation with American. Then we'd still have the exact same problem except we'd be insulting and alienating British writers instead of American ones. We should allow both, as we already do with spelling. ] (]) 13:26, 27 July 2011 (UTC)
*'''Oppose change to MOS quote guideline''' - Okay, I've read ], and my opinion is that it is a valuable guideline. It is consistent with the goals of other MOS guidelines (promoting readability and uniformity) and it is rational. The MOS guideline adopts the "logical" convention for quote punctuation, which in my opinion is more readable than the other approaches. The fact that some articles do not adhere to the ] guideline is not relevant: "guidelines are sets of best practices that are supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply" (from ]). The argument that "no one reads the MOS because there are too many rules" is not accurate: many editors, such as myself, perform "search" actions on specific keywords and successfully find the desired guideline. --] (]) 14:30, 27 July 2011 (UTC)
:::Not "many editors" compared to what it takes to maintain {{NUMBEROFARTICLES}} articles. And even fewer editors know how to perform a keyword search that includes the Manual's subpages, not just the main page, and the need for subpages is a function of the number of rules. And performing a keyword search presupposes that you know somehow that there is a rule out there somewhere to be found. And if a new Wikipedian first encounters the Manual of Style and decides that its other-worldly expectations must have been written by people who never click "Random article", then he is unlikely to use ctrl-f to search it like scripture. ] (]) 16:35, 27 July 2011 (UTC)
::Okay, how do you feel about the idea that the MoS forces people to use punctuation that the majority of reliable sources say is wrong for pieces written in American English? Should the MoS be held to lower standards than regular articles? ] (]) 16:05, 27 July 2011 (UTC)
:::There must be twenty accepted style manuals in use throughout the English speaking world. When the WP community, by consensus, adopts one particular guideline on one particular rule (be it punctuation, or grammar, or formatting) that decision is bound to conflict with some of the accepted style manuals. It is also likely that WP MOS guidance will conflict with actual style usage in many writing domains. Such conflicts are no reason to avoid adopting guidelines within WP. The MOS supports the laudable goal of presenting a uniform reading experience to WP readers. --] (]) 16:15, 27 July 2011 (UTC)
::::This isn't a case of twenty style guides that all say something different. Almost all of them, all the big ones except ACS, say LQ is wrong in American English. It's like writing "labour" in an article on American unions. You won't find American style guides that tell you to use that U. And why ban one style at all? We already accept both British and American spelling systems and both Oxford and non-Oxford spelling within British.
::::But back to the original question: Do you know of any problems, errors, misquotations, etc., that can be attributed to American English? You don't seem to believe that the ban should be lifted, but the reasons you give, personal aesthetic preference and the idea that Misplaced Pages can make its own rules, aren't the same as the ones listed in the MoS. What do you think about removing the rationale itself from the MoS and FAQ even if the ban stays in place? ] (]) 17:38, 27 July 2011 (UTC)
:::::I have no objection to removing supplementary rationale from the MOS. They important thing is that the MOS specify ''some'' standard, for the reader's sake. Every decent multi-author work, especially encyclopedias, forces their authors to adhere to one uniform style standard. It would be chaos to have every article with its own style. --] (]) 18:27, 28 July 2011 (UTC)
::::::Misplaced Pages is not like other multiple-author works, though. A) We have no editorial board to enforce a standard. B) Anyone can edit (even anonymous IPs), so it's not limited to a small, selected group. And C) We already allow a variety of styles in differing articles; that's precisely what ENGVAR is about. This would be an extension (appropriate, in my mind) of ENGVAR to the style of punctuation. ] (]) 20:53, 28 July 2011 (UTC)
:::::::The ] policy, correctly, permits articles to use country-specific vocabulary or spelling. It does not cover punctuation, formatting,or style (including quotation punctuation). Consistency in the formatting and style is what makes the WP articles uniform, and provides a pleasing experience for readers. --] (]) 13:27, 29 July 2011 (UTC)
::::::::Differences in spelling and word choice already create far more visible variation than consistency, and the English language Misplaced Pages is no worse the wear for it; indeed, it's understood that such variation allows Misplaced Pages to reflect the real, natural variation in the English language. But my main point is there's more differences between the major varieties of English than just spelling and a few different words. The fact is LQ is, outside of a few specialist publications, utterly unused in American English. We should reflect that, and allow people to use the AmEng that is, not the one a few people want it to be. ]. ] (]) 14:01, 29 July 2011 (UTC)
:::::::::But what makes vocabulary so different from spelling, Noleander, that it should be ignored? Look at it this way: If British punctuation is used throughout Misplaced Pages, then all the British English articles are correct and all the American English articles are incorrect. It is more important to be consistently correct than consistently tucked or untucked. ] (]) 16:36, 29 July 2011 (UTC)
If I may be so bold to quote myself... Taken from archive 113, on a previous discussion on the matter:
<blockquote>As an observer who hasn’t thus far contributed much to this discussion, but who has followed it (and its numerous predecessors) carefully and learned much from it, I would like to offer this summation of the facts I see present here.
<p>
The MoS calls for the use of a style known as the logical punctuation of quotations, which has been called logical quotation or LQ for short. This system, as one of its main points, only includes terminating punctuation (commas, periods, etc.) inside the quotes if they were part of the original source material (and then only if it can be determined with certainty). This is in contrast with traditional quotation (aka typographical quotation or TQ), in which, with rare exceptions, "the comma comes before the quote ", to use my 5th grade teacher's mnemonic.
<p>
While not universal in use, nor always rigorously applied, LQ is the far more common system used in Britain (and other Commonwealth countries). This has lead some, including respectable style guides, to characterize it as the British system or style.
<p>
This characterization is in part due to the marked contrast with US (and Canadian, as far as I can tell) usage, where, outside of some scientific and technical writings, LQ is exceedingly rare, while TQ is common, standard American English. This is a real distinction, one of the many that make American and British English distinct varieties of the language.
<p>
And therein lays the issue some have with the requirement of LQ. Its status as non-standard in American English makes it decidedly strange to even highly-educated Americans. It raises questions about the "anyone can edit" nature of Misplaced Pages. Other questions about the efficacy of the 2 systems compared to each other are also often bandied about, but are ultimately subordinate to the main question.
<p>
Those that support the LQ requirement believe that it's easy enough to learn, and aids Misplaced Pages's exactness enough that requiring it provides greater benefits than burdens.
<p>
That's why it keeps coming up as a topic of discussion, and why this part of the MoS is often ignored. And that's what makes it a problem that needs a solution. It's obvious from those factors that the status quo is insufficient.
<p>
I hope this covers enough that we can discuss the issue without resorting to ludicrous claims or talking past each other.</blockquote>

Which brings it to my view. I believe that American-style typographers quotes should be permitted, so long as the article is internally consistent. It's an ENGVAR thing; LQ is almost entirely unknown in American English, and if we truly respect the principles behind that so-well-respected-that it's-almost-policy guideline, both forms should be allowed so that the form of quotation that most naturally matches the other aspects of spelling and usage can be used. It's not as though quotations are a rarely used or largely misunderstood aspect of writing (unlike, say, dashes ;-) ). People should be allowed to write quotes in the form that is most correct for the version of English in use. For American English that it typographers' quotes. The only reason to ban it is a false consistency, which is ever the hobgoblin. ] (]) 06:39, 28 July 2011 (UTC)

*'''Oppose''' – I would rather have one style, which is consistent throughout Misplaced Pages. Yes, we have two different styles for spelling and dating because there's no real reason why one should be used over the other. The reasons why logical punctuation is superior have been repeated countless times. However, if we do allow both systems, one thing that must always use logical punctuation is something like {{xt|To add a non-breaking space, type "<nowiki>&amp;nbsp;</nowiki>".}} Putting the full stop in the quotation marks would be confusing. ''']&nbsp;&#124;&nbsp;]''' 14:24, 28 July 2011 (UTC)
*:The claims that LQ is inherently superior is disputed. No one has shown that it truly creates misquotations, unless one treats all quotations as merely character strings. That's not actual writing; that's data entry. ] (]) 20:53, 28 July 2011 (UTC)
*::If there is "any real reason why one should be used over the other," McLerristarr, then please provide proof of it. Tony suggested that the Americanness and Britishness of these styles was only in my imagination, so I provided sources supporting the fact that they are not. Do the same for the claim that LQ is inherently better&mdash;or at least better for Misplaced Pages&mdash;than American style. But let's make this fair. I've been through this before, so I knew where to look. Do you need a couple of days to find something?
*::Side note: American style guides actually say to do as you have done for data strings; they simply acknowledge that such cases are rare in general-audience writing. I could go through a hundred Misplaced Pages articles and not find one key-entry instruction. Allowing American punctuation would not require {{xt|"<nowiki>&amp;nbsp;</nowiki>."}} ] (]) 00:32, 29 July 2011 (UTC)
*:“here's no real reason why one should be used over the other”... Well, it depends on what you mean by ''real reason''. Spelling ''cheque'' like this makes it clear that you don't mean any of the other meanings of ''check''. <small>Hell, I took several seconds to figure out what the title of the film ''Paycheck'' meant.</small> :-) Also, what would be wrong with {{xt|type <code>&amp;nbsp;</code>.}}? <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 01:12, 31 July 2011 (UTC)
:::If I were to write, “I’ll write you check,” would there be any question about what I meant? And I′m not quite sure I see how the distinction relates to quotation styles&nbsp;{{nowrap|. . .}} The “real reason,” I suspect yet again, is personal preference. ] (]) 02:25, 31 July 2011 (UTC)
::::That's actually a good example of what I mean by "real reason," A. di M. We permit "check" in American English because that ''is'' American English and "cheque" is not. We do this ''even though'' you have just given a real example of a time when "paycheck" caused some confusion. No one has ever given us a real example of American-style punctuation causing even one problem on Misplaced Pages. From what I can tell, it only causes errors and misquotations in people's imaginations.
::::There would be nothing wrong with putting commas outside the quotes when the quoted material is a data string. American punctuation explicitly permits it. However, such cases are very rare. If you go through a hundred articles, you might find one that requires this. ] (]) 03:12, 31 July 2011 (UTC)
::::Indeed. There are lots of cases where a particular construction/spelling/whatever is ''theoretically'' better than another, but that's not a good reason to use it when it's unidiomatic in the variety of English we're writing in. Communication is a two-way process, and a distinction will only be understood when it's present in both the writer's ''and'' the reader's dialect. If I decided to spell ''nail'' as ''nale'' when I mean a metal spike rather than a body part, that wouldn't make my writing any clearer unless the reader somehow knew what I'm doing. Now, to a sizeable proportion of Americans (as well as a sizeable proportion of those who have been primed into reading American English), {{xt|"this", John said}} doesn't communicate that the comma is not part of what John said{{ndash}}it communicates that the writer made a typo. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 09:57, 31 July 2011 (UTC)
*'''Keep logical punctuation'''&nbsp; I was using logical punctuation before I knew it had a name, and I have American training.&nbsp; IMO, accuracy in quoting the original material is more important than accurately following the American training.&nbsp; ] (]) 12:27, 31 July 2011 (UTC)
:So you've seen American punctuation cause inaccuracy? This is exactly what this particular RFC is about: If American punctuation is banned for causing inaccuracy, but opponents of the ban are saying that under general use it doesn't cause inaccuracy anywhere but in LQ proponents' imaginations. Do you remember exactly where it happened? If it was on Misplaced Pages, could you link us to the article history? ] (]) 18:33, 31 July 2011 (UTC)
::So you refuse to stipulate that inaccuracy can exist?&nbsp; How do you explain the existence of American style guides that call for logical punctuation? ] (]) 23:13, 1 August 2011 (UTC)
:::Inaccuracy can exist under any system. What I'm saying is that in all the times this rule has been challenged, no one has offered even one example of American punctuation causing any problem of any kind on Misplaced Pages. I'm not saying this couldn't possibly happen. I'm saying that '''if it's so rare that no one on this page has ever seen it, then it's not a big enough problem to be worth making, keeping or enforcing a rule against it''', especially a rule that requires people to write incorrectly. I'm serious about those questions, though. If you've seen a non-hypothetical error that can be attributed to American punctuation, you should post a link to it here. It's 100% relevant to the issue.
:::All the American style guides that I know of that call for LQ cover specialized types of writing, such as computer programming or technical writing. Misplaced Pages is a general-audience publication. Do you remember the names of the style guides you're talking about? ] (]) 00:00, 2 August 2011 (UTC)
::::Not really that interested in doing research, like I said, I prefer being accurate to the quotation more than I prefer being accurate to a style guide.&nbsp; Regarding the question about style guides, your quote above says, "The overwhelming majority of reliable sources on American English actively prefer American punctuation for general writing"&mdash;which means you already have a list of the "underwhelming minority".&nbsp; ] (]) 02:08, 2 August 2011 (UTC)
:::::Using American style ''is'' accurate to the quotation. There is over a hundred years of practice that demonstrates this. Also, using American punctuation on AmE articles would make them accurate to ''both'' the quotations and the American English style guides.
:::::As for your comment about lists, no, counting the majority doesn't also mean that I know which particular other style guide you've seen. Cards on the table: I wasn't before, but I am now asking you which style guides you're talking about, because you are now giving me the impression that you have never actually seen an American style guide that requires LQ. Look, if it's something you saw a couple of years ago and you don't remember exactly what it was called, then say that. There's nothing wrong with it.
:::::Bottom line? It's one thing to use LQ yourself if you want to, but to make or support a rule forcing others to use it as well, you should be able to point to something other than your own personal preferences. ] (]) 02:38, 2 August 2011 (UTC)
::::::So you are saying that you might have been wrong when you implied that there was an "underwhelming minority" on 02:41 26 July 2011, and you might have been wrong when you said recently, "All the American style guides that I know of that call for LQ cover specialized types of writing, such as computer programming or technical writing"; because you didn't actually check your facts, and you don't actually know of any such guides?
{{od}}
Which do you think is better workmanship:

*Regarding the question about style guides, your quote above says, "The overwhelming majority of reliable sources on American English actively prefer American punctuation for general writing&mdash;" which means you already have a list of the "underwhelming minority."

*Regarding the question about style guides, your quote above says, "The overwhelming majority of reliable sources on American English actively prefer American punctuation for general writing..."&mdash;which means you already have a list of the "underwhelming minority..."

*Regarding the question about style guides, your quote above says, "The overwhelming majority of reliable sources on American English actively prefer American punctuation for general writing"&mdash;which means you already have a list of the "underwhelming minority".
] (]) 01:19, 3 August 2011 (UTC)
::No, Unscintillating, that is not what I implied. You said, "How do you explain the existence of American style guides that call for logical punctuation?" and I asked you which style guides you've seen that do that. For example, you might have once worked for a programming company that had its own in-house style guide. That's something that would be likely to call for British punctuation and that I would not be likely to have seen. It's also possible that you saw a British or Canadian guide years ago and only thought it was American. But hey, I could be wrong. Your sources might be better than I think they are. There's only one way to find out and that's to ask you about them.
::If you don't remember which guide it was, why don't you look at the list of style guides at the top of this discussion page and see if anything jogs your memory? If the guide you're talking about isn't on that list, maybe you should recommend it for addition.
::Regarding workmanship, that is not strictly speaking "my quote." It includes you reacting to something I said, so it should be written like this: "You said, 'The overwhelming majority of reliable sources on American English actively prefer American punctuation for general writing' &mdash;which means you already have a list of the 'underwhelming minority.'" You will notice how the fact that I changed double quotes to single does not in any way alter the text or misquote either person. It, like American punctuation, is understood to be part of the quotation process.
::Getting back on the core topic of this RFC, I think it's safe to say that you don't want to lift the ban. I don't think either one of us thinks you're going to change your mind about that. What do you think about removing the rationale? If no one can show that American punctuation causes errors or misquotation, then the MoS should not claim that it does, regardless of what else it may say. ] (]) 03:26, 3 August 2011 (UTC)

====Comment from an outsider====
Having been invited by RfC to consider the debate here, as best as I can make out, the arguments revolve around:
# a prominent lacuna about notions of audience;
# consistency;
# enforceability;
# cultural chauvinism; and
# desire for certainty.

If the English Misplaced Pages has a potential audience of anyone who can read and understand English, the likelihood is that grammar is a secondary considerations to the reliability of the information we present in the articles we edit. Jacob Lumbumbu in Kenya, Wong Chu in China, Gupta Singh in India, and Mehmet Riza in Turkey are probably blissfully unaware that this debate is going on at all, and wouldn’t care if they knew about it. Chances are, though, they learnt their English by studying British English.

As best as I can tell, if a single article adheres to a single style, we are already ahead of the game. To impose a single style on all articles would require a lengthy, very prescriptive manual of style, and continuous editing of all articles to keep pace with inevitable, progressive changes to the manual. If punctuation alters the meaning of a sentence, it becomes important. If it represents only personal preferences, comfort zones or chauvinisms, it is largely irrelevant, so long as a single style is maintained in a single article. Personally I have never yet objected to an editor coming in behind me to change my punctuation to accord with someone else’s assertion that an article has been designated as adopting American or British (or Venusian) English. So long as the meaning isn’t changed, and my name isn’t on a final product about grammar and punctuation, what do I care?

Enforcing any guideline as a rule at Misplaced Pages is like herding 50 cats towards anything. Good luck. It is, in fact so difficult that I think we are better off to involve ourselves only in disputes that count for something, like the veracity of sources, point of view debates, and malicious vandalism. Trying to make the manual of style more prescriptive has only one end: to make of it a weapon with which to beat someone else around the head. In my opinion the manual is already too prescriptive, and I’d hate to see it become more so. The original authors of the manual probably intended us to aspire to the most professional, exemplary standards we are capable of, which is a sliding scale across the vast numbers of editors here. The more prescriptive we become about form as opposed to content, the more elitist we become, and the fewer editors will actually stick around to be berated about punctuation. I propose that the last thing Misplaced Pages needs is more cops, and certainly not a new layer of punctuation cops.

The vast majority of English-speakers in the world are not American. India alone might have more English-speakers than the US. Even in nations where English is not a recognised national language, it nevertheless has currency as the pre-eminent international language. After 300 years of the overpowering effect of British and American money, arms, and culture on the entire world, not to know English is almost a disadvantage, like poverty or famine. To argue, contrary to Misplaced Pages’s stated universalist aspirations, that Misplaced Pages is exclusively by Americans for Americans is cultural chauvinism. The internet doesn’t recognise national boundaries, nor does knowledge. Once something is entirely beholden to a single nationality it becomes possible to perceive it as ideologically tainted, or propaganda. Already the Chinese, for example, have expressed misgivings about Misplaced Pages functioning as an instrument of ‘American imperialism’. Let’s not assist that argument by making it more easy to propose. I’m pretty sure that’s not what we aspire to. If there must be an argument about punctuation, let’s not make it one internal exclusively to the USA. In fact, if any debate within Misplaced Pages becomes exclusive to North America (sorry, Canucks), I, and many others like me, are gone.

As a sub-clause of the ‘Amerika’ argument, I hope it’s legitimate of me to assume that the founders of Misplaced Pages sought to leverage a clear technological and aspirational, idealistic US leadership '''''in''''' the world to give something '''''to''''' the world that isn’t proprietary.

Moving on, progressively sharpening the focus of the scope and prescriptiveness of a manual appears to me to be the quest for certainty, and the abdication of rational judgement specific to each and every concrete instance in which judgement is required. To do so risks stifling the content of Misplaced Pages articles for the sake of the form in which they are presented. In that sense the aspiration to develop a prescriptive, absolute set of rules governing punctuation approaches faith in the righteousness of a knowable cause. The idea that punctuation should be pursued with that kind of fervour strikes me as quaintly Oxbridge English and absurdly impractical.

It has already been said that we are not a professional or elitist organisation; we are all volunteers and we come from vastly different intellectual, educational and social backgrounds. Looking to the Misplaced Pages Manual of Style as a means of homogenising us seems not only misplaced, but also of such trifling importance when compared to getting the articles right that I am inclined to argue conservatively: let’s not make the manual any more prescriptive than it already is.

Regards, <span style="color: #366; font-family: serif; text-shadow: 1px 1px 1px #000;">]&nbsp;&#124;&nbsp;]</span> 02:20, 29 July 2011 (UTC)

:Does that mean you consider allowing two punctuation styles to be more prescriptive than demanding only one? If not, then the proposal is to make the manual ''less'' prescriptive. I can't find the statistic usually quoted here, but I think it was about 45% of our readers are U.S. ] (]) 03:35, 29 July 2011 (UTC)
:Rereading the proposal, it doesn't come out and say logical punctuation in British articles, and U.S. punctuation (or whatever name is better) for American articles. But that's what he wants. ] (]) 03:48, 29 July 2011 (UTC)

:———
:I’ll say yet again that despite all the ultimately unresolvable claims by proponents of either practice, it′s essentially a matter of personal preference. Though Tony may find a comma inside closing quotation marks jarring, most of us in North America do not. I personally find spaced en rules used for parenthetical a bit jarring, yet there is at least one editor who “hates em dashes” Personal preference, I guess.
:I don’t see where Darkfrog24 has suggested that Misplaced Pages become exclusively North American. It would be nice to have one overall style for almost everything, but given the disparate makeup of WP readers and editors, I doubt we’d ever agree on much of anything. Especially spelling&nbsp;.&nbsp;.&nbsp;.
:Though the rough breakout as “North American” vs. “British” practice is probably reasonable, it’s hardly absolute. The BBC web site uses “aesthetic” punctuation (and double quotation marks), for example. Of course, I’ll say as usual that with typewriter quotation marks, there isn’t any aesthetic. But that’s another topic for another time (probably many other times, actually).
:As for the US/North American fraction of English speakers one could start with ] and ]. The trick is what to make of the data; for example, should Indians who speak English as a third language be treated the same as a native speaker from the US or the UK, or a non-English European who speaks it as a second language? If recent experience is any guide, I doubt we could discuss this in less than several gigabytes. And numbers alone don’t say a thing about punctuation practice. My impression has been that “aesthetic” punctuation is largely limited to North America, but I′ve never seen anything solid to back this up.
:Finally, though I support allowing “NA”-style punctuation here, it’s far from my top priority, as I said earlier. But I don’t think Darkfrog24’s proposal is unreasonable. ] (]) 08:27, 29 July 2011 (UTC)
::I have to agree with Art, Peter S. You make a lot of interesting points, but I'm a bit in the dark about whether you would prefer to lift the ban or leave it in place.
::This is probably the third time I've said it in this conversation, but ''I don't want to ban British punctuation. That would be just as bad as our current ban on American punctuation. I want to allow both styles'', preferably linked to ENGVAR. Taking a guess from the rest of Peter S.'s comments, I'd suppose that he might like allowing both styles but might not like linking them to ENGVAR.
::As for international readers, considering that most of them will be reading English as a second language, I'd say that we owe it to them to make their reading experience as correct as possible. No, teaching English isn't Misplaced Pages's main purpose, but it doesn't hurt either.
::Going back to the RFC: The rationale behind the ban is the belief that American punctuation causes errors that British/logical punctuation does not. Any thoughts on this, Peter S? ] (]) 13:03, 29 July 2011 (UTC)
:::Oh dear. You have me there, Holmes. My position is that we shouldn't ban anything as an absolute, but also that we shouldn't mess with the status quo. As a good conservative I should vote to do nothing. And yet my conscience says that we should also allow you to follow your own conscience. What am I to do? I'm with you, oh defiler of French delicacies. Overturn any ban on anything that isn't rational and clearly phrased. Regards, <span style="color: #366; font-family: serif; text-shadow: 1px 1px 1px #000;">]&nbsp;&#124;&nbsp;]</span> 20:55, 29 July 2011 (UTC)
::::Defiler of&mdash;oh God, does my username mean something wretched in French?
::::Back on topic, as for the status quo, you should probably know that American punctuation does get used on Misplaced Pages. In fact, it's been the predominant style in between 1/9 and 1/10 of the front-page featured articles posted since early April. Overturning the ban would simply ensure that people can't get brought up on AN/I for using American punctuation (which has happened at least once that I know of). ] (]) 21:45, 29 July 2011 (UTC)
:::::We can trade recipes for frog's legs later. In fact I might consider teaching a class about broiling or boiling the dismembered parts of your persona, but I suspect that even the French aren't gonna listen to what I have to say on that subject.
:::::What I do have to say is that I agree with you if your ambit is to remove a ban on language. <span style="color: #366; font-family: serif; text-shadow: 1px 1px 1px #000;">]&nbsp;&#124;&nbsp;]</span> 22:10, 29 July 2011 (UTC)
::::::We have three options: 1. Leave the ban in place and continue to require British styles on all articles. 2. Lift the ban, creating two allowed styles (as with the serial comma). 3. Lift the ban and tie punctuation to ENGVAR (as we do with spelling).
::::::The third one is what I personally believe would be best for Misplaced Pages, but I could live with the second one. ] (]) 01:11, 30 July 2011 (UTC)
:::::::My hand is up to stop the ban (option two), and I'm sorry about culinary jokes at your expense. <span style="color: #366; font-family: serif; text-shadow: 1px 1px 1px #000;">]&nbsp;&#124;&nbsp;]</span> 10:05, 30 July 2011 (UTC)
:::::::I’d lift the ban, allowing either style. ] (]) 22:45, 30 July 2011 (UTC)
:::::::I'd go with number 2 but “encouraging” number 3. (Note that we tie date formats with countries even though 31 July is in AmE and July 31 in BrE. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 01:04, 31 July 2011 (UTC)
:::“onsidering that most of them will be reading English as a second language”... I don't think so. of readers are from North America or the British Isles or the Antipodes, so, even if some of them are Spanish/French/Irish/Welsh/Māori/... native speakers, my bet would be that more readers are NS than are NNS. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 01:04, 31 July 2011 (UTC)
::::I meant most of the English-speaking readers from countries other than those traditionally thought of as English-speaking, India and China and the like.
::::PS, no need to apologize. I was only concerned because I thought it might not be an entirely culinary joke. ] (]) 03:12, 31 July 2011 (UTC)

== Dashes: a new draft ==

Having considered the voting and the long discussion (see some details ]), I offer a new draft for consideration at this central forum for MOS, now that business appears almost complete at the dedicated subpages. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 03:05, 13 July 2011 (UTC)

;Suggested procedure
# It is essential that our concluding discussion be kept orderly, focused, and respectful. With this in mind I am suggesting a framework. I urge editors to use this framework, or alternatively to propose rational variations of it. I urge all editors to work to keep the discussion easy to follow, and to refactor if that will help.
# '''I request that no changes be made to the draft during discussion of it.''' Please instead propose new versions for parts of it, with localised discussion. Again, it will be easy for the process to disintegrate if we are not vigilant to stay on track.
# I propose that we rule out certain distractions especially, and that editors join in removing such distractions to a special subsection I have set up to receive them:
#:• personal attacks or innuendos
#:• threats, or expressions of intent to take admin or ArbCom action against any editor
#:• political statements and manifestos
#:• unnecessary reference to past conflicts
#:• insistence that the Manual of Style be something other than just that (its status is definitely ''not'' our present topic)
#:• reflections on the role of MOS generally within Misplaced Pages
#:• other obvious irrelevancies or contention
# '''I suggest that there be no voting at this stage'''; let's see how things take shape.
# If any editor wants to propose a rewritten whole draft, please bear in mind the consequences. Discussion should have one overall focus at a time, and we can all end up confused and directionless. Therefore: '''Just as I gave 24 hours' notice before posting a whole draft, please give similar notice of any further whole draft.'''
# The single question we face is this: '''What dash guidelines will best reflect the clear results of the voting?'''

;Notes on the draft
# The draft does not reflect my own preferences as its proposer; it will not satisfy any individual's preferences fully, nor should it aim to.
# As a practical necessity, '''I have assumed that ''consensus'' means ''clear majority assent'''''.
# Some preferences in the voting are for more than one recommendation (for en dash ''or'' hyphen, in a given situation). This is heeded where it is a majority preference; but if the majority accepts a guideline simply as given, that simple endorsement has been respected as best reflecting consensus.
# Some matters have been set aside (partly or wholly) as better treated in general sections of WP:MOS, since they apply beyond the guidelines we deal with here. They include:
#:• the desirability of recasting (needs a new section of its own)
#:• the fact that exceptions are sometimes in order (already thoroughly covered)
#:• use of hard spaces (already covered in WP:MOS, but it may need adjusting)
# The draft is much longer than the existing section. It has to be, since this, along with hyphens, is one of the most difficult areas in modern punctuation. Editors will suggest ways to shorten it; but the voting has shown how easily brevity leads to entirely wrong interpretations. We need to guard also against intentional misconstrual.
# Cases like {{xt|a pro-establishment–anti-intellectual alliance}} are not treated with their own special principle. I found that they were covered by another more basic guideline that is included. This requires discussion. Can anyone think of a case that warrants, in the MOS context, a separate provision for such cases?
# As an aside, we need to revisit the colors used in the {xt} and {!xt} templates (for readers unable to distinguish red and green). Meanwhile, I have preceded all red examples (of what ''not'' to do) with an asterisk:
#: {{!xt|*−10–10}}; {{xt|−10 to 10}}

;The draft itself (click on the "show" link in the green bar):

{| class="navbox collapsible collapsed" style="text-align: left; border: 0px; margin-top: 0.2em;"
|- |-
! style="width:40pt;"<!--undersized width specification means actual column width determined by widest word/unbreakable string in the column-->| General use
! style="background-color: #aaffaa;" | '''Proposed draft for a new dash section'''
! 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}}
<big><big><big>'''Dashes'''</big></big></big>
| {{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.}} }}
{{shortcut|MOS:DASH|WP:DASH}}

Two forms of dash are used on Misplaced Pages: ''']''' (–) and ''']''' (—). Type them in as <code>&amp;ndash</code> (–) and <code>&amp;mdash</code> (—); or click on them to the right of the "Insert" tab under the edit window; or see ].
*Use hyphens, never dashes, in filenames of images, sounds, or other included media.
*When a dash is used in the title of an article (or any other page), there should be a ] from a hyphenated version: {{xt|]}} redirects to the article {{xt|]}}.

Sources use dashes in varying ways, but for consistency and clarity Misplaced Pages adopts the following principles.

<big><big>'''Punctuating a sentence (em or en dashes)'''</big></big>
{{shortcut|MOS:EMDASH|MOS:SENTENCEDASH|WP:EMDASH|WP:MDASH|WP:SENTENCEDASH|}}

Dashes are often used to mark divisions within a sentence: in pairs (''parenthetical dashes'', instead of parentheses or pairs of commas); or singly (perhaps instead of a colon). They may also indicate an abrupt stop or interruption, in reporting direct speech.

There are two options. Use one or the other consistently in an article.

;1. Unspaced em dash
*{{xt|Another "planet" was detected—but it was later found to be a moon of Saturn.}}

Or:

;2. Spaced en dash
*{{xt|Another "planet" was detected&nbsp;– but it was later found to be a moon of Saturn.}}

Do not use spaced em dashes.
*{{!xt|*Another "planet" was detected&nbsp;— but it was later found to be a moon of Saturn.}}

Dashes can clarify the sentence structure when there are already commas or parentheses, or both.
*{{xt|We read them in chronological order: Descartes, Locke, Hume—but not his ''Treatise'' (it is too complex)—and Kant.}}

Use dashes sparingly. More than two in a single sentence makes the structure unclear; it takes time for the reader to see which dashes, if any, form a pair.
*{{xt|The birds—at least the ones Darwin collected—had red and blue feathers.}}
*{{xt|"Where is the—", she said, but then realized she held it in her hand.}}
*{{!xt|*First in the procession—and most spectacularly—came the bishops—then the other clergy.}}

<big><big>'''En dashes: other uses'''</big></big>
{{shortcut|MOS:ENDASH|MOS:NDASH|WP:ENDASH|WP:NDASH}}

Apart from its use as a sentence-punctuating dash (see above), the ] (–) has four other roles. These can be quite similar to uses of the hyphen (see ] above); or less often, the slash (see ] below).

;1. In ranges that might otherwise be expressed with ''to'' or ''through''
*{{xt|pp.&nbsp;211–19}};&nbsp;&nbsp; {{xt|64–75%}};&nbsp;&nbsp; {{xt|the 1939–45 war}}
Do not mix en dashes with prepositions like ''between'' and ''from''.
*{{xt|450–500 people}}
*{{!xt|*between 450–500 people}}; {{xt|between 450 and 500 people}}
*{{!xt|*from 450–500 people}}; {{xt|from 450 to 500 people}}
Use words, not en dashes, if negative values are involved. An en dash might be confusing.
*{{!xt|*&minus;10–10}}; {{xt|&minus;10 to 10}}
*{{!xt|*the drop in temperature was 5°–&minus;13°}}; {{xt|the drop in temperature was from 5° to &minus;13°}}
The en dash in a range is always unspaced, except for times and dates (or similar cases) when the components already include at least one space.
*{{!xt|*23 July 1790–1 December 1791}};&nbsp;&nbsp;&nbsp; {{!xt|*14 May–2 August 2011}}
*{{xt|23 July 1790&nbsp;– 1 December 1791}};&nbsp;&nbsp;&nbsp; {{xt|14 May&nbsp;– 2 August 2011}}
*{{xt|10:30&nbsp;pm Tuesday&nbsp;– 1:25&nbsp;am Wednesday}};&nbsp;&nbsp; {{xt|Christmas Day&nbsp;– New Year's Eve}}
*{{xt|1–17 September}};&nbsp;&nbsp; {{xt|February–October 2009}};&nbsp;&nbsp; {{xt|1492?&nbsp;– 7 April 1556}}
*{{xt|Best absorbed were wavelengths in the range 28&nbsp;mm&nbsp;– 17 m.}}

;2. In compounds when the connection might otherwise be expressed with ''to'', ''versus'', ''and'', or ''between''
Here the relationship is thought of as parallel, symmetric, equal, oppositional, or at least involving ''separate or independent elements''. The components may be nouns, adjectives, verbs, or any other part of speech. Often if the components are reversed there would be little change of meaning.
*{{xt|boyfriend–girlfriend problems}};&nbsp;&nbsp; {{xt|the Paris–Montpellier route}};&nbsp;&nbsp; {{xt|a New York–Los Angeles flight}}
*{{xt|iron–cobalt interactions}}; the components are parallel and reversible; iron and cobalt retain their identity
*{{!xt|*an iron–roof shed}}; ''iron'' modifies ''roof'', so use a hyphen: {{xt|an iron-roof shed}}
*{{!xt|*the poet's mentor–muse}}; not separate persons, so use a hyphen: {{xt|the poet's mentor-muse}}
*{{xt|red–green colorblind}}; red and green are separate independent colors, not mixed
*{{!xt|*blue–green algae}}; a blended, intermediate color, so use a hyphen: {{xt|blue-green algae}}
*{{xt|France–Britain rivalry}};&nbsp;&nbsp; {{xt|French–British rivalry}};&nbsp;&nbsp; {{!xt|*Franco–British rivalry}};&nbsp;&nbsp; {{xt|Franco-British rivalry}}
*{{xt|a 51–30 win}};&nbsp;&nbsp; {{xt|a six–two majority decision}};&nbsp;&nbsp; {{xt|an Obama–Palin debate}}
*{{xt|an Italian–Swiss border crossing}}; but {{xt|an Italian-Swiss newspaper}}, for Italian-speaking Swiss
*{{xt|the Uganda–Tanzania War}};&nbsp;&nbsp; {{xt|the Roman–Syrian War}};&nbsp;&nbsp; {{xt|the east–west runway}}
*{{xt|diode–transistor logic}};&nbsp;&nbsp; {{xt|the analog–digital distinction}};&nbsp;&nbsp; {{xt|a carbon–carbon bond}}
*{{xt|a pro-establishment–anti-intellectual alliance}}
*{{xt|Singapore–Sumatra–Java shipping lanes}}
*{{xt|the ballerina's rapid walk–dance transitions}};&nbsp;&nbsp; {{xt|a male–female height ratio of 1.2}}
A slash or some other alternative may occasionally be better to express a ratio, especially in technical contexts (see ] below).
*{{xt|the protein–fat ratio}}&nbsp; or&nbsp; {{xt|the protein/fat ratio}},&nbsp; or even&nbsp; {{xt|the protein-to-fat ratio}}
An en dash is not used for a hyphenated personal name.
*{{xt|Lennard-Jones potential}} with a hyphen: named after John Lennard-Jones
An en dash ''is'' used for the names of two or more people in a compound.
*{{xt|the Seifert–van Kampen theorem}};&nbsp;&nbsp; {{xt|the Seeliger–Donker-Voet scheme}};&nbsp;&nbsp; {{xt|the Alpher–Bethe–Gamow theory}}
*{{xt|Comet Hale–Bopp}} or just {{xt|Hale–Bopp}} (discovered by Hale and Bopp)
Following the dominant convention, a hyphen is used in compounded place names and language names, not an en dash.
*{{xt|Guinea-Bissau}};&nbsp;&nbsp; {{xt|Austria-Hungary}}
*{{xt|an old Mon-Khmer dialect}};&nbsp;&nbsp; {{xt|Niger-Congo phonology}}

The en dash in all of the compounds above is unspaced.

;3. Instead of a hyphen, where at least one component includes a space
*{{xt|an ex–prime minister}};&nbsp;&nbsp; {{xt|pre–World War II aircraft}}
In many cases, recasting the phrase is possible and better.
*{{xt|a former prime minister}};&nbsp;&nbsp; {{xt|aircraft before World War II}}

The en dash in all of the compounds above is unspaced.

;4. To separate items in certain lists
Spaced en dashes are used within parts of certain lists. Here are two examples:
* Pairing performers with instruments.
**{{xt|James Galway – flute; Anne-Sophie Mutter – violin; Maurizio Pollini – piano.}}
* Showing track durations on a CD.
**{{xt|The future – 7:21; Ain't no cure for love – 6:17; Bird on the wire – 6:14.}}

----
|}

=== Discussion of the draft ===

At first reading, this looks pretty good. I still think we need to mention the use of the en dash (or em dash??) as a separator when it's neither in a sentence nor in a list, as in the ] case we discussed – this seems to come up from time to time, in article titles at least, and people usually seem to opt for a spaced en dash (or some alternative other than a horizontal line) when the matter is considered.--] (]) 04:07, 13 July 2011 (UTC)
:Thanks, Kotniski. And thanks for breaking the ice with your draft, which influences the one I offer here. I agree that more work needs to be does on the point you mention. Luckily, it is self-contained and probably not a major cause of difficulty. Why not propose a neat modification to cover it? <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 06:23, 13 July 2011 (UTC)
::Noetica, I've looked only cursorily through your draft, and I must say that it's impressive. (Kotniski's was impressive too, but I believe this more recent draft takes the ball and runs with his improvements.) I was slightly concerned at the length of Noetica's draft, and we need to scrutinise it for "trimming opportunities"; but then, putting myself in WP editors' shoes, I learn something from every example, and examples are the key to conveying professional-standard typography. When this is tweaked, the final version might well be worth printing out and distributing to my clients. I'm most interested in the opinions of other editors. Thank you indeed, Noetica. ] ] 06:43, 13 July 2011 (UTC)

I think it looks pretty good, but a few comments:
*The order of the recommended/not recommended practice in the examples should match that in the text that precedes it, rather than the opposite, as in
*:Use words, not en dashes, if negative values are involved. An en dash might be confusing.
*::{{!xt|*&minus;10–10}}; {{xt|&minus;10 to 10}}
*Spacing of range dashes where one or more elements contains a space: either spaced or unspaced use should be allowed. The polling seems to indicate considerable support for allowing both, and the support for closed-up usage in US, Canadian, and British style guides (APA, CMOS, MWM. TCS, OSM, and NHR; the last two do mention that many British publishers space the en dash) is overwhelming. Like CMOS, I would usually prefer ''to'' or ''through'' for a complete date, but I certainly see no problem with {{xt|Christmas Day–New Year's Eve}} when we can use {{xt|New York–Chicago flight}}—there’s little ambiguity with either.
*Under (2), it might help to explain why {{xt|Franco-British rivalry}} takes a hyphen rather than an en dash—perhaps something to the effect of “the order of ''Franco'' and ''British'' cannot be reversed”, or “''Franco'' is a prefix than cannot stand alone”, or “''Franco'' is not lexically independent”. The last would be my last choice, because although its meaning may be obvious to most of us here, it may not be to others, and searching for the meaning is no simple task.
*Under (3), I would add one example in which the first component contains a space (e.g., {{xt|Chuck Berry–style lyrics}}, {{xt|New Zealand–style clothing}}, {{xt|golf ball–sized brain}}.
*The usage within items in a list (which I’m still not convinced is a distinct case) should not lend itself to be read as precluding alternatives, of which the unspaced em dash is the most obvious, but not the only possibility. If a style has been established for a specific class of articles (e.g., Days of the year), that style should be followed. For articles on discography, the format is not nearly so uniform, so any reasonable alternative should be acceptable. I don’t think we should give alternatives any more than a brief mention, and even then, it should only serve to indicate that there ''are'' alternatives. ] (]) 07:15, 13 July 2011 (UTC)

:Thanks Jeff. On each of your points in order:
:* I understand about keeping a uniform order of presentation. The trouble is this. It's good to keep the order ''wrong''–''right'', consistently in the examples (as I have done). But the explanation may be shorter and easier to follow in the reverse order. I don't see a difficulty in the case you exhibit above: the examples almost stand alone to make the point. Anyway, sure: such a refinement can be flagged for incorporation.
:* On the spacing of range dashes, the task is to interpret the voting and associated discussion, not to return yet again to the style guides. We have moved on from that, and must stay moved on if we want to make genuine progress and reach a conclusion. On the specific point you raise, though, about {{xt|Christmas Day—New Year's Eve}} being justified by analogy with {{xt|New York—Chicago flight}}, note that the sense of the dash differs. In one it shows a range, in the other it shows a relationship between two elements. Given that difference in meaning, it is well that the dash should at least behave differently with respect to spacing. That is at least as arguable. In the end, I believe the position I have incorporated reflects the clear majority in the voting.
:* For the prefix element "Franco", I agree entirely that things should be made explicit for it. I did that, then trimmed it out in pursuit of less wording. It can easily be put back, if people want that.
:* You write: "I would add one example in which the first component contains a space (e.g., {{xt|Chuck Berry—style lyrics}}, ...". But that was not put to a vote, so we have no evidence of consensus for it. These differ considerably from prefix cases, and they are treated differently by various style guides (for what that's worth).
:* I have little to say about dashes in those lists. For me it's pretty arbitrary, and a much easier thing to sort out than the other principles. Let others have their say: but let it be efficient and conclusive dialogue.
:<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 09:22, 13 July 2011 (UTC)
::* I tend to prefer “right/wrong”, but don’t have strong feelings, and would not even insist that the order be consistent overall if variations would make the individual points more clearly. But I would urge consistency between the text and any specific examples; either order would probably work, as long as the order of the example matches that of the text that describes it.
::* On spacing of range dashes, it obviously depends on how one interprets the voting. Though there seems to be more support for spacing, I obviously do not interpret the voting as clearly precluding closed-up use, as is supported by the overwhelming preponderance of widely respected style guides. I once again urge correct use of the singular and plural: you clearly speak for yourself and a fair number of others, but you definitely do not speak for everyone here, as the use of ''we'' would seem to imply. I am quite honestly baffled by “We have moved on from that”; if this is to say that we care not about widely accepted practice, it is almost as if we have extracted a position from a region in which the “]” is inapplicable, and the position accordingly is little more than ]. I agree that there may be a difference in the sense of the two examples, but the difference is slight, and in any event, the mere existence of a difference does not in itself justify differential treatment. The issue is rather, I think, one of whether the closed-up usage leads to ambiguity—and it does not. As I previously indicated in my comment on the voting, we have essentially an issue of operator precedence, in the order of hyphen, space, and en dash. If we accept this, there is no ambiguity; if we do not, much of the overall rationale for using en dashes is weakened. Lest I be thought a pusillanimous pussyfooter, I can assure you that I will oppose a draft that proscribes the closed-up use.
::* As for {{xt|golf ball–sized brain}}, I agree that we did not vote on the specific example, but we did previously vote on the more general case of compounds that contain hyphens or spaces, and, by implication, that {{xt|golf ball–sized brain}} would be preferable to {{xt|golf ball-sized brain}}, even if the endorsement of the former was tepid at best. ] (]) 10:23, 13 July 2011 (UTC)
::::Jeff, on the order of "right" and "wrong" examples and all that: no big deal. I suggest we defer adjusting such things, till weightier matters are dispatched.
::::On your remarks concerning the spacing of range dashes: For the third time, please desist from critique of my use of "we", which I have explained elsewhere. Stay with content, not its expression (on whose analysis we disagree). It seems that you refer to this statement of mine: "... the task is to interpret the voting and associated discussion, not to return yet again to the style guides. We have moved on from that, and must stay moved on if we want to make genuine progress and reach a conclusion." If you think our present task is different, please raise that matter in the subsection below: ]. Meanwhile, a close quantitative and qualitative analysis of the voting and comments on the point at issue would be relevant and valuable. I hope you will undertake that, and report it here. Finally on this, you say: "I can assure you that I will oppose a draft that proscribes the closed-up use." Please note that if we all take such stands even before such shared examination of voting, and also elevate clearly minority positions to sub-guideline status, we will end up with unmanageable complexity. The guidelines will be unworkable: they will fail to guide. With that in mind, I have suppressed my own strong disagreement with {{xt|ex–prime minister}}, though dissent from that in the voting would support my acting on that disagreement here. We must ''all'' be careful not to fall victim to ]. Everyone must compromise; that's how it is, with manuals of style.
::::On forms like {{xt|golf ball–sized brain}}, if you thought the community should consider those, the time to raise it was six weeks ago when the points for voting were settled. We ''have'' moved on! :) <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 22:48, 13 July 2011 (UTC)
:::::The points for voting were "settled" overnight without discussion from a list intended for a different purpose. They omitted much; this is one point that was omitted. As for ''we'', Noetica does not speak for anyone but xemself;<s> unless this is a case in which Mark Twain is correct.</s> ;} ] <small>]</small> 23:04, 13 July 2011 (UTC)

:::::I don’t necessarily object to ''we''; I use it here myself, but not in the sense of purporting to speak for Misplaced Pages when that is not necessarily the case. ''You'' feel that we have “moved on” from widely recognized sources, but clearly not everyone agrees (though I would certainly not go so far as to say that you speak ''only'' for yourself). You’ve also offered a definition of “consensus” that differs markedly from ]. I don’t necessarily see a “clear majority”, and it’s never been been strictly a matter of numbers, anyway—we seem to be missing the “quality of arguments”. If practice supported by the preponderance of quality guides is to be blown off, especially without any real reason for doing so, what then constitutes “quality of arguments”?
:::::If you’ve followed my comments, I’ve generally been very supportive of what’s been proposed, but I now find myself almost to the point of clearly recognizing that the MOS is a ''guideline'', and using my own judgment for recommendations are little more than dogged insistence on ], especially when they represent minority practice. I assure you that I shall not be writing {{xt|golf ball-sized brain}} (though I concede the opportunity to do so may never arise). ] (]) 02:35, 14 July 2011 (UTC)

My comments:
*I like Kotniski's draft more. (This one is a bit too wordy.) :-)
*I'd always use {{tl|xt}} and {{tl|!xt}} in ways that it is obvious from the surrounding texts which are the right examples and which the wrong ones, even without relying on the colour or on symbols such as asterisks, as in “{{xt|right}}, ''not'' {{!xt|wrong}}”, or “avoid {{!xt|wrong}}; prefer {{xt|right}}”. <small>But then, I once proposed for {xt} to have a tick and underlining and {!xt} to have a cross and strike-through, but it was opposed as too much clutter. A darker red and a paler, more bluish green (e.g. <span style="color:maroon">maroon</span> and <span style="color:teal">teal</span>) would be easier to tell apart for colour-blind people, but for readers with non-standard display gammas the former might be too dark (harder to tell from regular black text) or the latter too pale (harder to read against the background).</small>
*IMO, image filenames are even less relevant than recasting or hard spaces or exception would be (for ).
*As I already said elsewhere, I'd suggest the advisability of recasting the phrase using different examples than the ones where a dash is suggested. I'd use examples like the current ones for the dash (with such über-familiar noun phrases as ''prime minister'' or ''World War II''), and then after “... is possible and better” show seriously abstruse examples in red followed by a suggested rephrasing in green.
<span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 11:38, 13 July 2011 (UTC)
<span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 11:38, 13 July 2011 (UTC)
:::Examples of what you have in mind for the last point would be helpful. ] <small>]</small> 21:55, 13 July 2011 (UTC)
::A di M:
::* I like Kotniski's draft too; and Kotniski likes the present draft (too). On wordiness, please specify which words you would remove from the present draft. In introducing it, I predicted that editors would make such suggestions. But again: we have seen how brevity is misread in this most complex of punctuation topics; and we must preempt abuse of MOS guidelines that would capitalise on lacunae.
::* On the practical red–green issue, it may be best to deal with that another time. I like your comments. Meanwhile, we have a simple solution with "*" to get us through the present business.
::* On image filenames and the like, thank you for attending to this matter of general provisions versus local provisions. I'm not convinced yet on this one; I had thought that hyphens and dashes in filenames was a pretty confined issue. I wonder what others think?
::* On recasting, I strongly suggest that we stick with rewordings of the actual examples given; but I also strongly favour using less familiar examples to start with. I did not include those for this point, because I wanted editors to recognise the examples&nbsp;– for continuity with earlier versions of the guideline, for this discussion. Let's alter them later, sure.
::<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 23:15, 13 July 2011 (UTC)
:::Answering the points in order: 1. I'm not sure exactly what words are the culprit, but I'm under the impression that Kotniski's version manages to say pretty much the same things more concisely and no less clearly (though a couple extra examples might be added); 2. I still think that ''not'' would be a lot clearer than an asterisk, though it works better if right examples are before wrong ones (“{{xt|foo}}, not {{!xt|bar}}” vs “not {{!xt|bar}}, but {{xt|foo}}”); 3. I think whatever argument for or against the avoidance of dashes in file names would apply to pretty much all other hard-to-type characters; anyway, I think it's pointless as most files are hosted on Commons so the uploader might have never even ''heard'' of en.wiki's MOS; 4. if we say that rewording is sometimes (but not always) better, I think we ought to include both examples of when it's better than when it isn't. As for the former, I recall someone asking on this talk page how to punctuate some very complicated technical term itself including a several-word technical term as a modifier, and someone else (IIRC either you or Tony) suggested a recasting. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 14:59, 14 July 2011 (UTC)
Thanks, Noetica, it looks like a good step, very clear and logical, lots of on-point examples. A few comments:
<p> <!-- no inline interrupting comments here please -->
I am a little bothered by the statement "These can be quite similar to uses of the hyphen; or less often, the slash." The "quite similar" doesn't quite capture the right relationship. As one commenter pointed out in the voting or discussion, "interpretation is needed" in deciding whether some of the described roles are applicable in a particular case. Your examples make it clear that to decide which punctuation is needed in something like "blue–green", one has to consider the role, which requires interpretation; the process is not mechanical, because it signals the writer's intent; and that's why it's useful. Anyway, "quite similar" seems to sweep that point away. It would seem important to point out that the en dash roles differ from the roles of a hyphen; maybe something like "These are analogous to uses of the hyphen, which binds more strongly than the dash; or the slash, which separates alternatives."
<p> <!-- no inline interrupting comments here please -->
Another point: I still think the item "4. To separate items in certain lists" is not a separate role, but just another case of using spaced en dash as a dash; same idea in Kotniski's point.
<p> <!-- no inline interrupting comments here please -->
I'm surprised the "ex–prime minister" item causes trouble, but on review I see that several people had various problems with it. I note that it's taken directly from , along with the "anti-xxx–pro-xxx" example, which would certainly not be OK with a hyphen, but for other reasons as you note; it's similarly expressed in lots of other guides, though often as an option for improving clarity "when needed." And suggests "pre–World War II", and states that the hyphen is "incorrect" in that context; and on "post–World War II" and "San Francisco–based," we have the word of ; say similarly. So is this one more optional than most? If some editor changes "ex–prime minister" back to the hyphen version, should we complain and fix it back? I still think we should, since if an editor finds it useful to use punctuation to signal the structure more clearly, we ought to let them. In that sense, I don't see the point of trying to make this one more optional than most, as some are suggesting. On the other hand, I don't have strong feelings about it, and would be willing to go with adjustments if there's a consensus to do so.
<p> <!-- no inline interrupting comments here please -->
I would support the idea of removing mention of filenames, since it is not a style issue, just a source issue.
<p> <!-- no inline interrupting comments here please -->
On the spaced vs. closed-up en dashes, I'm happy to see that there's less of the spacing suggestion than before, and I agree that it should stay in the case of the date phrases with spaces in them, as it appears in every WP bio article. It's a step in a good direction (away from "too British for some"), and stops short of going too far; it's exactly as I would have interpreted the discussion.
<p> <!-- no inline interrupting comments here please -->
Generally, I think you addressed most of the disagreements – even the "facepalm" one. It would be hard to address the issues of the two guys who disagreed with most of the en dash roles, and still call it a consensus result. A few more may show up now, like the one who complains that he can't tell a hyphen from an en dash in a typewriter font, so it doesn't matter what you use; but I agree it's time to try to adjust the dash section as constructively as we can given all the constructive feedback that has come out. Thanks again for this draft, building on Kotniski's. ] (]) 03:54, 14 July 2011 (UTC)
:North American and British practice differ on spacing, and on use in spaced compounds—NHR states that there is no satisfactory way of dealing with “ex-Prime Minister”, and notes (but does endorse or reject) the US practice (which would be “ex–Prime Minister”). The recasting seems preferable for a nominal (as shown), and I don’t really have a problem with “former Prime Minister Gordon Brown”, though I might just as likely write “former–Prime Minister Gordon Brown”. Though I have a bit of an issue with “San Francisco-based company”, the caps do help (if not as much as in “ex-Prime Minister Brown”). I probably can also sort out “pre-World War II technologies”; here, I think the major issue is how many words an open compound can contain before it becomes unmanageable (and where, if at all, might we want a nonbreaking space. I think it’s a bigger issue without the caps, as in “pseudo-page transition” or “golf ball-sized brain”. With the latter, I can sort out what’s meant, but not without a double take; because the former is nor written in English anyway, it takes several double takes (but perhaps this would be true for any concept with which a reader is unfamiliar). In short, I think the dash vs. hyphen a fairly big deal when there are no caps.
:TCS does not seem to address the issue of open compounds, though they suggest an entirely different approach in some cases (e.g., {{xt|red colour-filter}} , apparently with the assumption that ''colour filter'' is a noun phrase).
:I agree that it′s sometimes a matter of eye rather than rote; for example, I would probably write {{xt|high school student}}, even though I’m unaware of a closed-up form of “school student” such as there is with “schoolteacher”. It may also be worth noting that some guides (e.g., APA and CMOS) do not use hyphens or dashes with ethnic identifiers (e.g., {{xt|African American Student}} rather than {{!xt|African-American student}}. But this is an issue for ] rather than here; I assume that we would prefer {{xt|African–American relations}} regardless of how the ethnic association is handled. ] (]) 05:59, 14 July 2011 (UTC)
:@Dicklyon: I've heard that using dashes in compounds which would normally use hyphens when one of the words has a space is uncommon in BrE. If that's the case, the fact that it “signal the structure more clearly” isn't enough to deprecate hyphens in this situation throughout en.wiki. For example, spelling the method of payment as ‹cheque› is clearer because it signals that you don't mean any of the other meanings of ''check'', but you don't want to recommend that in articles written in AmE. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 11:16, 15 July 2011 (UTC)
::It finds support in OSM (at 5.10.9), though the support is tepid at best. OSM does ''not'' endorse the hyphen as an alternative. As is discussed under ''What consensus means'', the Fowler brothers saw the problem with using hyphen as early as the beginning of the 19th century (and had no solution by 1931, either).
::One approach would be to permit either usage, possibly encouraging consistent use of either North American or British practice, though this could be tricky because some practices may be chiefly (but not exclusively) North American, and others may be chiefly (but not exclusively) British.
::I can’t say whether the fact that one construction may indicate the structure more clearly is sufficient to deprecate an alternative construction, but it seems to me that the point of en dashes in nearly all cases is to more clearly indicate what is meant than would a hyphen. So if it doesn’t matter here, it arguably doesn’t matter anywhere. ] (]) 22:39, 15 July 2011 (UTC)

Though Noetica and I seem to differ fairly strongly on what has been concluded with regard to spacing of range dashes, it should be clear that this is the only point in the draft on which we really differ. Though I’m not sure we really differ on the task that remains, we do appear to differ a bit on how this is to be done. I begin by looking at ]:

:In determining consensus, consider the quality of the arguments, the history of how they came about, the objections of those who disagree, and existing documentation in the project namespace. The quality of an argument is more important than whether it represents a minority or a majority view. The argument “I just don't like it”, and its counterpart “I just like it”, usually carry no weight whatsoever.

I don’t mean to dwell too much on the IDONTLIKEITs, but do maintain that given this framework, what RSs have to say is very much relevant in determining what may have been concluded. I agree that more people seem to prefer spacing; whether it’s a “clear majority” is more subjective, but there certainly is some significant opposition. Accordingly, I again turn to the quality issue, and suggest that given the great number of RSs that support closed-up usage, it does not seem reasonable to proscribe that practice. I do not recall a single source being cited as the basis for requiring the spaced usage, though Butcher may have been mentioned earlier in the discussion. I think it helpful to review what she has to say on the subject:
:En rules meaning ‘to’ and ‘and’ are usually unspaced: theocratic–military, chapters 11–9, 101–10. However, spaced en rules may be used between groups of numbers and words to avoid implying a closer relationship between the words or numbers next to the en rule than between each of these and the rest of its group:

::{|
|- |-
| {{xt|September{{nbsp}}2, 2001}}
|6.6–8||''but''||&emsp;6.6{{ndash}}7.8
| {{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. }} }}
|September–January||&emsp;||&emsp;18 September{{ndash}}19 January
|-
|1215–1260||&emsp;||&emsp;''c''. 1215{{ndash}}''c''. 1260
|} |}
::::::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}}


== Dyslexia font? ==
:But these spaced en rules should be used cautiously, especially if there are also parenthetical dashes, as the reader may not be able to tell one from the other; and it may be better to substitute ‘to’ in such cases.

Under “Parenthetical dashes”, she continues, “Spaced en rules are now most often used”, so it apparently is assumed that the parenthetical dash is indistinguishable from the spaced range dash.

Though I probably have more British style guides than the average Brit, I’m certainly not as familiar with them as I amd with the American guides. But of all the guides with which I am familiar, Butcher seems one of the most favorable to spacing range dashes. And the recommendation is far less than what’s current or proposed here. In particular, I simply do not see why a problem would arise with “Christmas Day–New Year’s Eve” when there is not a problem with “New York–Chicago flight”. In both examples, the dashes in both examples seem to me to be in the sense of ''to''. And isn’t the association addressed by using the en dash rather than a hyphen? If not, much of the rationale for using en dashes elsewhere would seem to break down.

A possible compromise would be to include wording similar to that above, perhaps adjusting the sense of the dashes to match whatever may be agreed to. Clearly it’s impossible to arrive at formulaic guidance on when association implied by the en dash might misleading, and the same is probably true for any possible confusion between range dashes and parenthetical dashes. Practically, the choice would be a matter of personal choice—British practice aside from OUP is apparently to prefer the spacing, while North American practice is usually to prefer closed-up usage. The case for spacing is probably strongest with full dates and with instances similar to the last example above. Even so, NA seem to prefer closed-up usage. The most common instance of full dates is arguably in obituaries, and unfortunately, they aren’t always much help. If my local newspapers are any guide, the copy editing is invariably done by the deceased. ] (]) 09:38, 15 July 2011 (UTC)

Though my main issue here is with {{xt|Christmas Day{{ndash}}New Year’s Eve}} (it’s really not different from {{xt|New York–London flight}}, and calling a range of dates is stretching things to the limit), I overlooked another: {{xt|28&nbsp;mm{{ndash}}17&nbsp;m}}. The en dash could initially be confused with a minus sign. There really is no ambiguity, just as there isn’t with closed-up dashes in most date forms (at least for North Americans), but the reader may need a double take to see what’s really meant. The implication of minus is far less with closed-up usage, but since there seems to be reasonable consensus against closed-up usage when both ends of a range of dates, times, or similar contain spaces, closed-up usage probably is not an option. It would be better to write {{xt|18&nbsp;mm to 17&nbsp;mm}}. This is consistent with CSE6:
:When expressing a range of numbers, use the word “to” or “through” to connect the numbers. Alternatively, an en dash, which means “to”, may be used but only between 2 numbers that are not interrupted by words, mathematic operators, or symbols to avoid confusion with the minus symbol.

This is stated somewhat better in the (which cites CSE). Perhaps Ms. Palin could in turn cite it in her debate with President Obama when mixing units in a range (“3 moose to 4 caribou”).

This usage really wasn’t put to a vote (and got little discussion there aside from A. di M.’s comment), which is perhaps why the potential confusion wasn’t noticed. Incidentally, I would replace {{xt|Obama–Palin debate}} with something else, because it quite likely will not happen, and consequently might confuse some readers. I’d return to {{xt|Lincoln–Douglas debates}}, the stature of which {{xt|Nixon–Kennedy debates}} cannot come close to matching. There is no potential confusion with a style if the plural is used. ] (]) 01:40, 16 July 2011 (UTC)
:Dunno, a sane person would typically write that as {{nowrap|{{xt|&minus;(17 m &minus; 28 mm)}}}} if that's what they mean. Also, in most cases it will be completely obvious from the context that you're looking at a range of positive numbers (so long as you don't use en dashes and minus signs in the ''same'' phrase, as in the red examples currently in the MOS). <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 12:13, 16 July 2011 (UTC)
::A slightly different issue, I think. The spaced en dash in most cases is not obviously different from a minus sign, and the first-impression interpretation of a spaced minus is subtraction, in this case “28&nbsp;mm minus 17&nbsp;m”. The context will usually prevent ambiguity (I don’t think we normally add or subtract wavelengths), but comprehension may require slight additional processing—the first impression I have is that of an operation involving units of length, which is plausible. The claim of real ambiguity is in most cases nonsense; no one is likely to mis-associate the numbers and words in something like “24&nbsp;June–17&nbsp;July”, though again, perhaps a brief rescan may be needed. One could also maintain that “3&nbsp;June 1970{{ndash}}9&nbsp;September 1971” is potentially ambiguous because of implied subtraction “{{nowrap|1970 − 9}}”, but at least for me, that first impression is less likely because I don’t normally think of subtracting dates. To me, the most jarring unspaced construction of dates would be something like “3 June 1970–9 September 1971”; the first thing I see is “1970–9″, which could mean “1970–1979”. Again, I quickly sort it out, but would prefer not to need to do so.
::Incidentally, spacing en dash in dates in at least one construction introduces genuine ambiguity. Consider “18&nbsp;July{{ndash}}3&nbsp;September 2012” does this mean “18&nbsp;July 2012 through 3&nbsp;September 2012” (the dates of the Obama–Palin debates) or “18&nbsp;July 2011 through 3&nbsp;September 2012” (the time between now and when these debates are behind us)? Without the spacing (“18&nbsp;July–3&nbsp;September 2012”) the close association of the months strongly suggests the former meaning. Though it’s hardly possible to definitively conclude that North American practice is “better” or “worse” than that elsewhere, I think it’s worth noting that with the former, there is little chance of confusion among the em dash, unspaced en dash, and (spaced) minus. ] (]) 07:19, 18 July 2011 (UTC)

:I definitely agree that the example {{xt|Obama–Palin debate}} is unacceptable. And use {{xt|the Lincoln–Douglas debates}} to clarify that you don't mean some generic Lincoln–Douglas debates. ] (]) 04:51, 18 July 2011 (UTC)

=== What consensus means ===
Consensus does not mean "a clear majority"; if we ran by majority vote, we would say so. Please see ] for how we do run; we do not use the proper meaning of ''consensus'' as "unanimous consent", which frequently causes difficulties over international treaties, whem a handful of states decline to join an overwhelming majority. (For more on this, see ], and others.)

Even on Misplaced Pages, "he goal of a consensus discussion is to reach an agreement about page content, one which may not satisfy anyone completely but which all editors involved recognize as a reasonable exposition of the topic."

This is not a reasonable exposition; a third of us object to ''requiring'' {{!xt|ex–prime minister}}, ranging from those like me that would permit it, to those who would recommend against it. There is also strong sentiment against {{!xt|the anti-conscription–pro-conscription debate}}; the weakly supported (but unopposed) recommendation of stronger language to avoid all such forms is omitted. ] <small>]</small> 16:45, 13 July 2011 (UTC)

::Which is why I keep harping on the idea of phrasing things as "preferences". When there is disagreement among Wikipedians over a style issue ... (and a third objecting is definitely a "disagreement") we should not impose the majority view... instead we should present the options, indicate that all are "allowed"... however, we can ''then'' note that one style is ''preferred'' (to put this another way... a "preference" can be determined by a majority vote, a "rule" needs clear and solid consensus). ] (]) 17:02, 13 July 2011 (UTC)
:::Would you care to do a draft? ] <small>]</small> 17:43, 13 July 2011 (UTC)
::::Actually, no... I have never pretended to fully understand the specifics of the endash vs emdash vs a hyphen debates (hell, I am still not sure I completely understand what the difference between them ''is''). Because of this, I am not really focused on ''what'' the MOS should say, but rather on ''how'' the MOS should say it.
::::I have been trying to find ways to break the "my way or the highway" deadlocks that those of you who ''do'' understand the nuances of dashes and hyphens keep getting into. Looking at the AfD, it is clear (even without fully understanding what is being discussed) that, on some points, almost everyone agreed. I think that consensus would justify presenting these items in terms of being accepted "rules"... conceptually telling readers: "this is how it should be done". However, it is also clear that on other points there was significant disagreement. I think that lack of consensus indicates presenting these points in terms of "preference"... conceptually telling the reader: "here are the options... all are allowed, but we prefer X". ] (]) 20:05, 13 July 2011 (UTC)
:::::I'll see what I can do in 24 hours. ] <small>]</small> 20:24, 13 July 2011 (UTC)

The claimed majority is not merely not consesuus, but false. The discussion or {{!xt|ex–prime minister}} is at ]; section 5b. At most 10 support requiring the dash, and of those Jeff, Tony, Kotniski, and MacWhiz are doubtful; 14 (including Ozob) would make it optional or deprecate it. ] <small>]</small> 23:53, 13 July 2011 (UTC)

:To clarify my position on the use in compounds: as Fowler notes (TKE, under HYPHEN)
::It is good English usage to place a noun or other non-adjectival part of speech before a noun, printing it as a separate word, and to regard it as serving the purpose of an adjective by virtue of its position {{nowrap|. . .}}

:He then proceeds to review the problems that arise with compound modifiers (mentioning his whimsical {{xt|Anglo-SouthAmericans}} that he realizes is doomed before even being proposed). I think the en dash is a much better solution, but it can only correct so much of a mess—there is some practical limit to the number of these non-adjectival parts of speech that can reasonably be employed. But like consensus, I don’t think it’s strictly a numbers game. I would prefer recasting {{xt|quasi-legislative–quasi-judicial}} to {{xt|quasi-legislative, quasi-judicial}}, partly because of its length, but also because nothing is lost in recasting—in fact, I think quite the opposite obtains.

:With {{xt|the anti-conscription–pro-conscription debate}}, the choice is not so obvious, and as it stands may well be the least of evils. An option might be {{xt|volunteerism—conscription debate}}, but this is somewhat less clear because the nouns are different (I had to think about the meaning for a moment). I think the main reason for my tepid support is that it’s less easy for me to quickly distinguish en dashes from hyphens than to distinguish en dashes from spaces. But perhaps this is just a personal quirk.

:As for the prescriptivism–descriptivism debate, it should be clear that I lean toward the former (especially for en dashes), but recognize that when ''well-established'' alternatives exist (especially when they reflect ENGVAR or its equivalent), I might allow any of them, possibly preferring one, if that alternative would normally reduce ambiguity. Like Blueboar, I might prescribe (or at least strongly recommend an approach if it’s one on which we clearly agree (e.g., parenthetical dashes and en dashes in ranges of numbers), especially when that practice finds nearly universal acceptance outside of WP. One always must be careful about claims of universality, of course; some guides (SP 811) deprecate range dashes for numbers in technical contexts, and some organizations (ASTM) proscribe them. In some cases (unspaced em dashes vs. spaced en dashes), an expressed preference would clearly not find any traction, and probably should not. And finding a justification other than ] would be almost impossible. One thing I certainly would not do without a mighty good reason is proscribe a common practice (e.g., closed-up use of range dashes) that finds broad support in the guides—it is difficult for me to see doing so as other than utterly capricious. The more such provisions we include, the more likely are editors to ignore the MOS (assuming they don’t already). ] (]) 09:13, 14 July 2011 (UTC)
:::Thank you for reminding me of TKE, although I would ascribe it to both Fowlers. The is available on line, and it is more concise that MEU in saying that there are only three forms of composition (closed up; spaced; hyphenated) and that the only call for a fourth is ''Anglo-South-Americans'', where there is are different ''levels'' of composition. They recommend, as we should, {{xt|Warsaw and Brest-Litovsk railway line}} instead of playing with hierarchy. ] <small>]</small> 02:19, 15 July 2011 (UTC)
::::Indeed, that 1908 Fowler's "King's English" predates any guides that I am aware of that talk about en dash usage. And it recommends things like "Covert-Garden-Market salesman" that modern guides eschew; the insertion of hyphens into compounds used as adjectives is deprecated when the compounds are proper names (not "Golden-Gate Bridge", but just "Golden Gate Bridge"). ] (]) 02:31, 15 July 2011 (UTC)
:::::::Yes, the Fowlers call a hyphen a regrettable necessity; more were necessary in 1908 than are now (and more seem to have been necessary in Oxford than in San Francisco, even then); a compounding dash is equally regrettable and much less necessary. ] <small>]</small> 02:44, 15 July 2011 (UTC)
:::::I have the 3rd ed. (1931), which ponders {{xt|Anglo-SouthAmericans}}—progress of sorts, I suppose. Though it was completed after F.W.’s death, much of the content obviously derives from his efforts. As many have correctly observed, the Fowlers were fighting some battles that have long since been resolved. But it remains a valuable work, even one makes it only through the five principles that being Chapter 1. Unfortunately, even in the 3rd ed., TKE is of no help on en dashes—I mentioned it simply to show that the Fowlers were well aware of the problem. That we′re still having difficulty finding consensus on some issues suggests that even with dashes, the problem remains vexing.
:::::As regards {{xt|Warsaw and Brest-Litovski railway line}}: for a reference to the railway, this works. But a {{xt|Warsaw and Brest-Litovski trip}} works less well, and clearly, {{xt|Warsaw-Brest-Litovski trip}} does not work at all. What the Fowlers did not propose was {{xt|Warsaw–Brest-Litovski trip}}, which seems to me to do the job. I concede that this usage wasn’t as enthusiastically embraced as some of the others, and it’s not the prettiest construction, but what are the alternatives? I suppose we could resolve it the way a mathematician would resolve default operator by using parentheses, as I have done in a few examples—namely {{xt|Warsaw-(Brest-Litovski) trip}}. I somehow don’t see this getting very far. ] (]) 06:56, 15 July 2011 (UTC)
::::::The proper rewriting of {{!xt|Warsaw–Brest-Litovsk trip}} is {{xt|trip from Warsaw to Brest-Litovsk}}, which offers no problem.

::::::As a minor detail, the press report the Fowlers are criticizing seems to have confused the name of the latter city with its adjective; ''if'' we use this example, we should amend it.

::::::But this presents another reason ''not'' to use such compounds where they can be avoided; they are inherently vague. ] <small>]</small> 18:35, 15 July 2011 (UTC)
:::::::If one is willing to forgo the adjectival usage, then of course this rewrite works. And it may be just as good. But were it unquestionably the “proper” rewrite, the Fowlers would probably not have bothered trying to deal with the adjectival form.
:::::::I guess the vagueness is in the eye of the beholder—I see no ambiguity in the form with the en dash, though I agree with many who though recasting may often be better. But in some contexts, recasting may not be practical, so it’s nice to have a way of handling the adjectival form. ] (]) 22:06, 15 July 2011 (UTC)
::::::::::The dash in {{xt|Warsaw–Brest-Litovsk}} can mean several things, depending on context; the Fowlers dealt with a case where it did mean ''and''; they recommended (as the surviving Fowler continued to recommend) abandoning the effort to pack it into a single adjective. Where's the profit in it?
:::::::::::But the fact that the dash can mean almost anything means it is inherently vague. Sometimes the ambiguity is settled by context; sometimes it isn't. ] <small>]</small> 23:18, 15 July 2011 (UTC)

:Here's something that's just occurred to me. For prescriptivism vs. descriptivism, if prescriptive points must be supported by reputable sources, such as style guides, then descriptive points must be supported by sources of similar reliability, such as sociolinguistic studies. (Come to think of it, many of the style guides cited as prescriptive have passages that describe actual use, so perhaps they'd be usable for both.) Personal observations of "what people do" should be dismissed as OR unless also so supported.

:And Noetica is a dude. He says so on his talk page or at least he did when I made a two-second pronoun check three years ago. It's not the most relevant of issues, but can we stop asking about it now? ] (]) 02:49, 15 July 2011 (UTC)
::I would happily defer to "sociolinguistic studies" if that means a controlled experiment to determine whether typical readers, not just punctuation mavens, understand material more quickly when dash rule number 89-4C-6 (f) is followed. But only if such studies exist. ] (]) 04:16, 15 July 2011 (UTC)

::Darkfrog, I largely agree. I clearly lean toward style guides, more out of practicality than ideology. It’s usually a fairly deterministic process to find (and perhaps cite) what Guide A&nbsp;recommends. There is of course the problem that Guide&nbsp;B may recommend something different, but at least is also fairly straightforward to find the differences and decide to prefer one or just allow both if A and B are widely respected. We can always argue whether a given guide is “widely respected”, but most of the guides provide help by listing most of the other major guides in bibliographies. Now perhaps this is all just a vast conspiracy, but the guides listed by the other guides seem to correspond well to measures such as ASR (Amazon sales rank). Perhaps this is a sort of descriptive prescriptivism.
::The alternative is far less straightforward. As Art indicated, a study relevant to a particular issue would need to exist, be discovered, discussed, possibly interpreted as to how well it relates to the issue at hand and as to what it actually concludes, as opposed to differing ]s. This seems to me a tall order, and arriving at a conclusion could make the discussion on dashes seem brief and trivial by comparison.
::That’s why I look to the guides—though this may not be a perfect solution, it seems simpler, faster, and less subjective than the alternative. ] (]) 07:20, 15 July 2011 (UTC)
:::So do I; most guides do not recommend most of this, and the exceptions have low ASR. ] (]) 22:13, 15 July 2011 (UTC)]
::::I guess we’d need to focus on specifics, but between APA and CMOS, most seem to be covered. And in the UK, NHR has reasonably high ASR. ] (]) 22:13, 15 July 2011 (UTC)


Is there any font available in wikipedia that can be called by CSS such as:
===Procedural subsection===
* ]
* ]
] (]) 06:52, 15 November 2024 (UTC)
:See ]. Personally I didn't find that it helped, but good luck.&nbsp;]&#124;] 20:37, 15 November 2024 (UTC)
::] seems outdated. I do not see 'Fonts' in preferences. ] (]) 01:21, 16 November 2024 (UTC)
:::Yep, that's out of date. I've raised the question on that talk page. Anybody else got ideas? If not here, perhaps ] has ideas.&nbsp;]&#124;] 02:43, 16 November 2024 (UTC)
::::{{replyto|Uwappa|SchreiberBike}} It's not in preferences, and as far as I know (my records go back to about 2010), it never has been. It's a configuration setting that is independent of preferences: as the ] page {{oldid|Misplaced Pages:Dyslexic readers|722482493|formerly said}} (I don't understand why {{user|This, that and the other}} {{diff|Misplaced Pages:Dyslexic readers|prev|722482530|removed it}}), it's done through the cogwheel next to the word "Languages". This is in the expected position in the left sidebar for four of the installed skins - Modern, MonoBook, Timeless and Vector legacy (2010). For three other skins, it's different:
::::*For Colugne Blue (which not many people still use), the setting may exist but I can't find it
::::*For MinervaNeue (i.e. most mobile users) there is no setting
::::*For Vector 2022, it's there but is more difficult to find (as are many other things): you need to look just above the "Read / Edit / View history" tabs, where you should find a box that shows a strange Asian character, a number, the word "languages" and a down arrow. Click that down arrow, and the cogwheel is revealed after "+ Add languages" at the bottom right of the dropdown.
::::Having located the cogwheel, click it and then proceed as per WP:DYX instructions 2 through 6 inclusive. --] &#x1f339; (]) 11:18, 16 November 2024 (UTC)
:::::Found it and successfully set the font to OpenDyslexic.
:::::That is eh... well hidden. ] (]) 13:52, 16 November 2024 (UTC)
::::::I {{diff|Misplaced Pages:Dyslexic readers|prev|1257778856|amended}} the WP:DYX page. --] &#x1f339; (]) 16:27, 16 November 2024 (UTC)
:::::::A video or animated gif of the process would probably be welcome. ] (]) 00:57, 25 November 2024 (UTC)
{{od}} {{od}}
¿There is still only halting progress because there’s complaining about what “consensus” means? The need to dwell on this point on Misplaced Pages is typically borne out of a minority side’s disputing that a consensus exists. Believe me—I know. I was exposed to a metric butt-load of Iranian-centrifuged, weapons-grade bullonium with complaints about how “ over date de-linking and deprecating routine use of the IEC computer prefixes like “kibibytes”. In the end, the hold-outs lost because fighting against the consensus view What we need is the following:


<s>The whole process should be simpler:
# All parties stipulate that '']'' discloses all that is known and needs to be known about the subject.
# My preference: OpenDyslexic is the default font for Misplaced Pages. Yes, that is all pages for everybody. Wikipedians can opt for another font in preferences. IP users have no choice. This will benefit the large majority of dyslexics that are not wikipedians.
# Establish a clear consensus.
# Wikipedians can opt in for Dyslexic font in preferences. No solution for the vast vast majority of IP dyslexics.
# Find an who has
# For happy few, the current solution: install dyslexic font on own device, create your own CSS. That will benefit the very few dyslexics that are Wikipedians, know how to install a font and 'speak' CSS.</s>
# Have said admin rule on the consensus (win, lose, no consensus for the change).
] (]) 04:54, 16 November 2024 (UTC)
# with the holdout who has been giving you grief.


:@] you will notice that you can actually click the cogwheel in numbered list item 1 on ] itself - no need to go locating anything! ] (]) 06:42, 18 November 2024 (UTC)
] (]) 22:39, 14 July 2011 (UTC)
:{{ping|Uwappa}} To take your numbered points in not their original order: 2) That's already the case, except "no solution for ... IP dyslexics" isn't really true; the "cog-wheel" menu discussed above is available to logged-out users. The problem is that it's hard to find. 3) This is additionally already the case. Anyone can install that font, system-wide, and have their browser impose it universally. This takes a smidgin of technical figuring-out, but anyone dyslexic who finds that font helpful has it in their best interests to figure that out, because really close to zero sites on the entire Web are going to be doing what they'd like done, so it will have to be done by local and overriding personal imposition. 1) As someone who's mildly dyslexic, I have to say I detest the OpenDyslexic font, and the earlier ones it's based on, as general reading fonts. As a decorative display font for things like flyers, OpenDyslexic is a nifty neo-] font, and I've actually used it before with that aesthetic in mind. But for general reading, I think I'd rather just gouge my own eyes out. I don't find it helpful in the least, and at smaller than heading sizes, it slows my reading pace by about 50%. Not everyone's ability issues are identical, even if they fall within the same general/overgeneralized classification. So, the idea of imposing this font on everyone by default is a non-starter; it'd be like requiring everyone to wear a hearing aid (turned up loud at that) even if their hearing is acute. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 12:34, 21 November 2024 (UTC)
:The funny thing about consensus though is that it doesn't actually require anyone to "rule" on anything, "huevos" or not. Regardless... there ''is'' a well trod path through Misplaced Pages's dispute resolution process, what there is of it, which does utilize "finding an 'uninvolved' admin with 'huevos'" in order to adjudicate a ruling. I guess that it's just a pet peeve of mine that people refer to that (mistakenly) as "consensus", but... meh.<br/>—&nbsp;] <span style="font-variant:small-caps">(]&thinsp;&bull;&thinsp;])</span> 01:49, 15 July 2011 (UTC)
::Your option 3 is nice, let the browser take care of it, across all websites. Yes, that will suit dyslectics fine and won't have any impact for the rest of us. Simple, working, excellent! Thank you!
::The sign of having achieved consensus is that you don't need an admin, nor huevos; nobody objects. That's what ] says; who objects to it?
::I am not dyslectic myself, so I can not judge the font benefits. The design idea makes sense to me, make sure characters do not look identical when 'flipped' in the mind. ] (]) 16:17, 21 November 2024 (UTC)
:::That only works for a particular sort of dyslexia, prone to vertical flipping. I'm glad such a font works for those who experience that. For some of us, it's more of a "swimming letters" effect that slows reading and causes a lot of mistaken first readings, e.g. seeing "exist" as "exits" or vice versa (though for me it's much more of an issue with numeric input). Also impedes visual scanning for typos, which has a lot to do with my higher-than-average rate of those. I sometimes re-re-re-read something before hitting "Publish changes" and there will still be an "obvious" typo in it. There's probably also horizontal flipping, like difficulty with E vs. 3, J vs. L, etc., but it's not something I've studied (and not something that affects me). I've heard of another sort that involves whole-word transposition, and that would drive me bonkers. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 14:28, 24 November 2024 (UTC)
::::I tried that OpenDyslexic font. It makes pages more difficult to read than the default Arial font. --] &#x1f339; (]) 14:34, 24 November 2024 (UTC)
:::I've tried the open dyslexia font. It is OK for me and I do understand how it counters both vertical an horizontal character-flipping.
:::For me the default Arial font is easier to read, but I am not dyslexic.
:::I do like the suggestion to solve it in the browser. Let dyslexic people use a special font, not just on Misplaced Pages, but on all websites.
:::* That will be great for dyslexic people.
:::* While the rest of use are happy with the standard font.
:::] (]) 14:36, 25 November 2024 (UTC)


== Retain or remove citation indicators in quoted text? ==
::Shouldn't this thread be under Procedure, the next section down? ] <small>]</small> 02:07, 15 July 2011 (UTC)
:::Note, I said thread, not section; I have made it a subsection. ] <small>]</small> 02:41, 15 July 2011 (UTC)


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)
====What consensus means====


: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)
In , we were instructed "The discussion should be of sufficient structure to allow easy quantification of consensus rather than a large amount of poorly-framed debate." Casliber structured the discussion to make it easy to quantify agreements and disagreements with the various detailed provisions of the dash section. The result was that most sections had overwhelming support and agreement, but there were also a few less certain provisions and some constructive ideas for improvements. People who offered ideas and disagreements should check what they said, compare what ended up in Noetica's draft (the only currently active proposal, I think, since it has been largely accepted as an improvement on Kotniski's), and see if they're happy with it, and speak up one way or the other, so we can get the consensus finalized.
::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 ==
Jeff Conrad and I and a few others have weighed in above. I pretty much agree with Jeff that spaces around connective en dashes are rare (esp. in AmE), so I'm glad that the new draft backed off some from what the old one said. And I'm OK with the present compromise ("always unspaced, except for times and dates (or similar cases) when the components already include at least one space") as being motivated by the , even if it's hard to see exactly how far it should be changed from the votes at hand (PMAnderson is correct that the voting did not address this question, and the expressed disagreements leave a range of possible changes, of which Noetica's is somewhere in the middle); tweaking it can be left for a later round. At this point, I think minimal changes from the stable version, as motivated by a great discussion with wide participation, plus better clarifying examples, is what we can call consensus based on the discussion. Going further will require more work and more discussion to get to a consensus to do more, unless someone soon suggests specific changes that get little pushback. I made a few suggestions myself, but am content to let them slide to a later discussion, or forever. Let's get this done. Am I right? Or do we have to discuss a lot more first? Jeff? A. di M.? Kotniski? Tony? Anyone else who wants to comment on the new draft? ] (]) 04:45, 18 July 2011 (UTC)


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.
=== Discussion of procedure ===
:I know probably no-one will like it, but here's my idea:
:*From Day&nbsp;1 to Day&nbsp;7, whoever can be bothered to shall review all recent discussion about this topic, write a draft in their own userspace reflecting the consensus as well as they can, review and comment other people's drafts, and tweak their own draft addressing other people's comments.
:*By the end of Day&nbsp;7, I guess there will be a few such drafts (probably less than half a dozen); the drafts shall be locked down, and a new subpage shall be created where as many people as possible (through ], ], ], ], ], maybe ], ], ], ], and possibly a watchlist-notice) shall be asked to review the drafts and sort them in order of preference, from Day&nbsp;8 to Day&nbsp;14.
:*At the end of Day&nbsp;14, the ‘ballot’ page shall be locked down and the preferences evaluated according to the ] or similar. The ‘winning’ draft shall then be copied and pasted, ''verbatim'', replacing the entire current Section&nbsp;8.9 “Dashes” of WP:MOS.
:*After that, tweaks to the guideline can be discussed and implemented through the normal ] mechanism for protected pages.
:(Of course, the better a drafter is at reflecting the community consensus, the more likely their draft is to win.)
:<span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 16:16, 13 July 2011 (UTC)
::The Schulze method is contrary to our stated goals: to select the policy which as many people as possible can tolerate. ] <small>]</small> 16:28, 13 July 2011 (UTC)


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.
:I have been reviewing Noetica's draft, with respect to how well it incorporates fixes to all the disagreements that came up in the extensive discussions; I intend to recommend a few tweaks, but I think things would get out of control if I tried to make my own competing version; I don't think you'd find many editors with the patience to dig into differences and rank them at this point. But if someone thinks it is far enough off-base that they want to do a whole new one, I guess we'll look at that, too. As Noetica suggests, some notice of such an intention would help us keep our work in order. Sounds like there's some sentiment for a more "watered down" version from a few editors. ] (]) 18:43, 13 July 2011 (UTC)
:Only a few editors have commented on any draft.... ] <small>]</small> 18:54, 13 July 2011 (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)
Refactoring remains unacceptable; if Noetica repeats it, he or she (I don't know whicn) may explain that action elsewhere. ] <small>]</small> 23:53, 13 July 2011 (UTC)
=== Removed discussion (see preliminaries, above) ===


:Sounds Latin enough to me. ] (]) 11:52, 26 November 2024 (UTC)
We now have an edit war over whether "What consensus means" should have === or ====. Would === <small><small>=</small></small> be an acceptable compromise? Another hot issue is Noetica's gender. See the top of his user talk page. And break your eggs on the '''big end only!''' ] (]) 00:38, 14 July 2011 (UTC)
:<chuckle> Fine; I was taught that gender should not matter; but Noetica was fiercely inovolved with the gneder-specific language movement. So rather than guess, I was non-specific.


::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)
:What I object to, however, is having my comment refactorsd. That's obnoxious, and we have politcy against it. ] <small>]</small> 00:47, 14 July 2011 (UTC)
::You presumably meant to say that only ''some'' comments should be refactored according to ] (whether this is one of those times is an issue that you and Noetica can surely debate for weeks.) ] (]) 01:17, 14 July 2011 (UTC)
:::No, I have never had a productive debate with Noetica (a neuter plural where I come from); I'd take him to ANI first. He does not have my consent. ] <small>]</small> 01:22, 14 July 2011 (UTC)
::<small>I did mis-guess Noetica's gender; this may (or may not) have to do with the fact that in my native language nouns such as ''{{lang|it|matematica}}'' are feminine singulars. (But then, where I am from Andrea and Nicola are men's names, so I shouldn't use that as an excuse.) :-) <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 14:45, 14 July 2011 (UTC)</small>
:::<small>WTF, nearly two days and neither of you guys has commented on whether it makes sense to call a girl Andrea given its etymology... :-) <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 12:13, 16 July 2011 (UTC)</small>
PMAnderson, you write: "Noetica was fiercely inovolved with the gneder-specific language movement ." That is a coloured characterisation ("fiercely") of an involvement that I have no recollection of. Please retract it. Your irrelevant asides focusing on me are a distraction. You have failed to retract all your pointed innuendos. Please remedy that. And striking out text will not be enough; I would like to participate in the important discussion above without attacks and provocations, whether they linger in the text or are perpetuated in edit summaries. I'm confident that other editors would take this to be a perfectly reasonable request. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 03:07, 17 July 2011 (UTC)
:I'm more inclined to assume good faith this time. I said "Another hot issue is Noetica's gender." That implied accusation entitles Septentrionalis to explain his half of that distraction. If, and only if, "Noetica was fiercely involved with the gender-specific language movement" is true, and if he has never been told Noetica's gender (although I've seen it repeatedly over the years by clicking Noetica's user name), then that is his explanation. Perhaps the most "inflammatory" comment above is my own: "... an issue that you and Noetica can surely debate for weeks", but somehow people seldom aim their best insults at me, on this page or any other battleground page. ] (]) 06:13, 17 July 2011 (UTC)
::Art, I admire your trust. But if you were as familiar with the relevant history as I am, that trust would melt away. PMAnderson knows exactly what he's doing. From one point of view, all of this is trivial. From another, it is of prime importance that we observe civility and work harmoniously. ArbCom has made the point explicitly. From the injunction under which we are currently working:
::<blockquote>All discussions on the subject of En dashes in article titles discussion (interpreted broadly) are subject to civility and 1RR restrictions. Administrators are urged to be proactive in monitoring and assertive in keeping debate civil.</blockquote>
::When PMAnderson acts and posts as he has, that is uncivil. When PMAnderson makes an edit summary that accuses me of "positive falsehood", that is uncivil; in fact, what he referred to in that summary represented merely a different take on certain voting, aided by a careless and slanted reading of what I had earlier said. You must know that I can look after myself in a street-fight, and have all sorts of tricks at my disposal if I choose to answer an assault with humour, incisive point-scoring, or ridicule. But the present matter is too serious for that. On the other hand, if people want to vary the framework and the suggestions I have made for the civil conduct of the discussion, sure: we could loosen up. Then we could have some ''real'' fun and fireworks. I'd rather we not do that; and I ask again that I be treated civilly (as the ''proposer'' of this move toward a resolution, with all of the difficult drafting that preceded it), as I treat others civilly also. I am keen to resume my involvement in the discussion; I'm waiting for conditions to be as ArbCom has said they should be.
::<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 06:47, 17 July 2011 (UTC)
:::Your sentence about "accuses me of 'positive falsehood{{'"}} is a legitimate complaint to the extent you explained it. But for those of us less able to comprehend the "relevant history" and all the "tricks at disposal", you often seem to take offense at a long list of trivialities most of us wouldn't mention. In that case, emphasizing the need for civility counts against you. ] (]) 15:45, 17 July 2011 (UTC)
::::So my insistence on the need for civility, which was also especially highlighted in an active ArbCom injunction, "counts against me"? I note your opinion, Art; others will agree with you, and others have agreed with me already. If I were to give the history that led us to this point, and has wasted weeks if not months of real time in people's real lives, you might find that uncivil of me. Hmmm. I say it would reveal incivility elsewhere; and it would reveal gross and sustained disruption to prove a point. I do not ''want'' to dwell on history, as I made clear in starting this whole section. Nor do I want to use kick-boxing techniques against unfair attacks. I can, but will not.
::::I am still waiting for a positive move toward respect and due process. Others may want to see the last several weeks' work dissipated; I do not.
::::<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 22:21, 17 July 2011 (UTC)
::::::Civility complaints are the last refuge of those with no case on the merits. ] <small>]</small> 23:15, 17 July 2011 (UTC)
::::::I expected my carefully hedged suggestion that "you often seem to take offense at a long list of trivialities" might get an angry outburst, although that suggestion was a natural response to a demand for civility. But instead I got an objection to the hint that such an offense-taking tendency is in itself a kind of incivility, thus aggravated by demanding civility of others. Oh well. Finish the dash draft? ] (]) 00:27, 18 July 2011 (UTC)
:::::::No need to hedge anything with me, Art. If you want to accuse me of incivility, do so directly so that we can settle things briskly and move on. You say: "instead I got an objection to the hint that such an offense-taking tendency is in itself a kind of incivility." But I was not hedging anything, and I did not mean or wish to hint anything beyond what I said: "I note your opinion, Art; others will agree with you, and others have agreed with me already." I want to avoid innuendos. Let's all do that. And let's be definite about all the issues here. Since my last post here, PMAnderson has come in with the gratuitous suggestion that in calling for ArbCom's injunction to be respected and enforced (for civility), I show that I have "no case on the merits". That would be laughable, if this were at all a laughing matter. I could respond in the same vein, and we would all get nowhere.
:::::::I have nothing to apologise for. Others ''do'' have something to backtrack on, and I am still waiting for the air to be cleared so we can continue our work without threats, arch attacks, or wanton misrepresentations.
:::::::<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 00:52, 18 July 2011 (UTC)
::::::::I see no hope of re-explaining the re-explanation, so I'm giving up. ] (]) 01:17, 18 July 2011 (UTC)
:::::::::Art: If you take a little time away and then give the content of this section a detached reading, you may come to understand why I too have a feeling of the futility of it all. Then again, you may not. It's your call.
:::::::::For my part, I am not giving up. Still just waiting. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 01:56, 18 July 2011 (UTC)


== Stale advice: slashes have been line-breaks since 2005 (Unicode 4.1.0) ==
=== Summary; final request to complete discussion; and notice of a final draft ===


{{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."
'''ArbCom's deadline (16 July) has passed. The only task now is to finalise a draft for the dash guidelines.''' Since it is imperative to conclude things in a collegial way and to bring this protracted matter to an end, I am setting aside my concerns over civility. I simply call once more for good will, restraint, and focus on the task as we wrap things up.


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 .
'''I propose to post a final draft, 24 hours from now.''' Someone has to, and since I have become intimately familiar with the task and its details, I propose to do this myself. I continue, of course, to suppress my own personal preferences in style; I hope that others will do the same.


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)
'''Below is a summary of editors' points about the present draft, with provision for brief discussion.''' I really hope that editors will not prolong discussion unreasonably. There will be opportunities in future, to revisit ''any'' guideline. Simple, short statements like "'''Agree'''", or "'''I can live with that for now'''", would be extremely helpful at this stage. '''This is not the place for deep analysis, generalities, politics, or digressions.''' Please keep comments neat and suitably indented, and do not start or continue lengthy exchanges. I will consider everything in this new final stage of discussion, as I prepare a final draft. Again, someone has to.&nbsp;<big>☺</big>


: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)
<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 03:06, 19 July 2011 (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 '']'', 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.
=====1. Length=====


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?
Tony and A di M have taken up the matter of length that I raised. (I had written: "Editors will suggest ways to shorten it; but the voting has shown how easily brevity leads to entirely wrong interpretations. We need to guard also against intentional misconstrual.)" No one has suggested what might be taken out. A di M wrote: "I'm not sure exactly what words are the culprit, but I'm under the impression that Kotniski's version manages to say pretty much the same things more concisely and no less clearly." (I set aside the question of Kotniski's draft; I am among those who have thanked him for that effort; but the newer draft takes things further than his did.) It seems to me that if this were so, editors ''could'' find ways to trim the present draft. Let's have short, definite suggestions now, if anything is redundant and unhelpful in the draft.


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)
;Brief discussion
* '''Agree''' Fine, brevity. No brainer. ] (]) 05:37, 19 July 2011 (UTC)
*'''Agree'''. Having read through it again, I'm impressed with the logic and efficiency of the examples. I learned from them, and other editors who want to should find them helpful and instructive. Editors who don't want to read them? Fine, others will be happy to fix. ] ] 12:34, 19 July 2011 (UTC)
* '''Agree''' – The length is OK; lots of examples good; more examples not really needed; no problem if you make minor adjustments one way or the other. ] (]) 14:58, 19 July 2011 (UTC)
*'''Disagree''' The length is excessive. Kotniski's draft is much shorter, and could be shortened further - yet it covers more ground. ] <small>]</small> 18:07, 19 July 2011 (UTC)
* '''Agree''' if that means the current length is OK. Brevity that results in ambiguity is of little benefit. As I discuss under ''Spacing in ranges'', I erred in providing far too few examples, including one that eluded me until this afternoon when I actually had to use it. The proposal concentrates more on examples than abstract descriptions, which is as it should be. ] (]) 04:29, 20 July 2011 (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)
;Response in the final draft
* No specific actions were called for. I added a couple ''more'' examples, to satisfy other requests below. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)


==Input needed on disagreement over where the lifespan goes in relation to a baronetcy or a peerage title==
=====2. Content and layout of examples=====
] 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:
'''A.''' Jeff Conrad commented: "The order of the recommended/not recommended practice in the examples should match that in the text that precedes it." I argued that this was not essential, thinking that the order among examples (wrong version, then right version) trumped other considerations. It's hard to meet both requirements and maintain clarity.
:''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:
;Brief discussion
John Doe, 1st Baron Doe, (1 January 1801 – 31 December 1881), was a Whig politician ...
* '''Agree''' Seems to be sensibly laid out. ] (]) 05:37, 19 July 2011 (UTC)
*'''Agree''', although I see Jeff's point. ] ] 12:34, 19 July 2011 (UTC)
* '''Agree''' – the order is OK, and it would be hard to make it as consistent as Jeff suggests. ] (]) 14:58, 19 July 2011 (UTC)
*A matter of rhetorical choices at each juncture; if the examples are clear without being made into a French garden, who cares? ] <small>]</small> 18:07, 19 July 2011 (UTC)
* '''Comment''' Recall that my suggestion was only that specific examples match the order of the text that describes them; It’s not a killer issue, but it would make it a bit easier on the reader. I see no need for overall consistence.
* '''Comment''' Unless there is good reason to do otherwise, I would like to see the examples show adjectival usage, because these are the more challenging usages. I give the example of {{xt|the 20&nbsp;kHz–20Hz&nbsp; propagation delay}}, which fooled me until I just had to use it.
* '''Comment''' I would like to see all examples of ranges of dates (and perhaps of physical quantities with appended units) include nonbreaking spaces where appropriate, as called for in ] (e.g., between date numbers and month names, as in <code>1790&amp;nbsp;&amp;ndash; 1&amp;nbsp;December</code>); new editors often learn by looking at the code. ] (]) 04:51, 20 July 2011 (UTC)


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.
;Response in the final draft
* I have managed to satisfy Jeff's request regarding the order of texts and examples.
* Several examples already show adjectival use; I have added two more, if we include {{xt|ex–prime minister Thatcher}} (Jeff accepts that as adjectival below, but I don't). It is important to show ''non''-adjectival uses also; they can be trickier in their way. This suggestion would have been better made during the last week, while the now superseded draft was on the table.
* It was discussed earlier that the issue of hard spaces would be removed, for enhanced general treatment elsewhere in MOS. Again, it is awkward to have to revisit this issue at the last minute (beyond my 24-hour period of notice, and four days after ArbCom's deadline). For every reader of MOS who is helped by seeing &amp;nbsp; in examples, there will be another is flummoxed and alienated by it. Best treated specially elsewhere; and best to revisit this issue another time. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)


So here we are. I'd like input from the project, and I'm sure Muéro would like that too.
'''B.''' A di M commented: "I'd use examples like the current ones for the dash (with such über-familiar noun phrases as prime minister or World War II), and then after '...&nbsp;is possible and better' show seriously abstruse examples in red followed by a suggested rephrasing in green," and later: "...&nbsp;if we say that rewording is sometimes (but not always) better, I think we ought to include both examples of when it's better than when it isn't." My own view is that the present examples work well to make their points. I put a lot of thought into their selection. And we don't want ''more'' examples, surely.


The discussion originated on ], but I'm copying it here, and closing it there, while notifying them.
;Brief discussion
* '''Agree''' They look like good examples. ] (]) 05:37, 19 July 2011 (UTC)
*'''Agree'''—No longer if possible, please. Very well laid out, IMO; it contains some tips for updating the rest of MoS in the future along these lines. ] ] 12:34, 19 July 2011 (UTC)
* '''Agree''' – a few more or less examples won't bother me, but I see no problem big enough to get hung up on. ] (]) 14:58, 19 July 2011 (UTC)
*'''Immaterial'''; but I'd like to see what A di M has in mind before deciding. ] <small>]</small> 18:07, 19 July 2011 (UTC)
*'''Agree''' with current examples, but might consider a few specifics ''if'' they would illustrate points that would otherwise be lost. ] (]) 04:51, 20 July 2011 (UTC)


===The discussion on Muéro's talk page===
;Response in the final draft
Hello.
* I believe I have understood A di M's suggestion; I have added an example in response. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)


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''".
=====3. Expository points=====


Thank you. ] (]) 15:50, 25 November 2024 (UTC)
'''A.''' Jeff Conrad thought "it might help to explain why 'Franco-British rivalry' takes a hyphen rather than an en dash." Agreed. I can do that, and had simply omitted the explanation to get fewer words. Any similar points, anyone?


: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)
;Brief discussion
*'''Agree''' Jeff gets his suggestion adopted. ] (]) 05:37, 19 July 2011 (UTC)
*'''Agree''' ] ] 12:34, 19 July 2011 (UTC)
* '''Agree''' – I'm OK with a bit more explanation, but don't see it as necessary really. ] (]) 14:58, 19 July 2011 (UTC)
*'''Disagree'''. The explanation is that compounds normally take hyphens (or spaces, or nothing). We do not need to deal with exceptions to exceptions. ] <small>]</small> 18:07, 19 July 2011 (UTC)


::Hello again.
;Response in the final draft
* Despite PMAnderson's dissent, the request appears reasonable. I have satisfied it. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)


::Thank you for your understanding. Re: your latest edits, you're now leaving a comma in place that shouldn't be there.
'''B.''' Dicklyon was "a little bothered by the statement 'These can be quite similar to uses of the hyphen; or less often, the slash.'&nbsp;" (See details above.) I accept this, and will make a change that expresses things better.


Nathaniel Charles Jacob Rothschild, 4th Baron Rothschild, (29 April 1936 – 26 February 2024),
;Brief discussion
^ ^ ^
* '''Agree''' Dick made a good point. ] (]) 05:37, 19 July 2011 (UTC)
A B C
*'''Agree''' ] ] 12:34, 19 July 2011 (UTC)
* '''Agree''' – Thanks for hearing me; I'll trust that you'll improve it a bit. ] (]) 14:58, 19 July 2011 (UTC)
*'''Let's see what happens'''. ] <small>]</small> 18:07, 19 July 2011 (UTC)


::Commas A and C are paired, comma B should be removed along with the postnoms that followed it. Commas rarely precede parentheses.
;Response in the final draft
* Done. Explained. More needs to be said about these combining forms (''Franco'', ''Sino''); but to get things concluded now, I'll hold back my concerns till the next time we visit the dash section. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)


::Cheers.
=====4. Spacing in ranges=====


::] (]) 17:52, 25 November 2024 (UTC)
Both Jeff Conrad and Dicklyon had things to say about this. (So did A di M, but it seems to me that his concern over confusion with minus signs was adequately addressed. I am ready to be corrected, of course.)
:::I don't think that makes sense. If someone doesn't have a nobility/royalty title, there is no comma before or after the life span. When adding the nobility/royalty title, the pair of commas should go before and after the nobility/royalty title. Why, when adding the nobility/royalty title, would the life span get looped into the comma pair? ]<sup>(]/])</sup> 17:56, 25 November 2024 (UTC)


====Step by step====
Jeff wrote, for example: "Spacing of range dashes where one or more elements contains a space: either spaced or unspaced use should be allowed. The polling seems to indicate considerable support for allowing both." And later: "Though Noetica and I seem to differ fairly strongly on what has been concluded with regard to spacing of range dashes, it should be clear that this is the only point in the draft on which we really differ." And again: "Clearly it's impossible to arrive at formulaic guidance on when association implied by the en dash might misleading, and the same is probably true for any possible confusion between range dashes and parenthetical dashes. Practically, the choice would be a matter of personal choice—British practice aside from OUP is apparently to prefer the spacing, while North American practice is usually to prefer closed-up usage. The case for spacing is probably strongest with full dates and with instances similar to the last example above. Even so, NA seem to prefer closed-up usage."
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:
Dick wrote: "I pretty much agree with Jeff that spaces around connective en dashes are rare (esp. in AmE), so I'm glad that the new draft backed off some from what the old one said. And I'm OK with the present compromise ("always unspaced, except for times and dates (or similar cases) when the components already include at least one space") as being motivated by the discussion (see 6b), even if it's hard to see exactly how far it should be changed from the votes at hand (PMAnderson is correct that the voting did not address this question, and the expressed disagreements leave a range of possible changes, of which Noetica's is somewhere in the middle); tweaking it can be left for a later round."
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.
My own view, after careful consideration of this vexed issue: Jeff's concern is perfectly understandable. I had incorporated a "marginal" case of a compound date range ({{xt|Christmas Day&nbsp;– New Year's Eve}}); strictly, it ''is'' such a case, and it would be a denial of the responsibility for a manual of style simply to exclude it as "too hard". People look to a manual to decide difficult cases. We could argue forever over this one, and about the principle as a whole; but in the end, we would still have to settle on a compromise. Dick is "OK with the present compromise", and "Noetica's somewhere in the middle". Finally, I agree with Dick that "tweaking it can be left for a later round"; and that applies to a number of finer points. Let's settle things for now, not for Doomsday or the afterlife.


Now, let's add the life span. Where do we add it? Before punctuation.
;Brief discussion
John Doe, 1st Baron Doe (1 January 1801 – 31 December 1881), was a Whig politician ...
* '''Agree''' A sensible amalgam of all input. ] (]) 05:37, 19 July 2011 (UTC)
^ ^
*'''Agree'''. This is one of these cases where no "solution" can satisfy every fiddly case. Noetica's compromise is appropriate. ] ] 12:34, 19 July 2011 (UTC)
A B
* '''Agree''' – It's OK, and I won't object if it changes a bit, now or later. ] (]) 14:58, 19 July 2011 (UTC)
The commas A and B are still paired. See?
*'''Disagree''' The way to settle it for now, not for Doomsday, is to be silent. The only thing that can be said definitively out of this is that there are several ways to space here; we don't need to say even that unless there is some reason to "extend our legislative hand" (and so breach policy). ] <small>]</small> 18:07, 19 July 2011 (UTC)
* Partially '''Disagree'''. Though I, like the vast majority of guides, clearly prefer closed-up usage in all cases, my vote was a compromise, especially where we have a long-established practice of spacing the dash in complete date ranges in biographies. I still take issue with a few of the examples, however. In some cases, it is impossible to assess consensus because I don’t think we really voted on the issues; in a couple of others, spacing the dash creates real ambiguity rather than “initial ambiguity”, so it becomes far more than a matter of personal preference. Some specifics: I fail to see how different treatment of {{xt|New York–London flight}} and {{xt|Christmas Day–New Year’s Eve}} can be justified; there’s certainly no difference in “initial ambiguity”, and the latter is simply not a range of dates. The genuine ambiguity is more serious, as arises from {{xt|18 July – 3 September 2012}}. Even worse is ambiguity that arises spacing the dash in a range of quantities with repeated units. I just encountered a real-world example for which even my suggestion to use ''to'' would not work: I had need to refer to “the 20&nbsp;kHz–20&nbsp;Hz propagation delay”. Had I used {{xt|the 20&nbsp;kHz – 20&nbsp;Hz propagation delay}}, I’d had have left the strong impression of subtraction, which would have been dead wrong because the actual difference here was one of time, not frequency. Now perhaps the reader would have sorted it out, but doing so would have required unnecessary effort. And I don’t think my suggestion of using ''to'' ({{xt|the 20&nbsp;kHz-to-20&nbsp;Hz propagation delay}}) really works here, either. This example raises another point: unless there is good reason to do otherwise, I think the examples should show adjectival use, because it is usually the most challenging case.
:Perhaps it could be said that these issues should have been raised earlier; if so, as the person who did the breakout, I must take much of the responsibility for failing to better separate some of the usages. Though some of my differences here are a matter of personal preference, I say once again that the sources agree with me. To the anticipated rejoinder that “we have moved beyond the guides”, I would say that I have a bit of a problem with summarily ignoring the “quality of the arguments” element of ], especially since I raised it in polling. If we really feel that “I like it” sometimes carries the day, we should revise ] accordingly. If we simply ignore it, I fail to see how we could chide anyone for ignoring this guideline as well. Again, please take my comments here in perspective—recall that my first words were “It looks pretty good”, and the cases here are relatively few. Nonetheless, my disagreement remains strong on a few of them. ] (]) 04:22, 20 July 2011 (UTC)
:* OK. Well, why not try working offline (backchannel, on your talk pages, whatever) with Noetica to hammer out a better solution. None of this stuff is locked in stone. Consensus can change. This is a complex package of changes and consolidations and there are bound to be points that can be modified or added. In that spirit, I hope one or both of you come back with a tweak you can accept in the spirit of compromise so you, Jeff, can be a member of an across-the-board consensus. ] (]) 05:04, 20 July 2011 (UTC)


] (]) 23:04, 25 November 2024 (UTC)
;Response in the final draft
* Dick, and Tony want to move on; PMAnderson wants silence; Jeff wants to expatiate at the eleventh hour; and Greg wants Jeff and me to get a room, where he can talk the legs off a chair and I can talk them back on again (count them at the end: there'll be five by then). Let's see what I can do&nbsp;...
* Jeff, your vote was a compromise? Fine. So was mine (I'd want certain headings to have been in this fold also, agreeing with at least five major style guides and de facto practice at OUP). The majority appears to be happiest with spaced en dashes for ranges when either component has a space; so we meet in the middle, with them. Now, you say that {{xt|Christmas Day&nbsp;– New Year’s Eve}} is not a range of dates? I say it is; and that its similarity to {{xt|New York–London flight}} is as superficial as the similarity of {{xt|blue~green algae}} and {{xt|red~green colorblindness}} (which we distinguish with "-" and "–"). We need to ''identify'' {{xt|Christmas Day&nbsp;– New Year’s Eve}} as a range of dates in the examples, to make a robust, simple guideline that anyone can understand. It does no more harm to space this one than it does to space any other date example (with spaces in it). For that reason I have added a ''further'' example: {{xt|Christmas 2001&nbsp;– Easter 2002}}. ''That'' is a date range, surely. The user gets the idea, and can remember and apply it. Bear in mind that these date ranges typically occur in parentheses, where they can do no harm to the enclosing sentence. As for your highly unusual and recently discovered example Jeff ({{xt|the 20&nbsp;kHz – 20&nbsp;Hz propagation delay}}), remember that hard cases make bad laws. There will always be rare, fluky situations that call for creative solutions; we soon get entangled if we make ourselves hostage to them.
* Finally Jeff, you have misunderstand me if you think that I interpret consensus as only a matter of counting votes. I ''wish'' you had not raised this right here; but since you did, I will answer. I wrote of the "practical necessity" under which I operated, given Casliber's requirement they we vote clearly, to "quantify" the consensus. Take him to task, not me. It was extraordinarily hard to work up a draft drawing on every last eddy of opinion, in those two subpages crammed with comment. Luckily, the voting corresponded pretty well with the weight of argument and evidence (sign of a thoughtful group). I suggest that ''you'' revisit the top few sentences of ], yourself. Take PMAnderson along with you. I quote: '''"Consensus is not necessarily unanimity. Ideally, it arrives with an absence of objections, but <u>if this proves impossible, a majority decision must be taken</u>. More than a simple majority is generally required for major changes."''' We have every reason to believe that this is such a case. Practical necessity, once more. But still, who is ''not'' trying for something better, by reason, compromise, and consultation? I know ''I'' have been, for the last several months. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)
:::You are proposing a major change, with (even by your own count), a hairline majority of 15-14. By your own argument, this should not be done; silence would be preferable. ] <small>]</small> 16:48, 20 July 2011 (UTC)
:*:Greg, with all due respect, after reviewing the results here half a dozen times, I have difficulty finding a clear majority, and nothing remotely approaching an “across the board consensus”; because of the way many of the votes were qualified, I have trouble even arriving at an unambiguous tally. Given your earlier comment “All parties stipulate that ] discloses all that is known and needs to be known about the subject”, I find your comment here puzzling—more than a simple majority would seem needed, and I cannot see that “quality of arguments” was even considered. ] (]) 21:37, 20 July 2011 (UTC)
:::Noetica, I’m not sure I’m taking anyone to task. I simply mentioned that I have great difficulty seeing a “clear majority”, and that I still cannot see how “quality of arguments” was considered. As best I can make of it, only two of us gave much more than “I like it” arguments here. What are the reasons for spacing? And what are the five major style guides to which you refer? Perhaps I missed something, but I do not recall recent mention of any of them. And for what it’s worth, the OUP books that I have close-up en dashes, though concede that I probably don’t have enough for a representative sample.
:::I’d hardly call {{xt|the 20&nbsp;kHz–20&nbsp;Hz propagation delay}} a fluke, though I admit that adjectival use probably isn’t all that common. I would say this: while the reader can probably sort out either closed-up or spaced usage, the latter at first glance resembles the common situation of a difference of physical quantities, while the former presents no such ambiguity, because a minus sign in subtraction is always spaced (except perhaps for those who write unreadable code). So the closed-up usage here avoids ambiguity, while not presenting other problems. Hard cases make bad laws? Perhaps in Australia {{nowrap|. . .}} in the US, we recognize that the safeguards of liberty have frequently been forged in controversies involving not very nice people.
:::As for “eleventh hour” I simply cannot agree—I’ve simply restated issues that I do not think were addressed. You obviously fee otherwise; sometimes reasonable minds can differ. ] (]) 21:37, 20 July 2011 (UTC)
::::So have I. Despite Noetica's persistent personal attacks, I have been willing to compromise; I supported ], which gave the permission half of those polled now support. It failed because many editors found it ''too'' restrictive (if I recall correctly, it was 19-18, and that was held not to be consensus); to claim something even more restrictive as consensus (on a narrower vote) is not accurate. ] <small>]</small> 20:19, 22 July 2011 (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)
=====5. En dash with spaced components=====


::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:
Jeff Conrad wrote: "I would add one example in which the first component contains a space (e.g., Chuck Berry–style lyrics&nbsp;...". And further on this matter: "One approach would be to permit either usage, possibly encouraging consistent use of either North American or British practice, though this could be tricky because some practices may be chiefly (but not exclusively) North American, and others may be chiefly (but not exclusively) British. / I can’t say whether the fact that one construction may indicate the structure more clearly is sufficient to deprecate an alternative construction, but it seems to me that the point of en dashes in nearly all cases is to more clearly indicate what is meant than would a hyphen. So if it doesn’t matter here, it arguably doesn’t matter anywhere."
... {{xt|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?
Dick wrote: "So is this one more optional than most? If some editor changes 'ex–prime minister' back to the hyphen version, should we complain and fix it back? I still think we should, since if an editor finds it useful to use punctuation to signal the structure more clearly, we ought to let them. In that sense, I don't see the point of trying to make this one more optional than most, as some are suggesting. On the other hand, I don't have strong feelings about it, and would be willing to go with adjustments if there's a consensus to do so."
... {{!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.)
Myself, I articulated my objections to this principle in the voting. I think it is quite unnecessary; but I put it in the draft because including it seemed more acceptable to more people than leaving it out. More importantly, I think, a substantial majority ''have'' expressed a wish for a simple principle, here and throughout the voting: either explicitly, or more often by their simple "agree". That is my view also: I don't like it, but stability and consistency on this particular principle is important in article titles especially, so let's go for the dominant way to lessen discord in future, and also possible searching problems. I also pointed out to Jeff Conrad that cases like {{xt|Chuck Berry–style lyrics}} were not voted on. Again, the present round of discussion need not be ''final''; but it ought to be ''finalised''. If anyone feels strongly about this in the future, let it be raised when the present work is behind us.
::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)
;Brief discussion
:::"Punctuation doesn't precede a parenthetical" is not a rule at all. It's just something you made up.
* '''Agree''' Good analysis on how to handle en-dashes. ] (]) 05:37, 19 July 2011 (UTC)
:::If the parenthetical were being applied to the nobility title, then the parenthetical should go within the commas that set off the nobility title. But the parenthetical is being applied to the actual name of the person, which came before the nonessential appositive that is set off by commas.
*'''Agree'''—No strong feelings, but I'm more used to it now, and have even introduced it in a recent FAC lead, because it seemed more elegant than a triple hyphenated unit. While I think some readers may not be familiar with the usage, it's intuitive enough. ] ] 12:34, 19 July 2011 (UTC)
:::If you dislike the placement of the nobility title between the name and the lifespan parenthetical, I wouldn't disagree. I'd happily remove the nobility title entirely from the lead sentence (or heck, the whole article). Or put the lifespan parenthetical first, and then the nobility title. But wherever the nobility appositive is being stuck, it gets set off by commas. That's the rule. ]<sup>(]/])</sup> 13:38, 26 November 2024 (UTC)
* '''Agree''' – I like this Americanism, but I won't object later if we want to adjust it to be more optional. ] (]) 14:58, 19 July 2011 (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)
*'''Disagree'''. There was a majority ''against'' requiring {{!xt|ex–prime minister}}; there was a majority to perfer it; neither was consensus. Any draft which requires it deserves dispute resolution. ] <small>]</small> 18:07, 19 July 2011 (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>
* '''Agree''' – This works for me.--] (]) 20:32, 19 July 2011 (UTC)
:# Something like "Xerxes Youill Zounds, Grand Poobah of Elbonia–Brobdingnag (3 May 1571 – 24 July 1644), was ..." is {{em|always}} indicating the life-span dates. If there is a need to specify the duration of a peerage, including a change in titles, that should be done in plain English in the article body, and is not going to be lead-sentence or even lead-section material. It's body material, like "Upon the death of his father, Zounds became 3rd poobah of Elbonia on 12 December 1629. He was elevated to 1st grand poobah of Elbonia–Brobdingnag on 20 June 1639 by High King Korki IX of Kerblachistan. Zounds was also the bishop of Lilliput from ca. 1630 to 14 February 1633, when he was defrocked by the archbishop of Elbonia."
* '''Agree''' Like Dick, I think it adds clarity in some cases, and probably more so than with prefixes. And as I’ve said, if a hyphen is OK here, it’s OK in many other cases where we call for an en dash. Be assured, though, that I won’t be running around looking for uses of the hyphen here to correct. I would, however, have the examples show adjectival use (e.g., {{xt|ex–prime minister Brown}}) because I think the benefit is more obvious}} (and how should “former prime minister Brown” be handled?). ] (]) 05:02, 20 July 2011 (UTC)
:# As an anti-classist myself, I still have to observe/concede that "don't include any titles or post-noms because they are classist" is not a viable position. WP is ], and when any such title or honor (whether earned or hereditary or otherwise) is pertinent to a notable article subject, it should be covered, more prominently the more important it is within the context of their notability. (See below for an idea toward suppressing lead inclusion when not related to notability at all but a late-coming add-on to the pile of someone's life aachievements.)

:# 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.
;Response in the final draft
:# 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>
* My analysis of the voting differs from PMAnderson's. Analysing the votes ''with their associated comments'' (as everyone accepts that we should), and seeing what the voters were willing or unwilling to accept, I count it this way. Of the 29 who voted on this principle (including PMAnderson, though he did not vote outside the navbox):
:#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).
** '''7 rejected it outright''' (SarekOfVulcan, Powers, Hullaballoo Wolfowitz, SJ, Headbomb, Nageh, Telpardec)
:#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.
** '''7 accepted it, but asked that it be optional''' (WFC, A di M, Powers, Enric Naval, Ozob, JN466, PMAnderson)
:#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).
** '''15 accepted it, and did not ask that it be optional''' (JeffConrad, Kotniski, Armbrust, Dabomb87, Tony, Kwami, ErikHaugen, Dicklyon, CWenger, Jenks24, Courcelles, macwhiz, Finell, InverseHypercube, Noetica )
: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)
::That's a simple majority (15–14) accepting it without any option; and that's a ''clear'' majority accepting it in one way or another (22–7). Only 7 out of 29 favour giving a choice. Nothing in ] obliges us to accommodate every minority preference in a manual of style. That's not what manuals of style are for. Last, we don't know what those 7 would say to this question: "Do you want a manual of style to set a simple uniform guideline for everyone?" That number would have been 8, remember: but I gave up my opposition to the principle for the larger good: consistency of style on Misplaced Pages. In fact, I would have held out and maintained opposition; but Jeff was so adamant, and the principle ''is'' so widely accepted in America, that I yielded.
* I have amended the heading for the section; we voted on prefixes, and it is confined to prefixes.
* By an extreme act of contortion, I have amended the guideline in the final draft so that it applies in an acceptable, well-delimited set of cases, and recasting is to be clearly preferred in all other cases. I submit that this is an optimal solution. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)
**In short, there is no consensus for making such forms mandatory. Any draft which makes it mandatory is absolutely unacceptable. A draft which expresses preference, as Blueboar suggests, would be acceptable to me and to at least three-quarters of those polled; it is conceivable that those who strongly prefer {{xt|ex-prime minister}}, or avoiding this construction altogether, would settle for being left alone. ] <small>]</small> 15:26, 20 July 2011 (UTC)

=====6. In lists=====

Jeff Conrad wrote: "The usage within items in a list (which I’m still not convinced is a distinct case) should not lend itself to be read as precluding alternatives." And Dick wrote: "&nbsp;'To separate items in certain lists' is not a separate role, but just another case of using spaced en dash as a dash; same idea in Kotniski's point."

Do editors really care enough about this right now, though? The present draft does the best it can to preserve what the current stable guideline says, but just makes it clearer. I propose that we leave this topic for possible consideration later, also.

;Brief discussion
* '''Agree''' That’s fine too. Going back to serial tweaking later to further flesh this out (like we used to do) will kill no one. ] (]) 05:37, 19 July 2011 (UTC)
*'''Agree'''. I must say, spaced en dashes in lists look the best to me—far better than most alternatives—but the draft is fine. ] ] 12:34, 19 July 2011 (UTC)
* '''Agree''' – It's kind of a misfit point, but not doing any real harm; defer adjustments to later. ] (]) 14:58, 19 July 2011 (UTC)
*'''Disgree''' This has never been important; nobody has argued for this at all strongly; Jeff has expressed continued puzzlement as to what this means or why. The provision this has evolved from was a profitless choice between two perfectly reasonable ways to format lists. Take out the whole point, until somebody presents an actual difficulty. ] <small>]</small> 18:07, 19 July 2011 (UTC)
* '''Agree''' – This also works for me, for the moment, and agree that further changes could be considered at a later point.--] (]) 20:32, 19 July 2011 (UTC)
* '''Agree''' that because the proposal includes examples, it’s a big improvement, provided that we don’t see it as precluding other punctuation. I still have doubts about whether this is a distinct usage, but this is a minor issue that can be dealt with later if it’s felt necessary. ] (]) 05:06, 20 July 2011 (UTC)

;Response in the final draft
* Nothing to do; nothing done. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)

=====7. Points to deal with elsewhere, outside the dashes guideline=====

A di M expressed this view: "Image filenames are even less relevant than recasting or hard spaces or exception would be."

I am happy to take out the mention of dashes and hyphens in filenames, subject to there being no objection here.

;Brief discussion
* '''Agree''' To make progress and break out of the current morass, there is no harm not addressing file names now; that issue can always be addressed in the far, ''far'' off future in Misplaced Pages time (next week in real time) if needed. ] (]) 05:37, 19 July 2011 (UTC)
*'''Agree''' ] ] 12:34, 19 July 2011 (UTC)
* '''Agree''' – Image filenames are not part of "style", but I don't care if they're in or out at this point. ] (]) 14:58, 19 July 2011 (UTC)

;Response in the final draft
* Done. We must follow up with changes elsewhere in MOS, for this and the other points that were to be moved outside the dash guideline. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)

=====8. Any points that have been missed in the above=====

* '''None''' Noetica, you’ve truly done a great job trying to capture the essential elements of everyone’s input to arrive at a distillation around which a general consensus can form. It is a magnificent effort in an all-volunteer, collaborative writing environment. Your heavy lifting here has not gone unnoticed. ] (]) 05:37, 19 July 2011 (UTC)


;Brief discussion
*Great job, Noetica. ] ] 12:34, 19 July 2011 (UTC)
* '''Thanks''' – for taking on the brunt of the work, and dealing with the inevitable blowback. I support you, and want to get this done, so will not offer any more new complications at this point. ] (]) 14:58, 19 July 2011 (UTC)
*Noted. Noetica's draft does not even represent the views of a majority, much less consensus. Those who approve of it approve of ignoring discussion, usage, and sources. ] <small>]</small> 18:07, 19 July 2011 (UTC)
:* Quoting you, PMA: {{xt|Noetica's draft does not even represent the views of a majority, much less consensus.}} What defines a consensus is being determined ''<u>now</u>''; here. Perhaps the consensus will be that it is a good step. Perhaps the consensus view will be that it smells like a Frenchman’s armpits; we’re not done yet. Whatever you think of Noetica’s effort at consensus-building in light of ] is irrelevant now. No one said working in a ] is easy. You had an opportunity here to . The tenor of your posts makes me not so sure you exploited the opportunity to the fullest. ] (]) 20:39, 19 July 2011 (UTC)
:::It does seem odd that PMA picks mainly on the minor "ex–prime minister" provision now, given that the section ] was not among those that he disagreed with; he says it "deserves dispute resolution," as if that's not what we're approaching closure on. And unclear what he means by "not even...a majority" if one-third of the people expressed some reservations and disagreements (including Noetica, himself, who is now trying to find a consensus compromise that isn't even his own opinion). And now PMA objects to mentioning the role of en dashes as separators in list items, but he didn't say so when he had the chance at ] (actually, if you "open" the "superceded" bit there, you can see that he said he agreed). Now he says this "has never been important; nobody has argued for this at all strongly," which might be true, but holding up resolution for a point that he said he agrees on, and that he agrees is unimportant, seems like just a stalling tactic. If he wants to propose changing either of these later, I might even agree with him for a change, but that's not where we're at. As for his statement that we "approve of ignoring discussion, usage, and sources," I just don't get what makes him say such things; just trolling, I guess. Also note that on Noetica's draft that we're discussing final changes to, PMA offered neither any criticism nor any suggested changes, but just procedural complaints; so to object now to Noetica's attempts to address all the suggestions seems at least counter-productive, if not in plain bad faith. ] (]) 02:07, 20 July 2011 (UTC)
::::It’s time to stop dumping on PMA. His style tends to be a hard-to-ignore one-man band. We all know that. In the past, too much has been made of his opposition and he has—in my opinion—had influence wildly in excess of head count. There’s been back & forth finger pointing and accusations that the other side has been operating… uhm… ''*cheatfully*''. The Good Ship Major Malfunction has sailed. PMA is ''just one voice.'' He’s stated his opinion: fine, thank you very much; time to move on. If a consensus can’t be made here despite his opposition, then there are one or more shortcomings in Noetica’s proposal that need to be ironed out in order to get more editors singing from the same sheet of music. Noses back to the grind stone please. ] (]) 05:16, 20 July 2011 (UTC)
* Though I still have a couple of very strong disagreements about a few points (and possibly the procedure at arriving at them), I stress again that the overall effort is a great job. ] (]) 05:10, 20 July 2011 (UTC)

;Response from Noetica
* Thanks! Now can we just ''settle'' this damn thing? It's been going for months. I don't know about others, but I'm exhausted. Just ''compromise'', yeah? '''I myself have strong disagreements with the draft I have made.''' But it works. You will not find a more considered, more complete, more sensitive solution to this hardest of problems in modern punctuation. Not on the web; not anywhere. And we did it together. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)
**I think the fact that you can't find it anywhere else strongly suggests that large parts of this problem did not need to be solved by wikipedia. Misplaced Pages is supposed to follow its sources, not synthesize them in novel ways. I have to agree with PMA that it would be better to say less and prescribe less. ] (]) 06:03, 30 July 2011 (UTC)

=== Final draft 1: please endorse, or comment ===
I present what I am calling "Final draft 1" for the dashes section. It responds to suggestions made in the preceding subsection, where I have now enumerated the changes and responded to all concerns. Changes are marked in this new draft by underlining, and in one case by striking through. '''To see the new draft, click on "Show", at the right:'''
{| class="navbox collapsible collapsed" style="text-align: left; border: 0px; margin-top: 0.2em;"
|-
! style="background-color: #aaffaa;" | '''Final draft 1'''
|-
|
<big><big><big>'''Dashes'''</big></big></big>
{{shortcut|MOS:DASH|WP:DASH}}

Two forms of dash are used on Misplaced Pages: ''']''' (–) and ''']''' (—). Type them in as <code>&amp;ndash</code> (–) and <code>&amp;mdash</code> (—); or click on them to the right of the "Insert" tab under the edit window; or see ].
*<s>Use hyphens, never dashes, in filenames of images, sounds, or other included media.</s>
*When a dash is used in the title of an article (or any other page), there should be a ] from a hyphenated version: {{xt|]}} redirects to the article {{xt|]}}.

Sources use dashes in varying ways, but for consistency and clarity Misplaced Pages adopts the following principles.

<big><big>'''Punctuating a sentence (em or en dashes)'''</big></big>
{{shortcut|MOS:EMDASH|MOS:SENTENCEDASH|WP:EMDASH|WP:MDASH|WP:SENTENCEDASH|}}

Dashes are often used to mark divisions within a sentence: in pairs (''parenthetical dashes'', instead of parentheses or pairs of commas); or singly (perhaps instead of a colon). They may also indicate an abrupt stop or interruption, in reporting direct speech.

There are two options. Use one or the other consistently in an article.

;1. Unspaced em dash
*{{xt|Another "planet" was detected—but it was later found to be a moon of Saturn.}}

Or:

;2. Spaced en dash
*{{xt|Another "planet" was detected&nbsp;– but it was later found to be a moon of Saturn.}}

Do not use spaced em dashes.
*{{!xt|*Another "planet" was detected&nbsp;— but it was later found to be a moon of Saturn.}}

Dashes can clarify the sentence structure when there are already commas or parentheses, or both.
*{{xt|We read them in chronological order: Descartes, Locke, Hume—but not his ''Treatise'' (it is too complex)—and Kant.}}

Use dashes sparingly. More than two in a single sentence makes the structure unclear; it takes time for the reader to see which dashes, if any, form a pair.
*{{xt|The birds—at least the ones Darwin collected—had red and blue feathers.}}
*{{xt|"Where is the—", she said, but then realized she held it in her hand.}}
*{{!xt|*First in the procession—and most spectacularly—came the bishops—then the other clergy.}}

<big><big>'''En dashes: other uses'''</big></big>
{{shortcut|MOS:ENDASH|MOS:NDASH|WP:ENDASH|WP:NDASH}}

<u>The ] (–) has other roles, beyond its use as a sentence-punctuating dash (see immediately above). It is often analogous to the hyphen (see the section ]), which ''joins components'' more strongly than the en dash; or the slash (see the section ]), which ''separates alternatives'' more definitely. Consider the exact meaning when choosing between these three. En dashes are used in four ways.</u>

;1. In ranges that might otherwise be expressed with ''to'' or ''through''
*{{xt|pp.&nbsp;211–19}};&nbsp;&nbsp; {{xt|64–75%}};&nbsp;&nbsp; {{xt|the 1939–45 war}}
Do not mix en dashes with prepositions like ''between'' and ''from''.
*{{xt|450–500 people}}
*{{!xt|*between 450–500 people}}; {{xt|between 450 and 500 people}}
*{{!xt|*from 450–500 people}}; {{xt|from 450 to 500 people}}
<u>If negative values are involved, an en dash might be confusing. Use words instead.</u>
*{{!xt|*&minus;10–10}}; {{xt|&minus;10 to 10}}
*{{!xt|*the drop in temperature was 5°–&minus;13°}}; {{xt|the drop in temperature was from 5° to &minus;13°}}
The en dash in a range is always unspaced, except for times and dates (or similar cases) when the components already include at least one space.
*{{!xt|*23&nbsp;July 1790–1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{!xt|*14&nbsp;May–2&nbsp;August 2011}}
*{{xt|23&nbsp;July 1790&nbsp;– 1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{xt|14&nbsp;May&nbsp;– 2&nbsp;August 2011}}
*{{xt|10:30&nbsp;pm Tuesday&nbsp;– 1:25&nbsp;am Wednesday}};&nbsp;&nbsp; {{xt|Christmas Day&nbsp;– New Year's Eve}};&nbsp;&nbsp; <u>{{xt|Christmas 2001&nbsp;– Easter 2002}}</u>
*{{xt|1–17 September}};&nbsp;&nbsp; {{xt|February–October 2009}};&nbsp;&nbsp; {{xt|1492?&nbsp;– 7&nbsp;April 1556}}
*{{xt|Best absorbed were wavelengths in the range 28&nbsp;mm&nbsp;– 17&nbsp;m.}}

;2. In compounds when the connection might otherwise be expressed with ''to'', ''versus'', ''and'', or ''between''
Here the relationship is thought of as parallel, symmetric, equal, oppositional, or at least involving ''separate or independent elements''. The components may be nouns, adjectives, verbs, or any other <u>independent</u> part of speech. Often if the components are reversed there would be little change of meaning.
*{{xt|boyfriend–girlfriend problems}};&nbsp;&nbsp; {{xt|the Paris–Montpellier route}};&nbsp;&nbsp; {{xt|a New York–Los Angeles flight}}
*{{xt|iron–cobalt interactions}}; the components are parallel and reversible; iron and cobalt retain their identity
*{{!xt|*an iron–roof shed}}; ''iron'' modifies ''roof'', so use a hyphen: {{xt|an iron-roof shed}}
*{{!xt|*the poet's mentor–muse}}; not separate persons, so use a hyphen: {{xt|the poet's mentor-muse}}
*{{xt|red–green colorblind}}; red and green are separate independent colors, not mixed
*{{!xt|*blue–green algae}}; a blended, intermediate color, so use a hyphen: {{xt|blue-green algae}}
*{{!xt|*Franco–British rivalry}}; <u>"Franco", is a ''combining form'', not independent; use a hyphen: {{xt|Franco-British rivalry}}</u>
*{{xt|France–Britain rivalry}};&nbsp;&nbsp; {{xt|French–British rivalry}}
*{{xt|a 51–30 win}};&nbsp;&nbsp; {{xt|a six–two majority decision}};&nbsp;&nbsp; <u>{{xt|the Lincoln–Douglas debates}}</u>
*{{xt|an Italian–Swiss border crossing}}; but {{xt|an Italian-Swiss newspaper}}, for Italian-speaking Swiss
*{{xt|the Uganda–Tanzania War}};&nbsp;&nbsp; {{xt|the Roman–Syrian War}};&nbsp;&nbsp; {{xt|the east–west runway}}
*{{xt|diode–transistor logic}};&nbsp;&nbsp; {{xt|the analog–digital distinction}};&nbsp;&nbsp; {{xt|a carbon–carbon bond}}
*{{xt|a pro-establishment–anti-intellectual alliance}}
*{{xt|Singapore–Sumatra–Java shipping lanes}}
*{{xt|the ballerina's rapid walk–dance transitions}};&nbsp;&nbsp; {{xt|a male–female height ratio of 1.2}}
A slash or some other alternative may occasionally be better to express a ratio, especially in technical contexts (see ] below).
*{{xt|the protein–fat ratio}}&nbsp; or&nbsp; {{xt|the protein/fat ratio}},&nbsp; or even&nbsp; {{xt|the protein-to-fat ratio}}
An en dash is not used for a hyphenated personal name.
*{{xt|Lennard-Jones potential}} with a hyphen: named after John Lennard-Jones
An en dash ''is'' used for the names of two or more people in a compound.
*{{xt|the Seifert–van Kampen theorem}};&nbsp;&nbsp; {{xt|the Seeliger–Donker-Voet scheme}};&nbsp;&nbsp; {{xt|the Alpher–Bethe–Gamow theory}}
*{{xt|Comet Hale–Bopp}} or just {{xt|Hale–Bopp}} (discovered by Hale and Bopp)
Following the dominant convention, a hyphen is used in compounded place names and language names, not an en dash.
*{{xt|Guinea-Bissau}};&nbsp;&nbsp; {{xt|Austria-Hungary}}
*{{xt|an old Mon-Khmer dialect}};&nbsp;&nbsp; {{xt|Niger-Congo phonology}}

The en dash in all of the compounds above is unspaced.

;3. <u>Instead of a hyphen, when applying a prefix to a compound that includes a space</u>
*<u>{{xt|ex–prime minister Thatcher}}</u>;&nbsp;&nbsp; {{xt|pre–World War II aircraft}}
<u>Use this punctuation when the construction must be retained—for example in a transcription of a speech, or in a heading that is already chosen as optimal. Otherwise recasting is better.</u>
*<u>Keep: ] (a Misplaced Pages article)
*Best to recast the two examples above: {{xt|former prime minister Thatcher}}; {{xt|aircraft before World War II}}</u>
*<u>Very awkward: {{!xt|*the mother had post–difficult birth health problems}}; recast as {{xt|the mother had health problems after a difficult birth}}</u>

The en dash in all of the compounds above is unspaced.

;4. To separate items in certain lists
Spaced en dashes are used within parts of certain lists. Here are two examples:
* Pairing performers with instruments.
**{{xt|James Galway – flute; Anne-Sophie Mutter – violin; Maurizio Pollini – piano.}}
* Showing track durations on a CD.
**{{xt|The future – 7:21; Ain't no cure for love – 6:17; Bird on the wire – 6:14.}}

----
|}
<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:42, 20 July 2011 (UTC)

==== Suggested procedure ====
# Editors, please review the draft, comparing it with the previous one and checking the comments I make above about changes.
# Consider carefully the need to yield on some points; we ''all'' have had to do that. Consider the value of this draft for the Project.
# Note errors, omissions, or ''final small fixes'' in the subsection below, in orderly and considerate brevity.
# If you absolutely must object to anything, do so ''soon'' and ''clearly'', proposing a ''precise solution'', rather than calling vaguely for something to be redrafted.
# Remember that we have been at this for months, and that we are four days overdue already. Eight weeks (effectively) ought to have been enough time to settle all the issues.
# Please have your say within 24 hours from now. After 24 hours, I will take whatever next step is appropriate (since I am used to dealing with this, I might as well be the one to carry it through). And we can get a completed version incorporated into WP:MOS.

==== Endorsements, and final points to fix ====

* ''(Remaining mute for a moment)'' My contribution to this has been to assist in making ''the process'' work (put a stop to sniping and ensure that a proper consensus once again rules and is immune to tendentiousness). I have not been paying close attention to the details of Noetica’s proposal. Since this is a final call for detail-oriented types to ensure things are correct, I’ll let others go first.<p>I invite the first individual here who has a firm grasp of the applicable issues (American practices, other-dialect English-language practices, familiarity with other well respected manuals of style, and the art of compromise) to scrutinize Noetica’s latest version and weigh in here with their thoughts.<p>And remember, none of this has been etched by lightning into stone; ]. Furthermore, after this “goes to press,” we can always go back to collegial serial tweaking to improve it. But serial tweaking can’t happen until the admins see first-hand that after unlocking WP:MOS, things don’t degenerate like it’s the chimp pen at the zoo after too-few bananas have been tossed in. ] (]) 14:45, 20 July 2011 (UTC)
*'''Unacceptable'''. Does not reflect consensus ''now''; does not reflect a majority; does not reflect the general trend of reliable sources (cherry-picking obscure and rarely used style manuals to support a preconceived position is not following Reliable Sources); does not represent English usage. It is also much more verbose than ]. Yet the changes which would make it tolerable are relatively small:
**In section 1: the parenthesis should read: ''(perhaps instead of a semicolon)'' or be omitted; {{xt|Another "planet" was detected: but it was later found to be a moon of Saturn}} is not current English, where a semicolon would be. (I would omit ''but'' with the dash as well as the semicolon.)
**In section 2: Change the first sentence to, for example: ''There are four ways of forming English compounds: with a space {{xt|black bird}}, with no space {{xt|blackbird}}, with a hyphen {{xt|black-bird}}, and with an en dash. Misplaced Pages prefers the last for relationships involving parallel, symmetric, equal, oppositional, or at least separate or independent elements; idiom may differ.'' The examples are far more than necessary, and are often not consensus.
**In section 3: Change ''Use this punctuation...'' to ''Recast this form where possible; when it is necessary to use it, Wikipedians generally prefer using an en dash in:''
**Remove ]; no article title is ever "decided as optimal"; especially on controversial subjects, they're the best we can do for now.
:Of these the last section is the most important; the present text would make any claim that this guideline is consensus into a falsehood.] <small>]</small> 16:03, 20 July 2011 (UTC)
::* The one thing we certainly agree upon, PMA, is that this doesn’t reflect consensus *now*. Of course, that’s only because you are the only one so far who has expressed an opinion. If there are two or three editors who support this and have similar logic, then there ''will'' be a consensus, albeit not one to your liking.<p>Your unfortunate choice for your first word above (“Unacceptable” rather than “Oppose”) seemed to be chosen to signal intransigence and an unwillingness to budge much in the ‘compromise’ department. At least I ''hope'' that’s all it was meant to telegraph, because if you think you are going to use tendentiousness or editwarring if the consensus here is to adopt it in order to impede progress, think again.<p>Oh… another thing: Tagbombing WP:MOS '''after''' an issue has been discussed and a consensus arrived at, as if those tags are a <nowiki>{{</nowiki> will no longer work. <nowiki>{{DISPUTE}}, {{POV}}, {{DISCUSS}} {{WHINE}}</nowiki> tags are not to be used as “'''Well then, EAT THIS!'''”{{nbhyph}}graffiti to force protracted discussion and eventual concessions to the losing side in a debate after a consensus is clear.<p>Now I’m gonna go pop some popcorn, pull up a chair, and watch as others resist the temptation to (try to) debate you while they instead merely express their views below so we can discern what the true consensus is… ] (]) 16:30, 20 July 2011 (UTC)
::::At last, Greg L makes himself clear. We spent a month on a poll, which showed that there is no consensus on what to do here; by Noetica's count, there is the slimmest possible majority. So it doesn't count; only the present discussion among half-a-dozen regulars counts. Business as usual. ] <small>]</small> 16:54, 20 July 2011 (UTC)
:::::I suppose it takes two to communicate, but you finally got my message point. Yes, the !vote outcomes of past debates don’t factor in to deciding whether a proposal is acceptable ''now''. That’s how compromise and progress is made. Some editors at first have a particular view but later change it after they see tweaks and compromises and buy{{nbhyph}}in from others. Some editors fatigue after protracted debate and defer instead to the opinion of other editors they perceive as specialists who are more well informed.<p>Noetica has labored and repeatedly revised in order to consolidate the best teachings and observations from a variety of editors. What is now under consideration is the newest amalgam designed to achieve a general consensus. It apparently contains elements you opposed in the past, still oppose today, and see as a deal breaker. Understood. Got it.<p>But I am pleased to hear that you now recognize that it is back to “business as usual.” If that means “WP:MOS and WT:MOS will follow ] to the tee,” great. If you think it means “The sword of tendentiousness shall smite those who just talk and agree on things that piss me off,” then, ''no'', it is not back to business as usual.<p>One thing now that we will be sure to do is run this comment period long enough to ensure that all who are inclined to weigh in here are afforded an opportunity to do so. ] (]) 17:17, 20 July 2011 (UTC)
:::It contains elements which half those polled opposed. If we are operating by consensus, that is a deal breaker. If we are not operating by consensus, this is not a guideline. ] <small>]</small> 17:46, 20 July 2011 (UTC)
'''Support''', though not necessarily more than ]. (I'd have to see how that has been edited since I last looked at it.) I was out of the country during the discussion of the first draught on this page, so these are my first comments on it.
*1. ''Best absorbed were wavelengths in the range 28 mm – 17 m.''
::I find this difficult to read, and would spell it out instead. IMO it is not a good example. But IMO we may need an example like "17–28 mm", since there has been at least one editor who's argued that the measurement-unit for the first number is undefined in such examples.
*2. We need to state up front that we do not extend this convention to bound morphemes like ''Franco-''. (Some MoS's I've seen ''do'' en-dash such forms, so this may not be obvious to everybody.)
:::''the Uganda–Tanzania War; the Roman–Syrian War''
::This is getting repetitive. Do we lose anything by moving one up into the rivalry example?
:::''or even the protein-to-fat ratio''
::Remove "even". That suggests this is somehow aberrant, when it's perfectly acceptable.
:::''Following the dominant convention, a hyphen is used in compounded place names and language names, not an en dash.''
::::''Guinea-Bissau; Austria-Hungary''
::::''an old Mon-Khmer dialect; Niger-Congo phonology''
::Change the rational for the first and remove the second.
::(1) Both countries are so punctuated because they are single entities. Compare ''Congo-Brazzaville'' and ''Congo-Kinshasa''. Although Guinea-Bissau and Austria-Hungary are good examples (I could see an edit war over whether Austria-Hungary is one entity or two), the reason for them is not arbitrary, as our wording implies. Also, the claim is ''false'': although only hyphens occur at a national level, at a local level (state parks and the like) official names may have a dash, even an em dash.
::(2) We do not have a convention of hyphens rather than dashes in language family names. All of the "Amerind" language families, for example, currently use en dashes (following, inter alia, the Cambridge Language Surveys such as ''The Andean Languages''), and there have been no objections. Therefore we do not need to spell out an exception for them.
::Also, shouldn't we spell out somewhere our conventions for "hyphenated" ethnicities, rather than one out-of-context example? At least a link?
*3. ''Otherwise recasting is better.''
::Otherwise recasting ''may'' be better. It often is. But often the dashed form is more straightforward and easier to process. We should not make a blanket pronouncement when editors may agree that ''not'' recasting is better style in some cases.
*4. Several people have noted that colons are generally acceptable here. I agree; I've come across several list articles so chock-full of dashes that they've become difficult to read. Colons often look better, though in some formats they may not be appropriate. We should provide them as an explicit alternative.
*Per the section below, while ''carbon–carbon'' bond should use an en dash, C&minus;C should probably use a minus sign, parallel to C=C and C≡C, as the arithmetical signs of a good font are designed to be the same width and centered at the same height, but do not in general correlate to dashes. Maybe a note?
:— ] (]) 18:08, 20 July 2011 (UTC)
* '''Support''' From what I can see, this effort to simplify is a magnificent effort by an Noetica to distill something around which a consensus can form. Any time there is a shepherding author like that, he or she is über familiar with the details to an extent I can never be. But it seems too that others here, including User:kwami, have pored over it as best they can and, while seeing some items that could be tweaked, are overall supportive in the spirit of compromise and getting back to a sense of normalcy. That basically describes my attitude. It may not be perfect, but it is a ''portion'' (dealing with dashes), of a ''manual of style'' at an all-volunteer hobby site. No condemned prisoners will be executed this week over what is being decided here. ] (]) 02:41, 21 July 2011 (UTC)
* '''Support''' – as I read it, Noetica has done as good a job as possible at incorporating all the comments into a new version that's cleaner, and closer to true consensus, than anything we've seen before. None of these provisions will be cast in stone, but we'll be able to unlock things and get back to a process of orderly change by discussion of individual points, instead of going back to the edit wars over such things as the "optionally" in the "ex–prime minister"; it doesn't really matter at this point how particularly difficult points like this get decided, except that the decisions at least have majority support, which they now all do, I'm pretty sure. We can fine tune it after this is done; what we can't do is keep the discussions open on multiple fronts at once, while keeping the MOS locked, and while PMA obstructs all efforts to get it settled. ] (]) 04:59, 21 July 2011 (UTC)
*'''Support''', and if I don't post in this section again within 48 hours, I'll have nothing in detail to say (I'm on a ruinously expensive timed connection for the next day and a half). ] ] 06:04, 21 July 2011 (UTC)
*'''Oppose''', for reasons previously stated about spacing. The objection is partially procedural (I simply cannot see a “clear majority”), and it would appear that no consideration was given to other than “I like it”. I hate to say it yet again, but the guides agree with me. At least two usages introduce needless ambiguity, and I regard this as more serious than others such as whether the dash is spaced in {{xt|Christmas Day – New Year’s Eve}}. Though it is not a basis of objection, I again strongly recommend that nonbreaking spaces be included in the examples. The examples themselves aren’t likely to break, but editors (who might examine the code) learn by example. ] (]) 06:53, 21 July 2011 (UTC)
*'''Support'''. a clear explanation of a very complex subject. Noetica has been scrupulous in taking note of the various points made in the discussion. ] (]) 09:23, 21 July 2011 (UTC)
*'''Support'''. I applaud the good work of Noetica, and would say the time for filibustering is over, bearing in mind the lengthy discussions and overwhelming endorsement by the community. There may be some small details to work out, which would be a lot easier dealt with as amendments to this once passed. ] (]) (aka Ohconfucius) 10:05, 21 July 2011 (UTC)
*'''Support'''. I'm less concerned about the issue than most people here and I'm unlikely to be active in implementation. However, too many experienced editors have wasted too much time under the current arrangements. I'm happy that there is a workable proposal on the table and I think it's time to accept it. ] (]) 16:28, 22 July 2011 (UTC)
*'''Support'''. As per Greg L. ]&nbsp;]&nbsp; 00:21, 23 July 2011 (UTC)

==== Interim replies (after 24 hours) ====

I respond here to all who have posted so far in the subsection above: ]. '''I propose now to wait <u>a further 24 hours</u> for any new commenters to contribute their endorsements or final fixes. New commenters: please post in the next subsection: ], leaving the first one devoted to issues that others have already raised above.''' Please try to keep things orderly, as we work through the last phase of this protracted dialogue. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 13:00, 21 July 2011 (UTC)

===== Answering Greg =====
The experience you bring to the table, along with your continued attention to details of process, is invaluable. I hope you will stay to watch developments, and comment as you see fit as we step methodically toward a resolution here. Just one quibble: your observations on consensus apply generally, and of course the policy provisions at ] are not to be set aside. But I remind you, and all editors here: we work under an Arbcom injunction, and with detailed instructions from ArbCom member ]. For a summary of that rather unusual background, editors can look at the beginning ] of this page. Consensus was supposed to be assessed by ArbCom on 16 July 2011; so we are five days behind already (effectively after ''eight weeks'' of deliberation and then voting). The present task is ''how to reflect the consensus established on the voting subpage, and associated discussion, for ArbCom to evaluate''. That does not mean we fall silent on remaining points of contention; but it might show them in a different light.

<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 13:00, 21 July 2011 (UTC)

===== Answering PMAnderson =====
Your first comment above is headed "Unacceptable". I think no one is surprised at this, and nothing I could in good faith say to you would make an iota of difference. I will address matters of fact on which we disagree, and also extract what I can that does address the purpose of the present phase of discussion.
* You write:
:<blockquote>Does not reflect consensus now; does not reflect a majority; does not reflect the general trend of reliable sources (cherry-picking obscure and rarely used style manuals to support a preconceived position is not following Reliable Sources); does not represent English usage.</blockquote>
::I answer that the draft reflects consensus better anything so far offered, and in fact is not distant from the dash guidelines it is intended to replace&nbsp;– which were also the result of careful collegial work. The draft does reflect a majority (a point I return to below). It most certainly reflects the trend of reliable sources, which are in this case recent general and specialised style guides, major dictionaries (including OED, against which I checked several examples), and related sources. It does reflect best-practice contemporary publishing, as codified in the sources just mentioned. Far from anything in the process being biased toward some "preconceived position", there was perfectly open process and the widest consultation, with anyone able to adduce any source they wanted to. If the present draft "cherry-picked" at all, it selected from palpably weighty opinions in the voting, and as little as possible&nbsp;– ''only'' as necessary to secure the nearest to a perfect consensus that we can achieve in an imperfect world, especially in ''this'' stubbornly refractory corner of the real world.
* You continue:
:<blockquote>Yet the changes which would make it tolerable are relatively small:&nbsp;...</blockquote>
::I answer that those changes are not timely (you had the last week to raise them), not consensual (not voted on, discussed, or otherwise tested), not focused on dashes (though you yourself set up the subpage with a limitation to discussion of dashes, against advice that I put on record), not designed to lessen prolonged and life-wasting wrangling at thousands of content talkpages, not specific as I had requested at the head of the section in which you comment (you refer to examples, but do not say which), and not all "relatively small" compared to the changes others propose here. More could be said; but I confine myself to your objection to "optimal". That one is relatively small; but I find nothing useful in it, since what is optimal in any case clearly amounts to "the best we can do for now", as you put it. Revision is always possible, or course. No one thinks otherwise. Nevertheless:
* You write concerning that last point on optimality:
:<blockquote>Of these the last section is the most important; the present text would make any claim that this guideline is consensus into a falsehood.</blockquote>
::I don't agree; but to remove what you take to be "most important" objection, I will amend the wording in the next draft I present.
* I reproduce your later post in full:
:<blockquote>At last, Greg L makes himself clear. We spent a month on a poll, which showed that there is no consensus on what to do here; by Noetica's count, there is the slimmest possible majority. So it doesn't count; only the present discussion among half-a-dozen regulars counts. Business as usual. </blockquote>
::Greg always makes himself clear. It's refreshing! Some corrections of fact, though:
::*No, we spent more than six weeks on a poll; 60 editors contributed to that page, and it showed dramatic agreement with almost all provisions of the existing dash guidelines. Where there was diversity of opinion, analysis still shows that a majority supported the guideline in question. Useful discussion ensued, and we can draw on it here to make an even more robust, comprehensive, and consensual version of those guidelines.
::*No, again you misrepresent what I have said. Only by applying a severely prejudicial spin can the hard quantitative facts be read as you suggest. You claim that mere voting is not enough. I agree: we must analyse, and look at the reasons and codicils. I have done so accurately; you have not. It was possible to find an equitable solution in the case of every guideline. Not easy, but possible. The results are in the present draft, soon to be refined even further. In any case, your recently discovered cynosure, ], guides all our actions here. And it provides for majority determination where all else fails. You seem to be doing your best to ensure that all else fails. Accept the consequences.
::*No, not half a dozen regulars. This time you find yourself opposed by the majority of those who voted, in the very subpage that you set up.
I will pass over in silence your later post. It adds nothing that I can constructively address.

<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 13:00, 21 July 2011 (UTC)
:::::By Noetica's count, I find myself opposed by 15 out of 29 editors. I don't think that count is correct, but that is not the point at issue; if it were correct, it would not be consensus.

:::::This is not a technicality: if there is genuine consensus in this matter, there would be reason to suppose that most editors ''not'' surveyed would agree with the consensus; and we could continue on that ground until shown wrong. But there is no real reason to suppose that so slim a majority represents even a majority of editors; under our uncontrolled conditions, it may or may not, as likely the one as the other. ] <small>]</small> 20:11, 21 July 2011 (UTC)

:::::Noetica's claim of untimeliness is false in fact; I did object last week. It is, more importantly, another policy violation: Noetica has invented rules without consultation, and without stating them, which would require anybody who objects to this proposal to log on in a certain time. But ]. That is policy. ] <small>]</small> 20:32, 21 July 2011 (UTC)

;Follow-up answers for PMAnderson
* You write: "By Noetica's count, I find myself opposed by 15 out of 29 editors." In doing so, you once again distort the truth so transparently that I can comfortably defer the refutation while I deal instead with serious talk, elsewhere in the section
* Since that palpable misrepresentation is the premise for your next point, I do not dignify it with a separate response.
* If you think me guilty of "policy violations", or single ''me'' out (!) as trifling irresponsibly with Wikipedian principles or with ArbCom's specific instructions, I sincerely hope you will take the opportunity to expose all of those issues when the imminent final draft is presented to ArbCom for certification, a week late. Who knows what other issues might be brought forward&nbsp;– by whom, and concerning whom?
<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 15:02, 22 July 2011 (UTC)

===== Answering Kwami =====
Welcome back. A pity that circumstances prevented your coming in earlier. Thanks for the points you now offer. My answers:
* On "wavelengths in the range 28 mm – 17 m", I agree that this form is not the easiest to read. The use of en dash is not the only option, of course; but it seemed to me from discussion that this was considered the ''best'' implementation, if one had already settled on an en dash. (I return to this below.)
* On "bound morphemes" like ''Franco~'', I had thought the point was solidly made in the examples. There are tricky cases to add ({{xt|Sino~North Korean détente}}??). I have something to say about this, but I hold off for now. Let's deal with it in the normal course of discussion, once all this business is behind us. It's way past everyone's bedtime!
* You mention these two examples: "the Uganda–Tanzania War; the Roman–Syrian War", and you comment:
:<blockquote>This is getting repetitive. Do we lose anything by moving one up into the rivalry example?</blockquote>
::I smiled a wry smile when I read that. I simply invite you to reflect on the prehistory of the present dialogue, involving a certain North American war. Yes: we need both. (Remember also your own subtle alteration of the text on the voting page, to include an {adj–adj noun} case.)
* You want ''even'' omitted from "or even the protein-to-fat ratio"? Consider it done!
* You comment on "Following the dominant convention, a hyphen is used in compounded place names and language names, not an en dash." You say several things; I pick up first on this part:
:<blockquote>Although Guinea-Bissau and Austria-Hungary are good examples (I could see an edit war over whether Austria-Hungary is one entity or two), the reason for them is not arbitrary, as our wording implies. Also, the claim is ''false'': although only hyphens occur at a national level, at a local level (state parks and the like) official names may have a dash, even an em dash.</blockquote>
::I do not think our wording suggests that the matter is arbitrary; it simply appeals to a "dominant convention". The claim concerning its dominance is ''not'' false: it dominates in the sense that it has strong adherence, statistically and in regimented practice. What did you read "dominant" to mean?
* You write:
:<blockquote>We do not have a convention of hyphens rather than dashes in language family names.</blockquote>
::OK. But we need one; and the use of hyphens is by far the dominant convention here. In this case and also for countries, why not endorse what the major sources almost universally choose to do, in a painfully thorny area? You can cite exceptions; so can I. But to what end? I say we want a guideline; and I submit that we don't want a patchwork of disparate, perpetually disputed titles for articles on kindred themes.
* On recasting cases like {{xt|ex–prime minister Thatcher}}, you want a softening. Others want a hardening, so that such forms are ''always'' recast. Still others (like myself) detest that form, and would want a ''hyphen'' or recasting, and never an en dash. The draft form of this guideline is a cunningly crafted compromise. No one is completely happy; but everyone should be able to live with it. The pain is shared, and the guideline serves to defuse hundreds of future disputes&nbsp;– if people will consult MOS for a recommendation based on sound principles and precedents.
* On colons and their preferred use, I agree. But the point is already made, isn't it? I suggest you read the draft guideline for sentence-level dashes again.
* On the carbon–carbon bond: the guidelines address continuous prose, not specialised chemical notations. We have ] for that. But we can't point to every location that may be peripherally relevant. The guidelines must be readable and focused, and show carefully selected indicative examples.
* On your extended remarks concerning hyphens and slashes, nothing needs to be done here. For eight weeks we have discussed dashes, and hyphens and slashes only as they bear most directly on questions concerning en dashes. Another time! When the present business is finished.

Kwami, I hope you will continue to contribute in these final days of the process. Your expertise is much appreciated. Please remember: these ''are'' the final, polishing stages.

<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 13:00, 21 July 2011 (UTC)

::Okay, most of this is pretty minor. (Of course I remember the Mexican–American War dispute. But I thought we could consolidate those examples so we're not so repetitive.) But re. languages: What you propose is making a specific counter-convention for language families. No other field is made to conflict with the semantic use of dashes, not even geographic names. Why this one? If it's only because most sources use hyphens, as you say, that was Anderson's argument for abolishing dashes altogether, so again, why this one? I don't see why all of the language-family articles currently using en dashes should be changed to hyphens just because ... what was the reason again?
::As for country names, please consider rewording from
:::''Following the dominant convention, a hyphen is used in compounded place names''
::to
:::''A hyphen is used in compounded (self-standing?*) country names''
::Otherwise we're going to have problems when official place names have dashes, for example '']'' as punctuated in the Protected Areas of British Columbia Act, and people on those articles decide that the MOS is therefore useless for deciding punctuation. *I also worry about cases like the ]. Perhaps that example could be added to the 'border' and 'treaty' examples? — ] (]) 19:32, 21 July 2011 (UTC)
::::It would be nice if discussions of my position were based on something I had actually said. I do not propose to "abolish dashes altogether"; I never have. I support ''permitting'' hyphens in words where they are normal usage. ] <small>]</small> 21:35, 21 July 2011 (UTC)
:::::Thanks for telling us. I did not understand that from your arguments up to now. — ] (]) 00:20, 22 July 2011 (UTC)
::::::Sort of like he fought to "permit" a hyphen in Mexican-American War, even though it was long stable with an en dash. ] (]) 00:39, 22 July 2011 (UTC)
::::::::Well, yes, this would include permission to spell ''Mexican-American War'' the way the sources do; whether we use a permission in any given case is a matter of judgment (in which ]. ] <small>]</small> 01:44, 22 July 2011 (UTC)

::'''Follow-up answers for Kwami'''
:::I have thought long and hard about your suggestions, and done some delving. I have changed my mind about one thing.
:::* I still think that the examples are not viciously repetitive. They make subtle distinctions despite appearances; and we know from experience what vexations eliding such distinctions can lead to. I am not inclined to alter the set of examples generally.
:::* On the other hand, I am ready to remove the entire guideline for compound place-names and languages (including language families). I think there will be no serious dissent. There does seem to be a "dominant convention" in favour of hyphens, looming over other considerations (cf. chemistry's local customs, or the post-Linnaean niceties of botany and zoology); but I concede that it is not overwhelming. You mention ''The Andean Languages''; well, Cambridge does indeed use en dashes and hyphens to make distinctions that others obliterate. Routledge follows very similar conventions; and over the last year I have been collecting examples from Glanville Price's ''Encyclopedia of the Languages of Europe'' (Blackwell, 1998) that must cheer the pedant's flinty heart: "Basque–Icelandic pidgin", but "bilingual Cornish/English speakers"; "Abkhaz-Abaza" (Abaza having two dialects: Bzyp and Abzhui; who knew?☺), but "a single Abkhaz–Abaza dialect continuum" all the way from Abzhywa to Ta'ap'anta; "Chechen–Ingush Autonomous Soviet Socialist Republic" and "a joint Chechen–Ingush written language", but "the Chechen-Ingush speech community" (I seem to recall they had a war about en dashes). The four-volume ''International Encyclopedia of Linguistics'' (Oxford; I only have the superseded 1992 edition) uses hyphens throughout ("Niger-Congo languages", as against Oxford's core style references and OED: "Niger–Congo languages"), but en dash in cases like "New Ireland–Tolai languages" and "North Trans–New Guinea Languages". In short, in these important reference works semantically based consistency is the principle, but managed and attenuated according to some general standard (Cambridge or quasi-CMOS, in the cases I have examined). Semantic distinctions are extraordinarily refined in this domain, and many standard works lapse into frank inconsistency, like Brown and Ogilvie's '''' (Elsevier, 2008), which alternates between "Uto–Aztecan" and "Uto-Aztecan". Let them work it out among themselves, and let's defer the issue for special consideration later. Our general guidelines will suffice till then. As I have suggested, the same should apply to the other matters you raise (so late, perforce); they can and should be addressed when we come to review the guidelines for hyphens and slashes, or some other opportunity.
::<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 13:27, 22 July 2011 (UTC)
:::::I was going to suggest removing those myself. If there is evidence of an exception needed in some field, the relevant project can take that up on their own style page. In looking at books for en dashes in compound language family names, I did find a few, so I suspect there's no real rule about that one way or the other. ] (]) 13:55, 22 July 2011 (UTC)
::::::How bout we leave in the country examples? ''Guinea-Bissau'' is a dab from ''Guinea-Conakry'' (though no-one uses the latter), so these are not co-equal elements. But it could easily cause confusion, since a country and its capital are two independent things. ''Austria-Hungary'' is an excellent example, since you really could debate that one ad nauseum. And I think ''Polish–Lithuanian Commonwealth'', or something like it, would be good to include, so that people don't become absolutist. I agree with leaving the language families out; they can be addressed, as you say, at the wikiproject if they are disputed. — ] (]) 17:07, 22 July 2011 (UTC)
::::::::How would you debate ''Austria-Hungary''? Who uses anything but a hyphen? Who recommends anything else? ] <small>]</small> 20:31, 22 July 2011 (UTC)

===== Answering Dicklyon =====
Thank you for respecting the intention of this phase of the process. Yes, of course we can fine-tune things later. Consensus can change, and the guidelines can be refined, and polished to reflect consensus even better.

<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 13:00, 21 July 2011 (UTC)

===== Answering Tony =====
Your terse support is helpful as we advance toward a resolution. But do get back to a proper connection soon!

<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 13:00, 21 July 2011 (UTC)

===== Answering Jeff Conrad =====
I don't know what others think Jeff, but I acknowledge your obvious experience and expertise. I know that you don't like everything in the present draft. As I have pointed out, I don't like it all either! In fact, I would probably object to more in it that you. Please think again about that. Neither of us is writing a guide to epitomise his own practice. On specific points:
* You write:
:<blockquote>The objection is partially procedural (I simply cannot see a "clear majority"), and it would appear that no consideration was given to other than "I like it".</blockquote>
::Well, you at first objected (almost a week ago) that a "clear majority" was not something to be looking for. Well, what ''is'' to determine the matters that you contest? What is ''your'' analysis of the numbers, and the comments, and the ensuing discussion, on those matters? And do you suggest that I act upon the principle "I like it"? ''Where'', in the name of all that's Jimbic? I have deliberately set aside what I like. (Have ''you'', by the way? As firmly as I have?) I am assuming that we both want guidelines that will help prevent the month-long wars over article titles that led to ''all'' of this, right? Well, at the head of the section in which you comment, I made this request:
::<blockquote>If you absolutely must object to anything, do so soon and clearly, proposing a precise solution, rather than calling vaguely for something to be redrafted.</blockquote>
::That, I suggest, was a fair request; but you have not done what I fairly asked. So now, here is my specific request of you; please attend to it urgently:
::<blockquote>Jeff, please draft and show here your own redrafting of the guideline for ranges with spaced components: in full, with examples. Do not shy way from controversial cases that might come up at several talkpages of articles, as the present draft does not. In short, make a guideline that guides, and omits nothing relevant. Then, please, do the same for the guideline concerning {{xt|ex–prime minister Thatcher}} and such cases. Complete, and easing the problem of replicated disputes at as many talkpages as possible.</blockquote>
::That is no playful or petulant request. I'm serious. If you can capture consensus better and with less likelihood of ruinous disputes arising, your alternatives should be considered.
* On {{xt|Christmas Day&nbsp;– New Year’s Eve}}, I have twice answered your objections and explained why it is a date range, how it differs semantically from {{xt|New York–Chicago flight}}. Please address that case in your draft guideline; and please also show how you would punctuate {{xt|Christmas 2001Easter 2002}}, and include the principles by which you determine these things.
* You write:
:<blockquote>I again strongly recommend that nonbreaking spaces be included in the examples.</blockquote>
::I understand why; and I have answered that. You have not answered me. You had a week to raise the matter, but did not until extremely late, delaying my scheduled posting (of which I gave 24 hours' notice). No one else has called for this, and there was agreement earlier not to complicate the dash guidelines with matters that are more efficiently treated generally. The general treatment could show en dashes with &amp;nbsp;, but there is no call for cluttering the dash guidelines in this way. They are intricate enough!
* I invite you to reflect on the enormous difficulty of the present task. I know you have addressed it energetically. Please consider, though, how long all of this has taken ''me''. How much work lies ahead depends partly on you, now. Please take ''some'' questions that I put above as rhetorical; shorten discussion, and make life easier. I have done all I can to meet your concerns. Now meet mine! Are you certain that holding out is worthwhile, where I and others suppress objections that are at least comparable to your own?
<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 13:00, 21 July 2011 (UTC)

:A few comments. I’m sorry for the length, but don’t know how to cover the issues in a couple of (silent) sound bites—that’s why I simply referred to the guides in the polling. I hope this answers some of your questions.
----
{| class="navbox collapsible collapsed" style="text-align: left; border: 0px; margin-top: 0.2em;"
|-
! style="background-color: #aaffaa;" | '''Style guide abbreviations'''
|-
|
<blockquote style="background: #eeffee; border: solid black 1px; padding:1ex"> {{User:Noetica/StyleGuideAbbreviations1}}</blockquote>

|}
----
:*'''“I like it”''' was directed at the votes under ''6b. when there is a space within either one or both of the items'', not at you—I’m sorry if I did not make this clear (musta been the typographical quotes {{nowrap|. . }}). As nearly as I can tell, the only ones to state much of anything other than “I (don’t) like it” were me and macwhiz, who cited style guides—I cited many, macwhiz cited CMOS16. In a sense, I could tally the voting as 2–0 in favor of closed-up usage, but that would obviously be silly. The issue that I see as having been given little of any consideration is a simple one: given that most of the high-ASR (Amazon Sales Rank) guides call for closed-up use, why would we diverge? You mentioned five major guides, but did not indicate what they were, so let me begin with what I was referring to. A while back, we looked at ASRs of several widely used guides on Amazon’s US and UK sites. I repeated this exercise a couple of days ago, adding a couple of glaring omissions, especially Butcher, and included Amazon Canada (they don’t seem to have one for Australia). I eliminated guides that did not deal with en dashes from the final results, and was left with 16 guides. I can provide the complete list of results if needed, but I’ll summarize for now:
:**US:Of the 16 guides, all but #10 (CGEL) and #16 (BCE) call for closed-up use exclusively.
:**Canada:All but #11 (BCE) and #12 (CGEL) call for closed-up use.
:**UK:All but #5 (BCE) and #9 (CGEL) call for close-up use.
::I don’t have CGEL, so I don’t know what it calls for. And full disclosure: the results include CMOS 14–16 and Turabian, so there is arguably a bias. Nonetheless, the older versions of CMOS sell far better than I would have guessed.
::We’ve both acknowledged the many limitations of ASR, but absent access to expensive commercial publishing databases, ASR seems better than simply “top guides” (the ones I like, of course). Though it might be nice to cite “de facto” practice in some cases, I think doing so in a verifiable and statistically valid way would be nearly impossible. So perhaps ASR could be regarded simply as a ] rather than a mere WAG. Accordingly, I don’t suggest that the recommendations of the listed guides are necessarily dispositive, but I do suggest that if we are to diverge from what seems to be fairly broad practice, there should be at least some reason. So much has been said here that it’s tough to track them all, but I don’t recall recent mention of why we ''should'' space en dashes at all. The only guide that I’ve examined that calls for spacing is BCE, so I’ll start with that:
:::However, spaced en rules ''may'' be spaced between groups of numbers and words to avoid implying a closer relationship between the words or numbers next to the en rule than between each of these and the rest of its group:
::The assumption is apparently that the en dash binds more tightly than the space; although this hardly seems unreasonable, it clearly is not universally held, especially in North America (and at least nominally, at OUP). As I have said, it’s tough to make the case that one practice is “right” and that the other is “wrong”, but that the preponderance of the guides, especially if weighted for ASR, call for closed-up use suggests to me that blowing off NA practice should at least have some basis.
::As I’ve also said, one great advantage of NA practice is that there is little likelihood of confusion among the em dash, en dash, and minus. Forcing the em dash is clearly a nonstarter, because that’s just not the way many British publishers do it, and they aren’t likely to change. But although it’s not my preference, there is little likelihood of confusion with a minus, or with a range/whatever en dash if the latter is closed up.
::I’ve suggested that the issue is one of “operator precedence”. At least in NA, it would seem to be something like “.”, “-”, “ ”, and “–”; with such an order, no ambiguity arises from closed-up use. With much British practice, the perceived order of the space and en dash would seem to be reversed, and some ambiguity could conceivably result. Practically, I agree with A. di M. that anyone in her right mind would fairly quickly recognize that “28&nbsp;mm{{ndash}}17&nbsp;m” meant a range rather than a difference, and the same is probably true for “20&nbsp;kHz{{ndash}}20&nbsp;Hz”. But let’s face it, the same is true for “28&nbsp;mm–17&nbsp;m” and “20&nbsp;kHz–20&nbsp;Hz”; with either approach, there may be some “initial ambiguity” that slightly interrupts the flow of reading, but in most cases, the meaning is probably quickly resolved. In this case, I would maintain that the “initial ambiguity” arising from the spaced use is considerably greater given the strong association of a spaced minus-kinda thingie with subtraction. Perhaps it’s just be, but with CSE and NIST I seem to be in reasonable company. And, whether they had this specific concern in mind, the significant number of general-purpose guides that recommend closed-up use arrive at the same end. Incidentally, my reference to “not very nice people” above was not meant to imply that that “the 20&nbsp;kHz–20&nbsp;Hz propagation delay” was a not very nice usage. But if Frankfurter had ever had to deal with en dashes, he well might have chosen similar words {{nowrap|. . .}}.
::As several of us have stated, “28&nbsp; to 17&nbsp;m” well may the best approach when used as a nominal, but with adjectival use, the close-up dash seems the least of evils.
:*'''Ranges of dates.''' Much the same applies to ranges of dates, although at least to me, the initial impression of subtraction is slightly less than with physical quantities because I don’t normally subtract dates. Nonetheless, I maintain that there is no greater “initial ambiguity” with “21&nbsp;July–16&nbsp;August” than with “21&nbsp;July{{ndash}}16&nbsp;August”. And I return to the example of “21&nbsp;July{{ndash}}3&nbsp;September 2012”: is it the period between now and then, or just the duration of the Obama–Palin debates? Here is a case of genuine ambiguity rather than simply “initial ambiguity”. Using “21&nbsp;July–3&nbsp;September 2012” avoids the genuine ambiguity. From this, it should be clear how I would handle “Christmas 2001–Easter 2002”. And the rule is simple with NA and OUP practice—always close up. A fallback rule might be inferred from BCE: space when there is a number on one side of the dash and alphabetics on the other. But I would look more to her use of ''may'', because the preponderance of bestselling guides don’t seem to find ambiguity with close-up use. Again, I don’t suggest that there is only one way to do it. But if indeed we generally follow the sources, the advice of a seeming preponderance of guides would seem to merit serious consideration, which I don’t think it was given.
::Now perhaps my explanation ''is'' eleventh hour. But my citation of a plethora of guides was not, and their recommendations seem to overwhelmingly support the position I advocated. As I mentioned, I would be OK with spacing the dash in complete ranges, especially because, as Tony mentioned, there are zillions of these at the beginnings of biographies, and I think it better to follow the well-established style in that instance. In most other cases, ''I'' would probably use ''to'' or ''through''.
:*''Nonbreaking spaces.''' My intent here was only to include them in the code for the examples, not to attempt to explain them—it’s covered elsewhere, as you noted. But if they’re missing from the examples, it would seem that the MOS would fail to follow its own advice. And the MOS is the potent, the omnipresent teacher. For good or for ill, it teaches all editors by its example. ] (]) 23:16, 21 July 2011 (UTC)

:I’ve added nonbreaking spaces to a few dates (and the quantity range) in the draft. I did not add the space to {{xt|1–17 September}}; I would probably use one (it’s no worse than 10:30&nbsp;pm), but wonder what others think. Whether or not the space is added, this clearly is an issue to be covered elsewhere. I′ve avoided any of the other changes discussed above on the assumption they would not be well received. ] (]) 04:36, 22 July 2011 (UTC)

;Follow-up answers for Jeff Conrad
:* Thanks for adding &amp;nbsp; in the code for the draft. I was deferring that until it was finalised, but it's good that it's done now. (For {{xt|1–17 September}} I would consider context; I think it's marginal.)
:* For some guides that agree pretty well with Butcher's on spacing of en dashes, see in the archives of this talkpage (search on "These sources may be of some value").
:* I had not wanted to raise it, since I wanted the discussion of spacing in ranges to be fresh and unprejudiced, but in fact WP:MOS already calls elsewhere for spacing such as most voters favour in our recent poll. See ], and search on "range". For more detail, and for treatment of other ranges, see ] (for example) and again search on "range".
:* I am as ready as anyone else to overturn anything irrational or that lacks consensus; but those guidelines ''are'' rational and consensual, as established in long deliberations at two talkpages with many participants (search the archives). The only things that are striking in the present draft are two examples: {{xt|Christmas Day&nbsp;– New Year's Eve}} and {{xt|Christmas 2001&nbsp;– Easter 2002}}. They accord perfectly with the principle laid out in the draft, and with the principles already used in WP:MOS and WP:MOSNUM.
:* Do you still want to make a different principle (or principles) for those two date cases and for the number ranges with changed units? I have twice asked you, very explicitly, to draft what you would prefer. You have not done so, but continued to make points generally without showing any black-letter proposal. What do you expect me to do? How long would you like me to second-guess what hard-and-fast wording would satisfy your need?
:* I could very easily roll over and remove something from the draft or soften something else&nbsp;– or make something ''vague'', which more than one style guide has done when faced with an impasse. I for one have no time left to go again over the details that you and your interlocutors produced over ''weeks'' of discussion. You had every opportunity to tease out salient issues and resolve them, or to push the boundaries and find the interesting cases that I have adduced and put in the draft. But you did not. The principles tested in voting and discussion on the subpages are further tested in the hard examples I produce. Do they stand up? I think so! If you disagree, there must be something wrong with the principles you and others forged or agreed upon, not with the examples. I have asked you to show otherwise; you have not.
:* I can with equal ease take stock right now, and deliver a consensus to ArbCom to certify. The process has been long, exhaustive, and exhausting. Everyone has compromised; and who can find anything ''new'' to say? I can't, beyond pointing to long-established guidelines here that appear to be confirmed in fresh examination by many editors.
:* On the grounds laid out above, and earlier, I make a last appeal to you: concede a little more. We all have (with the exception of PMAnderson, of course). I value your knowledge and acumen; and your imprimatur would give a further seal to a draft that already does all that anyone could have hoped for.
:After another 24 hours I want to lock in a truly final draft, and take the next steps for its incorporation in WP:MOS. I hope you will support this move&nbsp;– just as almost everyone else has, through collegial discussion and negotiated concessions. You will understand if I cannot wait any longer though, nor enter into still more wordy to-and-fro. Eight weeks (with months before that, of bickering) is about my limit. And I ''know'' I speak for others too when I say that.
<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 14:46, 22 July 2011 (UTC)
::You need merely change as suggested, or at least in that direction. That would settle the bickering; that is what consensus is supposed to do.

::I applaud JeffConrad's method; I would like to say that before this is settled. It shows that on this point, he has the strength of the arguments and the bulk of the style guides with him; in short, he follows the sources. ] <small>]</small> 20:29, 22 July 2011 (UTC)

::*Guides that support Butcher’s advice: Texas State University’s editorial style guide—can I see what the local community college recommends? Can I include a paper that I wrote on this topic over 30 years ago? This isn’t to knock Texas State, but to put it with the more widely used guide suggests desperation. For popularity, ''The Cambridge Guide to English Usage'' is in the mid-to-high 400,000s in ASR for Canada, the UK, and the US. If today’s rankings were inserted into the lists I recently compiled, this guide would rank 17, 10, and 10, respectively. The Australia-specific guides barely hit the radar in any of these rankings, but this obviously is misleading because they probably sell far better in Australia. Once again, I acknowledge that only so much can be inferred from ASR, but so far, it’s the best thing I’ve seen proposed here as a reasonable means of quantifying “top” style guides. And the data still suggest that the current and proposed wording is at odds with the overwhelming majority of guides. My objection remains that this wasn’t even considered, and remind that I mentioned this when I voted on 5&nbsp;June—not a single person responded.
::*Discussion of spacing in ranges: I’m willing to stand corrected, but I don’t see much in the discussion about ''why'' some range dashes should be spaced—it was largely “I (don’t) like it”. As mentioned, the only thing other than “I (don’t) like it” was the mention of style guides by two of us. Why did I not raise some of these specifics earlier? Recall that the ArbCom motion was to settle a dispute relating to article titles. This polling began as an informal effort by PMAnderson to see where we agree and where we disagree. It apparently morphed into a vote on what the MOS should say about dashes, but without any formal announcement of such. Even with a formal announcement, the procedure that I usually seen almost everywhere is to summarize results, securing agreement that there is agreement with the inferred conclusions, and then moving to the next step. That wasn’t done here, and I still maintain that consensus was not found on at least a couple of items.
::*What’s rational and consensual is sometimes in the eye of the beholder. If I were to summarize the archived discussion linked above, I would say that 1), there clearly was no consensus, and 2), the support for the current wording was primarily from two editors who pushed their preference pretty hard. There’s certainly nothing wrong with pushing one’s preferences—I do it just like anyone else—but a hard push doesn’t necessarily indicate consensus. I don’t suggest that the proposed practice is irrational, but simply that it’s no more rational than North American practice—and the latter avoids several problems, so in some cases, the current and proposed practice ''is'' irrational. I also suggest, based on the data presented, that it’s the minority practice—this doesn’t mean that it’s wrong, but perhaps does suggest that proscribing the more common practice is not reasonable.
:::I would finish my comment here by saying that I see closing up range/etc. dashes as affording no disadvantages whatsoever in comparison with spaced usage in some cases, and it does afford a few advantages—closed-up usage largely precludes confusion with parenthetical en dashes and minus signs, and it avoids ambiguity in the instances of two dates followed by the year of the ending date. So at worst, it does no harm, which is essentially what I said to PMAnderson and a few others in cases where the en dash was seen as having little value. To me, that makes North American practice clearly more rational.
::*I’m surprised that you think I’ve failed to respond to your requests to say how I would handle it, because I clearly have so indicated:
::*#I would follow majority practice and always use range/etc. en dashes closed up, avoiding the need for any special rules.
::*#Barring that, one possibility would be to draw literally from Butcher’s examples and space range/etc. en dashes when there is a number on one side of the dash and an alphabetic on the other side. I thought the meaning was obvious, but examples would be all date examples in the proposed draft but {{xt|Christmas Day–New Year’s Eve}}.
::*#Without additional qualification, dashes would be spaced in ranges of physical quantities with changed (or simply repeated) units. I think I made it clear that, to avoid possible confusion with subtraction, I would not space a dash in a range involving physical quantities, so no special rule is needed for changed simply repeated units, leading to {{xt|28&nbsp;mm–17&nbsp;m}} and{{xt|17&nbsp;mm–35&nbsp;mm}}. Clearly, not everyone seems to see the problem of confusion with a minus (e.g., the EU guide apparently does not), but I do find support from some pretty solid sources in NIST and CSE. I don’t see any real drawback to closed-up usage here, and it does seem to preclude initial confusion with subtraction. Again, at worst it does no harm.
::*#And yet another possibility would be to borrow further from Butcher: en dashes ''may'' be spaced in these situations, which in effect would be to allow either North American or non-OUP British practice, much as we treat (and propose to treat) parenthetical dashes. I’ve stated this as well.
:::I haven’t bothered with formal draft of these points because I think I’ve made it quite clear what I would propose, and without reason to believe that such a draft would get serious consideration, I don’t wish to spend the time or effort. I’ve already invested more time and effort just in this discussion than I’ve otherwise spent on punctuation in my entire life (aside, perhaps, from a similar discussion about quotation marks).
::*I hate to be the one in opposition, but I simply cannot join an “across the board consensus” that I cannot see. One possible approach would be to recognize that we don’t really have consensus on this issue (and perhaps on using a dash in open compounds not covered by other rules, e.g., {{xt|Chuck Berry–style lyrics}}), and refer the matter for further discussion, as Dick Lyon suggested. The issue of spacing dashes in ranges would have little impact on article titles, and although a title conceivably could be affected by the second issue, actual instances would seem few and far between. I would endorse such an approach.
::] (]) 08:45, 23 July 2011 (UTC)

;Final responses to Jeff Conrad
Jeff, of course I am disappointed that you could not compromise enough to accept the present draft (soon to be posted with amendments), but of course I respect your decision. Again, there are too many words for this latest of late stages. I will respond to just a little of what you write this time.
* "Guides that support Butcher’s advice: Texas State University’s editorial style guide—can I see what the local community college recommends? Can I include a paper that I wrote on this topic over 30 years ago? This isn’t to knock Texas State, but to put it with the more widely used guide suggests desperation."
::That is a misleading and unworthy comment, Jeff. I linked to an archive to keep things simple, and to spare myself yet more typing of text to no effect. I listed ''six'' sources, and of this one I wrote: "Texas State University's editorial style guide <u>This is one of several academic sources online that prefer the general style given in sources above, though perhaps implicitly.</u>" Do you want still more of the same? Please go looking, as I did.

* "For popularity, ''The Cambridge Guide to English Usage'' is in the mid-to-high 400,000s in ASR for Canada, the UK, and the US. If today’s rankings were inserted into the lists I recently compiled, this guide would rank 17, 10, and 10, respectively. The Australia-specific guides barely hit the radar in any of these rankings, but this obviously is misleading because they probably sell far better in Australia. ..."
::You go on to acknowledge the limitations of that sort of count. Well you might. We have been over this ground before, and much more that you seem intent on traversing yet again. You don't like "clear majorities", it seems; but you appeal to the numbers when it suits your purpose.

* "My objection remains that this wasn’t even considered, and remind that I mentioned this when I voted on 5&nbsp;June—not a single person responded."
::You should perhaps have insisted at the time; and not diluted a core message with a torrent of text. I took up points of yours at great length, and with meticulous concern for detail. But I can do only so much.

* "Discussion of spacing in ranges: I’m willing to stand corrected, but I don’t see much in the discussion about ''why'' some range dashes should be spaced—it was largely 'I (don’t) like it'."
::Yes, that is regrettably the way of things, often. Recall that Casliber had specifically called for quantifiability as opposed to mere spread of discussion. I think we should consider both.

* "This polling began as an informal effort by PMAnderson to see where we agree and where we disagree. It apparently morphed into a vote on what the MOS should say about dashes, but without any formal announcement of such."
::I agree. Ill-planned, or not planned, from the start. But voting (with comments) grew naturally out of two weeks of discussion of what people wanted to talk about over the subsequent six weeks. Anyone could have attempted to re-focus discussion. Myself, I take it that the role of MOS as Misplaced Pages reference-point for punctuation was not brought into question or discussion. I therefore take this as accepted: for titles as for text.

* "What’s rational and consensual is sometimes in the eye of the beholder. If I were to summarize the archived discussion linked above, I would say that 1), there clearly was no consensus, and 2), the support for the current wording was primarily from two editors who pushed their preference pretty hard."
::That's the real world, Misplaced Pages-style. Everyone had every opportunity to raise awareness and to steer discussion. I did all I could to extract a workable version of the guidelines we discussed, for real use in real editing. Nearly everyone approves&nbsp;– well enough! I have said to you several times that I myself disagree strongly with some provisions in the draft. Everyone does! That is not the point. Users of CMOS have their own private sets of gripes with it; so do users of NHR. That's how it is, with manuals of style. There can be consensus to adopt it, even if no two editors agree about which details are good and which are anathema.

* "I don’t suggest that the proposed practice is irrational, but simply that it’s no more rational than North American practice—and the latter avoids several problems, so in some cases, the current and proposed practice ''is'' irrational."
::Many editors find it workable; I am an experienced editor, and I am among them. And don't speak of "North American practice" as if there were one. There are several. Yours and Dick's, for example, appear to differ considerably.

* "I would finish my comment here by saying that I see closing up range/etc. dashes as affording no disadvantages whatsoever in comparison with spaced usage in some cases, and it does afford a few advantages—closed-up usage largely precludes confusion with parenthetical en dashes and minus signs, and it avoids ambiguity in the instances of two dates followed by the year of the ending date. So at worst, it does no harm, which is essentially what I said to PMAnderson and a few others in cases where the en dash was seen as having little value. To me, that makes North American practice clearly more rational."
::And I find otherwise, and some North Americans find otherwise regarding the various practices in your continent. We've had weeks to sort all this out. I've done my best to compromise, and to follow all that was happening. Sorry if you are not satisfied; let's all live with the ways we are not satisfied.

* "I haven’t bothered with formal draft of these points because I think I’ve made it quite clear what I would propose, and without reason to believe that such a draft would get serious consideration, I don’t wish to spend the time or effort."
::I said explicitly (twice) that I needed to see a draft. I said that it would deserve consideration. You "don’t wish to spend the time or effort" of drafting a small section, where I have laboured to produce an ''entire'' draft, and revise it at least twice, and discuss it, and fend off calumnies without end, and endure prolonged last-minute reiterations of issues? Hmm.

* "I hate to be the one in opposition, but I simply cannot join an 'across the board consensus' that I cannot see."
::You go on to say that we could come up with a partial consensus, for now. That was not our brief. We must work with realities, and with the task we face. I'm sorry you were not able to do that; but it is completely beyond my control&nbsp;– which is OK!

Jeff, thanks for your efforts. I will press on and post a draft that will bring this chapter of a monumental and dreary epic to a close. The big picture concerns the whole Project, and its quality. Let's all continue to focus on that, in the ways they we each see fit.

<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 10:29, 23 July 2011 (UTC)

:I strongly disagree on most of these points. I doubt that going through them would accomplish anything, so I shall not do so. ] (]) 04:57, 24 July 2011 (UTC)

===== Answering Colonies Chris and OhConfucius =====
Thank you! Much appreciated. Expressions of support, suggesting that we just go ahead and finish it, with all that hard work behind us, are enormously helpful right now. I hope there will be some more like that.

<font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 13:00, 21 July 2011 (UTC)


==== Endorsements, and final points to fix (II) ====
]</small></sup> 13:00, 21 July 2011 (UTC)]

*'''Ship it'''—Thanks Noetica! ] <small>(] | ])</small> 17:36, 22 July 2011 (UTC)
* '''Ship it''' No manual of style in a cross-country venue where ''*anyone can edit*'' can make every editor happy with every detail. Clearly, Noetica has done an exemplary job at trying to meld something that around which a consensus can form. ] (]) 22:25, 22 July 2011 (UTC)
* '''Discard it''' and replace by ], which is more accurate and less wordy; the proper word for this draft is "execrable". All comments on points of detail, including Kwami's and JeffConrad's, have been blown off; half of us (in two separate polls) have opposed these requirements; this doesn't reflect the usage of reliable sources. ---- <small>(This post was by PMA on 01:05, 23 July 2011, note left here by Greg L; delete if/when this is signed,)</small>

==== "Sidebar" issues, arising from recent discussion above ====
]</small></sup> 00:01, 22 July 2011 (UTC)]

===== Sidebar on hyphen-related stuff =====

Somewhat off-topic, but shouldn't we have a spacing comment for slashes too? (Not here, of course.) I was reminded of this with the new Plutonian moon, which has been listed with both of its provisional designations as "P4 / S/2011 P1". The spaces around the first slash are obviously necessary, and AFAIK generally the convention whenever one of the elements being joined by the slash itself contains a space. — ] (]) 18:36, 20 July 2011 (UTC)
'''Continued inside the navbox. Click on "show" at the right:'''
{| class="navbox collapsible collapsed" style="text-align: left; border: 0px; margin-top: 0.2em;"
|-
! style="background-color: #aaffaa;" | '''Further posts and discussion of "hyphen-related stuff"'''
|-
|
::User:kwami is correct (or more correct). I thought I would expand on the topic to ensure all here appreciate the distinction between how computers ''interpret'' a hyphen as an operator in arithmetic contexts, and how true minus signs are dealt with when one is dealing with fine typography. The {{tl|val}} template, which I helped to create and spent a bunch of time working with other editors on other platforms to ensure things looked good to all editors, replaces the hyphen/minus keystroke in the code with an actual typographical minus sign, (<code>&amp;minus;</code>). It renders as follows (between the arrows: → &minus; ←. It is longer than the hyphen but not as long as an en-dash (which may not be apparent unless you plus-size the type size in your browser). Thus, the progression of true hyphen, true typographical minus sign, en{{nbhyph}}dash, and em{{nbhyph}}dash is as follows:
:::-
:::&minus;
:::–
:::—

::If you zoom your font size in your browser, you can see the difference. I don’t know what type foundries are ''trying'' to do, but I think most editors will find that the components of an equal sign are the same length as the true typographical minus sign. Examine the two juxtaposed below at large type size:

:::&minus; as in C&minus;C
:::= as in C=C
:::&equiv; as in C&equiv;C (that was the ] → &equiv; ← (<code>&amp;#8801;</code> or <code>&amp;equiv;</code> and does not appear properly on all platforms)

::Of course, this is what a machinist friend of mine would say is “goosing butterflies” (too much effort for barely noticeable difference), but I thought I’d mention it. ] (]) 23:31, 20 July 2011 (UTC)

:::The difference between an en dash and a minus sign is usually pretty hard to see, and it varies among typefaces. The difference is most apparent when the character appears next to a plus sign, either in a vertical arrangement, e.g.,
::::–0.005
::::+0.002
::::−0.005
:::or horizontal juxtaposition (e.g., –+−). The latter seems an unusual occurrence, and at least on a monitor, the vertical alignment with the horizontal bar can vary with the zooming level/type size. Incidentally, I show the en dash first in both cases. With the default sans serif typeface in FF 5, the en dash is a bit closer to the baseline (it’s meant to connect lower-case letters; the minus is intended for use with lining figures). ] (]) 00:19, 21 July 2011 (UTC)

::On ranges of physical quantities: I agree that when used as a nominal, {{xt|wavelengths in the range 28 mm to 17 m}} is easier to read than {{xt|wavelengths in the range 28&nbsp;mm – 17&nbsp;m}}. I’m not sure ''to'' works as well in the adjectival usage {{xt|wavelengths in the 28&nbsp;mm-to-17&nbsp;m range}}. As for ambiguity with {{xt|17–28&nbsp;mm}}: the general-purpose guides (e.g., CMOS) seem to have no problem with omission of the first unit, and neither do camera manufacturers. But some technical guides are less tolerant. NIST SP&nbsp;811 wants units repeated (e.g., {{xt|17&nbsp;mm to 28&nbsp;mm}}, though much of the problem may arise from their strong deprecation of all range dashes “because the dash could be misinterpreted as a minus sign”; NIST’s objection apparently assumes the dash is spaced (they show {{!xt|*0&nbsp;ºC – 100&nbsp;ºC}}, {{xt|0&nbsp;V to 5&nbsp;V}} or {{xt|(0 to 5)&nbsp;V}} but not {{!xt|*0 – 5&nbsp;V}}, 2008 ed., at 7.7) This seems a bit strange, because range dashes are almost never spaced in the US, but perhaps NIST are afraid that some authors might do it; accordingly, it’s tough to tell whether they’d be OK with {{xt|0–5&nbsp;V}}. The BIPM SI brochure doesn’t discuss ranges, but does mention “all chemical bonds lie in the range 1 to 3 ångströms”; however, the issue is the use of ''ångström'' rather than treatment of ranges. ASTM (''Form and Style for ASTM Standards'', 2010 ed., at G26) ban range dashes except in tables. They don’t seem to explicitly mention whether units need be repeated, but give the example “0 to 250 mm” (at B13.1), so apparently they don’t require it. Conclusion: preferences seem to vary.
::Again, the tough case (with or without a dash) is the adjectival usage. ] (]) 00:06, 21 July 2011 (UTC)
:::Wouldn't we expect {{xt|wavelengths in the 28&nbsp;mm–to–17&nbsp;m range}}?
:::NIST conventions are fine in the few infoboxes where we are transcribing to that level of precision, such as (24.2 ± 0.3){{e|6}} cm or (132 {{±|6|14}}){{e|6}} cm, but IMO are overkill for most of our purposes.
:::The en dash and minus sign do not line up in most fonts I use. The dashes line up vertically with the hyphen, the minus and plus signs do not. BTW, having looked at the vector graphics of several professional fonts, I've always found that an equal sign is made by duplicating a minus sign, offset equally above and below the height of the minus sign, and that the cross bar of a plus sign is identical to a minus sign. An en dash, however, is a lengthened hyphen, set at a different height than the minus. — ] (]) 00:45, 21 July 2011 (UTC)
::::I’m not sure I’ve ever seen both ''to'' and en dashes in a range. And anyway, doesn’t {{xt|wavelengths in the 28&nbsp;mm–17&nbsp;m range}} accomplish the same thing in less space?
::::As for NIST conventions, I don’t quite see how precision comes into play with {{xt|(0 to 5)&nbsp;V}}; this seems to attempt the same as {{xt|0–5&nbsp;V}}, in a bulkier (and at least to me, less clear) manner. I’m not sure how I feel about the latter vs. {{xt|0&nbsp;V–5&nbsp;V}}. In speech, I almost always would use the former, and ''I'' probably would write {{xt|0&nbsp;V to 5&nbsp;V}}, though I’m not sure I would object to {{xt|0-5&nbsp;V}}. I would never write {{xt|0 – 5&nbsp;V}} or {{xt|0&nbsp;V – 5 &nbsp;V}}, for much the same reasons as CSE and SP811.
::::Your experience with en dashes is similar to mine, though in many cases the en dash is slightly thinner than the hyphen (this sometimes may be lost on a monitor). I’m not a chemist, so I’d defer to those who are, though choosing the symbol that best matched the others does seem pretty sensible.
::::Aside: is this really “hyphen-related stuff”? ] (]) 02:52, 21 July 2011 (UTC)
----
|}

===== Sidebar on format of "correct" and "incorrect" examples =====
May I raise 2 related points about the format this draft section uses to distinguish between "correct" and "incorrect" examples? &nbsp;&nbsp;'''(1)''' The style appears to depart significantly from that employed in many other sections of the MoS; and '''(2)''' the draft's (new?) formatting convention (color, font, and asterisk vs. no-asterisk) isn't explained anywhere (at least that I could find readily).&nbsp;...
'''Click on "show" at the right:'''
{| class="navbox collapsible collapsed" style="text-align: left; border: 0px; margin-top: 0.2em;"
|-
! style="background-color: #aaffaa;" | '''Continuation of the post, and any detailed replies'''
|-
|
::::'''NB:''' I don't think anything in my comments here needs to delay posting the final revision of the MoS in the slightest. If merited, these changes could easily be made in a routine edit after the revision is formally unveiled without killing anyone (to use one discussant's phrase). I fully respect and am keenly sensitive to the desire of many of the editors who have been labored long and hard on this epic endeavor to bring it to a prompt conclusion. (And I apologize if this question has already been addressed. I vaguely recall seeing it raised somewhere else in the discussion, but I couldn't find it when I went back and looked for it.) Finally, I'm assuming this revision isn't part of a MoS-wide style change.

:'''(1)''' The most often-used style for displaying these examples in other MoS sections is the one used in the section on semicolons:
::''Correct:''&nbsp;&nbsp;&nbsp;{{xt|Though he had been here before, I did not recognize him.}}
::''Incorrect:'' {{!xt|Though he had been here before; I did not recognize him.}}
::: The "correct" vs. "incorrect" form is a common, but far from universal, convention used in other style manuals, with some variations in labeling (e.g., right vs. wrong, recommended vs. discouraged, standard vs. nonstandard, etc.). S&W simply uses 2 columns (no matter how long the example), with the wrong usage always on the left side.

::: And there are numerous variations of and exceptions to this format ''within the MOS'':
:::: '''a.''' The order of the correct and incorrect examples isn't always consistent. Sometimes the order is consistently like the example above; other times the order is consistently reversed. In still other cases, the order is the same in which the governing rules or principles were discussed in the relevant paragraph, but other times not.
:::::– ''The order of examples in paragraph 2 of the draft revision of this section seems particularly unusual'': IMO, there doesn't appear to be any specific reason why the 4 examples of incorrect usage are mixed in among the much more numerous correct examples in 2 pairs, with a correct example between them. At the very least, the examples of incorrect usage should be grouped together. Such a long list of examples might be even more made even more visually appealing by dividing them into 2 separate sections, so the "Correct" and "Incorrect labels" would only need to be used once.
:::::: – – Anything that makes the MoS easier to read and follow would be less likely to discourage its use, and there are probably few things that induce reader torpor faster than long, complicated lists. (WP lists may be an exception, of course!) While no style guide is apt to be a thrilling page-turner, the least we can expect is for it to be as user-friendly as possible.
:::: '''b.''' In other MoS sections, if the examples are short enough, both are sometimes shown on the same line, including the "correct" and incorrect" labels, especially when this can be done without making the line appear crowded or cluttered and the difference between the correct and incorrect forms is easy to see. (E.g., in the semicolon example above, the over-under display makes the visually subtle difference pretty obvious; displayed side-by-side, such differences would be harder to see readily—which I find quite irritating.)
:::: '''c.''' Sometimes, as in the current version of this section, the examples are shown in-line with the discussion itself, formatted using the above font-color pattern.
::::::– This seems to work well if the examples are short, as is the case here, so that crowding doesn't make the result visually unattractive and more difficult to read.
::::::– In contrast, paragraph 3 of the "Hyphens" section ("compound modifiers") is a good example of when this practice doesn't work well: The text is very densely packed, with very little white space to give your eyes a rest. Instead, line after line, almost all single-spaced, fills almost the whole width of the screen (like this post!), and the examples tend to blur in with the rest of the text, despite the different font and color. (This problem is especially aggravated when, as discussed elsewhere, the user's browser renders both the red and green fonts in very dark tones that are difficult to distinguish from black, especially when mixed in with densely packed text.)
::::::– '''''Note:''''' To emphasize, this ''doesn't'' seem to be a problem at all with the current revised draft of the "Dashes" section, to the authors' credit—and I hope it can be kept that way!

:(2) Because this section's display format for correct vs. incorrect usages does depart significantly from that employed in many other sections of the MoS, this convention should be explained and prominently displayed as close as possible to the beginning of the section. This should be a very simple revision.
::: – Lacking such a guide to the convention used in this section, the user must infer it from the first few examples. This violates one of the bedrock principles of effective writing: The writer did a lousy job if a reasonably intelligent reader has to go back in the text and read something more than once in order to understand it just because of the structure of the sentence, paragraph, etc. (vs. some inherent complexity in the material, like, say, the fundamental definition of a ''limit'' in calculus).

I realize I'm arriving on the scene after all the arduous work has been done, but I only recently learned of this project. (And I have no particular expertise in dashes, anyway.) As I said earlier, these changes could easily be made in a routine edit after the revision is posted, although explaining the convention for designating correct vs. incorrect usages is both sufficiently important and easy to do that it merits doing ''before'' publication, if possible.

In ''Eats, Shoots and Leaves'', Truss writes,
<blockquote>One of the most profound things ever said about punctuation came in an old style guide of the Oxford University Press in New York. "If you take hypens seriously," it said, "you will sure go mad." ''(p 168)'' </blockquote>
The same might well be said of dashes!

Thanks to all for your arduous labors. <font color="blue"><big>'''''JFT'''''</big></font> --] (]) 22:53, 21 July 2011 (UTC)
-----------------------------------------------------------------------------------------------------------------------------------------------------
<font color="blue"><big>N</big><small>oetica</small></font>:

(1) I hereby bestow my ''nihil obstat'' and ''imprimatur'' for proceeding with the present draft, conditional only upon the one proviso and caveat noted below. By all means, proceed "with all deliberate speed."
* As noted in my original post,"I don't think anything in my comments here needs to delay posting the final revision of the MoS '''''in the slightest'''''. If merited, these changes could easily be made in a '''''routine edit after the revision is formally unveiled''''' without killing anyone (to use one discussant's phrase)."
* '''Proviso:''' To help minimize any initial confusion among users, I strongly believe the (temporary) convention for distinguishing between correct and incorrect usages should be explained as concisely as possible at the beginning of the section. One sentence should suffice, which could be inserted while awaiting other comments (or while the kettle is coming to a boil) so that it need not delay posting, at least not by more than a minute or two. Nevertheless, if those editors who have labored so long and arduously before I added my Johnny-come-lately penny's worth of thoughts prefer not to adopt my suggestion, that would most likely not cause the collapse of the whole MoS enterprise, and any ruffled feelings on my part should easily be assuaged with a nice cup of tea. (Milk ''and'' sugar, please. Lovely. Thanks.)
::(And it should be similarly quick and easy to group the 4 "incorrect" examples together in the long list of examples in paragraph 2. But again, this is not a life-and-death issue.)
* '''Caveat:''' As also noted in my original post, I have no particular expertise in dashes, so I doubt that my blessing on proceeding without further delay should carry much sway, as well as that any further input from me would be especially valuable. (I wouldn't even have known about this draft revision and posted my earlier comments had you not suggested I do so in a post elsewhere.)

(2) I wholeheartedly concur that MoS articles should be easily accessible to those who have difficulty distinguishing colors (hence the need for a crisp, clear convention for distinguishing correct responses from incorrect ones completely independent of color). Even though my own color vision is unimpaired, I too have difficulty telling the red from the green fonts (or perhaps more accurately, reddish vs. greenish) in long sections of densely packed text, as in the example from the "Dashes" section I mentioned before. Even the serifed font isn't particularly distinctive when buried within such passages! (It occurred to me after my earlier post that how clearly and distinctly red and green are rendered on a user's screen depends not only on the browser being used, as another contributor had noted, but also likely on the color fidelity and resolution of the screen itself and of the OS's built-in color set.)

(3) I tend to agree with Darkfrog24's preference that the MoS be phrased in a more imperative tone. But I suggest that discussion of this matter be postponed until after the revised "Dashes" section has been posted.

(4) BTW, putting the longer posts and discussions in collapsed boxes is a welcome improvement and should enhance navigation. This Talk page has become unwieldy. (I shudder to think about the archives.)

Thank you again for your dedication this project ... and for the tea! — <font color="blue">Jack</font> --] (]) 18:50, 22 July 2011 (UTC)
----
|}
Jack, I believe that at least one participant in the present discussion cannot distinguish red and green. Yes, the important issue you raise came up earlier; the asterisk is simply to get us through for now. The matter needs to be revisited&nbsp;– later, may I suggest? Your input will be valuable! Incidentally, are you in a position to add your endorsement explicitly above (it is hinted at in your post), for proceeding with the present draft? The clearer we are about this the better. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 00:01, 22 July 2011 (UTC)

:My own belief is that the MoS should be phrased in the imperative. We are telling people what to do, not describing what is done elsewhere. This style guide has a luxury that most do not: the ability to link to separate articles that can describe the prevalence and history of each rule, mark and space in detail. ] (]) 00:53, 22 July 2011 (UTC)

<font color="blue"><big>N</big><small>oetica</small></font>:
(1) I hereby bestow my ''nihil obstat'' and ''imprimatur'' for proceeding with the present draft, conditional only upon the one proviso and caveat noted below. By all means, proceed "with all deliberate speed."
<font color="blue">'''''''''' — Jack</font> --] (]) 18:50, 22 July 2011 (UTC)

== Punctuation after date ==

Neither ] nor ] appear to define whether a comma is required after the year in cases like the following:

*They agreed a ceasefire on April 1, 1873 in order to celebrate April Fools' Day.
::or
*They agreed a ceasefire on April 1, 1873, in order to celebrate April Fools' Day.

Which is correct? All examples given for this date format seem to have something like a full stop or right parenthesis after. --] (]) 10:04, 17 July 2011 (UTC)

:*''MLA Handbook for Writers of Research Papers'', 7th ed., §3.5.6: "If you begin with the month, be sure to add a comma after the day and also after the year, unless another punctuation mark goes there..."

:*''Associated Press Stylebook'' (2007), p. 159 (months entry): "''Feb. 14, 1987, was the target date.''" ] (]) 11:22, 17 July 2011 (UTC)

* The comma after date is placed when the date if part of an introductory clause, i.e. "In July 2011, the weather was nice." or "As on July 2011, I will stop drinking." However the first clause in the example you give is not an introductory clause, it is just a regular clause that happens to have a date in it. You could replace it with, say, "They agreed a ceasefire yesterday in order to celebrate April Fools' Day." In this case "in order to celebrate April Fools' Day" is not an independent clause, so a comma is not needed. —&nbsp;<small>&nbsp;]&nbsp;&nbsp;▎]</small> 11:56, 17 July 2011 (UTC)

:*Of course, H3llknOwz's opinion conflicts with the two cited style manuals. ] (]) 12:18, 17 July 2011 (UTC)

::*No, it doesn't. It is not opinion, I am referring to English language punctuation of introductory phrases. Also, I didn't say you ''cannot'' use a comma, I said it is not needed. Both your examples refer to introductory phrases – "If you begin with the month" and "''Feb. 14, 1987, was the target date.''" are both used at the start of sentence. What you are possibly meaning to quote is MLA §3.2.2 "''If such a date comes in the middle of a sentence, include a comma after the year.''" This is a stylebook suggestion, and whether it is used or not on Misplaced Pages is at editor discretion/consensus. I did not say you cannot use it and I believe most editors do. —&nbsp;<small>&nbsp;]&nbsp;&nbsp;▎]</small> 13:12, 17 July 2011 (UTC)
:::*The statement from the MLA handbook was an instruction, not an example. Failure to put a comma or other punctuation after the year is an error in applying MLA style. Of course, as you say, any style book only applies to those who choose to follow it. ] (]) 13:46, 17 July 2011 (UTC)

::::Thank you both for helping with this. I've looked elsewhere on the net and it does appear more common to use the comma. But it is a style question, so the real issue is whether this should be left to individual editors or whether MOS should have a position on it. --] (]) 13:21, 17 July 2011 (UTC)

::Chicago (14th ed.) says "In the alternative style , however, commas must be used before and after the year."--] (]) 13:41, 17 July 2011 (UTC)
:::I have had discussion on this topic with other editors. I am not saying that these discussions are definitive, as I am sure there are plenty of style books, but feel free to read what was said. ] ] (]) 14:48, 17 July 2011 (UTC)
::::Hellknows' post is correct, if a little unclear. ''If'' there is a comma before the year, there must be a punctuation mark after it (usually a comma, or the period after the sentence); the year is parenthetical. If there is no comma before, there may or may not be a following comma, depending on the rest of the sentence. In {{xt|July 11, 2011}}, there must be a comma before; in {{xt|July 2011}} or {{xt|11 July 2011}} there isn't. ] <small>]</small> 19:24, 17 July 2011 (UTC)
:::::The rule isn't in the Manual of Style, but it is at ], and I cite it so often it needs a shortcut: "... the month day, year, style of writing dates punctuates after the year&nbsp;..." ] (]) 20:21, 17 July 2011 (UTC)
The discussion on Chaosdruid's talk relates to sentences beginning {{xt|In 2011, the...}}. That is a short parenthetical phrase, and it is a question of taste whether it needs to be set off, by a single comma, at all. But when you use one comma in {{xt|July 11, 2001,}} it is mandatory to use both. ] <small>]</small> 20:47, 18 July 2011 (UTC)
:As Hellknowz and Anderson said. Think of it as a parenthetical: ''They agreed a ceasefire on April 1 (1873) in order to celebrate April Fools' Day.'' You couldn't leave out the closing parenthesis. That's the rational for requiring two commas, and two commas is standard punctuation. That said, it is ''extremely'' common to leave out the second comma, because the main reason they are needed is to help separate the numerals in the day from those in the year, and the clause is perfectly legible with a single comma between the day and year. I would therefore say that in a colloquial context a single comma is perfectly acceptable. However, in a formal context, such as an encyclopedia, we should stick to formal punctuation. — ] (]) 03:59, 19 July 2011 (UTC)
::I don't think this additional comma should be the subject of MoS rules, as long as there's article consistency on the matter. Aside from this, both alternatives at the top of this thread are unsatisfactory. "They agreed ''to'' a ceasefire on April 1, 1873 <s>in order</s> to celebrate April Fools' Day." ] ] 04:32, 19 July 2011 (UTC)
:::"They agreed a ceasefire" is grammatical, but apparently only in UK and Irish English; see ]. I didn't know that, but I am British and this would be the natural, though not the only, way for me to say/write it. The "in order" part of "in order to" is certainly redundant, but that doesn't make it actually wrong&nbsp;&ndash; I'm not a minimalist :) --] (]) 10:08, 23 July 2011 (UTC)
:::: <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 14:55, 24 July 2011 (UTC)

:::::(Chuckle) A classic worthy of ''The Daily Show'' or ''The Colbert Report''. --] (]) 21:23, 29 July 2011 (UTC)

::::Re "<s>in order</s> to": Yeah, it is indeed redundant (or should that be ''superfluous''?), at least in a huge majority of cases. But it also ''sometimes'' makes the sentence read more smoothly. I do omit it wherever possible. But I couldn't tell you how many of those times I've later reread the sentence, especially after more than a few minutes elapsed, and found myself stumbling over an awkward lack of transition between the infinitive ("to ...") and what preceded it. It causes me to pause for a few moments, thinking a word or more has been left out. And that's in something I wrote (or at least edited) myself, so I presumably know what I meant to say! If the absence of "in order" causes ''me'' to stumble in those cases, might not someone else, reading the sentence for the first time, also stumble? And that's an absolute no-no in effective writing. As Michael Oreskes, senior managing editor of the Associated Press, said, "The faster the eye flits across the words, the more vital it is that language be immediately and abundantly clear." (See
http://www.washingtonpost.com/lifestyle/style/david-minthorn-is-the-grammar-expert-for-the-associated-press/2011/07/25/gIQAGBLwfI_story.html

::::p. 2, 4th paragraph from the end.) So I usually do omit "in order," but I try to be sure what's left is "immediately and abundantly clear," with no stumbles. --] (]) 21:23, 29 July 2011 (UTC)

:::That comma rule's history at ] has ranged from wanting to delete the rule ] to wanting to delete it ]. As I stated there, if we didn't have the rule written down somewhere, then enforcing it would get me into a crossfire between those who consider the rule to be obvious vs. ridiculous, and I would probably decline to enforce it. WP:COPYEDIT is no longer considered part of the Manual of Style, but so far that hasn't mattered when discussing a particular comma. ] (]) 04:59, 19 July 2011 (UTC)
*Without suggesting a view as to whether or not this should be part of MOS rules, I will say that personally -- based on whatever guidebooks I've read over the decades -- I do insert a comma after the year, and do view that as appropriate.--] (]) 20:25, 19 July 2011 (UTC)

== RfC for Collapse boxes on chess problems ==

{{rfc|style|rfcid=9EB6CEF}}
Recently on ], the issue was raised as to whether chess problems (and, presumably, other problems where readers may prefer not to read the solution until they've tried to figure it out themselves) constitute a reasonable exception to ]. The issue was discussed a bit on ] and then it moved to ]. It would be helpful to see the input of uninvolved editors, and, if consensus is that this is an acceptable use of hidden text, consider adding in that exception either here and/or at ]. ] (]) 04:38, 23 July 2011 (UTC)
: Why should we make this exception to ]? Though, on the other hand, it's not exactly the same as a spoiler warning, or not including spoilers. The content would still be there, just kind of hidden. And it's a reasonable courtesy to people who want to learn about chess but not have the tactics ruined for them. So I don't see why not. ]&nbsp;'''j''' 05:14, 23 July 2011 (UTC)
::No guideline is intended to apply to all possible situations. I often object to those who invoke ] to ignore a guideline altogether, but not when they only assert an ]. Requiring a chess problem to show its solution, makes it almost useless. If the guideline was followed but the content was useless, that's like saying the operation was a success but the patient died.

::It should also be mentioned that there was a lot of unnecessary hostility. But you've already been to ] to handle that problem. ] (]) 05:26, 23 July 2011 (UTC)

:Technically I am an uninvolved editor to the extent that I joined the discussion at AN/I. If that in turn makes me an involved editor, then consider the following comments as being from someone who has played chess since the age of, oh, maybe 5. (I wasn't that good, I am certain my aunt let me win on purpose.)
:In giving this opinion, I will link to some chess puzzle sites. This is merely a list; I will go into detail under this list.
:*
:*
:*
:Keep in mind, this is based on a quick Google search.
:Looking at the first site, it's your basic here's the picture, scroll down for the solution. This is an old school way of doing things. In a book, you have absolutely no choice. The Internet is not a book, and we should not treat it that way. Moving to the second, it's daily puzzle (the easy one for today is LAME, BTW - no instructions and I was trying to checkmate only to be told the goal was to take the Bishop) appears and you can click and move the pieces. It's a basic interface, click and click again. The third one is beautiful; you actually click and drag the piece, and the system plays moves in response. If you give up, there is an option on the left to animate the solution. (I had to do that for the one I tried).
:Now, two of these do not have the solution on the page at all. This is the ideal way to do it; keep the solution to such a puzzle hidden from the vic-...''*ahem*'' participant and only reveal it when asked. The solution with which I agree to at ] when presented with Polgar's first chess problem (composed at age 4) was to have the solution hidden, but when the article reader looks at the diagram and makes a decision on the solution, they can then click the link to see if they're right. They can't play on the board directly (we are not a chess site, why would we?), but they can certainly try the puzzle without the chance of seeing a solution immediately by accidental scrolling (as could be the case in site #1, and some screen sizes might let users see the solution immediately without scrolling).
:The question was raised: why not put it in a separate section? No good at all; the last thing we need in an encyclopedia article is a section titled '''Solution to above problem'''. It's ridiculous in an online setup. In a paper encyclopedia, sure, it's great, but in this format it is just a mess and not something that needs its own section. Hiding the solution right under the grid and allowing the user to click when they are ready to see the solution is an ideal sol-...er, is the ideal way to handle this kind of presentation. ] (]) 05:35, 23 July 2011 (UTC)
::What he said. ] 06:15, 23 July 2011 (UTC)
:I definitely think this is a reasonable exception to the ] guideline, which is, after all, only a guideline, and I don't think ] is 100% applicable to this situation. In the ANI discussion, it was stated that concealment of the solution is, in a way, part of the content. I think that makes a lot of sense. It could be thought of as analogous to an ]. The illusion ''is'' the content. <B>—]</B> <sup>]</sup><sub style="margin-left:-3.5ex;">]</sub> 06:37, 23 July 2011 (UTC)
::While I don't think that what other sites do is relevant (because we have a different mission than a chess site), Torchiest's argument that the hidden-ness is essentially part of the content itself does make some sense to me. I'm still not fully convinced, but at least I can see a context for justifying this but not other types of spoilers. That, by the way, really is my biggest concern--I don't like the idea that others can use this as precedent to say "that local group argued there situation is special, but ours is also special so we should be able to hide our information as well". This argument sets up the idea that the difference lies in the actual material itself; it's almost like, if we were "quoting" these problems, we would have to separate the solution from the question, and our technical way of doing that is with hidden text. I'd still like to hear wider input, especially from MOS-gnomes, who can approach this not from a concept of what's appropriate for Chess problems, but how this fits into the greater logic of the MOS. ] (])
:::The point of my demonstration was to show different styles of laying out this type of problem, not to advocate a certain site's layout over another. After all, we are our own site, we do our own thing. I merely use the examples given to demonstrate why having the solution hidden (which itself is a spoiler to the puzzle) is the way to go, and two examples of sites I gave let you click a button to see the result if you give up. That's a similar format to what the AN/I agreed on here with a collapse box. ] (]) 14:37, 23 July 2011 (UTC)
*I think the issue can be avoided: at the ], I have suggested that a standard numbered footnote be used to provide the solution. That is much more in keeping with standard procedures. ] (]) 09:38, 23 July 2011 (UTC)
*:That's only satisfactory if footnotes exclusively containing bibliographic info are kept separate from those containing content, as in ]. Otherwise, it might not occur to all readers that the footnote contains the solution rather than a citation. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 19:06, 23 July 2011 (UTC)
*My view is that the collapse box is acceptable for solutions to any kind of incidental puzzle. Were the article about this problem (and I am no chess expert but it seems a pretty trivial problem to me) then a collapse box would be inappropriate. In this article I think it works - and it doesn't just have to apply to chess, either. Although I admit I'm struggling to think of other non gaming examples where it would apply! <span style="background-color:silver;color:black;">] ]</span> 12:43, 23 July 2011 (UTC)
*: Egg, yes, as far as chess problems go, it's pretty trivial. But!, were you aware that Susan was ''4 years old'' when she composed it? ] (]) 14:48, 24 July 2011 (UTC)
*There is a fundemental difference between a collapse box in an article that describes a book and one that describes a gaming puzzle - in the former, the reader is unable to ascertain the answer without reading the book (or opeing the box) whereas in the latter, the reader can find the solution without having the relavent gaming board present. This suggests to me that the guidance should be modified to council against collapse boxes in spoiler situations only in circumstances where the reader would be expected to consult an outside work to find the answer. ] (]) 13:03, 23 July 2011 (UTC)
*What implications does this sort of thing have for accessibility issues, ''i.e.'' for the visually impaired? <font face="Lucida Calligraphy">]<font color="#0095c6">of</font>]</font> 15:52, 23 July 2011 (UTC)
*'''Don't collapse puzzles; maybe put solution at article bottom''' - The ] guideline is very clear. Readability is paramount, and WP is supposed to contain prose-style encyclopedia articles. Many readers may not understand what "show" or "hide' means. Especially non-English speakers, or people with accessibility issues. Presenting information is far more important than avoiding spoilers. Plots of movies and books are clearly presented in WP articles, without any "show/hide" mechanism. See ]. See also ] which explains why spoiler alerts are not included in any WP article. As a compromise, consider the approach used in ], where there is a puzzle presented in the center of the article, and its solution is located at the bottom of the article, and a link jumps the reader from the puzzle to the solution. --] (]) 18:21, 23 July 2011 (UTC)
*:'''Disagree with view''' - If I am reading an article, I want the solution to be near the puzzle (not just chess but any theoretical puzzle used properly within the article), but not necessarily visible so as not to ruin the concept of the puzzle. The collapse option makes perfect sense here and is a suitable exception. This RfC is suggesting to make changes to the guideline (and note it's a guideline, not a policy, and cannot be enforced as such), and just responding saying that "the guideline is very clear" is completely ignoring the fact that this is a request to introduce changes to the guideline. ] (]) 20:18, 23 July 2011 (UTC)
::Following up on Lady of Shalott's question: I took a look at ]. At first this worried me, so I tried to look at the page with Javascript turned off. Conveniently, the page displays all of the information (basically, the way the article looked before the hidden line was added), so at least we don't have to worry about that. Regarding the visually impaired...I strongly believe that we should do what we can to make their browsing of Misplaced Pages as functional as possible...but in this case, isn't it correct that no matter what we do, the visually impaired can't use the problem any way, since it's contained in an image? In which case, it makes no difference how the solution is portrayed. ] (]) 00:51, 24 July 2011 (UTC)
:::That can be handled by means of <code>alt</code> attributes. Right now the template gives alt texts like “white queen” etc., but it might be tweaked to read “white queen in h4”. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 10:47, 24 July 2011 (UTC)
:::Just on that point, it is not impossible to give information to a person with a visual impairment without using the image. It just takes more effort. We should try to do that if at all possible. Regarding the collapse box, I think a screen reader 'reads through' the box, similar to the effect with Javascript off. ] (]) 16:57, 24 July 2011 (UTC)
::::OK, thanks, y'all, for the accessibility input. I do think the alt text should be made as informative as possible a la A. di M.'s suggested tweaking so that people using screen readers can obtain full benefit of the article's content. <font face="Lucida Calligraphy">]<font color="#0095c6">of</font>]</font> 20:19, 24 July 2011 (UTC)
*As a chess player with a passing interest in chess problems, I went and had a look, and while I appreciated the solution being hidden here, it was indeed a rather trivial problem to solve (the interesting thing is working out why a White piece is needed on d2 and why it has to be a pawn - the answer being that without that pawn there, there are two solutions to the puzzle, which would be a 'cook' - a failed problem - and that other White pieces on d2 would allow other mates). Personally, I think the solution should be in a footnote, but I'm not sure how chess problems and endgames (or indeed positions from notable games) should be handled. I'd be inclined to just present them without solutions! :-) ] (]) 21:51, 24 July 2011 (UTC)

::Personally, since there don't seem to be any accessibility issues, I prefer the hidden text to the footnotes. This is because I really don't like mixing "informative" footnotes with "citation" footnotes; to me that's extremely confusing, as when I see a reference marker, I assume that it leads to a citation, not to a place with further info about the text. Yes, there is a way to help avoid this confusion, by using reference groups, but I think that that is quite difficult for new editors to learn how to use, and still isn't entirely clear to a reader. If hidden text is the preferred option, what would people think of changing
::{{quote|Collapsible sections may be used in ] or ], or in tables which consolidate information covered in the prose.}}
::to instead read
::{{quote|Collapsible sections may be used in ], ], tables which consolidate information covered in the prose, and solutions to puzzles or problems (such as ]s) whose solutions are normally hidden or distanced from the problem in ] that collect such puzzles.}}
::That's probably too wordy; my intent was to distinguish puzzles which hide the answer as solving it is part of the "fun", to mathematical texts, which don't hide the answer to their "problems" except in textbooks, where the purpose is different and hiding is definitely not compatible with the way Misplaced Pages works. Also, I would like it to be very clear that the exception only applies to this particular class of problems, not to plot spoilers, to offensive material, etc. ] (]) 00:20, 25 July 2011 (UTC)
:::I like that. How about:
:::{{quote|Collapsible sections may be used in ], ], tables which consolidate information covered in the prose, and solutions to puzzles or problems (such as ]s) normally hidden or distanced from them in ] that collect such puzzles.}}
:::Slightly trimmed down, although maybe someone else could do even better? <B>—]</B> <sup>]</sup><sub style="margin-left:-3.5ex;">]</sub> 13:32, 25 July 2011 (UTC)
::::My go:
::::{{quote|Collapsible sections are permitted in ], ], tables which consolidate information already covered in the prose, and solutions to puzzles or problems (such as ]) normally hidden or distanced from them in ] that collect such puzzles.}}
::::Notably, I kept the s as part of the Wikilink on problems and chose a word I like better for a guideline. ] (]) 14:38, 25 July 2011 (UTC)
:::::Doesn't putting the 's' outside of the link but right next to it automatically make it part of the wikilink anyway, without needing the piping? Either way, though, the effect is the same. I like the simplification of the final clause. I have no opinion on "may" vs. "permit", which seems to be the subject of a significant discussion below. ] (]) 01:45, 27 July 2011 (UTC)
::::::Based on an above example, it appears that is indeed the case. I wasn't aware the code recognized that. ] (]) 13:24, 27 July 2011 (UTC)
*As an uninvolved editor, I strongly support the idea of making the suggested changes to WP:SPOILER and/or the Manual of Style. Chess puzzle solutions ''should'' be hidden in some way - that's exactly what I would expect if I were reading a book about chess, or even a bio about a notable chess master. Misplaced Pages needs to be flexible enough to allow various WikiProjects to make exceptions to guidelines and even policies, if need be and when appropriate. A collapsible section seems to be the most elegant way to do this. ] (]) 04:41, 29 July 2011 (UTC)
* Personally, I think that SPOILER has it right. All collapsible boxes unavoidably cause one accessibility problem: Any person who finds it painful to click on things (e.g., due to carpel tunnel syndrome) has to choose between experiencing pain and not reading the full article. ] (]) 22:40, 29 July 2011 (UTC)
*::I don't see anything in WP:SPOILER about carpal tunnel syndrome or other disabilities. And I do see hide/show boxes everywhere on Misplaced Pages. They are frequently on talk pages, and the first featured article I just checked for an example had sixteen hide/show navboxes at the bottom, with 'hide' being the default. Maybe the developers on Misplaced Pages could have an option for people with disabilities to have all hidden boxes default to "show". ] (]) 14:19, 30 July 2011 (UTC)
*'''Hide''' chess solution. I went to the Polgar for the first time and I was delighted that her four-year-old youngest-ever-published problem was open to my attempt to solve it without the answer being right there in front of me. All chess problem solutions should be hidden. ] (]) 14:54, 30 July 2011 (UTC)

*I'd like to point out, though of course I favor use of "hide"/"show" for chess problem compositions, and appreciate the language recently constructed for updating ], there exists a number of uses of "hide"/"show" already in some rather mature articles, for use not to depict chess problem composition solutions, but rather brilliant or difficult game continuations. For examples of these, please see articles ] (contains two such game continuations), ] (one), and ] (one game continuation in "Notable chess games" section, plus a problem composition in the same article). And I'm sure there are other article examples besides these. In addition, besides game continuations and problem compositions, there is an additional use of "hide"/"show" demonstrated in the mature article ] &ndash; a diagram about the Rice Gambit. My concern is, if the language currently under consideration to update ] is drafted, will it be so restrictive for chess as to allow use of "hide"/"show" for only chess problem compositions? And put the kibosh on use for brilliant or difficult game continuations? ] (]) 20:34, 30 July 2011 (UTC)
*:I think if it said "chess problems and continuations" it would be seen as covering all of those, unless you think more explicit language is needed (keeping in mind that I'm completely ignorant about chess, but wanting to see the language be both simple and comprehensive). ] (]) 03:46, 31 July 2011 (UTC)
*::I think the phrase you're suggesting is excellent. But will others here agree to the less restrictive language? Also, another part of the language under consideration says "... normally hidden or distanced from them in ] that collect such puzzles." But many times that does not describe or apply to brilliant or difficult game continuations found in books (which often, if not usually, print the continuations on the same page, i.e. not "hidden"). So am wondering if further modification to the language will be accepted in this discussion, to not put the kibosh on brilliant or difficult game continuations already found in mature articles as exampled above.) Ok, ] (]) 05:55, 31 July 2011 (UTC)
*::p.s. There are lots of books too, which ''do'' segregate position diagrams, from their brilliant or difficult game continuations (such as in the appendix). But I doubt one could call that the "normal" way it's done (the current language says "normally hidden"). There is the distinction, that brilliant or difficult game continuations come out of praxis/real games, whereas problem compositions are invented. But unlike problem compositions, brilliant or difficult game continuations sometimes are segregated from their diagrams, sometimes not. (The editors who included game continuations in ], ], and ] made their choice to segregate or not, choosing to hide. To me that seems best &ndash; to leave to consensus what's best for an article. But would that degree of flexibility be accepted here when drafting language update?) To summarize my thought here: solutions are normally segregated from their respective problem compositions. Brilliant or difficult game continuations sometimes are segregated from their diagram positions, and sometimes not. If I had to guess, I'd say the assertion they are ''normally'' segregated in books, is false. (So if we accomodate game continuations in the language, the "normally hidden or distanced" part can't apply to them.) Ok, ] (]) 06:38, 31 July 2011 (UTC)
:::I'm fine with adding "continuations"; I'm not fine with the idea of Misplaced Pages articles being substantially different from our reliable sources. If they're not normally segregated there, I don't think we should be making an exception here. As Ihardlythinkso knows, I strongly dislike the idea that editors of individual articles just get to declare that a particular guideline doesn't apply to them. Otherwise, people could say, "I don't care if that author is from the UK, people in the US read her a lot so we're going to use American English despite ]", etc. There's no point in having guidelines if they can essentially be overruled in every case by one or two "local" editors. ] (]) 12:31, 31 July 2011 (UTC)
::::Qwyrxian, I know you have worries and concerns, and that's normal for someone (now Admin) in your position, and the position you've assumed in this discussion, helping draft update language to the guideline. But I'm lowly editor, so I don't think or worry along the same lines as you, regarding uniform enforecment of WP policy, what precedents might mean re future implications, etc. So I can't help in that regard. About the issue here though, when you say you're "not fine with the idea of Misplaced Pages articles being substantially different from our reliable sources", as far as the game continuations I've mentioned (two in ], one in ], one in ], something on Rice Gambit in ]), I'm not in position to answer that and say "yes they are" or "no they're not", because I don't know. And I don't know if those specific game continuations AND their respective diagrams are, or are not, in reliable sources. (Because what we're talking about here is really a ''pair'' &ndash; a problem composition + its solution; a real game position-diagram + its continuation.) I have no idea. Maybe the editors who added that material would know. But they aren't here discussing. There's no way to know without their participation. (Which just makes me more curious about this whole process. What language can or will be drafted? And what are the implications for the aforementioned articles containing game continuations? (And I'm sure there are many more like them!) I mentioned before how brilliant or difficult game continuations might be "hidden" (appendixed) in books sometimes, or probably usually they aren't and occur on same page. But for any particular game continuation in any particular article (like the aforementioned ones), what will be done? Independent investigations for each? Revert for each unless editors can prove those particular game continuations are found in a reliable source, equally hidden? I don't even know if all that research is possible or likely! It will certainly be time consuming. But if you like to be uniform, as you do, there's no ignoring all of this intricacy and difficulty. (And to think it all started with the cute, little Pogar 2-mover, when you discovered me applying "hide"/"show" to the solution!) I'm curious what will become of this RfC, in light of the intricacy and difficulty alluded to. And another amazing point: I'm not aware anyone from WikiProj Chess registering comment here, or in the AN/I, or even at ]! (I've been also curious about that too. I wonder why it is. I wonder if they don't see any of this worth their time. And if they don't, why they don't.) When you reverted me at ], it was just because the edit caught your eye. While there are probably an unknown, maybe hundreds, of chess problem compositions already existing in mature articles. And now that I've introduced the point of brilliant and difficult game continuations, also found in mature articles, it just expands the issue very broadly, mutiplying the intricacy and complexity and difficulty. (Does that explain the lack of participation from WikiProj Chess members? That they view it, if they took a look at all, as nothing more relevant than Ihardlythinkso being picked on at ]? A funny insignificant trifle, since the broader spectrum of already-imbedded problem compositions + solutions, and real game positions + brilliant or difficult continuations, are widespread and deep, and no one or two Admins who jumped on Ihardlythinkso could possibly pose a challenge to those mature articles, or would ever think of making new policy and then use it as a precedent to go messing with those articles, ever? So why give a hoot? ) Peace! ] (]) 13:50, 31 July 2011 (UTC)
:::::I would still like to see some more participation from WikiProject Chess, but barring that I think that making "chess problems and continuations" an exception is an elegant solution. I also see no harm in doing so - the "hide" default is used so widely for other purposes, this just shouldn't be that big of a deal. ] (]) 15:02, 31 July 2011 (UTC)
::::::First Light, thx, but I doubt Qwyrxian would agree w/ you. Ok, ] (]) 17:10, 1 August 2011 (UTC)

== En dash change proposal ==

If you're weary of en dashes, and don't care exactly where to draw the line on the compromise about when to space them in complicated ranges, read no further. If you care, let's consider adjusting it. Jeff and I had a disagreement about process, but I pretty much agree with some of his points, and would suggest pushing Noetica's artful compromise just a little bit further. Jeff seems to have declined to provide a specific suggestion, so I'll propose one.

The present version says:

<hr/>

The en dash in a range is always unspaced, except for times and dates (or similar cases) when the components already include at least one space.
*{{!xt|*23&nbsp;July 1790–1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{!xt|*14&nbsp;May–2&nbsp;August 2011}}
*{{xt|23&nbsp;July 1790&nbsp;– 1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{xt|14&nbsp;May&nbsp;– 2&nbsp;August 2011}}
*{{xt|10:30&nbsp;pm Tuesday&nbsp;– 1:25&nbsp;am Wednesday}};&nbsp;&nbsp; {{xt|Christmas Day&nbsp;– New Year's Eve}};&nbsp;&nbsp; {{xt|Christmas 2001&nbsp;– Easter 2002}}
*{{xt|1–17 September}};&nbsp;&nbsp; {{xt|February–October 2009}};&nbsp;&nbsp; {{xt|1492?&nbsp;– 7&nbsp;April 1556}}
*{{xt|Best absorbed were wavelengths in the range 28&nbsp;mm&nbsp;– 17&nbsp;m.}}

<hr/>

I propose to take out some of the positive examples, and reword the guidance to narrow the situations in which spacing is used:

<hr/>

The en dash in a range is always unspaced, except when the ends of the range are long enough or complicated enough, with spaces in them, that it is important to signal a wider scope of connection; for example, to avoid connecting a number with one component directly with an inappropriate part of the other.
*{{!xt|*23&nbsp;July 1790–1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{!xt|*14&nbsp;May–2&nbsp;August 2011}} (inappropriately suggesting 1790–1 and May–2)
*{{xt|23&nbsp;July 1790&nbsp;– 1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{xt|14&nbsp;May&nbsp;– 2&nbsp;August 2011}}
*{{xt|10:30&nbsp;pm Tuesday&nbsp;– 1:25&nbsp;am Wednesday}};&nbsp;&nbsp; {{xt|Christmas 2001&nbsp;– Easter 2002}};&nbsp;&nbsp; {{xt|1492?&nbsp;– 7&nbsp;April 1556}} (avoid suggesting Tuesday–1:35, 2001–Easter, and 1492?–7)
Having a space, or mixed numbers and words, in a component is not necessarily enough to trigger this need; editorial judgement is needed, as simpler components with spaces in them should retain the en dash unspaced:
*{{xt|wavelengths in the range 28&nbsp;mm–17&nbsp;m}};&nbsp;&nbsp; {{xt|Christmas Day–New Year's Eve}} (mm–17 and Day–New are unlikely to be confusing)
Sometimes recasting to avoid the complication is preferable:
*{{xt|wavelengths in the range 0.028–17&nbsp;m}};&nbsp;&nbsp; {{xt|from Christmas Day through New Year's Eve}}

<hr/>

Please '''support''' or '''opppose''' this change, and/or propose a modification to make it better.

* '''Support''' as nom. I don't care strongly one way or the other, but if Jeff is right that there is more support, or more reasoned support, to less often spacing the en dash, maybe that will come out here. Basically, I think that choosing among the options suggested in style manuals is really an "I like it" process, in spite of what he says, so I have nothing more to say except that I think I'll like the result of this guidance a little better. I won't be offended if others prefer to keep what Noetica came up with. Let's don't make it a fight, just see which way the wind is blowing. ] (]) 21:43, 24 July 2011 (UTC)

* '''Comment''' I tried to stay out of the details while we were trying to actually once again function like ''civilized'' hairless apes. But some of these complex ranges look like poor writing practice to me. I think there is too much ''symbolitis'' on Misplaced Pages. Shall we consider something like the following:

<hr/>
For simple ranges, the en dash is unspaced.
*{{xt|The usual amount added to Olympic-size swimming pools is 20–30 liters.}}
Spaces on both sides of the en dash are often best for mixed measures and those with multiple components to the measures:
*{{!xt|*23&nbsp;July 1790–1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{!xt|*14&nbsp;May–2&nbsp;August 2011}} (inappropriately suggesting 1790–1 and May–2)
*{{xt|23&nbsp;July 1790&nbsp;– 1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{xt|14&nbsp;May&nbsp;– 2&nbsp;August 2011}}
*{{xt|10:30&nbsp;pm Tuesday&nbsp;– 1:25&nbsp;am Wednesday}};&nbsp;&nbsp; {{xt|Christmas 2001&nbsp;– Easter 2002}};&nbsp;&nbsp; {{xt|1492?&nbsp;– 7&nbsp;April 1556}} (avoid suggesting Tuesday–1:35, 2001–Easter, and 1492?–7)
Editors should consider recasting complex measures; particularly where space is not at a premium (i.e. body text and not tables). Mixed measures or those with multiple components to the measures are often more readable fully written out:
*{{!xt|wavelengths in the range 28&nbsp;mm–17&nbsp;m}};&nbsp;&nbsp; {{!xt|Christmas Day–New Year's Eve}}
*{{xt|wavelengths ranging from 28&nbsp;millimeters to 17&nbsp;meters}};&nbsp;&nbsp; {{xt|from Christmas Day through New Year's Eve}}
*{{xt|from 23&nbsp;July 1790 to 1&nbsp;December 1791}}
<hr/>
:That’s my suggestion. ] (]) 22:22, 24 July 2011 (UTC)
::Thanks; I took out a parenthetical that you left from mine that was inappropriate in yours. Let's hope future commenters will tell us which version they prefer (or OK with either); I'm OK with either. ] (]) 22:36, 24 July 2011 (UTC)

* '''Support'''. (merged after many ECs) A few suggestions:
*#I’d like to see some way of dealing with {{xt|24&nbsp;July{{ndash}}3&nbsp;September 2012}}, for which I’ve previously noted that the beginning year is ambiguous. If it is meant that the start year is 2012, I think {{xt|24&nbsp;July–3&nbsp;September 2012}} would handle it just fine, though I’m sure some others would disagree. I see no problem whatsoever, and at worst see it as a lesser evil. I recognize that this would raise some other issues (e.g., if this were acceptable, why would not {{xt|24&nbsp;July{{ndash}}3&nbsp;September}} also be?). At the risk of hammering a point, I might also mention that it finds support in arguably the majority of top-selling guides, so the practice is hardly off the wall; I’ll save the clutter of mentioning them unless someone asks. Of course, some other widely used guides sometimes suggest the spacing, so perhaps this could be an area of editorial judgment (read: elements of our common language that aren’t common). One could of course eliminate the ambiguity by always including the start year, but this seems unnecessarily burdensome.
*#I’d like to mention considering recasting {{xt|wavelengths in the range 28&nbsp;mm–17&nbsp;m}} to {{xt|wavelengths in the range 28&nbsp;mm to 17&nbsp;m}} or {{xt|wavelengths in the range from 28&nbsp;mm to 17&nbsp;m}}, just because so many technical organizations fear confusion of the dash and minus (and apparently some of us aren’t thrilled with the dash, spaced or unspaced). I’d also like to see examples of both nominal and adjectival usage (e.g., {{xt|wavelengths in the range 28&nbsp;mm to 17&nbsp;m}} and {{xt|wavelengths in the 28&nbsp;mm–17&nbsp;m range}}); with the latter, recasting to use ''to'' would be difficult. The same might hold in a table where space is at a premium.
*#The guiding principle should be to minimize ambiguity, though the approach ultimately chosen may vary with editor and situation—it’s simply impossible to cover or even anticipate every situation. I certainly fell a bit short in the polling breakout.
:] (]) 22:45, 24 July 2011 (UTC)

::* I’m ahead of you on this one and agree. As I proposed above, these complex ranges are best just written out. Check it out. ] (]) 22:57, 24 July 2011 (UTC)
::::Hey, I started mine before you posted {{nowrap|. . .}} perhaps great minds think alike. ] (]) 23:06, 24 July 2011 (UTC)
{{od}}
Seeing a quick general consensus on something that seemed like a no-brainer, I took a close version of what I proposed above and grafted into MOS There is a slight redundancy now, but I think the point it makes (getting editors to think about whether they have two different units of measure to the same measure or have multi-component units) is worth providing. ] (]) 23:26, 24 July 2011 (UTC)
:You're more bold than I! I expect we'll get to discuss some more after you get reverted, but maybe I'm wrong and it will be OK. I once made an MoS change after brief discussion; it was a good way to find the opposers, and went down in flames. ] (]) 04:55, 25 July 2011 (UTC)
:I have problems with this bit: "Spaces on both sides of the en dash are often best where there are mixed units for the measures as well as those with multiple components to the unit." First, you don't give an example of "mixed units", and probably don't mean to suggest doing the spaces in "28 mm – 2 m" and such. Second, I don't what "multiple components to the unit" is supposed to mean. Can you fix? ] (]) 05:02, 25 July 2011 (UTC)
:: Indeed, I was not clear. ''Measures'' are things like volume or time. ''Units of measure'' are things like "kilogram" and its symbol kg. After your post, I checked my booleans and text and realized what I had there was unnecessarily confusing. I revised it so it should be ''much'' improved. And it now uses parentheticals to clarify buzzwords like “units” and “values.” It is beginning with {{xt|For simple ranges where the en dash replaces the word “to”}}… If you don’t like what I have there, please revise until it makes sense to you. ] (]) 15:14, 25 July 2011 (UTC)
:::Your seems to have flipped advice back to more spaced en dashes, in 28 mm – 17 m. I thought this was what we were moving away from. But I'll let you and Jeff work it out for a while, and see if anyone else cares. ] (]) 03:12, 26 July 2011 (UTC)
:::As for Jeff's corner case "24 July–3 September 2012", I can't imagine how anyone could interpret it as other than two dates in the same year, whether the dash is spaced or not. Anyone who wants to say from about now to a date later in 2012 would add the 2011, if they had any sense. So I would oppose any attempt to "deal with" this case by way of punctuation. Whether you decide the two dates with one year should have spaces or not is no big deal to me. ] (]) 04:12, 26 July 2011 (UTC)
:::While we're at it, why not a date example with commas in it: (July 24, 2011 – September 3, 2012)? I see these in bios and such. ] (]) 04:17, 26 July 2011 (UTC)
::::On ranges such as “28&nbsp;mm{{ndash}}17&nbsp;m”: same impression as Dick. Again, I would show both nominal and adjectival usage, because the latter is more difficult. In many cases, the adjectival usage can be recast to a nominal, but sometimes it cannot be done easily. My example of “20&nbsp;kHz–20&nbsp;Hz propagation delay” might be recast as “propagation delay from 20&nbsp;kHz to 20&nbsp;Hz”, but this also is initially confusing because it reads as if propagation delay is reduced from 20&nbsp;kHz to 20&nbsp;Hz. Clearly, this is nonsense and should be quickly recognized as such, but there is a tiny bit to sort out, so it makes for more difficult. Any way, the phrase is jargony, and possibly confusing to anyone who isn’t pretty well versed in what is being discussed. But “the propagation delay of a 20&nbsp;Hz signal relative to that of a 20&nbsp;Hz signal” is pretty awkward, too. In this case, I think the closed-up adjectival use is arguably the least of evils. And in a table, it might be the only option.
::::On “24&nbsp;July–3&nbsp;September 2012”: you’re probably right—it’s more a case of initial ambiguity, though spreading things out does tend to loosen the association of “4&nbsp;July–3&nbsp;September”. It’s not as if most of these things can’t be sorted out, but rather at how much of a double take is needed. Quite honestly, I have a tough time imagining anyone who sees “4&nbsp;July–3&nbsp;September” reading “July–3”; after all, the spacing is nominally half an em vs. a third em, and “July–3” would be a mighty unusual way of giving month&nbsp;+ day. But I guess it depends on the main determinant of association—is it the amount of separation or the type of mark? There definitely appears to be two schools of thought on this.
::In any event, ranges of physical quantities are a bigger deal because at least some of us frequently deal with addition and subtraction of them. What think you, Greg? ] (]) 07:15, 26 July 2011 (UTC)<p><br>
:::* Jeff, I was trying to edit within consensus. My read about consensus was that other editors here wanted to replace the “to” in date ranges and the trick was how best to make it most readable, thus {{xt|23&nbsp;July 1790&nbsp;– 1&nbsp;December 1791}}.<p>''Personally'', I think this and similar constructions like {{xt|wavelengths in the range 28&nbsp;mm – 17&nbsp;m}} read very poorly. The ''whole point'' about all writing is to make it enjoyable to read. The great challenge of ''technical writing'' is to make it as non-confusing and illuminating as possible for the target readership. ''Any'' text or writing style that unnecessarily slows down the eye or unduly calls attention to itself is verboten.<p>Many readers live in countries where dates are commonly formatted a particular way. For instance, the date example I used here uses a convention that is common in European countries. Americans, who are accustomed to {{xt|July 23, 1790}} already have their brains slowing down to parse formats such as this; adding an en&nbsp;dash makes the brain work even harder to parse the construction.<p>The same brain struggle occurs when we mix different units of measure. I personally think that {{xt|wavelengths in the range 28&nbsp;mm – 17&nbsp;m}} is an abomination unto the eyes of the technical writing gods. When I ran across this the very first time here, my eye doubled back ''twice'' and my first thought (or second or third—I can’t recall) was that a mistake had been made and an “m” had been omitted. Is there a respected manual of style that we pulled that one from?<p>Were it me, my advise would be as follows:
<p>
<hr/>
:::::For simple ranges where the en dash replaces the word “to” between two positive integers (numbers like {{xt|20}} and {{xt|30}}), the en dash is unspaced.
:::::*{{xt|The usual amount added to Olympic-size swimming pools is 20–30 liters}};&nbsp;&nbsp; {{xt|pp.&nbsp;211–219}};&nbsp;&nbsp; {{xt|64–75%}};&nbsp;&nbsp; {{xt|the 1939–45 war}}
:::::For date ranges involving years from 1000 AD or later, it is acceptable to truncate the first two digits from the second year. For all other numbers, do not truncate.
:::::* Right: {{xt|pp.&nbsp;211–219}};&nbsp;&nbsp; {{xt|64–75%}};&nbsp;&nbsp; {{xt|the 1939–45 war}};&nbsp;&nbsp; {{xt|the 1939–1945 war}}
:::::* Wrong: {{!xt|pp.&nbsp;211–19}}
:::::Do not mix en dashes with prepositions like ''between'' and ''from''.
:::::*{{xt|450–500 people}}
:::::*{{xt|between 450 and 500 people}}, not {{!xt|between 450–500 people}}
:::::*{{xt|from 450 to 500 people}}, not {{!xt|from 450–500 people}}
:::::If negative values are involved, an en dash might be confusing. Use words instead.
:::::*{{xt|&minus;10 to 10}}, not {{!xt|&minus;10–10}}
:::::*{{xt|the drop in temperature was from 5° to &minus;13°}}, not {{!xt|the drop in temperature was 5°–&minus;13°}}
:::::For anything else, do not replace the word “to” with an en dash. Examples of constructs to avoid using the en dash include when ''units of measure'' (millimeters ''and'' meters or their symbols, names of months and days of the month for instance) appear on both sides of the word “to”; they should be fully written out:
:::::*Wrong: {{!xt|wavelengths in the range 28&nbsp;mm–17&nbsp;m}}
:::::*Wrong: {{!xt|wavelengths in the range 28&nbsp;mm – 17&nbsp;m}}
:::::*Wrong: {{!xt|23&nbsp;July 1790–1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{!xt|14&nbsp;May–2&nbsp;August 2011}}
:::::*Wrong: {{!xt|23&nbsp;July 1790&nbsp;– 1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{!xt|14&nbsp;May&nbsp;– 2&nbsp;August 2011}}
:::::*Wrong: {{!xt|wavelengths in the range 28&nbsp;mm–17&nbsp;m}};&nbsp;&nbsp; {{!xt|Christmas Day–New Year's Eve}}
:::::*Right: {{xt|wavelengths ranging from 28&nbsp;millimeters to 17&nbsp;meters}};&nbsp;&nbsp; {{xt|from Christmas Day through New Year's Eve}}
:::::*Right: {{xt|from 23&nbsp;July 1790 to 1&nbsp;December 1791}}
:::::*Right: {{xt|from July 23, 1790 to December 1, 1791}}
<hr/>
::::Note that I also suggest not truncating page numbers; at least up to three digits ({{xt|pp.&nbsp;211–219}} and not {{!xt|pp.&nbsp;211–19}}), which takes care of the vast majority of books). That’s what I think is best. ] (]) 15:31, 26 July 2011 (UTC)
:::::Greg, you're not being responsive to the issue. Your "as I would do it" version has no chance of approaching consensus, since date ranges in bio are so well established, so why distract us with it? And your previous proposal to space the en dash in "28 mm – 17 m" is at odds with what I and Jeff asked for. It's OK if you disagree, and prefer the Brit style on that, but then say so; this is the area where the previous consensus was most marginal, so we're looking to fine tune it. If Jeff would make a definite proposal, that would help, too. From how this is going, I'd say finding a consensus to change it is looking unlikely. But we definitely don't want you or Jeff or feel like you haven't been heard on it. ] (]) 15:57, 26 July 2011 (UTC)
::::::*There’s no need to jump my bones over this. I haven’t tracked the blow-by-blow (water under the bridge) leading to where we are today and have no appreciation for what is “Brit” style or not. I only stated what I think will read most naturally for an ''international'' readership reading an ''English-language'' publication. What works for an American or Brit or an English-speaking Italian may not work fluidly when ''the others'' read it.<p>So I stated my opinion as to what I think results in maximum reading flow for the widest spectrum of readers without prejudice or passion for which country’s writing customs might be disrespected (and therefore fully entitled to a road-rage brawl or “honor scuffle” in the parking lot). If expressions must be had where units of measure other than years appear on ''both'' sides of the en&nbsp;dash, then what is on MOS now works for me.<p>I’m all turned off now over how passionate (read: borderline hostile) the tenor quickly developed here and will avoid this page until tomorrow morning. Bye. ] (]) 16:11, 26 July 2011 (UTC)<p><br>'''P.S.''' But, thinking about what you said regarding biographies, I amended my preference. Back to the real world until tomorrow. ] (]) 16:47, 26 July 2011 (UTC)

<hr/>
:::::For simple ranges where the en dash replaces the word “to” between two positive integers (numbers like {{xt|20}} and {{xt|30}}), the en dash is unspaced.
:::::*{{xt|The usual amount added to Olympic-size swimming pools is 20–30 liters}};&nbsp;&nbsp; {{xt|pp.&nbsp;211–219}};&nbsp;&nbsp; {{xt|64–75%}};&nbsp;&nbsp; {{xt|the 1939–45 war}}
:::::For date ranges involving years from 1000 AD or later, it is acceptable to truncate the first two digits from the second year. For all other numbers, do not truncate.
:::::* Right: {{xt|pp.&nbsp;211–219}};&nbsp;&nbsp; {{xt|64–75%}};&nbsp;&nbsp; {{xt|the 1939–45 war}};&nbsp;&nbsp; {{xt|the 1939–1945 war}}
:::::* Wrong: {{!xt|pp.&nbsp;211–19}}
:::::Do not mix en dashes with prepositions like ''between'' and ''from''.
:::::*{{xt|450–500 people}}
:::::*{{xt|between 450 and 500 people}}, not {{!xt|between 450–500 people}}
:::::*{{xt|from 450 to 500 people}}, not {{!xt|from 450–500 people}}
:::::If negative values are involved, an en dash might be confusing. Use words instead.
:::::*{{xt|&minus;10 to 10}}, not {{!xt|&minus;10–10}}
:::::*{{xt|the drop in temperature was from 5° to &minus;13°}}, not {{!xt|the drop in temperature was 5°–&minus;13°}}
:::::For regular body text, do not replace the word “to” with an en dash if ''units of measure'' (millimeters ''and'' meters or their symbols, names of months and days of the month for instance) appear on both sides of the word “to”. Instead fully write out the expression:
:::::*Wrong: {{!xt|wavelengths in the range 28&nbsp;mm–17&nbsp;m}}
:::::*Wrong: {{!xt|wavelengths in the range 28&nbsp;mm – 17&nbsp;m}}
:::::*Wrong: {{!xt|23&nbsp;July 1790–1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{!xt|14&nbsp;May–2&nbsp;August 2011}}
:::::*Wrong: {{!xt|23&nbsp;July 1790&nbsp;– 1&nbsp;December 1791}};&nbsp;&nbsp;&nbsp; {{!xt|14&nbsp;May&nbsp;– 2&nbsp;August 2011}}
:::::*Wrong: {{!xt|wavelengths in the range 28&nbsp;mm–17&nbsp;m}};&nbsp;&nbsp; {{!xt|Christmas Day–New Year's Eve}}
:::::*Right: {{xt|wavelengths ranging from 28&nbsp;millimeters to 17&nbsp;meters}};&nbsp;&nbsp; {{xt|from Christmas Day through New Year's Eve}}
:::::*Right: {{xt|wavelengths ranging from 28&nbsp;mm to 17&nbsp;m}}
:::::*Right: {{xt|from 23&nbsp;July 1790 to 1&nbsp;December 1791}}
:::::*Right: {{xt|from July 23, 1790 to December 1, 1791}}
:::::For the first sentence of biographies, citations, and other sections of articles where parenthetical-like data is customary and expected, the word “to” may be replaced with an en&nbsp;dash in a ranges of dates. When doing so, place a space on both sides of the en&nbsp;dash:
:::::*Right: {{xt|23&nbsp;July 1790&nbsp;– 1&nbsp;December 1791}}
:::::*Right: {{xt|July 23, 1790&nbsp;– December 1, 1791}}
:::::*Wrong: {{!xt|23&nbsp;July 1790–1&nbsp;December 1791}}
<hr/>
::::] (]) 16:47, 26 July 2011 (UTC)

:::::I didn't know you were such a sensitive guy, Greg, so please excuse my clumsy nudge. I just wanted to point out that there's some delicacy involved if we're to fine tune the current consensus to a better one. Jeff is the one can tell you how much opinions are worth (his "I just like it" complaint), so I thought we could focus on where they differ, and talk logically about those differences; you don't need to know the gory history, but need to recognize that I was trying to offer a step toward Jeff's logically-preferred position (or is it just his opinion?); and you stepped back from there while saying you were trying to represent our emerging consensus (at least on the 28 mm – 17 m thing).
:::::Here's what you need to know: on this spacing issue, the old MOS (stable for many years before recent months) reflecting the Brit view was crafted by Tony and Noetica and others, in a good discussion circa 2007 or earlier. It calls for ''spaced'' en dashes more often than was natural with us Yankies. When we had the big vote on the details, this area came out quite mixed, even after Tony and Noetica agreed to compromise and use the spaces only in more complicated things like date ranges. I was happy. A majority was happy. Jeff wasn't happy, because he wanted to see it move it bit more, and because he didn't like the fact that we didn't quite find a strong consensus. PMAnderson made no comment on these provisions until we were all done, and then used it say that consensus was not achieved, so we shouldn't accept the new en dash section as a whole (it's still not clear if he wants to see changes in this section, or whether he likes it but just doesn't want to see anyone claiming the the MOS has consensus).
:::::So I wanted to give Jeff a chance to help find a better consensus. But Jeff has continued to decline to propose a version he likes, and you've not helped with your "support" of my proposal, so I think I'll give up. I don't really care if we keep the version you boldly changed to, or go back to what Noetica had done. My impression is that we are close enough to "consensus", meaning there's nobody who can't live with it, unless someone else is willing to say exactly how we need to change it make them happy. I don't think anyone but Jeff is likely to give that a try, but we'll see.
:::::And I don't think any of us are getting passionate, personal, or otherwise steamed up over it—I'm sorry if my text gave that impression. ] (]) 21:50, 26 July 2011 (UTC)
::::::Um, Greg, what are you waiting for me to propose? I’d have been glad to do it had I realized you were waiting :-). My approach may be slightly different from that of others—I usually look to first discuss concepts (like closed-up dashes for ranges of physical quantities). Based on years of experience with committees, working from a document “to argue away from” usually ensures much argument (perhaps not so much as here, but that could simply be because fewer people are involved). How often have I prevailed in getting agreement in concept before drafting? Far less often than I would like. What has it cost me? In some cases, several years and suboptimal results.
::::::Is my preferred practice more “logical”? That’s impossible to resolve—I think it’s really a matter of “Iwannadoitmyway”, as many here have mentioned (Darkfrog24 most recently). I can certainly give reasons why I think some aspects of “North American” practice are better, but Noetica and Tony might not agree. But I again note one thing: however it’s determined, North Americans are a substantial fraction of the English-speaking and English-publishing world—and for the most part, NA style guides seem to lead the sales in the US, Canada, ''and'' the UK. By no means does this mean that NA practice is any better than any other—CUP is hardly run by a bunch of idiots—but it’s not completely nuts, either. And I think it has sometimes been given short shrift here.
::::::I certainly wasn’t looking to take you on, and I doubt that Dick was either. Sorry if I came across that way.
::::::In any event, let me know what I haven’t produced and I’ll try to better describe it. ] (]) 01:17, 27 July 2011 (UTC)
:::::::Jeff, we're tired of concepts and just want to settle on a version; I applaud Greg for boldly pushing for what he thought would work, even if I thought it was unlikely to please you (and though I pushed back on some of his intermediate versions). If you like Greg's, say so. If not, propose a specific change or a new version. Noetica asked you several times for a definite proposal, and got nothing but long discourse and complaints about process and his use of "we". This doesn't need to be as slow as a standards committee. Excuse my increasing grumpiness. ] (]) 02:27, 27 July 2011 (UTC)

===Jeff Conrad’s proposals===
Dick, for practical purposes, I actually did submit a proposal. I normally follow North American practice, which has very simple rules: en dashes are always unspaced, so few examples are needed. We seem to need such an extensive treatment because our rules are so complicated. Now NA guide aren’t necessarily right, but they do far outsell all others, in some case even outside NA, so they can’t be all that bad, either. And above all, they’re simple. Note though, that in polling, I was OK with spacing dashes in ranges of full dates, largely recognizing Tony’s comment that the style is well established here, especially in bios. And I also don’t care for {{!xt|23&nbsp;July 1790–1&nbsp;December 1791}} because I initially see “1790–1791”.

Again the rules are simple:
----
;Approach 2:

Dashes are spaced when both endpoints are full dates (e.g., some combination of numerical date, spelled-out or abbreviated month, and year):

*{{xt|23&nbsp;July 1790{{ndash}}1&nbsp;December 1791}} not {{!xt|23&nbsp;July 1790–1&nbsp;December 1791}}
*{{xt|June&nbsp;25, 1988{{ndash}}April&nbsp;3, 1989}} not {{!xt|June&nbsp;25, 1988–April&nbsp;3, 1989}}
----
We’re done . . .

This didn’t seem to be what most folks wanted; allowing for other personal preferences, I might add
----
;Approach 3:

Dashes ''may'' be spaced in other ranges of dates for which both endpoints contain a space:
*{{xt|24&nbsp;June–23&nbsp;July 2010}} or {{xt|24&nbsp;June{{ndash}}23&nbsp;July 2010}}
*{{xt|May&nbsp;1–December&nbsp;3}} or {{xt|May&nbsp;1{{ndash}}December&nbsp;3}}
*{{xt|Christmas Day–New Year's Eve}} or {{xt|Christmas Day{{ndash}}New Year's Eve}}
*{{xt|Christmas 2001–Easter 2002}} or {{xt|Christmas 2001{{ndash}}Easter 2002}}

Dashes are always unspaced in ranges of dates, times, physical quantities, or similar, for which only one endpoint contains a space:

*{{xt|17–22 April}} not {{!xt|17{{ndash}}22 April}}
*{{xt|August 6–8}} not {{!xt|August 6{{ndash}}8}}
*{{xt|5:45–6:30 p.m.}} not {{!xt|5:45{{ndash}}6:30 p.m.}}
*{{xt|4–20&nbsp;mA}} not {{!xt|4{{ndash}}20&nbsp;mA}}
*{{xt|24–105&nbsp;mm}} not {{!xt|24{{ndash}}105&nbsp;mm}}

Dashes are always spaced in ranges of time that span more than one day:
*{{xt|10:30&nbsp;pm Tuesday{{ndash}}1:25&nbsp;am Wednesday}} not {{!xt|10:30&nbsp;pm Tuesday–1:25&nbsp;am Wednesday}}

Dashes ''may'' be spaced in other ranges of time for which both endpoints contain spaces:
*{{xt|10:30&nbsp;pm–1:25&nbsp;am}} or {{xt|10:30&nbsp;pm{{ndash}}1:25&nbsp;am}}

Dashes ''may'' be spaced in other ranges for which one or both endpoints are long or complex, and for which closed-up use could be confusing; it is impossible to cover every case, so sometimes the editor must exercise judgment.

Dashes ''may'' be spaced in ranges of physical quantities for which both endpoints contain spaces, as when units are repeated for both endpoints or when the endpoints have different units:
*{{xt|28&nbsp;mm–70&nbsp;mm}} or {{xt|28&nbsp;mm{{ndash}}70&nbsp;mm}}
*{{xt|wavelengths in the range 28&nbsp;mm–17&nbsp;m}} or {{xt|wavelengths in the range 28&nbsp;mm{{ndash}}17&nbsp;m}}

Care should be taken when spacing en dashes in ranges of physical quantities because of possible confusion with the minus (−). Confusion seldom arises with ranges of dates because they are usually not subtracted; however, subtraction of physical quantities is a common occurrence. Because the minus is normally spaced, confusion can sometimes be avoided by closing up the dash:
*{{xt|20&nbsp;Hz–20&nbsp;kHz}}

Quantities with units or unit symbols on both sides of the dash are often more readable when written out using ''to'', especially when the units are spelled out:
*{{xt|wavelengths in the range 28&nbsp;mm–17&nbsp;m}}; sometimes better, {{xt|wavelengths ranging from 28&nbsp;mm to 17&nbsp;m}}
*{{xt|20&nbsp;Hz–20&nbsp;kHz}}; sometimes better, {{xt|20&nbsp;Hz to 20&nbsp;kHz}}
*{{xt|wavelengths in the range 28&nbsp;millimeters – 17&nbsp;meters}}; better, {{xt|wavelengths ranging from 28&nbsp;millimeters to 17&nbsp;meters}}

Recasting may not be practical when space is at a premium (as in a table), or when the use is adjectival:
*{{xt|20&nbsp;Hz–20&nbsp;kHz response}} not {{xt|20&nbsp;Hz to 20&nbsp;kHz response}} or {{xt|20&nbsp;Hz-to-20&nbsp;kHz response}}

Complex ranges of dates are also often better recast:
*{{xt|Christmas Day–New Year's Eve}} or {{xt|Christmas Day{{ndash}}New Year's Eve}}; better, {{xt|Christmas Day through New Year's Eve}}
*{{xt|from 23&nbsp;July 1790{{ndash}}1&nbsp;December 1791}}; better, {{xt|from 23&nbsp;July 1790 to 1&nbsp;December 1791}}
----
To be honest, I’m not sure I really prefer the recast of “Christmas Day–New Year’s Eve” to “Christmas Day through New Year’s Eve”. And I′m still not convinced that this is a date (and even if it is, why is confusion more likely than with “San Francisco–Denver flight”?) In any event, I’ve listed it as a date so as not to get sidetracked.

Note that I don’t call for barring using less than the full range of page numbers. I usually include the last two (e.g., {{xt|pp. 1137–39}}, {{xt|pp. 1407–22}}). Obviously, this doesn’t work if the first number in the range changes: {{xt|pp. 883–901}}. Comprehensive guidance on this obviously would require some additional work.

At least to me, most of this isn’t too different from what several others have suggested.

I hardly suggest that this is sufficiently polished to incorporate as is (though perhaps it’s close). In particular, additional spacing between examples on the same line would probably improve things. And I’ve probably overlooked something. But this should give a general idea. In essence, I would allow either North American or British practice (add scare quotes if you must). In that sense, at least philosophically, I’d recommend everything, but the biggest initial issue is with spaced dashes in ranges of quantities—I don’t like ’em.

With the optional usages, most of my preferences (unspaced) are at the left. Are they better than the ones with spaces? There’s no answer. But are they worse? If so, I’d like to know why. And if so, why are they acceptable to (and often called for) the majority of widely used guides?

Greg, I hope this addresses what you were requesting, whether or not you agree with my ideas. ] (]) 07:15, 27 July 2011 (UTC)

:OK, better; a too-long and too-short proposal, but now we know more specifically what you're thinking. I hadn't realized that you wanted to leave such a wide range of cases up to editor discretion; if we do that, we can do it with many fewer examples, don't you think? But I felt like there was stronger support for more definite guidance, than for more options (there was some of that, too, I recognize). Let's see what Greg thinks, and whether anyone else cares. I can draft an intermediate-length polished version if it looks like that's where the wind is blowing. ] (]) 19:12, 27 July 2011 (UTC)

::*Whatever you guys want. I’m tired of so much fuss on en dashes. It should be less than 1% as difficult as getting dates delinked and ridding us of the IEC prefixes but has exceeded that threshold. ] (]) 19:40, 27 July 2011 (UTC)

::Dick, easier to trim a long one that to guess at what I want from a short one, right? On editor discretion: my real preference is pretty simple—I would prefer to do things in the manner to which ''I'' am accustomed, perhaps with the exception of ranges of full dates and times. But we know that clearly would not fly. I, like several others, have objected to a seeming imposition of what’s arguably minority practice, and if Butcher is the guide, one that is permissive rather than mandatory. We could argue all day (Day? Who am I kidding {{nowrap|. . .}}) about which is better—some could cite “five major guides” that support the more frequent spacing, and I could cite ten arguably “more major” guides that call for everything to be closed up. I think we know where that would lead {{nowrap|. . .}} So unless we battle to the death over forcing people to follow something to which they may object (with either British or NA practice), allowing either seems the only way. And quite honestly, we seem to be in pretty good agreement about allowing spaced en dashes for parenthetical dashes is essentially allowing either non-OUP British practice or NA practice, and and in doing so acknowledging the either is valid. I have a fair number of books from quality British publishers, and honestly find the spaced en dash a bit distracting—but I suppose many accustomed to the British style have the same reaction to unspaced em dashes. And the same is probably true of unspaced vs. spaced en dashes. But it’s worth noting that the usages that we’ve been discussing to death are pretty infrequent—I have to search mighty hard through all of my CUP and Elsevier books to find even a few examples. More succinctly: we seem to have no problem with allowing two different styles for a usage that is very common but get all worked up about doing so for a usage that is comparatively rare.
::I’m sure someone will take issue with my characterization as “British” or “North American”. But Chicago, OUP, Garner, and others describe it as such, so what’s the big deal? Compared with AmE–BrE differences in spelling, these differences seem pretty minor.
::So I guess I proposed what I did because it’s probably as unreasonable to insist that people do it ''my'' way as I claim it is for others to insist that I do it ''their'' way. I agree with you that many editors seem to have wanted more specific guidance. But if we insist on a more prescriptive approach, we are faced with which one to prescribe; I would of course insist on the one ''I'' prefer, and for which I could make a pretty strong case is very much the majority approach. And the the debate would continue forever {{nowrap|. . .}}
::As for the length: a bit of rearrangement and consolidation might slightly reduce the size. I was so tired when I wrote it that I could barely stay awake {{nowrap|. . .}} I’m amazed it’s even semi-coherent. ] (]) 21:32, 27 July 2011 (UTC)

::Greg, you objected that I had not made a proposal, and you now almost seem to be objecting that I have. Am I missing something? For what it’s worth, having recently been through a long and pointless discussion about quotation marks, I wanted nothing to do with this discussion, as Dick can attest. I completely agree with you that the effort expended here boggles the mind, especially when I think of what could have been accomplished had the same effort been expended on weightier issues. And there’s still significant disagreement on a couple of points {{nowrap|. . .}} I’ve been using en dashes for 25 years—almost as long as I have had access to something that could render them. For guidance, I simply grabbed a couple of widely used guides (primarily ''CMOS''), spent a few minutes reading what was recommended, and moved on. Here, of course, not everyone prays to the same Guide, with each side insisting that “my Guide is bigger than yours”. And until we can resolve which is the One True Guide, the debate will continue. We could, of course, recognize that there may be more than one True Guide, which is something like I have proposed. ] (]) 21:51, 27 July 2011 (UTC)
:::No, I’m not objecting to anyone’s proposals, Jeff. Everyone active on this issue as of late is knowledgeable, acting in good faith, and is plenty civil enough. I just don’t understand why so much effort has been (and currently is being) spent on en-dash stuff. I’ve grown weary of it because I see so much effort being expended and the car is still spinning its wheels in wet snow. I’ve thrown out my own ideas so those of you who are still keenly interested in further fleshing this stuff out can adopt bits & pieces of it, the whole thing, or nothing at all.<p>I personally think that en-dashes should be kept to a minimum because the word “to” is really easy to read. So all this head scratching trying to figure out how to expand the circumstances under which we can replace something über-easy to read with an en-dash '''''and still have the text be easily parsed by the eye''''' seems a brain damaged endeavor.<p>I lump the expanded superset of en-dash usage in the same camp as single-divisor math featuring negative superscripted exponents like {{!xt|A rocket engine with a flow rate of 300&nbsp;L&nbsp;s<sup>–1</sup>}} rather than the '''''far''''' more accessible {{xt|A rocket engine with a flow rate of 300&nbsp;liters per second}} or even {{xt|A rocket engine with a flow rate of 300&nbsp;L/s}}. Oh, yes; we all know there is ''far'' too much of this going on all over Misplaced Pages. I’m certain there are many editors who think they “appear smart” because they “write smart and abstrusely and all *scientificy*.”<p>Which brings up another flaw; Misplaced Pages is far, ''far'' too quick to launch into unit symbolitis rather than spell them out. Most quality publications would write {{xt|A first-press squeeze of 100 kilograms of olives would produce 20–25 liters of extra-virgin olive oil.}} We all know there are many wikipedians, who deep down think that using unit symbols is futuristic and cool, who would write {{!xt|A first-press squeeze of 100&nbsp;kg of olives would produce 20–25&nbsp;L of extra-virgin olive oil.}}<p>That’s my Thank you for listening. ] (]) 00:19, 28 July 2011 (UTC)
:::: <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 00:58, 28 July 2011 (UTC)
::::: Oh, well then… That doesn’t tell us what is good practices for regular body text in an encyclopedia, does it?
::::::* Wrong: {{!xt|24 June–23 July 2010}}
::::::* Correct: {{xt|Oh, fuck it.}}
::::: I’ve got ] on my side. ] (]) 02:18, 28 July 2011 (UTC)

====A brief digression on units and the clarity thereof====
Though I think superscripted negative powers are a bit hifalutin for most contexts, I still may be one of those evil trendies who generally prefer unit symbols—but it all depends on the context and the frequency of use. And the complexity of what is to be spelled out. A good example can be found in numerous stories about the San Bruno, California, gas pipeline explosion. For the most part, the normal operating condition was correctly described as “a pressure of 375 pounds per square inch”. But this gets pretty tedious if it’s mentioned several times in an article, and this apparently inspired some pretty creative writing, including “375 pounds per square inch of pressure”, and even “375 pounds of pressure per square inch” (lbf/in<sup>4</sup>?). Clearly, the first form is the only one that is unambiguous; perhaps the second could be handled as “375 pounds-per-square-inch of pressure”, though this seems awkward to me. The adjectival form might be “375-pounds-per-square-inch pressure”. The unit symbol form definitely has appeal here, but even so there are problems: “lb/in<sup>4</sup>” is ambiguous, because ''lb'' more often refers to mass than to force; “lbf/in<sup>4</sup>” isn’t ideal, either, because ''lbf'' isn’t standard symbol, and most non-technical readers don’t know the difference between pounds mass and pounds force anyway. Here I might prefer something like “a pressure of 375 pounds per square inch (lb/in<sup>2</sup>)”, with the symbols used thereafter or perhaps even “a pressure of 375 pounds per square inch (psi)” despite the universal deprecation of ''psi'' (which is probably the term most American engineers would use in informal conversation). Oh, f—k it&nbsp;{{nowrap|. . .}} There should be no doubt that I consider avoiding ambiguity with physical quantities mighty important, but in some cases there just isn’t an obvious best approach.

Getting back to topic: I think most of us would agree that clarity and easy reading are paramount. But we apparently don’t always agree on the forms that are easiest to read—probably has a lot to do with the forms to which we are accustomed. ] (]) 08:14, 28 July 2011 (UTC)
:When a unit of measure is long, like {{xt|the pipeline was pressurized to 375 pounds per square inch}}, and is repeated many times in the article, my advise for good technical writers is to parenthetically give the unit symbol {{xt|the pipeline was pressurized to 375 pounds per square inch (psi)}} and to ''then'' rely only upon unit symbols ({{xt|after the explosion, older pipelines had their operating pressure reduced to 290&nbsp;psi}}).<p>Depending on the nature of the article (if it is particularly long and prone to readers skipping to particular sections of interest, or if the parenthetical introduction to the unit symbol “psi” is mentioned early in the article and then doesn’t crop up again until way later), I will repeat the spelled-out version and the parenthetical introduction to the unit symbol when the unit of measure is once again mentioned: {{xt|it was later certified for operation at up to 350 pounds per square inch (psi)}}.<p>As technically minded writers, we get used to this stuff. As a mechanical and R&D engineer, I can authoritatively tell you than many people—typically women—are not as familiar with “psi” or pressures of any sort. Plain-speak and reinforcement of what unit symbols mean is important and is a lesson lost on many contributors who are intimately familiar with the subject matter. European writers tend to think that ''everyone'' including the extra-smart German Shepard next door knows what “kg” means. There are still plenty of people in America who were adults during the Korean war who get quickly lost when they see {{xt|100&nbsp;kg of olives}}. That is so needless; {{xt|kilogram}} doesn’t take up ''that'' much room and the vast majority of articles wouldn’t mention the unit so terribly often that such a simple, single-word unit of measure like {{xt|kilogram}} would bog the article down in eye-fatiguing tedium.<p>We all have to bear in mind that Misplaced Pages is directed to a ''general interest'' readership from all walks of life. I think editors who write this sort of stuff: {{xt|the typical garden hose in America delivers only about {{nowrap|0.5 L s<sup>&#x2012;1</sup>}}}}, ought to be required to pass a technical writing skills test before being allowed back. ] (]) 18:10, 28 July 2011 (UTC)
::Well, to those particular people writing {{xt|100 kilograms of olives}} wouldn't be particularly useful, either. {{xt|{{convert|100|kg|lb|0}} of olives}} is better, but in some particular cases {{xt|{{convert|100|kg|lb|0|abbr=on}} of olives}} is preferable. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 23:30, 30 July 2011 (UTC)
:@JeffConrad: I fully agree. Also, while empirically estimating which form is easier for readers to read is quite non-trivial <small>(there are a few studies about that, but the sample sizes aren't huge and the participants are usually undergraduate students, who might not be representative of the population as a whole)</small>, estimating which one they're most accustomed to is much easier (there are several ] available on the Web for free). <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 23:30, 30 July 2011 (UTC)

====New subpage to work on en-dash spacing====

] is where I've put a new proposal and discussion to keep from cluttering this page where lots of people are weary of en dashes. Please join if you care. I'm trying to make a version that's not so long and makes Jeff happy by allowing more options, and then we can see if that can raise a consensus better that what we had before. ] (]) 05:49, 29 July 2011
:If this were Dicklyon's goal, it would have been simple. But, oddly enough, the same text has reappeared, and and being reverted for, alothough it was sidely opposed at the original poll, is not supported by sources, and is opposed at the discussion. Funny thing that.] <small>]</small> 00:36, 2 August 2011 (UTC)

== Satisfying a <nowiki>{{who}}</nowiki> tag ==

Assuming consensus approved, good faith language, can the provision of ] citations in response to the placement of a <nowiki>{{who}}</nowiki> (or similar) tag be considered a WP adequate resolution to a ] objection? Thanks. ] (]) 13:08, 25 July 2011 (UTC)
:Not by itself in all cases. The language would need to support the source. So "some say ...." would need to be replaced with "in an editorial in The Times said....." if that was your only source. Something like "It was widely said at the time...." could stay, if it was sourced to a source that analysed the coverage and said "it was widely said at the time....". If the answer to "who" is one person/source only, then (1) the wording should be altered to show this and (2) ] may come into play. If the language itself can be reliably sourced, then it may not be necessary to alter the language. If it is an attempt to evidence "most people" by citing half a dozen people who said it, then that may be ] - and ] if there are another half dozen sources that contradict it. --] (]) 13:39, 25 July 2011 (UTC)
::Thanks for your consideration and I am in full agreement with your position though I'm not clear that you may have adequately noted my quite purposeful use of the plural "citations".
::To be specific and if I interpret your opinion correctly, in cases where multiple, diverse RS sources more than satisfy consideration under ] and consensus agreement exists for the language employed, source citations CAN, in your opinion, satisfy a <nowiki>{{who}}</nowiki> objection, correct? ] (]) 13:58, 25 July 2011 (UTC)
:::Sorry, did not catch that you were being specific in citations. In general, good sources can certainly satisfy a who objection. If the sources support the language, ] should not be an issue, as the main concern of weasel is unsourced non-specifics - vague wording intended to camouflage poor research, or the use of words that have a different meaning than the source supports.--] (]) 16:01, 25 July 2011 (UTC)
::::That is succinct and precisely the clarification I was seeking. Many thanks for that.
::::If I might note an ancillary question I've posed, you might find ] to be of some interest as well. Thanks for your consideration. ] (]) 16:45, 25 July 2011 (UTC)
:::::In addition, if one has a source, one might as well say "According to ''Brutal Copy Editing'', people who use apostrophes to create plurals are 'morons.'" Situations in which the structure of the sentence or paragraph would prevent the addition of such information would be rare. ] (]) 17:55, 25 July 2011 (UTC)
::::::''...if one has a source...''
::::::A single source is, I'd suggest, an entirely different consideration than an availability of multiple sources...as discussed above, but I certainly concur that a single source <nowiki>{{who}}</nowiki> objection is easily addressed by attribution. ] (]) 18:11, 25 July 2011 (UTC)
:::::::The solution to "too many cooks" is to make one of them head chef: "According to several high-end style guides, including ''Brutal Copy Editing'', people should not use apostrophes to make plurals." It would be like "et al." in a scientific journal. ] (]) 21:47, 25 July 2011 (UTC)

:Short answer: Yes. A weasel tag does not require ] attribution of a fact or opinion to any named source.
:Related to Darkfrog's example, if a substantial proportion of (relevant) sources support the statement, and none contradict it, then it is actually inappropriate and misleading to call out any particular one as holding the opinion. We assert widely agreed upon facts without specifically naming any particular person who holds that opinion. "According to many mathematicians, including Alice Expert, two plus two equals four" would be silly.
:Or, to give the more relevant example, if dozens of media sources say that the Casey Anthony trial is a media circus on par with the OJ Simpson trial—which they do—and none of them contradict it—which they don't—then we might well provide a string of sources, but we're not going to single out any one of them as especially holding this essentially universal view. ] (]) 23:03, 29 July 2011 (UTC)

== Asterisks in examples ==

Weren’t these added to assist readers who are red–green colorblind? I agree that the asterisks don’t look great, but some accommodation seems reasonable. If the asterisks are too unsightly, what about something like {{!xt|!Another "planet" was detected — but it was later found to be a moon of Saturn}}, in keeping with the symbol used to distinguish the templates? Although the implication of bang may not be obvious to everyone, it’s nonetheless common in computer science, so the meaning should be more obvious than using an asterisk. In any event, a brief mention of the convention should clarify. ] (]) 23:37, 25 July 2011 (UTC)
:Whatever we do, we don't need a special notation for the en dash section. I think Noetica made up the asterisk for people reviewing the new draft, but didn't expect it to last; so now is the time to work something out. The "!" might be OK; but can we fix the template to do it automatically? Or just adjust the colors to be distinguishable enough? ] (]) 02:59, 26 July 2011 (UTC)
::I strongly prefer we just use the words and instead of any color change and symbols, so no need to worry about visually impaired reader's accessibility. -- ] (]) 04:18, 26 July 2011 (UTC)
::I agree that we don’t need (or want) a special version for the dash section, and if it were decided that some indication other than color is indicated, building it into the template might be the only way to ensure consistency. Of course, this well could raise objection from some who don’t want any such clutter. But there may be even more merit to Sameboat’s suggestion, which doesn’t rely on color perception or a gimmick like a “!”. When both “correct” and “incorrect” examples are on the same line, putting ''not'' between them as A. di M. did works just fine and is shorter. Both approaches are consistent with how most other style guides deal with it. I see no problem with retaining using color for the examples to make it clear that they aren’t part of the text.
::Another approach would be to go even further and surround the example with curly braces, as ''CMOS'' and Garner do (e.g., <nowiki>{</nowiki>{{!xt|Another "planet" was detected — but it was later found to be a moon of Saturn}}<nowiki>}</nowiki>) so that it’s more obvious to the visually impaired. The typeface change certainly helps, but it’s nothing like the change of color ''and'' typeface. If such a change is made, it should be incorporated into the template to avoid the messy construction I had to use here.
::Probably not the top priority, but perhaps worth thinking about. ] (]) 07:39, 26 July 2011 (UTC)
:The bang might be standard in computer science, but the asterisk is standard in grammar <small>(though usually for genuinely unidiomatic or unattested usages, not merely ones which are the wrong register)</small> so I wouldn't expect either to be much clearer than the other. I once proposed , but it was opposed as too cluttered. Anyway, whatever scheme of colours/symbols is used should be ''redundant'' with the surrounding context, not ''relied upon''. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 12:44, 26 July 2011 (UTC)

::I argued strongly and at length on Noetica's Talk page in favor of using "Correct:" and "Incorrect:" (see Sameboat's note above), with appropriate font color and typeface contrasts, because the correct/incorrect convention is both common in other usage manuals and guides, ''as well as in other sections in WP:MOS''. Noetica agreed and assured me that he had "made up the asterisk for people reviewing the new draft, but didn't expect it to last," as Dicklyon noted above.
:::*That revision is the "minor" format change Noetica is referring to in parentheses in the list (far) above of those who supported posting the draft and moving on to the next stage in review and approval, as I did, ''contingent'' on making this revision ASAP after posting the draft. His priority was getting the draft posted for comment without further delay because it's quite behind schedule, and that seemed to me to be a reasonable course of action.
:::*I also argued for including a '''brief''', 1-sentence explanation of the asterisk convention and of its interim use to avoid exactly this kind of confusion. As JeffConrad says above, "In any event, a brief mention of the convention should clarify." But evidently Noetica either didn't consider that to be necessary or overlooked it in the process of posting the draft.
:::*As for using the "bang" instead of an asterisk, with all due respect to JeffConrad (whose numerous valuable contributions are noteworthy), it seems to me to be a non sequitur to assume that because the bang is "common" in comp sci, ergo it's "meaning should be more obvious than using an asterisk." (It wouldn't be to me, and I was a comp sci minor.) Aren't relatively few MoS users likely to be experienced in programming languages that use a bang extensively? Besides, ! is a very narrow symbol, so it's less prominent than many other common special characters, such as #. (* is also obviously quite small and is quite indistinct when it adjoins the 1st letter of what follows, without an intervening space. But I can imagine now the fierce debate that would ensue over how large a space is best to use!)
:::*Regarding the contrasting font colors and typefaces, they may perhaps improve readability when the correct and incorrect forms appear imbedded in-line in the text vs. being set off on 2 separate lines. (As discussed elsewhere, color differences alone wouldn't be visible to those with impaired color vision, and the color sets used by some browsers and computer models often render color contrasts less distinct, even under the best of circumstances.) I concur with A. di M. that "whatever scheme of colours/symbols is used should be ''redundant'' with the surrounding context, not ''relied upon''."
::::*But we should not downplay the importance of paying strict attention to readability: Parts of the MoS "Hyphens" section provide an especially egregious example of how ''indistinct'' the contrast of the current red-green serifed typeface can be. One portion of that section ''literally'' (and I do mean literally) fills my laptop's 15" screen ''from top to bottom and side to side'' with single-spaced text and very little white space! The red-green serifed typeface is barely noticeable unless I look carefully at each line and read more slowly than I normally would. It's a textbook example of poor page design! And it's likely to discourage editors from paying much attention to that section of the MoS if they can avoid it. The MoS can, and should, do better, and that change could begin with us. ("If not us, who? If not now, when?" etc.) — Jack --] (]) 22:21, 26 July 2011 (UTC)

:::::The problem with the color change is that it changes the font-color, since the color is so dark, it is often indistinct from the non-colored black text. However a pale colored background should solve this problem nicely. This is my proposed change to the current format:
{<span style="background:#fdd; font-family: Georgia, serif;">This are the wrong example.</span>}
<nowiki> {<span style="background:#fdd; font-family: Georgia, serif;">This are the wrong example.</span>}</nowiki>
-- ] (]) 01:31, 27 July 2011 (UTC)

:::::(after ec) Bang! Bang! Bang! OK, OK, I was just sayin’ {{nowrap|. . .}} I thought I had made it clear that using ''correct''/''incorrect'' (or ''right''/''wrong'', which is shorter and monosyllabic) is better, and A. di M.’s ''not'' is the briefest and probably the best for columnar examples. In any event, the color difference is at best a minor convenience—I’m fine with keeping it, but agree with many others that we should not rely on it.
:::::Just out of curiosity: what about my suggestion to use something like braces, as in <nowiki>{</nowiki>{{xt|pseudo–page transition}}<nowiki>}</nowiki>, to make the examples stand out better when color and typeface alone aren’t sufficient, for whatever reason? The braces aren’t especially pretty, but then neither is almost any convention I’ve seen for literal examples (especially in computer manuals, even the good ones).
:::::I tend to agree with Sameboat that the color change can be hard to see, but the pink background seems a bit garish, especially if I had to look at a page full of it. ] (]) 01:42, 27 July 2011 (UTC)

:: I like both Sameboat's and JeffConrad's suggestions. We could consider alternatives of which background color and symbols to use and discuss them.
::* Jeff, like you, I like the brevity of ''right''/''wrong'', but it no doubt violates some WP policy for being too blunt. And IMO {braces} aren't especially any more or less attractive than some of the alternatives. Maybe square brackets in a larger font than normal text (to avoid confusing them with intentional punctuation) might have more esthetic appeal, or we might be able to find a symbol in LaTex that would be more visually pleasing.
::* As I understand it, the purpose of whatever symbol is used (e.g., braces, asterisks, etc.) is primarily for the benefit of users with impaired color vision. Adding a background color, in combination with the symbol, has at least 2 advantages:
::::(1) It would make the incorrect example stand out when both the correct and incorrect forms are shown ''in one line of text''. No combination of symbols with (or without) colored, serifed fonts does that particularly well, especially where a lot of examples are shown in-line, as they are in the <s>"Dashes"</s> "Hyphens" section I referred to in my previous comment. They simply get drowned out by the sea of regular text.
::::(2) Yes, a page full of pink might be garish, but it would sure get the reader's attention (the whole point), and its reddish character virtually screams "Stop!" But seriously, there's much more flexibility in using background colors than font colors. Font colors must be dark, which creates the problem Sameboat and others have mentioned of becoming indistinct from normal black text. But a much wider variety of light or medium background colors could be used—perhaps a soothing pastel blue or yellow? Or amber? (Green might create confusion because it often connotes "Go!" or "OK".)
:: In any case, this merits further consideration. — Jack --] (]) 17:23, 27 July 2011 (UTC)
:::Some adjustments as per suggestions above: <span style="font-size:150%"></span> <span style="font-size:85%">(Right)</span>. <span style="font-size:150%"></span> <span style="font-size:85%">(Wrong)</span>
:::<code><nowiki><span style="font-size:150%"></span> <span style="font-size:85%">(Right)</span></nowiki></code>
:::The right/wrong are placed behind the examples so we don't need to concern about the capitalization when making it into a template. -- ] (]) 01:12, 28 July 2011 (UTC)
::::At least to me, the pastel backgrounds are pretty garish—far more so than the current scheme. I certainly would not want to read very much of this. I also think the curly braces work much better than the enlarged square brackets because they don’t increase the line spacing with inline examples. The curly braces are sufficiently uncommon in normal text that confusion is unlikely to result; moreover, there is some precedent for the use of braces, so the reader is more likely to be familiar with them. But the braces are jarring nonetheless, so if this idea were to gain any traction, I would limit use to inline examples—columnar ''right''/''wrong'' examples (and similar) are usually obvious enough that readers probably don’t need the extra cues. Anything that disrupts the normal flow is distracting, and I think it should be kept to a minimum—including typeface changes that aren’t central to distinguishing example text from ordinary text. I like to tell myself that I had no choice , but sometimes I wonder—suffice it to say this is painful to proofread. ] (]) 02:10, 28 July 2011 (UTC)

I surely hope none of you are serious about proposing these obtrusive forms. The current way of using the templates {{tl|xt}} and {{tl|!xt}} together with a variation of approving or rejecting additions is close to perfect. &minus;] (]) 14:56, 28 July 2011 (UTC)
:Then I prefer to not change the font style of the example text at all. You know what? The color and font changes make me glare at the screen for more than 1 second to distinguish the example from other text. It is absolutely flawed. The easiest and non-obtrusive way to indicate the right/wrong example is simply to italicize the example text (which is how dictionary does) and precede it by green tick ] or red cross ] with ] and title attribute. -- ] (]) 16:07, 28 July 2011 (UTC)

:Re Woodstone: And I, in turn, sure hope ''you'' aren't serious that the "current way of using the templates {{tl|xt}} and {{tl|!xt}} together with a variation of approving or rejecting additions ''is close to perfect''."
:*First, "close to perfect" assumes some objective criterion or set of criteria for determining what is perfect. E.g., under U.S. baseball's definition of a ], a game in which the pitcher(s) allowed only a single walked batter to reach base, and no one else, could reasonably be described as "close to perfect." So would achieving a 99% score out of a maximum possible 100% on an examination (i.e., no "bonus points"). Are there any comparable criteria for defining a perfect way of contrasting right and wrong examples so one is clearly discernable from the other, etc.?
:*Second, the noteworthy disadvantages of the {{tl|xt}} and {{tl|!xt}} templates have already been discussed at length above, in particular that the font colors must be dark, so they're often not easily distinguishable from the surrounding black text, especially in in-line examples that are imbedded in a long passage, so that many lines of text cover entire lines on the screen. (Again, see the MoS section on "Hyphens" for an egregious example of how difficult it is to ''readily'' identify the examples using the {{tl|xt}} and {{tl|!xt}} templates, without having to examine the text very closely. That particular passage literally gives me a headache, and my vision is 20/15.)
:*In the end, which manner of distinguishing correct examples from incorrect ones is judged "best" for MoS purposes is a matter of tastes, which are innately ''subjective''. And of course, there's no arguing about tastes, as the cliché goes. (Just because it's a cliché doesn't mean it isn't true.) Notable exception: My tastes are impeccable, naturally, so they trump everyone else's, and I ''don't'' much care for the current templates. ;-)
::*Also, I don't understand at all what you're referring to by "a variation of approving or rejecting additions," so I can't comment on it. --] (]) 18:03, 28 July 2011 (UTC)

:Sameboat: I like your initial suggestion above, at least as a starting point. But placing the "Right" and "Wrong" ''after'' the example seems illogical or counterintuitive (for want of a better term). Putting those labels ''before'' the corresponding example seems pedagogically more sound because it signals the reader from the beginning what characteristic he (she) needs to be alert for that distinguishes the correct example from the incorrect one. I readily admit, though, that I don't know enough about wiki code/wiki markup/HTML/whatever all that gobbledygook is called to understand what your rationale means about "capitalization when making it into a template." Coming from you, though, I tend to think it's worth considering, but I should hope that problem could be overcome, even if the coding were more tedious. (Easy for me to say, since I won't be the one doing the coding!) Overall, though, this is a noteworthy suggestion, and I hope it gets the consideration it merits. We can quibble ad infinitum about which combination of background colors, fonts and colors, special symbols, etc., but this example is a solid point of departure.
:*I'm not sure, though, how your Big Green Checkmark and Big Red X would be implemented with in-line examples. Could you show an example of how you see that working? --] (]) 18:03, 28 July 2011 (UTC)

:Jeff: I completely agree that we don't need to apply any special template to examples shown in columnar form; they are indeed obvious enough. In-line examples are our main concern, although for consistency, IMO the same distinguishing template (whatever it is) should also be applied to cases where the right and wrong examples are shown one under the other. Other than columnar form, that format is by far the most unambiguous and easiest to see, even at first glance, and I hope it will continue to be by far the dominant format used in this section. Ideally, in-line examples should be used only when they are very short. (Yet again, see the "Hyphens" section for examples of flagrant abuse of in-line examples. I hate to keep picking on that section, but it's a formatting abomination.)
:*But unlike you, Jeff, in this particular context, I like "anything that disrupts the normal flow." Rather than being distracting, IMO it's a distinct ''advantage'' to call attention to the contrasting examples as much as possible. For example, note the background color (and drastically different font) that seems to be the WP standard for setting off lines of code from the surrounding text, as in Sameboat's examples above; LaTex also does something similar by default when it renders its characters on the WP page. And the more I look at curly braces, the less I like them, despite my initial comments way above. (Cf. supra re tastes.) --] (]) 18:03, 28 July 2011 (UTC)

::I must add that while MOS is generally accepted throughout WP, it's meant for encyclopedic article. Guideline or policy under other ]s can look like a manual and be visually obtrusive, in a good way. The capitalization issue is that no wiki parser is able to check if the preceding context ended with a period, so we don't know if we should capitalize the right/wrong, we can just add another parameter for editor to change or just leave it all lowercases, though. The tick and cross images are the most straightforward possible, you just place it before the example, and the ] of the image embedding syntax will display the replacement text (right/wrong) when image is disabled in reader's browser. The caption/title attribute functions as the mouse-over popup tooltip to indicate the meaning of the symbol. -- ] (]) 01:07, 29 July 2011 (UTC)

:::I'm afraid I must confess that I don't know anything about wiki parsers or alt attributes, so I don't understand most of what your comment means. (I'm a content editor, not a wiki markup, HTML, or whatever programmer.) And what do the capitalization issue and other namespaces have to do with this discussion? What does "add another parameter for editor to change" mean? (Are you referring to a human editor or to some kind of parser or bot?)
:::As for using tick and cross images, I don't have any conceptual objection to them per se, but would it be possible to use a (much) smaller image size that is more consistent with the font size of the text? The relatively large size of the images above really would be garish (to use JeffConrad's adjective), even overwhelming and distracting, especially on a page with a large number of them. (And we do have quite a few pages where a large number would be needed; e.g., see the ''long'' list of examples in Noetica's proposed revision to the "Dashes" section.) Also, wouldn't the large size look odd when used with in-line examples, especially if more than 1 pair of right-wrong examples appeared on the same line? (Or should that be "right–wrong" or "right – wrong"?) --] (]) 18:00, 2 August 2011 (UTC)

== Original titles for works in foreign languages ==

Hello
The issue presented here started at a discussion for the naming of the '']'' article, questioning whether English orthodox was to be applied to a Spanish-language title with thus different orthodox rules. After much heated discussion we came to the conclusion that Misplaced Pages policies do not seem to have specific guidelines when it comes to the proper formatting for titles in foreign languages. Two Misplaced Pages policies were brought up to support the use of English orthodox in any title, regardless of language, but I chose to disregard them based on the following:
*] was used as a policy to support the move from "Caso cerrado" to "Caso Cerrado." However, this policy states that if a published work has an official English title in addition to a foreign language title, the English title is to be used. For example, the policy suggests that "]" is to be used instead of "]" because the former is an official English title. It does ''not'', however, suggest that English orthodox is to be applied to a foreign-language title with no English alternative.
*] was also presented, stating that common names are to be listed as they're more commonly formatted in English-language sources. However, foreign language ''titles'' do not qualify as "common names." The policy refers to common name terms such as "personal computer," "apple tree" and "beach towel," not titles of published works.

Misplaced Pages houses thousands of articles about foreign language titles in Spanish, French, Finnish, Italian, Galician, etc. About half of these articles apply English orthodox to foreign language titles, and the other half apply the orthodox associated with the language the titles are in. It is crucial that specific guidelines are made available, so users can determine which format to use. Generally speaking, English orthodox is not to be applied to foreign languages in the same manner that Spanish/Italian/French orthodox is not applied to English language terms. Regardless of this being the English Misplaced Pages, when titles or quotations in foreign languages are presented, they're still in a foreign language, and that language's orthodox should be respected, if nothing more, for common courtesy.

The ] is often disregarded as an unreliable source because of its high number of user-generated data. However, their very specific and strict guidelines are written by their knowledgeable staff, and they claim "Capitalization is language dependent." In other words, regardless of IMDb being an English-language site, titles are to be presented and formatted according to the orthodox accepted by their respectful languages. Many other sites adapt these same principles and are open to them when suggested (such as in title corrections, etc), even if not always written as part of their guidelines.

The bottom line is that there are currently no specific guidelines regarding proper formatting for foreign titles, this leads to confusion and in cases, pretty heated discussions with no evidence to back up either side.

Personally, I think the same rules should be applied here than in other Wikipedias: A foreign language's orthodox should be respected whenever and wherever that language is used. No foreign language becomes English simply because it is presented as part of a source with English as its dominant language.

Many thanks. ] (]) 20:43, 27 July 2011 (UTC)
:This isn't really an AN issue; ] and/or ] would seem to be better locations for this. I have an opinion on it, but raising it in a better forum is more likely to generate a meaningful response. ] (]) 23:05, 27 July 2011 (UTC)

:::My own take on the matter would be to use ''Pan's Labyrinth'' but make sure that ''El laaberinto del fauno'' be used in the lead. I would not, however, invent an English-language name for Misplaced Pages. ] (]) 01:16, 28 July 2011 (UTC)
:Thanks for your imput. Remember, however that the issue here is whether or not English orthodox is to be imposed on foreign language titles. For example, Spanish, Italian and French languages capitalize the first word and any proper nouns within a title ("El laberinto del fauno"), whereas English-language orthodox is to capitalize the first word and any keywords, excluding function words ("El Laberinto del Fauno"), making said titles incorrect in their respective languages. My argument is that English language orthodox does not and should not apply to foreign language titles, so "El laberinto del fauno" is correct. Regardless of being presented in the English Misplaced Pages, "El laberinto del fauno" is still Spanish and should abide by its rules, not English ones. ] (]) 02:09, 28 July 2011 (UTC)
::Just as a note, I think the word you're looking for is ], which is about writing, not ], which is usually religious in connotation (unless someone's talking about right-handed boxers).
::As for the question, if a foreign-language title of the work is being used as an article title because no commonly used English version exists (and making up one, even a direct translation, is ]), then the orthography of the original language should be used, as it accurately represents the original title, presuming its compatible with the Latin alphabet. (Transliteration of languages written in other alphabets is tougher, but that's a case of following the sources; we shouldn't make up transliterations, either.) ] (]) 05:53, 28 July 2011 (UTC)
:::I have to disagree. Translation is '''not''' the same as original research; in fact it can result in copyright being breached if the rules aren't followed.

:::We also need to avoid creating "one rule that fits all". Names of "works" are one thing but other titles should be appropriately translated and, yes, English capitalisation or lack of hyphenation used. "Theodor Heuss Bridge" is a perfectly acceptable name for the German "Theodor-Heuss-Brücke" even if it were an obscure name never before mentioned in English. This is standard translation practice and we will produce reams of unintelligible titles if we do otherwise. Also there is a need for consistency. If famous mountain passes are converted from "Foopass" to "Foo Pass" it would be inconsistent and illogical not to do the same for a pass never before mentioned in English books. That creates a 2-tier system. To sum up, a blanket rule here is dangerous, which is why WikiProjects for countries have developed naming conventions to guide editors. --] (]) 06:14, 28 July 2011 (UTC)

:::{{ec}}
:::FWIW, "orthodox" can be, and often is, used in a non-religious context as "adhering to what is commonly accepted, customary, or traditional". And IIUC "orthography" of English, or any language, can be seen as codifying the orthodox rules of writing.
:::That aside. I would agree that, for works that do not have English titles, the original titles be used and their use be consistent with the rules of grammar of the original language, up to an including diacritics. The only caveat would be to find the "romanized" version for languages not using a Latin character base.
:::@Bermicourt: If the Misplaced Pages editor is translating it's going to look like OR. If they are citing an English language source that uses the translation, it's sourced. Also, based on the original post, we ''are'' dealing with titles in relations to "works" - the first is a Spanish language TV show and the second is a film originaly released in Spanish. I'm not sure a premptive "This should not cover locations" is needed at this point.
:::- ] (]) 06:30, 28 July 2011 (UTC)
:I should mention that this would apply to latin alphabet-based languages (Portuguese, Romanian, Spanish, Italian, German, Galician, etc.), non-latin alphabet languages such as Chinese, Japanese and Arabic would naturally, if using their native titles, be romanized as opposed to using their characters (for article titles, the original non-latin title would appear in the introduction). Remember this is only for titles of published works, meaning television shows, programs, books, songs, albums, movies, etc. ] (]) 16:59, 28 July 2011 (UTC)
::This is at least the ''third'' forum in which this has come up; I met it at ].

:: My view is that we should do what other English-speakers do. This article has three sources in English (one of them a Hispanic News reporter, who presumably knows and cares about Spanish conventions). All of them use the English convention for marking a proper noun: {{xt|Casa Cerrado}}. We should not make up conventions; they will not be understood, which is our goal here. ] <small>]</small> 17:52, 28 July 2011 (UTC)
:::My view is the same as PMAnderson's. Just follow what the majority of English-language sources do when they are discussing the subject. ] (]) 18:05, 28 July 2011 (UTC)

:Nothing is being made up. Foreign languages have specific regulations for capitalization of titles in their respective languages. Spanish rules go as follows:
:''"Capitalization in Spanish is sparse compared to English. In general, only personal and place names, some abbreviations (e.g. Sr. López, but señor López), the first word (only) in the title of a book, movie, song, etc., and the first word in a sentence are capitalized, as are names of companies, government bodies, etc. Names of nationalities or languages are not capitalized, nor (in standard style) are days of the week and months of the year."'' from ]
:It is more than safe to assume that English-language authors of Internet articles are less-than-familiar with foreign language orthodox, and not reliable sources when it comes to proper formatting. There is no dispute here regarding which form is proper: "Caso cerrado" abides to proper Spanish orthography, "Caso Cerrado" is incorrect. "Caso cerrado" is not English, it's Spanish, and should follow the latter's grammar rules. The same goes for every other latin-alphabet based languages.
:The Internet Movie Database may not be a reliable source when it comes to their user-generated sections (trivia, goofs, etc.), but they DO have strict policies regarding capitalization in all languages according to said languages' proper orthodox, which none of the sources listed do. Based on those policies, they list the title correctly as "Caso cerrado." ] (]) 19:24, 28 July 2011 (UTC)

:'''Major problems with relying on English-language sources when choosing which orthodox to follow''':
*The vast majority of sources '''will not''' have neither specific nor strict guidelines relating to proper orthodox use. Instead, they'll be formatted according to the specific author's personal preference instead of any set guidelines. This makes those sources unreliable when it comes to choosing which is correct.
*Hundreds of foreign-language titles will have ''zero'' English sources (aside from the standard IMDb which ''does'' have orthodox guidelines, not chosen by specific authors or users), leaving countless article titles vulnerable to further indecission and conflict. Also, in many cases, English sources are bound to contradict one another, once again, leaving room for indecission. For these reasons I think it is crucial that a decission be made between applying English orthodox, making titles incorrectly formatted in their respective languages, or abiding to their proper orthodox, as accepted by their respective language. ] (]) 21:01, 28 July 2011 (UTC)

:After some research I discovered that there are in fact somewhat flaky guidelines for adapting foreign capitalization into foreign language expressions: ]. "Loan words" such as the French-adapted English title for "Les Miserables," naturally follow English conventions, but foreign words in the original foreign titles should follow the conventions associated with that language. For example, an English version of "Caso cerrado" does not exist in any form (subtitles do not qualify as 'English' version, assuming they even exist), therefore the title has neither been adapted as "Caso Cerrado" into English, nor translated from Spanish as "Case Closed." It remains a Spanish-language title for a Spanish-language television program, of which no English version exists. ] (]) 20:43, 29 July 2011 (UTC)
::That looks like a sensible guideline. Is anyone against it? ] (]) 23:49, 29 July 2011 (UTC)
:And did we agree that we're talking about ], not ]? ] (]) 23:51, 29 July 2011 (UTC)

:"Les Miserables" is a title adapted into English, it has become part of the English language and is thus an English title, it also does not apply. ] (]) 19:42, 29 July 2011 (UTC)
::And how do we tell the difference? Ask the infallible intuition of Taran Wanderer? ] has existed a century or so longer than any television series, and is ''more frequently'' mentioned in English; but "Casa Cerrado" is equally adopted. ] <small>]</small> 20:13, 29 July 2011 (UTC)
:::"Les Miserables" has been published in English with its original French title, thus the French title has been adapted ''into'' English. ''Caso cerrado'' has not been adapted into English in any shape or form, it remains the title to a Spanish-language television show. There's no English version with ''any'' title, neither adapted nor translated. THAT's how the difference is made crystal clear, and yes, you can trust Taran Wanderer, though I won't make myself a Misplaced Pages policy. ] (]) 20:22, 29 July 2011 (UTC)
::::''Les Misérables'' is the capitalization used in French as well as in English. ] (]) 02:32, 4 August 2011 (UTC)
:::In which case ] likely meant "Misérables" to perform as a proper noun, as opposed to the common "misérables," as was adapted into Spanish (miserables) and Italian (miserabili). Very often, titles on the covers of these works will adapt the 'capitalize all keywords' rule, but only for ] reasons, their official titles will still follow the language's ruling, regardless. This is common in movie posters and DVD covers, etc. ] (]) 04:01, 4 August 2011 (UTC)

=== Poll ===
Let's continue the discussion above, but let's organize each contributor's decision below as a poll to get a clear picture of where we stand. Those in
==== ...favor of applying English conventions to titles of published works in foreign languages ====
(e.g. ]: "Märchen von Einem, der Auszog das Fürchten zu Lernen" as opposed to "Märchen von einem, der auszog das Fürchten zu lernen" or ]: "Un Medicco in Famiglia" as opposed to "Un medico in famiglia")
#

==== ...favor of abiding to foreign language conventions in titles of published works in foreign languages ====
(e.g. German, first word and all nouns capitalized only: "Märchen von einem, der auszog das Fürchten zu lernen" or Italian, first word and proper nouns capitalized only: "Un medico in famiglia")
# ] (]) 06:49, 29 July 2011 (UTC), with the remark that this would follow the best sources for those titles as well
# ] ] (]) 07:29, 29 July 2011 (UTC)
# This is, in fact, what reliable sources do. If we're going to have a manual of style, it is kind of pointless to just have it say "follow reliable sources." The point of it should be to do some research into how reliable sources deal with certain frequently arising issues and then recommend that we do that. This is a clear instance of that - I have never seen a bibliographical entry in a scholarly work which does not follow the title capitalization conventions of the language the cited work was originally written in. ] (]) 17:52, 29 July 2011 (UTC)
#:An argument worth answering: we are not a bibliography, and ''Cosí Fan Tutti'' is normally so capped in running prose. But this is the second comment which does not actually disagree with the third position below; an argument that we need not consult reliable sources only works for edits that aren't based on reliable sources. ] <small>]</small> 17:58, 29 July 2011 (UTC)
#::I don't necessarily disagree with the position below, but I do think it makes sense to be somewhat more systematic than to just look up reliable sources for each individual case. As to ''Cosí fan tutte'', a suggests that it is frequently ''not'' capped in running prose in the manner you prefer, although it sometimes is. ] (]) 00:11, 30 July 2011 (UTC)
#:::I agree; by adapting this policy, specific cases would no longer be a problem. All languages (though the conventions page seems to be unaware of this) have specific guidelines for capitalization that we can turn to for any title. In the case of 'loan' titles ("Les Miserables," "Cosi Fan Tutti" and "La Isla Bonita"), there's no question we should use English-language guidelines. Adapting this policy would make the lack of sources not be a problem. What's clear is that we're all against the first option, that of forcing English conventions on foreign titles, right? ] (]) 01:16, 30 July 2011 (UTC)
#::::''Les Misérables'' has that capitalization in French as well as in English. As to ''Cosi fan tutte'', I'm not sure how there's "no question" when, as I pointed out, many news stories use the Italian capitalization. ] (]) 02:30, 4 August 2011 (UTC)
#] (]) 19:22, 29 July 2011 (UTC)
# Yes, when there's no obvious English version to choose. ] (]) 23:57, 29 July 2011 (UTC)
# Though there may wind up being a case by case discussion as to where a work such as a play, film, book, or similar has had an English language edition published with an anglicized title. It is also important to remember that this is ''not'' restricted to article titles, but also covers how the titles of works are presented within the whol of articles. Citing ] and ] is all well and good when trying to figure out an articles title. But those hold very little weight with the style used with in the article. - ] (]) 00:14, 30 July 2011 (UTC)
#In a ''very few'' exceptional cases there will be an ''established'' name used in English-speaking countries to refer to a foreign-language version of a work (a name is established by the consensus of the language community, not a few dozen Google hits). Such well-known titles will often merit an entry in other reputable encyclopaedias and we can follow their example:
::*the Luther Bible (no italics)
::*''Historiae animalium''
::In ''most'' cases there will probably be ''no'' established English name (differing from the foreign name), and foreign conventions, including capitalization, should normally be followed.
::Normally, the reader should be able to assume that an English name using English spelling and capitalization refers to the English version; any foreign language version should use the foreign name; and the spelling and capitalization rules appropriate to the language should be used:
::*''Albert Einstein: schepper en rebel'' is the Dutch version of ''Albert Einstein: Creator and Rebel''
::*''Der arme Heinrich''
::*''Under der linden'' by Walther von der Vogelweide
::*''Der Hauptmann von Köpenick''
::*''Die Täter sind unter uns''
::Unless editors are agreed that there is good reason to do otherwise, with a few exceptions such as all caps we should use the name exactly as it is printed on the front page (or in the national library catalogue). How ''The News of the World'' spells the works of Walther von der Vogelweide is of little interest. We should not attempt to apply English conventions to foreign words.--] (]) 21:58, 2 August 2011 (UTC)

====....favor neither position above, but do what our English-language sources do.====
#] <small>]</small> 20:31, 28 July 2011 (UTC)
#per ]. ] (]) 15:46, 29 July 2011 (UTC)
# I don't see any reason not to follow ], which says, "If the article is about a work in a foreign language (such as a book or other written work, movie, album, or song), using the capitalization found in most English language reliable sources is recommended." ] (]) 23:13, 29 July 2011 (UTC)
#:Because only a portion of foreign-language titles have reliable English sources to begin with. Few, if any, follow any set guidelines for capitalization, and are up instead to the preference of the author, who in many cases will assume that English-language capitalization is universal. Thus not 'reliable' sources in this manner. It is much easier to just follow the languages' own standards, since reliable sources ''should'' be doing that to begin with. ] (]) 23:29, 29 July 2011 (UTC)
#::In such cases, there is always the question whether we should have an article on the subject to begin with; there are notability requirements for books and prograpms. Some will be notable, despite never being discussed in English; for that minority, we can sometimes proceed by analogy; if not, then thee is no extablished English style, and the style of the original language is the reasonable thing to follow. But we are discussing a minority of a minority. ] <small>]</small> 23:38, 29 July 2011 (UTC)
#When English sources agree, we can use them; the problems are mostly only when there are no English sources for a title, or where there is no obviously accepted English version. So follow ] when possible. ] (]) 23:59, 29 July 2011 (UTC)
# Misplaced Pages needs to follow the practices of other quality English-language publications and not pretend we can change the very alphabet used to write the English language.<p>A trema ( ¨ ) is something I can type from my Mac keyboard (and just now did) precisely because Apple recognized that certain diacriticals are commonly used in English and endeavored to make it easier for Mac users to deal with common English-language practices. Misplaced Pages has zero business pretending it is *being enlightened* with stuff like “]” (the Vietnamese street execution dude) since none of those diacriticals can reasonably be considered as part of the English language. It doesn’t matter what our motives are, or how our only business is to look to best practices of quality English-language publications <u>and follow what they do</u>.<p><br>→ Shooting from the hip a bit here, I’d say we couldn’t go too wrong if we adopted a “two out of three” proposition after looking at how ''National Geographic'', ''The New York Times'', and ''Encyclopedia Britannica'' handle these things</u>.←<p>Oh… and for those who might cite how technology like Unicode allows wikipedians to show the rest of the world how to do things smart-like, uhm… no; type foundries have long offered every diacritical known to man and the aforementioned publications could use them whenever they want. It’s not about *technology*.<p>To PMA: Your name all by itself at the top of this doesn’t constitute a persuasive argument capable of swaying opinion; it’s a name on a list. Let’s see you use that brain of yours to advance some cool-beans reasoning that makes other editors arch their eyebrows, pout out their lower lip, and “Huh… he’s got a point.” That sort of thing factors into gauging the quality of each side’s position when discerning a consensus. ] (]) 04:50, 30 July 2011 (UTC)<p><br>'''P.S.''' BTW, I hope it was just an oversight in the lede of this proposal, when only German and Italian examples were mentioned and then the scope of ''the actual proposal itself'' was broadened to “foreign languages”. I note also the exceedingly magnanimous and wholesome wording of “abiding to foreign language conventions”. It still boils down to the fact that England, where our language came from, had its share of cultural influence from Germany, Italy, and France and this influence crept into common usage of the language used in England. (Then those darned Yanks went across the pond and changed some spellings, adopted other words for some common nouns, and likely evolved the adoption of certain diacriticals.)<p>As has been shown a hundred times before, it is folly to think we can exploit Misplaced Pages in hopes of changing how the world works because we think there is a better way; particularly when we hope to change the ''very alphabet we use to write the English language''. Were it me, I would counter with my own RfC and in the proposal, write '''Shall Misplaced Pages abide by common English-language conventions used by high-quality respected publications.'''<p>Judging from the practices and (two out of my above-mentioned three highly respected publications), Misplaced Pages would follow their lead and spell it {{xt|François Mitterrand}}. And in the case of Nguyen Ngoc Loan, we’d probably find ourselves again following as I wouldn’t be surprised if at least one of the remaining two sources I suggest we look towards (''The New York Times'' and ''Encyclopedia Britannica'') would handle his name the same way. ] (]) 14:40, 30 July 2011 (UTC)
#:If this approach is followed, then care must be taken to ensure that the "respectable sources" come from both sides of the Atlantic. ] (]) 20:26, 30 July 2011 (UTC)
#::That works for me. Any country that has English as its primary language works for me. That would include England and that “barbie” country where even the moon is upside down. Note that ''Encyclopædia Britannica'' has strong roots in Scotland and is owned by a Swiss guy. We wouldn’t be exactly turning our backs on the old world by including it in the three I proposed—besides, it’s the most respected encyclopedia out there. And ''National Geographic'' is published in 33 languages worldwide. We can rely on them to know about languages in general, and seek guidance from them on English-language issues directed to a readership that considers itself to be worldly. ] (]) 22:04, 30 July 2011 (UTC)
#Per WhatamIdoing. The original capitalization should be fallen back upon when there's no established Anglicization. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 23:16, 30 July 2011 (UTC)
#:There's only "stablished Anglicization" when the work in question is adapted into English and its original title is adopted. If "Caso cerrado" had been dubbed into English and its name had been borrowed, "Caso Cerrado" would become proper English. However, the fact that Variety.com (in some articles and not in others), and others use "Caso Cerrado" is ''not'' "Anglicization stablishment," just an assumption that English/Portuguese capitalization is universal. For an earlier argument about only German and Italian being used as examples, I did not think it necessary to list an example for ''every'' roman-alphabet-based language. Of course Spanish, Portuguese, Finnish, Romanian, Galician, Catalan, Sicilian, Bask, Estonian, Dutch, etc. are included in this proposal. ] (]) 00:14, 31 July 2011 (UTC)
#::I was talking about the rule in general, not about any particular case. I don't even know what the hell "Caso cerrado" is. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 00:29, 31 July 2011 (UTC)
#:::It's one of the examples we've been using. There's no English version of it, therefore it has not been 'adoted,' regardless of any English sources choosing to do so. I'm also speaking in general, continuing to use this case as example. There's confusion between titles that have been rightfully adapted into English (such as "]," or has it?) and others that have simply been formatted wrong in articles. ] (]) 00:43, 31 July 2011 (UTC)
#::::Where ] doesn’t fully give us guidance, ] will generally fill in the gaps. ] (]) 16:57, 31 July 2011 (UTC)
#:::::Prioritizing common sense would be a good practice. Common sense tells me that when an article title (or title within the article) refers to a title in its original language, said language's conventions should be used (such as with "Caso cerrado" or "El laberinto del fauno"), when it refers to a title of a work adapted into English (whether translated: "Pan's Labyrinth" or borrowed: "La Isla Bonita"), then English conventions should be used. Simple as that. ] (]) 17:46, 31 July 2011 (UTC)
#::::::I think MOS only needs to cover the broad principal and the vast majority of common stuff. There are bound to be plenty of details such as “when an article title (or title within the article) refers to a title in its original language.” For the most part, looking towards precedence established by respected English-language publications should give wikipedians guidance as to best practices. In other cases, where guidance is elusive, editors can establish a local consensus without trying to resolve everything at WP:MOS.<p>I have no problem with the examples you provided ({{xt|"Caso cerrado" or "El laberinto del fauno"}}). If “said language conventions” of the foreign language means adoption of diacriticals not used by high quality English-langauge publications like ''The New York Times'', ''National Geographic'', and ''Encyclopædia Britannica'', then no, I don’t agree with you whatsoever. It wouldn’t matter if there was a Broadway stage play on the Vietnam War titled “Nguyen Ngoc Loan and His 38-caliber Pistol,” and the play is named after a Vietnamese book titled “Nguyễn Ngọc Loan: Our ‘Dirty Harry’&thinsp;”, we can’t have mere wikipedians trying to change the English language and use the Vietnamese-language diacriticals.<p>Even if these efforts are given wholesome slogans like “Peacefully abide by ''all'' the alphabet conventions of world without *hate language* and with love for everyone”, we can’t be running off doing our *own thing* and try to expand the English alphabet beyond what is used by other respected English-language publications. That’s beyond the scope of what mere volunteer wikipedians with ''way'' too much time on their hands can rightfully do. ] (]) 22:05, 31 July 2011 (UTC)
#:Well, I would ''hope'' such major and respected publications would have their foreign titles properly adapted, but in any case, I doubt any of them will have any sort of publication on most of these works, since very few of them have had a significant impact on English-speaking regions. I'm sure those publications you mention have specifically-set guidelines (like IMDb.com does) when treating foreign titles, which cannot be said for a vast majority of 'reliable' English sources, such as Variety.com, where the capitalization is based on the author's own limited knowledge/personal preferences, as opposed to any guidelines, thus making their articles an unreliable or flaky source when choosing which format is appropriate, specially if fair knowledge on the language and common sense can be applied to prove them wrong. ] (]) 22:32, 31 July 2011 (UTC)
# ] 00:19, 1 August 2011 (UTC)

== Spaces in "XXX – United States relations" ==

See ]. There are tons of articles like this with spaced en dashes, which was previously what MOS:DASH recommended; now it recommends unspaced. Are we really wanting to make this much of a change? Will we be moving all those now? Any strong opinions one way or the other? Should I go ahead and RM them, or should I extend the requested optionality of such things into a new en dash change proposal that I'm working on? ] (]) 03:04, 29 July 2011 (UTC)

::I would suggest just ignoring the issue. Apply the new guideline to new articles and let sleeping dogs be. ] (]) 15:50, 29 July 2011 (UTC)
:::This ] would seem to apply. ] <small>]</small> 17:05, 29 July 2011 (UTC)
::::Yes, this can be taken to be a particular case of that general question that got no answer. I agree with you that sometimes "article titles should be changed for small benefeits," as you said there. Ignoring the issue will lead to years of churn, I expect, so I'm seeking to see if we can agree on a direction to reconcile guidelines and practice, for a cleaner resolution. ] (]) 20:29, 29 July 2011 (UTC)
*Just noting that the spacing of en dashes in bilateral relations articles and categories has recently become a source of confusion for quite a few at CfD and RM. It would be great if this could be clarified in MOS:DASH somehow. ] (]) 15:11, 30 July 2011 (UTC)

*'''Comment'''. I don't really care which way is decided on this issue, but whoever is doing the consensus-building needs to decide which it is and then implement it for old articles as well as new. Otherwise confusion results because editors see the "old" articles which use the old system and assume it is still in force and so they create new articles using the old format. Editors are far more likely to pattern article names after existing article names rather than consulting ]. Average editors probably also have no sense of how "old" an article is without specifically checking, which they presumably have little reason to do. So please decide on what the convention is and then implement it. If you're not prepared to implement it on old articles, don't change the convention. (These issues are not merely theoretical but as noted have arisen at category rename discussions, since category names generally follow the name of the article of the same name.) ] <sup>]</sup> 23:02, 1 August 2011 (UTC)
:Exactly why this kind of change should be minimised. See the discussion on changing the spacing rules for month-day dates but not for month-day-year dates: fiddly and with huge reverse-engineering problems. ] ] 01:47, 3 August 2011 (UTC)
::But we did change it (unless you interpret this as being like a date?); so should we change it back? Or clarify what we meant? ] (]) 01:50, 3 August 2011 (UTC)
:::To tell you the truth, as someone who wasn't involved in the discussion to revise, when I read what currently exists, I'm not really clear on whether the rule was changed or not. It used to be that there should be a space in "XXXX – United States relations". So what is the situation now? Space or no space? Or was that left ambiguous due to disagreements on this point? If there is a position, it would help to include some examples using country names. ] <sup>]</sup> 02:11, 3 August 2011 (UTC)
::::I thought we had moved away from most spaced en dashes as a compromise. But if so, the compromise remains too unclear. ] (]) 02:50, 3 August 2011 (UTC)
:::::The reason I am confused is this sentence: ''"The en dash in a range is always unspaced, except for times and dates (or similar cases) when the components already include at least one space."'' Why isn't "XXXX – United States relations" a similar case when the components ("United States") already includes at least one space? I agree that it could be clearer. I don't mind working to "correct" some of the old spacing issues in the bilateral relations articles and categories so that they conform to the new standard, but it would probably be best if there was something clear that I could point to that justifies the change. Right now it's ambiguous, if not misleading. ] <sup>]</sup> 03:02, 3 August 2011 (UTC)
::::::In reviewing Noetica's draft and comments on it, he clearly intended the spacing only in ranges, not in other symmetric relations. See where he says "note that the sense of the dash differs. In one it shows a range, in the other it shows a relationship between two elements. Given that difference in meaning, it is well that the dash should at least behave differently with respect to spacing. That is at least as arguable. In the end, I believe the position I have incorporated reflects the clear majority in the voting." This matches my understanding at the time. However, now I think we ought to consider also specifying spaces in other uses, such as in ]. By the same logic, I suppose I interpret "or similar cases" as meaning ranges that include spaces, in general, including 28 mm – 17 m, though that was not what I was thinking at the time. If you go back to Kotniski's draft ], you find much more explicit description of spacing ''in ranges'': "The dash is usually unspaced, but if the elements being linked themselves contain spaces (as with full dates), then the dash is spaced." There was some support for this draft, and I don't find any specific opposition to the spacing. In the comments at ], for example, PMAnderson , but not to the spacing provisions at all. Kotniski's also had unspaced en dashes in other pairs, including "the New Zealand–South Africa grand final". So Noetica's and Kotniski's are essentially the same, and got no objection to the spacing provisions besides from Jeff (until after the fact, when PMA joined him to disrupt things). That doesn't mean we shouldn't try to fine tune it, but in my experience, that may be difficult. ] (]) 04:29, 3 August 2011 (UTC)

:::::::Thank-you, that's a great summary of the background. I understand now. I definitely would agree that in non-range usages, it is unusual to space the dash, so I would have no objection to clarifying this issue about non-range spacing. ] <sup>]</sup> 04:51, 3 August 2011 (UTC)
::::::::Well, it's not at all unusual in WP article titles! ] (]) 05:05, 3 August 2011 (UTC)
:::::::::Very true. The previous guideline was implemented quite well, which is a good sign, actually. It means established guidelines actually do get followed. ] <sup>]</sup> 09:57, 3 August 2011 (UTC)

I think it should be explicitly stated in the guideline that these en dashes are unspaced even if the parts contain spaces (particularly since this represents a change from previous practice), and I think all the bilateral relations articles should be brought into line en masse - it's no big deal, and it's only confusing to recommend one thing and do another.--] (]) 09:09, 3 August 2011 (UTC)
:But , just a few minutes ago. ] ] 09:16, 3 August 2011 (UTC)

All right, ] to get this started.--] (]) 12:52, 4 August 2011 (UTC)

== Interesting article on the Associated Press (AP) Stylebook ==

You might be interested in (and possibly amused by) this article from the "Style" section of the Friday, July 29, 2011, edition of ''The Washington Post''** about the AP Stylebook and its chief editor.
http://www.washingtonpost.com/lifestyle/style/david-minthorn-is-the-grammar-expert-for-the-associated-press/2011/07/25/gIQAGBLwfI_story.html
'''{{!xt|Caveat:}} ''' washingtonpost.com is notoriously s-l-o-w to download, so click on the link and find something else to do for a few minutes (potty break, coffee refill, etc.)

If you take the stylebook knowledge quiz, note that it's testing only knowledge of the AP's guidelines, so some of its "correct" answers may be "incorrect" according to other guides. (I.e., even the most experienced WP editor shouldn't necessarily expect to score 100% on it.)
The print edition's headline for the article was a clever graphic, with the following text (in huge font), complete with copyediting marks correcting the typos and deviations from AP style (ahh, the occasional advantages of print over HTML):
::<blockquote><big>''Make no mistake; The folks behind the "AP style book" are''</big> </blockquote>
::<blockquote><big>''choosey about words such as 'e-mail,' 'octopi' and 'smart phone''' '''{{!xt|*}}'''</big> </blockquote>
Corrections shown by the copy editing marks:
*colon instead of semicolon after "mistake"
*"Stylebook" is 1 word, capitalized, no quote marks around the title and not italicized (that's the AP rule for "standard reference works" and the Bible; they use quotes around other titles and never use any italics)
*"choosy"
*The '''{{!xt|*}}''' refers to the following footnote about AP's guide: "They prefer 'email,' 'octopuses' and 'smartphone.'"
<nowiki>**</nowiki> Note: ''The Washington Post''<nowiki> '</nowiki>s stylebook requires that "the" be capitalized and included as part of its name, which seems to be a common (but not necessarily universal) practice among newspapers whose names begin with "the." All punctuation in the headline follows standard U.S. rules (e.g., commas inside quote marks). Apparently, both ''The Post'''s and AP's stylebooks omit the serial (terminal) comma in series of 3 or more items. Enjoy. --] (]) 21:34, 29 July 2011 (UTC)

== Using endashes in compounds whose elements themselves contain hyphens ==

The section on endashes used to contain a case for using endashes in compounds whose elements themselves contain hyphens or spaces (e.g. {{xt|the anti-conscription&ndash;pro-conscription debate}}) and when prefixing an element containing a space ({{xt|pre–World War II technologies}}, {{xt|ex–prime minister}}). I'm a little late to the game and I see that there has recently been a long and protracted debate on rewriting this section of the style guidelines. I've tried to follow the discussion as best as I can, but it's quite long. I discovered a draft page where various elements of the draft were voted upon, and I see that this particular case received wide support (see ]). It received 27 votes in support, 2 opposing votes, and 1 neutral vote. Yet, despite this support it somehow didn't make it into the final draft, and I can't find the discussion where it was axed. Can anyone shed some light on why this case doesn't currently exist in the guideline? ]&nbsp;<sup><small>]</small></sup> 22:02, 29 July 2011 (UTC)
:It got reorganized some, but those examples are still there, more or less (search for "ex–prime minister" or "a pro-establishment–anti-intellectual alliance"). The last bit is a simple application of a general use, the hyphens being irrelevant. Nobody came up with an example where having hyphens in one part or the other was a good reason to use an en dash. ] (]) 22:23, 29 July 2011 (UTC)
:Ah, I see you're into this proposal: ]. Example would be "Chungmugong Yi Sun-shin–class destroyer" versus "Chungmugong Yi Sun-shin-class destroyer". Good question. We ended up taking out the guideline to use the en dash on account of the spaces in Chungmugong Yi Sun-shin, and the one with the hyphen pretty much went with it, for lack of a compelling example of where it would be useful. Should we reconsider? This remains an area of less than perfect concensus, but it would be some work to reopen it and try to do better, as I'm trying to do with the spacing issues. ] (]) 22:36, 29 July 2011 (UTC)
::There are a couple dozen ship class names that have hyphens in the name itself. See a list I compiled at ]. I don't have any data on how many non-ship-class articles might be in the same boat (no pun intended). Take a look and let me know if you think it merits some more work. ]&nbsp;<sup><small>]</small></sup> 23:11, 29 July 2011 (UTC)
:::A hyphen in such constructions works fine: Duguay-Trouin-class cruiser (much better than a space, which suggests you're talking about some kind of a class cruiser). ] (]) 00:04, 30 July 2011 (UTC)
*The only function of a dash is this context is to prevent the confusion possible if the same pubcation is used at two different levels of grouping; {{xt|Lloyd-George–Winston-Churchill Government}} to avoid suggesting four men, Lloyd, George, Winston, and Churchill, instead of the Giovernment led by ] and ]. This implies the diminishing, but still attested Britsh custom of hyphenating compound adjectives; but {{xt|Government led by ] and ]}} is preferable anyway. ] <small>]</small> 23:26, 29 July 2011 (UTC)
*Since ''Chungmugong Yi Sun-shin''-class destroyer is unambiguous, it needs no dash; the structure is shown by the italics. If there is any danger of ambiguity, it rasts in the dash, which might suggest a compound between the ''Chungmugong Yi Sun-shin'' and "class destroyer." ] <small>]</small> 23:26, 29 July 2011 (UTC)
*The rather more common ] doesn't really need any more punctuation; it's clear as it stands. Does anybody add dashes or hyphens to it? ] <small>]</small> 23:43, 29 July 2011 (UTC)

Some writers use en dashes when compounding hyphenated words, but they're relatively uncommon; I've come across quite a few style guides that recommend against the practice, with the argument that it rarely dabs anything, and tends to disrupt the attention of the reader, a general no-no for punctuation. But en dashes are common with spaced compounds. (For Anderson's comments, read 'English' where he says 'British', 'increasing' where he says 'diminishing', 'one' where he says 'the only', and 'attributives' where he says 'adjectives'.) However, since the italics make the class name obvious in {{xt|''Chungmugong Yi Sun-shin''-class destroyer}}, a simple hyphen is sufficient, assuming that we ignore those who are protesting against italics.

As for {{xt|''U-10''-class submarine}}, again the italics, assuming they're correct, are sufficient. Where italics are not used, I don't know. For simple names, the ''Armed Forces journal international'' uses hyphens ({{xt|N-class submarine}}) whereas ''Jane's fighting ships'' uses scare quotes ({{xt|"N" class submarine}}). The latter convention would of course handle compound names as easily as simple ones, but it has not generally been what we've used on WP. Even without italics, though, I'm not sure using an en dash with a hyphenated class name provides any benefit.

Where the en dash would be useful is in things like {{xt|Passenger-Only Fast Ferry–class ferry}} and {{xt|P 4–class torpedo boat}}. — ] (]) 00:34, 30 July 2011 (UTC)
:Kwami may choose to read what is not the case; but I see no evidence that Scottish usage varies from English, British usage of the hyphen has been diminishing for over a century (although it may have hit bottom), and ''attributive'' (as a noun) is jargon. What other function of the compounding dash is there other than clarity? Power-gaming is not a function, it's an abuse. ] <small>]</small> 14:58, 30 July 2011 (UTC)
::Other meaning of "English": not of England, but of the English language. I know, when you're not claiming this "isn't English", you're claiming it's "only British". Perhaps you could invent some new excuses? Though I see promise for a new one: those you disagree with you could now be "abusive". Disappointingly unimaginative, though. — ] (]) 19:28, 30 July 2011 (UTC)

I′ll point to an example that Dick Lyon pulled out a while back: {{xt|San Francisco–based company}}. Now perhaps the caps would help avoid ambiguity if a hyphen were used rather than a dash, but I think they help less here than in {{xt|post–Civil War period}} because the caps don’t directly abut the hyphen that is to be replaced. The example {{xt|quasi–open government policy}} from CGEU doesn’t even have any caps, and {{xt|quasi-open government policy}} leaves me with a slightly different impression.

I agree with Chicago that many readers will miss the subtle distinction here. But in any event, if some readers just see {{xt|San Francisco–based company}} as {{xt|San Francisco-based company}}, what has been lost by using the dash? I do agree that a compound can only be so long for this to work, and the CGEU example is getting close, as is {{xt|pre—World War II aircraft}}. ] (]) 22:37, 30 July 2011 (UTC)

:Yes, really long strings screw up all hyphenation conventions. As for {{xt|post–Civil War period}}, some writers capitalize the "Post", in which case capitalization does not help. — ] (]) 02:25, 31 July 2011 (UTC)

== Unit measures for dates ==

Two ounces of July 30? 23rd century – 4th millennium? Spring – summer? Last weekend – next Tuesday? Last fortnight – next month? Unless I'm the only guy who doesn't get it, it should be re-explained. ] (]) 22:29, 30 July 2011 (UTC)
:Well, there are at least two of us {{nowrap|. . .}} and I’m pretty familiar with units. ] (]) 06:15, 31 July 2011 (UTC)
::{{Resolved}} by re-explaining. ] (]) 16:50, 31 July 2011 (UTC)
:::Greg's edits are not at all "resolved". They depart significantly from the consensus version we spent months negotiating, without consensus. At this stage, only uncontroversial alterations should be made. ] ] 06:13, 1 August 2011 (UTC)
::::I think Greg's version is not bad, now that the "units" thing has been fixed. I also agree with Tony that "only uncontroversial alterations should be made." So I was fully expecting Greg's version to get reverted back to the consensus version by Noetica, by someone who felt that Greg moved it in a bad direction; so far, nobody has complained or reverted. So maybe it's not controversial? Tony, are you saying you don't like it as much as what we had before? If that's what you're saying, then by all means let's take it back to the consensus version; I've invested a lot of effort trying to find a version that nobody objects to (see ]), but if it doesn't exist, then the one that the majority at least was OK with should be OK for now. ] (]) 06:32, 1 August 2011 (UTC)

::::''This'' particular issue this thread is about was solved. The other ones are being discussed at ]. (As for me, I prefer Noetica's version as it's shorter and clearer, though I'd retain Greg L's suggestion to avoid über-complicated dashed ranges.) <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 13:54, 1 August 2011 (UTC)

I consider the discussion at ] to be finished, and failed; I've reverted to Noetica's version, the last one that had something like consensus. ] (]) 17:16, 1 August 2011 (UTC)

== Check my work: Dashes ==

I proposed a move at ] under my understanding of what "conjunction" and "disjunction" mean when deciding between hyphens and dashes, but now I'm concerned that that understanding may be incorrect. Could one of the local "experts" check my reasoning there and advise? ] <sup><small><small>]</small></small></sup> 15:40, 31 July 2011 (UTC)

:It's clearly a case for an en dash. I'm as confused as you are about what the "conjunction" means in ]. I find no grammar or style books that use the term ''conjunction'' to describe the role of a hyphen. Maybe someone else knows of one that will clarify? Probably it just means a tight binding. Binding Charlotte tightly with Genesee would suggest an entity "Charlotte Genesee" being used as an attributive; the en dash would suggest that Charlotte and Genesee are both modifying lighthouse, in some relationship like "and" or "between"; in this case, indicating a location on the Genesee River, at or near Charlotte on land. ] (]) 21:13, 31 July 2011 (UTC)

::Okay, makes more sense now. Perhaps we ought to clarify "conjunction" and "disjunction" -- or remove them entirely -- from the policy page. ] <sup><small><small>]</small></small></sup> 00:02, 1 August 2011 (UTC)

:::Yeah, we've gone round & round on that wording. 'Disjunction' is almost but not quite right. It's useful in the phrase ''disjunctive en dash'', but as an actual explanation I think we need to spell it out: a union of independent elements, etc., not just "disjunction". — ] (]) 00:51, 1 August 2011 (UTC)

::::At least in the case of "disjunction", there are a few guides (by Garner) that talk about one usage of the en dash, of the sort where a slash (virgule) is sometimes used (see ), like "on–off switch" or "forward–reverse control", where it's one or the other but not both at once. But I don't see how "disjunction" is a good term for the more general case; where the relation is "and" or "between", I'd say it's more of a conjunction (a tying together, loosely). The using "conjunction" to describe the hyphen's role, we draw the line in the wrong place; time for a better description? ] (]) 03:35, 1 August 2011 (UTC)
::::The best description is to be silent, and above all avoid made-up jargon. Any phrasing that inspires us to ask "what does that mean?" doesn't serve anybody. ] <small>]</small> 21:40, 1 August 2011 (UTC)
As far as I can tell, this relates to one sentence in the discussion of image filenames: ''A hyphen is used only to mark conjunction, not disjunction (for which en dashes are used: see below)''. Set aside the unsourced claim of fact here; even if it were true, why need it be said there? Our rule is that image filenames don't use dashes at all, because readers don't see them and editors (who do see them) want to be able to type them easily. ] <small>]</small> 21:50, 1 August 2011 (UTC)
:There are other places to discuss your objections to the very idea, PMA; my question was about applying what's been agreed to for the time being. ] <sup><small><small>]</small></small></sup> 15:38, 2 August 2011 (UTC)

== Song vs. Tune ==

I should like to move that a guideline on the use of these terms be added to the MoS.

Americans seem to be the only English-speakers that refer to a piece instrumental music as a song; to everyone else it is a tune, or a piece (I know there are exceptions, like Mendelssohn’s Songs Without Words). Being English, I find it very confusing when reviews on amazon.com refer to "the songs on this abums", and I find later that the entire thing is instrumental. This is particularly so in idioms that could be either, such as Irish or Scottish folk music, or Flamenco.

Tune, on the other hand, is presumably comprehensible to everybody.

The guidelines say that "common ground should be sought where possible, words that would be confusing in other dialects should be avoided, etc."

So I should like to recommend respectfully that the word Song be avoided when referring to an instrumental piece. ] (]) 16:13, 1 August 2011 (UTC)

:I tend to think "melody, part of a song" when I hear "tune," (I'm from the U.S.) so perhaps it isn't as incomprehensible as you think. EDIT: I checked dictionary.com and it seems my impression is pretty close. "Tune" is not an ideal substitute for "song" or for "instrumental piece of music without singing."
:That doesn't mean you don't have a point. ] encourages using cross-English terms wherever possible (avoiding "bonnet" for "trunk of a car," using "fixed-wing aircraft" instead of "airplane" or "aeroplane," etc.) but we don't have a list of terms to be avoided in the MoS itself. It seems that your next step would be to create an entry for "song" in the article ]. Make sure that you have reliable sources that you can cite. For example, in my part of the U.S. the term "pigtails" is only used to mean ] and "braids" means what others call ]. However, because this isn't 1. the dictionary definition or 2. a clear AmE/BrE division&mdash;lots of American sources, speakers and writers use "pigtails" the dictionary way&mdash;this meaning of "pigtails" doesn't merit an entry in this article. ] (]) 17:43, 1 August 2011 (UTC)
::The OED with various definitions. I've always taken 2a as the main meaning, refering to a composition that sets a lyrical poem to a melody, as for '']''. Different harmonies do not make the song a different song. Different singers do not make it a different song. Different lyrics ''do'', as for '']'' which is sung to the same melody. Different recordings do not make the song a different song. Let us avoid conflating "song" with "performance", "recording", "track", "tune", "lyric" or anything else. The ideas are quite distinct, even if their vernacular usage is sometimes sloppy. ] <small>]</small> 19:16, 1 August 2011 (UTC)
:::So what is the word for a single popular-music composition of an independent melody, optionally with harmony or full backing accompaniment? "Composition" is too broad; "recording" doesn't apply to live performances, while "performance" doesn't apply to sheet music; "tune" doesn't incorporate the entire composition. ] <sup><small><small>]</small></small></sup> 20:31, 1 August 2011 (UTC)
::::What about "piece"? It should be unambiguous in context; or, failing that, "instrumental piece" or just "instrumental"? For example, "Wipe Out" was specified as a Song originally. I changed it to Instrumental in 2009, and no one seems to have complained or reverted it yet. ] (]) 20:43, 1 August 2011 (UTC)
:::::That's fine when writing of a single work, but what about a collection of such works? Shall we say that an album comprised ten songs and one instrumental? Well, I suppose we could call them tracks, but then does it make sense to say "He performed several tracks from his album"? Or what if it's not from an album: "We heard several pieces from other artists" -- does that mean bits and pieces, or songs? ] <sup><small><small>]</small></small></sup> 22:56, 1 August 2011 (UTC)
:News to me that ] was an American; see '']''. ;-> ] <small>]</small> 21:19, 1 August 2011 (UTC)
::::Septentrionalis, read the original comment more carefully! It depends what you are referring to. A folk musician will know various "tunes", which they will play with other musicians in various variations depending on the group. On a recording there are "tracks" (which used literally to be tracks in the vinyl days). A "piece" is normally a through-composed work, rather than a tune which can be adapted in performance. Surely it depends on the context whether "tune", "theme", "air", "song", "piece" etc are appropriate. Of course musicians - both popular and classical - often use technical terms in deliberately idiosyncratic ways. No-one thinks Hungarian Rhapsodies and Bohemian Rhapsodies are the same musical form. ] (]) 21:26, 1 August 2011 (UTC)
:::::And nobody in their right minds thinks "song" is the name of a musical form at all. This entire section is an example of why the Manual of Style is an ]; every pedant thinks they can use it to make every editor Do It My Way, when in fact sane editors ignore this page altogether. ] <small>]</small> 21:36, 1 August 2011 (UTC)
::::::Split hairs any way you want: the fact remains that using Song for something that isn‘t sung is confusing to many people, and should therefore be deprecated. ] (]) 22:24, 1 August 2011 (UTC)
:::::::The difference between "effect" and "affect" is confusing to many people, too, but that doesn't mean we avoid the words. ] <sup><small><small>]</small></small></sup> 22:56, 1 August 2011 (UTC)
::::::::Those words don’t mean different things to Americans and Britons. ] (]) 06:09, 2 August 2011 (UTC)
::"I've always taken 2a as the main meaning" leaves me thinking that there might be some peeves and personal preferences involved rather than a bona-fide case of people using the word wrong. Paul M and Lead Song Dog would be right to boldly edit articles so that they use more precise wording, but we should not work a rule banning this use of "song" into the MoS.
:::Of course the MOS doesn't ban the use of anything, it's a guideline. But we have scattered guidance on songs over many pages: ], ], ], ] all pertain. The inactive ] page also has relevant content. Of course, they are not entirely consistent. The at the massive ''Virginia Tech Multimedia Music Dictionary'' is rather elegant in its simplicity - we might learn from it. ] <small>]</small> 15:45, 2 August 2011 (UTC)
::::While popular usage of the term "song" has possibly evolved, the found in Grove's ''A Dictionary of music and musicians (A.D. 1450-1889)'' Vol. 3, Macmillan (1890) pp.584-632 starts out very simply. "In relation to the study oof music, a Song may be defined as a short musical composition, whose meaning is conveyed by the combined force of words and melody, and intended to be sung with or without accompaniment. The Song belongs, therefore, equally to poetry and music." Seems pretty clear to me. ] <small>]</small> 16:13, 2 August 2011 (UTC)
::Again, if you guys can find sources showing that Americans use "song" one way and Britons use it another way, then put an entry into the article on American and British English differences&mdash;if this is a real difference, then you'd be doing everyone a favor&mdash;but that's as close to the MoS as this should get. ] (]) 00:07, 2 August 2011 (UTC)
:I think there already is (was?) a guideline suggesting not to call instrumentals “songs” ''somewhere'' in a subpage. Anyway, sometimes it can be tricky to decide whether it applies to a particular piece: is "]" an instrumental? What about "]"? I say the former is and the latter isn't, but I can see why someone might disagree. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 15:31, 2 August 2011 (UTC)

== More disruptive editing ==

I've reverted PMA a few times already, as he seems intent on editing the en dash section without seeking consensus first. We worked on this for months; the votes and discussion are on record, as are examples of a process that attempts to fine-tune it. Just inserting one's own view is not helpful. Will we be locking down MOS again? Or is there a simpler solution? ] (]) 23:09, 1 August 2011 (UTC)
:More of the usual. Let's have a few mere facts:
:*We had a poll on this, at ], section 6b. It divided more or less evenly, between those for spaces around en dashes in dates, those against them, and those who were against such spaces in general, but hesitantly willing to consider them in dates.
:*Of these objectors, Jeff Conrad had a whole sheaf of style manuals which opposed.
:*Dicklyon started a conversation on this, ]. Characteristically, most of you weren't invited.
:*This resulted in what is an impasse.
:*Where there is no consensus, we should not make what we do not agree upon into a rule.
:*ANevertheless, Dicklyon, as Owmer of this page, has rever-warred to imnpose an edit which does not refelct consensus, or sources..] <small>]</small> 23:55, 1 August 2011 (UTC)

:Yes Dicklyon, in what can only be described as a brain snap, Pmanderson has taken it upon himself today to edit the MOS—to let us all know how it really should be. I'm tired of being told how the MOS should be from someone whose self-declared motivation is the abolition of the document (e.g. continually trying to declare the MOS as historic—something the community has overwhelmingly rejected). Thank you Dicklyon for taking the time and trouble to try and improve the MOS for all, and I certainly felt invited when you wrote "]". ]&nbsp;]&nbsp; 00:21, 2 August 2011 (UTC)
:::And rhe other liar is heard from. My "self-declared" goal is the improvement of MOIS; if I wanted to abolish it, I would do what most Wikiepedians do and ignore it. But since Diclyon;s text is unsupported by consensus, style guides,,or usage, there will be az few who need mo other reason to approve of it. ] <small>]</small> 00:29, 2 August 2011 (UTC)

*Jeez, guys, tone it down. Don't refer to other editors as "liars". Don't accuse others of "owning" the page. Just discuss stuff before adding it to the MOS. If you want to add a statement that there is no consensus for a certain issue, then I think there should be a proposal made that that sort of statement be added to the text. ] <sup>]</sup> 00:48, 2 August 2011 (UTC)
{{od}}
* PMA, the discussion on en dashes has moved here to ''']'''. You may discuss things there. The decision was to temporarily back out my effort at peace-making and use Dicklyon’s effort at consensus building as a placeholder while discussion is ongoing.<p>Your edit ({{diff|Misplaced Pages:Manual of Style|prev|442580109 |∆ edit, here}}) seemed well intentioned but, as you found out, just created conflict. Unfortunately, your response to being reverted was a childish editwarring comment ''written <u>right into MOS</u>'', where you wrote {{xt|The en dash in numerical ranges is unspaced; there is no consensus on times}}… ({{diff|Misplaced Pages:Manual of Style|prev|442582962 |∆ edit, here}}).<p>The world will not end if you have to stare at a placeholder effort as the issue is further discussed on the subpage to which I provided a link. However, were you to be allowed to persist at more of the same childish editwarring, MOS would get locked down again. The need for a lock-down is a clear sign that Misplaced Pages’s ability to reel in disruptive editors has broken down. I’m not going to wait around for others to try to set you up for a 3RR violation to prove that you are editing against consensus. You ''have no entitlement'' to a full three tries at editing against consensus. If you make any more waves on this issue as others go peaceably try to find the best solution, I’ll personally take you to ANI. Yes, that is a threat, promise, pledge, whatever you want to call it; it’s a fact. ] (]) 00:55, 2 August 2011 (UTC)


== Any objections to extending MOS:TIES to all nations and regions? ==
*Thank you Good Olfactory. For the record, here's an example of Pmanderson's true motivations regarding MOS pages: At ] Pmanderson propsed: "''WP:MOSNUM is declared historic. It shall be tagged <nowiki>{{historic}}</nowiki> and kept protected;''" and "''Let's get rid of it''". (BTW, that proposal received no support in the subsequent discussion.) I would appreciate if the (incorrect) allegation of "liar" is retracted, and if not, could an admin please step in and address the injustice. ]&nbsp;]&nbsp; 01:06, 2 August 2011 (UTC)
**The word "liar" should certainly be retracted; a much smaller concern is that "declare the MOS as historic" doesn't quite match "WP:MOSNUM is declared historic", and MOS should be changed to MOSNUM. ] (]) 01:26, 2 August 2011 (UTC)
*** Sure, let’s deal with that little jewel head-on. On the subject of ''']''', PMA: your {{xt|And rhe other liar is heard from}} seems to have gotten the goat of GFHandel. I tend to let stuff straight the heck off the role off my back like water off a duck. Misplaced Pages being the all-volunteer joint it is tends to have a spectacular degree of inconsistency in its enforcement on that sort of thing. To a large extent, I think the community gives wide latitude to characters who are seen as generally incapable of conduct expected. All I can say is you didn’t do yourself any favors with that personal attack on GFHandel. It’s becoming increasingly clear to me why your presence at MOS is closely associated with lockdowns. I’m tempted to start the process of dealing with you using a broad brush; it’s not going to take much. I suggest you either get an attitude transplant real pronto here, or take a wiki-break. ] (]) 01:32, 2 August 2011 (UTC)
***Art, you would be right if Pmanderson's real aim was only to declare MOSNUM historic (while leaving all the other MOS pages standing)—which all those who have had long-term dealings with him know isn't correct. No, no, the quote I gave is more than indicative of his real motivations around these parts. The more I think about his statement "''if I wanted to abolish it, I would do what most Wikiepedians do and ignore it''" the more I find it utterly agreeable, and I support him following that strategy to attempt to abolish the MOS. ]&nbsp;]&nbsp; 01:43, 2 August 2011 (UTC)
****Who gives a crap what PMA thinks in that regard? It’s way outside of the mainstream so it’s a waste spending time to contemplate its It’s time to move on and discuss things civilly at ]. If PMA behaves himself there, fine. If not, fine; I know how I plan on dealing with that too. ] (]) 02:22, 2 August 2011 (UTC)
*****I don't. If you didn't look so much like mirror images, this would have probably been resolved years ago. ] (]) 02:42, 2 August 2011 (UTC)
****** Who are you talking to and what are you alluding to, Art? ] (]) 03:56, 2 August 2011 (UTC)
*******"I don't" refers to "I know how I plan on dealing with that too." As for "if you didn't look so much like mirror images", well&nbsp;... let's just leave that at "you plural". ] (]) 04:12, 2 August 2011 (UTC)
********Well, ''“Awesome Wikipedian”'' or not (I just looked at your user page), that just comes across as your galloping in here on your whiter-than-white tall steed, it’s nostrils flaring in the morning mist, and having your steed rear up while you pronounce nebulous smack-downs on the little minions fighting in the trenches. It’s transparent and doesn’t impress. If you have something constructive to say, say what you mean. Otherwise, spare us the high-road posturing; M’kay? ] (]) 04:21, 2 August 2011 (UTC)
*********Aw, go fight on in the trenches. ] (]) 05:27, 2 August 2011 (UTC)


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.
As an update, I have PMAnderson for a week. Trying to undermine and weaken the dash consensus (like and ) that has required months of discussion is just not on. Plus show a lack of interest in discussing this constructively. ] (] '''·''' ]) 09:51, 2 August 2011 (UTC)


Would it not make sense to extend ] to nations (and regions) irrespective of whether they traditionally speak English or not? Because I can see how saying to someone that embraces multilingualism and values Europe's rich linguistic diversity wishing to contribute to an article on a topic with strong ties to their nation or region in the EU, where English is an official language, that in this case that tie doesn’t count (and someone else gets to decide) might be perceived as ... well ... rude and arrogant, which isn't just unnecessary but also unproductive. Would the article not benefit from including anyone with a strong tie to it?
:Thank you for watching. Nobody else is. I bet they still can't agree on dash spacing. ] (]) 14:43, 2 August 2011 (UTC)
* Yes, thanks. I hope other admins don’t try to second-guess you and pull the rug out from under your block, Casliber. Unless the other admins are going to invest the time to understand the history and pattern of editing and temperament of PMA, they’re not going to understand why WP:MOS actually had to be locked down for days-on-end; lock-downs are a clear sign that something was way-wrong. ] (]) 15:24, 2 August 2011 (UTC)


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)
== Chronological items - what should go into MOS and what should go into MOSNUM? ==
: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 ==
I have reinstated the changes that were reverted by ]. While I agree that that the MOS is not a list of possible difficulties, the list of difficulties serves as an introduction to the relevant section in ]. This follows the conventions used for the introduction in MOS for the section on Units of Measure.
:WP:MOS is becoming unmanageable – the split of WP:MOSNUM and of the section on Geographical terms has helped, but there has always been the danger of conflicting information appears in WP:MOS and WP:MOSNUM which is why I wrote the introduction as a series of difficulties. ] (]) 09:12, 2 August 2011 (UTC)
::Now that this article is unlocked, I made the changes discussed previously - see (]) and (]). My changes were twice unceremoniously undone without either editor actually being aware of the history behind these changes. Rather than have to go through all the discussions in these two archives, I invite comments from other editors regarding the changes that I made to WP:MOS at about 08:00 on 2 August 2011. ] (]) 13:17, 2 August 2011 (UTC)
:::My idea is that each section in WP:MOS should be a ] of the full guideline found in a sub-page, giving the general rules you need to know most often and a link to the “full” guidance for rare exceptions and rules which apply in more specialized situations. ] is what I had in mind (though I haven't edited that page in ages, so it may be outdated wrt what WP:MOSNUM says now). <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 15:21, 2 August 2011 (UTC)
::::One of the biggest problems with a summary is "mission creep" - more and more of what is on the subsidiary page get included back into the summary. That is why I prefer the introduction to define the scope of what is being discussed on the subsidiary page rather than to summarise it. This also removes the problem of contradictions being introduced into the text. In the case of chronological items, I reduced the scope to a number of typical issues that the user might have (and issues that are relevant but that he had not though of). ] (]) 15:28, 2 August 2011 (UTC)
I reverted again. I'm not opposed, but while I see there was some support for this kind of thing a few weeks ago, it's not clear to me that this was the wording we wanted for the summary. Are there any objections to reducing the verbiage by reinstating Martin's edit? — ] (]) 18:48, 2 August 2011 (UTC)
:A Manual of Style needs to be a manual, something that tells people what to do and how to do it. A list of non-directive principals (sic) is not a manual. It is nonsensical to list what a manual clarifies, while excising those clarifications. So long as the section headings are clear and accurate, so that the specific issue can be navigated to quickly via the ToC, why does the length of a MoS page matter any? ] (]) 19:50, 2 August 2011 (UTC)
::The Manual of Style comprises lots of pages, this one is only the “front” page. If all the guidance was found unabridged on one page, it'd be 1.4 MB, which would take forever to download with slower connections and would crash the readers' browsers a sizeable fraction of the times. :-) My idea is having the bulk of the guidance in the subpages (each of which would roughly correspond to a chapter of a printed style guide), a front page at WP:MOS giving an introduction with the general principles and then a summary of each subpage, and maybe a “full” version, for “brave” readers with a fast connection and no fear of a ToC filling several screenfuls, which would have the same introduction and then ''transclude'' the subpages. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 21:16, 2 August 2011 (UTC)
::Agree with A. di M. "So long as the section headings are clear and accurate, so that the specific issue can be navigated to quickly via the ToC" It can't. Most of the subpage information can't be found that way. But in the case of date information, you can still find it through the ToC, after clicking the link. That's better than finding a duplicate section that may or may not match the MOSNUM information, specifically ], and any other contradictions that may accumulate in the same way. Yes there are typos; we can fix them. And the length of the MoS page matters because it gives people less information to look through, before concluding that what they really want is either missing or on some subpage they can't find. We need a better system for navigating the subpages, but this step is in the right direction. ] (]) 23:14, 2 August 2011 (UTC)
:::I proposed more than a year ago that MOSNUM be reduced to just the stuff one doesn't want here (radiocarbon dating, for example, which is ''still'' on this main page, I see); and that MoS central have the basics as now. ] ] 01:45, 3 August 2011 (UTC)
::::Are people happy for me to reinstate the summary that was reverted yesterday (2 AUgust 2011)?
::::Are people happy that I should replace the section on numbers with a similar summary (currently both summaries can be seen at ])?
::::] (]) 06:52, 3 August 2011 (UTC)
:::::I don't think I am. Can you comment on my previous post here? ] ] 06:55, 3 August 2011 (UTC)
::::::Tony, if you scroll down to the section on Chronological items in ], you will see my proposal. It does not explicitly mention radiocarbon dating, but implicitly accomodates it with the phrase "but not limited to". Is this the answer that you were looking for, or should I have been looking at some other comment that you made? ] (]) 08:18, 3 August 2011 (UTC)
OK, I may have underestimated the scale of things above, and maybe the section should be abbreviated, but other sections are prescriptive, and Martinvl's text is descriptive: that does not serve as a summary of the MoS. ] (]) 08:39, 3 August 2011 (UTC)
::::Do you mean it would contain exceptions but not the rules they are exceptions to? I think that would be confusing. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 15:20, 3 August 2011 (UTC)
:::::??? I've said nothing about exceptions. If a short version of the MoS is required for the Mos page, then let that be a manual, not a description of the issues dealt with by the Manual elsewhere. ] (]) 17:43, 3 August 2011 (UTC)
::::::<small>Actually, I was commenting on Tony's suggestion “that MOSNUM be reduced to just the stuff one doesn't want here”. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 21:26, 3 August 2011 (UTC)</small>
:In response to ] - What you would have written, taking note that everything in the summary has to be in the subsidiary article and nothing in the summary and subsidary article should contradict each other. For the record, I cannot accept an answer "People must be careful to ensure that this does not happen" - my ] work experience has taught me that such demands are fraught with danger.
:Kevin McE has commented that my proposed rewrite, unlike most of the article, is not prescriptive. I know - the fault lies in the rest of the article - this is the third section to be contracted in a non-prescritptive manner, the other two being "geographical items" and "units of measure". The text for the fourth section "Numbers" can be seen ]. Since I am not a linguist, I will encourage other editors to use these four sections a start point for contracting the other sections of WP:MOS. ] (]) 09:02, 3 August 2011 (UTC)
::''the fault lies in the rest of the article'': is this your opinion, or is there a consensus that mandates this fundamental change? ] (]) 10:15, 3 August 2011 (UTC)
:::This is essentailly my opinion, based, I believe, on sound experience in ]. It was good enough for the user community when I applied it to the section "Units of measure", so it should still be good enough. The user community is generally of the view that something is needed, buit nobody is too sure what is needed (see (] and (]). As nobody else has done anything positive about this particular problem, I am trying to be ], putting a solution in place and seeing if the user community likes it. ] (]) 13:45, 3 August 2011 (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.
== Links in section headings ==


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, ]?
{{quotation|Headings should not normally contain links, especially where only part of a heading is linked.}}
Just out of curiosity, can somebody explain the reasoning behind this policy? –] (] • ]) 22:19, 2 August 2011 (UTC)
:Big horrible blue links make it look ugly. There may be technical reasons but for me this is the main thing. ] ] 22:29, 2 August 2011 (UTC)
:Search ] for "internal link in a section heading". Any other reasons? ] (]) 22:31, 2 August 2011 (UTC)
:And their effect on an article is ugly. ] (]) 22:33, 2 August 2011 (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)
== Extraneous clutter at the top ==


: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)
I haven't read the opening paragraphs of the MoS for some time, and was perplexed to see this:


::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.
:{{See also|Misplaced Pages:Manual of Style (trademarks)|l1=Manual of Style:Trademarks|Misplaced Pages:No original research|l2=Misplaced Pages's policy on no original research}}
::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)
{{Shortcut|MOS:FOLLOW|WP:MOSFOLLOW}}
: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)
::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".
::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 ==
:Many points of usage, such as the treatment of proper names, can be decided by observing the style adopted by high-quality sources when considering a stylistic question.<!--The preceding sentence is not consensus and is disputed--> Unless there is a clear reason to do otherwise, follow the usage of reliable English-language secondary sources. If the sources can be shown to be unrepresentative of current English usage, follow current English usage instead—and consult more sources.


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 counter to the opening statement "If the Manual of Style does not specify a preferred usage, please discuss the issue on the talk page." It seems to undermine the whole function of a MoS. There's an editorial note within the paragraph saying that there's no consensus for the opening statement. The links below the title are weird. I cannot find a record of consensus for adding this stuff.


* 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.
Unless someone can provide a good reason for retaining it, I intend to remove this subsection in the interests of reducing clutter and redundancy on the sprawling MoS page (especially since it's confusing). ] ] 04:18, 3 August 2011 (UTC)
* 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:
:. It's two years old. Its author, who often uses that edit's same reasoning to this day, has been banned for a week. We may thus presume a difference of opinion will occur next week. ] (]) 04:50, 3 August 2011 (UTC)
::::We don't need to wait for PMA's opinion, as we have it on record here: ]; he would support removing it under the condition that MOS is no longer a guideline; that is, in his mini manifesto, he objects to the removal and objects to MOS in general, and objects to anyone who supports MOS as "regulars" and "sponsors" who "need bots" (I'm still puzzling over that last bit). ] (]) 07:32, 3 August 2011 (UTC)
::Ah, fine, but this transcends a one-week ban. ] ] 05:05, 3 August 2011 (UTC)


* Length: should inline videos be shorter where possible? Does this apply to audio clips?
'''Support'''. I agree with revisiting this. This is the WP MOS and for stylistic issues we should offer the first port-of-call for our editors. If there's something we don't cover, then it can be discussed on the relevant talk page. The default should not be to go for whatever external manual an editor believes appropriate—that way leads to edit wars. ]&nbsp;]&nbsp; 05:18, 3 August 2011 (UTC)
* Language: if audio or video is original language, should subtitled content be preferred rather than recording originals? Should songs be subtitled where possible? What are the requirements for validating translations (what are the relevant WP policies on translation of original source material that apply?)
* Rendition: historical accents and historical musical performances might be very rare. Should we say that modern standards are fine, in the absence of authentic reconstructions?
* Public domain renditions: if audio or video is a rendition of a public domain source, for example a work by Mozart, or a speech by Caesar, what are the requirements for source validation (these should reference WP's general guidelines, but these are mostly focused on secondary sources).


] ] 20:25, 16 December 2024 (UTC)
'''Support''' deletion of "follow the sources". Yes, it's a bad section; we had already been discussing deleting it, when the MOS got locked for other disturbances. See ], where there was considerable support for removing it. History wise, in the original discussion about PMA's "follow the sources" section that met some initial rejection, several expressed concern that it would conflict with our style guidelines:
*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)
http://en.wikipedia.org/Wikipedia_talk:Manual_of_Style/Archive_109#Follow_the_sources
*:Thanks very much (and yes that was me!) I agree that MOS:Images would be best, especially to get this started.
PMA "persuaded" them that it would be OK, and then proceeded to use it exactly as had been feared. This will continue (next week) if we don't get rid of it. ] (]) 05:39, 3 August 2011 (UTC)
*: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:
'''Support'''. This was a politically motivated and unilateral insertion from the start. Its aim was to relegate WP:MOS, under the banner of Motherhood, to a minor role among the Project's guidelines and policies. The addition was immediately reverted (see edits following the one Art LaPella has linked, above). It attracted no thorough analysis in discussion (only two or three editors were involved), and never had anything remotely resembling consensus. The section's inclusion has been the cause of months of protection at this page, earlier this year. Time for it to go. No one denies that reliable sources have their place; but let no one deny the role of the Manual of Style. A manual of style is not an inventory of aphorisms; nor is it a vehicle for apologising for its own existence, at every available opportunity. <font color="blue"><big>N</big><small>oetica</small></font><sup><small>]</small></sup> 05:44, 3 August 2011 (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.
'''Support'''. Oh, yes please, with a cherry on top! It's useless waffle that doesn't add anything, and creates ambiguity for the average user when it's certainty they seek when coming here. The MOS needs to lose some calories, and this will burn up a few. --] ] 06:31, 3 August 2011 (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.
'''Comment''' I like the idea of a section reminding editors to consult sources because the MoS will not cover all instances or issues. However, it could be better phrased and I would not object to removing this section altogether for now. We can always put it back if we need it. Also: 1. I don't think that's quite what PMA meant, but it isn't as if we need a quorum or any specific editor's permission to change any part of the MoS. 2. The MoS register was a nice experiment, but it hasn't gone anywhere. Zero objection to giving it an honorable burial. ] (]) 12:28, 3 August 2011 (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 ].
:Not sure the "Sourcing" point needs to be made, as this is explained in detail for images generally.
:The "Length" point should probably link to the ] and point out the copyright issue when displaying here under fair use. It should say "video" not "videos" to be grammatical.
:I would drop the "Translations of subtitles" point and just link to ] for guidance on translations.
:The "Public domain renditions" point does not make any sense to me, and I would just drop it.
:I'm not sure whether the "Rendition" point needs to be made, but if it does, it's confusing. I think it's supposed to be recommending that historically accurate renditions of older works are preferred, if available. Maybe that's true, maybe it isn't, depending on what the purpose of inclusion in the article is. Might be better just to leave this point off; I don't see any similar guidance for audio samples of music. Page editors can decide which samples are best out of those available.
:Another point probably worth making is that a video should be considered an optional part of an article. In other words, any content vital to reader understanding should be included in the text and not be omitted on the assumption that reader will watch the video. Many readers will not be able to view video due to technical limitations, such as using a web browser that is not configured with a video player, or reading an article in another medium such as an app, paper printout, or text-to-speech system (including those who cannot see or find it difficult to read text). There is more specific guidance against putting text in images at ].
:It's fine for a video to re-explain something that's already explained in the text if having a moving image clarifies substantially, but it seems wasteful for embedded videos to effectively repeat or rephrase the text.
:-- ] (]) 22:49, 16 December 2024 (UTC)
::Thanks very much!
::* Regarding '''language''', this was meant to be about non-English content, think Bach or Mozart in German or Latin; or Goethe's poetry.
::* On '''Sourcing''', the section on images does not include YT, which is significant for CC video.
::* On '''translation''', the situation for subtitles is a bit different, as usually you cannot use academic in-copyright translations, so this mention is retained.
::* On '''public domain renditions''', this was the subject of a ]. Does that help? Take a file such as ]. There is some need for verification, even tho it is not being used as a citation? I've edited it for clarity.
::* On '''style of renditions''', this has come up a few times in discussion, including at the link above, where a user claimed only a Catholic priest could do a Latin audio recording; also at ] on LA Misplaced Pages about accents and delivery, preferring a modern standard over historical guesses. I figured the same principle might apply to say reading Shakespeare, or using 16th century instruments; it simply shouldn't be a consideration, but sometimes editors think it should be.
::* I've added the points on (1) text as images, (2) subtitles for EN content, (3) optionality of AV content
::'''VERSION 0.2'''
::Audiovisual content can also be used for illustrative purposes. Most of the guidance on images above applies to audio visual content. Importantly, audio-visual content should not be an essential part of a page, which is necessary to understand the whole. This is because not all readers will be able to download or access the content, for example because of technical limitations or relying on text to speech tools. With audio and video just as with any content, relevance is paramount; consult ] for further context. There must be a clear reason for including the content on the page.
::Additionally, consider:
::* '''Length''': inline videos or audio that is shorter will be easier for users to watch. Consider clipping long form content, and linking to the original on Commons, or elsewhere. Longer videos (eg, over 10 minutes) may be more suitable for links than inline video, unless they are highly relevant to the page's subject.
::* '''Rendition''': historical accents and historical musical performances are not required. Modern renditions of audio are acceptable. For example, there is no need to read Shakespeare with an Elizabethan pronunciation.
::* '''Musical, poetic and literary content''': aesthetic considerations are higher for these kinds of content. Where possible, the performances should be considered good by other editors. Where editors find performances are poor, content should generally not be included.
::* '''Subtitles for comprehension''': In English language videos, an English language subtitle track should always be provided for accessibility. See ] for more details.
::* '''Subtitles for translation''': where audio or video is originally in a non-English language, for example a Goethe poem, subtitles should generally be preferred over than translated audio, as this reflects the original more closely and text files are easier to correct than mistakes in audio-visual content. Where possible, songs should be subtitled. Original language versions should be made available where where possible for artistic content.
::* '''Translations of subtitles''' See ] for guidance. Note that longer subtitle sequences may need to be translated by Wikipedians rather than obtained from academic sources to avoid copyright infringement.
::* '''Embedding text''': As with images, rendered text should be avoided in video content. See ] for more information.
::* '''Public domain renditions''': if audio or video is a rendition of a public domain source, for example a work by Mozart, or a speech by Caesar, it must be possible to check the original scores or texts. An editor should be able to compare the performance with the original. Where possible, include links on media file pages so that editors can make checks.
::* '''Sourcing''': as with images, sourcing of audio-visual content needs to be copyright compliant. Sources of CC video and audio can include Youtube, Flickr and CC search tools. Care should be taken to ensure the licensing claims appear to be valid.
::* See also: ]


::] ] 23:32, 16 December 2024 (UTC)
:If (and that's a big if) there is instruction to consult outside sources, it should be clear that should only happen ''if'' the WP MOS does not give instruction ''and'' nothing has been forthcoming after discussion on the relevant MOS talk page. There should also be guidance to introduce discussion about what was discovered on the outside sources. I thought about why the MOS is important to WP and came up with the following (and I'm sure the list isn't exhaustive):
:::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)
:* it addresses the peculiarities of having a vast number of different viewing devices (different sized screens, tablets, PDAs, etc). This is something that print-based MOSs don't have to consider.
::::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.
:* it considers features specific to WP (e.g. info-boxes, tables, links, media, dynamic formatting, etc).
::::I'll be clear about the other discussions and examples of this content for context:
:* it provides consistency for the reader across millions of articles (e.g. to avoid encountering different abbreviations, or units of measure formatted differently in different articles).
::::* ]; ] no debate and no questions occurred
:* it indicates how information can be expressed succinctly—allowing the reader to focus on detail that deepens the understand of the article.
::::* ]; no questions raised (I am the main editor for this page but plenty of people make edits)
:* it gives guidance to local editors (to avoid or settle style-based disputes—encouraging to get on with the business of adding content).
::::* ]; ] as a link after discussion with editors
:* it gives guidance to editors who run tidy-up scripts (across multiple articles). Consistency also means that scripts have a better chance of working reliably (e.g. a smaller set of date formats exist to recognise and parse).
::::* ]; ] after discussion with editors
:What's amazing about WP's MOS is that it is one of the greatest exercise in consensus imaginable: with (just the main MOS page having) over 7,500 edits in ten years by more than 2,100 distinct editors (and five times that many edits on the talk page) . No doubt we are still on a (hopefully asymptotic) journey, but congratulations to all the editors here who have worked hard to achieve such noble goals.
::::* ]; readings included; no discussion or objection
:]&nbsp;]&nbsp; 00:14, 4 August 2011 (UTC)
::::* ]; reading of his disputes with no objections raised
*'''Support'''. Seems reasonable, and from the above has consensus support.--] (]) 01:13, 4 August 2011 (UTC)
::::* ]; 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 ] ==
===The global view section===


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)
:::So what the hell is ''this'' doing there? I don't mind "principles", but some of them seem irrelevant and/r redundant. No wonder editors complain that the MoS is too large:
: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)
:::"Except in content with a local focus or where specific localized grammar or spelling is appropriate, or when a ] and ], content should be presented from a global view ]." ] ] 05:10, 3 August 2011 (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? ==
Tony, that section came in a year ago, in by {{userlinks|Doc Quintana}}, who was subsequently permanently blocked as an abusive sock puppeter, with summary "I thought I saw this somewhere", and little notice. Given the fact that nobody has discussed it, and it seems extraordinarily odd, and has no better justification than that he though he had seen it some place, I suggest we just take it out, and see if anyone cares. I'll do that. ] (]) 06:00, 3 August 2011 (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)
And the "general principles" section that these were stuck into had its start in by SlimVirgin. Probably, in retrospect, saying "General Principles" made it a magnet for people with an agenda to sneak things into. ] (]) 06:13, 3 August 2011 (UTC)
:Well, Slim's good with this stuff, but probably didn't envisage that it would become the unruly forest we now see. ] ] 06:40, 3 August 2011 (UTC)
::The analogy applies inasmuch as the need to prune from time to time. --] ] 07:09, 3 August 2011 (UTC)
:::It's like "list" sections that become magnets for trivia, against the best intentions of their creators. So yes, let's reorganize it in a way that won't attract more principles. Or go with your forest pruning if you don't like my magnetic metaphor. ] (]) 07:21, 3 August 2011 (UTC)
::::Two more things: I can't imagine who might want to use any of those shortcuts to the "principles", or where. Isn't it easier and simpler to conflate all into a readable whole and refer people to the lead of the MoS? And could I ask whether ] is worth pursuing; it looks like a ghost town, yet is responsible for a large clutter-box at the top of the MoS. ] ] 07:59, 3 August 2011 (UTC)
:::::Your imagination is lacking. PMA used to cite ] some times when he disagreed with the application of the MOS. ] (]) 01:32, 4 August 2011 (UTC)
:Essentially, that is ] and ]. The former is already in the MoS (though buried somewhere most readers won't notice) and the latter is more about content than style ''per se''. <span style="white-space: nowrap;">― ]​<i lang="ga" xml:lang="ga"><sub>]</sub>​<sup>]</sup></i></span> 13:02, 3 August 2011 (UTC)


: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)
Good job, Tony; the new lead without the "general principals" collection is much better. ] (]) 01:30, 4 August 2011 (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)
* Yes, it works for me. ] (]) 01:48, 4 August 2011 (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)


== Legibility of thumbnails at default size ==
With Noetica's copy-edits for conciseness and such, we've dropped the size by about 4500 bytes (about 3%); not huge, but a good counter to the recent creep. What else can be cleaned up? ] (]) 05:45, 4 August 2011 (UTC)
{{Moved discussion from|Misplaced Pages talk:Manual of Style/Images#Legibility of thumbnails at default size}}
:Yes, it appears that ] is going through the MoS (in reverse order?) performing much-needed maintenance. I expect he'll alert the talk page if there's anything substantive to change. It looks like it's approaching a 10% reduction, but I'd be happy with a more minimalist approach (although my own effort a year ago showed that it's possible to make reductions in the order of 60%, I think people wouldn't be happy with the small number of examples that entails). ] ] 06:15, 4 August 2011 (UTC)
]
]
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)

Revision as of 12:27, 25 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 (156 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 12,392
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,996 1,996
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 225,987 225,987
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

    Should interactive content be included and, if so, where and how?

    Please select in your preferences: Enables javascript Calculator template to see a working calculator.
    Body roundness calculator 1805118131.890
    US_Navy_110426-N-00332-114_Students_measure_the_height_and_body_weight_of_fourth_and_fifth_grade_students_from_Lindenwood_Elementary_School.jpg
    Dimensions Height Waist
    180 +10 190cm≈6′3″ +3  183cm≈6′0″ +2  182cm≈5′12″ +1  181cm≈5′11″ 180cm≈5′11″ -1  179cm≈5′10″ -2  178cm≈5′10″ -3  177cm≈5′10″ -10 170cm≈5′7″ 81 +50 131cm≈51.575″ +40 121cm≈47.638″ +30 111cm≈43.701″ +20 101cm≈39.764″ +10 91cm≈35.827″ +5 86cm≈33.858″ +4 85cm≈33.465″ +3 84cm≈33.071″ +2 83cm≈32.677″ +1 82cm≈32.283″ 81cm≈31.890″ -1  80cm≈31.496″ -2  79cm≈31.102″ -3  78cm≈30.709″ -4  77cm≈30.315″ -5  76cm≈29.921″ -10 71cm≈27.953″
    Roundness 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 1 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg 0 Waist_to_height_ratio_silhouettes.svg
    Waist-to-height ratio (WHtR) 81/180 ≈= 0.450.45 ≈ 0.45
    WHtR Waist for height 180cm, 5′11″
    1.00 1.00 Waist_to_height_ratio_silhouettes.svg 180cm≈70.866″
    0.900.90 Waist_to_height_ratio_silhouettes.svg 162cm≈63.780″
    0.800.80 Waist_to_height_ratio_silhouettes.svg 144cm≈56.693″
    0.700.70 Waist_to_height_ratio_silhouettes.svg 126cm≈49.606″
    0.600.60 Waist_to_height_ratio_silhouettes.svg 108cm≈42.520″
    0.500.50 Waist_to_height_ratio_silhouettes.svg 90cm≈35.433″
    0.450.45 Waist_to_height_ratio_silhouettes.svg 81cm≈31.890″
    0.400.40 Waist_to_height_ratio_silhouettes.svg 72cm≈28.346″
    0.300.30 Waist_to_height_ratio_silhouettes.svg 54cm≈21.260″
    rounded bounded
    silhouette index,
    hidden     		5
    silhouette index,
    hidden     		5.876404494382022
    hidden <0.4 >=0.4 >=0.5 >=0.6
    hidden 0.4
    01     		0.4494
    0| 0.4494
    0

    7290108

    Health risks

    		00.6 ≤ WHtR0.6 ≤ 99: further increased health risks0 0.5 ≤ 99 < 0.60.5 ≤ WHtR < 0.6: increased health risks 10.4 ≤ WHtR < 0.50.4 ≤ 0.45 < 0.5: no increased health risks 0 WHTR < 0.499 < 0.4: Unspecified
    Today

    I think this is a new topic, forgive me if not.

    At Waist-to-height ratio, user:Uwappa wants to include an interactive calculator that they have developed, replicated here for your convenience. The concept is fairly simple: readers may enter their own height and waist-circumference and receive a calculation of their Waist-to-height ratio (and a related metric recently popular in the US, body roundness index). It is not earth-shattering stuff, the math is straightford and the underlying algorithms are fully supported by WP:MEDRS.

    We already have dynamic content, such as the display of the Islamic and Hebrew calendar dates v today's Gregorian calendar date. I don't see any issue with that practice.

    So here are the questions:

    1. Should Misplaced Pages include interactive content?
    2. If so, how should it be presented?
      1. Inline, without comment, so it appears to be just a static, illustrative example. As shown in this version of the page in the section #Guidelines. It is, however, still interactive.
      2. In an independent section, as shown in this version, in the section #Calculator, with a line of text that explains what it is. (This interactive calculator can calculate a waist–height ratio and Body roundness index. It accepts height and waist in cm or inches.
      3. Something else?
    3. Is it a WP:NOR violation? .
    4. Are there other issues that arise? (For ex, is MOS:ACCESS a show-stopper?)

    Personally I think it is a good idea (WP:NOTPAPER) but I'm not sure how best to handle it. Comments? 𝕁𝕄𝔽 (talk) 20:59, 2 November 2024 (UTC)

    See also Misplaced Pages:Village pump (technical)/Archive 215#Building a simple body index calculator. --Redrose64 🌹 (talk) 23:23, 2 November 2024 (UTC)
    On the subject of accessibility - if the labels for interactive fields are created using the {{calculator label}} template, it should mark in the HTML that that piece of text corresponds to that specific input button, which is something that screen readers should hopefully be able to take into account. I would recommend using {{calculator label}} where possible when labeling fields, for better accessibility (It may not be possible if a label labels more than one widget). For the most part, I think it should be reasonably accessible most of the time, but i would love to hear feedback from accessibility experts, as I am definitely not one.
    One thing I would recommend is to test how any interactive content looks when printed. In some cases it looks fine as is, but in other cases it might be necessary to make specific fallback content. The template supports having fallback content for cases where js is disabled or during printing. Bawolff (talk) 17:22, 11 November 2024 (UTC)

    Reply by Uwappa

    Demo:

    1. Update the height in the calculator on the WHtR page.
    2. The formula example values will 'magically update'.
    3. See the wikitext for what that takes to do. Look mum, no javascript!

    No, it was not me who wanted a calculator, do not deserve any credits here, user:Zefr does, see Zefr's founding father's idea of 01:28, 21 September 2024.

    1. Yes, Misplaced Pages should have interactive content. It is 2024. The web has moved on from being previous century 'static' text and images. WP is more than an online version of a paper encyclopedia with text and images. I fail to see why the calendar example is relevant here. Please don't be amazed that it is possible to show dynamic content in 2024, like the current time, 05:21, 26 December 2024 UTC .
    2.  
      1. Calculations should be presented inline, just like current examples at: Inch#Equivalents, Body_roundness_index#Calculation, Waist-to-height_ratio#Recommended_boundary_values, Centimetre#Equivalence_to_other_units_of_length.
      2. No, it does not accept just cm or inches. The Sandbox version does not ask you to input cm or inches, WP:NOTHOW. It uniquely accepts any unit, unlike commercial BRI calculators. A 3 year old in outback Australia could use a piece of string as a unit. You can use the height of a peanut button jar as a unit, please do and while at it, please record the time it took you to do the usability test and compare it with commercial calculators. It does support Americans, British and others using Imperial_units by providing cm-> feet & inches conversions.
    3. No it is not a NOR violation as defined by WP:CALC. The only thing Template:Calculator can do: calculations with numbers only. It yields just numbers, which include a simple bit, with a value of 0 or 1: to hide or to show, that is the question. See proposed plain English explanation in the sandbox. This show or hide is taken care of by standard CSS. Switch off CSS in your browser and see what goes on under the hood. A joke for the happy few that do understand Boolean_algebra#Basic_operations and have a sense of humor: Shakespeare was wrong. To_be,_or_not_to_be is not a question in 2024, it evaluates to a constant, boolean value: true. Same logic at: 中国房间 = AI NOT(AI)? That is not a question either. It is true.
    4. Security may be a concern to some. Is there some dangerous Javascript here? The answer was amazing for me: no. Look mum, no javascript in the wikicode. Current WP rules and guidelines suffice and apply, see information hierarchy in Sandbox.
    Uwappa (talk) 00:52, 3 November 2024 (UTC)

    It is hard to tell from a distance what the reason for this post is. To me this post is a waist of valuable time and should be withdrawn.

    The current MOS applies well to:

    • A fixed date, just text like 1 dec 2032
    • A dynamic date, like now is 05:21, Thursday, December 26, 2024 (UTC) using template:currentdate
    • A combination of the two, like it is now 95 months till 1 dec 2032
    • A dynamic interactive version, using calculator with input fields asking for a month 11, year 2024 and the result of a calculation: It is 97 till 1 dec 2032.

    What is the problem here?

    BRI = 364.2 − 365.5 1 − ( waist π × height ) 2 {\displaystyle {\text{BRI}}=364.2-365.5{\sqrt {1-{\Big (}{\frac {\text{waist}}{\;\;\pi \;\;\times \;\,{\text{height}}}}{\Big )}^{2}}}}

    with WHtR = waist height {\displaystyle {\text{WHtR}}={\frac {\text{waist}}{\text{height}}}}

    to get BRI = 364.2 − 365.5 1 − ( WHtR π ) 2 {\displaystyle {\text{BRI}}=364.2-365.5{\sqrt {1-{\Big (}{\frac {\text{WHtR}}{\;\;\pi \;\;\,}}{\Big )}^{2}}}}

    • It may be just a lack of knowledge, not knowing about WP:CALC. That is an easy one to solve, just go and read it
    • It may be a problem with limited Cognitive_skills or use of a small screen smartphone in stead of a large computer monitor. User JMF has replied with TMI to my posts several times. The easy solution would be to switch to a big monitor for more complex talk pages. For limited cognitive skills, I can only recommend to visit a medical expert, will not give medical advice WP:MEDICAL.
    • Disclosure: My field of expertise is a form of psychology that seems unknown in the English speaking world: function psychology. The 'patient' in that science is not the human, it is the design object that causes man-thing interaction problems like: Help, I do not understand my computer and my computer does not understand me. The 'cure' is a redesign of the 'thing' e.g. the Graphical_user_interface. Create a human efficient design that suits the qualities and limitations of the human eye, interpretation skills, memory, ability to think and take action (mostly with hands in computer interfaces). WP does not have an article yet on human efficiency or function psychology. Being too involved in this field, it is not up to me to write such articles, WP:COI, WP:OR, WP:NOTABOUTYOU.

    What I can do is to help WP and design excellent, human efficient interfaces. All of you can help by evaluating results.

    • Is the sandbox version human efficient? And please do not give a sh** about computer efficiency. No worries if computers do 'redundant' calculations to make humans more efficient.
    • Is the sandbox calculator better or worse than commercial equivalents?
    • I do not give a s*** about personal preferences and your 'solutions' based on personal preferences. Go and tell someone who cares. Just list the problems you encountered during the tests. The most valuable ones are when test subjects fail to reach the desired result.

    Such usability tests are easy to do and can be fun. Kudos to user JMF who has done a usability test that were very insightful for me in the metric world and have lead to an excellent unit less solution for people using either metric or imperial units.

    Please join the fun, perform a usability test yourself at: Template_talk:Body_roundness_index#Usability_test_of_body_roundness_calculators — Preceding unsigned comment added by Uwappa (talk • contribs) 07:24, 3 November 2024 (UTC)

    @Uwappa:, this discussion is about the principle of how best to handle interactive content on Misplaced Pages. The details of the first such example are not relevant to the discussion. If anyone wants the details, you have covered them extensively at the template talk page. 𝕁𝕄𝔽 (talk) 07:49, 3 November 2024 (UTC)
    Yes, I get the question. Do you understand my answer or is this TMI again for you?
    Did you notice the interactive date computations at #dateCalc? It would be a compliment if you missed it.
    Please go and inspect that bit of wikitext. Yes, it is really that simple to make interactive calculations!
    Uwappa (talk) 08:02, 3 November 2024 (UTC)

    To answer the OP's original numbered questions:

    1. WP should very selectively include interactive content, when doing so enriches the functional (not entertainment or time-passing) utility of the site in ways compatible with WP's goals. It is correct that WP is more than a traditional paper encyclopedia, but it is not everything.
    2. I would suggest starting with sectional inclusion (or, for something small enough, use in a sidebar). We're already doing this with some limited "test-bed" ways, e.g. with interactive maps in infoboxes, and some manipulable 3D visualization objects, etc. But just dumping it directly inline is probably "too much, too soon". I could see that being feasible for certain kinds of things in 5–10 years, maybe, after both the user base and the editorial community got more used to it.
    3. Basic, objective calculation is not WP:OR. The policy is explicit about that, and we already use it regularly (just mostly non-interactively), e.g. to provide age-at-death calculations, inflation conversions, etc.
    4. MOS:ACCESS always matters, but there are ways around most accessibility problems (especially in a table-based structure like the one used as the example). Some other kinds of content simply are not accessible, and there's nothing much to be done for it, but we don't ban them. E.g., a movable panorama image is of no use to a blind person; the best they get is alt text. What's key, though, is that important encyclopedic material, verus "extra" or "enrichment" or whatever add-ons, must not be inaccessible (and supplementary materials should be made as accessible as possible, even if this is challenging).

    I would add that the example given here is probably a good one, as the interactive form actually helps one to understand how the calculations work, plus people are apt to want to try their own numbers in there for personal relevance reasons, and it's not pure entertainment/trivia but something meaningful to them. A counter example might be adding a pool table simulator to an article about a pool game; we have no reason to do this. However, I could envision us having an extremely limited interactive feature to illustrate specific principles like, say, "running" sidespin on the cue ball and its effect on angle away from a rail cushion versus the angle the ball had coming in. Right now, we can illustrate the effect with a fixed series of short animations or even static diagrams, but it might be more useful to have a widget that took user input and illustrated the results. But it should certainly not be a "mess around all day on a pool-sim video game" feature. I.e., no ability to zoom out into a full-size table and simulate arbitrary billiards actions.  — SMcCandlish ☏ ¢ 😼  16:30, 24 November 2024 (UTC)

    I think articles on algorithms and math topics might be a place where having step by step interactivity would be particularly useful. I just added an interactive "illustration" to the Bubble sort article and I was also experimenting with the euclidean algorithm (not used anywhere as of yet). Bawolff (talk) 00:13, 26 November 2024 (UTC)

    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.

    Dyslexia font?

    Is there any font available in wikipedia that can be called by CSS such as:

    Uwappa (talk) 06:52, 15 November 2024 (UTC)

    See Misplaced Pages:Dyslexic readers. Personally I didn't find that it helped, but good luck. SchreiberBike | ⌨  20:37, 15 November 2024 (UTC)
    WP:DYX seems outdated. I do not see 'Fonts' in preferences. Uwappa (talk) 01:21, 16 November 2024 (UTC)
    Yep, that's out of date. I've raised the question on that talk page. Anybody else got ideas? If not here, perhaps Misplaced Pages:Teahouse has ideas. SchreiberBike | ⌨  02:43, 16 November 2024 (UTC)
    @Uwappa and SchreiberBike: It's not in preferences, and as far as I know (my records go back to about 2010), it never has been. It's a configuration setting that is independent of preferences: as the WP:DYX page formerly said (I don't understand why This, that and the other (talk · contribs) removed it), it's done through the cogwheel next to the word "Languages". This is in the expected position in the left sidebar for four of the installed skins - Modern, MonoBook, Timeless and Vector legacy (2010). For three other skins, it's different:
    • For Colugne Blue (which not many people still use), the setting may exist but I can't find it
    • For MinervaNeue (i.e. most mobile users) there is no setting
    • For Vector 2022, it's there but is more difficult to find (as are many other things): you need to look just above the "Read / Edit / View history" tabs, where you should find a box that shows a strange Asian character, a number, the word "languages" and a down arrow. Click that down arrow, and the cogwheel is revealed after "+ Add languages" at the bottom right of the dropdown.
    Having located the cogwheel, click it and then proceed as per WP:DYX instructions 2 through 6 inclusive. --Redrose64 🌹 (talk) 11:18, 16 November 2024 (UTC)
    Found it and successfully set the font to OpenDyslexic.
    That is eh... well hidden. Uwappa (talk) 13:52, 16 November 2024 (UTC)
    I amended the WP:DYX page. --Redrose64 🌹 (talk) 16:27, 16 November 2024 (UTC)
    A video or animated gif of the process would probably be welcome. WhatamIdoing (talk) 00:57, 25 November 2024 (UTC)

    The whole process should be simpler:

    1. My preference: OpenDyslexic is the default font for Misplaced Pages. Yes, that is all pages for everybody. Wikipedians can opt for another font in preferences. IP users have no choice. This will benefit the large majority of dyslexics that are not wikipedians.
    2. Wikipedians can opt in for Dyslexic font in preferences. No solution for the vast vast majority of IP dyslexics.
    3. For happy few, the current solution: install dyslexic font on own device, create your own CSS. That will benefit the very few dyslexics that are Wikipedians, know how to install a font and 'speak' CSS.

    Uwappa (talk) 04:54, 16 November 2024 (UTC)

    @Redrose64 you will notice that you can actually click the cogwheel in numbered list item 1 on WP:DYX itself - no need to go locating anything! This, that and the other (talk) 06:42, 18 November 2024 (UTC)
    @Uwappa: To take your numbered points in not their original order: 2) That's already the case, except "no solution for ... IP dyslexics" isn't really true; the "cog-wheel" menu discussed above is available to logged-out users. The problem is that it's hard to find. 3) This is additionally already the case. Anyone can install that font, system-wide, and have their browser impose it universally. This takes a smidgin of technical figuring-out, but anyone dyslexic who finds that font helpful has it in their best interests to figure that out, because really close to zero sites on the entire Web are going to be doing what they'd like done, so it will have to be done by local and overriding personal imposition. 1) As someone who's mildly dyslexic, I have to say I detest the OpenDyslexic font, and the earlier ones it's based on, as general reading fonts. As a decorative display font for things like flyers, OpenDyslexic is a nifty neo-Nouveau font, and I've actually used it before with that aesthetic in mind. But for general reading, I think I'd rather just gouge my own eyes out. I don't find it helpful in the least, and at smaller than heading sizes, it slows my reading pace by about 50%. Not everyone's ability issues are identical, even if they fall within the same general/overgeneralized classification. So, the idea of imposing this font on everyone by default is a non-starter; it'd be like requiring everyone to wear a hearing aid (turned up loud at that) even if their hearing is acute.  — SMcCandlish ☏ ¢ 😼  12:34, 21 November 2024 (UTC)
    Your option 3 is nice, let the browser take care of it, across all websites. Yes, that will suit dyslectics fine and won't have any impact for the rest of us. Simple, working, excellent! Thank you!
    I am not dyslectic myself, so I can not judge the font benefits. The design idea makes sense to me, make sure characters do not look identical when 'flipped' in the mind. Uwappa (talk) 16:17, 21 November 2024 (UTC)
    That only works for a particular sort of dyslexia, prone to vertical flipping. I'm glad such a font works for those who experience that. For some of us, it's more of a "swimming letters" effect that slows reading and causes a lot of mistaken first readings, e.g. seeing "exist" as "exits" or vice versa (though for me it's much more of an issue with numeric input). Also impedes visual scanning for typos, which has a lot to do with my higher-than-average rate of those. I sometimes re-re-re-read something before hitting "Publish changes" and there will still be an "obvious" typo in it. There's probably also horizontal flipping, like difficulty with E vs. 3, J vs. L, etc., but it's not something I've studied (and not something that affects me). I've heard of another sort that involves whole-word transposition, and that would drive me bonkers.  — SMcCandlish ☏ ¢ 😼  14:28, 24 November 2024 (UTC)
    I tried that OpenDyslexic font. It makes pages more difficult to read than the default Arial font. --Redrose64 🌹 (talk) 14:34, 24 November 2024 (UTC)
    I've tried the open dyslexia font. It is OK for me and I do understand how it counters both vertical an horizontal character-flipping.
    For me the default Arial font is easier to read, but I am not dyslexic.
    I do like the suggestion to solve it in the browser. Let dyslexic people use a special font, not just on Misplaced Pages, but on all websites.
    • That will be great for dyslexic people.
    • While the rest of use are happy with the standard font.
    Uwappa (talk) 14:36, 25 November 2024 (UTC)

    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)

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