Jump to content

User talk:SMcCandlish/Archive 205

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 200←Archive 203Archive 204Archive 205Archive 206Archive 207→Archive 210

December 2023

Precious anniversary

Precious
Six years!

--Gerda Arendt (talk) 09:14, 1 December 2023 (UTC)

Capitalization after a hyphen

Hey there. In 2020, you moved Three-Fifths Compromise to Three-fifths Compromise, with the edit summary WP:HYPHEN (don't capitalize after a hyphen unless what follows the hypen it itself a proper name). I have a question about that: are you certain WP:HYPHEN is saying "if what follows a hyphen is a proper noun" rather than "if the hyphenated compound is a proper noun"? If your interpretation of the wording is accurate, then I would propose that the exemption for "titles of published works" be extended to all proper nouns. In the case of the Three-Fifths Compromise, plenty of sources capitalize "fifths", including AP, NYT, WaPo, Forbes, LA Times, and Guardian, etc. This is also an outlier, as we have articles like Coca-Cola ("cola" is not a proper noun), Spider-Man ("man" is not a proper noun), Quasi-War ("war" is not a proper noun), Employment Non-Discrimination Act ("discrimination" is not a proper noun), etc. InfiniteNexus (talk) 19:37, 1 December 2023 (UTC)

Collapse-boxing a long thread so I don't have to keep scrolling past it
A user talk page isn't where to propose a change to a guideline. But what would probably actually happen is that "In titles of published works, follow the capitalization rule for each part [after a hyphen] independently" in MOS:HYPHEN would probably be removed, because it does not match actual practice (which is predominantly to use titles like "Evidence Suggesting Pre-adaptation to Domestication Throughout the Small Felidae" not "...Pre-Adaptation...". As for "Three-fifth Compromise", MOS:CAPS: "Wikipedia relies on sources to determine what is conventionally capitalized; only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia." Your "plenty of sources" dopesn't translate to "substantial majority".
"Coca-Cola" and "Spider-Man" are trademarks that are near-universally spelled that way in sources. The last two of those should probably move to "Quasi-war" and "Employment Non-discrimination Act" unless RS demonstrate that is is nearly always given with a capitalized "War" and "Discrimination" (if they do, then the renames should not happen). The fact you can find a handful of exceptions to our general practice is meaningless, because WP is written by humans and they are not consistent, and per WP:P&G: "Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply." These exceptions are arrived at by editorial consensus on a case-by-case basis, and we have various articles that diverge from what MoS or naming conventions or even the article titles policy expect because the sources indicate that an exception should be made and consensus imposes such an exception in that case. E.g. CCH Pounder does not follow MOS:INITIALS and Spider-Man: Far From Home does not follow MOS:5LETTER, and neither case is accidental. The existence of exceptions (due to either laziness/ignorance regarding the rule or a consensus to diverge from it in a particular case) does not mean the guidelines are broken.
At any rate, I have no idea why, when you find a rule the gist of which is "do not capitalize after a hyphen" (except in a proper name like Graeco-Roman that is consistently written that way by RS) you would want to introduce more inconsistency and confusion about this, just to selectively mimic AP News, Forbes, and some other off-site publishers who have nothing to do with our style manual. They are not following our style manual but their own ones. Unless treatment of a term/name across pretty much all of English-language publishing is uniformly doing something against our style manual, we have no reason to do something with that text string that is against our style manual.  — SMcCandlish ☏ ¢ 😼  00:46, 2 December 2023 (UTC)
Normally I would apologize in advance for delivering a WP:WALLOFTEXT response, but since you just wrote one to me, I figured we were good :)
  • A user talk page isn't where to propose a change to a guideline. Well yeah, obviously I wasn't trying to propose a guideline change here. I was saying that I would consider making a proposal at WT:MOS and/or WT:NCCAPS to change the guideline if your interpretation is accurate (which I assume you're saying that it is).
  • But what would probably actually happen is that "In titles of published works, [...]" in MOS:HYPHEN would probably be removed, because it does not match actual practice MOS:HYPHEN is supplemented by MOS:TITLECAPS, which directly contradicts the last part of your claim: "The general rule in English is to not capitalize after a hyphen unless what follows the hyphen is itself usually capitalized (e.g. post-Soviet). However, this rule is often ignored in titles of works."
  • Your "plenty of sources" dopesn't translate to "substantial majority". If you're looking for hundreds and thousands of sources that use the term "Three-Fifths Compromise", I hate to break it to you, but unlike Spider-Man and Coca-Cola, there aren't going to be many talking about a 200-year-old compromise. But I have provided a list of highly reliable sources that capitalize "Fifths" — the rest I found actually lowercase the entire phrase, including "three", but that is not WP:CONSISTENT with every other article in Category:Political compromises in the United States and would therefore not work for us. TITLECAPS specifically says to refer to sources, and in this case the majority is to capitalize (I found not a single source that capitalized "Three" but not "fifths").
  • The fact you can find a handful of exceptions to our general practice is meaningless It's not a "handful of exceptions", it's the majority. Before you ask, no, I do not have statistical evidence to support that, because it would be impossible (as far as I know) to compile a list of articles about proper nouns that are hyphenated — no regular expression would be able to determine what is a proper and common noun, unless there is a magical formula that I am not aware of. But since you asked for more examples/evidence, I went to WP:FA and did a Ctrl+F search for all the hyphens on the page. Of the 45 articles where the hyphenated title was a proper noun that was not a person or place name, and where the hyphen was followed by a common noun, only five used lowercase: 2019 WPA World Ten-ball Championship, Ninety-five Theses, Sonic X-treme, The Lord of the Rings: The Battle for Middle-earth II, and Trembling Before G-d. The latter three don't even count — the hyphen is not being used to connect two words for Sonic and Trembling, and "Middle-earth" is specifically singled out at MOS:HYPHEN (and TITLECAPS) because it is pretty much the only published work universally spelled with a lowercase "earth". So you see, "Three-fifths compromise" (and Ninety-five Theses and 2019 WPA World Ten-ball Championship) are the outliers, not the norm. If our MOS really does call for lowercase, it does not reflect the actual practice at all.
  • These exceptions are arrived at by editorial consensus on a case-by-case basis And they should be applied to cases where sources universally go against the norm of capitalizing after a hyphen in proper nouns, such as "Middle-earth". To reiterate, the norm for proper nouns is to capitalize after a hyphen. Can you name a hyphenated trademark where this isn't the case?
  • At any rate, I have no idea why, when you find a rule [...] you would want to introduce more inconsistency and confusion about this, just to selectively mimic AP News, Forbes, and some other off-site publishers who have nothing to do with our style manual. First off, that sounded a little aggressive, but I've seen worse. Capitalizing after a hyphen does not make things inconsistent; it's what the world has been doing and we've been doing in practice, so changing the guideline would make the outliers consistent with the norm.
  • Lastly, before I start prepping my proposal, I once again ask, are you certain your interpretation is correct? I just looked at MOS:HYPHENCAPS, and it offers a slightly different wording: "In article text, do not use a capital letter after a hyphen except for terms that would ordinarily be capitalized in running prose, such as proper names, demonyms and brand names." This sounds even more ambiguous than MOS:HYPHEN, leading me to wonder whether the MoS really means to capitalize after a hyphen for proper names, demonyms, and brand names. Or maybe that's just me.
InfiniteNexus (talk) 07:01, 2 December 2023 (UTC)
In the same order as above (and, yes, stuff like this often involves a lot of detailed argument):
  • Why? I repeat: "I have no idea why, when you find a rule the gist of which is "do not capitalize after a hyphen" (except in a proper name like Graeco-Roman that is consistently written that way by RS) you would want to introduce more inconsistency and confusion about this". See below on why it introduces confusion and inconsistency.
    But maybe we can short-circuit this and all my reponses below were a waste of time. You came here particularly about Three-fifths Compromise, and if that's really all you're on about, then I have to observe that a large number of sources do not capitalize any element of this, so it its not consistently treated as a proper name and should be moved to Three-fifths compromise per MOS:CAPS and WP:NCCAPS, and that would make this whole discussion moot. But I'll go over the rest in case your concern is broader.
  • "Often ignored" = "the capitalization is done very inconsistently in sources". Per MOS:CAPS: "Wikipedia relies on sources to determine what is conventionally capitalized; only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia." So if a work title like "Evidence Suggesting Pre-adaptation to Domestication Throughout the Small Felidae" is not near-universally presented in independent sources with "Pre-Adaptation" in it (when given in title case) then it should have "Pre-adaptation" in it (when given in title case), and must default to "Pre-adaptation" if there is insufficient RS mention of that title to do much of a head-count – for the same reason that "method acting" should be given in WP as "method acting" not as "Method Acting", because the preponderance of sources independent of the subject do not capitalize it. What we have here is a subtle WP:POLICYFORK in which MOS:TITLES and a titles-related line-item at MOS:HYPHEN have been drifting away from the MOS:CAPS central rule, on a basis ("some sources like to do it") that MOS:CAPS explicitly rejects. This needs to be repaired, not worsened.
  • This point is actually addressed by the one above, really. If there are insufficient sources to demonstrate a clear preference across English writing that pertains to the topic in question, then do what MoS defaults to, which is lower-case. In this particular case, it might actually be that there are sufficient sources to support a "Three-Fifths" exception, but even if there were that would not indicate any need for any RfC to change any guideline. The only need demonstrated for such an RfC or other discussion is to re-normalize MOS:TITLES and the abberrant related MOS:HYPHEN line item back into agreement with MOS:CAPS.
  • WP:FA search: In doing a Ctrl-F there myself, what I see is that almost all of the titles there (also ignoring persons and places) with hyphens in them and a capital after the hyphen are in one of the following classes: 1) have an independent proper name after the hyphen (Saint-Gaudens double eagle, Anglo-Saxon Chronicle, Rolls-Royce Merlin, Imperial Trans-Antarctic Expedition, Franco-Mongol alliance, Sino-Roman relations, etc., etc., etc.; or 2) are cases of following the style preferred by a trademark holder or other originator of a proper name (several examples, but one was Inter-Allied Women's Conference, which is also contraindicated by MOS:TM by default, but which might be permissible in those specific cases, e.g. if "Inter-Allied" is used near exclusively in sources completely independent of the subject and "Inter-allied" is virtually unattested); or 3) are titles of published works which have been rendered this way because of the misleading POLICYFORK identified above (The Bread-Winners, Seventy-Six (novel)); or 4) have the hyphen followed by an all-caps acronym or other code/symbol (WBPX-TV, Tropical Depression Nineteen-E (2018), Nike-X, etc.). 2006 Chick-fil-A Bowl is interesting; it goes lower-case after the first hyphen (as it should, since "fil" it not a proper name but a fragment of the common noun fillet) but then upper-case again because the "A" there is a symbol, the letter A prounced by its name as /eɪ/, and is not just a letter representing the usual /ɑː/ sound that a would typically have at the end of an English word or name, i.e. it's not "Chick-fil-ah". (It also happens to match the official corporate name spelling and much more importantly the dominant spelling in reliable sources which is Chick-fil-A not "Chick-Fil-A", which is what you seem to be arguing for.)
    A few of the FA search results are problematic in novel ways, despite having FA icons on them, or are exceptional or edge cases. E.g. 2001–02 South-West Indian Ocean cyclone season is against MOS:COMPASS, as "South-West Indian Ocean" is not a proper name, but a general description of a vague area and not even a notable topic, so should be "south-west Indian Ocean" or "southwest Indian Ocean" (and the article text veers back and forth between these spellings, which is against MOS:CONSISTENT, too). Similarly, John Edward Brownlee as Attorney-General of Alberta is against MOS:JOBTITLES and should have "attorney-general"). Hi-Level is a weird one; actual source usage includes all of "Hi-Level", "Hi Level", "High-Level", "High Level", "high-level", "hi-level", etc., etc.; the article is unclearly written despite its FA star, and it is uncertain whether this is/was a trademark of Budd Company or just a general class-of-vehicle term that should not be capitalized at all; since it originates from the concept "high-level locomotive" or "high-level train" and is thus a compound modifer, an argument could be made to retain the hyphen even in the short form, though not all sources use it. O-Bahn Busway is another weird case, of an Ausralian road given German name; in German all nouns (Bahn means 'path, track, way, course') are capitalized; and "O-bahn" is not unattested in independent sources. That said, proper names in the form "X-Longersting usually are capitalized after the hyphen in most sources, thus D-Day naval deceptions and the non-FA D-Day. North-Eastern Area Command, North-Western Area Command (RAAF), Operation Ten-Go: special cases of official designations; we would not necessarily "obey" them, per WP:OFFICIALNAME, but RS usage strongly dominates with the capitalization (though curiously the hyphen is often dropped, even in governmental sources, in the first two cases; in the third, the proper spelling of this non-English term is actually Ten-gō, and it can be found that way in some English sources, though our "FA" doesn't really reflect this).
    Anyway, if you think that being an FA has anything at all to do with MoS compliance, you're mistaken. The tiny WP:FACTION who control FA process have evicined startling levels of anti-MoS activism over the years (up to and including hounding out of the process one of WP's best copye-ditors and fact-checkers for daring to insist on some MoS compliance in an FAC, with such viciousness that he almost quit WP entirely and has certainly withdrawn most of his participation, for several years now). They're generally in favor of whatever personal preferences the dominant editor of an article has (WP:OWN policy be damned). There is no MoS-compliance requirement in WP:FACR to begin with, and the only MoS cleanup checking that programmatically happens is at WP:GACR, and only for five kinds of compliance. All sorts of things pass GAN and FAC with style problems in them, from titles on down; it is left to editors to randomly clean them up as time and interst permit.
  • Trademarks are a terrible basis for trying to decide what to do with capitalization, since one of the most frequent marketing techniques is to over-use capitalization to get attention. WP really doesn't care what companies and other trademark holders prefer (see all of MOS:TM as well as WP:OFFICIALNAME), only what reliable sources do with the name, and we only diverge from our default style when, for a specific case, the independent sources nearly always agree to style it the way the trademark holder does. Since you asked: Middle-earth itself is a trademark, of The Saul Zaentz Company d.b.a. Middle-earth Enterprises (formerly Tolkien Enterprises). As for more examples, few trademarks have hyphens in them, and when they do, they are usually joining proper names or before a code like "-XR" or "-B"; I can't find any kind of "list of hyphenated trademarks" anywhere on the Internet to examine. But we already saw that Chick-fil-A is another example.
  • "Capitalizing after a hyphen [in a proper-noun phase] does not make things inconsistent": It certainly does do so because the default is to not do it otherwise, and the broader default is to not capitalize anything that is not consistently capitalized in sources. We write Mediterranean-style cuisine, so why on earth would we write something like "Bob's Mediterranean-Style Restaurant" when "Bob's Mediterranean-style Restaurant" is perfectly fine, and the first is confusingly inconsistent with all the text around it about "Mediterranean-style cuisine". The capitalization of the S in the restaurant name serves no purpose at all, and is just use of capital letters to draw the eye for marketing reasons. The only time we should do it is when, for whatever reason, independent reliable sources overwhelmingly prefer it (and there are enough of them to be statistically meaningful). Honestly, I think for most of the indivdual cases you probably care about that they'll be instances where the sources show such in the first place. Much more to the point, though, POLICYFORKing the material further and further apart so that MOS:CAPS is in more conflict with more other micro-topical concerns like a line-item in MOS:HYPHEN and a section at MOS:TITLES would by defintion be increasing inconsistency and confusion. Observing this and calling it what it is (or would be) is not "aggressive".
  • The wording was weird because the latter two are examples for the former; the three don't really form an and list. It's a recently introduced [1] error. Fixed it to: "In article text, do not use a capital letter after a hyphen except for terms that would ordinarily be capitalized in running prose, such as proper names (e.g. demonyms and brand names)". This is consistent with MOS:HYPHEN, other than it hasn't been messed up by the titles-of-works "rider" that someone injected at MOS:HYPHEN (and in MOS:TITLES) and which is generally the source of the confusion and inconsistency we've been seeing here and there.  — SMcCandlish ☏ ¢ 😼  09:35, 3 December 2023 (UTC)
