Wikipedia talk:Manual of Style/Disambiguation pages

Scrap MOS:DABACRO

The whole section is counterproductive to the purpose of a disambiguation page, which is to point people to where they want to go. Just because an acronym isn't used inside of an article doesn't mean it shouldn't go onto a disambiguation page. SW is not mentioned once on the article for Star Wars, and yet SW obviously still has a link to Star Wars because the series is commonly abbreviated that way.

There are cases where it can be hard to fit an acronym into an article, and this rule either forces unnatural edits so that an article can appear at a disambiguation page, or else it prevents the disambiguation page from having the article, even when it obviously should. For example, George W. Bush mentions GWB as a nickname of his, which is technically false; he doesn't go about introducing himself as GWB, it's just a common shortening of his name. The only purpose of that is so that he can appear at GWB; removing this rule could allow for that text to be removed. Canada's ISO 3166-1 alpha-3 country code is CAN, but that information doesn't appear anywhere on the article Canada. It would be extremely difficult to smoothly fit a country's ISO-3166-1 alpha-3 code into its article, especially when the Canada article is very long already (as country articles tend to be). Still, if someone were to wonder what country CAN is at the Olympics, they would want Canada to be at that disambiguation page. And it is at CAN, which is technically against the current rules and yet that is obviously the correct choice.

In general, as far as I've seen, people generally disregard this rule for the most part, because there are many cases in which following it is obviously counterproductive to the purpose of the disambiguation page. Given this, and the fact that whatever (spotty) enforcement still occurs tends to hinder user experience rather than helping it, I think the whole section should go. Ladtrack (talk) 19:34, 20 August 2025 (UTC)

GWB example is a red herring, as there is no expectation that the former president would introduce himself by the nickname. All a nickname signifies is that it is used to refer to the person. I strongly object to removing this section, as it is all too common for new-ish editors (and at least one persistent sock puppet) to slap in entries for whatever random articles happen to start with some initials. IMO, there MUST be some verifiable indications that the subject is in fact commonly referred to by the initialism (i.e., not just a one-time mention in some fan site headline). older ≠ wiser 20:47, 20 August 2025 (UTC)

Canada lists the country's alpha-2 code. Paradoctor (talk) 20:48, 20 August 2025 (UTC)

There was discussion previously about country codes. As I recall, result was to give them a pass for inclusion. The focus of discussion was more on whether the dab should link to the respective ISO list article (or the Olympics' or other authority's list articles) where the code is mentioned or to link directly to the country article. older ≠ wiser 21:22, 20 August 2025 (UTC)

Does any use "SW" without first having mentioned "Star Wars" and expect anyone to know what they're referring to? I think people seeing that sort of convenience abbreviation used for something that has already been identified in full are, if they want to look it up, going to search for the full name. As for GWB, that he doesn't call himself that is beside the point. He's commonly known as that, to the extent that there have been many stands-alone uses of it. Largoplazo (talk) 23:16, 20 August 2025 (UTC)

The idea is that if someone sees "SW" without context and decides to look it up, we can put that in the disambiguation page so they go "oh, Star Wars". That's the benefit of it being in there. That, I would argue, is actually maybe the best reason to be generous with acronyms in disambiguation pages. We want to help out people that stumble into the acronyms SW, or YT, or RBG. None of those articles list that acronym as an alternate name for the subject but obviously they should all be on the disambiguation page. Ladtrack (talk) 04:42, 21 August 2025 (UTC)

The Ruth Bader Ginsburg article does contain several indications of her being known as RBG. I think Largoplaza's point is that it is exceedingly rare for initialisms like SW or YT to be used WIHOUT context in any but the most informal settings (where the usage would likely be clear to the participants in any case). older ≠ wiser 10:50, 21 August 2025 (UTC)

Sure, but these are disambiguation pages. They don't have to adhere to notability standards. The whole purpose of them is to help people find the article they want. Most of the time people that see these acronyms will already know what they mean, but not always, and these type of links clearly do help people find the article they want. Isn't that alone a good enough reason to allow them? Ladtrack (talk) 16:44, 21 August 2025 (UTC)

