Wikipedia talk:Manual of Style

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Welcome to the MOS pit


    Style discussions elsewhere[edit]

    Add a link to new discussions at top of list and indicate what kind of discussion it is (move request, RfC, open discussion, deletion discussion, etc.). Follow the links to participate, if interested. Move to Concluded when decided, and summarize conclusion. Please keep this section at the top of the page.

    Current[edit]

    (newest on top)

    Capitalization-specific:

    Move requests:

    Other discussions:

    Pretty stale but not "concluded":

    Concluded[edit]

    Extended content
    Capitalization-specific:
    2023
    2022
    2021

    A worsening MOS:DASH issue (causing mounting WP:CONSISTENT problems)[edit]

    At some point (I don't have the patience to history-dig for it), we lost the line-item in MOS:DASH that said something along the lines of using an en dash between the name parts of merged jurisdictions and other compound/merged/commingled/spanning/encompassing entities and things (other than, mostly, corporations, the post-merger/acquisition names of which take rather random forms like "DaimerChrysler" and "KPMG Peat Marwick" and so on). This principle was consistently used numerous times for establishing various article names, such as

    What brought this to my notice was an RM at Talk:Carson–Newman University to convert the en dash to a hyphen, in a case where this is a merged entity of institutions individually named Carson and Newman, not a case of a unitary insititution having been named after two people.

    Ever since the MOS:DASH wording changed along the way somewhere, various cases that called for, or at least originally called for, en dash are now at hyphens. Some examples include:

    Locus of the problem: The remaining MoS wording that seems applicable is only this: Generally, use a hyphen in compounded proper names of single entities. ... Wilkes-Barre, a single city named after two people, but Minneapolis–Saint Paul, an area encompassing two cities.

    The latter point of this seems to still vaguely suggest using, e.g., Gilgit–Baltistan, Moravian–Silesian Region, Carson–Newman University, etc., but it is too unclear to reliably result in this at RM. People just see "Generally, use a hyphen in compounded proper names of single entities", without regard for the intent (or at least former intent) for the products of merging to be en-dash treated. The seizing upon this first part is so firm for some editors that the second just gets ignored, and we end up with titles like Mount Carmel-Mitchells Brook-St. Catherines and Long Harbour-Mount Arlington Heights and Grand Falls-Windsor which are akin to Minneapolis–Saint Paul (combined name for a fused area encompassing multiple individually named places) not to Wilkes-Barre, Pennsylvania (always one place, that happens to be named after two people).

    Even the "Generally" in that wording now no longer makes sense, because the case in which it didn't apply is now so obscured as to be almost missing.

    So, we have something of a WP:CONSISTENT policy crisis that has developed over the last few years, with various articles on subjects of this merged/commingled/spanning nature being at en-dash titles and various of them at hyphen titles, and people willy-nilly RMing them at cross purposes to each other, with different moves concluding for conflicting results (plus sometimes just some manual moves, and sometimes pages simply having been at one or the other format the entire time without being moved). A prominent recent example is AFL–CIO being stable at that title for years, on the basis of the merged-entities reasoning, then suddenly moved to AFL-CIO on the preferences of a total of three editors.

    We really need to settle one way or the other on this, and record it clearly in MOS:DASH.

    PS: There are also a handful of outright errors, like:

     — SMcCandlish ¢ 😼  23:41, 22 January 2024 (UTC)[reply]

    Fully agree. As I said the other day at Talk:University of Illinois Urbana-Champaign, all of these articles should immediately be moved back per the MoS. As a style matter, these really don't have anything to do with COMMONNAME. Perhaps a mass RM? InfiniteNexus (talk) 05:58, 23 January 2024 (UTC)[reply]
    Regarding names of major universities (for example), why wouldn't we give deference to the formatting on their own letterhead (whether hyphen or en, spaced out or not, depending on font), just as we give deference to random corporate branding like "DaimlerChrysler"? SamuelRiv (talk) 06:07, 23 January 2024 (UTC)[reply]
    Because the MoS specifically recommends this style. As I noted at the Carson–Newman RM, the only reason most websites avoid using en dashes in their style guides is that it's not on a standard keyboard. But Wikipedia has its own style guide, which doesn't defer to external style guides used by other publications. See also MOS:CONFORM; we always normalize dashes, apostrophes, quotation marks, all caps, etc. InfiniteNexus (talk) 06:12, 23 January 2024 (UTC)[reply]
    That seems like a massive assumption that they "only" use a hyphen because it's not on the standard keyboard. Additionally, some of these universities are two names, which MOS:DASH suggests we should stylize with a hyphen. I fail to see why we should rely on an assumption towards en dashes when all reliable source indicate the commonname and desired name uses a hyphen. glman (talk) 14:13, 23 January 2024 (UTC)[reply]
    @Glman have you got endash and hyphen the wrong way round here? YorkshireExpat (talk) 16:53, 23 January 2024 (UTC)[reply]
    No, sorry, you're right. YorkshireExpat (talk) 17:54, 23 January 2024 (UTC)[reply]
    It's not a matter of "deference". Names like DaimlerChrysler and KPMG Peat Marwick do not involve "horizontal lines", so the question never arises for them. If we had "Daimler[- or –]Chrysler", then it would. At least until recently, the decision would have been "Daimler–Chrysler" as a merger em dash. But the way MoS has drifted from clarity on this matter over the years, it would now be about a 50/50 toss-up, some arguing for consistency with other en-dashed names of merged entities, and some arguing for consitency with hyphenated ones of the same sort, when all of them in this class should be using the same style. I'm not even sure I care which direction it goes in, as long as one is picked and recorded clearly in MoS so the conflict stops.  — SMcCandlish ¢ 😼  07:17, 24 January 2024 (UTC)[reply]
    But University of Illinois Urbana-Champaign is a completely different case to Carson–Newman University, and I agree this should be a endash when going by the style guide. WP:COMMONNAME is a different argument. At that point one would be arguing for the occasional exception espoused by WP:MOS. YorkshireExpat (talk) 17:47, 23 January 2024 (UTC)[reply]
    Well, yes, they are completely different cases, but both call for en dashes for different reasons, the first because it serves and is named for multiple cities, the second because it's a merger of a Carson institution and a Newman institution. Or least both used to call for en dashes, but MOS:DASH has gotten confusingly messed with over time so that the second of these categories is no longer clear (the first still is, despite someone arguing below to keep the hyphen in the university name).  — SMcCandlish ¢ 😼  07:17, 24 January 2024 (UTC)[reply]
    @InfiniteNexus: The point of this thread is that the MOS:DASH material has become so muddled that it's unlikely that such an RM would conclude with a consensus, and if it did it would be on a very split basis that pits one "consistency" and against another, because the guideline material no longer offers the clarity required to be certain. Anyone can spin it to mean what they want it to mean, and cite the "precedents" in RM history that agree with them.  — SMcCandlish ¢ 😼  07:17, 24 January 2024 (UTC)[reply]
    I think the rule "use en-dash if two entities merged, hyphen if it was named after two persons/entities from the start" is entirely impractical, needlessly hard to follow, and confusing to readers, so I'm not sad that that line item was lost (assuming it ever existed, which I don't know). A rule I know that's way easier to follow and makes (for me) more sense is to use an en-dash if one of component parts consists of multiple words (e.g. Minneapolis–Saint Paul, Grand Falls–Windsor), but not otherwise (e.g. Gilgit-Baltistan, Moravian-Silesian Region). Let's not multiply the en-dashes without good reason. Gawaon (talk) 16:46, 23 January 2024 (UTC)[reply]
    A rule I know that's way easier to follow and makes (for me) more sense is to use an en-dash if one of component parts consists of multiple words. I'm sorry but this makes no sense, why would this be a rule? WP:MOS makes absolutely no mention of this. YorkshireExpat (talk) 21:06, 23 January 2024 (UTC)[reply]
    It used to; I'm not sure what happened to that. But it's a different kind of en dash usage not relevant to the sort under discussion here.  — SMcCandlish ¢ 😼  07:17, 24 January 2024 (UTC)[reply]
    Rather than try to shoehorn this into the reply chain, I'll point out here that the official Representation Order for Canadian federal electoral district uses emdashes, not endashes, between geographical entities. Moving them all to endashes would often be erroneous. G. Timothy Walton (talk) 20:00, 23 January 2024 (UTC)[reply]
    Nope, it's just an arbitrary style choice, not even consistently followed by the responsible agency, much less anyone else. I demonstrate this clearly below in a sub-thread.  — SMcCandlish ¢ 😼  07:17, 24 January 2024 (UTC)[reply]
    Generally, use a hyphen in compounded proper names of single entities. I think discussion ends here. Carson–Newman University is a single entity, including compounded names, so it gets a hyphen. The fact that it wasn't a single entity in the past is neither here nor there; WP:MOS makes no reference to that. Why should the history of a university determine the current naming? The argument for University of Illinois Urbana-Champaign is entirely different. Urbana–Champaign is a metropolitan area comprising multiple single entities, and that's why it gets the endash. Why WP:CONSISTENT should apply here is anyone's guess. Certainly there should be no mass RM based on that policy.
    However, I might go further. For Urbana–Champaign, which is not a single entity, we can do what we wish and render that in our own style. For the University of Illinois Urbana-Champaign, a single entity, the people who run it choose to render it in that style, with a hyphen. More importantly (for WP:ARTICLE) secondary sources render it in that style. It is arrogance to say that we know better, and we will change how it is rendered for our purposes. YorkshireExpat (talk) 21:05, 23 January 2024 (UTC)[reply]
    That's confusingly inconsistent with regard to Urbana[– or -]Champaign, and is exactly the opposite of the intent of all of MOS:DASH, MOS:ARTCON, and WP:CONSISTENT policy. To the extent that argument for "University of Illinois Urbana-Champaign" with a hyphen has a kind of logic to it, it is contradicted by other logics. The university's name is exactly like that of Seattle–Tacoma Airport; it indicates a two-city service/coverage area, which calls for an en dash. The above is exactly what I mean by people latching onto the first half of the "Generally, use ..." rule and ignoring the rest of it. This happens because the wording has gotten unclear.  — SMcCandlish ¢ 😼  07:17, 24 January 2024 (UTC)[reply]
    Well I think I've been perfectly clear. Nowhere in policy does it say that names of entities after merger get endashes. Nowhere does it say anything about component parts consisting of multiple words. I'm going by what it says now. I don't think my second argument is confusingly inconsistent. For the institution it's all about how sources render the name, and replicating the style that the sources use (WP:STICKTOTHESOURCE). Otherwise it's single vs multiple entities. YorkshireExpat (talk) 19:20, 24 January 2024 (UTC)[reply]
    This is my thinking as well. A single entity, such as a school or corporation, is akin to a hyphenated surname resulting from a marriage. It should be a hyphen. Whether or not a company is named for two people who co-founded the company at one point in time, or the company is named for two previously independent predecessors, it's still one company named after two things, not an alliance of still independent entities. The Baden-Württemberg principle. Another example is Metro-Goldwyn-Mayer, named for the three predecessor studios, but a single, hyphenated, entity. oknazevad (talk) 21:35, 24 January 2024 (UTC)[reply]
    Well, that is definitely one interpretation/preference that has grown over the last several years due to the wording here becoming unclear. That perception used to be in the minority, maybe it's now in the majority; I'm not really sure. But various editors do not agree with that interpretation, and there remains a conflict, with RMs concluding for opposite results due to whichever "camp" shows up and comments more at that particular move discussion. Maybe we just need to RfC this to pick one option or the other and record it more clearly?  — SMcCandlish ¢ 😼  01:35, 25 January 2024 (UTC)[reply]
    Right, writing Baden–Württemberg or Metro–Goldwyn–Mayer would be absurd. So SMcCandlish's original conjecture (that this would be a generally usable and useful rule) can be considered refuted. Gawaon (talk) 03:49, 25 January 2024 (UTC)[reply]
    "Gawaon doesn't like it" isn't a refutation, it's just you being firmly in one of the "camps of interpretation" already clearly identified. If there was general agreement that this use of the en dash was an absurdity, then the entire first block of examples posted above could never have existed. We have two competing views on this, and no clear resolution on getting past it. I think an RfC on what the wording should be about this kind of case is probably in order, to settle it one way or the other clearly, though I have not drafted one yet. I kind of figured that would be the case when I opened this, but it was worth checking to see if there was already a clear resolution. When the first comment, from InfiniteNexus, is pretty much diametrically opposite yours, that's not a good sign for there already being agreement.  — SMcCandlish ¢ 😼  04:20, 25 January 2024 (UTC)[reply]
    Sure, but how many examples of Baden–Württemberg or Metro–Goldwyn–Mayer with en-dashes can you find out there in the wild, especially in WP:RS? I know that "Wikipedia does it differently from all the rest of the world" is a theoretically possible policy, it just doesn't sound like a very well-conceived one. I'm not opposed to an RfC, but would still like to point out that the other "camp" you mention doesn't seem to exist outside of our little bubble. Gawaon (talk) 05:51, 25 January 2024 (UTC)[reply]
    The infrequency of it is definitely an argument against doing it (though statistical analysis of this is not very practical since ngrams, Google Scholar, etc., treat and - as equivalent). An argument for doing it is rule simplicity: any time names of two entites are run together with a horizontal line, use the en dash not the hyphen. [shrug]. I'm not a partisan on this issue, but I'm interested in the question being resolved clearly so that we no longer have two diametrically conflicting article titling patterns for such cases. Assuming the hyphen were preferred for such cases, we would still have the question to resolve of whether Champaign–Urbana metropolitan area being retained with an endash as multi-city juridictional label should also result in Champaign–Urbana Courier, Champaign–Urbana Challenger, and University of Illinois Urbana–Champaign for consistency with that, or instead produce Champaign-Urbana Courier, Champaign-Urbana Challenger, and University of Illinois Urbana-Champaign for consistency with other "single entities" that are "named after" multiple things. This is one of numerous cases of warring consistencies. Then there's Center Point–Urbana Community School District in the middle. Is that a multi-city jursidiction that takes an en dash or a single entity that takes a hyphen? It could qualify as either, so how do we rewrite the MoS item clearly enough to pick one or the other for such a case? I'm pretty good at the challenges of clear policy writing, but this one is thorny.  — SMcCandlish ¢ 😼  17:34, 25 January 2024 (UTC)[reply]
    I'd give all of those hyphens personally. Also love that fact that the Champaign–Urbana Courier was previously owned by Lindsay–Schaub Newspapers :D (which is inconsistently rendered in that article, but I'd also give a hyphen btw). They're all proper names. YorkshireExpat (talk) 21:51, 25 January 2024 (UTC)[reply]
    Whether "they're all proper names" is completely irrelevant; the question is which line to use between the proper names, in which contexts.  — SMcCandlish ¢ 😼  03:41, 31 January 2024 (UTC)[reply]
    Just explaining my thinking. YorkshireExpat (talk) 15:56, 31 January 2024 (UTC)[reply]
    YorkshireExpat: The entire point of this thread is that the wording has become confused over time and is subject to "warring interpretations", so just insisting that you have an intepretation of its currently messy state isn't exactly telling us anything. Everyone has an intepretation, and they conflict. More to the point of what you said, nothing about style matters on WP is ever about what the sources are doing (or we literally could not have our own style guide at all, and would always have to do, on every style question of every kind, exactly what 50.0000001% or more of the sources were doing – the common-style fallacy), except where we explicitly state otherwise, and that pretty much is only when it comes to one single thing: whether to capitalize something (see top of MOS:CAPS). That's a special rule the community adopted to (mostly) put an edit to disruptive squabbles over capitalization. If WP's MoS was to just use hyphens any time they are the dominant punctuation, then we'd simply delete almost everything in the MOS:DASH section and use hyphens for almost everything, because the bulk of publishers (mostly in news) have abandoned hyphen vs. dash distinctions that are preserved predominantly in academic-leaning writing, and the former no longer use dashes for any function at all other than a form of parenthetical punctuatiion – like this. WP:STICKTOTHESOURCE is entirely and only about facts, not internal style decisions about how we choose to write about the facts. Confusion to the contrary is fairly common, but it is still a confusion. If your idea that WP had to follow the most common style were correct, the only style guide that WP could ever have would be just a tiny document addressing a handful of MediaWiki technical limitations, with style otherwise being just determined by majority use in sources. Of course, WP is not actually written that way, we have a large style guide, and we have a policy at WP:NOT#NEWS that Wikipedia is not written in news style. One upshot of this is that a style that dominates in news material but not in academic and other non-news material is not a style we'll adopt (unless we have a good reason to do so as determined by project-internal consensus for some other particular reason).  — SMcCandlish ¢ 😼  01:35, 25 January 2024 (UTC)[reply]
    If the standard is boiled down to single vs multiple entities (the wording is pretty clear and mentions neither mergers nor multiple words as brought up in this discussion) then it's quite simple to follow (far easier than requiring a history of the entity(ies) involved) and conveys information about the nature of the construction of the thing that is being written about (this would be entirely lost with the multiple words thing). That's why I think it should stay as it is, perhaps with some better examples to clear up this confusion in the future.
    The thing about WP:COMMONNAME was only ever a secondary argument from me anyway, so I'm happy to concede that, despite the arrogance involved in retitling an institution, not to mention the assumptions made when doing that. YorkshireExpat (talk) 18:40, 25 January 2024 (UTC)[reply]
    It's just a house-style matter. Names of things (like whether to "obey" silly trademark stylizations, whether to abbreviate things like "Incorporated" and "Limited" in company names (and whether with or without a trailing "." and whether or not preceded by a comma), whether to capitalize a leading "the" or include it at all, whether to put spaces between initials, etc., etc., are all arbitrary style decisions that vary from publisher to publisher. You can wish all you want that it were not so, but it provably is so. Using silly argument to emotion tactics like bemoaning things as "arrogance" are not going to convince anyone of anything, and just make you look like a crank PoV pusher of entirely subjective prescritivist notions.  — SMcCandlish ¢ 😼  03:41, 31 January 2024 (UTC)[reply]
    Yep, that's fine. I'm just going with the policy (as currently written). YorkshireExpat (talk) 16:00, 31 January 2024 (UTC)[reply]
    Some of the examples above don't seem especially well chosen, since they can be explained in other terms – i.e., Minneapolis–Saint Paul, Dallas–Fort Worth metroplex, and San Antonio–Austin metroplex can be explained in terms of MOS:ENBETWEEN / Dash#Attributive compounds. But Champaign–Urbana metropolitan area and Seattle–Tacoma International Airport are not cases of MOS:ENBETWEEN / MOS:PREFIXDASH / MOS:SUFFIXDASH. It would be nice to get more clarity over "an institution created by merging prior institutions" and "a unitary institution/place that was named after two people" and "an area encompassing two non-merged places" or "an institution named after two non-merged places" and "a place/city/nation formed by merging previously-distinct places". I've seen opinions expressed in RMs based on such considerations, but the MoS hasn't seemed clear, and I am not aware of very relevant external style guidance. (Talk:AFL-CIO#Requested move 16 August 2023 was more a matter of the outcome for Talk:SAG-AFTRA#Requested move 20 July 2023 than the three editors who commented.) —⁠ ⁠BarrelProof (talk) 17:10, 15 February 2024 (UTC)[reply]
    Well, yes, the "MoS hasn't seemed clear" issue is what this is about. It needs to be clear, but there's clearly not agreement on what it should say, and there are a lot classes to consider. Not an easy RfC to whip up, but I'll put it on my list.  — SMcCandlish ¢ 😼  02:45, 24 February 2024 (UTC)[reply]

    To anyone following this I've started a move request here, if anyone's interested and has a viewpoint. I think it's an interesting case. YorkshireExpat (talk) 15:49, 1 March 2024 (UTC)[reply]

    Canadian federal electoral districts[edit]

    Moving reply here so as not to put a large block of links in the main thread above: G. Timothy Walton above asserts: the official Representation Order for Canadian federal electoral district uses emdashes, not endashes, between geographical entities. Moving them all to endashes would often be erroneous..

    Nah, it is easily demonstrable that which horizontal line to use is just a completely arbitrary house-style choice, and we do not follow the Canadian government's house style, nor they ours. More to the point, they don't follow their own, anyway. The Canadian government is not consistent at all on an unspaced em dash, even within the same agency – the one responsible for administring electoral districts – and for the same electoral district; cf. their official usage here, which is unspaced double hyphens (an old typewriting convention standing in for an en dash, with an em dash represented by three), and their equally official usage here, which is an unspaced en dash not an em dash. This idea that these districts "officially" require an em dash seems to be an assumption about what what is done in a particular webpage or other document without any regard to what's done in others, in reference to the same districts. And it wouldn't matter anyway, since WP doesn't follow some other entity's house style even when it's "official".

    Other agencies use whatever they want; e.g.: Library of Parliament uses spaced hyphens for this [1][2]; Statistics Canada uses unspaced double-hyphens again [3], and same at main Canada.ca government site [4][5]; Parliament of Canada prefers the unspaced em dash [6], and ditto for Elections Ontario [7] and Public Prosecution Service [8]; Federal Redistribution uses unspaced en dash [9] as does the government's Canada Gazette [10], but not always (here with unspaced em dash [11]); the City of Toronto uses an unspaced hyphen [12]; Legislative Assembly of Ontario uses unspaced en dash and unspaced hyphen in same document [13].

    Independent source usage generally doesn't follow this alleged but disproven em dash convention, either: Ontario Community Health Profiles Partnership uses unspaced double-hyphen [14], GeoCoder uses unspaced hyphen [15], University of Calgary Canadian Elections Database confusingly uses unspaced double-hyphen for federal [16] and unspaced hyphen for provincial [17], StudentVote.ca uses unspaced em dash [18], Toronto.com (combined website of the newspapers The North York Mirror, Scarborough Mirror and Etobicoke Guardian) uses unspaced hyphen [19], Canada Gazette sometimes uses unspaced em dash [20], but otherwise unspaced en dash [21]; CBC News uses unspaced hyphen [22], and so do The Globe and Mail https://www.theglobeandmail.com/canada/article-toronto-election-results-map/], Toronto District School Board [23], Global News [24], CTV News [25], CityNews [26], and Canadian National Multilingual News Group [27]; Toronto Star uses the unspaced em dash [28] or unspaced hyphen [29] on different pages; Simon Fraser University uses spaced hyphen [30]; Ontario Public School Boards Association uses mostly spaced en dash, some unspaced em dash, and at least one case of hyphen spaced on one side, all in the same document [31].

    This is all just from the first page of search results on the same electoral district. Clearly demonstrates this is entirely a house-style choice, with some (both within and without the government) not caring at all which one it is even from page-to-page on the same site, sometimes not even on the same page. WP has no reason at all to do anything but follow it's own MOS:DASH rule, which calls for Toronto–Danforth with an unspaced en dash, with parenthetical disambiguation as needed for multiple districts. The idea of ever trying to disambiguate these just by which tiny little horizontal line they have in them is not even vaguely practical.  — SMcCandlish ¢ 😼  07:17, 24 January 2024 (UTC)[reply]

    I agree. WP:CANRIDINGS (a.k.a. MOS:CANADA#Ridings) seems rogue. —⁠ ⁠BarrelProof (talk) 17:10, 15 February 2024 (UTC)[reply]

    MOS:BLOCKQUOTE[edit]

    According to this discussion, a transparent background is applied to quote boxes in article space because of the guidelines established in MOS:BLOCKQUOTE and MOS:COLOR. I think this choice makes the pages using this template look cluttered and visually appalling. Furthermore, as pointed out by @Belbury, these models have been employed in over 22,000 times across Wikipedia, which means the current orientation is interfering with readability in many places. I would like to suggest that article space quote boxes should have a guideline that encourages neutral tones, such as the default grey colour (#F9F9F9). As a last argument to support this change, I will also cite @Light show: "Light background colors can make a document more visually appealing by adding a layer of design and sophistication, which can make the text more engaging to readers [...] large pages of black and white text can be monotonous to read, so having some light background colors for block quotes with borders can break this monotony, making the reading experience more pleasant and less tiresome". GustavoCza (talkcontribs) 01:46, 4 February 2024 (UTC)[reply]

    The {{quote box}} background was made transparent across all articles a few days ago, citing MOS:BLOCKQUOTE. Is a floating sidebar quotation really a blockquote, though? Belbury (talk) 12:16, 5 February 2024 (UTC)[reply]
    Technically it is, I'd say, but still I don't think MOS:BLOCKQUOTE needs to, or should, apply here. Gawaon (talk) 13:59, 5 February 2024 (UTC)[reply]
    I too was very surprised to see such a major change (affecting many thousands of articles, including FAs) implemented without either discussion or notice. I just don't think such wide-reaching changes should be made unilaterally. The wording says "Block quotations using a colored background are also discouraged". It doesn't say why, nor does it actually prohibit their use. I completely understand the need for style conventions. I also get that colored boxes may cause accessibility issues. But to overturn a approach that has been widely used for many years without any discussion doesn't seem the right way to go. KJP1 (talk) 07:23, 8 February 2024 (UTC)[reply]
    I'm not really involved with that, but I think you could simply revert the style change to the {{quote box}} background and wait what happens (second step of the WP:BRD process). Gawaon (talk) 08:08, 8 February 2024 (UTC)[reply]
    That seems like a simple move, even for a technical numpty like me. But I note the template is used on 803,000 pages! I'd prefer that the editor who made the change self-reverted. And then we could have a discussion about the whys and wherefores and whatever else. KJP1 (talk) 10:36, 8 February 2024 (UTC)[reply]
    I don't think there is anything broken about the current template, which displays a transparent background in article space, per two MOS guidelines. I have been told in the past by administrators that BRD does not apply to templates (something I do not believe, but I taste good with ketchup, so I do not meddle in the affairs of administrators), so I am reluctant to self-revert in this case. I think the discussion here should determine if there is a community consensus to change our MOS guidelines, specifically: do not use colored text or background unless its status is also indicated using another method, such as an accessible symbol matched to a legend, or footnote labels (MOS:COLOR) and Block quotations using a colored background are also discouraged (MOS:BLOCKQUOTE). – Jonesey95 (talk) 13:27, 8 February 2024 (UTC)[reply]
    I don't think that line from MOS:COLOR applies to the question of the template's default colour, as that grey isn't communicating the "status" of anything. It's the same shade of grey you get around an image thumbnail or infobox. It generally seems to be the case that when Wikipedia floats something in a box at the side of an article, that box gets an #F9F9F9 background. Belbury (talk) 14:13, 8 February 2024 (UTC)[reply]
    I am following this thread and am willing to modify the template once the guidance here on the MOS page(s) has/have been clarified. If neutral background colors are acceptable in some situations, I'm fine with MOS explicitly allowing a neutral background color for {{quote box}} and similar block content in article space, as suggested above. – Jonesey95 (talk) 21:26, 8 February 2024 (UTC)[reply]
    A full rainbow of background colours are already acceptable "in some situations" under the part of MOS:COLOR that you're quoting! It allows background colours that communicate information so long as that information is also indicated using another method.
    I could imagine an article that interleaved multiple quotes from two different sources (perhaps a green paper and a white paper), and used background colours in addition to in-text attribution to distinguish them as an aid to readability.
    MOS:COLOR doesn't appear to take a view at all on the background colour for infoboxes, navboxes, thumbnails, graphs and so on. I don't know if the recurring design for all of these (#F9F9F9 with a 1px #AAAAAA border) is part of a higher level Wikimedia style document. Belbury (talk) 09:12, 9 February 2024 (UTC)[reply]
    I too think that MOS:BLOCKQUOTE doesn't apply to quote boxes, since blockquotes are part of the normal article text, while quote boxes are outside of it – like images, say. So the white background requirement doesn't apply, and the change to the styling should be reverted. Gawaon (talk) 17:33, 8 February 2024 (UTC)[reply]

    I don't think any change to the MOS is needed for the sake of the issue at hand apart from maybe an explanatory note that quote boxes are not block quotes under the MOS, which is how everyone here apart from Jonesey95 seems to understand it (myself included).

    However, the root cause of the problem is that we've been sticking our heads in the sand in regard to the use of quote boxes for nearly a decade now. I previously raised the issue back in 2017, and SMcCandlish explained that the lack of mention stemmed from wishful thinking that it'd make quote boxes go away, which it didn't. I'm not updated on the issue, and the last major discussion I'm aware of is the 2016 RfC, where there was consensus against pull quotes but not much agreement on what other uses of quote boxes are appropriate. It's such a lack of agreement that's preventing them from being documented in the MoS. Has there been any attempt in the intervening years to find some agreement on this? --Paul_012 (talk) 17:26, 8 February 2024 (UTC)[reply]

    I like the suggestion that we distinguish between a quote box, which is closer to an image, and block quotes which are part of the main text. Can that work? KJP1 (talk) 20:48, 8 February 2024 (UTC)[reply]

    Quote boxes are not block quotes, but a form of sidebar, which typically (for images, infoboxes, navboxes, etc.) have at least a slightly different background color. However, the vast majority of uses of quote boxes in our articles are inappropriate per one or more policies and should be converted into normal block quotes. People do it because they like stylizing things, but it draws a gross amount of attention to a particular party's statement versus that of other parties (that fails WP:UNDUE), or in article on a particular author/speaker, document, etc., draws a gross amount of attention to some WP editor's personally selected "most important" or "favorite" part, which fails both WP:NPOV generally and WP:NOR, in the vast majorityof cases.

    We probably should have an RfC about this, well "advertised" at the relevant policy pages and at WP:VPPOL. Most of the objections to pull quotes also apply to highlighted quotes of any other kind. What has happened is that pull quotes were community deprecated, so people insistent on injecting undue "decorated" quotes all over the place, have been evading it by using quoted content that technically isn't a pull quote because it does not repeat material already quoted inline in the main text. Literally the only way to tell the difference is to read every word of the article from top to bottom and see whether the decorated quote material is or is not unique on the page (and that might change at any time anyway). This is clearly a pattern of WP:LAWYER / WP:GAMING, and it needs to stop. Legitimate uses of templates like this in mainspace are extremely rare, and zero of them are actually necessary. There is not a single case that could not be replaced by an in-context block quote (and many are so short they should not be in block quotes at all, but inline quotations in quotation marks). I'm gratified to see that the quote-boxing has been replaced by normal blockquotation at various articles on famous speeches. This is a move in the right direction, presenting the material encyclopedically both as to contextual placement in the article and as to visual presentation, instead of doing it like a magazine or a click-bait website.  — SMcCandlish ¢ 😼  22:42, 8 February 2024 (UTC)[reply]

    What Candlish said. I can't say I'm a fan of these quotes, they are almost always inappropriate Lee Vilenski (talkcontribs) 09:15, 9 February 2024 (UTC)[reply]
    Absolutely fine with a wider RFC, but is there not sufficient consensus to revert to the status quo, while we have the discussion? KJP1 (talk) 09:57, 9 February 2024 (UTC)[reply]
    ""decorated" quotes" I don't mind having quote boxes in the articles, the same way i don't mind having a thumbnail to provide some additional context. It's much more annoying that everything thinks their own color/border is more important than everyone else's.

    The quote box template has more styling commands than I can count. Whereas a few behavior switches with accompanying standardized styles in classes should be all that is needed. (which is not to say that i think they should all be gray, I think that our gray is horrible as a text background and not suited for pieces of text like this [nor for captions of thumbs honestly]). —TheDJ (talkcontribs) 12:42, 3 March 2024 (UTC)[reply]

    When is a local, non-proper loan word (that is synonymous with a more recognizable term used in the same context) acceptable in titles?[edit]

    WP:COMMONALITY states Use universally accepted terms rather than those less widely distributed, especially in titles. For example, glasses is preferred to the national varieties spectacles (British English) and eyeglasses (American English); ten million is preferable to one crore (Indian English).

    When does WP:TIES override this guidance? JoelleJay (talk) 23:48, 19 February 2024 (UTC)[reply]

    It doesn't, I think. TIES refers to cases where no opportunities for commonality exist. Gawaon (talk) 06:56, 20 February 2024 (UTC)[reply]
    I agree with this; it makes the most sense from the perspective that we are trying to write an encyclopedia that our readers can generally understand, and I would support clarifying TIES and COMMONALITY to make this clearer. BilledMammal (talk) 22:17, 25 February 2024 (UTC)[reply]
    It seems to me that the key words in this question are "synonymous" and "non-proper". Some varieties of English contain words that are not synonymous with their closest equivalent in other varieties of English and that, while they are loan words, are proper within their ENGVAR. For example, Québécois as a term is not fully synonymous with "Quebecker", which may linked explain why the linked article has the title it does.
    The terminology used in the WP:HQRS on a topic will typically reflect the formal register of the ENGVAR associated with the topic and, where other terms are not fully synonymous, should generally be reflected in enwiki articles. As I see it, this isn't a matter of "overriding" COMMONALITY, but of defining where it ends and TIES begins. Newimpartial (talk) 17:42, 23 February 2024 (UTC)[reply]
    How are editors supposed to determine which terms are non-synonymous, or which terms are most prevalent within an ENGVAR? Does the mere existence of some HQRS using one local term mean that term should be preferred even if the vast majority of HQRS use the more recognizable term? JoelleJay (talk) 20:39, 25 February 2024 (UTC)[reply]
    As I understand it, editors are supposed to follow HQRS in general - reading for content, accepting distinctions that are documented in the literature and treating ad synonyms terms that are treated in the literature as synonyms. In my experience, hit counts from search engines are of little if any use in making such evaluations. Newimpartial (talk) 00:08, 26 February 2024 (UTC)[reply]

    I have some difficulty in working out the point of Spelling § International organizations. As written, it is non-prescriptive, at least explicitly, and therefore seems out of place in the MoS.

    Given this, the natural reading to me is an implicit extension of an MOS:TIES-style principle to articles with a strong ties to international organizations. I may have missed an explicit statement of such a policy in this connexion, but, if I have not, and am nevertheless right, it would be good to be clearer. Docentation (talk) 04:15, 2 March 2024 (UTC)[reply]

    Wikipedia:Manual_of_Style/Spelling#International_organizations is mostly listing the variants that Wikipedia allows and the differences between them. MOS:ENGVAR, MOS:TIES and MOS:RETAIN cover how to apply them and whether you can/should/shouldn't change from one form to another.  Stepho  talk  05:16, 2 March 2024 (UTC)[reply]
    1. The point of MOS:SPELLING might simply be to describe the proper use of different varieties of English. But in that case why mention international organizations? Whether or not the World Bank uses US English does not change how US English is spelled.
    2. If the point of MOS:SPELLING is to list acceptable varieties of English,
      1. it is both incomplete and redundant: it says nothing about Pakistani or Malaysian spelling in English; and nearly all the varieties of English it mentions are listed at MOS:ENGVAR or MOS:TIES;
      2. the inclusion of international organizations’ preferred varieties of English remains inexplicable—whether some international odganizarion uses a variety doesn’t change how that variety is actually spelled; and
      3. any such purpose, as far as I can tell, remains implicit given the wording of the page.
    3. I therefore remain of the view that listing international organizations’ preferred variants only is useful as part of the style guide if that gives some guide as to which variant to use. Accordingly I think either
      1. the section should be deleted, or
      2. it should be made explicit that strong ties to an international organisation listed give reason to use its preferred variety of English.
    I am minded to propose this at some point, but raise this query informally in particular to establish whether there is any other explicit reason for MOS:SPELLING § International Organizations to exist in its current form; in such a case my proposal would be misconceived. Docentation (talk) 17:39, 2 March 2024 (UTC)[reply]
    The point is to make clear that articles about these international organizations use the style used by those organisations for their own publications and internal documentation, and do not necessarily follow the style of the country in which their HQ is located. MapReader (talk) 17:48, 2 March 2024 (UTC)[reply]
    I agree that that’s the only plausible point of the section—otherwise, it seems to be pointless. But is that explicitly stated anywhere? Docentation (talk) 23:43, 2 March 2024 (UTC)[reply]
    The other question is whether it's even relevant for us. We don't otherwise follow any organization's style guide when writing about them – so why should we make an exception here? Gawaon (talk) 07:19, 3 March 2024 (UTC)[reply]
    Adopting the same variety of English as an international organization is articles about it is rather less deferential than adopting the style guide wholesale. It seems to me that extending MOS:TIES to international organizations is more analogous to using the right national variety of English when there are strong national ties. Docentation (talk) 18:35, 3 March 2024 (UTC)[reply]
    I agree. And it avoids an ultimately futile argument as to which style to use for an organization like the UN, which exists above national boundaries. MapReader (talk) 21:42, 3 March 2024 (UTC)[reply]
    I propose to insert the following text in MOS:TIES: Articles with strong ties to an international organization listed under a variety of English at Spelling § International organizations should use that variety, and to amend Spelling § International organizations accordingly. If nobody objects for a week, I shall go ahead; otherwise, I shall raise a proper RfC. Docentation (talk) 22:08, 6 March 2024 (UTC)[reply]

    Essay suggestion: "How to ignore the MOS"[edit]

    Of course, we have learned—or are still trying our best—to internalize that the MOS is a set of guidelines, and there are exceptions of some quantity to nearly every prescription therein. Especially regarding the niche-er points with tables and markup, I like the idea of surveying pages that clearly, intentionally contravene points of the MOS, but

    • It is done intentionally
    • It is done for a compelling reason, possibly one very particular to that article's topic,
    • It works; moreover, it works for everyone, and following the MOS would likely make the article obviously worse to read.

    I know this is going to be more subjective than most collaborative ideas on here—it's coloring outside the lines, but I think it's possible to create something educational, right? Remsense 03:57, 4 March 2024 (UTC)[reply]

    What goal are you trying to achieve by doing this? More to illustrate the sort of case that, when editors come across it, they should understand the point and leave it alone; to encourage editors to recognize circumstances where they should do this; to explain to them how to do this; or something else? One way of looking at is that if you're seeing cases where it's been done nondisruptively and successfully, then maybe no help is needed from the guidelines, but maybe that isn't the case. Largoplazo (talk) 04:57, 4 March 2024 (UTC)[reply]
    Largely the first two reasons you gave. (I realize many editors might read a headline like this and have heart palpitations because someone's trying to be clever again—I promise, I'm not actually interested in guideline-flaunting for its own sake.) Maybe "exceptions that prove the rule" are equally in order? Remsense 05:03, 4 March 2024 (UTC)[reply]
    • I wouldn't really title it like that. The key point is what to do when you believe that the MOS and core policy (NPOV, OR, or V) or higher-priority policies (BLP, FRINGE, MEDRS) come into contradiction. Those policies do override the MOS in situations where they actually, genuinely come into direct conflict; however, caution should be exercised before assuming that that's the case in any specific instance, because the MOS is usually written with an eye towards core policies anyway and because what seems like a sufficiently clear-cut V or NPOV issue as to override the MOS to you may not seem so clear to anyone else. I think a good rule of thumb is that if the contradiction you've identified is narrow and specific then you might have a case, although you still have to convince people if anyone objects; but if you have some sweeping objection to an entire aspect of the MOS (eg. "using BCE anywhere is obviously POV!") then it's usually safe to assume that the community considered that when writing the MOS and didn't agree with you. --Aquillion (talk) 05:48, 4 March 2024 (UTC)[reply]
      If I'm being honest, I did a clickbait. My tongue was lodged firmly in my cheek, I wouldn't pick this title either. Remsense 05:50, 4 March 2024 (UTC)[reply]

    Mention of table of contents[edit]

    In the section organization section, there's the text If an article has at least four section headings, a navigable table of contents appears automatically, just after the lead. This appears to have been removed in newer versions of Wikipedia, as the table of contents was moved to the left of the article. I'm not sure how to address this text, so I welcome other editors to take a look. —Panamitsu (talk) 09:23, 5 March 2024 (UTC)[reply]

    I believe that the behaior is browser dependent: I'm still seeing the TOC after the lead. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:57, 5 March 2024 (UTC)[reply]
    @Chatul: It's skin-dependent. Vector 2022 puts the TOC in the sidebar; all other skins put it between the lead section text and the first heading. Logged-out users get Vector 2022. --Redrose64 🌹 (talk) 00:24, 6 March 2024 (UTC)[reply]
    Is the skin kept in a cookie? I get different behavior depending on which machine/Firefox I'm using, for the same user id. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:44, 7 March 2024 (UTC)[reply]
    Is the skin kept in a cookie??? Yikes! Remind me to keep my nieces and nephews away from your house on Halloween. EEng 22:04, 7 March 2024 (UTC)[reply]
    Since the location is skin-dependent, can we just say "table of contents appears automatically"? Firefangledfeathers (talk / contribs) 03:06, 7 March 2024 (UTC)[reply]

    Italics for foreign words that refer to the article's topic?[edit]

    I am currently working on an article about a Malagasy zebu-wrestling sport. Its names are tolon'omby and savika—Malagasy words. Should they be italicized and/or use the lang template throughout the article? What about the bolded first uses in the lede? Zanahary (talk) 22:42, 6 March 2024 (UTC)[reply]

    Use {{lang-mg}} and {{lang}} as appropriate for any Malagasy text in an en.wiki article so that screen readers pronounce the text correctly. Use bold markup where approriate.
    {{lang|mg|tolon'omby}}tolon'omby
    {{lang|mg|savika}}savika
    {{lang-mg|tolon'omby}}Malagasy: tolon'omby
    {{lang-mg|savika}}Malagasy: savika
    Trappist the monk (talk) 23:46, 6 March 2024 (UTC)[reply]
    Should I do the same in the articles for kangina, masonjoany, akazehe, and okujepisa omukazendu? Zanahary (talk) 23:59, 6 March 2024 (UTC)[reply]
    Why would you not?
    Something to mind, cf:
    Kangina{{Lang|prs|Kangina}} – not correct
    Kangina{{Lang|prs-latn|Kangina}} – correct
    Trappist the monk (talk) 01:19, 7 March 2024 (UTC)[reply]
    Thanks! And should the titles of these articles be italic? Zanahary (talk) 01:25, 7 March 2024 (UTC)[reply]
    WP:ITALICTITLE.
    Trappist the monk (talk) 01:35, 7 March 2024 (UTC)[reply]
    That policy says it should be done for foreign phrases, which I think is natural, but does it apply to single words, when the word itself is not the article's topic? Quick search gave me mehndi, bedhaya, buda, debtera. Zanahary (talk) 07:24, 7 March 2024 (UTC)[reply]
    when the word itself is not the article's topic What? If the article title is not the article topic, one of them needs to change so that the article title is the article topic.
    In WP:ITALICTITLE, 'foreign phrases' is linked to MOS:FOREIGNITALIC which begins with this:
    Wikipedia uses italics for phrases in other languages and for isolated foreign words that do not yet have everyday use in non-specialized English.
    I read that to mean single words and foreign phrases should be marked up.
    Trappist the monk (talk) 14:19, 7 March 2024 (UTC)[reply]

    MOS and Unlinking[edit]

    2604:3D08:9B7B:E800:AC7D:A86B:5EE4:14B7 (talk · contribs) seems to be on a quest to unlink United States from every Simpsons article. What's the MOS on that?? Q T C 04:05, 7 March 2024 (UTC)[reply]

    MOS:OLINK indicates that major countries are generally appropriately unlinked. Nikkimaria (talk) 04:31, 7 March 2024 (UTC)[reply]

    Inline spacing templates[edit]

    I really wish we didn't need inline spacing templates like {{-?}} and {{'s}}. It feels like they're just trying to compensate for bad kerning that browsers ought to be handling automatically. Sdkbtalk 04:58, 7 March 2024 (UTC)[reply]

    Parenthetical citations in explanatory notes[edit]

    Does the manual of style take any stance on parenthetical citations within an explanatory note?

    A post by an editor at Help talk:Shortened footnotes [32] objects to an example because it "seems to maintain that parenthetical references are still allowed inside explanatory notes. That might have been true at some stage, but WP:PAREN now says "deprecated on Wikipedia"." If this is true, that example should be removed, but after looking through the RFC this appears not to be so. {{harv}} still has several thousand uses, and pages like the Holy Roman Empire article seem compliant with the Manual of Style. The documentation for {{harv}} should also be updated. Template:Harvard citation/doc should either make clear that the template is now meant for explanatory notes, or state that its usage is deprecated outright. Regards, Rjjiii (talk) 02:35, 8 March 2024 (UTC)[reply]

    Haven't closely followed this, but it may be possible to finesse this by the simple measure of using {{harvnb}} insted of {{harv}} in some of these cases. I've replied at the thread and given one example of how to do this for the § 5 example. Not sure to what extent that is extensible to other examples, as I haven't examined them. Mathglot (talk) 03:06, 8 March 2024 (UTC)[reply]
    Or nicer still, {{harvp}}, which (like the primary {{sfnp}}), produces references with the year in parentheses like CS1. 𝕁𝕄𝔽 (talk) 09:10, 8 March 2024 (UTC)[reply]
    It is INLINE parenthetical referencing that is deprecated, not parenthetical referencing per se. When {{harv}} is used within a <ref>....</ref> pair there is nothing wrong with it. It is however more work when you consider that {{sfn}} does the same job with less typing! Martin of Sheffield (talk) 09:22, 8 March 2024 (UTC)[reply]

    Relevant discussion...[edit]

    at the WP:Articletitles talkpage, to do with italic titles. Primergrey (talk) 00:39, 18 March 2024 (UTC)[reply]

    Addition suggestion: Lifespan tags[edit]

    Lifespan tags are dates in parenthesis which contain the birth and death dates of a person. For example: (1 January 1900 – 1 January 2000).

    • The start and end dates should be divided by an en dash, and not a hyphen or em dash.
    • If the lifespan tags are of the subject of the article, the en dash should be separated with spaces: (1 January 1900 – 1 January 2000), not (1 January 1900–1 January 2000)
    • If the lifespan tags appear in another part of an article, such as being used to give the birth and death date of a person who is not the subject of the article, the dates should be divided with an en dash, but the en dash should not be spaced apart, and should only include the year, not the month and/or day: (1900–2000).
    • Lifespan tags should be included in the short description, but only the years: Chinese encyclopedia writer (1900–2000). Except if the article is of a holder of a highly important office position, such as Abraham Lincoln, where the years serving in office are placed instead of lifespan tags.
    • If one date is not known, then where the date would go should be replaced with a question mark (?): (? — 1 January 2000; this also goes for the short description.
    • If the subject is Living, then put b., followed by their birth date: (b. 1 January 1900.
    • Lifespan tags should be included after the article title in set index articles
    • Lifespan tags can be used to disambiguate article titles, but only as a last resort. Use occupational titles before lifespan tags, which should be placed after the occupational title, separated with a comma (,): John Doe (businessman, 1900–2000), not John Doe (1900–2000).

    Roasted (talk) 20:09, 18 March 2024 (UTC)[reply]

    Isn't most of this covered by MOS:DATERANGE? And I think the abbreviation "b." should (almost) never be used for "born". And the em dash in your "date is not known" example is wrong. -- Michael Bednarek (talk) 01:21, 19 March 2024 (UTC)[reply]
    I also think this is largely redundant and not needed. Also, some of it is in conflict with current best practices – for example, short descriptions typically don't include the years of life, unless needed for disambiguation. Which is for the better, as they are meant to be short, after all. Gawaon (talk) 07:33, 19 March 2024 (UTC)[reply]

    Kind of a design question[edit]

    Some folks here might be interested in Wikipedia talk:WikiProject Islam#RfC on using the crescent and star symbol or Allah calligraphy. It's not directly MOS-related, but it's a design-related question about whether we want to use a unified symbol/logo for various items (e.g., sidebars, navboxes), and if so, which one (of the two main candidates). WhatamIdoing (talk) 00:10, 19 March 2024 (UTC)[reply]

    "Media" doesn't work[edit]

    Hi. I noticed that in the infobox when adding the lang it (e.g. on the page Bica (coffee)) "media" doesn't work; why? JacktheBrown (talk) 20:33, 20 March 2024 (UTC)[reply]

    @JackkBrown: this is the talk page for discussing improvements to the page Wikipedia:Manual of Style, it is not a help desk. I don't see how your problem is related to the Manual of Style.
    Anyway, {{infobox food}} expects the |name= parameter to be plain text, without markup. You should use |name=Bica|name_lang=pt|name_italics=true. --Redrose64 🌹 (talk) 22:02, 20 March 2024 (UTC)[reply]

    Silently correct an error if it's in a title?[edit]

    Per MOS:TYPOFIX "insignificant spelling and typographic errors should simply be silently corrected". But, what if the error is in a title being cited? Correcting the error is going to make it hard to find that article if the link changes. E.g. "Neflix star returns to his West Sussex roots". Clearly Neflix means Netflix, at Timothy Innes, and I know some would correct that, but I'm not sure. Thanks for your thoughts. SchreiberBike | ⌨  21:45, 20 March 2024 (UTC)[reply]

    Don't see any problem correcting the ref title, but of course the underlying url has to be left alone. - Davidships (talk) 22:10, 20 March 2024 (UTC)[reply]
    Yeah I'd correct that without hesitation. Popcornfud (talk) 22:30, 20 March 2024 (UTC)[reply]
    As the OP wrote, correcting the typo makes it more difficult to find the article if the link changes and it needs to be found again. I would not correct but give some inline comment <!-- not a typo --> or {{not a typo}}. Other readers will figure out the meaning just as you did. -- Michael Bednarek (talk) 23:35, 20 March 2024 (UTC)[reply]
    He could correct it and have a hidden comment next to the ref that clarifies what the actual title is. —El Millo (talk) 23:38, 20 March 2024 (UTC)[reply]
    @Facu-el Millo: "correct it and have a hidden comment next to the ref that clarifies what the actual title is." I like that. It hides the error. It doesn't require a disruptive {{sic}}. If at some point in the future it needs to be searched for again, the original will be easy to find. I'd probably put it in hidden text right next to the word that was corrected.  SchreiberBike | ⌨  02:11, 21 March 2024 (UTC)[reply]
    @Davidships, Popcornfud, Michael Bednarek, and Facu-el Millo: Based on what seems like a consensus above, I propose the following change to the MoS. At the end of the paragraph that ends "be silently corrected (for example, correct basicly to basically).", we could add the sentence If there is a typo in the title of a source, the source could be hard to find after the typo has been corrected, so when correcting the typo, add a hidden note (<!-- -->) near the error to indicate the original text. I hate to add anything which makes the MoS longer and more complicated, but is this worth the distraction? What think you? SchreiberBike | ⌨  11:41, 24 March 2024 (UTC)[reply]
    Comment: Where the ability to find the ref is not compromised because there is an underlying URL (as in this example), this is not necessary; otherwise a [sic] would seem more appropriate. But I am just a passing editor, so I leave this to those with broader persective on MOS. - Davidships (talk) 12:06, 24 March 2024 (UTC)[reply]
    I think this is such a rare borderline case that it doesn't deserve to be mentioned. I also have some doubts that it's really necessary. Presumably, when the original URL disappears, people will just enter it into the Wayback Machine and hopefully retrieve it there. If not, they may google it, but search engines are fairly tolerant of misspellings and I suppose the typo-corrected title may be nearly as findable as the original one. Maybe more so, if the publisher had in the meantime spotted and corrected the typo. Gawaon (talk) 12:54, 24 March 2024 (UTC)[reply]
    @SchreiberBike I think it's too specific—it's OK to draw attention to it as a issue to be aware of when editing, and maybe suggest possibilities for handling it, but prescribing which to choose seems premature. Something like One way to handle this is . . . seems better. Musiconeologist (talk) 13:47, 24 March 2024 (UTC)[reply]
    That is, the recommendation would be to bear the issue in mind when correcting a title. Use of a hidden note would be an example rather than a guideline. Musiconeologist (talk) 13:55, 24 March 2024 (UTC)[reply]
    I agree with Gawaon's point: it's rarely occurring and not worth mentioning. -- Michael Bednarek (talk) 14:41, 24 March 2024 (UTC)[reply]

    Quotation marks and internal links: visually identical examples[edit]

    Apart from the colour, the "correct" and "incorrect" examples under Quotation marks and internal links both display identically and behave identically when I click them. So the only way to compare them is to open up the section for editing. Maybe include a code snippet for each? Not necessarily the whole fragment—I'm thinking perhaps just [[" "]] and "[[ ]]" so things don't get too cluttered.

    NB I've not checked for other instances of this—I just happen to have encountered this one. Musiconeologist (talk) 13:18, 23 March 2024 (UTC)[reply]

    In the correct example, the quotation marks are outside of the linked title, while in the incorrect one they are part of the link text. If you look closely, you should see it. Gawaon (talk) 13:42, 23 March 2024 (UTC)[reply]
    Perhaps someone can come up with a way to make the difference more obvious. EEng 13:45, 23 March 2024 (UTC)[reply]
    @Gawaon I did, and in the app they appeared as part of the link in both cases. Musiconeologist (talk) 14:20, 23 March 2024 (UTC)[reply]
    OK, scrub that. The difference is visible in the app. I had to take a screenshot then zoom in. Apologies. I might add something about them showing in the link colour in one and in the surrounding text colour in the other. Musiconeologist (talk) 15:31, 23 March 2024 (UTC)[reply]
    I've now made the change, before seeing the replies. I decided it was minor enough to just do it. Feel free to change it if something else would be better. Edit: I've since changed it, to a brief comment noting whether the quotes are the same colour as the link or as the surrounding text in each case. Musiconeologist (talk) 14:24, 23 March 2024 (UTC)[reply]
    I took the liberty to revert that since I think that your earlier version (with the code examples) was actually more helpful. Gawaon (talk) 17:40, 23 March 2024 (UTC)[reply]
    @Gawaon Thanks—I saw just after saving a change here. I'm happy with that. Musiconeologist (talk) 17:53, 23 March 2024 (UTC)[reply]

    WP:COMMONNAME, "Parmesan" page[edit]

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



    According to this rule, if a valid English translation exists it must be used, but in the case of "Parmigiano Reggiano" the situation becomes very complicated. In order, a user changed the name of the page ("Parmesan") to "Parmigiano Reggiano"; I deleted his changes, but after further investigation, and based mainly on the sentence (on the page) "Outside the EU, the name "Parmesan" can legally be used for similar cheeses, with only the full Italian name unambiguously referring to PDO Parmigiano Reggiano.", I was wondering whether, since "Parmesan" outside Europe is almost always a bad imitation, it's wrong to write Parmesan under the ingredients of Italian foods; this might make them less authentic. JacktheBrown (talk) 05:10, 24 March 2024 (UTC)[reply]

    I think the current situation is fine. The Italian name is given in the lead sentence and is a redirect to the article, but it shouldn't be printed in bold, as it's not a "common name" widely used in English. And it shouldn't be the main article title, for the same reason. Gawaon (talk) 06:26, 24 March 2024 (UTC)[reply]
    I guess that depends on where you are? I checked the websites of three major UK supermarkets, and all of them sell under the label "Parmigiano Reggiano". I remember the 'Parmesan' moniker from decades back, but it's now uncommon; typing a search and all three supermarket sites redirect to Parmigiano; on one the Parmesan name doesn't appear and on the other two it is only used for a couple of products, lower graded usually grated cheese. It's not really used nowadays for the whole cheese or solid pieces of it. MapReader (talk) 06:42, 24 March 2024 (UTC)[reply]
    @MapReader: also in my opinion. If we came to the conclusion to change the title, we would have to change all the "Parmesan" (to "Parmigiano Reggiano") from thousands of articles, I see this as very difficult. JacktheBrown (talk) 06:47, 24 March 2024 (UTC)[reply]
    An interim solution would be to put both names in the lead sentence, in bold. Gawaon (talk) 07:00, 24 March 2024 (UTC)[reply]
    Yes, but establish the correct position and over time WP will conform; meanwhile the redirects will do the job. Defending the current position with arguments based on merit is fine, but retaining an incorrect or unsupported position (and IMHO using 'Parmesan' as the article title is now just wrong) simply because changing it leads to some work isn't really acceptable. MapReader (talk) 07:01, 24 March 2024 (UTC)[reply]
    I wonder if this usage persists in North America? There is a similar issue over "Swiss cheese" which is not made in Switzerland and "Emmenthal" which is a PDO in Europe. @Johnbod:, who may be able to advise but may choose not to get back into this culture war again. --𝕁𝕄𝔽 (talk) 08:56, 24 March 2024 (UTC)[reply]
    Yes, "Parmesan" in US, Australia etc can be locally made. It's just a style of cheese there. Certainly in the US "parmesan" would be the dominant name. This is covered in the current article. There's two different topics covered in this article. I think they should be split out: an article on the global generic style under "Parmesan" and another "Parmigiano Reggiano" covering the "real" stuff. If it's left as currently written "Parmiagiano Reggiano" wouldn't be a correct name for this article. DeCausa (talk) 09:10, 24 March 2024 (UTC)[reply]
    @MapReader Isn't that just supermarkets trying to make their parmesan sound special and non-generic, though? Or trying to avoid saying that it's parmesan since people think of that as a low-quality grated thing? They'll avoid the everyday word if there's an alternative that sounds worth paying more for. I don't think supermarket usage is a particularly good guide. Musiconeologist (talk) 13:09, 24 March 2024 (UTC)[reply]
    Of the names mentioned so far, parmesan is the only one I'm familiar with, but I haven't checked whether it's usually in upper or lower case. (I think cheddar cheese is usually lower case and not really associated with the place any more.) Musiconeologist (talk) 13:14, 24 March 2024 (UTC)[reply]
    Checked and they're both uppercase, or were in 2005 (the date of my Oxford Spelling Dictionary edition. They may have moved to lowercase by now.) Musiconeologist (talk) 13:25, 24 March 2024 (UTC)[reply]
    I don’t think so. You only hear very elderly people taking about Parmesan nowadays; it dates back to the Delia Smith era when cooking anything foreign was adventurous and the brave pioneers bought a pot of grated second rate Italian cheese to sprinkle on their Spag Bol. The next generation are rather more familiar with international travel and international food, and happy to call things by their proper names. MapReader (talk) 19:33, 24 March 2024 (UTC)[reply]
    @MapReader Steady on. I'm only 61 . . . ! Last time I went to an Italian restaurant I was asked if I wanted Parmesan. I'm not at all happy with this stereotype. It could be considered quite ageist. (I'm trying not to consider it that way, but not succeeding very well.)
    What I'm finding online is a fair number of articles which try to explain Parmesan as a generic name for things which aren't strictly Parmigiano Reggiano and distinguish the two. Also one about Parmigiano Reggiano having an advertising campaign to promote that as "the only real Parmesan", which rings alarm bells for me.
    It's good that people have adopted the Italian name, but I'd hardly say the other one has gone out of use. Musiconeologist (talk) 21:04, 24 March 2024 (UTC)[reply]
    Hence why I think DeCausa has a point that really the material needs splitting into two articles, particularly if Parmesan is actually still ‘a thing’ in the US. MapReader (talk) 21:24, 24 March 2024 (UTC)[reply]
    I really agree with MapReader. Today we hear very little about "Parmesan", and it might happen that if a non-native Italian speaker (e.g. resident of Louisiana) reads "Parmesan" on an Italian food page, he might think it's an American ingredient, creating a huge misunderstanding and misinformation about Italian cuisine (an American would never want misunderstandings about the culture of his state, e.g. Louisiana, so it would be right to respect us Italians too). Of course, as already written, it's not enough to rename the page, but all the words "Parmesan" must be changed to "Parmigiano Reggiano", otherwise it would be even worse and create even more confusion and misinformation. This definitely requires the help of a bot; we are in luck, because "Parmigiano Reggiano" is capitalised, so the bot in question cannot make a mistake, and it would only be a profound act of indifference not to do so if consensus is reached. JacktheBrown (talk) 20:08, 24 March 2024 (UTC)[reply]
    DeCausa makes a valid point above, however - the current article covers both the historic, genuine Italian product and the fake American knock off stuff. There should definitely be an article about Parmigiano - using the American title for this information is clealry inappropriate - and in that article maybe there’d be a cross link and single sentence mentioning the fact that in some English speaking countries, the term Parmesan is used to describe a pale imitation product. If Parmesan is still a particularly significant US product, then it would be notable enough for its own article. MapReader (talk) 20:42, 24 March 2024 (UTC)[reply]
    I agree. There are two kinds of cheese: "Parmigiano Reggiano" (a controlled name only from a specific place in Italy) and "Parmesan" (the cheap American knock-off, often sold as a white powdery cheese-like substance). The differences between these are maybe larger than between Parmigiano Reggiano and Grana Padano. They are separate enough that we should have two separate articles for them. Then there would be no dispute over the name. —David Eppstein (talk) 20:50, 24 March 2024 (UTC)[reply]
    @David Eppstein I've a feeling they might *both* officially have that restriction here (UK), but I'm not sure. It's not something I habitually buy, so I've not needed to know. Musiconeologist (talk) 21:11, 24 March 2024 (UTC)[reply]
    If there's a place that only allows "Parmesan" to refer to cheese from the province of Parma, we could mention that in either or both articles, but that doesn't change the basic facts that there are two distinct types of cheese and we should have articles on types of cheese not on commonly-conflated names of cheese per WP:NOTDICT. —David Eppstein (talk) 21:17, 24 March 2024 (UTC)[reply]
    @David Eppstein I'd certainly agree with that. Musiconeologist (talk) 22:05, 24 March 2024 (UTC)[reply]
    • Comment - first of all, this is not the appropriate venue to be having this discussion, at least if you expect some binding result to emerge from it. If someone wants to propose splitting, then a discussion at Talk:Parmesan Is in order, and similarly an RM for a proposed move. I don't see any questions here that rise to needing clarification at MOS level. As for the question itself, I'm surprised at the suggestion that "Parmesan" is obsolete or only used by old people. I live in the UK and I'm not sure I recall anyone saying Parmigiano, informally in conversation and also Italian restaurants still seem to generally offer it as Parmesan. Perhaps the packaging on supermarket cheese does say that though, if only for legal reasons. A thorough analysis of sources would be required in any case.  — Amakuru (talk) 22:22, 24 March 2024 (UTC)[reply]
    @Amakuru: could we move this discussion to the Parmesan talk page and continue there? Thank you. JacktheBrown (talk) 22:34, 24 March 2024 (UTC)[reply]
    Agreed. There's actually a thread opened on this at Talk: Parmesan (which I've just posted to) which was opened in January. Someone should just close this thread and note the continuation there. DeCausa (talk) 22:41, 24 March 2024 (UTC)[reply]
    @DeCausa: no, we need to move these comments, they're important. JacktheBrown (talk) 22:43, 24 March 2024 (UTC)[reply]
    I don't see why. A link would do - and I'm not sure what's here is that enlightening! DeCausa (talk) 22:47, 24 March 2024 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.