Thank you for the thoughtful "long-ass" response. What I'm trying to point out to you is that according to our MOS (specifically, MOS:HYPHEN), the default is Middle-earth and Chick-fil-A, while Spider-Man and Nineteen Eighty-Four are exceptions that are only permissible if an overwhelming majority of sources use a capital letter. We can safely disregard single letters (e.g. D-Day) and acronyms (WABC-TV) as those would normally be capitalized after a space in prose. The issue with this guideline is that for the vast majority of proper names, an overwhelming majority of sources do use a capital letter. Logically, Spider-Man should be the default and Middle-earth the exception, not vice versa. The published-works exception sorta, kinda does this, but published works are not the only cases where capitalization after a hyphen is the norm. You have observed yourself that almost all of our FA sample falls under "exceptions"; if everything is an exception, that means they are not exceptions but the norm.
Responding to more specific points of your response, I was not implying that FAs were the gold standard for interpreting the MoS (though I should note that WP:FA? does have an MoS compliance requirement, #2). As for Three-Fifths Compromise in particular, I am well aware that some sources use all-lowercase, but as I noted in my previous comment, this is not WP:CONSISTENT with Category:Political compromises in the United States. With that being said, I realize a hypothetical RM would have a 50/50 chance of passing given the clash between PAGs (AT is actually policy and MoS a guideline, but MoS warriors certainly are not going to let this go without a fight).
InfiniteNexus (talk) 18:26, 3 December 2023 (UTC)
I guess that's one way to look at it, but it is not the way I look at it. We have a general, across-every-topic-for-every-reason, default that we do not capitalize that which is not capitalized in a strong majority of independent sources. We could just stop there. The cases you are generally concerned about (trademarks and work titles) would mostly qualify as capitalized after the hyphen in a strong majority of sources. And they still will qualify even if we also say something specific like "Generally don't capitalize after a hyphen except when a proper name follows the hyphen". It's simply not broken. This discussion, however, opened with Three-fifths Compromise, which is neither a trademark nor a work title, and which turns out to not be consistently treated as a proper name in RS, so should not be capitalized anyway, but rendered "three-fifths compromise", mooting the concern in the first place.
When exceptions to a rule exist for completely unrelated reasons that does not constitute "an exception", confusing dissimilar things into one fictional category, so it cannot be exceptionality so common that it's really the norm. That's equivalent to saying that because it's okay for police to shoot criminals under various circumstances, armed forces to kill lots and lots of people in military conflicts, home-owners (in many if not most jurisdictions) to kill home invaders, and taken all together these exceed the murder rate, that the laws against homicide are wrong because killing people for these unrelated exceptions exceeds the norm against murdering people and has become the new norm. We have laws against murder because killing people for reasons that don't fall under one of those exception is something that shouldn't happen, and we have a lower-case-by-default rule because capitalizing things for reasons other than enumerated exceptions is something that shouldn't happen.
FA having a requirement to have a lead that properly summarizes the article and to be divided sensibly into sections (and to have a consistent citation style, which is not an MoS matter but a WP:CITEVAR one) is not FACR having an actual and enforced rule to follow MoS (except on two "how to not write terribly" basics that would be in there even if MoS didn't exist at all). If you actually read FAC discussions over the last decade or so, they are a morass of argument against MoS compliance.
Various other things in Category:Political compromises in the United States probably also need renaming to lower case for the same reason. WP:CONSISTENT is not a tail that wags the dog. Our article titles should be consistent to the extent that is practical, after they conform to various applicable policies and guidelines; they are not made to thwart those P&G just to be consistent temporarily with titles that themselves are wrong per the P&G. And the underlying notion that everything in a category that contains some articles on things that are treated as proper names means that they must all be proper names is clearly not tenable. See, e.g., Category:Political movements and all its many subcategories; on a portion of what is contained in them are proper names (and some things in them that are presently capitalized should not be, though many of these have been cleaned up over the last few years). We don't go capitalizing all of them, especially when MOS:DOCTCAPS is a specific rule against doing that. Maybe more the point, WP:AT has nothing to do with capitalization and never has; that's a style matter determined by MoS concerns. People get confused about this because the MOS:CAPS rule to capitalize [only] when the vast majority of the RS do so is superficially similar to WP:COMMONNAME (which again has nothing to do with style of a name; it's the policy to choose Foo over Bar if Foo is the most common name, without any regard at all to whether in a particular case it is rendered Foo, foo, F-oo, f-oo, F oo, f oo, etc. only with regard to it not being some variant of Bar).
"MoS warriors certainly are not going to let this go without a fight"? You're the one who approached this from a "the guidelines are wrong and I must change them to suit my views" battleground position, and there is no RM discussion in the entire history of that article and its talk page. What did happen is one editor inappropriately used WP:RMSPEEDY in 2011 to move it from the correct title Three-fifths compromise to Three-Fifth Compromise against three guidelines (MOS:CAPS, WP:NCCAPS, MOS:HYPHEN), and the responding RM admin should have refused because this would automatically be a controversial move; and much later, following MOS:HYPHEN but just assuming in good faith that this was actually a proper name, I moved it to Three-fifths Compromise. But I'm the one you're upset at? This comes across as another of those "give me capital letters or give me death" things, the sort of activity that the MoS regulars refer to as "style warrior" behavior: pursuing disruptive battles against MoS guideline compliance for personal style peccadillo reasons. But you want instead to pretend that people applying the guidelines as they are written are the "warriors"? When there has been zero activity to de-capitalize this as not a proper name, in the entire 18-year history of the article? Please.  — SMcCandlish ☏ ¢ 😼  04:15, 4 December 2023 (UTC)
I did not call you an MoS warrior. I said that if I were to open an RM for Three-Fifths Compromise on the grounds of WP:CONSISTENT, there would likely be backlash from MoS warriors who insist MOS:CAPS takes precedence over WP:CONSISTENT. As for your murder rate example, I look at this way: we have a general rule that you should not kill people (capitalize after a hyphen). However, if you are a police officer (title of a work), soldier (trademark), or a homeowner whose home is being invaded (other proper nouns), you are permitted to use deadly force (capitalize after a hyphen) unless the circumstances do not call for it (unless the overwhelming majority of sources say otherwise). Under the current wording of MOS:HYPHEN and its associated guidelines, police officers (titles of works) are already exempted, which you are apparently against, and I am saying this exemption should be extended to soldiers and homeowners (other proper nouns).
Clearly, we do not agree on what is and should be the norm, so I will not pester you further unless you feel additional discussion is warranted. I haven't decided whether it is worth my time and energy to start an RfC, but considering the limited time I have on my hands, as well as my other more important on-wiki commitments, I am probably just going to let this go for now (not ruling out revisiting this in the future, should it ever come up again). Thank you for the ... spirited debate. InfiniteNexus (talk) 05:07, 4 December 2023 (UTC)
"Other proper nouns" that are capitalized that way near-uniformly in RS are already exempted, by the very fact that they are capitalized that way near-uniformly in RS. One that is not captitalized that way near-uniformly in RS should not be exempted, or MOS:CAPS would not say what it does. This also actually applies to trademarks, and also always applied to titles of works until two individuals POLICYFORKed the material in two places (that don't even agree with each other!). What obviously needs to happen is for the material to be re-normalized back to "do not capitalize something unless it is capitalized in a strong majority of RS". What you want to do is take an alleged exception that doesn't categorically exist (trademarks) and another alleged exception that two editors made up out of nowhere but can't actually agree on, and use this doubly cracked foundation as a rationale to invent a third and even broader category of alleged exception. So, yes, I'm not going to agree with that, and I don't think much of anyone else will either, other than a handful of the same actual "style warriors" who just hate MoS in general or at least MOS:CAPS because they are not getting their pet-peeve preference that they perpetually re-re-re-litigate, on some WP:SSF or WP:CSF matter.  — SMcCandlish ☏ ¢ 😼  05:19, 4 December 2023 (UTC)
I already responded to this argument above. I said that what is currently being evaluated on a case-by-case basis (whether to capitalize) should be flip-flopped with the default (whether to not capitalize). You responded with the murder-rate analogy, which I replied to, and now you're repeating your claim that whether to capitalize should be determined on a case-by-case basis, despite the fact that most sources capitalize the word after a hyphen in proper nouns. Would you like to explain why you think we should ignore the norm and take MOS:CAPS as gospel, ignoring common sense? InfiniteNexus (talk) 05:40, 4 December 2023 (UTC)
That's one of those "have you stopped beating your wife?" constructions. We have a general principle at MOS:CAPS; it is expressed in narrower form in various other places, including MOS:HYPHEN, though some people have been screwing around inconsistently with the language there and this needs to be repaired. There are lots of other places the same "don't capitalize unless all the sources are doing it" principle is also expressed and employed (all throughout MoS, really). It is consistent and well-understood, even if a handful of editors WP:DONTLIKEIT because they like over-capitalizing things to better match what they are used to in ornithology journals or video-gamer websites or dog-breeding magazines or train-spotting fandom forums or whatever the specialized-style fallacy is. Then you come along and want to create a complicated counter-rule, to always capitalize after a hyphen by default for any kind of proper name (when you have to know by now that WP editors spend more time arguing about what is and is not a proper name than doing much of anything else, and that's even how this thread started to begin with). This would be confusing and divisive, set up a [further] conflict between guidelines, be abused as a wedge to drive more capitalization into the project for all sorts of other things, and cause various other problems. Meanwhile, the end result for the titles you care about would not change in any way: the ones that should be capitalized after a hyphen, because they are treated this way near-universally in independent sources, would be capitalized after a hyphen here, under both scenarios. You would cause a truckload of trouble for no practical gain of any kind.  — SMcCandlish ☏ ¢ 😼  05:59, 4 December 2023 (UTC)
I am aware of the MoS's general preference for lowercase, but there are exceptions listed under almost every single MoS guideline — why shouldn't there be one for hyphens? What MOS:TITLECAPS currently says about capitalization after a hyphen is true: almost nobody does it in titles of works, and I'm arguing that the same can be said for other proper nouns. And no, there would be practical gain: outliers such as Three-fifths Compromise (assuming we treat it as a proper noun) and Ninety-five Theses would be moved to be in line with Spider-Man, Quasi-War, and Nineteen Eighty-Four, unless it is proven that the overwhelming majority of sources do not use a capital letter. InfiniteNexus (talk) 06:29, 4 December 2023 (UTC)
There shouldn't be one for hyphens because they are applied for completely different reasons in different cases, and because of MOS:BLOAT. We do not need to record in MoS every time consensus comes to some kind of exception decision in a particular case, or MoS would be ten times longer and would look like nothing but a morass of exceptions and no general rules, thus defeating its purpose. But you're arguing for a broad "mega-exception" across an entire set of classes of cases. It isn't even true that lower-case after a hyphen is almost never done in titles of works. It tends not to be done in titles of movies and modern books (though there are exceptions) since it doesn't support marketing's love of capitalization to grab attention. But lower-case after a hyphen is common in article titles that are written in title case. I no longer have a collection of style guides filling up half my place, but I would bet good money there are citation styles that specifically demand lower-case after a hyphen except for a proper name. (At the other extreme are various content-management systems that automatically capitalize every single string in a title, with results like "Of" and "An" and "The" being capitalized in mid-phrase. Not something to emulate here.)
Your scenario about "Three-fifths Compromise (assuming we treat it as a proper noun) and Ninety-five Theses" would not be affected in any way by any of this at all; the first of these should provably move to three-fifths compromise (there is no "assuming we treat it as a proper noun" because it is already proven not to be one); and Luther's work would be determined by the exact same criteria under both systems: whether RS are near-consistent in capitalizing "Five").
If you're curious, they certainly are not: [2][3][4]. The prevalence of "Ninety-five Theses" without capital-F "Five" is strong evidence against your claim that sources nearly always capitalize after a hyphen in such titles. (It's also suggestive that some off-site style guides call for lowercase after a hyphen, or the style would not be so common (and WP's MoS wouldn't have come up with idea on its own), though which ones might do so would bear more direct research if someone wanted to insist on it. Ultimately it doesn't matter, because WP has its own style manual and is not dictated to by any particular external publishers.) The only thing your position for "-Five" has going for it is that in recent books, "-Five" in this title has quite suddenly become more common than "-five" [5]. But it is not so overwhelmingly dominant that MOS:CAPS would be satisfied, especially given the very long history with "-five" dominating [6], and the recent (c. 2004 onward) spike in "-Five" probably being attributable to a particular publisher or a small handful of them (probably religious publishers given the nature of the subject matter, and so not independent of the subject), and quite possibly strongly influenced by WP itself (WP:CIRCULAR) because our article title had "-Five" until 3 May 2016 (and the n-gram data ends at 2019, so we can't see what's been happening in the 2020s)‎. The fact that our article on the subject dates (with "-Five") to right when the capitalization suddenly started increasing in books is very suspicious. Nor does this increase appear to be matched in other source types, since "-five" is still common in news, journals, and other results, including recently published ones (though we lack a means of getting solid satistical numbers on them; no one's made a large corpus of English that can be queried in this way except from book materials).
Questions like this should continue to be handled on a case-by-case basis of whether there is sufficiently consistent use of a capital letter in a largely majority of RS to warrant a divergence from the MOS:CAPS lowercase default. There's simply nothing special going on with titles: styles differ in the real world, we have a default style (like all major publishers do), and a divergence from it in a particular case should only be made because in that specific instance nearly all independent sources agree on that divergence. That's the general MoS treatment of everything, not just capitalization.  — SMcCandlish ☏ ¢ 😼  07:32, 4 December 2023 (UTC)

Chicago:

The following rules apply to hyphenated terms appearing in a title capitalized in headline style [...]

  1. Always capitalize the first element.
  2. Capitalize any subsequent elements unless they are articles, prepositions, coordinating conjunctions ([...]), or such modifiers [...] following musical key symbols.
  3. If the first element is merely a prefix or combining form that could not stand by itself as a word (anti, pre, etc.), do not capitalize the second element unless it is a proper noun or proper adjective.
  4. Capitalize the second element in a hyphenated spelled-out number (twenty-one or twenty-first, etc.) or hyphenated simple fraction (two-thirds in two-thirds majority).

The examples that follow demonstrate the numbered rules [...]

[...]
Record-Breaking Borrowings from Medium-Sized Libraries (2)
[...]
Anti-intellectual Pursuits (3)
A Two-Thirds Majority of Non-English-Speaking Representatives (3, 4)
[...]

APA:

In title case, capitalize the following words in a title or heading:

  • [...]
  • major words, including the second part of hyphenated major words (e.g., "Self-Report," not "Self-report")

MLA:

When you copy an English-language title or subtitle [...] use title-style capitalization: capitalize the first word, the last word, and all principal words, including those that follow hyphens in compound terms.

[...]

Do not capitalize the word following a hyphenated prefix if the dictionary shows the prefix and word combined without a hyphen.

Theodore Dwight Weld and the American Anti-slavery Society

AMA:

In titles, subtitles, and text headings, do not capitalize the second part of a hyphenated compound in the following instances:

If either part is a hyphenated prefix or suffix (see [...])

Nonsteroidal Anti-inflammatory Drugs for Ankylosing Spondylitis

If both parts together constitute a single word (consult [...])

Reliability of Health Information Obtained Through Online Searches for Self-injury [...]
Short-term and Long-term Effects of Violent Media on Aggression in Children
[...]

However, if a compound is temporary or if both parts carry equal weight, capitalize both words.

[...]
Low-Level Activity
Drug-Resistant Bacteria
[...]

In titles, subtitles, and text headings, capitalize the first letter of a word that follows a lowercase (but not a capital) Greek letter (see [...]), a numeral ([...]), a symbol, a stand-alone capital letter, or an italicized organic chemistry prefix, [...]

AP makes no mention of capitalization after a hyphen, but "The Star-Spangled Banner" is given as an example of a title (which we also capitalize, would you look at that).

InfiniteNexus (talk) 18:48, 4 December 2023 (UTC)

Seasons Greetings

Merry Christmas, SMcCandlish!
Wishing you Season's Greetings and a Happy Winter Solstice! As the year comes to a close, I want to express my appreciation for your dedicated efforts on Wikipedia and extend heartfelt thanks for your assistance throughout the years. May the holiday season bring you and your loved ones abundant joy, good health, and prosperity.

RV (talk) 09:06, 25 December 2023 (UTC)

Star (heraldry)

Hi, I was just going through and resolving "by whom" tags, and I came across a note you had left on a page (here). I haven't got access to the source, but it looks to me that the text is better without the hedging language ("it has been said"), but obviously, if it was put there because that is the language used by the source it should probably stay.

I know it's a long shot, but you don't remember why you put the note do you?

Best, BNS Boynamedsue (talk) 12:39, 27 December 2023 (UTC)

@Boynamedsue: I just put the cleanup tag there because the passage contained WP:WEASEL wording, presumably because someone was aware of a source that used mullet more broadly in a Scots heraldry context. Since no such source has been provided, and we have at least one high-quality source (Fox-Davies) stating it has only the more specific meaning in that context, your removal of the hedging seems the best course. Neither of us can magically make appear an alleged source we don't have that uses the term in a more general sense. :-)  — SMcCandlish ☏ ¢ 😼  22:58, 27 December 2023 (UTC)
Many thanks, that's sorted then. I suspect no such even exists, there are a lot of compulsive hedgers about... Boynamedsue (talk) 06:35, 28 December 2023 (UTC)

CITV Split

 Done

I have started a debate at Talk:CITV about whether former programming should be split into a separate article called List of programmes broadcast by CITV. Dwanyewest (talk) 14:24, 27 December 2023 (UTC)

Not my usual sort of topic, but I commented over there anyway. Gist: split would be good if the content is expanded to be more infomrative, but not if just kept as a bare list of show names.  — SMcCandlish ☏ ¢ 😼  23:20, 27 December 2023 (UTC)

Post-holiday followup

@InfiniteNexus: More research of the above sort is needed. To just dive in and do one bit of it, I find that MHRA Style Guide [7] has a ridiculously inconsistent rule to capitalize after a hyphen, even when it's a prefix that cannot stand alone, except when that prefix is specifically Re-. There is no rationale given for this weirdness. I think it would be worthwhile to look in other major style guides and see whether anything like a largely consistent pattern actually emerges. Your four American ones (at least two of which, APA and AMA, have been moving over time to be increasingly consistent with Chicago on many points) don't cover enough ground for us to be certain of this. And AMA is trying to be meaningful but failing dismally. "Short-term" and "low-level" are both the same kind of term; same goes for "self-injury" and "drug-resistant". They can all be split up without hyphens, without losing meaning: "A low level of drug resitance was observed over a short term in a study of patients admitted for self injury". (I guess this is what happens when medical people with no linguistics background try to write material about English-language structure and usage.) The unitary hyphenated compounds below cannot be split up this way (though some are sometimes colloquially written as hyphenless closed compounds: "knowhow" and "runnerup", but not "fatherinlaw").

Iff it turns out that there is a demonstrable lean across all major style guides, then we could probably encapsulate it with something simplified and easy to remember and apply, which might (more resesearch is needed) be something like:

In title case, capitalize after a hyphen when the compound is temporary (usually a multi-word modifier that would be written without hyphens if not used adjectivally): Real-Estate Demography, Remote-Control Operation, Common-Sense Guidelines. Do not capitalize after a hyphen if the term is a compound with:

  • a prefix (Pre-eclampsia, Anti-establishment), unless what follows the hyphen is a proper name Neo-Aristotelian;
  • a suffix (Dada-esque);
  • a compound with a synergistic meaning separate from that of its parts and which is almost always hyphenated (Father-in-law, Know-how, Runner-up).

A construction like this would avoid AMA's categorical confusion; avoid highly debatable ideas like "constitute a single word", "if both parts carry equal weight", "principal words", "major words"; avoid "the dictionary" nonsense (there is no such thing as "the" dictionary, but lots of dictionaries which often conflict with each other and have different levels of prescriptive versus descriptive approach); and avoid nitpicky geekery no one is apt to care about, like musical key symbols and italicized organic chemistry prefixes (we should not address minutiae like that unless long-term dispute arises about it, per WP:CREEP and WP:MOSBLOAT).

However, I find the "the second element in a hyphenated spelled-out number" very dubious, and same with "-century" constructions; I have seen many titles of things that use "Twenty-two", "Fifty-third", and "Fourth-century"; this is one of several cases that needs more investigation in more style guides. And in the end, we are not required to do what a loose preponderance of other style guides seem to lean toward, especially when they contradict each other as to details and rationales; they are just duly informative with regard to what we decide. But we do need to decide something, since the extant material at MOS:TITLES has a gap, and people are not agreeing on what fits inside it.

PS: Your "The Star-Spangled Banner" is given as an example of a title (which we also capitalize, would you look at that) smirking isn't constructive. You know as well as I do that WP content is not a source, and that editors doing stylistically questionable things at a particluar article has nothing to do with whether a style rule we have should be changed. More to the point, the style guides you quoted are not in agreement on it, and AMA for one would have it as "The Star-spangled Banner" because "star-spangled" is not a temporary compound but a poetic 18th-century neologism that is a unitary term and appears to have nearly no existence without the hyphen. MLA would also lower-case "-spangled" because of its dictionary rule [8].  — SMcCandlish ☏ ¢ 😼  01:43, 29 December 2023 (UTC)

If you are still interested in looking into this, feel free to so, but right now I do not have time to continue delving into this matter. The four (five, if counting AP) style guides I looked at are probably the most widely used in the U.S., so it seems safe to assume that this is the norm among most external style guides. I don't have access to style guides from other countries. InfiniteNexus (talk) 07:35, 29 December 2023 (UTC)

Feedback request: Wikipedia style and naming request for comment

Disregard
 – Already one this one, weeks ago. I wish the RfC bot could detect that and not leave redundant notices.

Your feedback is requested at Wikipedia:Requests for comment/Emoji redirects on a "Wikipedia style and naming" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 17:31, 2 December 2023 (UTC)

Feedback request: History and geography request for comment

 Done

Your feedback is requested at Talk:Battle of Bakhmut on a "History and geography" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 06:30, 3 December 2023 (UTC)

Feedback request: Biographies request for comment

Disregard
 – I just skipped that WP:1AM mess, since no input from me was needed.

Your feedback is requested at Talk:Christopher Columbus on a "Biographies" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 07:30, 4 December 2023 (UTC)

Speedy deletion nomination of Category:Sports facilities and venues task force articles

Resolved
 – Someone jumping the gun on a just-created category before it had time to populate.

A tag has been placed on Category:Sports facilities and venues task force articles indicating that it is currently empty, and is not a disambiguation category, a category redirect, a featured topics category, under discussion at Categories for discussion, or a project category that by its nature may become empty on occasion. If it remains empty for seven days or more, it may be deleted under section C1 of the criteria for speedy deletion.

If you think this page should not be deleted for this reason you may contest the nomination by visiting the page and removing the speedy deletion tag. Liz Read! Talk! 08:08, 4 December 2023 (UTC)

Wow

I made your "Smartest things I've seen on Wikipedia list". I'm honoured. Lee Vilenski (talk • contribs) 12:39, 4 December 2023 (UTC)

Thought that adding your user name would have pinged you, but glad you saw it and found it a nice surprise. :-)  — SMcCandlish ☏ ¢ 😼  13:18, 4 December 2023 (UTC)
No pings (or at least not one that I saw). I'm a big proponent of making the MOS/policy into best practice and not dumbing it down just because it often gets flouted. Lee Vilenski (talk • contribs) 19:21, 4 December 2023 (UTC)
I guess the ping parser doesn't do its thing when the username link is followed by a pre-existing timestamp, probably to stop it going off when discussions are copy-pasted from active talk pages to archives.  — SMcCandlish ☏ ¢ 😼  01:46, 5 December 2023 (UTC)

Editor experience invitation

 Done

Hi SMcCandlish :) I'm looking to interview people here. Feel free to pass if you're not interested. Clovermoss🍀 (talk) 13:08, 4 December 2023 (UTC)

Vertical entries in tables

Running this past you first before raising it at Wikipedia talk:Manual of Style/Dates and numbers, but Bringhurst would be scathing about the table "General guidelines on use of units" at MOS:UNITNAMES. He writes " All text should be horizontal, or in rare cases oblique. Setting column heads vertically as a space-saving measure is quite feasible if the text is in Japanese or Chinese, but not if it is written in the Latin alphabet."[1] I don't actually know but it seems very likely that a screen reader would barf at the Aspect column. Shall I raise it? I don't have an easy solution, unfortunately?

More generally, is there an MOS advice deprecating vertical column heads? --𝕁𝕄𝔽 (talk) 16:33, 4 December 2023 (UTC)

References

  1. ^ Bringhurst, Robert (2004). The elements of typographic style (third ed.). Seattle: Hartley & Marks. ISBN 978-0-88179-206-5.

𝕁𝕄𝔽 (talk) 16:33, 4 December 2023 (UTC)

@JMF: MOS:TABLES doesn't include the word "vertical" in it. MOS:ACCESS does, but none of the occurrences address this. The style is well-attested in the real world, on paper (I've seen it even in things like census tables as far back as the early 19th century and it's probably older than that), but is ultra-rare on WP and on other websites because of its readability problems. I suspect that it poses accessibility issues, though not all of them that one might imagine (screen readers aren't doing an OCR-style scan of the page, but operating on the HTML elements in the page source). There's also a WP:NOTPAPER argument to make about it; we have no dire need to save space (and the "solution" is to just make a normal horizontal header, and if something in one is long, use forced line-breaks in it or use CSS width controls on the columns). However, Help:Tables#Vertically oriented column headers is a whole section of instructions on how to do vertical headers like this, and there is a template, {{Vertical header}} for doing it. It appears to me that the guidelines have never addressed this because the feature wasn't available until HTML 5 and CSS 3; the guidelines have not caught up because this is done so rarely and there's been so little discussion/dispute about it, it hasn't bubbled up to guideline-level discussion.
I think I would raise concerns about this at WT:MOSTABLES, and post a pointer to that discussion at WT:MOSACCESS, Help talk:Table, Template talk:Vertical header, and maybe WT:MOSNUM, as well as an entry in the discussion list at the top of WT:MOS.  — SMcCandlish ☏ ¢ 😼  02:02, 5 December 2023 (UTC)
 Done See Wikipedia talk:Manual of Style/Tables#Proposal to discourage vertically oriented ("sideways") column headers. Thank you for your advice: you will doubtless recognise some plagiarism of your reply above, thank you. --𝕁𝕄𝔽 (talk) 17:10, 6 December 2023 (UTC)