No, but disambiguation pages should not be presenting material that is unsupported (i.e. unverified) in the linked articles. That is an essential stop gap measure to avoid having to deal with references and citations on the dab (as well as to prevent the addition of spurious content that an editor happens to "know to be true"). That there may be occasional exceptions is not a reason to remove this section. older ≠ wiser 17:17, 21 August 2025 (UTC)

Might we make an exception to MOS:DABONE for generic terms whose similarly-named implementations are an entry in the list?

I recently added Automatic Reference Counting to Arc#Technology. I opted for a concise description, and the result is quite technical-sounding; given this, and given that many people searching for the meaning of "ARC" in a programming context are likely interested in reference counting generically, it would be ideal if both links were present. Although cases like this are quite rare, I wonder if an exception to MOS:DABONE isn't warranted, since I can't think of a better approach at this time. ErrorDestroyer (talk) 20:55, 6 September 2025 (UTC)

Are you saying we should include a link on the arc dab pages because some people might be searching for the term 'arc' but actually want the reference counting article? Or are you suggesting there are other systems that use the term 'arc' that are described at reference counting page? If the latter, the dab should include a separate entry with the link rather than combining it with the entry for Automatic Reference Counting. IF the former, no, I am not persuaded that is very likely. older ≠ wiser 21:14, 6 September 2025 (UTC)

This is called a race condition, right? :P Paradoctor (talk) 21:15, 6 September 2025 (UTC)

The former was true for me; someone used the ARC acronym to refer to reference counting in general, and I wasn't sure what they meant. ErrorDestroyer (talk) 00:25, 7 September 2025 (UTC)

Is there somewhere that describes the difference between automatic reference counting and reference counting at large? If so, add an entry for "automatic reference counting". If not, there is nothing to do. Paradoctor (talk) 21:14, 6 September 2025 (UTC)

If they're interested in a related subject, such as a more general one, the article that matches the dab page should get them there. In this case, the first sentence of the article takes care of that. (For the same reason, I removed the redundant hatnote from the article. It seemed like having a hatnote at the top of Chocolate ice cream reading "For ice cream in general, see Ice cream.") Largoplazo (talk) 22:08, 6 September 2025 (UTC)

Not sure how I feel about your removal of the hatnote, as there are surely programs besides Clang which count references automatically. I found the hatnote to be a helpful clarification. ErrorDestroyer (talk) 00:30, 7 September 2025 (UTC)

I'm a bit slow, but I get there: WP:DABRELATED. Paradoctor (talk) 23:19, 6 September 2025 (UTC)

Ooh, I think that section is poorly worded in its role as a subsection of "What not to include". To align with the purpose of that section and with the way the other subsections are worded, "Include articles only if the term being disambiguated is actually described in the target article" should be replaced by "Do not includes articles if the term being disambiguated is not actually described in the target article." It's meant to exclude redirects that might be permitted under one of the "What to include" criteria. It certainly isn't intended to be understood as "anything mentioned in an article is an appropriate redirect to that article". Largoplazo (talk) 02:32, 7 September 2025 (UTC)

Putting all the other issues aside: what "What to include" criteria? I mean, other than homographs and near misses of such? Paradoctor (talk) 02:49, 7 September 2025 (UTC)

This sounds like the Automatic Reference Counting article shouldn't just be describing the Clang implementation? Should automatic reference counting be re-pointed to the more generic description, and a hatnote placed on top of the former as a start? --Joy (talk) 07:58, 7 September 2025 (UTC)

But that specific implementation is what ARC is; there's apparently much to said about it on its own, enough to fill its own article; and the reader is set straight upon reading the first sentence. What problem are you looking to solve that this doesn't already solve? Largoplazo (talk) 13:07, 7 September 2025 (UTC)

