Misplaced Pages

Revision as of 01:20, 26 December 2024

This is the talk page for discussing improvements to the Manual of Style page.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Shortcut WT:MOS

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:

Manual of Style This 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 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. 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. Misplaced Pages Help Top‑importance This 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 Top This page has been rated as Top-importance on the project's importance scale.

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)

• Talk:United States Virgin Islands's at-large congressional district#Requested move 10 December 2024 – Plural possessive MOS:POSS question
• Talk:Second Italo-Ethiopian War#Flags in the infobox
• Misplaced Pages talk:Manual of Style/Biography#Proposal to import a line-item from WP:JUDAISMSTYLE into MOS:BIO – to use policy-based material on "Christ" found in an essay but more useful in a guideline. (Nov. 2024)
• Misplaced Pages talk:Article titles#Request for comment on the relationship between WP:CRITERIA and WP:TITLEFORMAT – Has stylistic implications (punctuation, leading "The", etc.) despite not being intrisically an MoS matter. (Nov. 2024)
• Talk:Battle of Tory Island#Infoboxflags - use of flag icons in infobox per MOS:INFOBOXFLAGS (Sep.–Nov. 2024) – See also prior Talk:Sino-Soviet border conflict#Belligerents flags.

Pretty stale but not "concluded":

• RfC needed on issue raised at Misplaced Pages talk:Manual of Style/Biography/2024 archive#British peer titles in infoboxes (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 MOS:BIO, MOS:INFOBOX, 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 MOS:JOBTITLES revision RfC needs to be drafted, based on Misplaced Pages talk:Manual of Style/Biography/2023 archive#JOBTITLES simplification proposal (Dec. 2023 – Jan. 2024, archived without resolution). JOBTITLES remains a point of confusion and conflict, which the guidelines are supposed to prevent not cause.
• Misplaced Pages talk:Naming conventions (companies)#Use of comma and abbreviation of Incorporated – Involves MOS:TM (plus WP:COMMONNAME, WP:OFFICIALNAME, WP:POLICYFORK). 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.
• Misplaced Pages talk:Manual of Style/Islam-related articles#NPOV usage of "the prophet Muhammad" or "the prophet" – Involves MOS:HONORIFIC, MOS:DOCTCAPS, WP:NPOV, WP:CHERRYPICKING, 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.
• Misplaced Pages talk:Manual of Style/Tables#Proposal to discourage vertically oriented ("sideways") column headers – Specifically in tables, possibly elsewhere. MOS:UNITNAMES (at the table "General guidelines on use of units") has an example of existing use that is being challenged, and material at Help:Table is also at issue. (Dec. 2023 –) Result: Still unresolved.
• Help talk:Table/Archive 9#Indenting tables – Help page is conflicting with MOS:DLIST and MOS:ACCESS on a technical point. (Aug. 2023 – Jan. 2024) Result: No objection to fixing it, and a suggestion to just do it WP:BOLDly, but the work actually has to be done.

Capitalization-specific:

Move requests:

• Talk:Three wishes joke#Requested move 25 December 2024 – Should the disambiguation page use title case?
• Talk:Minsk District#Requested move 25 December 2024 (116 Belarus districts) – Lowercase "district"?
• Talk:Aizkraukle District#Requested move 23 December 2024 (26 Latvian districts) – Lowercase "district"?
• Talk:LANCO (band)#Requested move 21 December 2024 – Drop the all-caps?
• Talk:City Line (Merseytravel)#Requested move 18 December 2024 – Lowercase "Line"?
• Talk:Tri-State tornado outbreak#Requested move 18 December 2024 – Was this a "Tri-State tornado outbreak" or a "tri-state tornado outbreak"?
• Talk:The Desert Rats (film)#Requested move 3 December 2024 – Does that capitalization of "Rats" distinguish the film from the UK military division?
• Talk:Island Cove (Cavite)#Requested move 17 December 2024 – Should this be called the Island Cove POGO Hub or Island Cove POGO hub?
• Talk:International Day To Combat Islamophobia#Requested move 16 December 2024 – Lowercase "To"?
• Talk:North Yemen Civil War#Requested move 28 November 2024 – Lowercase "civil war"?

Other discussions:

• Talk:Fullbore target rifle#Major rework – Is it too risky to ask people who are carrying firearms to use lowercase?
• Misplaced Pages talk:Article titles#Request for comment on the relationship between WP:CRITERIA and WP:TITLEFORMAT
• Talk:Dorothy Kilgallen#Capitalization of the word mass – "her funeral Mass" vs "her funeral mass"
• Talk:Julian (emperor)#Capitalization of "emperor" – should "emperor" be capped when referring to a specific person?
• Misplaced Pages talk:Naming conventions (ethnicities and tribes)#Indigenous – continuation of an RM discussion on capitalization of "indigenous"
• Talk:War on terror#Capitalisation of "global war on terrorism" in prose
• Misplaced Pages talk:Manual of Style/Music#THEBAND disambiguators – what to do about "The" in parenthetical disambiguators?
• Talk:F1NN5TER#Capitalization – Should the online persona be called "F1NN5TER", "F1nn5ter" or "Finnster"?
• Talk:Union Jack#Case consistency – Union Flag, or Union flag?
• Misplaced Pages talk:Naming conventions (geographic names)#Capitalisation of "oblast" when used as the name of a Ukrainian administrative division – May affect other administrative divisions (e.g. raion) and other nations for which such terms are used

Pretty stale but not "concluded":

• Talk:Upstate New York#Other plausible capitalization issue – Capitalization of "Upstate" New York.
• Talk:Southern Italy#Lowercase or uppercase? – Capitalisation of "southern". Also "northern" and "central" in related articles.
• Misplaced Pages talk:Naming conventions (capitalization)#Capitalization of geologic names – Despite being opened on an NC talk page, this is about usage in general not just in our article titles.
• Talk:Fall of Saigon#Names section and capitalisation – capitalisation of Vietnamese language names and capitalisation of their English translations?

Concluded

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

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, 18:18, 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 18:18, 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?

• It may be a case of Amygdala hijack. A bit of good old British humor might help. DON'T PANIC, don't PANIC, don't panic!!!!
• It may be fomo. Help, this Template:Calculator is too complex for me, I am just an editor of fixed text. I won't be able to do this kind of stuff! The computer nerds are taking over WP, panic, panic, panic!!! Same solution: DON'T PANIC, don't PANIC, don't panic!!!!
• It may be limited Math skills, leading to a false WP:OR claim. See Talk:Body_roundness_index#c-Zefr-20241014181200-Uwappa-20241014080100 and Template_talk:Body_roundness_index#c-JMF-20241020193300-Zefr-20241020192100. Credits to user JMF for seeing the logic in

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

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

to get $${\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)

• 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., 1, 2, 3). If DATECOMMA applies to ranges, then this uninspiring back-and-forth can take a rest as the changes are obviously helpful. Hyphenation Expert (talk) 20:57, 8 November 2024 (UTC)

  I mean... I don't think those edits are incorrect personally. Hey man im josh (talk) 21:15, 8 November 2024 (UTC)

Sad to say, under MOS as it stands, the IP's changes are correct. I just think it's stupid to bother. 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.