Will check it out.  — SMcCandlish ☏ ¢ 😼  03:56, 7 December 2023 (UTC)

Feedback request: History and geography request for comment

 Done

Your feedback is requested at Talk:Ezra Pound on a "History and geography" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 06:30, 6 December 2023 (UTC)

Formats for citing sources

First, I love what you wrote on this page: "My fault? If I've screwed up and broken something, say so and why/how; I'll probably see that I've erred, and will at least acknowledge that you've raised an objection. (Less hostility and more information will work better.)" Some complain that Wikipedia is getting hostile to editors, but we are ALL fallible. Thanks for reminding us all of that.

Regarding my recent edit on "Proverb", you suggested using a type of formatting when citing a source. However, I find it awkward, and it's not required: https://wiki.riteme.site/wiki/Wikipedia:Citing_sources. Hope my edits help people learn. Hope my edits are gracious. Pete unseth (talk) 01:23, 8 December 2023 (UTC)

Sure, it's not required, but it's standard and needed – or at least a manually formatted, non-templated citation is needed that uses the same citation-facts order as the rest of the citation output on the page that is received by the reader. (One of the fantastic things about the citation templates is they output the consistent citations no matter what order you put the parameters in.) Otherwise, your're just making a very confusingly inconsistent and hard-to-parse citation for no good reason, which someone else will have to clean up later. The lack of a rule forcing you to do something helpful isn't a compelling rationale to not do the helpful thing, as it were. The citation parameter names are pretty intuitive (except for some unusual ones). That said, of course it is better to cite a source even in suboptimal formatting than not cite one at all. PS: Sorry if the edit summary came off as testy or commanding; when plowing through the watchlist, one sometimes isn't ideally mindful about the wording, especially in such a short form.  — SMcCandlish ☏ ¢ 😼  01:35, 8 December 2023 (UTC)
Thanks for your explanation. We both edit under our real names and we both know that we cannot please everybody, not even ourselves. Merry Christmas! Pete unseth (talk) 19:17, 8 December 2023 (UTC)
True enough!  — SMcCandlish ☏ ¢ 😼  03:42, 9 December 2023 (UTC)

