Jump to content

Wikipedia talk:Manual of Style

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

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:

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

    Move requests:

    Other discussions:

    Pretty stale but not "concluded":

    Concluded[edit]

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

    Reconsider ellipsis ... vs … preference[edit]

    Support for … (unicode ellipsis, U+2026) is widespread now. The decision to prefer ... over …[1] was made 15-20 years ago when unicode support was nascent.[2]

    Benefits of … (unicode ellipsis)

    1. More accessible — screen readers can read "ellipsis" properly
    2. more compact & readable. Better line breaks
    3. renders with better fidelity using font glyph
    4. scales better when zooming & with high-DPI devices like mobile phones
    5. easier to parse (distinct unicode representation for character)

    Tonymetz 💬 18:01, 16 April 2024 (UTC)[reply]

    If we discuss this, we need to discuss the use of typographical quotation marks too! Gawaon (talk) 18:23, 16 April 2024 (UTC)[reply]
    Eh, I'm not so sure about that. Curly quotes have drawbacks (e.g. being 'keyed', being more frequent to the degree where I would argue the extra byte substantially increases page sizes on average) that U+2026 … HORIZONTAL ELLIPSIS does not. Remsense诉 18:36, 16 April 2024 (UTC)[reply]
    Fair enough. We also use en dash (–) and friends, after all. Gawaon (talk) 20:05, 16 April 2024 (UTC)[reply]
    I agree with Gawaon's 1st sentiment that curly quotation marks/apostrophes should be discussed in the same vein as ellipses. Both deal with the distinction of ASCII representation vs. extended character maps. I don't think that their multi-byte effect on increased page size is of any concern. -- Michael Bednarek (talk) 04:49, 17 April 2024 (UTC)[reply]
    I know! Let's have an RfC on whether they should be discussed together! EEng 15:11, 21 April 2024 (UTC)[reply]
    The big BIG advantage of requiring straight quotes and period ... ellipses is that it doesn't allow yet another gratuitous style variation for gnomes to slow-war over. It looks fine, it works, it contributes to having a clean readable style instead of a fussy special-character-elaborated one. Why get rid of those advantages? —David Eppstein (talk) 06:57, 17 April 2024 (UTC)[reply]
    Though I said the opposite above, I think it might indeed make most sense to limit this to the ellipsis issue for now, since it would be a relatively small change – much smaller than changing the rules for quotes and apostrophes. So if this is changed now, the quote issue could possibly be reconsidered in a year or two, then taking into account the experience with the ellipsis change.
    For the ellipsis, there are two possibilities:
    1. Allowing both ... and … as equally valid options. Very easy change, but with the disadvantage that usage in any given page could then be mixed, annoying the typographically aware. Though the visible difference between ... and … is small (much smaller than "quotes" vs. “quotes”, I'd say – in fact, in our standard font I can hardly see it), so that shouldn't matter very much. Also, to prevent "slow-warring", we could make the rule that changing ... to … is allowed, but changing in the opposite direction is not. In that way, pages would slowly evolved in the typographically correct direction.
    2. Requiring, from now on, that … is used, and deprecating ..., just like MOS:DASH has deprecated the use of single or double hyphens instead of dashes. This would ensure that there is a single standard all pages are meant to adhere to, so totally eliminating the risk of edit warring. The disadvantage, of course, is that there are 100,000s of pages (at least) that currently don't adhere to that standard. I suppose a bot could help with that change, but it would still be a giant task to bring them in adherence.
    Personally I think option 1. would be fine, while 2. daunts me a bit because of the size of the required changes. Gawaon (talk) 07:39, 17 April 2024 (UTC)[reply]
    While I'm not opposed on principle, I doubt implementing this change across thousands of articles would be feasible. InfiniteNexus (talk) 23:48, 20 April 2024 (UTC)[reply]
    Well, option 1 wouldn't have to be "implemented", it would just be an option for editors to choose from now on. Gawaon (talk) 06:06, 21 April 2024 (UTC)[reply]
    Bad idea. The point of an MoS is to be as consistent as possible. And changes would have to be implemented regardless; if you don't do anything, AWB, bots, and other automated tools will just continue changing them. InfiniteNexus (talk) 06:10, 21 April 2024 (UTC)[reply]
    Oppose any "use whichever style you want" option. Gonnym (talk) 11:24, 21 April 2024 (UTC)[reply]
    I have no real preference for one or the other, but I oppose the change. It wouldn't be too much work for a bot to change all of one to another. Still I see no reason to mess with what's been working. Actually, I do prefer the three dots. Anyone can type ... and the … requires a bit more effort, and … displays differently depending on the font used, so sometimes looks odd. Mixed use looks sloppy and I really want to avoid that. SchreiberBike | ⌨  11:48, 21 April 2024 (UTC)[reply]
    I'm wary of creating yet another challenge for new editors who want to do the right thing – we want to keep them. NebY (talk) 14:26, 21 April 2024 (UTC)[reply]
    My preference would be to create templates for such things as ellipses and in-line quote[a] and relegate the style arguments to the talk pages of those templates. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:55, 22 April 2024 (UTC)[reply]
    I would support mandating the unicode ellipsis. Adding this to the MOS wouldn't create any burden to new users – gnomes would simply bring articles into conformity over time. Graham11 (talk) 03:36, 21 May 2024 (UTC)[reply]
    More likely some bot operator is going to get it into their head that this must be done immediately!!1! and make our watchlists unusable for several days while they crank through all the Wikipedia articles at a rate of several per second. How about let's don't. —David Eppstein (talk) 07:16, 21 May 2024 (UTC)[reply]
    There's a 200% chance this will happen, because at least two bot operators will try it. Remsense诉 07:17, 21 May 2024 (UTC)[reply]
    Isn't that a matter that should be addressed at WP:BRFA? Graham11 (talk) 17:10, 21 May 2024 (UTC)[reply]
    If the Unicode ellipsis is better for screenreaders, we should go for it. Just add an ellipsis option to the usual dash scripts. —Kusma (talk) 19:28, 21 May 2024 (UTC)[reply]
    Is there any more reason to believe that it is better for screenreaders than to believe that it is worse for screenreaders? One could equally well write, if it is worse for screenreaders, then we should continue to eschew it. —David Eppstein (talk) 20:03, 21 May 2024 (UTC)[reply]
    On a quick Google, I have found some accessibility blogs that advocate use of the ellipsis character over three dots. I have no idea how important it is in practice. —Kusma (talk) 20:19, 21 May 2024 (UTC)[reply]
    Have you considered asking at WT:WPACCESS? --Redrose64 🌹 (talk) 21:50, 21 May 2024 (UTC)[reply]
    I just brought it up at Wikipedia talk:WikiProject Accessibility#Is there a preference from an accessibility standpoint for ellipses (...) style? SchreiberBike | ⌨  — Preceding undated comment added 23:02, 21 May 2024‎ (UTC)[reply]
    I think we should be ok with either. There doesn't need to be consistency for this. —TheDJ (talk • contribs) 07:21, 20 June 2024 (UTC)[reply]

    Require semantically/typographically correct ellipsis per accessibility issues. Allow someone to type in three periods for convenience, but keep it deprecated and have semi-automated tools and bots change this as long as they are making other changes as well. Change all page and category titles as well with redirects from three dots. ―Justin (koavf)❤T☮C☺M☯ 23:07, 21 May 2024 (UTC)[reply]

    As a screen reader user, I've never heard of these accessibility issues ... screen readers can read three dots fine. It really doesn't need a mass change here. Graham87 (talk) 07:54, 22 May 2024 (UTC)[reply]
    How mean of you. You've just taken away some gnome's purpose in life. (For those playing along at home, we've now got two Graham's Grahams in the conversation.) EEng 13:59, 22 May 2024 (UTC)[reply]
    Bold of you to write "Graham's" on this talk page! JoelleJay (talk) 00:35, 12 June 2024 (UTC)[reply]
    Something like that always happens when I'm being a smartass. EEng 08:55, 12 June 2024 (UTC)[reply]
    Graham's law says that the rate of hot air escaping from a talk page discussion is inversely proportional to the square root of the weight of the arguments contained within. Hawkeye7 (discuss) 03:54, 12 June 2024 (UTC)}[reply]

    Oppose any change - three dots is fine and easier to write. Then again, if it's not onerous to make a bot that turns every instance of ... into … after every single edit that includes ..., I'm not going to lose any sleep over it. BoldGnome (talk) 02:57, 12 June 2024 (UTC)[reply]

    Notes

    1. ^ In some cases the obvious name is already taken, e.g.,
      {{ellipsis}}
      This template should not be used in Main namespace; it will instead display an error message.
      {{quote}}
      A wrapper for <blockquote>...</blockquote>.

    Allow either ... or …. I agree with the (minor) advantages of using the unicode character, but changing it everywhere seems like a huge waste of time and effort. We should just be agnostic about it, IMO. Nosferattus (talk) 18:14, 20 June 2024 (UTC)[reply]

    The problem with "allow either" is that in some fonts they look very different from each other. Having "..." and "…" near each other looks pretty bad to me. SchreiberBike | ⌨  20:46, 20 June 2024 (UTC)[reply]

    Change "foreign-language" to "non-English language"?[edit]

    Of course "foreign-language" is a common adjective to mean "in a language other than English" and that's fine, but it also looks a bit odd in the guidelines of an international internet encyclopedia? "non-English language" is clunkier I'll admit, but it's also more precise in a way that seemingly doesn't cost much. Should we consider changing it on policy and guideline pages?

    (I'm fairly sure it shouldn't be non–English language or non-English-language even as an adjective, right? Those both look ridiculous.)Remsense诉 05:28, 3 May 2024 (UTC)[reply]

    Agree. “Foreign” presupposes where the reader is, which isn’t appropriate for an international encyclopaedia. MapReader (talk) 07:08, 3 May 2024 (UTC)[reply]
    My concern is that "non-English" might exclude the English-based creoles like Nigerian Pidgin; we should treat these creoles as we would treat any other non-English language, as English speakers tend to be unable to understand them. BilledMammal (talk) 08:28, 3 May 2024 (UTC)[reply]
    I think it is fairly safe to say that no one would have this as their public definition of "English language", right? Remsense诉 08:37, 3 May 2024 (UTC)[reply]
    It’s not exactly an English language - but it’s also not exactly a non-English language. BilledMammal (talk) 08:52, 3 May 2024 (UTC)[reply]
    Right, so how does "foreign language" do better with that ambiguity? I would think it does worse. There's no definite boundaries between any two lects you can define. Remsense诉 08:54, 3 May 2024 (UTC)[reply]
    Don't fix what ain't broke. Foreign is fine as we all know it means a language other than English. Masterhatch (talk) 08:48, 3 May 2024 (UTC)[reply]
    I would agree if it were a big deal to fix. Plus, it is a little bit broken—we all know what a lot of words *should* mean, but that doesn't mean we can't seek to further improve our word choices. Remsense诉 08:50, 3 May 2024 (UTC)[reply]
    Agree. 'Foreign' is not necessarily the same as non-English even when you assume the reader/editor is in a country where English is the most commonly spoken language. Many countries where English is the norm were colonised and had/have indigenous languages of their own, which would be odd to call 'foreign'. FropFrop (talk) 09:04, 18 May 2024 (UTC)[reply]
    You aren't wrong. We can simplify most of this, avoiding "non-English language". In this main MoS page, nearly all uses of "foreign" are either to qualify a noun other than "language" ("foreign words", "foreign text") or in the adjectival "foreign-language" to qualify a noun. In the former cases, just replace "foreign" with "non-English". In the latter, replace "foreign-language" with "non-English", omitting "language". A couple of cases are tricky because they link to sections currently titled "Foreign languages" on other MoS pages. Those can be dealt with in turn but is there anything objectionable about my proposal to make the first round of substitutions forthwith? Even to the extent that I could argue that, pragmatically, readers will know what we mean, "non-English" is better.
    Finally, for the noun phrase "foreign language(s)", "language(s) other than English" seems more natural than "non-English language(s)". Largoplazo (talk) 11:43, 18 May 2024 (UTC)[reply]
    Agreed for all the reasons you've provided. "Non-English languages" is fine enough to me. – Primium (talk) 23:14, 13 June 2024 (UTC)[reply]

    "was" vs "is" for Wikipedia articles about human remains[edit]

    I previously opened a thread about this topic here: Wikipedia_talk:WikiProject_Archaeology#"was"_vs_"is"_for_individual_ancient_human_skeletons, but I think here is more appropriate. Looking at the articles listed at Category:Homo sapiens fossils (which is misleadingly titled, including remains from the last few thousand years which definitely aren't fossils), it seems to be the standard for Wikipedia articles about individual human skeletons, mummies and the like to describe them as human remains in the present tense, rather than as deceased humans in the past tense. Examples of this include for example, Cheddar Man, Ötzi, and The Younger Lady. Is this correct according to the MOS? As noted in the WT:ARCHAEOLOGY discussion the idea of describing Native American remains in the present tense like this has received pushback. I don't have a strong opinion about which way should be preferred, but I think there should be consistency regarding the way the remains of all deceased humans should be described. Hemiauchenia (talk) 22:37, 27 May 2024 (UTC)[reply]

    Arlington Springs Man is on my watchlist, and there's been some recent back-and-forth in the edit history around that question. Currently, it reads:

    Arlington Springs Man was a Paleo-Indian whose remains were found in 1959 on Santa Rosa Island...

    The alternate version that's been proposed (via edits) is:

    Arlington Springs Man is the skeleton of a Paleo-Indian which was found in 1959 on Santa Rosa Island

    I found @GreenC:'s edit summary thought-provoking and convincing: "They are the remains of an individual human being and needs to be treated as such. This is not an article about a dinosaur, rock, or woolly mammoth. This is why NAGPRA exists to deal with the dehumanizing of Indian ancestors as merely relics or old bones stored in a warehouse." Schazjmd (talk) 22:45, 27 May 2024 (UTC)[reply]
    My point is that the remains of Native Americans shouldn't be treated any different than those of other humans. If we are going to have a standard of describing Native American humans remains as "was a person" rather than "is skeleton/mummy" then this should be broadly applied to all articles about human remains. As far as I can tell, this "was a person" has so far only been inconsistently applied to Native American articles, for example the Incan mummy articles Aconcagua mummy, Mummy Juanita and Plomo Mummy are all in the present tense. Hemiauchenia (talk) 22:54, 27 May 2024 (UTC)[reply]
    I agree with all human remains being treated consistently in article leads. I just found the edit summary persuasive that it's more respectful to recognize that they were a person. Schazjmd (talk) 23:09, 27 May 2024 (UTC)[reply]
    • The difference is some old remains nobody claims/cares anymore as an ancestor or relative, and some do. Personally I think all these articles should be framed foremost as about a person because it makes for a better and more accurate article, given that perspective. Many of these articles are poorly written they get confused on this moving back and forth about bones or person sort of willy nilly with no compass. Sometimes a sentence might concern the remains, sometimes not, you need to know when to use which. The lead sentence framing concerns a person is the main compass direction, because that is why remains are studied, to learn about the person and their culture. The remains are only one aspect of the person. This is borne out when you read these articles, they concern much more than the remains. The articles concern the life of the individual, as learned through the remains. -- GreenC 23:12, 27 May 2024 (UTC)[reply]
    I don't think consistency is very important here. If Native Americans prefer that their ancestors be talked about a certain way (I have no idea), then why wouldn't we respect that? On the other hand, that doesn't mean we should talk about remains like Cheddar Man or Ötzi—that don't come from an Indigenous/settler-colonial context—in the same way.
    I usually use the present tense for purely pedantic reasons, i.e. to avoid anachronisms. Sentences like Arlington Springs Man was a Paleo-Indian [...] are factually incorrect: there was nobody called "Arlington Springs Man" in the past and nobody who considered themselves "Paleo-Indian". In my experience this overwhelmingly how archaeologists and other scientists that study human remains talk about them, for what that's worth.
    If the concern is dehumanisation, an (admittedly quite awkward) compromise could be something like Arlington Springs Man is the name given to a Native American man [...]. I do disagree with GreenC above: these articles are first and foremost about the remains of a person, not the person. We can infer some things about the latter from the former but it is not accurate, and potentially offensive, to write as if we can narrate a person's life from their bones. – Joe (talk) 09:14, 4 June 2024 (UTC)[reply]
    Arlington Springs Man has the Note after his name in the lead sentence: "His historical name is unknown. A moniker was invented as a means of identification." You could say "Arlington Springs Man is a moniker for a Native American man .. " but this is overly fussy and already obvious to 99% of readers, a Note serves that purpose fine. There is some guideline somewhere that advises against this sort of thing, say what it is sufficiently for understanding, don't qualify too much in the lead sentence, we are writing for a general audience. See WP:LEAD for the purpose of the lead and how to write a good lead section. -- GreenC 15:46, 4 June 2024 (UTC)[reply]
    The formulation "X is the remains of"—the status quo you're objecting to—also conforms to WP:LEAD. – Joe (talk) 07:42, 5 June 2024 (UTC)[reply]
    • If we're talking about a person who has died, it's past tense. If we're talking about remains that still exist its present tense. Am I missing some nuance here? I don't see why it's different to anything or anyone else. For most people we don't talk about their still existing remains once they die, but in these cases we are. Canterbury Tail talk 11:43, 4 June 2024 (UTC)[reply]
      It concerns the framing and topic creation of the lead sentence:
      1. "Ötzi is the natural mummy of a man" (lead sentence)
      This is incorrect. The article frames the name "Ötzi" as the remains, and not a moniker for the once-living man. Nevertheless, throughout the rest of the article, it refers to "him" and "he". The article is thus confused as to what the name Ötzi refers to, indeed what the topic of the article is: a person, or human remains. The lead sentence could more accurately say "Ötzi was a Bronze-age man whose mummified remains.."
      1. "Kennewick Man was an ancient Indigenous American man whose skeletal remains were found .." (lead sentence)
      This is correct. The primary topic of the article concerns a man, his life, environment, culture .. of which the remains are an aspect of that man's life and death.
      We have many articles that frame individual people as physical objects in the lead sentence. -- GreenC 15:22, 4 June 2024 (UTC)[reply]
      What do you mean by "correct" and "incorrect" here? Looking through the first couple of pages of Google Scholar results for "Ötzi", almost all of them primarily discuss a "mummy", "corpse", or "iceman", rather than a person. Are they incorrect? – Joe (talk) 08:07, 5 June 2024 (UTC)[reply]
      Well, of course both are "correct", but we need to choose the best option for a general purpose general reader encyclopedia. We are not writing a journal article. Wikipedia articles cover all aspects of the person including their remains but not limited to their remains. -- GreenC 15:11, 5 June 2024 (UTC)[reply]

    Parenthetical plural(s)?[edit]

    It seems that the particular constructions referred to as "parenthetical plurals" by style guides—e.g. when posting thread(s),—have never been discussed here before, which is a bit shocking. Here's a quick pitch for why we should consider explicitly deprecating their use in article(s):

    • They are almost entirely useless, and usually do not clarify any ambiguity. This is the case for WP:AND/OR but stronger. Use of a plural form to indicate "any number of" is usually completely fine, and when it's not there's usually a broader problem with the structure of your sentence.
    • Something something, brackets can create problems for wikitext, somehow.
    • While neither AMA nor Chicago explicitly disallow parenthetical plurals, they both firmly suggest that you should never have to use them.
    • They are ugly.

    Remsense诉 09:46, 31 May 2024 (UTC)[reply]

    At least in the example given, the construction is worse than ugly: when posting thread is plain ungrammatical. --Florian Blaschke (talk) 20:52, 20 June 2024 (UTC)[reply]
    That's my bad. Remsense诉 20:15, 28 June 2024 (UTC)[reply]
    I personally nuke these on sight and I can't recall even once getting any pushback for it. Primergrey (talk) 20:12, 28 June 2024 (UTC)[reply]

    WP:SDAVOID[edit]

    Hi. I have been seeing editors removing former from short descriptions on corporate articles, using the essay WP:SDAVOID as the reasoning. I wonder if other editors believe the same as me as this madness, as leaving defunct companies with short descriptions without it is inaccurate. For example Cavenham Foods or Tudor Crisps who have been defunct for quite some time. Davidstewartharvey (talk) 05:31, 3 June 2024 (UTC)[reply]

    I agree with you. --Cyfal (talk) 05:56, 3 June 2024 (UTC)[reply]
    Short descriptions are supposed to give extremely brief descriptions for the purpose of disambiguation. I don't see time-specific descriptors as critical for that, so I'm in favor of keeping them out. It's not misleading to omit the information. Popcornfud (talk) 06:16, 3 June 2024 (UTC)[reply]
    Yeah, leaving it out seems fine (and indeed preferable) to me too. That there is an article about a company doesn't imply it still exists, so there is no need for such qualifiers. Gawaon (talk) 06:42, 3 June 2024 (UTC)[reply]
    The short description for Canaan reads "Region in the ancient Near East". It isn't implying that Canaan exists now, it's just identifying it as what it was when it was. The same goes for products and corporations. Just understand the SD to be explaining not what the topic is but what it is-or-was. Largoplazo (talk) 09:39, 3 June 2024 (UTC)[reply]

    Citations within quotes?[edit]

    This is a bit confusing, so let me try to give an example.

    Suppose we have a book, A Great Book by Joe Sixpack, that says something like this:

    The sky is blue.[15]

    Then at the end of the book is a list of sources, including one for footnote 15. Let's call this "The Original Source". So we have a book by Sixpack that cites "The Original Source".

    Now we want to quote from A Great Book in a Wikipedia article. And we do so like this, preserving not just the quote, but Sixpack's source citation too:

    In his book A Great Book, Sixpack says that "The sky is blue.[1]"[2]

    I find this awkward and unnecessary. I would leave out the citation to "The Original Source". Verifiability is still preserved, because a curious reader can look up Sixpack and from there find The Original Source. Does this seem right?

    I found this at Lynn Conway, the quote that starts with "By taking this job". GA-RT-22 (talk) 16:23, 12 June 2024 (UTC)[reply]

    @GA-RT-22: WP:SAYWHEREYOUGOTIT - just cite A Great Book by Joe Sixpack, with page number. --Redrose64 🌹 (talk) 18:58, 12 June 2024 (UTC)[reply]
    Exactly what I need. Thanks! GA-RT-22 (talk) 20:20, 12 June 2024 (UTC)[reply]
    Redrose64 is right, of course, but it's also true that (a) you might as well look at Original Source to see if it meets our own standards (it usually will, if A Great Book is published by a good publisher), and (b) if it's easy to access Original Source it's worth taking a look at that too. At least once that I recall I've found that Joe Sixpack misinterpreted Original Source. Mike Christie (talk - contribs - library) 20:57, 12 June 2024 (UTC)[reply]

    References

    1. ^ The Original Source
    2. ^ Joe Sixpack. A Great Book.

    Discussion on other talk page and project[edit]

    See Wikipedia:Village pump (policy)‎#MOS on date format by country and Talk:Lisa del Giocondo‎#Edit warring about whether the date format customary in a non-English speaking country has any bearing on what date format should be used in an English Wikipedia article. Jc3s5h (talk) 21:04, 17 June 2024 (UTC)[reply]

    Should orthographical variations be mentioned in place names[edit]

    Title, should orthographical variants be included when place names are given? Traumnovelle (talk) 07:11, 19 June 2024 (UTC)[reply]

    I think it has to depend on the history of the orthographies in question. For one particular case, MOS:ZH says that alternate/historical romanizations of Chinese place names generally shouldn't be used, even if they appear as a part of other proper names: e.g. Tsingtao Brewery Co., Ltd. is located in Qingdao, Shandong. Remsense诉 07:22, 19 June 2024 (UTC)[reply]
    It's not historical but it isn't commonly used outside of a minority group essentially. It's Pokeno, which instead of using a macron is sometimes spelt as Pookeno but I can't find any reliable source that actually uses this spelling. Mayhap it is more akin to dialectal variations. Traumnovelle (talk) 07:30, 19 June 2024 (UTC)[reply]
    If ultimately attested in RS, I think this is worth mentioning, maybe in a footnote. Remsense诉 07:35, 19 June 2024 (UTC)[reply]
    Can you give an example of what you're asking about? Largoplazo (talk) 10:23, 19 June 2024 (UTC)[reply]
    The example is in my other comment. Traumnovelle (talk) 19:52, 19 June 2024 (UTC)[reply]

    Indentation[edit]

    This week I took a long time to learn how to enable a first-line indentation and I would like to float the possibility of improving the sentence under 'Indentation' which cites two templates to enable other editors to learn how to use them more quickly. Would anyone be willing to mentor me if I tried to improve it to achieve this objective? For the record, I should disclose that I am new to templates.John Desmond (talk) 15:09, 20 June 2024 (UTC) .[reply]

    What do you mean by "first-line indentation"? EEng 17:21, 20 June 2024 (UTC)[reply]
    Some of my friends, yesterday
    I suspect that John Desmond refers to a common practice in printed books where the first line of a paragraph is indented by one or two em. --Redrose64 🌹 (talk) 20:40, 21 June 2024 (UTC)[reply]
    Not really relevant for Wikipedia, though, it seems. Gawaon (talk) 20:58, 21 June 2024 (UTC)[reply]
    That's a correct suspicion - see John Desmond's edit here, for example. Davidships (talk) 00:01, 22 June 2024 (UTC)[reply]

    Semi-protected edit request on 20 June 2024[edit]

    A$ is similar to 'As'. So, change A$ to AU$. 70.22.248.187 (talk) 17:30, 20 June 2024 (UTC)[reply]

     Not done: A change of this magnitude would require consensus and affect a significant number of articles. GSK (talk • edits) 17:58, 20 June 2024 (UTC)[reply]

    Improvement to advice about embedded section anchors[edit]

    I just made this edit to MOS section § Section headings to add this explanatory note (name="many links") to the portion targeted by MOS:SECTIONANCHOR:

    To find out how many inlinks there are to the old section title and what articles have them, you can execute this advanced search this advanced search, changing article to the name of the article, and oldsection to the old section title. If there are only a small number of links to the old section title, it's better to just update them..

    I recently noticed that a bunch of users have added unneeded embedded section anchors after renaming a section header, presumably because they don't know how to find out if there are any articles that link to the old section title or not, and if so, how many of them there are. Imho, embedded section anchors should only be added when necessary, as they create squirrely wikicode which may mystify other editors, or discourage them from making further changes to the section header which may be warranted. To reduce the scope of this issue, increase transparency about section inlinks, and limit the number of unneeded embedded anchors being created especially when there are no incoming links at all (a good proportion of them), I added the note. (A secondary problem, much less serious imho, is users using the problematic, unsubsted version identified at MOS:SECTIONANCHOR as resulting in undesirable behavior.)

    I would appreciate additional eyeballs on this note, both the wording as well as any comments on the generic advanced search terms. I am aware that the search doesn't include everything (notably, will not find links from articles using {{slink}} to target it) or exclude (nowiki's, html comments) but I am trying to keep the input search term field simple-looking enough that a user unfamiliar with advanced search won't be afraid to try it, so it's kind of a balancing act how complex to make it. That said, if there's anything egregiously missing or wrong with it, or if it can be significantly improved without degrading usability, please do comment, or just adjust it. Adding @PrimeHunter, Sdkb, Trialpears, Qwerfjkl, Colin M, Quiddity, and Rjjiii:. Thanks, Mathglot (talk) 23:13, 26 June 2024 (UTC)[reply]

    Thanks for adding this tip! Marginally related, is there some way to find all broken section anchors pointing to some article? I would find that extremely helpful in order to improve the integration of a page that has underdone a lot of reorganization over time so that this method of looking for broken section links by name is not practical. Gawaon (talk) 06:08, 27 June 2024 (UTC)[reply]
    This would be better handled in its own section. Please see WP:VPT#Finding broken section anchors. Thanks, Mathglot (talk) 02:42, 28 June 2024 (UTC)[reply]
    Look great, thanks! Better than my usual method, clicking through every page of the "What links here?" results and Ctrl-F-ing the old section title. Firefangledfeathers (talk / contribs) 11:55, 27 June 2024 (UTC)[reply]
    Good info! Thanks for researching, documenting, and pinging. Quiddity (talk) 03:52, 28 June 2024 (UTC)[reply]

    Note: updated the advanced search link (new link) to also handle templated links like {{slink}}, {{Further}}, {{Main}}, etc., without making it longer or scarier-looking. Mathglot (talk) 01:44, 28 June 2024 (UTC)[reply]

    @Mathglot: If you go to the link and then change the terms to what you want before clicking search it finds all links to that section in articles, but if you edit the link and go to it directly, it searches in all pages. Is that fine? – 2804:F1...A9:64C1 (talk) 03:51, 28 June 2024 (UTC)[reply]
    Not entirely sure I understand; are you trying to draw a distinction between searching only articles (i.e., main space) and searching all namespaces (articles, Talk pages, User pages, Wikipedia project pages and so on)? If so, we can do that by adding search term :all and perhaps we should. I've updated the search link in the explanatory note to search all namespaces, pending any objections or other comments on this aspect of it. Mathglot (talk) 04:07, 28 June 2024 (UTC)[reply]
    I meant that the link included profile=all, so editing the link itself would result in searching all pages (any namespace), but going to the link and then editing the terms and clicking search would result in searching only in articles.
    Anyways, now the :all is not* doing anything, try for example, searching for :all linksto:"Banana" insource:/[[|]Banana\#/ vs without the :all (but with all namespaces selected).
    Edit: *It is doing something, if you select all namespaces it ignores them and searches only in article space. Hm. – 2804:F1...A9:64C1 (talk) 04:36, 28 June 2024 (UTC)[reply]
    (edit conflict) The problem is not in the link, but in your example. If you choose an article name which has no links outside mainspace, like Banana, then the correct behavior is that there is no difference with or without the :all search term. Try an example like "Vichy France" which has some inlinks from mainspace, as well as other namespaces.
    Secondly, although that will actually work correctly, even without a section name, this whole issue is part of the clarification of section § Section headings in the MOS, so really applies more to that case. For that, you can try examples like "Vichy France#Collaborationnistes". (ec) Mathglot (talk) 04:42, 28 June 2024 (UTC)[reply]
    It has links outside of mainspace, that's why I said to remove the :all and select all namespaces. – 2804:F1...A9:64C1 (talk) 04:45, 28 June 2024 (UTC)[reply]
    Thanks for that; I must've been assuming the wrong functionality for :all; I need to look at that again. Your workaround works, but should be doable without it, assuming there is a search prefix or pseudo-term that activates that; let me check. If you know what it is, please post it. Mathglot (talk) 04:51, 28 June 2024 (UTC)[reply]
    Ah, I found it, it is all:. – 2804:F1...A9:64C1 (talk) 04:56, 28 June 2024 (UTC)[reply]
    Oops, of course it is; the colon goes at the end in every search term, don't know how that happened. Will go fix that. Mathglot (talk) 04:58, 28 June 2024 (UTC)[reply]
    Okay, colon is in the right place now; try "Banana" again. Mathglot (talk) 05:04, 28 June 2024 (UTC)[reply]
    It works, behaviour is consistent now, thank you, and for the info :). – 2804:F1...A9:64C1 (talk) 05:12, 28 June 2024 (UTC)[reply]
    Thanks for your efforts, which have helped improve it. Mathglot (talk) 06:04, 28 June 2024 (UTC)[reply]

    I made this edit based on recent observation. Correct me if I'm wrong. Biogeographist (talk) 20:57, 28 June 2024 (UTC)[reply]

    Adding that sentence about searching redirects as well looks like an improvement to me. Even if there's a way to do that via advanced search (instead of What links here), Cirrus doesn't support alternation, so you can't have the union of two searches in one query, afaik; plus, that might get into "too complex" territory even if we could, so I think your approach is the right one, here. Thanks, Mathglot (talk) 21:17, 28 June 2024 (UTC)[reply]
    There is also Wikipedia:Database reports/Broken section anchors that could be checked, though only afterwards (and with up to one month's delay). Gawaon (talk) 21:16, 28 June 2024 (UTC)[reply]

    Use of em dashes to join place names in naming electoral districts[edit]

    Please see this discussion about the use of em dashes to join place names in naming Canadian electoral districts. – Jonesey95 (talk) 18:27, 27 June 2024 (UTC)[reply]

    What tense should be used in articles about obsolete computers?[edit]

    MOS:TENSE says:

    "By default, write articles in the present tense..." and "Generally, use past tense only for past events, and for subjects that are dead or no longer meaningfully exist."

    The page gives an example: "The PDP-10 is a mainframe computer family manufactured by Digital Equipment Corporation from 1966 into the 1980s."

    There is a big discrepancy concerning tense in articles about old computers (Vintage computer). One issue is if they "meaningfully exist". Consider some one-of-a-kind computers:

    • The IAS machine is intact and exists in the collection of the Smithsonian (I saw it on display in 1967), but it is no longer on display and doesn't work.
    • ENIAC - all (or almost all) of the parts of ENIAC exist, but they are spread out among several museums and displays (I've seem most of the parts.)
    • Whirlwind I - a few parts still exist.
    • BINAC - I don't think any of this computer still exists.

    Then there are computers of which many were made. There are several non-working examples (e.g. UNIVAC I) in museums (Computer History Museum and others). There are even a few working examples. The Living Computers: Museum + Labs had quite a few computers that were made decades ago and are still working.

    Anyhow, I'm looking for guidelines about what tense should be used. Most of the articles use past tense for these old computers. Bubba73 You talkin' to me? 01:21, 28 June 2024 (UTC)[reply]

    FWIW, the car articles are equally inconsistent. Ford Model T and Ford Model A (1903–04) use present tense. DeSoto (automobile), Imperial (automobile), and Plymouth (automobile) all use past tense. RoySmith (talk) 01:42, 28 June 2024 (UTC) :The above is not a technical question, AFAICT. Wikipedia talk:Manual of Style is probably the right venue for this inquiry. – Jonesey95 (talk) 06:15, 28 June 2024 (UTC) [reply]

    OK, I'll move it when I have time. Bubba73 You talkin' to me? 15:41, 28 June 2024 (UTC) [reply]
    If there's even one existing working example the guidance is pretty clear. Use present tense. There's even a strong case for non-working examples if their historic value is "meaningful" enough, but that's not so cut and dry. Primergrey (talk) 18:17, 28 June 2024 (UTC)[reply]
    And regarding the automobile articles, the Ford ones are about models that do exist. The others are about companies that do not. Primergrey (talk) 18:21, 28 June 2024 (UTC)[reply]
    For computers, I'd say that "no longer meaningfully exist" should be interpreted as "no working exemplars exist". If a running computer exists somewhere, its article should be in present tense, otherwise past tense. Indefatigable (talk) 18:18, 28 June 2024 (UTC)[reply]
    It isn't always easy to tell if there is a running example somewhere. And when there is, they are usually in a collection to demonstrate it - it is not doing productive work anymore. Bubba73 You talkin' to me? 21:33, 28 June 2024 (UTC)[reply]
    Does it have to be doing productive work? Various sorts of steam engines are lovingly restored, maintained and displayed in all their gleaming, puffing glory; each one definitely exists though few are doing anything productive. NebY (talk) 00:59, 29 June 2024 (UTC)[reply]
    Good point. If it is working, then it "meaningfully exists". Bubba73 You talkin' to me? 01:28, 29 June 2024 (UTC)[reply]
    It depends on what the meaning of is is. Mathglot (talk) 22:02, 28 June 2024 (UTC)[reply]
    Or it depends of what the meaning of meaningful is. Bubba73 You talkin' to me? 01:29, 29 June 2024 (UTC)[reply]

    And, as an example, the page uses present tense for the family of PDP-10 computers manufactured from 1966 to the 1980s. It is very unlikely that any particular one of them is still running and doing productive work, but the recently closed Living Computer Museum had five working ones. Bubba73 You talkin' to me? 00:51, 29 June 2024 (UTC)[reply]

    Size and power costs make it unlikely that historical computers are doing productive work. But if I can go to a museum and see a complete one, even in a non-working state then I would definitely say that computer "is". Same for mostly complete (say 80-90%) machines. Less than that gets murky. Parts spread over different locations is probably "was" but may be gathered back into a (near) whole machine again. But there isn't any real consequence of getting this wrong. So, I'd just say that any machine physically near complete (say 80% or better) in a single location, working or not is a computer still in existence and anything else is no longer in existence. For the borderline cases, flip a coin and move on with life.  Stepho  talk  02:07, 29 June 2024 (UTC)[reply]
    Something like the GE-200 series, I have no idea if one still exists. Bubba73 You talkin' to me? 02:32, 29 June 2024 (UTC)[reply]
    Most often the name of a computer refers to the definition of its architecture. There are no "PDP-10" computers, but there are the KA-10, KI-10, etc. But there are books that describe the architecture of the PDP-10, and those books exist. Some architectures never existed. The general rule is that events (in the past) are past tense. Computers were designed, introduced, sold, rented, and such, in the past. Note, for example, that Shakespeare's plays are present tense, even though he is dead, and even though one might not be being performed. Since the written form exists, they should be present tense. And if the documentation for a computer architecture exists, it should be present tense. If no processors exist, and no documentation exists, it could be less obvious. But best then to just write in terms of an event. The Burroughs B5500 was designed and sold by the Burroughs corporation. That works even if none exist. Gah4 (talk) 02:39, 29 June 2024 (UTC)[reply]
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style&oldid=1231581766"