Wikipedia talk:Manual of Style/Disambiguation pages

place descriptions

I'm here after trying to verify [1] by @Shhhnotsoloud. I spent a bit of time looking into what those place names refer to and then describing and ordering them by likelihood of being topics of interest, so I'm not exactly thrilled with it being dumped so casually :)

The manual text here does say:

For places, it may only be necessary to write the name of the article.

It may be appropriate to add the country after the link.

This is inexplicably terse in a lot of cases, and inconsistent with the other entries, because WP:D and this page also say it's normal for captions to exist:

Entries are sentence fragments

If an entry link by itself is insufficiently descriptive for navigation, use a sentence fragment

The disambiguated place names themselves may be descriptive enough to people who know exactly what they're looking for, but for anyone else, and/or anyone wading through a drab list, I don't see why we should be removing a handful of words that describe these. Maybe there's ways to make it more natural or concise, but wholesale removal seems excessive to me. Blue links at the start are already fairly distinct for whoever is just looking for a quick parsing of the list.

Likewise, sorting a hamlet before a huge suburb just because it's alphabetically ahead seems really inefficient to me. This is also covered by MOS:DABORDER. (We also don't have a great track record with navigation outcomes with long, alphabetically sorted lists.) --Joy (talk) 17:08, 11 February 2025 (UTC)

I completely agree with Joy, and think the it may only be necessary to write the name of the article should simply be stricken. It's not urgent but every entry, including geographical locations, should have a brief description, even if it is only "a town in Southern New Jersey" or the like. Do not see a reason to suggest excluding more information is good practice. This is especially obvious, at, say, Frankfurt (disambiguation) - simply having "Frankfurt (Oder)" is useless, and "Frankfurt (Oder), Germany" wouldn't be much better. A location in Brandenburg and "on the Polish border" makes clear that this Frankfurt is very far away from Frankfurt-am-Main and a separate entity. SnowFire (talk) 17:26, 11 February 2025 (UTC)

I don't agree (with criticism of the Erskine#Places cleanup). Disambiguation page entries should be as brief as possible: enough to find what you want, but nothing unnecessary, because unnecessary text is clutter and makes what you really want more difficult to find. If an entry is listed under Places that's because it's a place, so "a village" doesn't help. "a village near Stettler" doesn't help either because if you already known it's near Stettler then you'll know it's in Alberta, Canada. And seperating two entries in Australia by two other entries not in Australia is, well, just unhelpful. Of course when I'm editing I don't intend to "casually" discard others' work, or upset them at all, because we're all just editors trying to make the encyclopedia better. Shhhnotsoloud (talk) 11:39, 12 February 2025 (UTC)

None of this is "clutter", though. More information than the "brief as possible" version can and usually are highly useful. We're not talking about an essay here, we're talking about simply what this entity is. "A village" in the blurb can certainly help - what if it's a geographical landmark like a mountain? What if it's a weird census-designated-place? What if there are multiple meanings of the containing geographical entity (e.g. Georgia)? A single, simple word does wonders that a title doesn't, especially for the case where the reader doesn't know the details and a few details will be helpful. Remember that it's equally useful to know that something isn't a match as knowing something is a match, so a little detail aimed at the clueless reader is still helpful. SnowFire (talk) 19:26, 12 February 2025 (UTC)

I think you may be overestimating the average reader's grasp of geography :) A reader might have visited or heard about a place and wants to read about it, but we can't really assume that they are aware of the entire hierarchy of entities related to it, or the specific one we chose for the disambiguation marker.

Giving them a few more hints as to the location seems benign to me and a safe default, because it's still much shorter than e.g. having to click through and read the lead sections of those articles. Indeed even if you have mouseover showing lead sections, reading list captions is still faster, because you don't have to move your hand in a precise manner.