Sort keys and case-insensitivity

Regarding Special:Diff/1188842740. Just for your information, sort keys are case-insensitive on the English Wikipedia since the middle of 2011 (source 1, source 2: 5.3.1.0 ... 23 July 2011 ... Do not add DEFAULTSORT if case insensitively the same as article title, now that Mediawiki sort keys are case insensitive). For an example, see User:SMcCandlish/sandbox, User:andrybak/sandbox, and Category:X2. —⁠andrybak (talk) 22:25, 8 December 2023 (UTC)

Well, I'll be. I had no idea. Meanwhile, I've encountered sort keys intentionally applying uppercase changes on purpose the entire time. Looks like a lot of sort keys need to be removed as just "noise" at this point.  — SMcCandlish ☏ ¢ 😼  04:15, 9 December 2023 (UTC)

Question

Hi, I would like to dedicate this month's token question (I promised to do one every 30 days) to asking you a few things about cursive. I want to reassure you that I'm no longer thinking about italics, the two pages I will list below are pages I made changes to a month ago or more; I would like to ask you if "canzone napoletana" and "pizzeria" (and while we're at it, "pizzaiolo" too) should be put in italics. Thanks in advance. JackkBrown (talk) 05:23, 10 December 2023 (UTC)

Both "pizza" and "pizzeria" are fully assimilated into English as everyday terms; canzone napoletana and pizzaiolo are not, so should be in {{lang|it|...}} markup to italicize and language-identify them.  — SMcCandlish ☏ ¢ 😼  10:07, 10 December 2023 (UTC)

Feedback request: Biographies request for comment

 Done

Your feedback is requested at Wikipedia:Village pump (policy) on a "Biographies" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 19:32, 10 December 2023 (UTC)

Nomination of MOS:VARS for deletion

 Done
A discussion is taking place as to whether the article MOS:VARS is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/MOS:VARS until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article until the discussion has finished.

Fram (talk) 16:54, 12 December 2023 (UTC)

Feedback request: Politics, government, and law request for comment

 Done

Your feedback is requested at Talk:Javier Milei on a "Politics, government, and law" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 23:30, 13 December 2023 (UTC)

A barnstar for you!

The Guidance Barnstar
Thanks for helping fight policy creep and forks by proposing the merge of WP:SELFSOURCE and WP:BLPSELFPUB with WP:ABOUTSELF. {{u|Sdkb}} talk 06:11, 15 December 2023 (UTC)
Thank you!  :-)  — SMcCandlish ☏ ¢ 😼  14:59, 15 December 2023 (UTC)