See above - editor ErrorDestroyer reported expecting other readers to be interested not only in this specific meaning, but the more generic meaning as well. We don't want to surprise readers looking up a seemingly generic term but then focusing on a very specific meaning. Setting up hatnotes seems completely sensible in that case. If there's less doubt that the generic-sounding redirect is appropriate, keep it as is, just mark it {{R from ambiguous term}} or similar. --Joy (talk) 13:24, 7 September 2025 (UTC)

I'm puzzled by the greater concern being shown for however many people are mistaken about the level of specificity of the term "Automatic Reference Counting" than for people who actually are looking for information specifically about Automatic Reference Counting and for whom that article is the source of the information they're looking for.

Regarding being interested in the specific topic as well as the more general topic: So, if they're interested in the specific topic, then we need the article about that specific topic, right? Every single article on Wikipedia that's about a subtopic of a larger topic has a link to the article on the larger topic. If someone is interested in the subtopic and, by extension, also the larger topic, and they find the article on the subtopic, a link, generally in the first paragraph, will take them to the larger topic as well. That's the norm. We don't change the subtopic title to redirect to the larger topic title when there's plenty to tell the reader about the subtopic.

Returning to the subject of disambiguation pages, Shepherd (disambiguation) has an entry for German Shepherd; it doesn't have an entry for Working dog or Dog afterwards in case the person looking up German Shepherds is also interested to know more about dogs. The first sentence of German Shepherd has a link to Working dog. I understand that that doesn't cover the problem discussed here, where people think the specific term refers to the higher-level topic—but it still fixes it while providing the reader with a clear yet gentle correct to what they'd previously thought. Largoplazo (talk) 13:53, 7 September 2025 (UTC)

In my mind the difference in capitalization in such a long phrase is pretty significant. If someone is looking up a descriptive phrase, and we know that this description plausibly refers to both a generic and a specific meaning, and we have articles on both, we should add standard (WP:D) navigation elements to help readers.

For example, if we had a article about (generic) shepherding practices in Germany, or if Agriculture in Germany talked at some length about the same, and it was plausible that readers could be looking for this information and not just dog breed information, then the redirect German shepherds would be ambiguous, and we would place a hatnote or disambiguate the redirect. --Joy (talk) 14:14, 7 September 2025 (UTC)

With the current state of the article, the only suggestion of further ambiguity is in the section reference counting § Rust where the types Rc and Arc are mentioned, apparently meaning non-atomic and atomic respectively. The way Automatic Reference Counting is currently written, it appears to be entirely about the usage based on the Clang compiler. If there are other compilers or languages with similar usage, there is nothing I can see in these articles. older ≠ wiser 13:26, 7 September 2025 (UTC)

RE: The newer templatte

Hi, 👋 @Danbloch the reason I think the article and other instance of quoting article content could use a template like this is:

1. For consistency firstly, mostly block indents are implemented using : or blockquote or block indent templates of many kinds
2. Or custom div's are employed with varying styles like just a box, black border, gray border, blue dashed border.... Then some will use a pre or code tag but remove the monospace.... which looks totally off to the visual mimicry, and I honestly would do that and match the style, but I cannot do the background or the interior padding... it's not consistent to the way the actual printed text appears, and that's what we're trying to 'mimic' or convey to the reader that's what they're now looking at. It's one reason we syntax highlight for small snippets even of code.

I'm happy to change the margins (even though they exactly match how .mw-content of article class appears and the .body class), but I think it deserves a bit more padding? And the background being var(--background-base); this also accomodates themes/skins etc. What do you think? waddie96 ★ (talk) 04:17, 15 September 2025 (UTC)

Hi, waddie96. I completely agree that a template would be nice (makes wikitext of articles which use this construct easier to read, and make it easier to create new articles or modify existing ones).

The consistency I was talking about was within MOS:DAB, but that was misleading on my part--if you'd changed all the examples in the article at once instead of just the first section it would be consistent, but I would still have the concerns that I think it's more readable (colors) and looks better (indentation) with the existing display.