On the matter of sorting, choosing any method will create unhelpful situations. The real question is what is most helpful to the average reader. So, how do they parse such a list? Is 9 entries short enough that they just start reading from start to finish, or is it long enough that they start searching by some parameter? Do they look at the blue links, or do they look at the captions for sorting? I don't know that we have clear answers to these questions, but we should probably look for them. --Joy (talk) 19:27, 13 February 2025 (UTC)

I mostly agree with Joy here. There is no reason to obsessively trim descriptions to the absolute minimum. I think a bit of context can often be helpful. We don't want the descriptions to be mini-essays or to recapitulate the entirety of a stub, but a bit of context beyond the country can be helpful. older ≠ wiser 12:57, 12 February 2025 (UTC)

Erskine, Minnesota, a town in Polk County, in the United States: I doubt a reader would know they are looking for an Erksine in Polk County but not know its in Minnesota. Erskine, Minnesota, U.S. is sufficient. Don't add any more than is necessary for the reader to determine the correct entry that they are looking for.—Bagumba (talk) 14:41, 12 February 2025 (UTC)

What if Erskine wasn't a town? How would you know? Confirming "A town" directly in text means that no thinking is required for taking a guess. (And sure, lots of features have "Lake" or "Mountain" or "National Park" in their name, but not all of them. Quick, what do you think Devil's Kettle, Minnesota refers to, without clicking the link?) SnowFire (talk) 19:47, 12 February 2025 (UTC)

Even in this dab page we have an Erskine Park which isn't a park and a Mount Erskine which isn't a mountain. PamD 21:52, 12 February 2025 (UTC)

As I had stated, Don't add any more than is necessary for the reader to determine the correct entry that they are looking for. I don't think the average reader can distinguish a town from a community, locality, etc., but is there a more generic alternative term? At least we agree that mentioning the county is superfluous there.—Bagumba (talk) 23:40, 12 February 2025 (UTC)

That's what I meant by making it more natural or concise. If the average reader looking for that place doesn't relate it to its county name, that part should be dropped. Dropping the more basic facts is what seems excessive. --Joy (talk) 19:09, 13 February 2025 (UTC)

It should also be noted that the two examples presented in this MoS section are rather contrived.

If Jacksonville (disambiguation)#Places only included those two smaller American cities, that would be fine, but it doesn't - it actually includes two dozen other places, and I don't think anyone can really say that list is easy to figure out for a person who doesn't specifically know which one they're after.

If the Kimberley (disambiguation)#Places and historical events list only included those two similarly-sized towns on different continents, that would likewise be fine, but it doesn't - it also actually includes a couple dozen places, a variety of locations and types

I think the MoS needs to better match what's actually happening out there. --Joy (talk) 18:47, 14 February 2025 (UTC)

In addition, we already see in MOS:DABSHORT:

Keep the description associated with a link to a minimum, just sufficient to allow the reader to find the correct link. In many cases, the title of the article alone will be sufficient and no additional description is necessary. If the type of entry is identified in a header (e.g. songs, films), it usually does not need to be repeated verbatim in the description.

So this section on places is largely redundant with that, too (and those many cases are basically weasel words without much support in practice AFAICT).

Special:WhatLinksHere/MOS:DABPLACES indicates the shortcut was linked from discussions 4 times over a span of 10 years. --Joy (talk) 18:32, 17 February 2025 (UTC)

As there's been no further response here, I've made an edit to the guideline to reflect the findings from this discussion. --Joy (talk) 12:11, 21 February 2025 (UTC)

Parenthetic statement about WP:DABPRIMARY

@Danbloch, I don't understand why you think the original parenthetic statement is "clearer". Current parenthetic statement:

(This is opposite to the guideline for primary topics in articles; that is, MOS:BOLDLINKAVOID does not apply to disambiguation pages.)

Proposed parenthetic statement:

This is opposite to the guideline in MOS:BOLDLINKAVOID which applies to articles, as disambiguation pages are not articles.

Here are the problems I found with the current statement (which is why I edited it):