Tevis

Glad I'm not the only Walter Tevis fan. Have you read Mockingbird? It's prophetic. Coretheapple (talk) 20:45, 17 December 2023 (UTC)

I haven't, actually! Maybe I should check it out.  — SMcCandlish ☏ ¢ 😼  21:03, 17 December 2023 (UTC)
You won't be sorry. Coretheapple (talk) 21:15, 17 December 2023 (UTC)

Wikipedia talk:Naming conventions (television)#Move TV seasons from parenthetical disambiguation to comma disambiguation

Moved to Wikipedia talk:Naming conventions (television)#Follow-up RfC on TV season article titles

The discussion was closed as "rough consensus to change from parenthetical disambiguators, however, there was no clear consensus for any of the options brought up during the discussion", with a call for an RfC on a replacement. I think there was actually a consensus for moving to no punctuation, and have expressed that to the closer, but absent some retroactive amendment to that decision, I guess our next step is to craft an RfC (but a better one than was proposed in the close). I raise this here because I think you were the most active participant in the discussion, but also pinging @Tavix, Bkonrad, Hyperbolick, StarTrekker, Alex 21, LaundryPizza03, and Bilorv:. BD2412 T 04:31, 18 December 2023 (UTC)

Well, sometimes a guideline change takes a two-round RfC process. It's a butt pain, but not the end of the world. Personally, I'm not in favor the no-punct option, but that really doesn't have anything to do with whether the closer assessed it well. If it's not stark-obviously a bad close, it's probably better to just do a followup RfC than to try to get AN to overturn the close and re-close it. That way lies drama.  — SMcCandlish ☏ ¢ 😼  04:42, 18 December 2023 (UTC)
Just to note, I don't take it personally and there would be no drama from me if folks wanted to go the AN close review route. voorts (talk/contributions) 00:06, 19 December 2023 (UTC)
Something like the closer's formatting would work, as it honed down the three most popular options aside from the status quo, but it would be most clear with a table of specific examples for disambiguated and non-disambiguated TV series titles. –LaundryPizza03 (dc̄) 04:48, 18 December 2023 (UTC)
Like this:
Options
No. Description Example 1 Example 2
1 Status quo The Simpsons (season 8) Hawaii Five-0 (2010 TV series, season 10)
2 Comma after series name The Simpsons, season 8 Hawaii Five-0 (2010 TV series), season 10
3 Space after season name The Simpsons season 8 Hawaii Five-0 (2010 TV series) season 10
4 Colon after season name The Simpsons: season 8 Hawaii Five-0 (2010 TV series): season 10
–LaundryPizza03 (dc̄) 04:56, 18 December 2023 (UTC)
Yep, that would be helpful.  — SMcCandlish ☏ ¢ 😼  04:57, 18 December 2023 (UTC)
If there is already consensus to move away from the status quo, does it really need to be an option? BD2412 T 14:17, 18 December 2023 (UTC)
It's actually helpful to see how bletcherous the status quo really is. E.g., all through that discussion I always had examples like "The Simpsons (season 8)" in mind, and the awfulness of "Hawaii Five-0 (2010 TV series, season 10)" wasn't really clear. If there's already a consensus to move away from that, then listing it again would be harmless; or it could be put above the table as a status quo line and not numbered as an option.  — SMcCandlish ☏ ¢ 😼  15:46, 18 December 2023 (UTC)

PS: I just reviewed the re-close by Voorts [9], in which an options list kinda-sorta like the above table is shown, but which lacks the helpful examples and neither includes a status quo option nor includes the status quo as a non-option. I would thus propose more clearly to use this:

 

The status quo results in article title examples like these: The Simpsons (season 8) and Hawaii Five-0 (2010 TV series, season 10) and Dancing with the Stars (South Korean season 3).

There is a consensus to change away from this, but not yet a consensus on what to replace it with. The options are:

Options
No. Description Example A Example B Example C
1 Comma after series name The Simpsons, season 8 Hawaii Five-0 (2010 TV series), season 10 Dancing with the Stars (South Korean TV series), season 3
2 Space after series name The Simpsons season 8 Hawaii Five-0 (2010 TV series) season 10 Dancing with the Stars (South Korean TV series) season 3
3 Colon after series name The Simpsons: season 8 Hawaii Five-0 (2010 TV series): season 10 Dancing with the Stars (South Korean TV series): season 3

 

(Also fixed two "season" for "series" typos.)  — SMcCandlish ☏ ¢ 😼  23:59, 18 December 2023 (UTC)

This is way better than what I proposed, although I still think that the an example(s) with nationality and/or nationality+year should be added. voorts (talk/contributions) 00:09, 19 December 2023 (UTC)
Didn't think of that. Have an example in mind? Short would be better, to keep the table concise.  — SMcCandlish ☏ ¢ 😼  00:11, 19 December 2023 (UTC)
Dancing with the Stars (South Korean season 3). The examples should also have italics for the series' names, no? voorts (talk/contributions) 00:21, 19 December 2023 (UTC)
A bit long; will see if I can find a shorter one. As for italics, this is strictly about the page title, and the italics might confuse people into thinking it has something to do with in-article writing about and linking to seasons.  — SMcCandlish ☏ ¢ 😼  01:04, 19 December 2023 (UTC)
Didn't really find a shorter example (lots of such ambiguous-title shows but most don't have their own season articles), so I integrated that one into the table above. It is good to include, since it wasn't obvious that in these unusual cases the title will actually be lengthened.  — SMcCandlish ☏ ¢ 😼  01:14, 19 December 2023 (UTC)
I took a look at the guidelines, and naming conventions apply to article titles, not page names, so it should be displayed as italics. For the article Random Television Show Title, season 1, it would be displayed using: {{Italic title|string=Random Television Show Title}}. voorts (talk/contributions) 01:47, 19 December 2023 (UTC)
I understand that at the actual article we'd have an italic-title template in it; but doing it here would potentially confuse what the issue is, that we're talking about the strings that are used to build the article title, not how text is formatted inside articles.  — SMcCandlish ☏ ¢ 😼  01:51, 19 December 2023 (UTC)
Shouldn't participants see how it would actually appear as the article title? Some of the concerns in the prior discussion were regarding readability. voorts (talk/contributions) 01:56, 19 December 2023 (UTC)
I put the italics in, and hope this doesn't confuse the issue in the long run.  — SMcCandlish ☏ ¢ 😼  02:04, 19 December 2023 (UTC)
Shall we move forward with this? Having undertaken the initial discussion, I don't think I should be the one to launch the RfC. BD2412 T 19:50, 24 December 2023 (UTC)
Done, at Wikipedia talk:Naming conventions (television)#Follow-up RfC on TV season article titles. "Advertised" the RfC to various pertinent project pages.  — SMcCandlish ☏ ¢ 😼  22:53, 27 December 2023 (UTC)

Getting rid of {rp}