If I understand your post correctly, you're saying that it is possible to make the template-generated display similar to the existing display. If you're okay with that then I'm all for it. And I agree about the padding. And to be fair, if you don't want to do make some of these changes I'd probably get used to it.

For people following along at home, in Special:Permalink/1311323420, #Linking to a primary topic uses the template (new style), while the rest of the document, starting with #Introductory line, uses raw HTML (existing style). Danbloch (talk) 05:29, 17 September 2025 (UTC)

Cool I'm actually happy with a background I agree it's needed, I added a more subtle one so it doesn't look like an infobox/sidebar/navbox? Are you okay with that. I also put the margin+padding to be the 3em block quote amount; I do think if it's padding:0 and margin 3em (which is what it is on the old MOS:DAB that we would like to replace, is a bit too indented... It's jarring the jump from normal text to it... Let me know how you like it now, examples can also be seen at Template:Quote article text#Examples. Last question, I made a boolean tq/green/color variable, that some editors like to make the quoted text have {{tq}}, now this sets it green but not the font serif. Should it? Or should I remove the feature and editors should just insert {{tq}} when inserting in the content para,meter. Like:

{{quote article content |{{tq|content}} }}

waddie96 ★ (talk) 07:25, 17 September 2025 (UTC)

I think that's fine. Feel free to put back the change to "#Linking to a primary topic" so I (and others) can see the new version live. I don't have a feel for the usage, but if you think editors will want to use tq formatting, the boolean seems much better than having them use {{tq}} manually. Danbloch (talk) 16:19, 17 September 2025 (UTC)

Ok so instead of doing it on the live page, I did the edits here: User:Waddie96/sandbox/dab. FYI the template almost exactly replicates block quotes (without the border-left of course 😉) but also with the background and border as discussed that dilineates it nicely. I actually like the padding/margins etc that i was initially against. Just took the eye some getting used to. It replicates it so well it 'fits'. Other issue I came across is as a screen reader user myself, this DAB page is a minefield of *(#%*(#@&#*(%#&*(%& unnecessary lists..... think CSS bright web color blue on purple on neon green for your visual interface with courier new mixed with a crayon font, is how this text sounds to the person using a screen reader when semantically relevant HTML elements are used for styling 🙈🙈🙈🙈🙈🙈

Functionally, ARIA roles, states, and properties are analogous to a CSS for assistive technologies. For screen reader users, ARIA controls the rendering of their non-visual experience.

[1]

Sigh. I am willign to fix it, but hesitant if someone comes along and does a sweeping revert... Anyway let me know what you think of the imp[rovements! waddie96 ★ (talk) 17:38, 17 September 2025 (UTC)

Looks good. Thanks! Danbloch (talk) 20:09, 17 September 2025 (UTC)

Should I merge? waddie96 ★ (talk) 22:03, 17 September 2025 (UTC)

• I'll go ahead and merge

waddie96 ★ (talk) 22:03, 17 September 2025 (UTC)

Consensus on seperating capitalization

Is there an accepted consensus on disamb pages per capitalization? I found it quite unhelpful to not see certain acronyms presented, especially given Wiki autohandling of this in the searchbar. Respublik (talk) 04:36, 20 September 2025 (UTC)

Prince Andrew (disambiguation)

There is some discussion at Talk:Prince Andrew (disambiguation)#Primary topic redirect about the best way to present the former prince on the disambiguation page. older ≠ wiser 18:08, 2 November 2025 (UTC)

Question about alphabetising

I thought I had come across a style guide page about this years ago, but cannot track it down. Do we do word-by-word or letter-by-letter alphabetising on DABs? I thought it was word by word, i.e. Skinny Fish would come before Skinnyfish (made up example), but I just came across someone reordering as if the space did not exist. Can anyone point me to a style guide on this, or indicate what is preferred on DAB lists, please? Laterthanyouthink (talk) 22:48, 10 November 2025 (UTC)