1. The recommendation is in MOS:BOLDLINKAVOID. That's not clear in the original parenthetic statement
2. The concept of "primary topics" does not exist in articles; it only exists in disambiguation pages
3. Original parenthetic statement does not explain why the recommendation is not applicable to disambiguation pages.

Would appreciate an explanation. Green Montanan (talk) 14:46, 1 August 2025 (UTC)

Most people don't know what MOS:BOLDLINKAVOID is. I don't. I know the guideline, but not the name of the shortcut. So in order to understand the proposed rewording, people would need to click on the link, while with the original they can see "guideline for primary topics in articles", get an approximate understanding, and only click the link if they want more information. The whole parenthetical is just a bonus.

I think your points 1 and 3 are clear in the original. But even if they weren't, people don't need to understand these details to understand the point.

Point 2 is reasonable, but it can be fixed by just removing the word "primary". Dan Bloch (talk) 01:59, 2 August 2025 (UTC)

To make it clear, we should probably remove the three words "primary topics in" and add 6 additional words at the end to read: "(This is opposite to the guideline for primary topics in articles; that is, MOS:BOLDLINKAVOID does not apply to disambiguation pages, which are not considered encyclopedic articles.)" ―Green Montanan (talk) 12:10, 2 August 2025 (UTC)

"considered" is wishy-washy verbiage. Dabs are not articles, period. Paradoctor (talk) 15:53, 2 August 2025 (UTC)

I agree that Dabs are not articles. However, they are in the article namespace. Henceforth, they are not considered articles even though they are in the article namespace. Green Montanan (talk) 15:56, 2 August 2025 (UTC)

Point being that splitting hairs is not helpful there. If you must, link the phrase to the subatomic detail. The message here is: dabs not articles, so different rules apply. Less is more. Paradoctor (talk) 16:05, 2 August 2025 (UTC)

What does "link the phrase to the subatomic detail" mean? ―Green Montanan (talk) 16:09, 2 August 2025 (UTC)

[[some location that explains finer points which only detract from the main point here|''which are not encyclopedic articles'']] Paradoctor (talk) 16:21, 2 August 2025 (UTC)

Sounds reasonable. Since the shortcut WP:DABSNOTARTICLES linked to a discussion that was 18 years old, I replaced that discussion with a short essay. ―Green Montanan (talk) 17:44, 2 August 2025 (UTC)

I'm not sure that sentence serves any good purpose at all. I can think of two possible scenarios:

1. A reader who has no idea that anything is said anywhere in the Manual of Style about links in bolded article titles comes upon this sentence, which doesn't even say in what way what's being said here is "opposite to" (is that British English? it's weird to my American senses) something said somewhere else, leads them to look at that guideline, whereupon they find out it's about something completely different anyway: linking of part of a boldfaced repetition of the title of the article containing the link, whereas this is about linking the entirety of the title of another article. And they say to themselves, "Wow, this is a completely different thing, why did they waste my time sending me here?" Summary: The sentence is cautioning them about this not being a contradiction when they would have had no idea that it might be a contradiction, and it wastes their time.
2. A reader who knows, whether or not they remember where they read it, that there's something somewhere about linking within boldfaced titles, comes here and thinks "Gee, I'd swear that contradicts another guideline somewhere." For that situation, it suffices to assure them that there isn't a contradiction, but to do that it doesn't need to tell them where they read it. Eliminating that from the sentence would streamline the sentence and make the above discussion moot.

To satisfy the needs of the second reader without needlessly obstructing the first, it would suffice to write, "(This supersedes any other guideline regarding the linking of all or part of a bolded article title.)" Or "(While other guidelines address the linking of all or part of a bolded article title, disambiguation pages aren't articles.)" Largoplazo (talk) 02:46, 3 August 2025 (UTC)

I don't think it's necessary to write "any other guideline", given that there is only one guideline: MOS:BOLDLINKAVOID (at least I'm not familiar with any other guideline).

I could support rewriting the parenthetic statement to say "(This supersedes the guideline against adding hyper-links to any boldfaced text in the lead of articles, since disambiguation pages are not encyclopedic articles)" ―Green Montanan (talk) 03:20, 3 August 2025 (UTC)

There's no superseding because the two provisions are about completely different things, as I explained above. Largoplazo (talk) 06:31, 3 August 2025 (UTC)

You're the one who introduced the word "supersedes". Green Montanan (talk) 06:35, 3 August 2025 (UTC)

Well, you're correct that I did. Though, on second reading, the context was different. I had been addressing any vague idea that a user might have that another actually conflicting guideline appeared elsewhere—and maybe there even is one somewhere (since I don't have an eidetic imprint of the entire MOS in my head). In that event, this one would supersede it. By the time we get to your proposed text, we're referring to the one actual, specific provision that all of you are discussing here, not a hypothetical one floating around in the reader's head, and that provision doesn't conflict with the one here. Largoplazo (talk) 14:57, 3 August 2025 (UTC)

"contrasts with"? "hyper-" and "any" should go, the former is understood, the latter doesn't need emphasizing. I prefer "as" in place of "since", as the latter has no temporal connotation. Paradoctor (talk) 07:50, 3 August 2025 (UTC)

Looks like we are converging to rephrase the parenthetic statement as such: "(This is the opposite to the guideline not to add links to boldfaced text in the lead of articles, as disambiguation pages are not encyclopedic articles)". ―Green Montanan (talk) 13:57, 3 August 2025 (UTC)

"opposite of" Paradoctor (talk) 14:37, 3 August 2025 (UTC)

We are not collectively converging there, since that guideline isn't relevant at all. This is no more the opposite of that than it's the opposite of the guideline calling for an article title in the lead sentence to be bolded, or the one calling for not forcing an article title into the lead sentence in the case of a descriptive title, or article alternative titles (such as those from redirects) to be bolded, or other articles to be linked on first reference. This guideline exists. Those guidelines exist. They are generally about titles and boldfacing and linking but this one doesn't supersede or conflict with any of the others and isn't the opposite of them because none of those would come into play here in the first place even if this provision didn't exist. Largoplazo (talk) 15:03, 3 August 2025 (UTC)

I don't understand your reasoning: One guideline says to add links to bold text, another guideline says not to add links to bold text. By definition that means that the two guidelines are opposites. ―Green Montanan (talk) 15:46, 3 August 2025 (UTC)

Linking of different portions of the bolded text in question (full versus partial) for entirely different reasons (the title of the article containing the text versus the title of an article elsewhere) on different kinds of pages (articles versus disambiguation pages). Mutually exclusive circumstances.

An example of where "opposite of" would make sense. "Commonly in Hebrew, the feminine form of a qualifier can be derived from the masculine form by adding the suffix ה. When it comes to numbers greater than 2, the opposite is true." THat is, numbers, when qualifying nouns, are qualifiers, so they're part of the domain covered by the general rule. Therefore, in the absence of the number-specific rule, the general rule would be expected to apply but, because of the existence of the number-specific rule, the opposite is actually the case. In contrast, the discussion we're having here is about two guidelines whose domains are mutually exclusive. WP:BOLDLINKAVOID isn't opposite, it's simply irrelevant, despite having factors in common. If there were a general principal that "no links shall ever appear anywhere in bold text in any page in the article namespace", then the DAB guideline could be said to be the opposite of that—though it would be better to say that it's an exception to it. Largoplazo (talk) 16:13, 3 August 2025 (UTC)

You're splitting hairs. Both are rules about bold links in the first sentence on mainspace pages. One says "hee", the other says "haw". Paradoctor (talk) 17:11, 3 August 2025 (UTC)

Two things that aren't the same can have something in common without being opposites of each other. No one would describe a detective film set in Italy where the production crew were Italians as the "opposite" of another detective film set in Italy but where the production crew were all Americans. You call this splitting hairs; what I want to know is why it's so important to you to use the word "opposite" once it's been pointed out why it's not 100% apt and when no purpose is served by doing so. Largoplazo (talk) 18:00, 3 August 2025 (UTC)

"American" and "Italian" are not opposites. "Avoid bold link" and "ensure bold link" are. What is so hard about that? Paradoctor (talk) 18:06, 3 August 2025 (UTC)

"Avoid linking part of a bold reiteration of the article's title in the lead sentence of an article" and "Do link the entirety of the title of another article in the opening sentence regarding the primary topic of a disambiguation page" are not opposites. These two provisions are not giving contrary instructions about the same thing, they're giving independent instructions about two different things. Of course it looks like "splitting hairs" when you repeatedly discard every aspect of the difference between the two situations that shows that it's more than splitting hairs. Also, what I want to know is why it's so important to you to use the word "opposite" once it's been pointed out why it's not 100% apt and when no purpose is served by doing so. Largoplazo (talk) 18:16, 3 August 2025 (UTC)

not giving contrary instructions about the same thing I should hope so. Take your time. Paradoctor (talk) 18:22, 3 August 2025 (UTC)

I have no idea what you mean by this, and it this point I don't care, particularly since you clearly have no explanation for why you care so strongly about keeping the word even after I've asked you twice. I've said what I have to say and I've expressed it as clearly and precisely as possible. Largoplazo (talk) 18:37, 3 August 2025 (UTC)

You can't really say that WP:BOLDLINKAVOID is irrelevant. It's in the current version of the parenthetic statement. We are not discussing removing the link. We are discussing how to present it.

• @Danbloch suggested to make the link without explicitly naming WP:BOLDLINKAVOID
• @Paradoctor has made other useful suggestions
• Your comments are incoherent, especially once you started to go down the rabbit hole of rules of Hebrew grammar (I have no clue how that relates to the topic of this discussion).

It therefore seems that the consensus wording is "(This is the opposite of the guideline not to add links to boldfaced text in the lead of articles, as disambiguation pages are not encyclopedic articles)". —Green Montanan (talk) 21:13, 3 August 2025 (UTC)

I can say it, I did say it, and I explained several different way at several levels of detail why I consider it irrelevant. So your first sentence is nonsense and pointless. We, including me, are discussing several alternatives and considerations, including the ones I offered. You don't own this discussion and you have no role in choosing who is or isn't a participant in it.

Your failure to distinguish analogies from rabbit holes is disturbing.

Wikipedia has no principle that says "When people begin a discussion about changing the wording of something, responders are forbidden from suggesting yet other alternatives, including the view that an even better solution would be to remove the text altogether." Did you ever notice how in many "Articles for deletion" discussions, multiple participants will recommend "redirect" or "merge and redirect" as an alternative, and the closing administrator, rather than scolding all those people for daring to !vote anything but "keep" or "delete", actually follows their recommendation? Well, it's possible that you haven't noticed—it just occurred to me to check your history here and it's relatively new, so you may not have acquired all the relevant context yet, and you may still have some tuning to do to your understanding of how people collaborate on Wikipedia.) Anyway, your rule is your own invention and inapplicable. Largoplazo (talk) 23:54, 3 August 2025 (UTC)

So far, the consensus is that WP:BOLDLINKAVOID is relevant. You are entitled to your point of view, but it's not the consenus. —Green Montanan (talk) 00:46, 4 August 2025 (UTC)

No other participant in this discussion is advocating for the removal of the parenthetic statement. —Green Montanan (talk) 00:52, 4 August 2025 (UTC)

Only two people besides you and me have participated at all in this discussion re a major guideline page, it's been up for only 24 hours, and you're sitting here declaring consensuses. Largoplazo (talk) 01:16, 4 August 2025 (UTC)

I have qualified my statement of a consensus with the words "so far" or "it seems". —Green Montanan (talk) 01:23, 4 August 2025 (UTC)

Beat me to it. As there are clearly communication issues, taking a break seems sensible. Paradoctor (talk) 01:32, 4 August 2025 (UTC)

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.

[2]

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)