Applause! Now tell me how to get round wp:CITEVAR objections like this one: Talk:Eric Gill/Archive 1#Proposal to change citations of McCarthy's books to use harvard referencing and Talk:Eric Gill/Archive 1#Page number citations are expected when the source is a substantial book. I had hoped to get the Eric Gill article up to GA standard but I am too much of a secret typographer to put my name to a GAN, given its current spider-crawled-in-the-ink appearance. Sigh. 𝕁𝕄𝔽 (talk) 20:03, 18 December 2023 (UTC)

@JMF: I think in the Gill case (if I'm reading it right), the other party's objection was to inline parenthetical referencing with page numbers, which the community also deprecated already, i.e. doing things like "This is a claim (Smith 2023, p. 7).", instead of "This is a claim.<ref>Smith 2023, p. 7.</ref>", or the templated equivalents "This is a claim.<ref>{{harv|Smith|2023|p=7}}</ref>", or "This is a claim.{{sfn|Smith|2023|p=7}}". It's actually possible that 14GTR was literally opposed to ever including page numbers in any form, in which case his argument has no WP:P&G legs to stand on and should just be ignored.
Sudden flash of possible insight: A strong case can be made that because the community did clearly deprecate inline parenthetical referencing in 2020 (WP:PAREN), and the rationale for doing so was its reading-flow disruptiveness, not the fact that round-bracket characters were involved, this actually translates automatically to a deprecation of {{Rp}} as well. It is simply another format for doing inline parenthetical referencing (its own documentation states explicitly that it's an adaptation from "full Harvard referencing and AMA style", though ultimately this is me quoting myself), just with fewer details and using superscript and colon, instead of more details with round brackets and no superscript or colon. That is, the deprecation is of citations that are inline and parenthetical, not inline and using what Americans call parentheses (round brackets). So, replacing "This is a claim (Smith 2023, p. 7)." but retaining "This is a claim<ref>Smith 2023.</ref>{{Rp|7}}" to produce "This is a claim.[1]:7" is simply defying that site-wide consensus by still putting part of the citation (page numbers or other in-source locations) inline parenthetically – especially given that the template can be used to produce things like "This is a claim.[1]:viii–xiv, 7–9, 12, and back cover". Indeed, Wikipedia:Citing sources#Generally considered helpful already includes "converting parenthetical referencing to an acceptable referencing style". So, you could actually try that argument right now in doing cleanup of {{Rp}}.
Because of the "let chaos reign" stupidity that is WP:CITEVAR, some people are probably apt to try to argue against this, but I think their case will be weak and easily deflated. That said, probably the only path to total cleanup is going to be really fully documenting how to convert {{Rp}} into other formats, and why it is a good idea, and why {{Rp}} is bad, and then have a follow-up RfC or TfD to formally deprecate {{Rp}} and mandate its replacement (mostly by AWB and sometimes even by bots for simple cases), so that it is no longer considered a valid "citation style" for CITEVAR purposes, no question about it. And I think the work in doing that documentation is going to be in my lap, though I'm not over-eager to wade into it right this second. It gives me a headache just thinking about it.  — SMcCandlish ☏ ¢ 😼  21:04, 18 December 2023 (UTC)
The stonewall response was much as I expected though I had hoped that time and the offer of a ladder to climb down might just do the trick. AFAICS, the only way forward is to formally propose that {{rp}} be deprecated in favour of harvard referencing. Trouble is, when I tried to use the {{harvid}} method way back, I found it hostile. I persisted and matters much improved when I found {tl|sfnp}}. But other editors may have had their fingers burned and will resist, based on their bad experience way back when. So preparing the ground with explanation and education may be needed? --𝕁𝕄𝔽 (talk) 20:00, 20 December 2023 (UTC)
Took me "a minute" to figure it out, too. I've started the slog of fully documenting how to replace {{rp}}, at User:SMcCandlish/Replacement of Template:Rp. Still needs some more info in it, and proofreading for any markup errors that mess up any of the code examples.  — SMcCandlish ☏ ¢ 😼  09:46, 21 December 2023 (UTC)

Incremental updates

Update: This is going very slowly, but I'm committed to working on it. It's going to require a bunch of very well-tested regular expressions, used in series in a JS user script, to catch and clean up a large number of content use cases, so that it produces uniform citation formatting (and without breaking anything). My earlier-documented work toward that at the page mentioned above has already been surpassed, in code I'm developing off-site. I'll start building the regexes I'm working on into a JavaScript pretty soon and start testing that against real content and refining it. After it reliably works for all valid and most sane but invalid test cases, then we'll be able to do search–replace operations against {{rp}} that will have predictable results with minimal errors. This is going to be a big project. It was more difficult than I expected because XML syntax (much less XML mixed with a {{...}} syntax!) is incredibly difficult to parse accurately with regex (or anything else for that matter) reliably. I've been using advanced tools like regex101.com with complex blobs of valid and invalid test-case input, and using ChatGPT to try to work out particularly thorny matching failures, and so on. As an example, just one of the regexes developed so far looks like <ref\s+name\s*=\s*(?:"\s*([^"](?:(?!\s*\/>|\s*"\s*>|\s+(?:group|follow|extends)).)*?)\s*"|'\s*([^'"](?:(?!\s*\/>|\s*'>|\s+(?:group|follow|extends)).)*?)\s*'|([^"](?:(?!\s*\/>|\s*>|\s+(?:group|follow|extends)).)*))\s*(?:(\/)|)>, and even this cannot yet handle <ref name=foo group=bar> to normalize the name= part, only to avoid breaking a ref that has a group= part (and it does not do anything to normalize the latter part yet, only the former).  — SMcCandlish ☏ ¢ 😼  00:06, 28 December 2023 (UTC)

