Jump to content

Wikipedia talk:Manual of Style

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:MOSTALK)

Welcome to the MOS pit


    Style discussions elsewhere

    [edit]

    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

    [edit]

    (newest on top)

    Pretty stale but not "concluded":

    Capitalization-specific:

    This section is an excerpt from Wikipedia talk:Manual of Style/Capital letters § Current.[edit]

    Move requests:

    Other discussions:

    Pretty stale but not "concluded":

    Concluded

    [edit]
    Extended content
    This section is an excerpt from Wikipedia talk:Manual of Style/Capital letters § Concluded.[edit]
    Capitalization-specific:
    2023
    2022
    2021

    Possessives and premodern figures

    [edit]

    Please forgive me for broaching one of the subjects with dozens of previous discussions linked in the header, but this has been bugging me and it seems major enough to be a source of consistent confusion and discrepancy. Generally, articles about classical figures (or at least that's the most helpful scope I can ascertain) with Greco-Latin names ending in S like Archimedes seem to consciously diverge from MOS:'S. It seems to be a real problem, as these are among the most prominent examples of what the aforementioned guideline is meant to cover. As we seem rather unlikely to happen upon a well-defined exception for the MOS, what are we meant to do here? Remsense ‥ 论 12:15, 14 September 2024 (UTC)[reply]

    are you referring to adding an S after the apostrophe, or to using U+0027 ' APOSTROPHE rather than U+2019 ’ RIGHT SINGLE QUOTATION MARK? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:15, 15 September 2024 (UTC)[reply]
    The former, sorry. Archimedes' versus Archimedes's. Remsense ‥ 论 02:09, 16 September 2024 (UTC)[reply]
    Why should it have anything to do with the date of the subject? We do not change our language to classical Greek to talk about Archimedes; why should we change it in other ways?
    But now I'm wondering about a different issue. A possessive 's or s', at least the way I would speak it, is voiced, more like a z. So is the way I would normally pronounce the s at the end of the name Archimedes. If I were more stuffy about Greek pronunciation (remembering that scene from Bill and Ted) it might be different. But for some reason, some other names ending in vowel-s (including Moses and Jesus) end with an unvoiced s for me. If I spell the possessive "Moses' " and pronounce it "Mozəz", I am substituting the final consonant rather than merely dropping a repeated consonant. But if I spell it "Moses's", and pronounce it "Mozəsəz", it seems more logical to me because I am still pronouncing both the name and the possessive the way I would expect to.
    Which is to say that I think the use of s' vs s's could reasonably be based on pronounciation rather than orthography or chronology. —David Eppstein (talk) 07:17, 16 September 2024 (UTC)[reply]
    No trailing S seems the more common style in sources in those contexts, which has recently been gestured to on Archimedes' heat ray as to why it is conventional here. I don't agree with that at all, but it's an argument—one that seems to be directly contradicted by existing consensus, which is why I'm a bit flummoxed.
    I also disagree with the phonology argument, as that is surely something that varies by accent and likely cannot be clearly distinguished in many cases. Remsense ‥ 论 07:21, 16 September 2024 (UTC)[reply]
    There are two distinct issues.Correct grammar calls for dropping the S only after a plural ending in S. A singular ending in S has an 's possessive form.
    The other issue is what Wikipedia's policy is or should be. That, presumably, is driven by WP:RS. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:14, 16 September 2024 (UTC)[reply]
    Not really, as citation or quotation isn't the same thing as transcription: we're fully capable of diverging in style from our sources (in many cases we are expected to) because it obviously doesn't affect the meaning of the claims. Remsense ‥ 论 09:16, 16 September 2024 (UTC)[reply]
    It's generally observed that Jesus and Moses do not take the apostrophe s, to avoid the ziz ziz sound: so Jesus' and Moses'. (Tangent: Suppose there are several people called Jesus, who collectively own something - it would be the Jesuses's.) However it is not generally considered categorically wrong. I forget what MoS says. All the best: Rich Farmbrough 20:26, 28 September 2024 (UTC).[reply]
    Sounds a bit too much like Azazel. MORE THAN A COINCIDENCE??? EEng 17:44, 16 October 2024 (UTC)[reply]
    We should absolutely not return to making exceptions on this. Major style guides like Chicago (the one most of MoS is based on) have abandoned this stuff, and those that do or used to make exceptions for it never offered consistent exceptions, nor reasons for any that were consistent between style guides, consistent with principles within the same style guide, or even consistent with actual linguistic and pyschological facts, but just confused rationalizations offered in defense of contradictory "traditions". PS: Actual oral pronunciation of something like "Jesus's" or "Jesus'", as you like, varies entirely by dialect and often by other factors (habituation within a particular subculture, like a specific church commnity, etc). — SMcCandlish ☏ ¢ 😼  02:18, 26 October 2024 (UTC)[reply]
    I'll just bluntly ask: "if I start changing this in highly visible articles, how much pushback will I get"? I don't want to step on peoples' toes, but I also think the current disconnect between many important articles and what policy plainly says is a problem. Remsense ‥ 论 02:27, 26 October 2024 (UTC)[reply]

    Formatting of captions

    [edit]

    I propose this rule:

    • However, if any complete sentence occurs in a caption, then every sentence and every sentence fragment in that caption should end with a period.

    should be complemented by this:

    • For sentence-fragment captions, if other punctuation occurs, then that caption should also end with a period.

    See example at John Vivian, 4th Baron Swansea. It seems weird to me to have every other punctuation – but not the very last. HandsomeFella (talk) 19:14, 23 September 2024 (UTC)[reply]

    That's not the sentence in the article; remove the extraneous or. The proposal sounds reasonable at first glance but could use a strong justification. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:39, 23 September 2024 (UTC)[reply]
    So if a caption includes a harmless comma or dash, it must end in a period? I don't think that would be an improvement. Our current rule is simple and consistent and I can't see a good reason for such a change. Gawaon (talk) 08:39, 26 September 2024 (UTC)[reply]
    A sure way to distress readers and editors would be to punctuate captions that aren't sentences with periods, as if they were sentences. That would be very weird indeed, and lead to reverts of insertions of periods or to expansions of captions into weighty sentences, which would then be reverted, and the disruption would continue until the MOS change was reverted. NebY (talk) 15:20, 26 September 2024 (UTC)[reply]
    Agreed with "don't think that would be an improvement" and "would be very weird indeed", and the potential for WP:BIKESHEDDING and WP:DRAMA across a large number of pages (most any with illustrations, really).  — SMcCandlish ☏ ¢ 😼  02:05, 26 October 2024 (UTC)[reply]

    Proposed astronomy MoS

    [edit]

    We have put together a proposed MoS article for the subject of astronomy, located here: MOS:ASTRO. Is there an approval process that needs to be followed to have it be included on the {{Style}} template? I.e. to have it added to the 'By topic area' under 'Science'. I just want to understand the steps. Thank you. Praemonitus (talk) 17:32, 24 September 2024 (UTC)[reply]

    New shortcut: WP:ASTROSTYLE.  — SMcCandlish ☏ ¢ 😼  09:54, 21 November 2024 (UTC)[reply]
    Hmmm… It covers a few things that are not really Style issues. Perhaps it should be entitled WP:ASTRO not MOS:ASTRO? Blueboar (talk) 20:28, 27 September 2024 (UTC)[reply]
    Oh, okay. Well I suppose it's more of a guideline then. Thanks. Praemonitus (talk) 02:04, 28 September 2024 (UTC)[reply]
    Quick question..... this is being presented by a Wikiproject? I assume there's more than just four people at the project and that this is currently the norm for these type of pages? Moxy🍁 02:34, 28 September 2024 (UTC)[reply]
    All I was asking for was the procedure. It is in regards to WP:AST. Thanks. Praemonitus (talk) 04:51, 28 September 2024 (UTC)[reply]

    It is relatively uncontroversial for WikiProjects to develop suggestions for article content and to label it as an essay, and does not require a formal RfC and encyclopedia-wide consensus; for a recent example see Wikipedia:WikiProject Numbers/Guidelines. Making something a binding guideline on the whole encyclopedia is a much bigger thing, and probably would require buy-in from a much wider pool of editors through a formal RfC advertised at the Village Pump etc. If you are going to call it a Manual of Style it should be limited purely to style and not content or referencing, and be more phrased as clear formatting rules than as vague "you should consider this kind of source for this kind of content" suggestions. Also, I tend to think that suggestions like "The accuracy of the image should be confirmed by an astronomy expert" go far beyond usual Wikipedia norms where we rely on verifiability through sourcing rather than credentials and personal expertise. —David Eppstein (talk) 06:09, 28 September 2024 (UTC)[reply]

    Thank you, David. Praemonitus (talk) 14:38, 28 September 2024 (UTC)[reply]
    @Praemonitus: You shouldn't refer to something like this as a "guideline" unless and until it has been through the WP:PROPOSAL process (usually at WP:VPPOL these days). This usually entails significant revision after community input, because WP:Writing policy is hard. Something like this is (presently) a WP:PROJPAGE essay, and should be tagged as such, with {{WikiProject style advice}} or if so much of it isn't style matters then {{WikiProject advice}}. And it should be at Wikipedia:WikiProject Astronomy/Style advice since it is not part of the MoS. If a proposal process were successful, it would move to WP:Manual of Style/Astronomy and take shortcuts like MOS:ASTRO. Please do not pre-emptively create "MOS:..." shortcuts to things that are not part of the MoS guidelines; this just confuses people and leads to conflicts (especially people claiming that some four-author page with no community buy-in has the force of a guideline when it does not).  — SMcCandlish ☏ ¢ 😼  02:01, 26 October 2024 (UTC)[reply]
    Thank you for your input, SMcCandlish. Praemonitus (talk) 02:28, 26 October 2024 (UTC)[reply]

    9×19mm Parabellum

    [edit]

    Should this be capped? All the best: Rich Farmbrough 20:12, 28 September 2024 (UTC).[reply]

    It was apparently registered as a trade mark (not an RS but see here) which would be good reason to cap. Ngrams indicate some mixed usage but not enough to argue lowercase, even though it is probably passing into lowercase usage. Cinderella157 (talk) 00:50, 29 September 2024 (UTC)[reply]
    Gonna attempt to contribute something, for lack of input, based on cursory background reading of cartridges in the past:
    If "Parabellum"'s popularity is equivalent to lowercase, then perhaps the same can be argued for "Winchester" or even "NATO" (or "Nato" or "nato", I've seen in forums?) -- does that make any sense? (I'd say the only reason "Winchester" always stays capitalized is that it's already a proper name in English, and then seeing "Nato" might be more about avoiding online shouty-case.) You could make a better claim that this is something like a genericized trademark if the generic term "parabellum" were applied to cartridges other than the specific original 9x19mm pistol cartridge (or the other specific Parabellum cartridges) (and not simply identical/compatible cartridges by different manufacturers). SamuelRiv (talk) 23:11, 16 October 2024 (UTC)[reply]
    If it's a trademark (and not legally declared, across multiple major pertinent jurisdictions, to have become genericized, like "asprin"), then it takes capitalization, per MOS:TM, at least when used for the subject of the trademark. The term "genericized trademark" actually has a specific legal meaning and is frequently misused; it does not mean "sometimes used by random people as a stand-in for a class of products instead of a specific famous one, or used metaphorically and sometimes with the spelling changed"; "Kool-Aid" and "Band-Aid" are not genericized trademarks, no matter how often someone might write "Don't drink the koolaid" or "That solution would just be a bandaid". SamuelRiv's point is reasonable about "parabellum" sometimes being used for aftermarket products, to mean basically "Parabellum-compatible" or "Parabellum-equivalent" or less flatteringly "Parabellum-knockoff", but that usage is probably too imprecise and marketing-PoV for WP to be using in the first place.

    As for "Nato", that style was originated by some news publishers with a strange "dumb it down" house style of always writing acronyms pronounced like words (instead of spelled out) as if they are words and not acronyms/initialisms (they do "MI5" and "FBI", but "Unicef" and "Nasa", and also farcically do "Aids" in reference to the disease, despite it not being a proper name and other diseases not being capitalized - they don't write "Tuberculosis" or "Myeloma"). That this silly and confusing and inconsistent style has spread to forums and social media, which essentially have no style norms other than idiosyncratic senses of expediency, is not surprising, but it's not related to the "Parabellum" question, or to WP style (we do "AIDS" and "UNICEF", per MOS:ACRO).  — SMcCandlish ☏ ¢ 😼  00:50, 26 October 2024 (UTC)[reply]

    The insert box beneath the edit window

    [edit]

    In the Common mathematical symbols section, we suggest using the insert box beneath the edit window, the edit toolbox under the edit window, in the "Math and logic" section of the edit toolbox, and in the "Insert" section of the edit toolbox, which many editors no longer have, or not usually. Assuming it's still present for enough editors to be worth mentioning, can we qualify that briefly so as not to leave many editors lost and confused? NebY (talk) 19:54, 7 October 2024 (UTC)[reply]

    @NebY: This is the "charinsert" gadget, which is enabled by default for all users and all skins, and if people no longer have it, they've been to Preferences → Gadgets and disabled the "(D) CharInsert: add a toolbar under the edit window for quickly inserting wiki markup and special characters (troubles?)" option. --Redrose64 🌹 (talk) 21:02, 7 October 2024 (UTC)[reply]
    I have that gadget enabled. NebY (talk) 21:22, 7 October 2024 (UTC)[reply]
    What about the mobile app users? I would assume this gadget is not available to them. Do they have some equivalent? It does seem that this text should probably be adjusted to account for different user-experience paths.  — SMcCandlish ☏ ¢ 😼  00:52, 26 October 2024 (UTC)[reply]
    [edit]

    I have been encountering ongoing issues with User:Skitash, while I respect some of the work they have done on certain pages, they appear to have a significant bias when it comes to articles related to the Amazigh/Berber ethnic group.The first issue involves multiple pages specific to Berber history, such as Maghrawa and Banu Ifran. When I added the language tag in the lead per WP:LEADLANG for Tamazight/Berber, my edits were reverted by User I made sure to retain the foreign language , which shouldnt even be done, WP:FORLANG, in Arabic, even though it was uncited. User:Skitash justified their reversion of the Tamazight language inclusion by citing Wikipedia:No original research, despite the fact that the word "Banu Ifran" was cited twice for its tamazigh translation. The reason given was that the writing system (Neo-Tifinagh) "wasn’t used back then." However, the uncited Arabic text was allowed to remain. I need clarification: Are we prohibited from adding the lead language just because the writing system was different at the time, while keeping uncited Arabic text even though it falls under WP:FORLANG? Or should both be removed entirely? Im reaching out as i would prefer to avoid an edit war.

    The second issue pertains to Wikipedia:Neutral point of view and Wikipedia:Manual of Style. On the page for Berberism, User introduced language that seemed biased, stating that the movement is closely tied to Anti-Arab racism. This was presented in a way that gave it undue weight, appearing twice on the page—once within the larger text and once in the first section on Algeria—without proper citation for the upper part. I removed the uper part, even though i believe both fully break Wikipedia:Neutral point of view , but removed the upper one as it not only breaks such but also Wikipedia:No original research, Wikipedia:Verifiability but it was reverted by him. I want to better understand the situation, whether I made an error in removing it or if Skitash’s edits were indeed problematic.

    The third issue relates to Karima Gouit and broader pages about Berbers. My understanding of Wikipedia:LEADLANG, particularly for ethnic groups with their own language and script, supports the inclusion of Neo-Tifinagh for Tamazight. However, Arabic text is used twice on these pages, while the Latinized form of Amazigh appears only once and Neo-Tifinagh is entirely absent. I need confirmation: Is it permissible to add Neo-Tifinagh, even if cited? And what about the use of Arabic, which is not the ethnic language of these ethnic groups? Returning to the issue of Karima Gouit, she is an Amazigh singer, as indicated by her public profiles outside of her wikipedia page that is fully outdated, songs, interviews, and her latest acting role. She is also a famous activist for the Amazigh cause. Skitash reverted the addition of her name in Tamazight, despite allowing the Arabic version to remain. This is in addition to the broader debate over whether to include her Berber ancestry, which two other editors argued against citing Wikipedia:Ethnicity is not notable enough for intro section, suggesting that it should only be included in the body with proper citations. Despite these discussions on the talk page, Skitash has shown little interest in further conversation even when he was the one behind the removal of the edits, and the dialogue is now largely between me and two other editors who were not initially part of the revision. But as it went on, he decided to put the page under deletion, and trying to place every "old" citation not even related to the subject as "poorly cited", I have since escalated the matter to the dispute noticeboard, but Skitash responded by filing a report against me at Wikipedia:Sockpuppet investigations/YassinRi suddenly with questionable cause, while he also has another dispute with another editor relating to inclusion of berbers in their own topics. which is outside the scope of this question, apologies but just wanted to point this out..For Karima Gouit’s page, should her name translation in her native language be included or not? And in terms of dealing with Skitash, is there a more effective way to communicate with them directly, rather than constantly involving third parties in disputes regarding Berber-related topics since he clearly oppose it? TahaKahi (talk) 13:31, 9 October 2024 (UTC)[reply]

    While you do bring up some specific style issues, I get the sense that this is mostly a content dispute. I wonder if you could cut this down to those issues where you really need help interpreting the MOS, and bring up the other issues in some other forum — see Wikipedia:Dispute resolution for help in finding such. --Trovatore (talk) 18:08, 9 October 2024 (UTC)[reply]
    I have brought it up in the Dispute resolution, it met being locked as the person that continues to try and block the Wikipedia:LEADLANG decided to put it under deletion as i mentioned earlier instead of having a conversation and trying to reach a resolution, this extented to him ignoring yet another person, who made a dispute resolution on him for yet the same subject, his disliking of anything relating to Berbers/Amazighs to be included in Berber/Amazigh related subjects, here: Wikipedia:Dispute resolution noticeboard#Algeria discussion , instead, the same person took it even further and decided to ignore it, as seen in his response to the alert made in his page when he deleted it: [1].
    I understand this matter may not reach a conclusion under MOS, but I would like clarification on one point: Can we establish a decision regarding the inclusion of Berber languages (Tamazight), which is widely spoken in North Africa, especially in Algeria and Morocco, for subjects related to their history and culture? For historical figures like Kahina or Kusaila, who are clearly Berber and not Arab or even Muslim. should they have Tamazight and its neo-script or latinized form included in their Wikipedia intros, per Wikipedia:LEADLANG? would this would apply to historical figures, kingdoms, Amazigh activists, and related topics.A clear decision on this would help prevent further edit wars. From what I've seen, other language versions of Wikipedia include Tamazight per Wikipedia:LEADLANG, but this issue persists only in the English version. It is consistently being contested by two individuals with vague reasoning, as I mentioned earlier. TahaKahi (talk) 18:37, 9 October 2024 (UTC)[reply]
    What other projects do or don't do is neither here nor there. If you have a specific question regarding a specific edit, then you use the article's talk page and make your case there. Forum shopping, casting aspersions ad misrepresenting the sources to push a POV (like you did) is not acceptable. M.Bitton (talk) 18:44, 9 October 2024 (UTC)[reply]
    I will refer to read what I said at the start of my reply which details how this didn't work, as for why this exist, its because I was referred to make one from the dispute resolution from 2 day ago. And also i would refer to your behavior in Wikipedia:Administrators' noticeboard#c-M.Bitton-20241009175700-TahaKahi-20241009175000 TahaKahi (talk) 18:50, 9 October 2024 (UTC)[reply]
    Considering that this has already landed at the AN, I don't think there's anything to be done here. Gawaon (talk) 07:37, 10 October 2024 (UTC)[reply]
    The administrator noticeboard of our topic is chaotic at the moment, as many people are involved. It seems that a resolution may not be reached, as the discussion has shifted away from the main topic to something else. I don't know the exact path to take here? I was told to see the issue with Dispute resolution, then MOS and with AN i moved back and forth. TahaKahi (talk) 07:50, 10 October 2024 (UTC)[reply]
    If it's not resolved there, it certainly won't be resolved here. This page is for discussions about improvements to the MOS, and your issue seems largely unrelated to that. You'll have to resolve it either at the talk pages of the articles in question or at the AN. Good luck. Gawaon (talk) 08:02, 10 October 2024 (UTC)[reply]
    @TahaKahi: I would add that these pages seem comparatively obscure, so resolution at the talk page of one or another of them seems unlikely, especially if it's just you and someone else arguing back and forth and reverting each other, but not coming to agreement on sources. The first issue you mentioned sounds like a source reliability dispute, and is something for WP:RSN. The second seems like a matter for WP:NPOVN. The third: Well, Karima Gouit is a red link, so I'm not entirely sure what this is about. As a general matter, it is normal and expected for an ethnic group's name for itself (or some topic that pertains especially to that group) in its own language(s) and script(s) to be represented in the lead, within reason (though sometimes in a footnote). Tamazight is a language family (or sometimes used more narrowly for a subfamily); Neo-Tifinagh is a modern standardized script (though not universally adopted) for writing those languages. If the multiple Tamazight languages are going to produce multiple distinct renditions of a name in N-T, then that will be excessive and it should all go in a footnote, especially if non-Neo versions in historical Tifinagh are also included (discouraged; that's better for an "Etymology" or "History" section). As for Arabic, it is the dominant language/script in much of the pertinent region, so is also often going to be reasonable to represent in Berber-related topics, at least broad/general ones; but if a footnote is used, then Arabic should also go in the footnote.

    I'm only getting your side of the story, but it seems that you might be meeting anti-Neo-Tifinagh or anti-Tamazight (or even anti-Berber) PoV pushing, which is likely a matter for WP:NPOVN again. If there's a really clear WP:NOR problem happening that is distinctly NOR more than NPOV or V/RS, then that particular matter might be better brought up at WP:NORN. I would advise trying to resolve one issue at a time, not starting 2 or 3 noticeboard threads. But anyway, virtually none of this is really an MoS matter, except trivially and incidentally. My quick trawl through various articles related to the Berber people and languages shows a great deal of PoV-laden and otherwise unencyclopedic language, so a more focused cleanup effort needs to be engineered, perhaps through asking for help at any of these noticeboards in the course of trying to resolve issues thereby, and by asking for help at any of the pertinent wikiprojects listed in the wikiproject banner shell at the top of Talk:Berbers (Berbers, Ethnic groups, Africa and pertinent national taskforces/workgroups thereof, Morocco, Tunisia, Egypt, and Algeria; if it's a language-specific matter, maybe also Linguistics, and Languages; maybe also Guild of Copyeditors, though they are swamped).  — SMcCandlish ☏ ¢ 😼  00:36, 26 October 2024 (UTC)[reply]

    Examples to clarify MOS:AFFIXDASH vs MOS:DUALNATIONALITIES (especially re: combining forms)

    [edit]

    Good morning,

    In editing an article, I discovered an issue I realised isn't very clear from the existing examples given in MOS:AFFIXDASH and MOS:DUALNATIONALITIES, and this recalled an earlier debate I'm still unsure about.

    The multi-compound in question was "Afro-Peruvian-American" on the page Afro–Latin Americans. Now, this could probably just be rendered "Afro-Peruvian American" to avoid the issue altogether, but I thought it best to find out what's actually right and to get a clarifying example or two on here if we can, to settle future debates.

    Over at Afro–Puerto Ricans, I was told the en dash is correct in that title page, even though "Afro-" is a combining word rather than a non-standalone prefix. This was a little confusing, because MOS:DUALNATIONALITIES gives a similar example where this isn't the case specifically because of a combining form:

    "Wrong: Franco–British rivalry; Franco- is a combining form, not an independent word, so use a hyphen: Franco-British rivalry."

    Obviously, "British rivalry" isn't an open compound, so I recognise this example may not be wholly applicable, but it seems to me that the article is calling out combining forms as different to standard affixes. If true, the combining form might essentially make "Afro-Puerto Rican" a single thing, meaning you would only use the en dash if you added a prefix to that (such as for "anti–Afro-Puerto Rican"). (Merriam-Webster suggests they're slightly different things too: https://www.merriam-webster.com/grammar/spelling-using-compound-words-guide/prefixed-suffixed-and-combining-form-compounds.)

    The argument given against that view was essentially that MOS:AFFIXDASH always applies, even for combining forms, and thus because "Latin America" is an open compound, the "Afro-" should be joined with an en dash. I'm still not wholly sure if that's right, simply because all the examples under MOS:AFFIXDASH use prefixes and suffixes which are non-standalone (i.e., non-combining forms), and the section doesn't seem to comment specifically on combining forms. And "Afro-" like "Franco-" seems to me to be subtly different to a prefix like "trans-", "pre-" or "post-".

    So, in short: if "Afro-Latin Americans" and "Afro-Puerto Ricans" are correct, then can we mention that MOS:AFFIXDASH doesn't apply to combining forms? And if they're wrong, and we should use "Afro–Latin Americans" and "Afro–Puerto Ricans", can we get some examples at MOS:AFFIXDASH that use combining words too? That would neatly clarify the situation without too much extra verbiage.

    And finally, given the answer to the above, should I also change "Afro-Peruvian-American" to "Afro-Peruvian–American" or "Afro-Peruvian American" (or even "Afro–Peruvian-American"/"Afro–Peruvian American")?

    I hope this makes sense! (I care a little bit too much about punctuation, it seems.) Lewisguile (talk) 08:25, 11 October 2024 (UTC)[reply]

    Any thoughts on this? I archived my other (settled) query so this one is more visible. Lewisguile (talk) 08:09, 14 October 2024 (UTC)[reply]
    @Lewisguile: "Afro–Puerto Ricans" with an en dash is wrong; the quite specific rule is that combining forms (typically prefixes) take a hyphen. This particular case is going to be potentially confusing to someone somewhere, regardless what kind of horizontal puctuator is used, because the prefix is being attached to a two-word proper name that, being a proper name, does not take internal hyphenation. "Franco-Austrian" doesn't have that problem, but "Russo-Sri Lankan" would, and it would be better the rephrase when practical, e.g. in "Russia–Sri Lanka trade relations" or "trade relations between Russia and Sri Lanka". For "Afro-Puerto Ricans", an alternative like "Puerto Ricans of African descent" might be awkward sometimes but preferable in others. Just because some such terms are conventional, as in "Afro-Cuban" and "Afro-Brazilian", doesn't mean that every possible construction of this sort is mandatory to use. (And "Afro-American" has fallen into explicit disuse.) PS: On the last question, it would be "Afro-Peruvian-American" as an adjective ("an Afro-Peruvian-American singer"), but "Afro-Peruvian American" as a noun phrase. An en dash is not used at all in such a construction, even a shorter one. No one is "Japanese–British". Such a string indicates a relationship (be it collaborative or conflicting) between Japan and Britain as nations, cultures, geographic regions, or governments.  — SMcCandlish ☏ ¢ 😼  00:03, 26 October 2024 (UTC)[reply]
    That was my belief, too, but when I raised it over at the page now named Afro–Puerto Ricans, I faced vigorous disagreement. I have updated the examples and the guidance text here. Please let me know what you think?
    Similarly, this means we probably need to rename the pages which were recently changed to have an en-dash, including Afro–Latin Americans and a few others? But if others are happy with my recent tweaks to the MOS:AFFIXDASH section, then I should be able to request a move on those with a link back here now it's clearer. Lewisguile (talk) 06:56, 26 October 2024 (UTC)[reply]
    Only if the person is an American of African and Peruvian heritage, rather than someone with all three contemporary nationalities. MapReader (talk) 13:30, 26 October 2024 (UTC)[reply]
    Agreed. All three heritages together would presumably be "African–Peruvian–American", since they're all equal? Probably also a good example to include. Lewisguile (talk) 13:46, 26 October 2024 (UTC)[reply]
    I must admit I don't really get the logic behind the new rule now added to the MOS. If "ex–prime minister" is correct, why is "Afro–Puerto Rican" wrong? The text talks about "Combining forms" but what's that and why is "Afro-" more combining than "ex-"? Right now I would have no idea how to distinguish a combining prefix from a non-combining one (if there's such a thing, which I doubt). Gawaon (talk) 08:23, 26 October 2024 (UTC)[reply]
    According to the Chicago Manual of Style, a combining form + open compound gets an en dash.

    the word something ... is a combining form that connects to other words with a hyphen, as in "twenty-something years old." When joined to the open compound "two hundred," it gets an en dash in Chicago style

    I boxed up two hundred–something widgets. Hyphenation Expert (talk) 08:45, 26 October 2024 (UTC)[reply]
    So I find the carve-out added to MOS for combining forms needless. Hyphenation Expert (talk) 08:50, 26 October 2024 (UTC)[reply]
    Right, you don't agree with the change and I can't agree with it either simply because I don't understand it. So we have no consensus here and I'll revert the change until consensus is reached. Gawaon (talk) 08:58, 26 October 2024 (UTC)[reply]
    The Chicago MOS is using "combining form" in a manner that isn't consistent with how we've used it earlier under MOS:DUALNATIONALITIES. As per the examples under Dual Nationalities, the difference is that "Franco-" (as explained above) is a combining form of "France", just as "Afro-" is. "Ex-" isn't a combining form. The specific overrides the general, so you don't split the combining form with an en dash.
    Combining forms like "Afro-", "Franco-" and "Russo-" are fundamentally different to affixes like "ex-", "post-", "pre-", etc. I'm not sure how to best explain because it seems self-evident to me, but I'll try. The former can be rendered as standalone words which don't need hanging hyphens, whereas the latter usually can't because they're just modifiers; their purpose is to modify but not really to exist on their own. (Yes, in colloquial usage we might say "my ex[-partner]", "I'm pro[-this] or "I'm anti[-that]", but we're always implying another word there that those affixes modify. "France" doesn't have to do that.)
    "Ex–prime minister" is different because "ex-" isn't a combining form and "prime minister" is a compound with a space. "Puerto Rican" is a compound with a space but "Afro-" is a combining form. Hence, the specific rule overrides the general rule. Lewisguile (talk) 09:43, 26 October 2024 (UTC)[reply]
    I think your explanation is a bit confused. Neither "Afro", "Franco" nor "post" (in that sense), "pre" can be used in their own. They are all only usable as prefix. But I suppose what you meant is that "Afro-", "Franco-" and "Russo-" are "combining forms" of words that can be used on their own (African, French, and Russian). Granted that, where exactly in CMOS does it say that these combining forms always take a hyphen instead of an en dash? If they have such a rule, I wasn't able to find it. Gawaon (talk) 10:23, 26 October 2024 (UTC)[reply]
    It's in MOS:DUALNATIONALITIES. For "Franco-British", it calls combining forms out as exceptions. As for the rest: yes, that's what I was trying to say! Thanks for clarifying. Lewisguile (talk) 10:46, 26 October 2024 (UTC)[reply]
    However, "Franco-British rivalry" takes a hyphen because both parts are just one word. "Franco–British" is just as incorrect as "ex–wife" would be. But if "ex–prime minister" is correct, why should "Afro–Latin American" be wrong? It still doesn't make sense to me, and I think unless there is precedent in major style guides (preferably several of them) we should not add this complication and leave MOS:AFFIXDASH as it is. Gawaon (talk) 11:03, 26 October 2024 (UTC)[reply]
    "Franco–British rivalry" isn't called out as incorrect because they're both one word; it's called out as incorrect specifically because of the combining form. I.e., the combing form is an exception.
    Prime minister doesn't include a combining form, so "ex–prime minister" is fine. Lewisguile (talk) 14:03, 26 October 2024 (UTC)[reply]
    See below for my reply. Gawaon (talk) 17:55, 26 October 2024 (UTC)[reply]
    I'm very surprised with SMcCandlish's comment that says "Afro–Puerto Ricans" is incorrect, but I don't see a clear consensus at this point. It looks like Gawaon and Hyphenation Expert are not agreeing with that, and Hyphenation Expert said the CMOS supports an en dash (although I haven't found exactly where – can someone provide an exact quote?). I note that SMcCandlish didn't comment in the RM at Talk:Afro–Puerto Ricans#Requested move 7 August 2024. So far, I don't see an indication of a consensus to overturn that. (I'm also surprised with the Lewisguile assertion that "ex-" is not a combining form.) —⁠ ⁠BarrelProof (talk) 17:30, 26 October 2024 (UTC)[reply]
    Regarding CMOS, I haven't been able to find anything there that would carve out an exception for "combining forms" to be treated differently from other prefixes (that is, they suggest treating "Afro-" exactly as "pre-" for all I know). I was unable to find any rule to the contrary and my request for a reference has gone unanswered so far. Regarding the reference to MOS:DUALNATIONALITIES, that's a total red herring, since that section simply does not discuss the use of affixes with open compounds (compounds that themselves include a space). Gawaon (talk) 17:52, 26 October 2024 (UTC)[reply]
    I think you and Hyphenation Expert are both saying "Afro-" is the same as "pre-" (or "ex-"), suggesting "Afro–Puerto Ricans", "pre–World War II" and "ex–prime minister". And Hyphenation Expert is saying the CMOS agrees. But this seems to differ from SMcCandlish's view. —⁠ ⁠BarrelProof (talk) 18:11, 26 October 2024 (UTC)[reply]
    If there's no consensus on what the right answer is, that at least suggests we need clarity.
    I'm not opposed to leaving Afro–Puerto Rican as it is (in my mind, we already discussed that and there wasn't support for a hyphen instead of an en dash), but I'd rather the examples in MOS make it clear what should happen here so we don't run into the same problem further down the line.
    So if my suggestions above weren't helpful (and the text has been reverted, so I assume they weren't), can we agree some text that is helpful and which affirms the status quo? E.g.:
    • Afro–Puerto Rican
    • Wrong: Afro-Puerto Rican
    My concern isn't to be nitpicky or difficult here. I just really think we need clear and unambiguous guidance so that when I see something like "Afro-Peruvian American", I know whether I'm using an en dash, hyphen, etc. Lewisguile (talk) 19:07, 26 October 2024 (UTC)[reply]
    Sure, adding "Afro–Puerto Rican" as another example to MOS:AFFIXDASH would be fine with me. "Afro-Peruvian American" seems a different case, however, since I suppose it means "American of Afro-Peruvian" descent? So in that case, "Afro-" refers only to "Peruvian" rather than to "Peruvian American", hence the hyphen is correct. (In contrast, an Afro–Puerto Rican is not a Rican of Afro-Puerto descent, as the use of a hyphen would suggest.) Gawaon (talk) 20:17, 26 October 2024 (UTC)[reply]
    I think this depends on whether the combination of Afro, Peruvian and American is an adjective or a noun. I think a person could be "an Afro-Peruvian-American scientist", but a group of people who are Americans of Afro-Peruvian descent would be "Afro-Peruvian Americans". —⁠ ⁠BarrelProof (talk) 20:32, 26 October 2024 (UTC)[reply]
    I agree with these.
    Probably the more seamless way to add to the MOS is not with a new "Afro-" example, but next to the existing "Franco-" example. I.e., following Franco-British rivalry with a note that, if used with an open compound, it's Franco–South Korean rivalry again, not Franco-South Korean rivalry. Hyphenation Expert (talk) 21:04, 26 October 2024 (UTC)[reply]
    But we're talking about MOS:AFFIXDASH, while the "Franco-" example is in MOS:DUALNATIONALITIES. Gawaon (talk) 21:58, 26 October 2024 (UTC)[reply]
    And this issue logically belongs into AFFIXDASH, whose core rule (section header) says: "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" (emphasis added). While DUALNATIONALITIES also calls for en dashes (exceptions excepted), it does so for unrelated reasons – which has contributed to the confusion here, I think. Gawaon (talk) 22:05, 26 October 2024 (UTC)[reply]
    I agree it should go in AFFIXDASH. I'd be happy adding a more complex example like Afro-Peruvian American too, for ultimate clarity. Though that one likely needs more space than Afro–Puerto Rican. Maybe the former should come at the end of that section, since it covers both AFFIXDASH and an example, as in DUALNATIONALITIES, where the combining form makes the first part one word, so it's trickier. If it's at the end, the extended text doesn't disrupt the other examples. Lewisguile (talk) 22:30, 26 October 2024 (UTC)[reply]
    I've added "Afro–Puerto Rican" as another example to AFFIXDASH. "Afro-Peruvian American" doesn't belong there (except possibly as a negative example), since it doesn't have a dash. Conceivably it could go into DUALNATIONALITIES, but as it seems a straightforward application of the rules that are already there, I don't think it's needed. Gawaon (talk) 09:53, 27 October 2024 (UTC)[reply]
    Thanks. I meant as a negative example in the case of "Afro-Peruvian American", since I can see people defaulting to "Afro–Peruvian American". But it's admittedly much rarer than "Afro–Puerto Rican" or "Afro–Latin American", so we can always cross that bridge when we get to it. Lewisguile (talk) 08:13, 28 October 2024 (UTC)[reply]

    Relatedly, I recently ran into an editor who refused to believe that "Korean-American" (in adjectival form) could be a case of MOS:DUALNATIONALITIES, insisting instead that because there was no country named Korea that the "Korean-" part of this must be an ethnicity rather than a nationality. Which was incorrect, as in this case "Korean-" was intended as a shorthand for South Korean, which perhaps should have been spelled out more explicitly. But in cases like this where one of the nations has a space in the name, should we still hyphenate it as "South Korean-American" or do we need to spell it out, for instance as "South Korean and American"? —David Eppstein (talk) 19:19, 26 October 2024 (UTC)[reply]

    Both "South Korean–American" with an en dash en and "South Korean and American" are surely fine. But don't spell it as "South Korean-American" since that would suggest that "South" modifies "Korean-American" rather than just "Korean". Gawaon (talk) 20:20, 26 October 2024 (UTC)[reply]

    "Toponomy", "Etymology", or "Name"

    [edit]

    Hello, I'm a new user to Wikipedia and would like some clarification on an inconsistency I've noticed.

    For articles on countries, cities, regions, & other such places, it's typical that the first section after the introductory paragraphs is dedicated to the meaning & origins of the place's name. However, the title of this section varies from article to article. As three major examples, the article for England labels its first section as "Toponomy", the article for Scotland labels it as "Etymology", and the article for Ireland labels it as "Name".

    Valid arguments can be made in favor of all 3 styles. Toponymy is the most specific & accurate term; Etymology is consistent with articles on non-location subjects; Name is the simplest option.

    Should a specific term be favored? Which one should it be and why? Or is it up to individual editors' discretion? GenderBiohazard (talk) 01:45, 16 October 2024 (UTC)[reply]

    Some WikiProjects have specific recommendations - for example see Wikipedia:WikiProject_Cities/Settlements:_Article_structure#Toponymy. Nikkimaria (talk) 01:48, 16 October 2024 (UTC)[reply]
    Thank you. GenderBiohazard (talk) 01:52, 16 October 2024 (UTC)[reply]
    Amusingly, it reads: "Toponymy: This section may also be called Etymology or Name." So, full circle. "Names" also occurs, for places with more than one; I've also seen "Naming" in a few cases. Sometimes this information is not in a section devoted to it at all but is part of the lead, or is integrated chronologically into the "History" section. I'm skeptical that the average reader knows what "toponymy" means, though they'd figure it out quickly enough from the content in the section. "Etymology" would only really apply if the content in the section really did dwell on etymology. At, e.g., "New York" this probably wouldn't be applicable, since the origins of the word new and the name York are unlikely to be involved. "Name[s]" is simple and universally understood, but it might seem informal. This seems to me one of those "leave it to consensus at each article" matters.  — SMcCandlish ☏ ¢ 😼  23:47, 25 October 2024 (UTC)[reply]

    Up for north?

    [edit]

    What do we think of the colloquial practice of equating cardinal directions with conventional depictions on a map? Examples would include "down south", "up north" or even "going down to London". This last is particularly confusing as there's another convention (I think rail-based) that always says "up to London"! I would argue that such language should be avoided here; it adds no meaning and introduces a potential for confusion. It may also be too colloquial for encyclopedic purposes. What do others think? John (talk) 12:35, 21 October 2024 (UTC)[reply]

    Aside from direct quotations and titles of works, I would say that such usages are not encyclopedic phrasing. --User:Khajidha (talk) (contributions) 12:59, 21 October 2024 (UTC)[reply]
    I'll have you know that the official phrase is "darn Sarf"! Billericay Dickievans123 (talk) 13:02, 21 October 2024 (UTC)[reply]
    I think I'm a bit surprised that the MoS doesn't already have advice regarding colloquialisms? Is it time for MOS:COLLOQUIALISM? DonIago (talk) 14:31, 21 October 2024 (UTC)[reply]
    I'd say that goes without saying. In an encyclopedia, use encyclopedic language. Gawaon (talk) 16:34, 21 October 2024 (UTC)[reply]
    Ah, MOS:TONE mentions colloquialisms, so I think this falls under that umbrella. DonIago (talk) 16:44, 21 October 2024 (UTC)[reply]
    Yes, and there are orders of magnitude too many colloquialisms that wouldn't be appropriate in an encyclopedia for us to address random ones like this individually. We address very few of them in specifics, and only when they are endemically habitual in casual writing and thus produce a lot of cleanup to do (e.g. MOS:CONTRACTIONS, MOS:YOU).  — SMcCandlish ☏ ¢ 😼  23:37, 25 October 2024 (UTC)[reply]

    "Perhaps the most..."

    [edit]

    I'm seeing a lot of articles using this sort of wording and I don't like it! To take just one random example, "Prague was perhaps the most important center for Cubism outside Paris before the start of World War I." (Czech Cubism), the 'perhaps' seems weaselly and/or POV. It also reads like an editorial rather than an encylopedia entry.

    I think either "Prague was an important center for cubism", or "Prague was the most important center for cubism", or "so-and-so called Prague 'The most important center for cubism'" (whichever the sources support) would be infinitely better in most cases of 'Perhaps the most|best|biggest|' etc.

    However, I can see a LOT of articles using this sort of construct, I wanted to just start a discussion here to see if it's being left alone for a good reason, or if I'm right that this is an example of WP:WEASEL before I embark on modifying loads of articles to fix something that only I have a problem with!

    Thanks,

    JeffUK 14:03, 23 October 2024 (UTC)[reply]

    It certainly has the potential to be used in a weaselly way, but like other such formulations, it is fine if the statement accurately reflects the source. If a source states that Prague is arguably the most important centre for cubism outside Paris, that is the nuance the article should reflect. There is ambiguity in the world, and good sources reflect that. In many cases the wording might be better replaced with something else, but I think it would have to be evaluated case by case.--Trystan (talk) 14:35, 23 October 2024 (UTC)[reply]
    I agree this would be better honed down to a specific claim like "Prague was widely regarded as second only to Paris as a center for Cubism"<source>. It's the "perhaps" that jars; like the topic above, MOS:TONE would seem to recommend against language like this. Yes, we should reflect the uncertainty that exists within and between sources, but I don't think this is what "perhaps" does. John (talk) 16:16, 23 October 2024 (UTC)[reply]
    There are a lot. Simple searches show 2,198 articles using "perhaps the best" and 658 "possibly the best", but "perhaps the most" with 9,890 articles is possibly the worst. NebY (talk) 17:01, 23 October 2024 (UTC)[reply]
    • I strongly disagree with this point. Certainty may be achievable in chemistry, but it just isn't in the humanities, & it absolutely necessary that we indicate this to our readers where appropriate. Unfortunately some editors don't get this. Johnbod (talk) 18:10, 23 October 2024 (UTC)[reply]
      You're absolutely entitled to your opinion, but please don't misrepresent mine. There is no certainty in any complex field, not in the sciences (see uncertainty principle), not in history (see historiography), not in politics, art or anything else. But as an encyclopedia, we reflect this uncertainty best when we quantify the uncertainty and attribute it to the best sources, not when we use a lazy form of words to wave a hand at something being uncertain. Everything is. John (talk) 21:06, 23 October 2024 (UTC)[reply]
      I wasn't commenting on you at all, but whatever. Don't tell me, tell the herds of editors who pounce on any expression of uncertainty. Johnbod (talk) 23:03, 23 October 2024 (UTC)[reply]
      Then I apologise. My background is in Chemistry and I've worked on a lot of chem stuff over the years here. So I wrongly thought that was directed at me. Here's to expressing the uncertainty as clearly as possible, but preferably without flabby phrases like the one under discussion. On the same ground I find qualifiers like "about", "approximately" and "some" are way overused here. Pretty much all measurements are uncertain. John (talk) 23:45, 23 October 2024 (UTC)[reply]
      Sure - I didn't know that (or had forgotten), so a bit of a fluke there! You can't get far in my areas of art history and ancient history without a lot of qualifiers, especially if you are trying to write general articles. Johnbod (talk) 00:02, 24 October 2024 (UTC)[reply]
      Qualifiers are absolutely fine, I think 'Perhaps the most..' specifically sounds like us pontificating in wiki-voice, rather than explaining why there is uncertainty, or who thinks there is uncertainty, but 'perhaps' isn't the issue here exactly, You could find/replace it with "One of the most" and you'd have the same problem. I'm realising thanks to this discussion that it's something that requires thought and research to resolve on an article-by-article basis, to identify the source of the uncertainty and be more explicit about it, it's maybe not a style question at all, more one of sourcing and verifiability. JeffUK 08:02, 24 October 2024 (UTC)[reply]
      The two possibilities are not mutually exclusive. In my opinion (having looked at the sample articles linked from this discussion), it's always a style issue and almost always a sourcing one too. A good article won't ever airily handwave the uncertainty in this way, I think. Thanks for raising such an interesting point. John (talk) 21:22, 29 October 2024 (UTC)[reply]
    I think that it is a fair point that "Perhaps the most..." sorts of statements should be quotes from authorities. BD2412 T 01:02, 24 October 2024 (UTC)[reply]
    My concern with that as a blanket policy is that it would tend to give more weight to less careful sources. A source that says Prague was the most important centre for cubism after Paris could be cited in wikivoice, while if the same source added "perhaps", just to acknowledge there is some room for debate from the prevailing view, the statement could only be quoted.--Trystan (talk) 13:54, 24 October 2024 (UTC)[reply]
    I would think that we would still want a statement like "Prague was the most important centre for cubism after Paris" in a quote. BD2412 T 14:08, 24 October 2024 (UTC)[reply]
    Could we not have some guideline that unsourced and unsupported "perhaps the most" statements may possibly be inappropriate? I see statements such as
    Out of all the Andean countries, Bolivia remains perhaps the most culturally linked to the indigenous peoples. - Music of Bolivia
    Of the several stories about the ghosts of former presidents of the United States revisiting the White House, Lincoln's ghost is perhaps the most common and popular. ... Perhaps the most famous incident was in 1942 when Queen Wilhelmina of the Netherlands .... Lincoln's ghost
    Perhaps the most spectacular athletic events were in swimming. Swimming at the 1972 Summer Olympics
    their casual invitation to Willie [Maley] to also come along was perhaps the most important in Celtic's history. Tom Maley
    Such statements are often verbal fillers, as also with "perhaps the best known"[2], a little stronger and more stylish than "for example" and yes, comparatively innocuous - but unsubstantiated and possibly indicating that the writer's personal knowledge is focused on that particular instance. NebY (talk) 14:45, 24 October 2024 (UTC)[reply]
    What would be the alternative, though? Just "the best known" is essentially impossible to prove (and even if some sources say so, others might disagree) and just not mentioning this fact at all would in many cases be a real loss, I'd say. Gawaon (talk) 16:30, 24 October 2024 (UTC)[reply]
    Agree with Gawaon and NebY that this is filler, adds no meaning, and is inherently impossible to prove. I think I would argue that this is therefore a phrase that should never appear in Wikipedia's voice but only in an attributed quote. John (talk) 20:01, 24 October 2024 (UTC)[reply]
    That's not what I said or meant, rather on the contrary ("just not mentioning this fact at all would in many cases be a real loss" – emphasis added). Let's remember that outside of narrow fields like maths, strict proof is rarely possible anyway, and we go for what reliable sources say, not for what's proven. If several RS call something "the best known", while other's don't mention this fact, summarizing this as "perhaps the best known" seems a reasonable choice. One could also say "a well-known" and that's probably what I would do, but still I wouldn't say that the alternative must always be avoided and eliminated on sight. Gawaon (talk) 07:51, 25 October 2024 (UTC)[reply]
    No, I know. You said that such claims are unprovable and NebY said they were verbal filler. I agree with both those statements and hence don't think it's a very encyclopedic phrase. I'm not suggesting we just don't mention it or remove it on sight either; I proposed a better form of words right at the start. I think in general value judgments (such as this) absolutely have to be attributed. This is why I don't think in this form it should be appearing in Wikipedia's voice. John (talk) 12:24, 25 October 2024 (UTC)[reply]
    I think we are glossing over the fact that not saying something in Wikipedia's voice is different from not saying something at all. If you want to say that "Lincoln's ghost is perhaps the most common and popular", well, according to whom? We can't say it at all if no reliable source actually thinks this is true, and if one does, then we can quote the language it uses to say this. BD2412 T 22:10, 25 October 2024 (UTC)[reply]
    I have to entirely agree with this: "It certainly has the potential to be used in a weaselly way, but like other such formulations, it is fine if the statement accurately reflects the source[s]." In particular, there is rarely unanimity or near-unanimity across multiple RS on matters that are a judgment call, yet a large enough preponderance of them may agree on an assessment that leaving it out would result in an incomplete/misleading article, yet also WP is not in a position to declare a subjective matter of public consensus to be an objective fact. That is, this sort of wording is a way by which WP can indicate to the reader that a bunch of sources agree on this point, but some minority do not, and it's not a matter of cold hard fact (like whether the earth is round or flat, or many other science questions). Our readers already understand this. All that said, there is conceivably a better way to phrase it than the specific strings at issue here like "Perhaps the most", and "is perhaps one of the best-known", and the like. I would suggest coming up with something you are convinced is better and trying it out at a number of randomly selected articles and seeing whether it sticks. PS: If one wanted to have a more in-depth review of this sort of language and whether we should have advice specifically addressing it, WT:MOSWTW is probably a better venue than the main MoS talk page. MOS:WTW is basically where MoS and NPoV+NOR most strongly intersect. That entire guideline is about terms and phrases to avoid (sometimes or always), and why, and what to do instead.  — SMcCandlish ☏ ¢ 😼  21:23, 25 October 2024 (UTC)[reply]
    I agree with a lot of what you say, and on the best next steps. Your science example proves my point rather than yours though; the Earth is neither perfectly spherical nor flat. Aside from the mountains and the oceans, it bulges significantly at the Equator. Few complex subjects can fairly be described without some uncertainty. The use of "perhaps" seems like a WP:TONE concern, as in my opinion a serious encyclopedia should report the nature and degree of the uncertainty, rather than just trivially stating that it exists. I'm not saying words like this should never be used, more that a more precise form of words is better. It's like "a number of"; better to state the actual number if it's known, or just say "some". As you say, a candidate for WTW. John (talk) 21:45, 25 October 2024 (UTC)[reply]
    I didn't say anything about "perfectly spherical". Lots of non-perfectly-spherical shapes are still round (i.e. subjected to curvature around their circumference). On the more important matter, we're generally not in a position to "report the nature and degree of the uncertainty", at least not the "degree" part, because that would require WP:OR unless a secondary reliable source has actually quantified it, which is unlikely in the vast majority of cases. Even covering the nature and perhaps [there's that word you don't like!] some vague indication of degree is often not appropriate in a lead section, both for length reasons and for giving undue weight to a fringe position to highlighting its nonsense claims. a more precise form of words is better – Like what? Or to put it another way, how exactly is "perhaps" supposedly broken? PS: I agree about "a number of", which is a confusing construction.  — SMcCandlish ☏ ¢ 😼  10:08, 21 November 2024 (UTC)[reply]

    MOS:PRONOUNS cleanup

    [edit]
    The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
    Consensus for the merge/clean-up. Choucas Bleu (T·C) 20:18, 10 November 2024 (UTC)[reply]

    To solve several problems at once, I propose the following:

    1) Add this text to Wikipedia:Manual of Style#Pronouns (MOS:PRONOUNS), which at present confusingly lacks anything on third-person ones, despite disputation about them coming up more often than with regard to any other:

    Third-person pronouns

    Refer to a person with pronouns (and other gendered words) that reflect their most recent self-identification in recent reliable sources. Singular they/them/their are appropriate in reference to anyone who uses them, as replacements for neopronouns, and in generic reference to persons of unknown gender.
    (For considerably more detail, see WP:Manual of Style/Biography § Gender identity.)

    Shortcut

    Ships (military or private) may be referred to either by neuter pronouns (it, its) or feminine pronouns (she, her). Both usages are acceptable, but each article should be internally consistent and exclusively employ only one style.[a] As with all optional styles, articles should not be changed from one style to another without clear and substantial reason.[b] Try to avoid close, successive uses of the same referent for a ship by carefully using a number of referents in rotation; for example, it or she, the ship, and the ship's name. The she/her optional style does not apply to other vessel/vehicle types, such as trains.[c]

    [...]

    Notes

    [...]

    1. ^ As usual, direct quotations should not be altered in such a regard, and have no effect on determination of consistency within Wikipedia-authored content.
    2. ^ See Wikipedia talk:Manual of Style/Archive (ships as "she") for an index of recurrent debates about this subject, from 2004 though 2022.
    3. ^ See Wikipedia talk:Manual of Style/Archive 167 § WP:SHE for steam locomotives as well as ships – concluded with a strong consensus against the practice.


    2) This (mis-placed) subsection at Wikipedia:Naming conventions (ships)#Pronouns (WP:SHE4SHIPS) is to be deleted:

    Pronouns
    Shortcut
    For the naming convention for military vessels, see MOS:SHIPPRONOUNS.
    Ships may be referred to by either feminine pronouns (she, her) or neuter pronouns (it, its). Either usage is acceptable, but each article should be internally consistent and exclusively employ only one style. As with all optional styles, articles should not be changed from one style to another without clear and substantial reason.[a]
    1. ^ See Wikipedia talk:Manual of Style/Archive (ships as "she") for an index of recurrent debates about this subject, from 2004 though 2024.

    and replaced with:

    Pronouns
    For use of "it/its" or "she/her" in reference to ships, see WP:Manual of Style § Third-person pronouns.


    3) The subsection at Wikipedia:Manual of Style/Military history#Pronouns (presently MOS:SHIPPRONOUNS) is to be deleted:

    Pronouns
    For the naming convention for merchant ships, see WP:SHE4SHIPS.
    Shortcut

    Ships may be referred to either using feminine pronouns (she, her) or neuter pronouns (it, its). Either usage is acceptable, but each article should be internally consistent and employ one or the other exclusively. As with all optional styles, articles should not be changed from one style to another unless there is a substantial reason to do so.

    Try to avoid close, successive uses of the same referent for a ship by carefully using a number of referents in rotation; for example, it/she, the ship, and the ship's name.

    and replaced with the same cross-reference as above:

    Pronouns
    For use of "it/its" or "she/her" in reference to ships, see WP:Manual of Style § Third-person pronouns.


    4) Shortcuts that presently go to either of the old ship subsections will be re-targeted to the new one in the main MoS page.


    What this will solve:

    • It is very confusing that the main MoS page has a section for pronouns but contains nothing about the two most frequent pronoun-related subjects of conflict on Wikipedia.
    • It is unhelpful to have advice that is fairly frequently sought (and repeatedly contentious) buried on obscure pages.
    • One of these is a naming conventions page, and has nothing to do with article content; the ship pronoun question never arises in article titles, so this does not belong in an NC page at all.
    • The military-related concern ends up being exactly duplicative of that with regard to merchant and other private-sector ships, so it is not intrinsically a military style matter at all.
    • It is unwise to have initially duplicate language in two different guidelines, as it will inevitably WP:POLICYFORK over time and cause a conflict. The language in the two subsections has already drifted apart some.
    • The purpose of the main MoS page is (aside from having some unique, usually overarching rules that are not found in any of the topical drill-down pages) to summarize the key points of all the MoS pages. With regard to pronouns, these two points certainly qualify.
    • Make a few bits of the wording slightly clearer. E.g., that the ships thing is both military and private-sector.
    • Point to the consensus record against expanding she/her beyond ships.
    • Clarify that singular-they is also used generically; MOS:GENDERID skips that because it isn't pertinent to gender-related editing disputations, but I think we all know by now that this particular usage of singular-they is the one with a pedigree all the way back to Middle English. There still exist various agitators against singular-they, so any antics they might get up to on a wikilawyering basis need to be accounted for. Provide them no loophole to game.
    • For ships, subtly suggest a preference for it over she by listing the former first. This will be in agreement with the vast majority of actual practice, both in our material and in modern RS material.
    • Fix shortcuts so people arrive at the MoS material about it, not at cross-references to the MoS material about it.

    Please do not response to this cleanup proposal with suggestions to add new or remove old restrictions with regard to any sort of pronoun usage. This is not what this thread is about.

    The "Try to avoid close, successive uses of the same referent ..." material might be compressable without losing the gist of it. I chose not to, here, since this is in part a merge proposal and those are complicated when major textual changes are introduced.

    Further compression could be achieved by not having the first-paragraph summary of MOS:GENDERID on pronouns, but only a bare cross-reference sentence like "For third-person pronouns and their relation to human gender, see WP:Manual of Style/Biography § Gender identity."

    PS: For those interested in the tediously long history of disputation over she/her and ships, see Wikipedia talk:Manual of Style/Archive (ships as "she"); this might be missing some that happened at other pages, like in article talk. I don't know of a comprehensive archive of debates regarding pronouns and social gender, but someone may have compiled one by now.  — SMcCandlish ☏ ¢ 😼  00:53, 25 October 2024 (UTC)[reply]

    • As a content manager in real life, it drives me nuts to see the same material duplicated across several pages. Support condensing to just the MoS page as suggested. Parsecboy (talk) 11:51, 25 October 2024 (UTC)[reply]
    • Support — OwenBlacker (he/him; Talk) 12:20, 25 October 2024 (UTC)[reply]
    • Good idea, support. If it is possible to clarify that this section of the style guide refers to ships that float on water, and not airships, spaceships or other vehicles, I think that would be useful. John (talk) 16:07, 25 October 2024 (UTC)[reply]
      Of legal knowledge I acquired such a grip / That they took me into the partnership. / And that junior partnership, I ween, / Was the only ship that I ever had seen. [3] EEng 17:37, 25 October 2024 (UTC)[reply]
      But that sort of ship so suited he / That now he is the ruler of the Queen's Navee. --Trovatore (talk) 18:02, 25 October 2024 (UTC) [reply]
      If you mention suiting again I'll report you for legal threats. EEng 19:33, 25 October 2024 (UTC)[reply]
      Suit yourself. --Trovatore (talk) 20:35, 25 October 2024 (UTC) [reply]
      Suture self. EEng 20:49, 25 October 2024 (UTC)[reply]
      One of my favorite dad jokes involves that pun. A doctor cuts her finger in the OR. Another doctor says "Let me sew that closed for you" ... you can figure out the rest.  — SMcCandlish ☏ ¢ 😼  21:03, 25 October 2024 (UTC)[reply]
      @John: That would actually be a substantive change, and I'm skeptical there is a clear consensus for it. Most of our terminology with regard to spaceships, airships, and hovercraft (maybe something else I'm forgetting) are derived directly from those pertinent to float-on-water ships, because they are closely analogous in most relevant respects. That's not the case with trains and tanks and trucks/lorries and skateboards and bicycles and etc. The train RfC hints in the vague direction of "don't do it for spacecraft either", but did not clearly reach a result that specific, so for now it's an open question. That is, the jury seems to still be out on the exact definition of "ship" for this particular purpose.

      And I expect (given 20 years of history) for the entire matter to come up again within the year. If it does, it should probably be done as a VPPOL RfC, to attract a larger body of input from the community, instead of just the same handful of MoS regulars and people from watercraft and military history wikiprojects. [Aside: I wonder, sometimes, that this hasn't also come up for a few other topics with a historical "she" practice, especially countries, as in "Ireland and her rolling green hills". No one seems to want to fight to impose that style, and I'm glad of it.] But for now, I just want to merge and clean up the redundant and poorly placed guideline material as it presently stands. If nothing else, it will provide a single and obvious locus of the perennially-but-unresolvedly disputed material, instead of having it scattered in confusing places.  — SMcCandlish ☏ ¢ 😼  21:03, 25 October 2024 (UTC)[reply]

    I read somewhere around here recently that Japanese ships are referred to with he/his. Are we saying just don't do that in English WP, or are we just ignoring a potential complication? I'd be in favor of saying explicitly not to. Dicklyon (talk) 01:54, 26 October 2024 (UTC)[reply]

    Something to research further, I suppose, but that's another substantive change proposal and out-of-scope for this merge/cleanup thread. Something to address in a later revision proposal after we have more details/sources on the question.  — SMcCandlish ☏ ¢ 😼  02:22, 26 October 2024 (UTC)[reply]
    No prob. I Support in any case. Dicklyon (talk) 03:01, 26 October 2024 (UTC)[reply]
    Japanese doesn't have gendered third-person pronouns, so I don't see how that can be. あいつ usually gets translated as "he" or "she" depending on whom is being referenced, but I very much doubt it is ever used for ships, as it's usually used with contempt. 73.2.106.248 (talk) 13:03, 4 November 2024 (UTC)[reply]
    • Ships are typically referred to in English as 'she'. That's a very old usage and tradition. Is it codified in military usage, or simply traditional. Randy Kryn (talk) 02:51, 26 October 2024 (UTC)[reply]
      Either way, the point is that some will argue strongly for "she", and some will argue strongly against, and that's not part of what we can settle in this cleanup re-org. Same as what he told me about using "he" for Japanese ships; best not bring it up right now. Dicklyon (talk) 03:03, 26 October 2024 (UTC)[reply]

    Noting the consensus close, I've put this work on my to-do list, but will probably get to it tomorrow or later.  — SMcCandlish ☏ ¢ 😼  10:12, 21 November 2024 (UTC)[reply]

    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Main Street, U.S.A.: GEOCOMMA?

    [edit]

    I was considering reviewing Main Street Vehicles, which contains many references in running text to the theme park section Main Street, U.S.A. These currently lack GEOCOMMAs, e.g. is located in the Main Street, U.S.A. section. This is not technically a geographic place name as the comma is part of the full name. Would a comma after still be necessary? Sammi Brie (she/her • t • c) 06:01, 28 October 2024 (UTC)[reply]

    I would treat it as one, as it's clearly modelled after them. Gawaon (talk) 08:15, 28 October 2024 (UTC)[reply]
    What are those periods doing? John (talk) 11:00, 28 October 2024 (UTC)[reply]
    Good question! Gawaon (talk) 17:37, 28 October 2024 (UTC)[reply]
    The comma is present in its official logo. I'm sorry to admit I can't put my finger on it, and I've been known to be wrong from time to time, but I believe MoS says we retain the comma in that case. According to the article's lead, it doesn't even refer to a single, discrete location on the planet. The all-caps in the logo is a different matter. Agree as to the periods; the rationale for adding them, if any, is not apparent and unknown to me. Maybe it's a COMMONNAME argument, I don't know, but offhand I'd say the article needs a move to Main Street, USA. (Needless to say, the mechanism for that is WP:RM at Talk:Main Street, U.S.A., not consensus here.) ―Mandruss ☎ 03:37, 29 October 2024 (UTC)[reply]
    The question here is not about the comma before "U.S.A./USA", but whether there should be one placed after it if the sentence continues. As per GEOCOMMA, I'd say yes. Gawaon (talk) 08:29, 29 October 2024 (UTC)[reply]
    What's wrong with "Main Street USA"? Tony (talk) 11:52, 29 October 2024 (UTC)[reply]
    It's not what the theme is called. Gawaon (talk) 17:36, 29 October 2024 (UTC)[reply]
    It is, according to the theme's own logo, as displayed on the article. John (talk) 19:56, 29 October 2024 (UTC)[reply]
    I've started a move discussion at article talk if anyone's interested. John (talk) 00:13, 30 October 2024 (UTC)[reply]
    My mistake. Thanks for correcting me. In that case, no meaningful opinion. ―Mandruss ☎ 22:59, 29 October 2024 (UTC)[reply]
    Yes, it would take a comma afterward, since the comma in it is serving the same bracketing function as that in "Des Moines, Iowa", or the one in "Gallumphing Department, Ministry of Silly Walks", or that in "Encyclopædia Britannica, 11th edition", and so on. Bracketing commas come in pairs unless the second is replaced by other punctuation (or would be at the end of something that takes no terminal punctuation, like a table header).  — SMcCandlish ☏ ¢ 😼  10:36, 21 November 2024 (UTC)[reply]

    "Wikipedia Manual of Style" listed at Redirects for discussion

    [edit]

    The redirect Wikipedia Manual of Style has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 November 1 § Wikipedia Manual of Style until a consensus is reached. TeapotsOfDoom (talk) 19:22, 1 November 2024 (UTC)[reply]

    I didn't see this in time to comment, but it was kept, and I think this was an error. The general argument seemed to be that it was a plausible typo (a missing ":"), but by that reasoning every WP:-namespace page should have such a mainspace redirect. The secondary argument seemed to be that non-edtor readers might actually be looking for our manual of style, as a "meta" matter, but a) ditto the above issue, and b) our MoS is not a work of public advice and people should not consult it the way they might the AP Stylebook or whatever. The third issue is that by now it may well be possible to write an actual encyclopedia article about the WP MoS; enough off-site publications have probably treated it or aspects of it with sufficient depth to pass WP:GNG, but this cross-namespace redirect is squatting on the title. If that article could exist then it should. In short this should be a red link, so should be re-RfDed at some point, with a clearer rationale.  — SMcCandlish ☏ ¢ 😼  10:44, 21 November 2024 (UTC)[reply]

    "Manual of Style:" listed at Redirects for discussion

    [edit]

    The redirect Manual of Style: has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 November 1 § Manual of Style: until a consensus is reached. TeapotsOfDoom (talk) 19:50, 1 November 2024 (UTC)[reply]

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

    [edit]
    Please select in your preferences: Enables javascript Calculator template to see a working calculator.
    Today
    [refresh]

    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 Wikipedia 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? [not obviously to my mind, since it is 'merely' expressing the RSs in numerical rather than text form].
    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)[reply]

    See also Wikipedia:Village pump (technical)/Archive 215#Building a simple body index calculator. --Redrose64 🌹 (talk) 23:23, 2 November 2024 (UTC)[reply]
    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]

    Reply by Uwappa

    [edit]

    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, Wikipedia 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, 20:35, 21 November 2024 UTC [refresh].
    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)[reply]

    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 20:34, Thursday, November 21, 2024 (UTC) using template:currentdate
    • A combination of the two, like it is now 96 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?

    with

    to get

    • 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)[reply]

    @Uwappa:, this discussion is about the principle of how best to handle interactive content on Wikipedia. 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)[reply]
    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)[reply]

    MOS namespace

    [edit]

    Now that we have the new MOS namespace, are there any plans to move the manual of style, or will that namespace just be used for the MOS shortcuts (e.g. MOS:THEY) that used to litter the article space? — Martin (MSGJ · talk) 14:24, 3 November 2024 (UTC)[reply]

    It's just used for shortcuts, to keep MoS stuff from sucking up all the mnemonically useful shortcuts that could have other uses/targets in "Wikipedia:" namespace. MoS collectively has more shortcuts than anything else on the system. "MOS:" used to be a pseudo-namespace, but doing it that way had no practical benefit and had the downside of everything in it really being a namespace page (plus any variation like "Mos:" causing the creation of additional mainspace pages). Thus it is now a proper namespace.  — SMcCandlish ☏ ¢ 😼  10:53, 21 November 2024 (UTC)[reply]

    "Wikipedia:MOSSECTIONHEADINGS" listed at Redirects for discussion

    [edit]

    The redirect Wikipedia:MOSSECTIONHEADINGS has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 November 5 § Wikipedia:MOSSECTIONHEADINGS until a consensus is reached. Hexware (talk) 16:35, 5 November 2024 (UTC)[reply]

    "MOS:HESD" listed at Redirects for discussion

    [edit]

    The redirect MOS:HESD has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 November 5 § MOS:HESD until a consensus is reached. Hexware (talk) 16:35, 5 November 2024 (UTC)[reply]

    MOS:DATECOMMA and ranges

    [edit]

    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[/and] or from[/to].
    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)[reply]

    Chicago Manual agrees, a second comma after the year in a range. Hyphenation Expert (talk) 13:10, 8 November 2024 (UTC)[reply]
    A minor prior discussion. EEng: do what feels best. SMcCandlish: No, there is no exception. Hyphenation Expert (talk) 13:29, 8 November 2024 (UTC)[reply]
    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)[reply]
    The USGPO requires it: [4] The dates of September 11, 1993, to June 12, 1994, were erroneous. Hyphenation Expert (talk) 13:48, 8 November 2024 (UTC)[reply]
    • 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)[reply]
      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)[reply]
    • While Amaury's argument is complete nonsense, the idea that 2015 in May 5, 2015 is a "parenthetical" is something even worse: pompous nonsense.[1] 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    "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)[reply]
    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)[reply]
    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)[reply]
    +JohnFromPinckney Hyphenation Expert (talk) 00:47, 11 November 2024 (UTC)[reply]
    • MLA style: [5] The exhibit ran from June 2, 1995, to April 4, 1996, in New York.
    AP style: [6] 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)[reply]
    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)[reply]

    Bracketing commas always come in pairs [etc] – 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)[reply]
    That's not the view of the MOS, though. Gawaon (talk) 09:56, 12 November 2024 (UTC)[reply]
    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)[reply]
    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)[reply]

    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)[reply]
    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)[reply]
    Says the one with the longest user-talk page across all WMF projects, LOL.  — SMcCandlish ☏ ¢ 😼  21:35, 14 November 2024 (UTC)[reply]
    But then, my talk page isn't all one post. EEng 22:45, 14 November 2024 (UTC)[reply]
    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 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)[reply]

    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    [a]     		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)[reply]
    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)[reply]
    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)[reply]
    Not general, just what's needed to successfully edit Wikipedia. Which apparently includes these rules for comma placement, otherwise this discussion wouldn't have started. Gawaon (talk) 15:53, 16 November 2024 (UTC)[reply]
    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)[reply]

    Notes

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

    Citation templates and MOS:RANGE

    [edit]

    MOS:RANGE says to space the en-dash in page ranges with hyphenated page numbers like "12-1 – 12-24", but if this is attempted in a citation template, the template code strips out the spacing. Either the MOS or the templates need to be fixed to be consistent with each other. I've started a discussion at Help talk:Citation Style 1#MOS:RANGE violation; please participate if you have an opinion. —David Eppstein (talk) 07:25, 11 November 2024 (UTC)[reply]

    Capitalisation of acronyms that are the name of an organisation

    [edit]

    At Talk:National Union of Rail, Maritime and Transport Workers#Requested move 12 November 2024 it is proposed to move Associated Society of Locomotive Engineers and Firemen to ASLEF. While the acronym is very clearly the most common form, how it is capitalised varies between ASLEF and Aslef (the former is official and used in very roughly 2/3rds of independent news publications). When spoken it is uniformly a word (/æz.lɛf/). I've not found what the manual of style has to say about this (I presume it does have something about it, it's bound to have come up before). Thryduulf (talk) 13:37, 12 November 2024 (UTC)[reply]

    In US English, such things maintain full capitalization (eg: NASA, OPEC). I think the usage of ordinary proper noun capitalization is generally becoming more common in British English. However, if your "very roughly 2/3rds of independent news publications" is correct, then usage for this organization would seem to still be ASLEF. --User:Khajidha (talk) (contributions) 13:44, 12 November 2024 (UTC)[reply]
    Has nothing to do with American versus other dialects. Reducing proper acronyms from "ASLEF" style to "Aslef" as if they are non-acronym words is simply a habit of some particular news publishers, in the UK, in the US, and elsewhere (they write "FBI" and "UN" but "Nasa" and "Unesco"). It is habit WP does not use, as it is rarely found in academic writing, and is often confusing and irrational (e.g. when the same publishers write "Aids" for "AIDS", when disease names are not proper nouns (it's like capitalizing "Horse" and "Burritos" and "Television"). The "Aslef" style is further contra-indicated by various acronyms sometimes being prounced as word-acronyms and sometimes as initialisms, depending on the speakers background. No acronyms take lower case unless virtually all dictionaries of English agree that they have been re-interpreted by most speakers as words not acronyms and are no longer written uppercase (thus "laser", "radar", "scuba"); in these cases it's all-lowercase, no initial capital.

    People really, really need to stop proposing changes based on their personal preference just because they can find some publications that agree with their preferences. WP does not care what newspapers or marketing materials or bureuacratese or fiction-writing or non-academic nonfiction lean toward. We do what is predominant in academic style guides and the books and journals that follow them. (Unless we have a really compelling reason to do otherwise, such as having to choose a what-is-best-for-reader-clarity decision when those style guides broadly contradict each other, or when we have a technical requirement to deal with). This situation is not going to change, because an encyclopedia is a form of academic work, and the writing style provides parsing precision and interpretational clarity that other styles lack.  — SMcCandlish ☏ ¢ 😼  03:57, 13 November 2024 (UTC)[reply]

    I don't understand why you wrote most of that? I wasn't proposing any change, and expressed no preferences. The manual of style has different thresholds and defaults for what to do when usage in reliable sources is inconsistent in different contexts. I didn't know what the manual of style says about this circumstance, so I looked but failed to find it (it was subsequently linked in the RM). So I asked here what the guidance is and Khajidha concisely answered my question without any diatribes. Thryduulf (talk) 04:44, 13 November 2024 (UTC)[reply]
    Khajidha mis-answered the question. Repeat: this has nothing to do with American versus other dialects.  — SMcCandlish ☏ ¢ 😼  21:09, 15 November 2024 (UTC)[reply]

    Dyslexia font?

    [edit]

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

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

    See Wikipedia:Dyslexic readers. Personally I didn't find that it helped, but good luck. SchreiberBike | ⌨  20:37, 15 November 2024 (UTC)[reply]
    WP:DYX seems outdated. I do not see 'Fonts' in preferences. Uwappa (talk) 01:21, 16 November 2024 (UTC)[reply]
    Yep, that's out of date. I've raised the question on that talk page. Anybody else got ideas? If not here, perhaps Wikipedia:Teahouse has ideas. SchreiberBike | ⌨  02:43, 16 November 2024 (UTC)[reply]
    @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)[reply]
    Found it and successfully set the font to OpenDyslexic.
    That is eh... well hidden. Uwappa (talk) 13:52, 16 November 2024 (UTC)[reply]
    I amended the WP:DYX page. --Redrose64 🌹 (talk) 16:27, 16 November 2024 (UTC)[reply]

    The whole process should be simpler:

    1. My preference: OpenDyslexic is the default font for Wikipedia. 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)[reply]

    @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)[reply]
    @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)[reply]
    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)[reply]

    RfC Indian numbering conventions (crore, lakh, etc.)

    [edit]
    The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
    Moved to Wikipedia talk:Manual of Style/Dates and numbers § RfC Indian numbering conventions
    Marking this closed and moved, to forestall further WP:TALKFORKing.  — SMcCandlish ☏ ¢ 😼  11:57, 21 November 2024 (UTC)[reply]

    I am revisiting an issue that was last brought up 6 years ago 1 and settled without a strong consensus.

    I think we should avoid using Indian numbering conventions unless it is needed for context. For instance, if we want to list the box office take of an Indian movie, don't use "crore", use "millions". This isn't about disrespecting a culture, it's about using internationally favored notation and unit conventions. We should use "millions" instead of "crore" for the same reason we favor meters over feet. There is no reason that India-related articles should be an enclave of Indian conventions. People who are not Indian will struggle with these things, it will weaken Wikipedia's role as an information tool for everyone.

    This is not the same thing as currency. It is appropriate to list an Indian movie's box office take in rupees. Providing a US$ conversion is optional, but a good idea since the US dollar is widely used around the world as a reserve currency. But write it as "millions of rupees", not "crores of rupees". Kurzon (talk) 16:27, 16 November 2024 (UTC)[reply]

    @Kurzon: Why are you bringing this up here, and not at Wikipedia talk:Manual of Style/Dates and numbers? Also, don't jump straight for a full-blown thirty-day formal RfC without first exhausting the suggestions at WP:RFCBEFORE - and when you do, you should link the places where discussion was tried. Third, when you do use the {{rfc}} tag, you must also specify at least one RfC category, to prevent the big red error message that you got here. --Redrose64 🌹 (talk) 16:36, 16 November 2024 (UTC)[reply]
    Now at Wikipedia talk:Manual of Style/Dates and numbers#RfC Indian numbering conventions. --Redrose64 🌹 (talk) 20:06, 16 November 2024 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Should reference titles have spelling corrected?

    [edit]

    I read MOS:PMC to say that spelling errors in the titles of referenced works can be silently corrected. This seems like a problem to me—it sacrifices the accuracy of our citations, makes way for disputes about language variations and spellings aligned with different populations and political alignments, obfuscates trends in spelling, and makes way for good-faith errors like changing "whisky" to "whiskey", all for no apparent reason. How does it help Wikipedia if the title of a referenced work is overwritten with a better one? ꧁Zanahary꧂ 19:32, 16 November 2024 (UTC)[reply]

    The titles of references should be treated as if they are direct quotations from the source text (which is essentially what they are), and reproduced exactly as they are shown in the source. I make an exception for capitalisation, but not for national spelling differences. --Redrose64 🌹 (talk) 20:05, 16 November 2024 (UTC)[reply]
    No, their spelling should be left as is. That's also better for findability, if nothing else. Gawaon (talk) 12:07, 17 November 2024 (UTC)[reply]
    I hope no one thinks The Compleat Angler should be corrected to The Complete Angler. Largoplazo (talk) 12:52, 20 November 2024 (UTC)[reply]
    I updated the guideline per the clear consensus here—for some reason I was not prompted to enter an edit summary. ꧁Zanahary꧂ 16:22, 20 November 2024 (UTC)[reply]

    There was a discussion earlier this year now archived at Wikipedia talk:Manual of Style/Archive 228#Silently correct an error if it's in a title? It's hard to say there was a definite consensus on anything. For my practice, in an obvious mistake in a newspaper headline or similar, I make the correction, but leave a note in the wikitext (like <!-- "Mclver" in original -->) and use an edit summary like "Spelling fix, McLver → McIver, as explained at MOS:TITLETYPOCON". That's not perfect, but it's the best I've come up with. I'd only do that when it is a clear error. SchreiberBike | ⌨  23:02, 17 November 2024 (UTC)[reply]

    With respect and curiosity, what good does it do to edit the title of a source at all? ꧁Zanahary꧂ 06:43, 18 November 2024 (UTC)[reply]
    @Zanahary: Per MOS:TYPOFIX "insignificant spelling and typographic errors should simply be silently corrected", and if we don't fix them, the errors propagate into other places. The example I used above of "Mclver", which should be "McIver" (a lower case "L" when an upper case "i" is intended, but it looks the same in a sans-serif font) occurred 33 times in Wikipedia several months ago when I ran that check. Many of those were in the titles of references, and many of those titles had also been copy-pasted into our article text. I often see editors fix such errors referencing MOS:TYPOFIX and I think that makes it harder to find the source if the URL doesn't work, so I hoped to find a better solution. SchreiberBike | ⌨  22:52, 18 November 2024 (UTC)[reply]
    This is a discussion proposing a change to the MOS—what exactly is the nature of McLver? Where does that typo come from? I’m talking about changing a source’s title (its actual published title) in references because the title as accurately reproduced contains an error. ꧁Zanahary꧂ 22:57, 18 November 2024 (UTC)[reply]
    McIver and MacIver are both reasonably common names. "Mclver" and "Maclver" are understandable errors because they look the same in some fonts. I'm using that as an example of a series of corrections I made fairly recently, many of which were the actual published titles of references. SchreiberBike | ⌨  23:14, 18 November 2024 (UTC)[reply]
    How do you know that the original source errantly used a lowercase L? Is it a typographic thing you’re able to discern by looking at the letterforms of a scan?
    In general, I want to distinguish between typographic errors and variations, which I think can be standardized with silent correction, and spelling errors, which I think should remain in place. ꧁Zanahary꧂ 23:46, 18 November 2024 (UTC)[reply]
    These were almost all on live websites. The quickest way is to Ctrl+f, then type an L, and see if it finds an "L". The other way is reading the articles. Also, I've found no use of "Mclver" or "Maclver" as a correctly spelled English word. SchreiberBike | ⌨  00:12, 19 November 2024 (UTC)[reply]
    On the websites of original publication, or on websites cataloguing or referring to the publication? This seems like an edge case, ambiguously between a spelling error and a typographic error. For the matter of spelling errors in titles like "Ukranian Detriot" instead of "Ukrainian Detroit" here, what is your position on a policy that advises against silent correction? ꧁Zanahary꧂ 00:26, 19 November 2024 (UTC)[reply]

    I for one often search for reference titles as exact strings, to find copies of the reference (for instance when they are unlinked or when an old link has gone dead) or to search databases for missing metadata for the title. Changing the spelling to fix errors or according to national preferences (a recently-encountered example) makes this much more difficult. —David Eppstein (talk) 07:18, 18 November 2024 (UTC)[reply]

    I agree with your general point. Just a pity that the example you chose undermines the point, since the edit you dislike did in fact correctly reproduce the original title of the paper (which is written in en.en). --𝕁𝕄𝔽 (talk) 11:01, 18 November 2024 (UTC)[reply]
    The edit shows a correction to the title of the paper, from a previously-incorrect title whose incorrectness in fact significantly slowed my search for the correct metadata. —David Eppstein (talk) 17:52, 18 November 2024 (UTC)[reply]
    Ah, you mean it was the editor who first created that article in 2010 who erroneously transcribed the title. Easily done, especially with the uninvited "help" of autocorrect. I doubt it was done with malice aforethought. Ok, I can see that I'm in a hole now, so I'll stop digging. 𝕁𝕄𝔽 (talk) 20:07, 18 November 2024 (UTC)[reply]
    Hey, no hole! Would everyone in this discussion support clarifying prose in the MOS that advises not to inaccurately "correct" the titles of sources when reproducing in references? ꧁Zanahary꧂ 22:28, 18 November 2024 (UTC)[reply]
    For corrections involving spelling or wording, I would support that. I think corrections like changing curly quotes to straight, or changing the capitalization (especially from all caps) are ok. —David Eppstein (talk) 22:49, 18 November 2024 (UTC)[reply]
    I agree; that doesn’t damage searchability and punctuation can vary across references anyways, especially in pre-digital sources. ꧁Zanahary꧂ 23:00, 18 November 2024 (UTC)[reply]
    I agree with SchreiberBike (and others) that we may correct minor typographical errors - but judiciously and with care. No bots "fixing" titles under any circumstances.  Mr.choppers | ✎  04:46, 20 November 2024 (UTC)[reply]
    Don't correct spelling errors in cited source titles; it impedes actually finding the source by copy-pasting the title to search with. Just stick [sic] on the end (but don't use {{sic}} inside a citation template, or it'll pollute the citation metadata). Making capitalization and punctuation consistent is fine, since search engines ignore those factors.  — SMcCandlish ☏ ¢ 😼  12:01, 21 November 2024 (UTC)[reply]

    I support the MoS changes made by Zanahary and Jonesey95. That is not what we came up with before, or what I've been doing, but it is a big improvement on what we had before - which was not clear at all. SchreiberBike | ⌨  13:30, 21 November 2024 (UTC)[reply]

    Address future-tense verbs in "tense" section?

    [edit]

    MOS:TENSE discusses the use of present and past tense, but I also frequently run across future tense that seem inappropriate.

    Here's a contrived example: "An observer will see that an object will fall when dropped." The prose is more compelling by removing the future-tense verb "will" and rephrasing as present tense: "An observer sees that an object falls when dropped." It's also more concise.

    I've been cleaning these up when I run across them. I have rarely enountered a situation where using "will" is appropriate to describe facts. Facts are facts, they are true now, not just in the future.

    Related to this would be the article about zero conditional grammar. These cases, also, are better expressed with the zero-conditional construction and eliminating the words "will" or "won't".

    It seems natural to use the word "will" in speech, but isn't necessary in writing. I've also seen clumsy constructions that mix all tenses together, as in "The city government will now no longer collect sales taxes." ~Anachronist (talk) 20:20, 20 November 2024 (UTC)[reply]

    Does this come up so often and with so much editorial conflict that we actually need a rule about it? If not, then we really need not to have a rule about it. Most of what you've raised above just seems like general matters of poor versus better writing, and unlikely to spark debate. WP:BETTER might be a reasonable place to put something about this, though. It's MoS-adjacent without being rules people may think they need to absorb or are apt to cite and squabble about.  — SMcCandlish ☏ ¢ 😼  12:10, 21 November 2024 (UTC)[reply]
    It comes up frequently, but not with editorial conflict. I wasn't aware that the contents of MOS must be restricted to practices that are contentious. I simply noticed that MOS:TENSE failed to mention future tense and sought to rectify that.
    Thanks for referring me to WP:BETTER. ~Anachronist (talk) 15:46, 21 November 2024 (UTC)[reply]
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&oldid=1258795153"