It now parses even stuff like <ref group="bar's > / bar" extends=baz name='foos > / foo' follow="quux quux" /> (and some of the code it's accounting for is only in the beta of mw:Help:Cite and not deployed on en.WP yet), though this one regex only fixes up the name= parameter; other passes with similar regexes would handle other attributes like group= to normalize their formatting. Then another pass to fix spacing that shouldn't exist between citations. And so on. And of course a pass to replace {{rp}} with {{sfnp}} or whatever. Like I say, a multi-step process that'll be done by using the regexes in JS. The regex in question is now the monstrous <ref\s+((?:group|follow|extends)\s*=(?:(?!name\s*=).)*)?name\s*=\s*(?:"\s*([^"](?:(?!\s*\/>|\s*"\s*>|\s+(?:group|follow|extends)).)*?)\s*"|'\s*([^'"](?:(?!\s*\/>|\s*'>|\s+(?:group|follow|extends)).)*?)\s*'|([^"](?:(?!\s*\/>|\s*>|\s+(?:group|follow|extends)).)*))(\s+(?:group|follow|extends)\s*=(?:(?!\s*\/>|\s*>).)*)*\s*(?:(\/)|)>. I'm suprised I pulled this off. Its one failure is that it can't gracefully handle the XML-valid (but technically ref-invalid) form name='foo "bar" baz' (single-quoted value with nested double quotes) or the completely invalid name="foo "bar" baz">; that's something that'll need to be handled by an earlier cleanup pass that looks just for those specific problems.  — SMcCandlish ☏ ¢ 😼  02:02, 28 December 2023 (UTC)
Regex upgraded again, to handle line-breaking between <ref> attributes, as well as > inside quoted attributes after name=.
The new regex (just for handling name with or without other attributes present) is: <ref\s+((?:group|follow|extends)\s*=(?:(?!name\s*=)[\s\S])*)?name\s*=\s*(?:"\s*([^"](?:(?!\s*\/>|\s*"\s*>|\s+(?:group|follow|extends)).)*?)\s*"|'\s*([^'"](?:(?!\s*\/>|\s*'>|\s+(?:group|follow|extends)).)*?)\s*'|([^"](?:(?!\s*\/>|\s*>|\s+(?:group|follow|extends)).)*))(\s+(?:group|follow|extends)\s*=(?:(?!\s*\/>|"\s*>|'\s*>)[\s\S])*)*\s*(?:(\/)|)>
It is already sophisticated enough to handle input as awful as:
<ref group=
      "bar's > / bar"
     extends=
      baz
     name=
      '
      foos > / foo
      '
     follow=
      "quux > quux"
 />
Even <syntaxhighlight> can't deal with the above, but what I'm writing can. This one just cleans up name (to name="foos > / foo" from the above mess, and gets rid of the line break before the closing /> while we're at it); similar regexes in later passes will deal with group, etc., then eventually {{rp}} replacement.  — SMcCandlish ☏ ¢ 😼  03:27, 29 December 2023 (UTC)
Reminder to self: At some point, the script will also have to account for {{#tag:ref |Citation content here. |name=... |group=... |follow=... |extends=...}} (with parameters in various order and with or without linebreaks and extraneous spacing).  — SMcCandlish ☏ ¢ 😼  03:37, 29 December 2023 (UTC)

Intervene?

Have you seen Help talk:Citation Style 1/Archive 92#Automating conversion of REF-plus-Rp to Sfn((m)p)? Do you want to launch a teaser trailer? Your call. --𝕁𝕄𝔽 (talk) 18:22, 28 December 2023 (UTC)

@JMF: Done.  — SMcCandlish ☏ ¢ 😼  01:43, 29 December 2023 (UTC)

Vauthors

Possibly telling people how to write harv citations is out of scope but I thought I should flag this one for you to include or ignore, your call. I've only just found the {{ref={{sfnref|blah blah}} }} facility and it is a lot more convenient that adding first=/last= to each and every name, just so you can write {{sfnp|last1|last2|last3|last4|2024}}. Here is a test example:

Up to you. --𝕁𝕄𝔽 (talk) 16:56, 29 December 2023 (UTC)

I'll need to account for |vauthors= in the documentation and scripting eventually. But |vauthors= should not be used except in an article entirely done in Vancouver-style references (or it's against WP:CITESTYLE's instructions to use a consistent referencing style). It's a poor idea to use that style in the first place because it outputs less-useful author metadata, and much more importantly is harder to parse for readers (it is less clear that something like "Tan LH" is an individual's name than "Tan, L. H." that matches the rest of our initials formatting and other name handling, most especially when "Tan LH" appears in an article otherwise using citations that output "Tan, L. H."), and it's more error-prone for editors because this weird name formatting must be done exactly perfectly in that parameter. Another serious fault with it is that we often actually know complete author names (and these can be quite helpful in distinguishing authors and even in finding the source in the first place if it's something without a free-to-read URL or DOI), but |vauthors= forces us to drop most of the name information we already have; it's a disservice to readers and to editors doing verification work. Any time I run into a |vauthors= in an article that is not consistently in Vanc style, I replace it with a set of |last1=|first1=... (unless I'm in a big hurry or something), often with more complete author names.

Using |ref={{sfnref|...}} a.k.a. |ref={{harvid|..}} isn't dependent in any way on |vauthors=.

Also, the Lua behind the citation templates can already parse the names inside |vauthors= (if they were done right) and use them with {{sfnp}}, {{harvp}}, etc., directly. If we remove the |ref={{sfnref|Wang ''et al''|2015}} from your example:

Here is a claim in the article.[1]

References
  1. ^ Wang et al. (2015).
Sources

Wang T, Mo L, Mo C, Tan LH, Cant JS, Zhong L, Cupchik G (June 2015). "Is moral beauty different from facial beauty? Evidence from an fMRI study". Social Cognitive and Affective Neuroscience. 10 (6): 814–23. doi:10.1093/scan/nsu123. PMC 4448025. PMID 25298010.

Just using the automated {{sfnp|Wang|Mo|Mo|Tan|2015}} is clearer and easier than using a |ref={{sfnref|Wang ''et al''|2015}} along with {{sfnp|Wang ''et al''|2015}}. And there doesn't seem to be a consensus that "et al." should be italicized as Latin, because it is so assimilated into English, like "i.e." and "e.g."; I don't think any of our citation templates italicize it. (But it should have a "." after it, italicized or not, even in British usage, since it's a truncation abbreviation, of et alia.) Even without the italics, just using the automated {{sfnp|Wang|Mo|Mo|Tan|2015}} is still clearer and easier than using a |ref={{sfnref|Wang et al.|2015}} along with {{sfnp|Wang et al.|2015}}.  — SMcCandlish ☏ ¢ 😼  23:23, 29 December 2023 (UTC)

Ah, I didn't realise that {{sfnp}} was able to deconstruct a vauthors list. I could have saved myself a lot of hassle. Now I've given myself some more hassle to redo it properly. ;-^
(I too prefer to change a vauthors list to |first1= last1= first2= last2= etc. Generally I avoid using it when creating a citation except when the authors are Chinese or Japanese but the article is in English: how do I know if it is last=Mao first=Tse Tung or vice versa? I confess to using it too when ten authors are listed, for example on IPCC papers.) --𝕁𝕄𝔽 (talk) 17:18, 30 December 2023 (UTC)
Well, like I said at the other page, no one's ever going to be "punished" for mixing citation styles. :-) Someone else just might rearrange it later. It can be a hassle. I got pretty irritated in fixing a vauthor instance stuck into an otherwise non-Vancouver article, as it had over 30 authors. I've seen someone reduce this to the first four last/first pairs then do |display-authors=etal, but I'm a little down on that because we had more author information and doing that deleted it. I think I'll whip up a script to convert from vauthors to last/first, at least for my own convenience, but probably after doing this big ref-cleaner and rp-replacer job first.

As for Asian names, I would guess just go by what the publication says; if it's "Chaudhary, C.; Richardson, A. J.; ...", and had a "Hua, X." or rarely but sometimes in Sinological material "Hua X" with no comma, in the author list, that already indicates the family-name order. But if the paper's author list started with "Chetan Chaudhary, Abigail Richardson, ..." and included something like "Hua Xiang" then it could be ambiguous; did they keep the same order, or give the Chinese names in surname-first order? I'm not sure vauthors would help here, since you wouldn't be sure whether to use "Hua X" or "Xiang H". Some familiarity with East Asian naming patterns helps. A name like "Hua Xhiangshu" or "Hua Xhian-shu" or "Hua Xiang-Shu" (orthography varies) would be family-name-first. People with more experience at it than I have can figure out Japanese names just by familiarity with which are usually given and which family names. Korean I'm generally at a loss with, unless it follows the Chinese pattern ("Lee Joon-gi" or "Lee Joon-Gi" or "Lee Joongi" is surname-first). It helps a little that a few Korean family names are overwhelmingly common, like Park/Pak/Paik, Lee/Li, Jun/Joon/June, Song/Sung, and Kim. When I'm unsure, I usually just Google around for other works by the same person until I can figure it out. If I could not at all, I would probably do |author4=Hua Xiang using the name order I had found (at all or most commonly) and leave it for someone with language/culture-specific experience to figure it out later. Maybe put in an HTML comment to this effect.  — SMcCandlish ☏ ¢ 😼  22:52, 30 December 2023 (UTC)

PS: As I understand it, the vauthors to sfnp/harvp "translation" uses the author names up to the first four. I'm not sure what happens when someone has a main cite with |vauthors=Chaudhary C, Richardson AJ, Hua X|display-authors=etal. I'm not sure if the latter is just a visual injection of "et al.", or whether it counts as a fourth author name and would require {{sfnp|Chaudhary|Richardson|Hua|et al.|2023}}. I suspect not, but something to test in a sandbox.  — SMcCandlish ☏ ¢ 😼  23:04, 30 December 2023 (UTC)

Merry Christmas!

A very happy Christmas and New Year to you!


Have a great Christmas, and may 2024 bring you joy, happiness – and no trolls, vandals or visits from Krampus!

Cheers

SchroCat (talk) 09:28, 18 December 2023 (UTC)

"Wikipedia:SPECTRUM" listed at Redirects for discussion

 Done

The redirect Wikipedia:SPECTRUM has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Anyone, including you, is welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 December 20 § Wikipedia:SPECTRUM until a consensus is reached. Headbomb {t · c · p · b} 01:17, 20 December 2023 (UTC)

New pages patrol January 2024 Backlog drive

New Page Patrol | January 2024 Articles Backlog Drive
  • On 1 January 2024, a one-month backlog drive for New Page Patrol will begin.
  • Barnstars will be awarded based on the number of articles patrolled.
  • Barnstars will also be granted for re-reviewing articles previously reviewed by other patrollers during the drive.
  • Each review will earn 1 point.
  • Interested in taking part? Sign up here.
You're receiving this message because you are a new page patroller. To opt-out of future mailings, please remove yourself here.

MediaWiki message delivery (talk) 02:10, 20 December 2023 (UTC)

Games

S, I know you're into games and their capitalizations, so take a look at List of abstract strategy games. I downcased a whole bunch of games listed there already, but there are a few I'm not sure what to do about, such as Connect Four, that might be trademarks, or might be generic. Do you have any insights or advice on those? Dicklyon (talk) 07:25, 20 December 2023 (UTC)

Will have a look-see, but am in middle of some detailed thangs.  — SMcCandlish ☏ ¢ 😼  09:29, 21 December 2023 (UTC)
@Dicklyon: For that one, we have an article title of Connect Four, and a lead that begins "Connect Four (also known as Connect 4, Four Up, Plot Four, Find Four, Captain's Mistress, Four in a Row, Drop Four, and Gravitrips". "Connect Four" does appear to be sourced as a Milton-Bradley (now Hasbro, after merger) trademark, along with the later "Connect 4" spelling. And in English, it is probably the WP:COMMONNAME even if we'd prefer otherwise. It is possible some of the other names are trademarks (or constitute titles of works in the form of commercially published variants of this game, more specifically), but would need to be investigated one-by-one, with those that are not trademarks being lower-cased. And it might be more WP:NPOV to rewrite most of the article to use one of the lowercased non-TM names, and only use "Connect Four" or "Connect 4" when referring to specific MB–Hasbro products/publications.
What is presently at "score four" seems like it should be "Score Four" (trademark of Funtastic in 1968, AKA "Connect Four Advanced" by Hasbro later); there doesn't appear to be a generic name for that variant. And I'm skeptical it is a valid stand-alone article instead of a section at Connect Four, anyway; looks like it would not pass a GNG test at AfD.
I didn't look closely at other examples. Were there some other iffy ones?  — SMcCandlish ☏ ¢ 😼  01:43, 29 December 2023 (UTC)
Sure, lots of potentially iffy ones. Like what I did here. You concur? And what about things like Five Field Kono that are usually capped in sources, for no apparaent reason? Dicklyon (talk) 05:51, 29 December 2023 (UTC)
The cleanup at peralikatuma looks spot-on to me. And five field kono (not even a redirect there? FFS ....) is a folk game, not a trademark/publication, so should be lower-case, and as: five-field kono (five-field {{lang|ko-Latn|kono}}) – per MOS:HYPHEN and MOS:FOREIGN. The parent article gonu has similar issues. This is the kind of stuff MOS:GAMECAPS is specifically aiming to address (along with overcapitalization of things like sports, folk dances, sport/dance moves and techniques, game pieces, musical instruments, etc.). For at least the immediate future, we have one weird exception, for go (game), which is presently being rendered "Go", but obviously really should be go ({{lang|zh-Latn|go}}), but we would need another RfC to undo the previous one that arrived at "Go" through what seems to be a WP:SSF-based WP:LOCALCONSENSUS. But in no way is "Go" some kind of "capitalize all Asian folk games" excuse. So, kono/gonu.  — SMcCandlish ☏ ¢ 😼  06:20, 29 December 2023 (UTC)
Thanks, I fixed some more of those. There's still a ton of over-capping in games generally though. Dicklyon (talk) 18:27, 29 December 2023 (UTC)
Yes there is. Probably still in a lot of dance articles, too, though I cleaned up a lot of those. Sports mostly look pretty good, but I still run into obscure ones over-capitalizing stuff.  — SMcCandlish ☏ ¢ 😼  23:24, 29 December 2023 (UTC)

Solstice greeting

Sunlight entering the chamber of Newgrange

My best wishes of the solstice season and for the coming year. 𝕁𝕄𝔽 (talk) 18:07, 20 December 2023 (UTC)

"MOS:VARS" listed at Redirects for discussion

 Done

The redirect MOS:VARS has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Anyone, including you, is welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 December 21 § MOS:VARS until a consensus is reached. Fram (talk) 09:15, 21 December 2023 (UTC)

December greetings

December: story · music · places

Thank you for what you do and stand for! I wish you a good festive season and a peaceful New Year! -- Gerda Arendt (talk) 17:17, 20 December 2023 (UTC)

Today, I have a special story to tell, of the works of a musician born 300 years ago. --Gerda Arendt (talk) 09:59, 22 December 2023 (UTC)

Dahua Technology

 Done

Hi SMcCandlish, I noticed that you are part of the category of Wikipedians willing to provide third opinions [10]. I have been working on Dahua Technology and am hoping you may be interested in reviewing an ongoing discussion on the talk page regarding specific terminology used in the article. I'd be grateful for your feedback and assistance in implementing the edits as you see fit. Thank you, Caitlyn23 (talk) 19:23, 20 December 2023 (UTC)

Will try to look into it tomorrow, but it's been a long day for me already.  — SMcCandlish ☏ ¢ 😼  09:31, 21 December 2023 (UTC)
More like the next day or day after; have a lot going on.  — SMcCandlish ☏ ¢ 😼  10:00, 22 December 2023 (UTC)
Hi SMcCandlish, just checking back to see whether you may have time to review the discussion on the Dahua Technology talk page. I'd be interested to hear your thoughts and would appreciate assistance with the edits. Thanks again, Caitlyn23 (talk) 18:22, 28 December 2023 (UTC)
@Caitlyn23: This isn't really a Wikipedia:Third opinion matter, because it's not a dispute between two editors; rather, there has been a series of consensus discussions with unclear resolution. It would be much more appropriate for me to simply weigh in as one of those editors, than try to do what amounts to arbitrating between one editor (you) and a bunch of other editors (of differing opinions but some of them against yours). I have done that now, suggesting a compromise approach both sides hopefully will find workable.  — SMcCandlish ☏ ¢ 😼  01:43, 29 December 2023 (UTC)

New message to SMcCandlish

Hey, I just wanted to reiterate that I've appreciated every site or MOS-related discussion we've both been involved in over the past few months—I've always learned something valuable even if I seemed adamant in the moment, so thank for for your clear and unflinching dialogue. Remsense留 15:28, 22 December 2023 (UTC)

You're welcome. Not sure everyone appreciates the "unflinching dialogue" approach. But I've found it more practical (as a professional activist back in the day, and on-site now) to take a "This means X" and "We need to do Y" and "The Z approach is the best one for [reasons]" position rather than "I interpret this as X but I guess someone might think it means X-1", "We could do Y but some people prefer Y+1", "A way to do this that I like is Z" stance (or lack of stance), because little gets done or gets decided consistently (or often worse, the decision is to let chaos reign) with the latter approach. PS: FWIW, I generally just respond to arguments/ideas/interpretations/proposals on their own merits (in concert with the rest of the system), and I don't keep a list in my head of editors I've butted heads with; I mostly don't pay attention to usernames. So if I seemed vociferously opposed to some idea you liked at some point, it wasn't personal. :-)  — SMcCandlish ☏ ¢ 😼  19:53, 22 December 2023 (UTC)
It takes all kinds, is how I think I'd put it. We certainly need plenty of plain-spoken editors like you around. Remsense留 21:22, 24 December 2023 (UTC)

I realize you're probably busy, but am wondering if you could comment on whether I'm being too harsh in reverting Xhkvfq, or is there a tendentious POV issue with their edits? Geogene (talk) 19:25, 22 December 2023 (UTC)

@Geogene: I responded at Talk:Cat predation on wildlife and at Draft:Human–cat conflict and Draft:Cat predation on islands. Is there more?  — SMcCandlish ☏ ¢ 😼  21:14, 22 December 2023 (UTC)
I've reverted them [11] at Feral cat just today. This has been going on too long for me to remember all the disputed content, but I know I've been reverting their edits for long enough that the concern about OWNership they alluded to on the Cat predation on wildlife could be a legitimate issue. Geogene (talk) 21:24, 22 December 2023 (UTC)
Addressed the issue there too, and in user talk. There is a consistent pattern of using WP:OR to denigrate various established positions and the reliable sources for them, taking unrelated facts and weaving a PoV-pushing, WP:FRINGE narrative out of them that isn't actually supportable by any of the WP:RS materials. If this doesn't drastically improve pretty soon, this probably needs to go to WP:ANI for a topic ban. There are too few editors actively watchlisting these articles for us to long tolerate someone trying to rework them to support a "cats are precious and harmless" viewpoint against everything the sourcing is telling us. That said, a handful of introductory or clarification sentences with appropriate sources can probably be distilled from this user's material, though it takes some work (I did some at Talk:Feral cat#Invasive species; and set up a discussion at Talk:Cat predation on wildlife about possibly doing something like that with some of Xhkvfq's drafts' cited sources (but probably none of the textual content in those drafts, which are just activism polemic).  — SMcCandlish ☏ ¢ 😼  00:19, 23 December 2023 (UTC)

Merry Christmas!

~~~ Merry Christmas! ~~~
Joyeux Noël! ~ Buon Natale! ~ Vrolijk Kerstfeest! ~ Frohe Weihnachten!
¡Feliz Navidad! ~ Feliz Natal! ~ Καλά Χριστούγεννα! ~ Hyvää Joulua!
God Jul! ~ Glædelig Jul! ~ Linksmų Kalėdų! ~ Priecīgus Ziemassvētkus!
Häid Jõule! ~ Wesołych Świąt! ~ Boldog Karácsonyt! ~ Veselé Vánoce!
Veselé Vianoce! ~ Crăciun Fericit! ~ Sretan Božić! ~ С Рождеством!
শুভ বড়দিন! ~ 圣诞节快乐！~ メリークリスマス！~ 메리 크리스마스!
สุขสันต์วันคริสต์มาส! ~ Selamat Hari Natal! ~ Giáng sinh an lành!
Весела Коледа! ~ Meri Kirihimete!

Hello, SMcCandlish! Thank you for your work to maintain and improve Wikipedia! Wishing you a Merry Christmas and a Happy New Year!
Gråbergs Gråa Sång (talk) 12:57, 23 December 2023 (UTC)

Spread the WikiLove and leave other users this message by adding {{subst:Multi-language Season's Greetings}}

Question

Hi, do you think "condottiere", "podestà", ballerina", "danzatrice" and "diva" are assimilated words in common English? Wishing you a Merry Christmas! JackkBrown (talk) 17:14, 23 December 2023 (UTC)

"Ballerina" and "diva" certainly are everyday English; the other two are not, so {{lang|it|condottiere}}, {{lang|it|danzatrice}}.  — SMcCandlish ☏ ¢ 😼  20:34, 23 December 2023 (UTC)
And "podestà"? JackkBrown (talk) 21:05, 23 December 2023 (UTC)
The lead sentence's wording and markup '''{{Lang|it|Podestà}}''' ({{IPA-it|podeˈsta|lang}}), also '''potestate''' or '''podesta''' in English ... are already correct and, for that matter, completely self-explanatory. I'm going to advise for the sixth or seventh time that if you cannot intuit which words should and should not be italicized in English, you should not be changing the italicization (or language markup) of words at English Wikipedia. Just let other editors, the ones who are native speakers of English, deal with these matters. Please stop messing with this stuff. Also, you don't need to do {{ping}} at someone's own talk page.  — SMcCandlish ☏ ¢ 😼  00:00, 24 December 2023 (UTC)
Unfortunately, if I don't think about it, hardly anyone does, because these are Italian topics and the editors' interest is very much focused on American and British ones. JackkBrown (talk) 00:17, 24 December 2023 (UTC)
@JackkBrown: Fair enough, I suppose, but you can probably save a lot of time just by using Dictionary.com and other major dictionaries of English. If the word is listed in it (without a note indicating it's a foreignism), then it's probably assimilated enough into English to use it without any of the italicizing language markup (or bare italics). E.g., "podesta", "diva", and "ballerina" are listed as English words of Italian origin. If it's not included in the dictionary, then probably italicize it with the {{lang|it}} template. E.g., "podestà" with the diacritic is not in the dictionary, and "danzatrice" and "condottiero" are also not listed. "Condottiere" is a special case: It is listed with a derived meaning in English of 'any mercenary or soldier of fortune'; in the case of our article, we are not using it in this adapted, generalized/vague way at all, but in the original, literal, historical Italian meaning of 'a leader of a private band of mercenary soldiers in Italy, especially in the 14th and 15th centuries', so it should be italicized. An opposite example is Consigliere; English has adapted this term to refer specifically to a Mafia advisor to and representative of the family head. In regular Italian, it simply means 'couselor/councilor' and has no Mafia connections in particular. Thus, our article does not italicize the term at that article, about the Mafia role, but does italicize it under "Etymology" when giving its original Italian meaning. This stuff is subtle and complex, and a big part of why I think you should find something other to do that tweaking italics. PS: Happy holidays to you as well. :-)  — SMcCandlish ☏ ¢ 😼  00:46, 24 December 2023 (UTC)
I suppose "signoria" should also be written in italics. Merry Christmas! JackkBrown (talk) 00:57, 24 December 2023 (UTC)
Yes.  — SMcCandlish ☏ ¢ 😼  01:16, 24 December 2023 (UTC)

Season's Greetings

Season's Greetings
Wishing everybody a Happy Holiday Season, and all best wishes for the New Year! The Nativity scene on the Pulpit in the Pisa Baptistery by Nicola Pisano is my Wiki-Christmas card to all for this year. Johnbod (talk) 02:59, 24 December 2023 (UTC)

A Merry Christmas to you!

Hello SMcCandlish: Enjoy the holiday season and winter solstice if it's occurring in your area of the world, and thanks for your work to maintain, improve and expand Wikipedia. Cheers, Jerium (talk) 16:48, 24 December 2023 (UTC)

Spread the WikiLove; use {{subst:Season's Greetings}} to send this message

Jerium (talk) 16:48, 24 December 2023 (UTC)

Artistic billiards

Hi! I've done a little bit of work on Artistic billiards over the last couple days - I'd never seen a match, but recently found a video on YouTube and it's very enjoyable! Shame it is so hard to find a detailed video. I've added some info from Trick Shot about Artistic Pool, but I'm not super familiar with the subject. Is there any funky sourcing outside of Shamos's book about these terms, Google isn't super helpful. Lee Vilenski (talk • contribs) 13:13, 27 December 2023 (UTC)

@Lee Vilenski: Not that I'm really aware of, or I would have split Artistic pool into its own article by now. I know Tom "Dr. Cue" Rossman is heavily involved in artistic pool (or at least was as of around 2010 or so). Old pool magazines like Inside Pool and Billiards Digest from that era probably have some coverage, but I no longer have a collection of that stuff (used to live in a converted warehouse space with oodles of room, but now a small apartment, so had to downsize a lot). AZBilliards may have some coverage, and there might be historical info among Rossman's own online materials. As for artistic [carom] billiards, carom in general isn't very popular in the English-speaking world but is a big deal otherwise, so I would expect more source materials to be available in French, Italian, Spanish, and Chinese, among other languages in the "carom world".
One minor concern is that Trick shot#Artistic pool and Artistic billiards#Artistic pool are basically near-identical WP:CFORKS. The meat of the material should be merged to the former, with the latter reduced to a compressed summary, with {{Main|Trickshot#Artistic pool}} at the top of it.  — SMcCandlish ☏ ¢ 😼  23:13, 27 December 2023 (UTC)
I thought as much. I am in the process of merging, although I don't really see how Trickshot would be the main article of the two. Perhaps I don't know enough about the subject. Lee Vilenski (talk • contribs) 09:21, 28 December 2023 (UTC)
@Lee Vilenski: Well, artistic pool, artistic billiards, and trick-shot snooker are all essentially sub-topics (discipline-specific variants) of the Trick shot topic. Artistic billiards is well-developed in encyclopedic material enough for a stand-alone article. Artistic pool is slowly heading that direction; trick-shot snooker is not yet (though there's at least one specific-competition article). But Artistic pool (on a six-pocket pool table) is not a subtopic of Artistic billiards (on a pocketless carom table).  — SMcCandlish ☏ ¢ 😼  01:43, 29 December 2023 (UTC)

Happy New Year

Happy New Year!
Wishing you and yours a Happy New Year, from the horse and bishop person. May the year ahead be productive and distraction-free and may Janus light your way. Ealdgyth (talk) 14:45, 31 December 2023 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=User_talk:SMcCandlish/Archive_205&oldid=1260736728"