Wikipedia talk:Manual of Style/Disambiguation pages/Archive 43

Archive 40

Archive 41

Archive 42

Archive 43

Archive 44

How to list entries at "surname" page when also have "hndis"?

Charles Best has seven people listed. Should they also be each included in Best (surname), or instead just a single link to the hndis page? If the latter, should it go in the main list (annotated as there being several people of that name) or in the See-also list? DMacks (talk) 04:07, 15 July 2020 (UTC)

I think the reader is better served if they are all listed on the surname page so that a reader looking for a particular "Best" can scan a list rather than having to check umpteen dab pages: they might be following up a mention of "... other early poets such as Best ..." or "... Best's work on insulin ... ". PamD 05:03, 15 July 2020 (UTC)

I agree, as that's best for reader navigation. But what goes on a surname page is best discussed at Wikipedia talk:WikiProject Anthroponymy/Standards, since surname articles aren't disambiguation pages. -- JHunterJ (talk) 11:12, 15 July 2020 (UTC)

Thanks for the pointer. MOS:DABNAME says to see WP:DABNAME, which is a redirect to Wikipedia:Disambiguation#Naming the disambiguation page not somewhere in the Anthroponymy project or specifically relevant page. DMacks (talk) 19:07, 15 July 2020 (UTC)

In this case I think it's fine to list them all. Generally, it depends on how big the page is and how big the selection of ambiguous links are. Compare this to a monster like List of people with surname Smith. BD2412 T 19:26, 15 July 2020 (UTC)

@DMacks: MOS:DABNAME has two links to the Anthroponymy page: one piped to " anthroponymy list article", the other at "their own style standards". Based on your recent experience, perhaps you have ideas on how to (boldly) edit it to make it more obvious for the next person.—Bagumba (talk) 08:46, 16 July 2020 (UTC)

I've been addressing this problem using transclusion, which works in most, but not all cases. The most recent example is at Wade (surname); I've included below some of the wikicode for the transclusion:

*[[April Wade]], American actress and producer
*[[Ben Wade]] (1922–2002), American baseball player<!-- from [[Ben Wade (disambiguation)]] -->
*<!--to edit this, edit the transcluded list-->{{:Ben Wade (disambiguation)}}
*[[Bernie L. Wade]] (born 1963), American minister, President of the International Circle of Faith
*[[Bill Wade]] (born 1930), former American footballer

Looking at the source page for transclusion, you have to place tags in the right place to support it, as shown below for Ben Wade (disambiguation):

'''[[Ben Wade]]''' (1922–2002) was a Major League Baseball baseball player and scout.

'''Ben''' or '''Benjamin Wade''' may refer to:<onlyinclude>
*Ben Wade, character in the film ''[[3:10 to Yuma (1957 film)|3:10 to Yuma]]''
*Ben Wade, character in the film ''[[Key Largo (film)|Key Largo]]''
*[[Ben Wade (politician)]] (1883–1958), Australian politician
*[[Benjamin Wade]] (1800–1878), U.S. lawyer and United States senator
*[[Benjamin Wade (Survivor contestant)|Benjamin Wade (''Survivor'' contestant)]] (born 1971), American reality television personality</onlyinclude>

Note that in this case, you need to manually add the first Ben Wade because it's out of the main list ... that's what I mean by "works in most, but not all, cases". I've not gotten any push back to this approach, nor have I sought input. Having 'exposed' myself here - suggestions are welcome. --User:Ceyockey (talk to me) 03:30, 16 July 2020 (UTC)

As an aside, Byrne is a candidate ripe for a thorough transclusion treatment. --User:Ceyockey (talk to me) 03:42, 16 July 2020 (UTC)

@Ceyockey: That's an interesting technique. It might be useful to annotate the "includeonly" tags with a hidden comment to explain what they are for, or perhaps "see talk page" and a note there, so they don't get "tidied up" and removed by some well-meaning gnome. I think I would probably have removed them myself, so hope I haven't encountered any:apologies if I have. I know now. PamD 04:52, 16 July 2020 (UTC)

Yes, some editors see syntax they dont understand and presume its useless (without asking) and delete them. Just like some will not see (or ignore) hidden comments. The pains of crowd sourcing.—Bagumba (talk) 08:38, 16 July 2020 (UTC)

Thanks for the feedback. "Delete the unknown" is a good thing to try and avoid. I'll think about something that can be used and re-used with a minimum of effort -- something which presents like template:Use DMY dates might be good. --User:Ceyockey (talk to me) 00:16, 17 July 2020 (UTC)

Quite agree in principle about "delete the unknown"... but I stub-sort a lot and come across all sorts of garbage where editors have got in a muddle, pressed wrong keys etc, so I get used to clearing up that sort of stuff. As a simple person-name dab page is (appears to be) so straightforward, with no apparent reason for any complexities, I might in the past have come across these tags and "helpfully" cleaned them up too. ALways helpful to leave an explanation to help future editors. But I'll try to remember this example for the future, when I come across something I don't understand. PamD 09:14, 17 July 2020 (UTC)

I love this approach, but I've avoided it because I thought things outside of the template namespace weren't supposed to be transcluded like that. If that's fair game, game on! And I'll be adding that to my cleanup steps. Now, if only there were a way to make it work with ship SIAs... :-) -- JHunterJ (talk) 11:17, 16 July 2020 (UTC)

For the namelist, I think (in ascending order of preference)

1. Linking to the dab page is the minimum
2. Copying and enumerating all the items is a better experience for the reader
3. Transcluding is the best solution, avoiding multiple copies becoming out of sync.—Bagumba (talk) 08:53, 16 July 2020 (UTC)

In the case of Jiménez (surname), an editor added {{:Julio Jiménez (disambiguation)}} and it resulted in a big "This disambiguation page lists articles about people with the same name...." in the middle of the list. But I don't see the same thing in Wade (surname). Is there a way to avoid this? Leschnei (talk) 11:44, 16 July 2020 (UTC)

Using onlyinclude tags like this. -- JHunterJ (talk) 11:52, 16 July 2020 (UTC)

Ah ha! - I was looking for a difference in the target page not the source page. Thank you! Leschnei (talk) 12:07, 16 July 2020 (UTC)

• Using onlyinclude tags is an easy option, but it can lead to problems whenever someone decides to transclude the page elsewhere: the sections marked up for transclusion onto the dab page may not necessarily be the same ones that might be needed elsewhere. For that reason, I believe it's cleaner if labelled section transclusion is used instead, although it comes at the cost of marginally higher complexity. – Uanfala (talk) 16:41, 21 July 2020 (UTC)
  • @Uanfala: Thanks. I've converted the Ben Wade (disambiguation) into Wade (surname) to this solution type and it's working well. --User:Ceyockey (talk to me) 14:35, 25 July 2020 (UTC)

    When doing this I found the spacing required is a bit different in that a) I needed to add a line between the editor note on the source page and the first line with a section transclude boundary on it and b) I needed to put the section transclude code on the same line as the preceding line in the target page. --User:Ceyockey (talk to me) 14:39, 25 July 2020 (UTC)

Hatnote template and documentation

OK. The templates I wanted to use as examples to start from use Lua modules ... and I've never worked with those. So, I started from scratch and did a crude template to be used as a hatnote. See the very bottom line of my sandbox at User:Ceyockey/sandbox for an instance of the template; the template itself is at User:Ceyockey/sandbox_template_hndisonlyinclude, and you can reach the documentation either from the hatnote itself or from the template page. I would add templatedata before releasing into the wild, but wanted to get this out there for critique while it's fresh in people's minds. I don't make templates very often. Thoughts on whether pages where this transclusion-enabling edit has been done should be auto-categorized to anywhere? If anyone with good template creation skills wants to grind on this, feel free to use my sandbox space -- my thinking would be to have the 'editor-oriented message' only appear when editing the page, but I didn't get an example of that in my looking which didn't include meta-templates and Lua modules. Thanks for taking a look. --User:Ceyockey (talk to me) 01:39, 17 July 2020 (UTC)

I was bold and took the template and documentation into main template space and have used it on Ben Wade (disambiguation). --User:Ceyockey (talk to me) 02:15, 17 July 2020 (UTC)

I've had a go with John Schaeffer (disambiguation), as I was creating it this morning. I added your template, based on looking at the Ben Wade page, but I then removed it. I'm not sure about displaying the message to all readers: we don't usually include a "See also" to the surname page. Can we have it as the sort of message which only shows up when someone goes to edit the page? Readers don't need or want to know. But I like the technique, and it could keep a lot of surname pages more up to date. PamD 09:14, 17 July 2020 (UTC)

• @PamD: I would have liked it to appear only to editors like the use dmy dates message, but couldn't figure it out as it seems to rely on some Lua module witchery that I've not dove into yet. --User:Ceyockey (talk to me) 00:44, 18 July 2020 (UTC)

• Strong agree that this template should only be visible to editors, and then it should be highly visible. I'd suggest making it an Editnotice instead of something visible on the page. —swpb^{T • go beyond • bad idea} 15:49, 21 July 2020 (UTC)
• Ive removed it as it irrelevant to readers.—Bagumba (talk) 16:37, 21 July 2020 (UTC)

@Ceyockey: It looks to me as if there's a very slightly wider linespace after the transcluded section, ie before "Jonathan" in Schaeffer (surname). Am I getting it wrong in one or the other end of this transclusion? Or am I imagining the different line spacing? PamD 09:21, 17 July 2020 (UTC)

• @PamD: I didn't see any larger space by eye, but there are sometimes background things happening that can come out depending on the type of browser, the magnification, the operating system; so I took a look at the html code around the site of transclusion:

<li><a href="/wiki/Jody_Schaeffer" class="mw-redirect" title="Jody Schaeffer">Jody Schaeffer</a>, American cartoonist and co-creator of <i>Megas XLR</i></li>
<li><a href="/wiki/John_Schaeffer" title="John Schaeffer">John Schaeffer</a> (born 1951), American fitness trainer and author</li>
<li class="mw-empty-elt"></li>
<li><a href="/wiki/John_Schaeffer_(art_collector)" title="John Schaeffer (art collector)">John Schaeffer (art collector)</a> (1941–2020), Australian art collector and businessman</li>
<li><a href="/wiki/John_Schaeffer_(environmentalist)" title="John Schaeffer (environmentalist)">John Schaeffer (environmentalist)</a> (born 1949), American solar power advocate</li>
<li><a href="/wiki/John_Nevin_Schaeffer" title="John Nevin Schaeffer">John Nevin Schaeffer</a> (1882–1942), American classicist</li>
<li><a href="/wiki/Jonathan_Schaeffer" title="Jonathan Schaeffer">Jonathan Schaeffer</a>, Canadian computer scientist</li></ul>

Appears there is an extra empty 'li' element inserted at the point of transclusion. There isn't anything in the wikitext which can be altered, but there might be some Lua code that could be used to eliminate the empty 'li' element - again, beyond my knowledge at the moment. --User:Ceyockey (talk to me) 00:50, 18 July 2020 (UTC)

Edward House

Edward House is the name of several people and the name of a building in Pakistan. Should it be sorted as 'House, Edward' or 'Edward House'? Leschnei (talk) 12:18, 14 September 2020 (UTC)

"E" in disambiguations, "H" in human name disambiguations, is how I sort them. Perhaps {{hndis}} should also take the optional parameter as a sortkey only for the human name category too, and leave the pagename as the sortkey for the disambiguations. -- JHunterJ (talk) 12:39, 14 September 2020 (UTC)

Never mind that last part. If they're just hn dabs, they aren't listed in the base dabs list... -- JHunterJ (talk) 12:41, 14 September 2020 (UTC)

The page had simply {{disambiguation}}, I added [[Category:Human name disambiguation pages|House, Edward]]. Is that sufficient? Leschnei (talk) 13:24, 14 September 2020 (UTC)

Yep! (Note that you can now also do {{disambiguation|hn=House, Edward}} for the same result. I got tired of typing out the category name.) -- JHunterJ (talk) 13:29, 14 September 2020 (UTC)

Excellent, I'll keep that in mind. Thanks, Leschnei (talk) 15:33, 14 September 2020 (UTC)

Thanks, @JHunterJ: Looks useful - on the very rare occasions it's relevant. I hope I remember it if I find this situation. PamD 17:27, 14 September 2020 (UTC)

Start each entry with a capital letter

MOS:DABENTRY has a bullet point saying Start each entry with a capital letter. Now that's sensible enough, at the very least because entries usually start with a link to the article, and when an article (or another Wikipedia page) is referred to, it is used with an initial capital (in contrast to uses when it's the topic of the article that's being referred to: then an initial capital is not required).

But what do we do when the entry does not start with an article link? If we followed DABENTRY to the letter, we'd capitalise its first letter. However, dab entries are sentence fragments, not full sentences, and these do not need to use sentence case. MOS:LISTCAPS seems to allow both uses for sentence fragments, but in practice it's not uncommon for dab entries to use lower case when they don't start with an article link. I think this works well for a dab page like German, which in my opinion would look jarring if it were changed to sentence case. Or is there something I'm missing? – Uanfala (talk) 10:21, 15 September 2020 (UTC)

I prefer to keep the blue-linked, red-linked, and unlinked entries consistent, e.g., "German, any of the Germanic languages". -- JHunterJ (talk) 12:00, 15 September 2020 (UTC)

Should life dates use "b."?

Should life dates on disambiguation pages use "b." rather than "born"?

E.g.:

• John Pierce Jones (born 1946), Welsh actor

or

• John Pierce Jones (b. 1946), Welsh actor

We currently spell out the word, but abbreviating it would gain a slight degree of concision. BD2412 T 01:59, 20 September 2020 (UTC)

MOS:DATERANGE suggests use b. only where space is limited e.g. tables and infoboxes; use either born or b. consistently in any given table column.. I'm not sure space is such a constraint on disambiguation pages that two fewer characters would be significant. older ≠ wiser 02:25, 20 September 2020 (UTC)

True. My thinking is that we do seem to try to be more concise in disambiguation pages than in other article spaces. I have also noticed it being used in disambiguation pages from time to time. BD2412 T 02:30, 20 September 2020 (UTC)

I think we should stick with "born": while we aim to be concise we aren't space-limited like the tables and boxes for which that exception is written. And "(born 1952)" is slightly shorter than the "(1917-2014)" format used for other dates in a dab list, so sits happily alongside. And I correct "b." in dab pages. PamD 05:52, 20 September 2020 (UTC)

Continue spelling it out. -- JHunterJ (talk) 13:53, 20 September 2020 (UTC)

I've always wondered why we use born 1940 rather than 1940–. – Uanfala (talk) 13:54, 20 September 2020 (UTC)

Why the dab project does? MOS:TOPRESENT. Why Wikipedia style does? I can't answer that one. -- JHunterJ (talk) 14:03, 20 September 2020 (UTC)

Stage names

I have questioned this edit with the editor who made the change, but we disagree over it. It seems to me that, where a person is known by their stage name (and their article uses that name as its title), the person should be listed on the disambiguation page for names (here), rather than on the "other uses" page (here). We are discussing a single real person, not a band or an organisation, and it seems highly counterintuitive not to include the link to their article on the "names" page. Is there a guideline on this? Ghmyrtle (talk) 08:06, 24 September 2020 (UTC)

• "Monty (singer)" should be listed on the disambiguation page since it's a topic that could have the ambiguous title (as an article title or as a redirect to the article), whether or not they're listed on any Wikipedia list article. -- JHunterJ (talk) 12:15, 24 September 2020 (UTC)

  Agree that it should (at least) be on the dab.—Bagumba (talk) 12:47, 24 September 2020 (UTC)

• The name list page (it's technically not a disambiguation page, but rather a WP:SETINDEX) can be discussed at WT:APO. One could make the argument that the name page should not be the WP:PRIMARYTOPIC,[1], in which case readers would see the singer first on the dab, independent of whether it's also listed on the name page.—Bagumba (talk) 12:47, 24 September 2020 (UTC)

Migration

User:JHunterJ would like to apply his singular vision of what a dab should look like to Migration. I contend that his his proposed version is a disaster of unusability, which counts as WP:PTMs many entries which are not, and leaves a huge, undifferentiated "See also" section where helpful sections were. The page is currently in its status quo form, which I thank JHunterJ for respecting, except for the addition of a cleanup tag. I'd like some folks here to weigh in on whether there is anything wrong with the organization of the page that would warrant the tag, and if there is, let's hash that out here. —swpb^{T • go beyond • bad idea} 18:26, 21 September 2020 (UTC)

Try to present the issue neutrally when raising it. See how I raised it on WT:D instead. -- JHunterJ (talk) 18:50, 21 September 2020 (UTC)

Can't we all just use Talk:Migration? – Uanfala (talk) 21:27, 21 September 2020 (UTC)

Talk:Migration was not likely to attract any users other than myself and J, and we know how we feel. I suppose I could have started there and put a notice here. But either way, I was inclined me to involve other editors as soon as possible, and I'm glad I did – your comments at Talk:Migration#PTMs and your edits to the dab have been immediately helpful. I'll let you or another editor decide when and if the cleanup tag can be removed, but there's no question we're in a better state than where we started – thanks. —swpb^{T • go beyond • bad idea} 13:58, 24 September 2020 (UTC)

Italics for foreign language article names?

Is there a reason that MOS:DABOTHERLANG prohibits italic type for entries with foreign language article names when they do qualify for one per WP:ITALICTITLE? It's not that italics aren't used at all in disambiguation pages, book names and the like are italicised, I guess I wanted to know if there was a reason for the deviation from WP:ITALICTITLE... —I'llbeyourbeach (talk) 12:39, 3 October 2020 (UTC)

Does DABOTHERLANG say that? I don't see anything about italics, there is one example entry with an italic headword that's marked as incorrect, but the point isn't that such an entry should not be in italics, the point is that it should not be included at all. – Uanfala (talk) 20:16, 3 October 2020 (UTC)

I use italics in the disambiguation page entry if the linked article uses italics, and not if it doesn't. And {{lang}} is one of the handful of templates that I believe is acceptable for use on disambiguation pages (which has the effect of italicizing the title). -- JHunterJ (talk) 15:05, 4 October 2020 (UTC)

Thanks, @JHunterJ and @Uanfala, I thought the same but then someone with more experience with DABs said the above and I got insecure. Reckon someone should add italics to the correct example as well to make this less confusing for everyone. —I'llbeyourbeach (talk) 17:14, 5 October 2020 (UTC)

I made the section on italics more generalized.[2] -- JHunterJ (talk) 18:13, 5 October 2020 (UTC)

Ordering of items in See also section

@JHunterJ: (and for info @Uanfala:) You attempted to change the guidelines for the ordering of items in the See also section of disambiguation pages ([3]) because I challenged your reversion of my work at FX2 (see Talk:FX2 (disambiguation)). Your edit has been substantively reverted by Uanfala, and future changes, unless they are minor, will require consensus, as is normal practise. This has been discussed before, at Wikipedia talk:Manual of Style/Disambiguation pages/Archive 42#Canned Search, and ordering in See also sections, not that long ago, although with limited participation, but you'll notice that I publicised my proposed change and asked for opinions first. The sequence of events—I make an edit in accordance with guidelines; you revert it; I challenge the reversion; you change the guidelines to suit your view—doesn't look particularly good, but we're both experienced editors and I will continue to assume good faith on your part. Shhhnotsoloud (talk) 08:00, 27 September 2020 (UTC)

FWIW, it doesn't explicitly say they are listed in order, though it could be implied by the numbering.—Bagumba (talk) 10:52, 27 September 2020 (UTC)

So, these are the recent changes to the guidelines. There are two changes: one is the addition of a text that ordering should be logical. While I didn't oppose it when it was added yesterday, on second thought I realise that it's necessarily at all ("Of course the order will be logical, did anyone think it should be random?"). The second change has to do with replacing sequential numbering with bullet points: I think that's an improvement as it avoid the suggestion that different types of entries should come in a fixed order. We shouldn't be stipulating that – editors obviously disagree on the order, and in my opinion it's better to let people use their judgement in individual circumstances rather than push forward a one-size-fits-all solution. – Uanfala (talk) 12:18, 27 September 2020 (UTC)

And the previously dictated/suggested order is not useful to the casual reader not steeped in Disambiguation Lore; if the See also section is long, how are they supposed to know where to find things in it. If obfuscated ordering is needed, they'll need sub-section headers for readers. I don't know when or how it got put in there, but it doesn't reflect normal practice in disambiguation pages. -- JHunterJ (talk) 14:18, 27 September 2020 (UTC)

Per WP:SEEALSO the SA section should not be long. If it is, the solution is to shorten it. Johnbod (talk) 17:20, 5 October 2020 (UTC)

Per the actual WP:SEEALSO text, should be "limited to a reasonable number", and "Consider using {{Columns-list}} or {{Div col}} if the list is lengthy." -- JHunterJ (talk) 18:16, 5 October 2020 (UTC)

WP:SEEALSO also specifies logical ordering, even though "Of course the order will be logical, did anyone think it should be random?". Specifying ways of logical ordering (alphabetical) is useful to avoid the previous illogical ordering suggestion. -- JHunterJ (talk) 14:20, 27 September 2020 (UTC)

I "attempted" a bold edit to improve the encyclopedia. It "looks" perfectly fine, per WP:BOLD. -- JHunterJ (talk) 14:18, 27 September 2020 (UTC)

No. BOLD covers changes that might be controversial, not ones you already know are controversial because you just tried them on a content page and were rebuffed. You should have started this discussion, not User:Shhhnotsoloud, and you should have waited for its resolution before editing. Your impatient, bullying style helps no one. —swpb^{T • go beyond • bad idea} 18:14, 30 September 2020 (UTC)

Bringing this in line with WP:SEEALSO did not seem controversial. My style is not impatient or bullying, and I did not take Shhhnotsoloud's revert as a rebuff -- that's just your non-collegial mindset showing through. -- JHunterJ (talk) 19:34, 30 September 2020 (UTC)

primary topic and number of blue links

I happened across the page Dying of the Light which has two blue links in the initial primary topic sentence fragment.

To my surprise our MOS is silent on whether this is permissible or not. As far as I could see this was last discussed here: Wikipedia_talk:Manual_of_Style/Disambiguation_pages/Archive_42#Linking_to_a_primary_topic But the poster's concern was waved away. There is no reason to be ambiguous here!

Do we or do we not apply the guidelines for individual entries to the primary topic? Either say explicitly the primary topic is an individual entry in all other aspects than mentioned under MOS:DABPRIMARY... or say explicitly the primary topic does not abide by the restrictions on individual entries.

In order to encourage discussion, I'm boldly assuming that yes, MOS:DABENTRY applies to MOS:DABPRIMARY. If you revert me, be prepared to argue for the opposite. Thanks CapnZapp (talk) 21:55, 6 October 2020 (UTC)

There are some obvious differences (e.g. full sentences vs. sentence fragments, closing punctuation, bolding). Otherwise, I would think that much of the logic for individual entries applies to the primary-topic line, and that that has been taken as obvious enough as not to warrant explicit mentioning. – Uanfala (talk) 23:32, 6 October 2020 (UTC)

I agree. These seem relatively rare, as far as I can tell. (Dying of the Light has no primary topic, by the way, so I've edited it to remove the DABPRIMARY paragraph. As originally written by the page's creator, most entries had 2 or even 3 bluelinks, so I don't think there was any confusion there about DABPRIMARY specifically, just DABENTRY generally.) Station1 (talk) 06:13, 7 October 2020 (UTC)

Station1's version is better. There isn't a primary topic here (if there was then the disambiguation page would be at Dying of the Light (disambiguation). Shhhnotsoloud (talk) 06:58, 7 October 2020 (UTC)

More explaining printing

Example:
In the list of PVR there is: "Proliferative vitreoretinopathy".
The way it is written currently it takes each !! reader some time to find (out) which words correspond to the letters of the abbreviation (of course the first word is not the problematic one).
Therefore I suggest, that, at least in all such cases where two words are printed as one word, they should be written in a way which makes it much more cognizable which words are abbreviated; for example like:
"Proliferative VitreoRetinopathy". (In the actual disambiguation page without the "").
In this case the words which are abbreviated and are somewhat harder to distinguish are begun with a capital letter.

It would be even more explicit and more easy to recognize if each letter of the abbreviation (that is: the first word too) would be written fat in the spelled out subject, that would be, in this case: "Proliferative VitreoRetinopathy" (again, in the actual disambiguation page without the "").
Please ping me. Steue (talk) 03:33, 6 October 2020 (UTC)

@Steue:: The disambiguation page isn't there to inform readers how an acronym is constructed. It is there to get readers looking for Proliferative vitreoretinopathy et al. using the title PVR to the topic they're seeking. As needed, the linked articles can inform the readers how their acronyms are constructed, but MOS:NOBOLD guides against bolding individual letters in the manner you suggest. -- JHunterJ (talk) 11:11, 6 October 2020 (UTC)

I agree with JHunterJ. There is no reason for a disambiguation page entry to supply any information about a topic beyond that needed to accomplish its disambiguation. Largoplazo (talk) 11:49, 6 October 2020 (UTC)

@JHunterJ and Largoplazo:
if all the words in the written out version are separated by spaces I completely agree with you and MOS:NOBOLD and the intelligence of the readers, but in this special case it is different: the "vitreoretinopathy" is written out as one word plus this term is very rare.
And as it is written somewhere in our rules: There may be exceptions.
There is also "Ignore all rules!"
Everything in any wiki is there to help those who seek informations.
I judge texts (and web sites, graphic user interfaces, help texts and handbooks) by the amount of time they take me to find what I'm looking for.
So I still think a bolding of the initials in this single case would help !! some readers and save time of many readers.
I'm thinking especially of those many readers all around the globe whose mother tongue is not English.
I would even go so far to consider the un!wilingness to help those mentioned as a kind of racism.
Please ping me. Steue (talk) 08:39, 9 October 2020 (UTC)

@Steue: I don't see that this is a special case. The page already tells them it's proliferative vitreoretinopathy, which is what they do need to know. If it puzzles them that "PVR" is used as the abbreviation for that rather than just "PV" and they wonder why that is, it's a trivial consideration that I don't see as being urgent enough that it needs to be dealt with instantly.

One might similarly wonder why "pH" stands for a measure of alkalinity or acidity, "XTC" is used casually to refer to the drug MDMA, or "DNA" stands for "deoxyribonucleic acid", but none of the disambiguation pages PH (disambiguation), XTC (disambiguation), nor DNA (disambiguation) satisfies this curiosity. (Actually, even the articles MDMA and DNA implicitly treat the matter as either unimportant or self-evident, as neither of them spells out the letter-by-letter significance of the abbreviations "XTC" and "DNA" either.) Largoplazo (talk) 10:30, 9 October 2020 (UTC)

@Steue:, this isn't a special case. This is exactly the normal case. You can use Talk:Proliferative vitreoretinopathy to make your ignore all rules case for the odd bolding option there. Please don't ping me; I watch this page. -- JHunterJ (talk) 11:28, 9 October 2020 (UTC)

Most abbreviations which I have seen are comprised of separate words: one word for one letter of the abbreviation.

The "vitreoretinopathy" is written out as ONE word, that is, what makes this a special case.

And this place here is the right place, because my suggestion, as I intended it, only concerns this disambiguation page.

My suggestion may or may not be mentioned on the article "Proliferative vitreoretinopathy"

Please ping me. Steue (talk) 20:11, 9 October 2020 (UTC)

@Steue: I assure you that I understand perfectly well, and I gather that JHunter does as well, what your point is about the peculiarity of this abbreviation—so much so that I addressed it specifically the last time I wrote, and gave other comparable examples. So your latest comments merely repeat remarks that you'd already made and to which I've already responded. Largoplazo (talk) 20:23, 9 October 2020 (UTC)

@Steue:, I agree with JHunterJ and Largoplazo. A reader arriving at a disambiguation page is not looking for why an entry appears on the page -- they are looking to navigate to the correct article. older ≠ wiser 20:17, 9 October 2020 (UTC)

This is not important enough that I spend more of my time on it.

Steue (talk) 21:10, 9 October 2020 (UTC)

Split history pages as DAB

How do we deal with history of ZZZ pages where they have been split into separate articles for different eras of history. eg I've just created History of the Royal Navy as a dab page where the history has been split into History of the Royal Navy (before 1707) and History of the Royal Navy (after 1707). I tried to look to some of the Premier League football club articles for guidance (including a page I created long ago) but cannot find any consistency. History of Aston Villa F.C. was like this but I've removed the massive amount of text to turn it into the base links only. History of Manchester United F.C. and History of Arsenal F.C. lists the articles whereas History of Liverpool F.C. has summaries.

So my questions: do we have a guideline for this kind of article? Are they even dab pages? Should anyone care? Woody (talk) 15:06, 19 October 2020 (UTC)

IMO, they are not disambiguation pages. A disambiguation page is used when there are several different topics with the same (or very similar) names. In this case, we have only one topic that has been divided into subparts for convenience. The overall topic article that is an index of the subtopics is, unsurprisingly, a set index article. --R'n'B (call me Russ) 18:58, 19 October 2020 (UTC)

See, for example, Bolivia national football team results. And in this particular case, redirecting History of the Royal Navy to Royal Navy#History would serve the purpose without a SIA (like List of Arjuna Award recipients redirects to Arjuna Award). -- JHunterJ (talk) 19:32, 19 October 2020 (UTC)

Thanks for the responses. I think linking it to Royal Navy#History is the easiest and cleanest solution. It doesn't help with some of the football articles but I think SIA is more accurate as R'n'B says. Woody (talk) 20:07, 19 October 2020 (UTC)

Disambigs for RDB and RDA

Could someone more experienced with the practices than me comment if creating disambiguation for the above two to Construction_of_electronic_cigarettes#Rebuildable_atomizers is reasonable? Current discussion on my page why I believe they shouldn't be. User_talk:Graywalls#RDA_and_RDB Graywalls (talk) 21:25, 22 October 2020 (UTC)

MOS:DABRED

There is a discussion at Talk:Penpol#Edit revert about if a red link can be used on a DAB page if the blue link supplied mentions it and there is a mainspace link from a different article but not the blue linked article. I think this is OK since the red link in another article makes the red entry acceptable and the mention in the blue linked article satisfies the 2nd part. The blue link could alternatively be changed to List of United Kingdom locations: Pe-Pen#Peno-Pens but the current blue link seems more sensible since its about a place that the red link contains. Also by red linking it ensures people follow MOS:RDR rather than bypassing it. @Shhhnotsoloud:. Crouch, Swale (talk) 17:33, 10 November 2020 (UTC)

Corner case, but yeah, that tracks. If I came across the situation in the wild while cleaning a page, I'd probably swap it to link to the article that uses the red link. It couldn't hurt to add the red link to the mentioning blue-linked article, though. -- JHunterJ (talk) 18:18, 10 November 2020 (UTC)

Is there a good alternative to a double parantheses?

In Daily Star, the See also section lists the DAB page Star (newspaper). I changed the title to Star (newspaper) (disambiguation) which works but the double parantheses look silly. I have run across this situation several times, so I'm wondering if there is a better solution. Leschnei (talk) 13:33, 15 November 2020 (UTC)

Use piping to remove the "(disambiguation)"? Or maybe say, either in the piped text or in the description, that the link is for a list of newspapers named "Star"? – Uanfala (talk) 17:34, 15 November 2020 (UTC)

Thanks, I did as you suggested. I was trying to think of a solution that didn't involve piping, maybe a new redirect like Star newspaper (disambiguation), but that didn't seem good either. Leschnei (talk) 22:36, 15 November 2020 (UTC)

The double paren titles usually indicate a set index article or an incomplete disambiguation. In this case, I'd move it to List of newspapers named Star (naming conventions for lists, including set index articles) and remove the disambiguation tags and redirects. Alternatively, it could be merged into Star (disambiguation) as an {{R from incomplete disambiguation}}. -- JHunterJ (talk) 12:16, 16 November 2020 (UTC)

Star (disambiguation) is already pretty long, but I like the idea of a set index article. Looking at other common newspaper names:

- The Tribune and Sentinel (newspaper) are set indexes (indices?).

- The Journal and The Times (disambiguation) contain non-newspaper entries and are DAB pages.

On closer inspection, it appears that Star (newspaper) had both {{DAB}} and {{SIA}}; I've removed the DAB template. Leschnei (talk)

And fixed links going to Star (newspaper) (disambiguation). Leschnei (talk) 00:46, 17 November 2020 (UTC)

Listing people on disambiguation pages

MOS:DABNAME says:

For short lists of name holders, sections such as People with the surname Xxxx or People with the given name Xxxx can be added below the main disambiguation list.

Interpreting this guideline has led @JHunterJ:, on a number of occasions, to reformat what I regard as perfectly acceptable versions of disambiguation pages such as this version of Lalitha to versions like this. It is frustrating to have one's work tampered with solely because of a slightly different interpretation of guidelines, but that's not my point—others might think sometimes I do that ;-)—actually my point is that the guidance here is horrible: it results in miscellaneous entries dangling at the top not under a header, and superfluous wording in the one remaining header.

Would editors please support changing the guideline to:

For short lists of name holders, a list can be included in a People section of the page.

Shhhnotsoloud (talk) 10:02, 20 December 2020 (UTC)

• Yes. Although in the case of Lolita, the names could easily be split from the dab. The name may even be primary topic. older ≠ wiser 11:42, 20 December 2020 (UTC)
• I didn't "interpret" it that way; that was the wording that resulted from the consensus discussion. As partial title matches, they shouldn't be on the disambiguation page at all. The previous compromise was reached to keep from having to create small name-holder list articles. The acceptable alternatives would be to place them in See also or just go ahead and create the name-holder list article. Or leave them in the section below the actually ambiguous topics. -- JHunterJ (talk) 12:29, 20 December 2020 (UTC)

  And to Bkonrad's point, if properly creating the anthroponymy article, yes, it might involve moving the disambiguation page to the (disambiguation) title and creating the article at the base name. -- JHunterJ (talk) 14:24, 20 December 2020 (UTC)

• Why not mention both options? I think both can work, depending on the context. But otherwise, yes: I don't think it's productive to switch between the two format just for the case of switching. If the guidelines say that something can be done, this does not necessarily mean that it must be done. – Uanfala (talk) 23:28, 20 December 2020 (UTC)
  It is frustrating to have one's work tampered with solely because of a slightly different interpretation of guidelines, but that's not my point—others might think sometimes I do that ;-) Hear, hear! :) Though I'm part of the same camp too. I think one easy change that could help a little with creating a better environment would be to ditch the possibly deeply entrenched habit of using summaries referring to "cleanup" or "repair" (unless there actually was something messed up or broken ), and instead go for more informative descriptions (like "rearrange entries" or "alphabetise"). – Uanfala (talk) 23:37, 20 December 2020 (UTC)
  • Thanks @Uanfala: On the other option: yes, you're right, I had only intended replacing the text I quoted at the top with the new text. The full guidance would read (omitting the bit in brackets):

    There are two options for listing name holders. For short lists of name holders, a list can be included in a People section of the page. For longer lists, and as an alternative for a short list, create an anthroponymy list article and link to it from the disambiguation page. If it isn't clear that the article includes a list, consider mentioning that in the description. For example:... Shhhnotsoloud (talk) 10:50, 21 December 2020 (UTC)

  • The two options are already mentioned: "There are two options for listing name holders (people whom the encyclopedia reader wouldn't expect to find under the single-name title). For short lists of name holders, sections such as People with the surname Xxxx or People with the given name Xxxx can be added below the main disambiguation list. For longer lists, and as an alternative for a short list, create an anthroponymy list article and link to it from the disambiguation page." You're right, that you "can" put it in a section below the main disambiguation page doesn't mean you "must" -- in this case you could instead create the anthroponymy list article. As far as the rah-rahing about the frustration of "one's work tampered with", reread the last bullet of WP:OWNBEHAVIOR and note that the subsequent editing (not "tampering") was done to improve the encyclopedia because the previous work was due to an apparent ignorance or misunderstanding of the guidelines, not because of a difference in interpretation. Misinterpreting them is not the same as a difference in interpretation. -- JHunterJ (talk) 13:27, 21 December 2020 (UTC)
    • Sorry, the two options I was referring to were: 1) listing people in the "People" section of the main part of the dab [page; 2) listing them in "People named.." right at the end. These were the two approaches in the versions of Lalitha quoted above, right? And as for the other thread, well, JHunterJ, if you frequently find yourself believing that other, experienced, editors are afflicted with ignorance and misunderstanding of the guidelines, then, of course, it's still possible that you're right and everybody else is just plain wrong, but it's much more likely that your approach is the odd one out. – Uanfala (talk) 14:58, 21 December 2020 (UTC)
      • If you believe that you're incapable of misinterpreting a guideline, you're likely incorrect. In this case, for example, the guidelines say one thing, and the suggestion from Shhhnotsoloud is to change it to say a different thing. Thinking that the current version says the same thing as the suggested version is just plain wrong, even if an experienced editor happened to miss that the first time around. I have also misinterpreted guidelines before, but I didn't blame the editors who point that out to me, nor accuse them of tampering with my work. Improving other editors' contributions is Wikipedia, and treating that in the adversarial way you're choosing to is a problematic approach. -- JHunterJ (talk) 15:08, 21 December 2020 (UTC)
        • Has anyone been misunderstanding the dab guidelines here? I think you might find it easier to see the point I was trying to make if you first consider WP:GUIDES and WP:ADHERENCE, which are, by the way, among the fundamental policies. Even the perfect guidelines will have exceptions, and their application should be carried out with common sense. And the fact that we're even debating changing these particular guidelines is an indication that they may in fact be far from perfect. So, my original points was: if a given editor makes an edit to a dab page that seems to break one or another of the rules, it may be that they're not a completely ignorant fool, but may actually be making an informed judgement that the page will better serve its purpose if a particular rule is disregarded. – Uanfala (talk) 18:18, 23 December 2020 (UTC)
• There probably should be a bright[er] line here as to when to include a short list of notable people with the name on the dab page versus when to split them off to a separate WP:ANTHROPONYMY page; leaving things like this open to editorial discretion leads to arguments like this one. I suggest that limit is 2 basically following WP:TWODABS: 2 people is an entry on the dab page, 3 people is a hatnote (not a see also) leading to a separate anthro page. And as JHunterJ said, partial title matches should not be included on dab pages at all; looking at the Taylor dab page, Taylor (surname) is a valid entry, Elizabeth Taylor is not. Ivanvector (^Talk/_Edits) 15:15, 21 December 2020 (UTC)
  • That's a different issue – the disagreement here was to do with where exactly the list should appear within the dab page if it's not split out. Otherwise, I think 3 entries is way too low a bar – if followed, this would lead to a proliferation of teeny tiny pages that will be more of an impediment to navigation than anything else. Personally, I don't see any point in splitting out into a new page unless either substantial encyclopedic content about the name is going to be given, or the list is already so big that it's making the dab page unwieldy. – Uanfala (talk) 15:26, 21 December 2020 (UTC)
    • Short lists of encyclopedic topics (which anthroponymy lists have been determined to be) are not impediments to navigation. If you object to the existence of short anthroponymy list articles, WT:ANTHROPONYMY would be the place to change that approach. If lists of name holders are pointless, they'd also be pointless on disambiguation pages; and if they're not pointless, then a list article is appropriate. Wedging partial title matches into a list of ambiguous topics is not appropriate, though. -- JHunterJ (talk) 15:56, 21 December 2020 (UTC)
  • @Ivanvector: I agree that there might be a debate about what "short list" means, but for now, if you'll forgive me for trying to steer us down only one track, do you support changing the guidance in the way I suggest? Shhhnotsoloud (talk) 09:26, 23 December 2020 (UTC)

    I don't think this is really off-topic to your question. Lists of people with the surname/given name are partial title matches and shouldn't be included in dabs at all - all that should be included is a wikilink to an anthro page that lists them. It would be better if the guidance to list people on dab pages was simply removed. Using the Lalita example, if someone goes by the mononym Lalita then they should be included in a "People" section, but all other people with Lalita as part of their name should be listed on an anthro page, and all that should be included on the dab is a link to it. Taylor#People is how it should be done, and neither the current guidance nor your proposed change describes that. Ivanvector (^Talk/_Edits) 13:56, 23 December 2020 (UTC)

• I disagree. The reader does not care whether the page they are looking at is a dab page or a surname page: they want to find their chosen topic. Surname entries for people are important, as many readers will have a reference to "Bloggs's work on the subject" or similar, and want to find a person by their surname. If that surname has perhaps 2 meanings, with articles, as a common noun and is the surname of 3 notable people, a dab page including those 5 entries is best for the reader, even if 3 of them are PTMs. It is less helpful if they find a page with 2 entries plus a link to follow to a surname page with 3 entries. If the surname list goes above ... well I'd think perhaps a dozen entries ... or if there is sourced encyclopedic content about the surname itself, then we need a surname page, linked from the dab page. For smaller numbers, help the reader by minimising their clicks. PamD 17:36, 23 December 2020 (UTC)

• So, to compromise:

There are two options for listing name holders. For short lists of name holders (about 12 entries), a list can be included in a People section of the page. For longer lists, and as an alternative for a short list, create an anthroponymy list article and link to it from the disambiguation page. If it isn't clear that the article includes a list, consider mentioning that in the description. Shhhnotsoloud (talk) 08:53, 24 December 2020 (UTC)

Or rather than "included in a People section of the page" say "included in a section of the page with the heading People with the name, after other sections but before "See also" ". As at present, to my understanding. PamD 11:16, 24 December 2020 (UTC)

Hello @PamD: but the section should be included in accordance with WP:LONGDAB, ie alphabetically, unless f course there's a good reason for putting it somewhere else. Shhhnotsoloud (talk) 09:00, 31 December 2020 (UTC)

@Shhhnotsoloud: There is a good reason: surname matches are a special case of WP:PTM, not quite standard dab page entries. PamD 09:45, 31 December 2020 (UTC)

Almost everybody above (edit: PamD is a notable exception) appears to have completely overlooked and/or ignored the primary purpose of a disambiguation page: to help readers find the the content they are looking for. To this end it is very significantly preferable for disambiguation pages to contain lists of people with a that name, especially as anybody could be referred to mononymously in any given context. Only if there are multiple pages (more than 30-40 entires) worth of people with the same name should they be relegated to a separate page that someone will have to read, and even then the most prominent people should be listed on the main page and we must be making no requirement for people to know whether the person they've seen referred to in that matter has that name as a first name, surname, nickname, only name, or some other name that does not fit neatly into Anglocentric naming conventions. It matters less where on the page the "people with this name" section is (as long as it is logically placed in the context of other entries) but they should be on the page wherever possible as this is very significantly more helpful for readers. If this is contrary to any guidlines that exist for formatting disambiguation pages then the guidelines need to be changed as they are making the encyclopaedia less accessible. Thryduulf (talk) 16:08, 24 December 2020 (UTC)

• So to split the difference:

There are two options for listing name holders. A list of name-holders can be included in a People section of the page. For longer lists (of 20 or more entries), and as an alternative for a short list, an anthroponymy list article can be created and linked from the disambiguation page. If it isn't clear that the article includes a list, consider mentioning that in the description. Shhhnotsoloud (talk) 09:08, 31 December 2020 (UTC)

I would set that threshold way lower than 20. Maybe 12. BD2412 T 19:07, 31 December 2020 (UTC)

Thank you everyone: I made the change. Shhhnotsoloud (talk) 13:28, 6 January 2021 (UTC)

Sorting for Li Ang

Li Ang includes one given name, one entry that states that Li is the family name, and one entry that doesn't mention give any indication of family name. I'm not sure how to phrase the sorting for the DAB page - it is currently tagged with {{tl:hndis}}. Would {{tl:disambiguation|given name|hn=Li, Ang}} be appropriate? Leschnei (talk) 14:43, 11 February 2021 (UTC)

@Leschnei: I don't think "Li Ang" is a "given name" in the usual senses here. Shhhnotsoloud (talk) 10:14, 13 February 2021 (UTC)

@Shhhnotsoloud: OK, so I'll leave it as {{tl:hndis}} - thanks. Leschnei (talk) 12:46, 13 February 2021 (UTC)

Category link as a See also entry

Is it acceptable to add a link to a category (*[[:Category:Foo]]) as a See also entry? I didn't find anything clear cut in the MOS or the talk archives.

I just did this at Noah's Ark (disambiguation) to remove movies named Noah and Evan Almighty which obviously are not (full) title matches, but I can understand that they are so closely related to the topic that there is an argument to include them somehow. Is this a slippery slope to invite all kinds of navigation-impeding "related concept" links? Personally, I think it's a good compromise to have a single link to cover all these borderline cases.

Another example is Santa Claus (disambiguation): I can understand that a user may be looking for "that Santa Claus movie", not realizing it was called Miracle on 34th Street. Statue of Liberty (disambiguation) is lucky enough to have a Statue of Liberty in popular culture article, should we hold this as a standard for including a "broad category type link"? Hoof Hearted (talk) 21:23, 18 February 2021 (UTC)

The example in MOS:DABGROUPING

The section in MOS:DABGROUPING currently gives the following as an example of a grouping of dab entries:

Thingamajig may refer to:

Science

• Thingamajig (biology), an invasive plant used as ground cover
• Thingamajig (chemistry), an isotope of chlorine
• Thingamajig (physics), a kind of pulsar

World music

• Thingamajig (Peru), a wind instrument similar to an aulos
• Thingamajig (Qatar), a seven-stringed musical instrument
• Thingamajig (UK), a wind instrument, similar to, but longer than the Peruvian one

Now, do we actually need such an example dab page within the guidelines? If we do, then the example needs to change, as there are several things that are wrong with the current one. "World music" is a category you can expect to see in a western music store, not in an encyclopedia. The titles in the "Science" section don't follow the usual conventions: plant titles will be disambiguated with "plant" and not "biology", isotopes – with "isotope" and not "chemistry" (?!), types of pulsars – with "pulsar" and not "physics". Descriptions are also expected to be brief: for example, "wind instrument" is enough, and the fact that it's similar to an aulos is a piece of extraneous detail (and what's an aulos anyway?); "stringed musical instrument" is likewise sufficient, no need to include the number of strings. – Uanfala (talk) 20:45, 2 February 2021 (UTC)

I'd support those changes. —swpb^{T • go beyond • bad idea} 16:57, 3 February 2021 (UTC)

I would also support those changes, but also support deleting the example all together. Shhhnotsoloud (talk) 09:26, 5 February 2021 (UTC)

It's just an example, so I'd say go ahead and be bold (though I understand that guideline changes are too often blindly reverted due to lack of prior discussion).—Bagumba (talk) 10:04, 5 February 2021 (UTC)

Well, my main quesion was whether having those examples was necessary in the first place. I wouldn't want to spend time improving something that will ultimately be thrown out. The fact that such obvious improvements need to be made may indicate that this example has probably not seen a lot of eyes over the years. – Uanfala (talk) 21:58, 25 February 2021 (UTC)

BBC (sexual slang)

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Talk:BBC (disambiguation)#BBC as a porn/sexual term – apparently the entry to for the sexual term keeps getting censored off the disambiguation page, despite there being an ideal article section to point to.  — SMcCandlish ☏ ¢ 😼  19:29, 14 April 2021 (UTC)

Better acronym DAB example

Can we have a better example than TLA at MOS:DABACRO? Although I do understand the cleverness of using an example of pages named acronyms to demonstrate a MOS about acronyms. At the time it was added by Widefox in 2019, Acronym, the target of the Two-letter acronym redirect, did have a mention of "Two-letter acronym" on the page, and not as an acronym.

Today, Acronym does not even have a mention of "Two-letter acronym", and we may be complicating what should be a simple example, by bringing in redirects and targets to explain it. This will be confusing to someone when all we are trying to demonstrate is that a page that does not refer to it's subject using the acronym, should not be in the acronym's DAB entry. - Jay ^Talk 22:21, 7 June 2021 (UTC)

Sure, no problem to use a different example as I agree that the current self-referential one makes it less clear. It was just the first thing that came to mind to replace the previous example The British Soap Awards (incorrect) which went stale - it's nowadays a correct entry as the initialism is in that article. Mind you, the current example is currently a different (and quite common) class of valid redirects that remain invalid dab entries but also remain valid redirects despite having no mention in the article, but that's irrelevant for a simple example. Widefox; talk 20:57, 9 June 2021 (UTC)

People with the name

The recent update to MOS:DABNAME clarified that people with the name can be listed either in the main "People" section or in a separate "People with the name" section right at the end. This addressed cases where each person may not necessarily be known mononymously, and is explicitly an alternative to having a separate name index. However, the way the text is currently worded, an editor can easily arrive at the implication that the two means for listing people are available only for people that are commonly known under just this name, while people who only have it as, for example, a surname, should never be listed on the dab page. We need to clarify that. Thoughts anyone? – Uanfala (talk) 15:51, 26 June 2021 (UTC)

Former names

In the case of a thing that has changed its name from Old Name to New Name (and Old Name redirects to New Name), what should the entry for Old Name look like on disambiguation pages? I think the options would be...

1. Old Name [redirect], former name of New Name
2. Old Name, former name of New Name [link]
3. New Name [link], formerly called Old Name
4. New Name, formerly called Old Name [redirect]

Example 1: The New York Post, formerly called the New York Evening Post. The options for the entry on the Evening Post disambiguation page would be...

1. New York Evening Post, former name of the New York Post
2. New York Evening Post, former name of the New York Post
3. New York Post, formerly called the New York Evening Post
4. New York Post, formerly called the New York Evening Post

Example 2: Trinity University of Asia, formerly called Trinity College of Quezon City. The options for the entry on the Trinity College disambiguation page would be...

1. Trinity College of Quezon City, former name of Trinity University of Asia
2. Trinity College of Quezon City, former name of Trinity University of Asia
3. Trinity University of Asia, formerly called Trinity College of Quezon City
4. Trinity University of Asia, formerly called Trinity College of Quezon City

Option 1 follows the guidance for an "alternative name" under the MOS:DABREDIR section (i.e. on the James Carey disambiguation page, the link should be from James Carey not Jim Carey). A former name often an alternative name, and both above examples have the former name in boldface in the lead. However, if the old name isn't used outside of historical contexts then the guidance wouldn't really apply.

Option 2 follows the guidance in the MOS:DABMENTION for mentions of topics in other articles, and it would be fair to assume that the article would mention the name change. However, it's not really a separate topic mentioned within another article – it's the same topic. Both the above examples use this format, and it seems to be the most common in the wild.

Option 3 follows the guidance if New Name is a variation on or expansion of Old Name – but that isn't always the case.

Option 4 doesn't follow any guidance and doesn't have much to recommend it, but I include it for completeness.

Is there a right answer under current guidance? Apologies if this is actually obvious but has gone over my head. If it's not clear-cut, I think it'd be a good idea to clarify what to do in this circumstance: either to say there's no rule and it's context-dependent, or pick one of the above options. Charlie A. (talk) 14:13, 8 July 2021 (UTC)

Edited for clarity and to include real-world examples. Charlie A. (talk) 13:31, 13 August 2021 (UTC)

The general answer is Option 1: Use the link that matches the ambiguous term, and put the link first in the entry. You will, of course, run into more complicated situations—exceptions, and exceptions to the exceptions, etc.—but Option 1 will do for most uses. —ShelfSkewed Talk 16:27, 13 August 2021 (UTC)

Russia (disambiguation)

Hi!

I run into issue with user @Clarityfiend:. The problem is that:

a) He literally rejects sources that prove that prove that some particular state or region was called Russia, but the Russia that is now known as Russian Federation.

b) He does no research before making edits. So far he provided zero sources to confirm his point. All edits are based on his personal opinion.

c) Instead of checking provided sources and starting discussion when I undid his first removal, he did it again. And now instead of coming up with any proof and reverting page to original state, I quote "ask for others' opinions at Wikipedia talk:Manual of Style/Disambiguation pages if you want to waste your time. I will not respond any further here, only there.".

He claims that his edits are based on Wikipedia:Disambiguation#Partial_title_matches. But unlike "Zoo example" given there, there isn't that many countries/regions that share the same name. And it is standard practice on Wikipedia for countries/regions with dualistic names like Austria-Hungary to be included on both Austria (disambiguation) and Hungary (disambiguation). As well as countries/places previously known under one common name and nowadays under different one to still be there like Byzantine and Western Roman Empire on Roman Empire (disambiguation), Taiwan on China (disambiguation) or Dacia and Principality of Theodoro known in some prior period of time as Gothia on a Gothia page.

Sorry that some of the sources are a bit dated. It's hard to look for them past such amount of sources about modern state called Russia, as well as I don't have as much time and I don't have access to any paid electronic library. And I tried to use English sources only.

Also I had to filter out everything but "Russia" as user Clarityfiend did not accept any other variations like Old/Western/Little/Red Russia used to distinguish between Russias as well as it's synonyms Ruthenia and Rus'. I can only presume that Holy Roman Empire and Eastern Roman Empire won't match his requirements to remain on Roman Empire (disambiguation) page, and they will be next on his removal list.

Kievan Russia

Source:

Baptism of Russia in 988

Source:

Rurik founded the monarchy in Russia

Literally any search for well-known name/date from that time (Iziaslav, pechenegs, Liubech) + Russia

Kingdom of Russia

Source:

the Great duchy of Halicz or Galizia, or Russia, as it was called since 1153

Source:

pronounced Daniel to be the King of Russia

Source:

In 1339 the Lithuanians seized on Russia and Casimire seized on Leopolis

Source:

All Polish and Hungarian chronicles agree that Russia or Ruthenia lay to the north of Hungary which it was separated by the Carpathian mountains. The name Galitza was well known [...] It became gradually of more general application, and was in time confounded with Russia.

Later became a province of Poland called Russian Voivodeship or just Russia. Sources: 1, 2, 3

The easiest way to look it up is under "Regnum Russiae", but most sources will be in Latin or Russian/Ukrainian.

Lithuania-Russia

Source:

In the sixteenth century European writers distinguished between Muscovy and Russia often using "Russia" to mean the Ukraine or Lithuania and regarding Muscovy as a country located east of Russia.

In English it can go by as Lithuania-Russia 1 2, Lithuanian-Russian State 1, 2, Grand Duchy of Lithuania, Russia, Zhmudz etc. Korwinski (talk) 00:17, 1 September 2021 (UTC)

Proposal: change "born" and "died" in lifespans to "b." and "d."

I propose that rather than saying of a disambiguation page subject, e.g., (born 1950) or (died 1802) we should say (b. 1950) or (d. 1802). The abbreviations are commonly known and usage would comport with the desire the disambiguation page lines be brief. It would save two characters per applicable name. BD2412 T 05:22, 2 September 2021 (UTC)

MOS:DATERANGE says to use b. and d. "only where space is limited". I'm not sure if space is limited on a dab, as the descriptions should already be concise. However, it's one of those things that I personally don't change the style if one is already clearly established on the page.—Bagumba (talk) 05:52, 2 September 2021 (UTC)

I don't think saving 2 characters is important, and would prefer dab pages to continue to use the full words, as for leads of bio articles. PamD 05:59, 2 September 2021 (UTC)

In the interest of brevity I think we should dispense with dates of birth and death on disambiguation pages nearly altogether. The purpose of the brief description is to assist in the disambiguation (even if it's redundant to the disambiguator in the article title). If one Susan Smith is Susan Smith (archeologist), a Canadian archeologist and another is Susan Smith (chef), an Australian chef, then disambiguation has been accomplished. Anything beyond that, whether it's their dates of birth or death or their places of birth or the color of their hair, is superfluous to the purpose of the disambiguation page. For that reason, it's mystified me that people add them, in some cases by mass addition on disambiguation pages that didn't already have them. The only circumstance where it might make sense is in the case of two people with the same profession, where even the title carries the vital statistics as an additional disambiguation: Susan Smith (Australian chef, born 1938) and Susan Smith (Australian chef, born 1973).

One can reasonably argue that even the national designations are redundant, unless, say, we have an Australian chef and an Irish chef. At least, though, readers are more likely already to know the nationality of the sought subject, which might make it helpful for distinguishing the sought subject from one of the alternatives. In contrast, how often does a reader searching for information on a person know up front when that person was born? Largoplazo (talk) 11:42, 2 September 2021 (UTC)

Sometimes I've looked up a name mentioned from somewhere with no other context given, but I can infer their likely nationality and guess which person I'm interested in. Same could be said with years if you know the rough era the person thrived and nothing else.—Bagumba (talk) 15:33, 2 September 2021 (UTC)

I agree completely with this. It is not at all uncommon in disambiguating links to need to know the subject's time period to exclude non-starters from the search. BD2412 T 16:19, 2 September 2021 (UTC)

Yes, someone might become a member of parliament after a previous existence as a sportsperson or broadcaster (or many other reason-for-notability changes): having the dates helps eliminate some of the definitely unsought entries ("this person wrote a book in 1963, so they are definitely not the person born in 1970"). PamD 17:44, 2 September 2021 (UTC)

I'd prefer keeping the existing style for "born". As for "died", it's usually more helpful to use "fl." and a range, except in cases where the death year is really the only known date. Nick Number (talk) 16:44, 2 September 2021 (UTC)

Disambiguation pages about initials or acronyms

Should a disambiguation page about initials or acronyms make that clear about the disambiguated term? For instance, the disambigation page about MRD should perhaps describe "MRD" as "initials that may refer to, etc." Opinions? -The Gnome (talk) 16:00, 14 September 2021 (UTC)

I tend to think it's rather self-evident. BD2412 T 16:25, 14 September 2021 (UTC)

Well, quite often, a series of letters does not mean "initials." Take the disambiguation page for ABC: among the many subjects denoted by these three letters is the musical group ABC whose name is not made up from initials; it's simply "ABC." Why not state upfront if we have initials or not? -The Gnome (talk) 09:51, 15 September 2021 (UTC)

That adds to the case I was already going to make that I don't see that it's beneficial to make a special announcement at the top of disambiguation pages where all the entries happen to be initials. If one entry isn't initials, then it doesn't get that announcement, but if no entries are, then we should make a to-do about it? How about a page like Core that happens to have entries for which it is an abbreviation along with many where it isn't? If a reader sees an entry where the term is initials, it will be obvious that it's initials, advance warning isn't useful. Largoplazo (talk) 10:05, 15 September 2021 (UTC)

I agree with BD2412. Readers can exercise common sense to infer that a sequence of uppercase letters is probably a set of initials and not a normal English word. Colin M (talk) 14:56, 15 September 2021 (UTC)

I don't see how it helps the reader to know upfront whether the entries are all abbreviations or not.—Bagumba (talk) 15:25, 15 September 2021 (UTC)

Confused about redirects as dab entries

I'm a bit confused about when redirects are appropriate as dab entries. The guidance at MOS:DABRED and MOS:DABREDIRECT seems somewhat inconsistent. MOS:DABRED includes the following example:

• (correct) Flibbygibby (architecture), a flamingo motif used on cornices Y
• (incorrect) Flibbygibby, a type of noodle N

This is clear if there is no redirect at "Flibbygibby (architecture)". The question is what to do if someone has already created a redirect from Flibbygibby (architecture) to the cornice article. Such a redirect might be tagged {{R to section}}, {{R to subtopic}} or {{R to related}}. To keep the question straightforward, let's assume the article cornice contains the term "Flibbygibby" but it is not treated as a red link.

In such a case, which of the following is correct?

• Flibbygibby, a flamingo motif used on cornices

or

• Flibbygibby (architecture), a flamingo motif use on cornices

Note that in the second example above, the text for "Flibbygibby (architecture)" is a blue link because there is a redirect with that name. The presumption here is that this is a minor topic and not a potential article, so the red link is not appropriate in this case. But the redirect does exist. MOS:DABREDIRECT says redirects should not be used on dab pages, with some exceptions, and the exceptions don't appear to include this case. Given that, I would think the first example above is correct, i.e., don't use the redirect.

One might argue it's better not to include any entry at all in the dab, since it's not notable enough to have a red link article. There are lots of examples, though, where there are entries in dab pages that are only mentioned in articles and are not red links. This is described at MOS:DABMENTION.

On the other hand, MOS:DABRED says:

If the only pages that use the red link are disambiguation pages, do one of the following:

...

• Make a redirect to a page where the item is described (see § Piping and redirects above).

This case seems to apply here, because the article cornice includes term Flibbygibby but it is not treated as a redlink, so the only pages that would use the red link would be a disambiguation page. If there weren't already a redirect for "Flibbygibby (architecture)" this guidance appears to suggest creating one and then using it on the dab page. If not, why would the guidance be to create a redirect at all? Is it suggesting to create the redirect and then NOT include it as an entry in the dab? That's certainly confusing, and I'd say unclear. It seems then that this guidance indicates that the second example above is correct, i.e., use the redirect.

So which is correct? Coastside (talk) 00:41, 11 October 2021 (UTC)

As currently written, I agree that it doesn't make sense to create a redirect but then not use it in the dab. Practically, however, it doesn't really make sense to create a redirect if the term is just some trivial mention, like a bit character in a movie whose only mention is the bottom of a cast list.—Bagumba (talk) 02:41, 11 October 2021 (UTC)

So I gather you wouldn't create an entry at all? What about MOS:DABMENTION then? When do you include an entry with no article, no redirect, and not notable enough for a red link? What's the difference between "trivial" mentions and those described in MOS:DABMENTION? Is it some gray zone between notable enough to include as an entry in the dab but not notable enough for a red link? If such a gray zone exists, then it seems some of these questionable entries have redirects and some don't. Coastside (talk) 04:14, 11 October 2021 (UTC)

I have created such entries, but always think the existing guidance makes it quite subjective, the bit characters being an example. Of course my additions aren't trivial LOL.—Bagumba (talk) 23:57, 15 October 2021 (UTC)

I think the key clause in MOS:DABMENTION is if it would provide value to the reader. Trivial dabmention entries usually fail this test because they're not terms that readers would plausibly search for. e.g. readers are not going to type the name of a minor character from a single episode of a TV show into the search bar, because they know we're not going to have an article about a subject like that. Colin M (talk) 14:23, 17 October 2021 (UTC)

If the topic is notable and worthy of one day having a separate article, then I believe there's a slight preference among the community to have incoming links to it stay in red. That way it will be readily visible to editors who visit the pages with those links that the article doesn't yet exist, and presumably that will provide an incentive for its creation. So, a redlink is preferred on a dab page because a redlink is preferred everywhere. If a redirect has already been created, then it's possible to bring it to WP:RFD and it may get deleted solely on those grounds, though it's probably not going to be worth the effort unless there's something else that's wrong with that redirect.

A topic may not be notable, but still warrant a dab entry. The threshold is lower than WP:N, but still higher than WP:NOTEWORTHY (not everything that's merely mentioned somewhere needs having an access point through a dab page). If we have substantial coverage of this non-notable topic, and that coverage is in a single place, then it makes sense to have a redirect to that place. And if a redirect exists, then in my opinion it's preferable to use it in the dab page. It's a bit better for readers: otherwise, in an entry like Flibbygibby, a type of noodle it isn't immediately apparent that the noodle link will lead to content about flibbigibbies and so be worth clicking on. And it's marginally better for editors: if the redirect is updated (to point to a different section of the article, or to a different article), then the dab entry will automatically become up-to-date (the issue here is not about saving the effort of updating the dab page, but the risk it won't get updated at all: editors who rename the section or restructure the topic will ideally check the incoming redirects, but wouldn't normally go as far as inspecting the incoming links).

Of course, there are situations where a redirect is not appropriate in the first place. For example, a redirect can only have a single target, so if the topic is covered across two articles, the dab page will ideally provide equal navigation to those articles from the entry's description. Or a redirect may be present, but we still don't want readers to follow it. That happens, for example, with terminology: if the target contains only a very brief definition, there's no point encouraging readers to go there, as the same very brief definition will already be present in the dab entry's description (an instance of that is the entry for tempo marking at Adagion). – Uanfala (talk) 16:10, 12 October 2021 (UTC)

This is a very thoughtful and insightful answer. I found it very helpful on many levels. Thank you.Coastside (talk) 17:26, 12 October 2021 (UTC)

Place for editor-facing comments

Normally, when I need to leave a comment explaining why a weird-looking dab entry has been included or why it's in the section that it's in, then I'd use the hallowed wiki practice of leaving an html comment. Some editors probably do read those comments, but I'm not seeing them. What I am seeing is editors routinely removing html comments and proceeding to edit in a way that shows they haven't read them.

Evidently, we need a higher standard of visibility than used on the rest of Wikipedia. What are the alternatives? – Uanfala (talk) 11:35, 19 November 2021 (UTC)

Are subsequent edits hand-crafted in traditional wikitext, or do they have tags indicating VE, mobile, or some other newfangled WYSIWYG contraption which might conceal comments and/or remove them? Certes (talk) 13:35, 19 November 2021 (UTC)

Ha, no. The recent cases I remember involved the vanilla desktop source editor. But even the VE shows the comments (with a big exclamation mark icon, and the beginning of the text of the comment in dark gray colour, which, when clicked, expands to show the whole comment). – Uanfala (talk) 13:58, 19 November 2021 (UTC)

Then I hope someone has a better idea but I suspect we've done all we can. We may just have to assume that the editor has chosen to override the comment (and may be even be right occasionally). Certes (talk) 14:58, 19 November 2021 (UTC)

Agree html comments are useful for such things. I also use them to hide entries that currently fail WP:DABACRO when I suspect the commented out entries may be candidates for reinclusion if/when the article defines the acro, plus it explains why it currently isn't listed, rather than ping-pong editing of inclusion/removal. I do, however, remove some boilerplate comments, as we already have a general editor guide visible when editing dabs. Widefox; talk 13:18, 20 November 2021 (UTC)

Yes I agree that we've done all we can. I do occasionally delete comments when I've decided to override the intent of those comments: consensus and style does change over time and deletion of a comment that explains what is now bad practice is fair. Shhhnotsoloud (talk) 12:09, 28 November 2021 (UTC)

But that's often the whole point of the html comment: to explain why something that looks at first sight like an example of "bad practice" has been purposely chosen as the optimal solution in the context. – Uanfala (talk) 13:40, 28 November 2021 (UTC)

Yes, but like all edits, it's doesn't mean they're necessarily good. I only very rarely delete them, and even then they've been there for years. Shhhnotsoloud (talk) 08:50, 1 December 2021 (UTC)

The DABMENTION shortcut

The section "Items appearing within other articles", which is the target of the MOS:DABMENTION shortcut, has the following rule:

If a topic does not have an article of its own, but is mentioned within another article, then a link to that article may be included if it would provide value to the reader.

The shortcut is a fair and memorable representation of this rule, and it's very widely used. However, I've come to realise that it sometimes tends to lead people down a garden path. The two issues are:

1. Even though the rule is (and always has been) about topics, the prominence given in the shortcut to the word "mention" has led some, including a few very experienced dab editors, to take it to be about terms instead. People have cited DABMENTION when objecting to dab entries where the topic is definitely mentioned in the linked article (even typically being the topic of the whole article), though not with that exact term. A mention of the term will be desirable if its connection to the target article is not obvious (for verifiability), but most often in this case the connection has been obvious: for example, because the term is a common English word for the topic, or a straightforward alternative transliteration of the article's title.
2. The same emphasis on mentions has encouraged others to see any mention, no matter how trivial, as a justification for adding a dab entry. One particularly common case concerns songs mentioned in an album article, where the article provides no content about the song beyond its length and track position. This issue has been raised before, and it was the reason why a few years ago the bit about reader value was added to the guideline. I believe this may have helped, but only to a degree.

What do we do?

One possible remedy is to create, and start using, a shortcut that won't have these misleading implications. Any ideas here? How about DABCONTENT? Or DAB(SUB)TOPIC? DABWITHIN? – Uanfala (talk) 20:05, 29 August 2021 (UTC)

Regarding the first issue, it's definitely a valid point, but in my experience it comes up very rarely. I do a lot of editing of dab pages, and have a lot of them on my watchlist, but I think the recent discussion at talk:Fucking is the first time I've seen this distinction be relevant. I'd be curious to see other examples where this has caused confusion, if you can think of any.

I think the second issue is a big problem (I wrote a grumbling mini-essay on it here), but I think it's mostly orthogonal to the first issue, and solving it will require actual changes to the text of policy (perhaps by expanding on what it means to "provide value to the reader"). I think the main reason for bad dabmentions failing to provide value to the reader is that they are utterly implausible as search terms for the linked article/(sub)topic. There is just not a person on earth who types "Mercury" into the search bar on Wikipedia hoping to find information about the fictional town that provides the setting for the movie Young Adult. Colin M (talk) 21:47, 29 August 2021 (UTC)

I'm going off topic here, but it turns out the Young Adult entry on Mercury isn't completely implausible. According to WP:Clickstream data, the link was followed 11 times in November last year. – Uanfala (talk) 13:37, 19 November 2021 (UTC)

That's out of approximately 10k total views, right? I'm wondering if this is something like the Lizardman's Constant. If we added a completely irrelevant entry to the dab, I wouldn't be surprised if it got around 0.1% of the total clicks through some combination of reader curiosity or bot/crawler activity (there's an attempt to remove such entries from the data, but I imagine there are a few that will fly under the radar because they provide a dishonest user-agent string). Colin M (talk) 18:42, 1 December 2021 (UTC)

Maybe the solution to the second issue is to change "mentioned" in the guide to "discussed"? Terms are mentioned, topics are discussed. —swpb^{T • go beyond • bad idea} 19:47, 16 September 2021 (UTC)

I think that's a good idea. If there aren't any objections, I'll change that word and remove the DABMENTION from the shortcut box. We'd still need a handy replacement though. – Uanfala (talk) 13:37, 19 November 2021 (UTC)

Placement of "other uses" entries, including "common" uses, on sectioned dabs

There appears to be disagreement on two aspects of how we handle these types of entries on long, sectioned dab pages:

1) From MOS:DABGROUPING: "Entries which do not fit neatly into any section should be placed in an "Other uses" section or subsection, at the bottom of the page or section"

To me, that says there should not usually be any entries above the first subsection of a section, and if there are, they should be moved to the bottom of the section as "Other uses in [topic]".

2) From MOS:DABORDER: "In cases where a small number of main topics are significantly more likely to be the reader's target, several of the most common meanings may be placed at the top, with other meanings below."

To me, this logic applies to sections as well as whole pages, and creates an exception to the "Other uses" rule.

So as an example per my interpretation, you might have:

'''Blah''' may refer to:

==Science and technology==
* [A common meaning of "blah" in science (one that is "significantly more likely to be the reader's target" per DABORDER)]

===Biology===
* [Meanings of "blah" in biology]

===Physics===
* [Meanings of "blah" in physics]

===Other uses in science and technology===
* [Meanings of "blah" in science (other than biology or physics) that are NOT "significantly more likely to be the reader's target"]

[more sections]

User:Widefox disagrees, though I'm not entirely clear on their preferred interpretation. How does everyone else interpret the guide?

Note: I'm splitting this discussion from the one above, as it is unrelated. —swpb^{T • go beyond • bad idea} 15:13, 17 November 2021 (UTC)

---

[From above thread:]

The entries at the top of the Arts and media section are what the guideline identifies as "significantly more common" uses of the term, which may go at the top. The entries I moved back to "Other uses" sections were not. And again, where such entries should go is settled consensus; this thread is only about what its title says. If you want to change the consensus on "other uses" entries, please start a different thread. —swpb^{T • go beyond • bad idea} 15:25, 17 November 2021 (UTC)

Re 3. sorry - which guideline says "significantly more common" for tops of sections? It appears to me that you've misquoted MOS:DABGROUPING to me, which I've already corrected above but you haven't acknowledged that factual error? Widefox; talk 16:33, 16 November 2021 (UTC)

Re: common meanings, I'm not misreading DABGROUPING, I'm reading MOS:DABORDER, second bullet: "In cases where a small number of main topics are significantly more likely to be the reader's target, several of the most common meanings may be placed at the top, with other meanings below.", which I contend applies to sections as well as the whole page. Re "other uses" subsections, I'm reading DABGROUPING, two sentences before the part you quoted above: "Entries which do not fit neatly into any section should be placed in an "Other uses" section or subsection, at the bottom of the page or section" (emphasis mine). That seems clear, but if you want to talk about it more, please start a new talk section; this one is just about the hatnotes. —swpb^{T • go beyond • bad idea} 17:21, 16 November 2021 (UTC)

It is clear that you are synergizing MOS:DABORDER and MOS:DABGROUPING - that is your interpretation. Firstly "common meanings" / MOS:DABORDER is a red herring as we are talking about sections and subsections, so coming back to what you originally wrote above MOS:DABGROUPING explicitly says not to do this which is factually incorrect. OK, so now I know what part of MOS:DABGROUPING you were interpreting. Your interpretation may seem clear to you, but it also seems clear to me that it hinges on "neatly" - which is subjective. Whether to place an entry in a subsection of a section or just the section is subjective. That is not how you've portrayed it to me "explicitly not". Logically, if it fits in a section, it may also fit in a subsection so both would be logically allowed, and subjective neatness would be the determinant. Is that clear now how your portrayal of my edits as being "explicitly not" allowed is actually factually incorrect? Do you consider all these long section names (as detailed above) to be neat, and more importantly, that they fail MOS:DABGROUPING? MOS:DABGROUPING Section headings should be as simple as possible. 1. They are not needed at all if the entries are "neat" in the section, 2. the wording is verbose. That causes the TOC to be gratuitously wide. If in any doubt, I invite anyone who has time to follow this to compare the two versions above and decide which is better for readers. (And as for limiting the scope of this talk section to a certain issue, I think BOOMERANG is pertinent in that by attempting to get another editor to conform with your interpretation and style, the wider issue of overcomplicating dabs is the bigger issue.) Widefox; talk 10:58, 17 November 2021 (UTC)

With the best intentions, you and I alone aren't going to resolve this. Let's please let others discuss here so that consensus will be clear in the future. —swpb^{T • go beyond • bad idea} 15:19, 17 November 2021 (UTC)

I take it that your concern for my edits has now gone, now that your incorrect warning put on my talk is uncontested. I'll leave this for others. Please don't give false warnings to other users. Widefox; talk 16:23, 17 November 2021 (UTC)

Guys, it appears that this disagreement is more apparent rather than actual. Regardless of whether you see MOS:DABORDER as relevant here or not, you do seem to agree that – within the current guidelines – it's OK for sections to begin with a few loose entries that don't otherwise fit into any of the subsections. As far as I can tell, one of you believes that this should only happen for entries that are popular or common, while the other sees it as appropriate for entries that are just not very obscure. This appears to be only a difference of degree. – Uanfala (talk) 00:51, 24 November 2021 (UTC)

Ok, but where do you fall on that difference? Should entries at the top need to be significantly more common (as I think the guide clearly says), or just not especially obscure? —swpb^{T • go beyond • bad idea} 21:35, 24 November 2021 (UTC)

@Uanfala: —swpb^{T • go beyond • bad idea} 14:13, 26 November 2021 (UTC)

Me? I believe entries at the top of sections should be avoided altogether. If they're very common, then they can be listed at the top, but only if they're also present in the relevant subsection. – Uanfala (talk) 14:42, 26 November 2021 (UTC)

I think we 100% agree. —swpb^{T • go beyond • bad idea} 17:44, 26 November 2021 (UTC)

@Uanfala, Shhhnotsoloud, Largoplazo, Bagumba, PamD, JHunterJ, BD2412, Charlie Awesome, Coastside, and Colin M: As the most active contributors to this talk page over the last year, I would appreciate your input on this topic and the one above, which seem to have gone stale. Thank you! —swpb^{T • go beyond • bad idea} 19:41, 23 November 2021 (UTC) @Uanfala, Shhhnotsoloud, Largoplazo, Bagumba, PamD, JHunterJ, BD2412, Charlie Awesome, Coastside, and Colin M: Apparently the first ping didn't work since I forgot to sign it. —swpb^{T • go beyond • bad idea} 14:40, 24 November 2021 (UTC)

Yes, MOS:DABGROUPING explicitly recommends the "other uses" approach, but it doesn't explicitly rule out alternatives (even though one possible implication is that it does). Regardless of what the guidelines say, I think we can agree that both approaches are used in practice.

Personally, when I organise dab pages I try to find a partitioning into subsections that won't result in any "leftovers" (you know, you don't always need to have "Science and technology", or any of the others, if it's going to have just two or three subsections. In such a case you can dispense with the section altogether, promote the subsections, and move the leftover entries into the dab's only "Other uses" at the end). But yeah, that's not always possible. If you have an "Other uses in..." subsection, then an obvious result is that the TOC gets bigger. I tend to dislike long TOC headings, but as far as I can see that only eats into the otherwise unused white space. As for the vertical length of the TOC, yeah, then you would want to make it as short as possible for ease of navigation, but that's not an overriding concern.

However, my main concern is with listing the leftovers before any subsections – because this effectively creates a category that's not visible from the TOC. That has already been mentioned, but I believe it's important. Say there is an "Art and entertainment" section with three subsections for "Films", "Literature" and "Music", and a leftover entry for a video game positioned at the top. Now, if a reader looking for the video game used the TOC to navigate, they'll look into the headings below "Art and entertainment" and they'll see there are enumerated three categories that their desired article doesn't fit. Maybe the reader is familiar with dab structure and so will guess there may be an entry hanging loose at the top, or they may just ignore the TOC and directly look through the page. But it's also possible they may conclude that there's no relevant entry and not look any further. – Uanfala (talk) 00:51, 24 November 2021 (UTC)

Thanks, well said: 1) The neatest solution is to avoid leftovers (if practical); and 2) Leftovers at the top of sections can easily be missed. DABORDER allows for a few "significantly more common" meanings up top, but if there's a chance they'll be missed there, I would argue they should appear in an appropriate subsection as well (other uses, or something more specific). And – key to the disagreement – I don't see any allowance for leftovers up top that are not "significantly more common", do you? Or would it help for the guide to be more explicit on that point? —swpb^{T • go beyond • bad idea} 14:52, 24 November 2021 (UTC)

Another solution might be a more artful use of headers. For example, where a grouping of "Films", "Literature" and "Music", would leave a leftover entry for a video game, adjust them to "Visual media", "Literature" and "Music", so that video games and films can be grouped together. Many issues involving a title that could fall into two groups can be resolved by more precisely defining the header terms. BD2412 T 19:59, 24 November 2021 (UTC)

Agreed, as Uanfala said: avoid leftovers if you can. Sometimes though, it just isn't possible without making very awkward groupings. —swpb^{T • go beyond • bad idea} 21:28, 24 November 2021 (UTC)

Yes, avoid leftovers. In the example case I'd either use "Other uses in arts and entertainment" or indeed "Gaming" in this specific case. Shhhnotsoloud (talk) 12:12, 28 November 2021 (UTC)

re 2: I would only interpret this as applying to listing common meanings at the top of the page, but not at the tops of individual sections. The latter is not something I've commonly observed in practice, and it seems like it would lead to the problem discussed earlier about entries which logically belong in more than one place. e.g. if Blah (neurotransmitter) is "significantly more likely to be the reader's target" than other Science and technology meanings, do we list it at the top of the "Science and technology" section and in the "Biology" subsection?

re 1: I agree with your interpretation of MOS:DABGROUPING here, though I will say that, from what I've seen, it's still very common in practice to put uncategorized entries at the top of a section, rather than in a "Other uses in X" subsection - it might even be more common? (I personally don't mind the practice, since I value keeping the ToC compact and find it reasonably intuitive for navigation.) Colin M (talk) 19:09, 1 December 2021 (UTC)

You say "From MOS:DABORDER: "In cases where a small number of main topics are significantly more likely to be the reader's target, several of the most common meanings may be placed at the top, with other meanings below. ... To me, this logic applies to sections as well". I entirely disagree with this assertion.. Shhhnotsoloud (talk) 19:56, 1 December 2021 (UTC)

To editor Shhhnotsoloud: So if you don't support an exception for common meanings (assertion 2), can I assume you support assertion 1 (there should never be any floating entries at the top of sections) without exception? I can work with that – to me, that is the more important question, since this discussion was largely precipitated by floating entries that didn't even claim to meet a "more common" standard. If we are reaffirming a consensus that at least bars those kinds of entries from the top of sections, I'm happy. —swpb^{T • go beyond • bad idea} 14:39, 2 December 2021 (UTC)

Can you imagine a table listing countries in ascending order by their population and, grouped under each, the country's major subdivisions listed in descending order by population? If the page-wide Other Uses section should be at the bottom of the page, then section-specific Other Uses subsections should be at the bottom of their respective parent sections. Largoplazo (talk) 23:35, 3 December 2021 (UTC)

How we deal with entries that plausibly fit in multiple sections

When dividing long dabs (like Star (disambiguation)) into sections, it can be hard to avoid having entries that would make sense in more than one section. As I see it, there are three ways of dealing with this. In light of some disagreement, I think it's time for a consensus. The approaches I see are:

1. Don't deal with it. Put each entry in exactly one section, and if the reader guesses the wrong section, they'll go to the top of the page and try again (or, I suspect, often just give up).
2. Repeat entries in each section that they would make sense in. This makes long dabs even longer, but makes it more likely a reader will find what they want in one go.
3. Put each entry in only one section, but put a hatnote pointing to that section at the top of any other section where the entries in question might be expected to be found.

To me, the approach that makes thing easiest for readers is a hybrid/flexible one: first, try to avoid the situation in the first place (let's call that approach zero). Then, if there are only a couple such entries in a section, repeat them (approach 2). If there are a lot of entries (or a whole subsection) that would fit it multiple places, use hatnotes (approach 3). That's the approach I laid out in the supplement MOS:LONGDAB and have been implementing for a while.

So, I'm looking for either support of this hybrid approach, or arguments for why another approach is better. Thanks! —swpb^{T • go beyond • bad idea} 15:06, 15 November 2021 (UTC)

Side comment: I've put a box around Widefox's reply below, just to make it clear where it starts and ends, since it has a number of indents, outdents, and signatures that make that tricky visually. I'm not changing the reply in any way, just helping readers of this thread. —swpb^{T • go beyond • bad idea} 16:07, 16 November 2021 (UTC)

Ok, just a couple of things:

1. I didn't complain about any of your other, valuable changes, so I don't know why you're bringing them up.
2. For the sake of readability, maybe you can shrink your reply and stick to the topic in the title – no one but you or I cares about what's on your talk page (and I don't have to be "neutral" there, I'm allowed a position).
3. [Moved this point to the next thread, below]
4. I don't think I understand your argument against the hatnotes. Granted they don't appear in the TOC, but I don't see how that makes them detrimental. I don't think a 30-ish character long (rarely 60-ish) hatnote makes a page much harder to use, even on mobile. —swpb^{T • go beyond • bad idea} 21:18, 15 November 2021 (UTC).

If anyone finds this TLDR - I'm for keeping dabs as simple as possible including as few templates as needed - hatnotes at the top can be put in See also sections as we are not disambiguating topics, so are redundant. There's likely some exceptions like common spelling errors when may it's useful.

Re 3. sorry - which guideline says "significantly more common" for tops of sections? It appears to me that you've misquoted MOS:DABGROUPING to me, which I've already corrected above but you haven't acknowledged that factual error? Widefox; talk 16:33, 16 November 2021 (UTC)

Procedural remarks

Moving the off-topic portion of this discussion to its own thread below; please continue it there. —swpbT • go beyond • bad idea 15:13, 17 November 2021 (UTC) Swpb - your major talk refactoring below into a separate section breaks up the chronology, and you've used that to frame the discussion completely differently to "explicitly not" (per above) - it isn't helpful from my perspective, as both sections are needed for context. Widefox; talk 16:36, 17 November 2021 (UTC) Revise your comments however you want so you feel understood, but leave these two separate topics separate, for the sake of everyone else. —swpbT • go beyond • bad idea 19:00, 17 November 2021 (UTC) Please familiarise yourself with WP:REFACTOR If another editor objects to refactoring then the changes should be reverted. It's now moot, but please don't do that again, as it's aggressive to post on another users page with a false warning, refuse to accept that it's false, and try to dominate an open discussion about your behaviour. I don't have the impression that you're listening or willing to engage in open discussion, but just over-selling your dab style which as detailed above and below isn't optimal for readers IMHO. I encourage other dab editors to agree that overly long section names and formulaic use of "Other use in X" makes dabs less fit for "navigation". Widefox; talk 14:46, 18 November 2021 (UTC) "an open discussion about your behaviour." That is not what this thread is. This is a discussion to establish a guideline consensus; everything else is off topic. If you want to complain about my behavior, there are several appropriate forums for that where I'll gladly participate (although I don't know what sort of satisfaction you're hoping for). —swpbT • go beyond • bad idea 16:50, 18 November 2021 (UTC)

@Uanfala, Shhhnotsoloud, Largoplazo, Bagumba, PamD, JHunterJ, BD2412, Charlie Awesome, Coastside, and Colin M: As the most active contributors to this talk page over the last year, I would appreciate your input on this topic and the one below, which seem to have gone stale. Thank you! —swpb^{T • go beyond • bad idea} 19:41, 23 November 2021 (UTC) @Uanfala, Shhhnotsoloud, Largoplazo, Bagumba, PamD, JHunterJ, BD2412, Charlie Awesome, Coastside, and Colin M: Apparently the first ping didn't work since I forgot to sign it. —swpb^{T • go beyond • bad idea} 14:40, 24 November 2021 (UTC)

@Uanfala, Shhhnotsoloud, Largoplazo, Bagumba, PamD, JHunterJ, BD2412, Charlie Awesome, Coastside, and Colin M: I promise this is the last ping, but one of you must be able to offer an opinion on this. —swpb^{T • go beyond • bad idea} 14:49, 30 November 2021 (UTC)

• It's a bit "TLDR", but of your initial set of options 1-3 I think I'd go for "1", with the option of re-engineering the subject headings in some cases if that would help resolve the issue. But I haven't looked into this in detail. Sorry. PamD 18:00, 30 November 2021 (UTC)

• Further: duplicate entries seems a very bad idea, as anyone coming to the page to fix an entry will not expect them and probably only fix the first found, and we spiral into chaos. Listing some people at their topic and others under "people" or on separate page would confuse readers: one or two very commonly sought people known by the dab term could appear in the top, "commonly", section, but beyond that people just get listed as people. PamD 06:20, 4 December 2021 (UTC)

To editor PamD: Ok, so what about the reader who is looking for "Star, a female professional wrestler from the Gorgeous Ladies of Wrestling" (or some other entertainer known as "Star"), ends up on Star (disambiguation), sees an "Arts and entertainment" section near the top, and looks there? This is a casual user who doesn't know about the "people only go in 'People' sections" rule. On not seeing their target, do they go back to the ToC and see if it could be somewhere else? Or do they (I think more likely) conclude that we don't have an entry for their target, and give up? I agree on the hazards of duplication (though hidden comments could ameliorate that; I wonder what you think of Uanfala's comment below). This is where hatnotes offer value, no? —swpb^{T • go beyond • bad idea} 16:18, 6 December 2021 (UTC)

@Swpb: Yes, they look at the headings, see "People", and realise that people are people. If they go to "Arts and entertainment", they notice that there are no people listed there, and look further. If we start having duplicate entries, then when information about "Star" changes (possibly she dies) we find her annotation updated in one place and not the other, because editors do not expect duplication. If you put her in two places, and she developes a sideline in politics, would you expect to see her listed three times? Just no. PamD 23:08, 6 December 2021 (UTC)

@PamD: Your position boils down to: If a person knows Star only as a politician, then that person is going to come away from this disambiguation page thinking that Wikipedia has no article on her because we insist on choosing only one section. Why is that acceptable? How is that helpful?

You ask "would you expect to see her listed three times?" The purpose of a disambiguation page isn't to meet people's expectations as to the number of times one subject is listed meeting a particular restriction, so your question isn't pertinent to the value and utility of a disambiguation page. The proper question is "Can people who will be coming in search of this subject through different avenues be equally able to find this subject, or are we going to penalize users for not having the context we've decided is primary?"

As for maintainability, if there are three entries and, should an event occur that makes it desirable to update the existing annotations, only one of them is updated, that is no worse than case of a single entry on a disambiguation page that nobody thinks to update: not a terrible thing. It's a subsidiary consideration to the primary purpose of these pages. Largoplazo (talk) 00:39, 7 December 2021 (UTC)

I think it's unlikely a reader who sees what they think is the right section is going to read the rest of the ToC first; why would they? If the target isn't where they expect it, they have no reason to assume it must be somewhere else. Repeat entries can also be managed with {{section transclude}}, but repeats aside, what about hatnotes (noting, again, that the first course is always to avoid the situation where possible)? —swpb^{T • go beyond • bad idea} 16:54, 7 December 2021 (UTC)

• I'd go for 1, but I don't think it happens enough to deserve extensive debate or new guidelines. Shhhnotsoloud (talk) 08:53, 1 December 2021 (UTC)
  • It actually happens quite a lot on dab pages for very common terms. —swpb^{T • go beyond • bad idea} 19:10, 1 December 2021 (UTC)
• I would also lean towards 1. Hatnotes (3) might be appropriate in some rare cases, though I think they're overused in the current iteration of Star (disambiguation) (e.g. I don't think the "Businesses § Transport companies" subsection needs the hatnote "For vehicles, see § Transportation.", since a vehicle is not a business). I'm pretty strongly opposed to 2 (repeat entries) since it makes long dab pages even longer and creates maintainability issues (if someone makes a correction to the text of the dab entry in one place, they might not know to make the same change in the other place where the same link is listed). Colin M (talk) 19:17, 1 December 2021 (UTC)
  • The specific hatnote you mention is indeed not very helpful, so I've gotten rid of it. But I think their usefulness may be more common than you think. Some of the most commonly used headings leave room for overlap, like "People" and the various fields they are in, "Arts", "Sport", etc., or "Transportation" with several other sections. —swpb^{T • go beyond • bad idea} 19:39, 1 December 2021 (UTC)
• I'm going to go with listing a title in each applicable section. There's a small risk of a later passerby thinking the duplication is outright wrong and removing one of the entries, but that can be reversed with an explanation. I thought about having a "Multiple fields/arenas/categories" section for those, but (a) that would be ugly, (b) it would be at the bottom or else it would be even uglier, yet (c) if it were at the bottom then users might check one of the expected single-field sections, not find the entry, and not realize there's a multiple-field section to explore at the bottom. If it's going to be ugly in one way or another, opt for the way that is at least more helpful rather than more likely to leave a user unassisted. Largoplazo (talk) 23:31, 3 December 2021 (UTC)
• Normally, the dab page should be arranged in such a way that there won't be uncertainty about which section a given entry will belong to – that's better for the readers, so when they look at the table of contents, they'll immediately spot the relevant section and not wonder about alternatives. However, this may occasionally be difficult to achieve. If an entry fits equally well in two sections, do you place it in both or arbitrarily pick one? I've seen editors going for the latter as the self-evident choice or removing repeat entries on sight, but I've never seen good reasons for that and I'm glad this has been brought up for discussion now.
  Repeating content is of course undesirable in articles: excluding the lede section, the reader shouldn't be forced to go through the same piece of text twice. But dab pages aren't articles: readers don't read them from beginning to end, they only browse the table of contents and then the relevant section. Repeating entries between sections doesn't make a difference to readers. It doesn't have much of an effect on page size either: even for large, complicated dab pages, if they're well organised, then you won't need to repeat more than a couple of entries.
  I think the key consideration here is that it can't be taken for granted that readers will always check all applicable sections. Even if we ignore the fact that many people have been a bit spoilt by the efficiency of Google and so will expect to find what they need at the first try, it still remains the case that it may not necessarily occur to absolutely everybody that a given entry may be subsumed under a different heading than the one they thought of at first.
  Given the possibility that some readers may miss the entry they need, and – of less importance – the inconvenience all the rest will have to go through in browsing through additional sections, I believe it's worthwhile to repeat entries where plausible. The only costs are in maintenance, and these are low. It's indeed possible that when making updates editors may miss the additional copy, but this can easily be prevented by, for example, an html comment next to each entry (assuming editors don't automatically ignore such comments :) ); even without that, I think it's better to have an entry with an outdated description than one that's in a place where some readers will miss it. – Uanfala (talk) 21:57, 4 December 2021 (UTC)

Very well said!! This is a "lesser of evils" situation. First, try to avoid the situation; if that won't work, weigh helping the reader against adding maintenance. IMO, helping the reader is usually worth it. —swpb^{T • go beyond • bad idea} 16:26, 6 December 2021 (UTC)

• Hadn't seen this question before, so a late entry.

I'm very prescriptive on this, and my lodestar is: anything that isn't a unique entry and (very optionally) a brief disambiguation aid, is clutter until proven innocent.

This is based on my own use of disambiguation pages, which I believe would not be too far off from any other reader's. I'm there to find one entry. Anything that I have to read to find that one entry slows me down. "This section is about floor waxes. For candle wax, look at "Candle Wax" -- doesn't help me, if I'm looking for Hepzibah Wax, the famous children's author. Oh, but in the "People" section it suggests I should also look at "Music" and "Sports"! And the Scranton Wax Museum is under "Museums", and "Entertainment", and "Research Institutions".

Each one of these things is perhaps helpful for someone, but it's an impediment for almost everyone (that is, the three listings for the Scranton Wax Museum helps Scranton-Wax-Museum-lookers, but on a large dab page, which is what we're talking about, most people are, statistically speaking, not going to be Scranton-Wax-Museum-lookers, and we're slowing them all down.

On my user page, I've described this as the "ASCII Table Rule of Thumb", based on the historic observation that at least in the old days, every computer book ever written had an ASCII table as an appendix, despite very few people ever needing to actually read it. You could also call it the "Mr. Creosote" theory: "Oh, just add it, what could it hurt? It's wafer thin!"

In summary: add entries exactly once. Don't add breadcrumbs to other sections. Keep things uncluttered, to the benefit of the majority of your readers. People will still find the entry—especially if the page is uncluttered.--NapoliRoma (talk) 17:34, 7 December 2021 (UTC)

To editor NapoliRoma: 1) Your reader looking for the author Wax will never see the note in "Floor waxes", because why would they be reading anything in that section? And 2) more generally, you've cast a much more extreme policy than is really on the table here. First, there should never be three sections that could claim the same entry (even two is to be avoided) – if there were, the answer would be to revise the scopes of the sections. I've repeated up and down this thread that all this is a fallback, for if the situation can't be avoided in the first place; I don't know why no one is acknowledging that. And second, most importantly, this is not about mandating breadcrumbs for all possible situations, it's about allowing breadcrumbs for the few situations where they are most likely to be helpful. Would you not agree they should be allowed, given that they can always be challenged case by case? —swpb^{T • go beyond • bad idea} 18:34, 7 December 2021 (UTC)

NapoliRoma, I agree with Swpb. Your scenario implies that you aren't bothering to look at the section headings, which means you're complaining about a fraction of a second lost at the same time that you're choosing not to avail yourself of an aid provided to cut your search time substantially. Meanwhile, you're suggesting saving one-quarter of a second each for perhaps 100 self-defeating heading-ignorers justifies preventing one user from finding the information they're looking for altogether. I disagree with that trade-off. Largoplazo (talk) 22:25, 7 December 2021 (UTC)

Redirects to sections

MOS:DABREDIR says: "A redirect should be used to link to a specific section of an article if the title of that section is more or less synonymous with the disambiguated topic." This is somewhat confusing. I thought disambiguation pages were for disambiguating terms, not topics. Maybe it could be reworded along the lines of: "A redirect should be used to link to a specific section of an article if the title of that section is more or less synonymous with the topic referred to by the ambiguous term."? --Sangdeboeuf (talk) 23:41, 6 December 2021 (UTC)

Seems like splitting hairs – I don't see how confusion over that sentence would lead to a bad edit. The proposed text might be a tiny bit more precise, but at the cost of making the sentence harder to parse, which to me is a net negative. —swpb^{T • go beyond • bad idea} 14:33, 7 December 2021 (UTC)

In the current wording, it says "disambiguated topic"—that is, this entry has now disambiguated the ambiguous term, and we're pointing to the appropriate article/section for that entry. I think that's correct.--NapoliRoma (talk) 16:49, 7 December 2021 (UTC)

Now that this sentence has been placed in the limelight, I notice a rather more serious problem with it: if the title of that section... What the title of the section happens to be is completely irrelevant here. What matters is that the section covers the topic referred to by the ambiguous term. And it doesn't matter if this topic is discussed in a well-defined section, a list entry, or more diffusely throughout the article. See for example Inclusive, where this principle is appropriately applied to more than half of the entries contrary to what a literal reading of the guidelines would suggest. – Uanfala (talk) 00:03, 8 December 2021 (UTC)

That's a great point. How about just "A redirect should be used to link to a specific section of an article if that section discusses the disambiguated topic." Looks like redirects to whole articles are covered in the subsequent bullet. —swpb^{T • go beyond • bad idea} 14:28, 8 December 2021 (UTC)

That sounds like an improvement. We may want to tweak the wording to clarify that the topic should be discussed only or mainly in the section. (Pedantically, Mercury (planet) is discussed in all of its sections, but Mercury should obviously link to the entire article.) Certes (talk) 15:00, 8 December 2021 (UTC)

How about the dab page Positive and the redirect Positive charge which points to no particular section of Electric charge? – Uanfala (talk) 16:09, 8 December 2021 (UTC)

That's a good example of correctly linking (via a redirect) to the whole article rather than to a section, as positive charge is discussed in several sections. Positive currently links the similar Positive (electricity) instead; is there room for both? Certes (talk) 16:46, 8 December 2021 (UTC)

That's a good example of using a redirect to link to a subtopic, but that would be ruled out by the guidelines as currently worded: "Positive charge" is neither an alternative name for Electrical charge, nor a subtopic confined to a single subsection. Thanks for spotting the gap at Positive: I've added an entry for positive charge, and retargeted Positive (electricity) to the dab page). – Uanfala (talk) 17:28, 8 December 2021 (UTC)

True. We probably need a separate bullet point for redirect to a whole page where the subtopic not confined to one section, unless there is consensus that we should present these links in some other way, such as Positive, a polarity of electric charge. Certes (talk) 18:57, 8 December 2021 (UTC)

Does it make a difference if the redirect is to a section or not? I don't believe it's relevant for us how the particular article happens to have been organised. As far as I can see, what matters is that the redirect refers to a subtopic (or a related topic) that's treated within that article. Or is there something that I'm missing? – Uanfala (talk) 23:03, 8 December 2021 (UTC)

The guideline seems to imply that redirects are deprecated unless they lead to sections (with certain exceptions which don't apply here). That nuance may have crept in unintentionally and should probably creep out again unless someone knows a reason why it should stay. The extra bullet point suggested above would defuse it. To take a concrete example: do we allow  • Positive, a polarity of electric charge;  • Positive charge, an electrical property; or either? Certes (talk) 23:24, 8 December 2021 (UTC)

I've boldly made the change. —swpb^{T • go beyond • bad idea} 17:23, 8 December 2021 (UTC)

The following bullet does cover redirects to whole articles, but that could do with some attention as well. For example, it's got two numbered conditions, but the first one has been effectively made redundant because of the wording in the second one. Also, it says the redirect could serve as an alternative name for the target article. The redirect could serve as an alternative name for the topic of the article, but when you refer to the name of the article, you risk sending people down the garden path of wondering about whether that term fits the article naming conventions, which is beside the point.

The wording in the guidelines here, and in the case for sections, does appear to permit a wide range of redirects, like Planet Mercury or Capital of France, which we obviously aren't going to use. Maybe we should consider a more substantial rewrite here. It may be a good idea to reiterate why we avoid redirects in the first place (because they obscure the target article's names), and lay out why we use them when we do (most importantly, to bring the link in line with the disambiguated term). – Uanfala (talk) 16:09, 8 December 2021 (UTC)

It's been a while, but IIRC, part of the rationale for using a redirect involved potential that the term might become a standalone article. There's also potential to facilitate changes in target of the redirect if content gets reorganized. On the other hand, I think another rationale was more of an aesthetic one, so that the links can all be in the first position rather than in a piped section link in the description. older ≠ wiser 00:03, 9 December 2021 (UTC)

indention

This MOS doesn't seem to address the practice of indenting within DAB pages. Should it? What is the consensus on doing so? — Fourthords | =Λ= | 21:41, 26 January 2022 (UTC)

MOS:LIST is disappointingly silent on the topic of sublists. We sometimes use them where items are part of another, e.g.

• Foo, a town in Narnia
  • Foo village
  • Foo Airport
  • Foo (parliamentary constituency)

where the village, airport, etc. lie within the town. Certes (talk) 19:41, 29 January 2022 (UTC)

Avoiding descriptions when the link is unambiguous?

The section MOS:DABENTRY makes the excellent point that descriptions need to be brief, but then goes on to add:

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.

That's not good advice any more. Even though a few editors have remained faithful to this principle, my understanding is that most of us do normally include descriptions in such cases and we strive for those descriptions to be consistent in the level of information provided at least within each section. I'm taking this as self-evident and proposing that this text be scrapped in its present form. Would we need some remaining mention of the situations where descriptions are largely unnecessary (as sometimes happens with acronyms)? – Uanfala (talk) 01:00, 25 January 2022 (UTC)

I don't think descriptions are disallowed, but we should make it clear that repetition is optional. The examples include both

• "Dark Star" (song), by the Grateful Dead Y
• "Dark Star" (song), a song by the Grateful Dead Y

though the latter seems unnecessarily repetitious: the article title may be clue enough, especially if the dab section is headed "Songs". Certes (talk) 01:30, 25 January 2022 (UTC)

I for one think the existing text is good advice, how often it's followed notwithstanding. If any part of a description doesn't help the reader – because it repeats the parenthetical, it repeats the header, the link is a spelled-out acronym, or else – there's no reason for it to be there, even if it's the whole description. —swpb^{T • go beyond • bad idea} 15:44, 25 January 2022 (UTC)

One thing I had in mind, and thought that everybody else did too, was the fact that not all users will read the the entire entries from one end to the other, including the link. Some (most?) people may find it quicker to skim read vertically: either just the links, or just the descriptions. A relevant factor is that adjacent entries may not always use the same level of disambiguation in their titles. Consider the following three formats for the same group of entries:

Variant 1:

• Foo, Chandipur
• Foo, Namagari
• Foo, Lithuania
• Foo, Krasnoyarsk
• Foo, Magadan

Variant 2:

• Foo, Chandipur, a village in India
• Foo, Namagari, a town in India
• Foo, Lithuania
• Foo, Krasnoyarsk, a village in Russia
• Foo, Magadan, a locality in Russia

Variant 3:

• Foo, Chandipur, a village in India
• Foo, Namagari, a town in India
• Foo, Lithuania, a city in Lithuania
• Foo, Krasnoyarsk, a village in Russia
• Foo, Magadan, a locality in Russia

Which one serves our readers best? #1 gets closest to what the guidelines recommend. But imagine you're looking for a place and the only thing you know about it is that it's located in India. Variant 1 will be confusing unless you're already familiar with the individual lower-level disambiguators used. Variant 2 remedies this, but imagine yourself in the shoes of the reader looking for the place in Lithuania. How could you most quickly spot the country name you're after? In Variant 2 some countries appear in the descriptions (on the right of the visual field), others are only part of the links (on the left). You'll likely need to glance back-and-forth between the column of the links and the column of the descriptions. What if you're looking for a city but you're not sure which East European country it was in, which variant will be the most helpful?

I'm only bringing this up because I occasionally see people converting from the third variant into the second or the first, and the current guidelines seem to encourage that. – Uanfala (talk) 23:23, 25 January 2022 (UTC)

I'd probably go for

• Foo, Lithuania, a city in Bar County

which is a little inconsistent but gives a similar amount of detail to the Indian places if in a different order. Better might be

• Foo, Bar County, a city in Lithuania

but I'd not create the redirect just for that. Certes (talk) 00:53, 26 January 2022 (UTC)

There's another way to do it, I dare say the best way, given that these entries are presumably in a "Places" section:

• Foo, Chandipur, India
• Foo, Namagari, India
• Foo, Lithuania
• Foo, Krasnoyarsk, Russia
• Foo, Magadan, Russia

The country names are useful info, the village/town/city distinction is much less so. There might sometimes be value in adding words to a description to create parallelism for vertical skimmers, but I don't think that negates the current MOS advice on descriptions. It could supplement it though. Maybe something following the current text like "In some cases, it may be helpful to readers to use the same pattern of description for a series of entries of the same type". —swpb^{T • go beyond • bad idea} 18:27, 28 January 2022 (UTC)

For me, type isn't less important than location. As a reader, I'd find your example disorientating: it lists where things are but doesn't disclose what those things are. If I were forced to use only a single word in each description (a rule that fortunately we're never constrained by) then I'd go for the type information, as the location is normally already given in the link. – Uanfala (talk) 23:26, 28 January 2022 (UTC)

Another test case from Francisco Rodríguez:

Boxing

• Francisco Rodríguez (boxer, born 1945), Venezuelan boxer
• Francisco Rodriguez (boxer, born 1984) (1984–2009), American boxer
• Francisco Rodríguez Jr. (born 1993), Mexican boxer

Is "boxer" repetitive? Would a description with only the nationality without "boxer" be too cryptic?—Bagumba (talk) 08:57, 26 January 2022 (UTC)

I tend to dodge that issue by calling him a "Venezuelan flyweight" or similar. It adds potentially useful distinguishing information concisely and avoids any risk that repetition might look silly. Certes (talk) 18:40, 28 January 2022 (UTC)

@Certes: Thanks. Any ideas if the disambiguator is already by sports position e.g. Chris Carter:

American football

• Chris Carter (defensive back) (born 1974), American football safety
• Cris Carter (born 1965), American football Hall of Fame wide receiver
• Chris Carter (wide receiver) (born 1987), American football wide receiver
• Chris Carter (linebacker) (born 1989), American football linebacker

—Bagumba (talk) 07:35, 3 February 2022 (UTC)

I don't think we have any strict rules but I'd tend to leave "American football" out if it's in the subheading, and maybe have no description at all for the last two as it all appears elsewhere. I can imagine readers knowing that the guy they're looking for played safety but not his year of birth. Certes (talk) 10:58, 3 February 2022 (UTC)

Dab entries for other-language articles

While I was doing the NPP, I came across this DAB page which includes an entry for an article that does not exist on English WP but does on another project. I've never encountered this before and am not sure what to do. My inclination is to redirect it to the single entry with an article, but I would like the thoughts of those who deal with this regularly. —Compassionate727 ^(T·C) 12:35, 1 April 2022 (UTC)

I think you're right in this case, as the mention of the Belgrade museum carries little useful information beyond its director's name. In general, there are differing views on allowing interlanguage links in dabs. A longer discussion appears in the WT:Disambiguation archives from 2020—21. Certes (talk) 13:31, 1 April 2022 (UTC)

Hatnote explanation in See also section

This whole manual of style primarily applies to the disambiguation page itself, yet the first paragraph in MOS:DABSEEALSO talks about placing hatnotes in an article (giving the example Sydney). Without clicking the links, I thought it was suggesting to add alternate spellings as hatnotes instead of a See also section on a DAB page (which contradicts the bulleted list that follows).

Is this paragraph really necessary for a DAB page style guide? (I'm wondering if it would be better on the WP:DAB guide.) If it belongs here, I think it would help to make it more clear: "...alternate spellings in a hatnote in the article instead of..." I'm fixing the DAB Marine World right now, which has 4 hatnotes that I think should be moved to a See also. Hoof Hearted (talk) 15:13, 6 May 2022 (UTC)

The paragraph is confusing because it applies to articles but doesn't make that clear, being in a page about the text of dabs. We should probably remove it. Hatnotes in dabs are mainly limited to self-references (e.g. Verification) and internal section links (e.g. Phoenix#Arts and entertainment). Article-style hatnotes occasionally appear where a blatant mistake is so common that many readers will be looking for the other term (e.g. Columbia) but, though justified, that promotion from See also verges on IAR.— Preceding unsigned comment added by Certes (talk • contribs) 22:06, 6 May 2022 (UTC)

Thanks Certes. Seeing no other opinions I have removed those sentences. Hoof Hearted (talk) 13:16, 10 May 2022 (UTC)

Need other eyes

The discussion is Talk:Apex#Apparently_this_is_necessary.... Sorry and thank you. —swpb^{T • go beyond • bad idea} 18:11, 12 July 2022 (UTC)

Policy discussion affecting DABMENTION

There is a policy discussion at Wikipedia_talk:What_Wikipedia_is_not#Recent_correction_to_Simple_Lists that will have a direct impact on all DAB entries made under the MOS:DABMENTION guidance. Interested editors are invited to participate in the meta discussion. Huggums537 (talk) 13:48, 11 July 2022 (UTC)

Specifically, the proposal concerns wording that would forbid disambiguation pages from including entries on titles that are not individually notable, but are mentioned in other articles. —David Eppstein (talk) 17:44, 8 August 2022 (UTC)

RfC on change to MOS:DABMENTION

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Withdrawn by nom. It is clear that consensus for this specific proposal will not develop, and the discussion remaining open appears to be disruptive to efforts to develop an alternative proposal that may have a consensus, per comments below that would prefer a less structured discussion. If any editor believes this close is inappropriate, please revert. BilledMammal (talk) 23:56, 11 August 2022 (UTC)

---

Should MOS:DABMENTION be changed from:

If a topic does not have an article of its own, but is discussed within another article, then a link to that article may be included if it would provide value to the reader.

to

If a topic does not have an article of its own, but has nontrivial coverage within another article, then a link to that article may be included if it would provide value to the reader.

This would mean that for a mention to warrant a disambiguation entry it would require nontrivial coverage, rather than merely a mention. 10:10, 8 August 2022 (UTC)

Compare MOS:DABRED: "Do not create red links to articles that are unlikely ever to be written, or are likely to be removed as insufficiently notable topics." - Butwhatdoiknow (talk) 15:27, 8 August 2022 (UTC)

This RfC is prompted by discussion on a related RfC at WP:NOT. @JoelleJay, Guarapiranga, Thryduulf, PamD, Scope creep, Cullen328, Huggums537, David Eppstein, Certes, and Blue Square Thing: pinging the editors involved in that discussion. 10:10, 8 August 2022 (UTC)

• Support. The current text could be interpreted as permitting the creation of endless lists of non-notable people with only trivial mentions in the target articles, such as can be seen with Terry Pearce and Arthur Harley. This change would address that, while also permitting the removal of the related text at WP:NOTDIRECTORY that should prevent such creations but also prevents otherwise productive changes. BilledMammal (talk) 10:10, 8 August 2022 (UTC)
• Oppose. Neutral. I don't see much difference between "is discussed" and "has nontrivial coverage". Either can be used to exclude Arthur Harley and perhaps Terry Pearce though, as one of the few international umpires without an article, a redirect might be justified. (See AfD). Certes (talk) 10:30, 8 August 2022 (UTC)

  In my experience some editors interpret is discussed to mean any mention, no matter how trivial. This proposed change would clarify that such trivial mentions are not suitable. BilledMammal (talk) 10:36, 8 August 2022 (UTC)

  Changing to Oppose, because it's clear that others do see a difference. The current guideline has worked consistently well for many years. The proposed new wording, as interpreted by others, would introduce pointless hurdles and bureaucratic burdens for those who do the actual work of maintaining dabs, without improving the encyclopedia. Certes (talk) 10:10, 11 August 2022 (UTC)

• Oppose this is unnecessary and looks a bit like moving the goalposts around for the sake of it. It just opens up the scope for arguing about what "non trivial" means at multiple RfD. Blue Square Thing (talk) 10:41, 8 August 2022 (UTC)
• Support scope_creep^Talk 11:06, 8 August 2022 (UTC)

• @Scope creep: any reason for your support? Natg 19 (talk) 22:00, 8 August 2022 (UTC)

• Oppose In practice, you wouldn't often provide navigation for topics with only trivial coverage, but this isn't simple enough to be codified into the guidelines. The approach so far has been to leave it to editor judgement. The discouragement of inappropriate entries was part of the reason why the text says "discussed" (rather than "mentioned", which used to be there until just a few weeks ago), and the main motivator for the bit about value to the reader (added a few years ago).
  I'd be very wary of making inclusion dependent on the state of the target articles: some will have nontrivial coverage that should eventually get trimmed down, while others (many others: Wikipedia is after all a work in progress) don't have much content now but will get expanded in future. The requirement for non-trivial coverage would rule out a large number of uncontroversial entries. Think of an article about a rural municipality with just a mention of the village that is its headquarters: that village will obviously be appropriate on the relevant dab. Or think of the various glossaries: the music tempos listed at Tempo#Basic tempo markings, or the entries in the extensive Glossary of botanical terms are each barely a sentence long, but they likely account for the most important entries on the corresponding dabs, like Andante or Cordate. Uanfala (talk) 11:33, 8 August 2022 (UTC)
• Oppose, unnecessary. The kind of topic that WP:DABMENTION works best for are abstract concepts that have nothing to do with coverage. -- Tavix ^(talk) 11:35, 8 August 2022 (UTC)
• Question. I would support any change in wording if it makes the intention clearer and unambiguous. What is the basis of using the text "nontrivial coverage" here? I see it being used in WP:SIGCOV, WP:BAND, WP:GEOLAND, etc., with respect to coverage in external sources. Has it been used in any other WP page to mean coverage within an article? I would not be comfortable re-using a term for an enwiki article (a tertiary source), that has so far been used for secondary sources. I would prefer using other acceptable terms, which have been used in the context of enwiki articles. I also do not like the existing word "discussed", although I see it more than "a mention". Per BilledMammal, it can be subject to misinterpretation, and articles are not discussions. Jay 💬 11:42, 8 August 2022 (UTC)

  Good point. We wouldn't want editors to misinterpret DABMENTION to mean that every entry must pass WP:N – unless, of course, the related RfC fails, in which case we might be stuck with precisely that interpretation. Certes (talk) 13:47, 8 August 2022 (UTC)

• Oppose based on WP:NNC and WP:WHYN where both together say notability rules like "significant coverage" do not apply to content inside navigational pages such as disambigs and lists. Makes WP:SIGCOV kind of a moot point for stuff in articles, lists, or disambigs, and rightfully so. If we had to make sure every single mention of every single name in every single article were notable, then article writing would be hellishly impossible. Huggums537 (talk) 13:13, 8 August 2022 (UTC)
• Oppose "non-trivial" is less clear than "provides value to the reader". MB 14:26, 8 August 2022 (UTC)
• Oppose per Uanfala, and on the grounds that the change would very likely make wiki-lawyering worse. XOR'easter (talk) 14:30, 8 August 2022 (UTC)
• Oppose as worded. The proposal appears to incorporate Terry Pearce and Arthur Harley as examples of what would be excluded. Nothing currently on those pages should be excluded from a disambiguation page. The listed subjects are there because they are noted within the encyclopedia to be world-class athletes, candidates for national office, or figures without articles from a long list of blue links for similarly-employed subjects. We do not exclude subjuects from lists merely because they do not merit a separate article, and a disambiguation page is, fundamentally, a list. I have no objection to coming up with reasonable guidelines for limiting WP:DABMENTION, but a proposition that merely highlights for deletion a few existing disambiguation pages with existing clearly noteworthy names is unreasonable. BD2412 T 15:44, 8 August 2022 (UTC)
• Oppose changing a clear and objective standard into a vague and subjective one. --R'n'B (call me Russ) 20:20, 8 August 2022 (UTC)
• Comment Asserting that there should be more than a mention doesn't explain a change from "discussed" to "has nontrivial coverage", given that "discussed" is already more than a mention. Largoplazo (talk) 22:49, 8 August 2022 (UTC)
• Oppose - Why? I don't see a problem with the dabs mentioned. Let's look at a list like List_of_mayors_of_Bogotá. Someone named Juan Martín Caicedo Ferrer was mayor between 1990-92. I guess we don't have an article about him, but he's included in the list. If there were someone else named Juan Martín Caicedo Ferrer who happened to be mentioned in another list, why wouldn't we disambiguate them? The question is: might readers search for this person? If so, do we content about them? If so, do we have content about multiple people with the same name? Then disambiguate. I see no need for "nontrivial coverage" for something as purely functional as a dab page. Maintainability is a problem across the project, and not a reason unto itself. — Rhododendrites ^talk \\ 02:59, 9 August 2022 (UTC)
• Question(s). Some people are opposing because they say DABMENTION already requires "nontrivial mentions" through its use of "discussed", which also seemed to be a stance used to argue for the NOT proposal. But others here are saying there isn't or shouldn't be any such restriction, which might also be supported by the language in DABMENTION, particularly (bolding mine) Items appearing within other articles and If the topic is not mentioned in the other article. So which is it? Further questions:

1. Apparently there are 10,029,641 "humans" in Wikidata; are each of these valid DAB candidates?
2. If "discussed" doesn't mean "given nontrivial treatment", what stops the addition of, e.g., private non-notable minor grandchildren of a deposed nobleperson to DABs?
3. What happens if the above names are later removed per BLPNAME, but the section the DAB links to remains intact -- how would we even know to remove the DAB link (is the editor removing the names from the article supposed to check each one to see if it has a DAB entry? Because I have removed a lot of genealogy cruft/royalty fandom without doing such a check...)?
4. Are there multiple editors watching each DAB page to make sure every non-notable addition actually is mentioned in its target, and that the mention is DUE and not promotional?
5. Is removing a mentioned-but-non-notable entry ever justified, and if so, how?
6. Does "discussed" supersede "appearing" and "mentioned" for, say, authors listed in reference sections?
7. What about non-notable people who are mentioned on multiple pages without any single one being "primary" (i.e. people who would not qualify for a redirect)?
8. Or is each DAB item on a non-notable person expected to have an existing redirect that can be used as the link (in which case, this should be stated at DABMENTION)? JoelleJay (talk) 04:47, 9 August 2022 (UTC)

PamD has responded to these below, so just adding a few additional notes. The answer to #2 I think should be "common sense", or (in DABMENTION language) the fact they the entries wouldn't provide value to the reader. #4? There are a few editors who patrol new additions and also sometimes do big cleanups, in which entries not meeting DABMENTION get routinely thrown out; I don't know how extensive the coverage of these is. #5? I'd remove an entry if it's of low encyclopedic significance (like the relatives mentioned in a biography you refer to earlier). In #6, do you mean authors of books cited in a given article? Of course no-one is going to add dab entries for them. As for #8, whether to link via a redirect or not will depend on several factors (see for example this discussion). Uanfala (talk) 10:46, 9 August 2022 (UTC)

• Oppose: The current wording works well. Dab pages help readers to find information (and to find whether or not we have any information on the topic they seek), and help future editors by distinguishing the several existing uses of a name. Generous criteria for inclusion in dab pages increase that helpfulness. (Breaking my month's wikibreak to contribute, not plannng to contribute further).

But because I don't plan to be back, a few quick responses to JoelleJay's questions:

1: No, only those which are mentioned in en.wiki articles

2: Nothing, if they are listed on the page

3: When removing chunks of articles you presumably check for incoming links anyway to avoid leaving a trail of red, formerly blue, links, so would recognise dab pages, redirects, or other links which were pointing to material you are about to delete and could fix accordingly.

4: Well, the dab pages I have created are all on my watch list. I can't speak for other editors. Are there multiple editors watching every page or list? Judging by some long-standing errors I've found and fixed, the answer is no.

5: There may be some edge cases, but I can't see why anyone would want to do so.

6: Not sure what is being asked.

7: Pick one typical page and word dab entry accordingly, or use the exception that allows for more than one blue link in an entry.

8: This might be worth considering: "if they merit a dab page entry, they merit a redirect from a disambiguated title"; but this would need further discussion. Although the aforementioned folk for whom there isn't an obvious single target page would be a problem. In each case we need to think "How would we treat this person if their name was unique?": would we redirect to just one of their films/sports events etc? They should not be made harder to trace just because they share their name.

Now logging off again. PamD 07:14, 9 August 2022 (UTC)

Thank you (and Uanfala) for responding.

1: So you are saying all en.wiki mentions are valid, but others are saying "common sense" applies?

2&5: Apparently there are very divergent opinions as to whether any DAB entry for a mentioned person should ever be added or removed.

3: Removing just some unlinked names rather than a whole section won't cause any broken links, why would anyone check for incoming links in that case? I certainly didn't think anyone would be DABbing any of the non-notable people mentioned in this heaping BLPNAME violation, but apparently every single one would have been a valid entry?!

4. So it sounds like there are no built-in safeguards against SEO spamming or BLPNAME violations or propagation of libelous info in DABs. Redirects at least have standards for inclusion, can be discussed at RfD, and have visible evidence of existing in article space. Redlinks are restricted to subjects that might be notable on their own, and are similarly visible. DABs have...whoever made the page and whoever adds an entry, with no way to tell in the target article that they exist, and no justification for removal other than the target content being deleted.

6. I can think of plenty of reasons someone would want to have their academic paper as a reference in a WP article, and those same reasons would apply to getting one's name into an article title (major promo boost if googling "John Smith"+"Berkeley" gets you a Wikipedia article titled "John Smith" that from the results preview appears to be "about" the researcher at Berkeley; even if you click through and discover it's a DAB page there's still huge points scored from being described among a bunch of "other" notable John Smiths). Not to mention there is a very high probability your DAB blurb will be retained even if your self-citing is reverted.

7. Having multiple blue links in the DAB entry is a nice option, but how do we know they are all the same person if there is no overlap in content in the target articles?

8. Conversely, people with uncommon names should not be harder to trace than those with shared names, nor are common-name non-notable people inherently more deserving of a dedicated blurb in an article titled with their name (which will show up in search results first). JoelleJay (talk) 21:46, 9 August 2022 (UTC)

JoelleJay, I think I won't deprive others of the opportunity to take this up and respond to your specific points. Just a general note. I appreciate your asking questions and engaging with the issues, but I think that if you stopped just thinking about things in the abstract and started doing some practical work with dab pages, you'd find out that most of those issues aren't there. Despite differences of formulation or occasional (and inevitable) disagreements, dab editors will be of the same opinion when it comes to the vast majority of practical cases: I don't think you'd find anyone here defending the hypothetical addition of the dozens of people mentioned in the genealogy you've linked. There aren't any dab-specific safeguards against SEO spamming and the like probably because there has never been the need for them. I won't speculate about why dabs aren't a magnet for SEO spammers (I don't know, maybe they've figured out that name-dropping their client in the middle of a dab page isn't going to influence results on Google?), but this has never to my knowledge been a problem. Yes, you do sometimes get kids (or the odd delusional adult) adding their name to a dab, but these invariably come as IPs and get promptly reverted by recent changes patrollers. Uanfala (talk) 22:34, 9 August 2022 (UTC)

Thanks again for your considered responses. I guess my question re: what you said about norms among DAB editors is: shouldn't guidelines reflect practice? If the vast majority of experienced users would object to (or just never even consider) adding those genealogy names, we should identify why that is and make sure this is something new DAB editors can ascertain from our guidelines, because it certainly isn't clear now. JoelleJay (talk) 04:56, 10 August 2022 (UTC)

This is already in the guidelines (the bit about including a link only if it will be useful to readers). Maybe that could be stated in different terms, but ultimately, I don't think we should expect this guideline to be able to fully capture the whole extent and nuances of existing practice, and conversely, I don't think the guideline should constrict future practice into some arbitrary mould. Proposed rules like "only for non-trivial coverage" or "only via a redirect" are overly simplistic and leave no room for common sense. Yes, they will be appropriate to many situations, but if applied to others, they will make things worse. In my opinion, it's better if we give editors a goal (provide value to readers) and let them figure out how best to get there in each context, than if we prescribed a single method for achieving this goal. Uanfala (talk) 23:48, 10 August 2022 (UTC)

• Oppose wording, support in principle Enough concerns stated about the proposed wording. Still, I think it's worth brainstorming at a non-solution-specific RfC what "is discussed within another article" entails. I often see seemingly trivial fictional characters, obscure band members, random family memebers, etc. listed on DABs. Is this unconditionally supported, or what are the caveats?—Bagumba (talk) 11:21, 9 August 2022 (UTC)
• Alternative proposal:

  If a topic does not have an article of its own, but has a redirect to its name pointing to a section, anchor or entry in another article or list, then that redirect link may be included.

  This would eliminate the problem of non-notable entries becoming orphaned in dab pages when the topic is removed from the target page. Redirects are more likely flagged, discussed and maintained when anchors and list entries are removed or sections renamed. — Guarapiranga ☎ 07:14, 10 August 2022 (UTC)

I think I'd have less of a problem with that - and it benefits from actually saying something concrete. I'd want to see what others say before I threw my entire support behind it as I might have missed an important nuance. Blue Square Thing (talk) 09:23, 10 August 2022 (UTC)

This would overlap with the existing MOS:DABREDIR. —Bagumba (talk) 16:37, 10 August 2022 (UTC)

Overlap as in confirm? Only the following seems out of step with it (emphasis mine):

A redirect should be used to link to a specific section of an article if only that section discusses the disambiguated topic.

But then the examples given are not of redirects, but of piped links. Looks like that needs correcting too. — Guarapiranga ☎ 22:36, 10 August 2022 (UTC)

The entry for Eon (geology) is the example with a redirect. The other piped linked entries are examples of when not to use a piped link, when a redirect is more appropriate. —Bagumba (talk) 08:11, 11 August 2022 (UTC)

That's not what the guideline says, though:

A redirect should be used to link to a specific section of an article if only that section discusses the disambiguated topic. This also suggests that the topic may eventually have its own article. For example:

If instead it said:

• A redirect should be used to link to a specific section of an article, instead of a piped link. For example:

... those examples would make more sense. — Guarapiranga ☎ 22:41, 11 August 2022 (UTC)

I actually find that it is MOS:DABPIPE that is more at odds with this proposal (and with general WP practice):

Apart from the exceptions listed below, piping and redirects should generally not be used on disambiguation pages.

That should be changed too. — Guarapiranga ☎ 23:52, 10 August 2022 (UTC)

I'd support this. JoelleJay (talk) 21:16, 10 August 2022 (UTC)

I think this amounts to WP:INSTRUCTIONCREEP, and would result in makework permissible-but-unnecessary redirect creation. BD2412 T 22:48, 10 August 2022 (UTC)

Interestingly, I thought it is the current policy that is both too prescriptive, in trying to accommodate piped links, and vague, leaving the door open to endless discussion on what constitutes value to the reader, while redirects have much more cut and dry policy and style, and disputed cases are routinely discussed at RfD. — Guarapiranga ☎ 23:24, 10 August 2022 (UTC)

I think you can say that there is a clear body of established practice at RfD, but I don't see the redirect policy as cut and dry at all, as it says almost nothing about which redirects are appropriate and which aren't. Uanfala (talk) 23:53, 10 August 2022 (UTC)

The relevant portion of the WP:RPURPOSE guideline for the reasons to create redirects is equally open-ended:

Sub-topics or other topics which are described or listed within a wider article. (Such redirects are often targeted to a particular section of the article.)

—Bagumba (talk) 04:26, 11 August 2022 (UTC)

And, interestingly, that definition allow for redirects for all the obscure minor descendants of minor nobility about whose potential presence on dab pages someone was concerned, if they are once listed on their ancestor's page: "listed" is a very low bar. PamD 08:51, 11 August 2022 (UTC)

For a redirect? Is it? Why? (if I may ask) I don't see any requirement in WP:TARGET for section redirects to be notable, is there? — Guarapiranga ☎ 22:35, 11 August 2022 (UTC)

True, but at least we have RfD where such things can be discussed. JoelleJay (talk) 21:59, 11 August 2022 (UTC)

Yes: disambiguators could make an end-run around any new obstacles by creating permissible-but-unnecessary redirects. Please don't make us do that. Certes (talk) 10:27, 11 August 2022 (UTC)

There are benefits to using redirects but there are also drawbacks. Above, I've linked to a recent discussion where these questions are picked apart, so I'll give just two examples. Casting a dab entry around a redirect will obscures the relationship with the target article (which may lead to reader confusion), while creating a redirect will be a bad idea in a number of common cases (when the topic is notable, when it's treated in more than one article, etc.). Uanfala (talk) 23:53, 10 August 2022 (UTC)

• Oppose per above (as creator of one of the dab pages). J947 † ^edits 06:28, 11 August 2022 (UTC)

OP's first example

Let's look at the first example the OP offers of a disambiguation page they think should not exist because all of the links are WP:DABMENTION links:

Terry Pearce may refer to:

• Terry Pearce (fl. 1952–1956), New Zealand Test cricket umpire
• Terry Pearce, futsal coach for Australia at the 1992 Paralympic Games for Persons with Mental Handicap
• Terry Pearce, candidate in the 2015 Bracknell Forest Borough Council election, England
• Terry Pearce, Australian competitor in the M60 2000 metres steeplechase at the 2016 World Masters Athletics Championships

For the first one, almost every link on the page is a blue link, so this is not a list of trivial subjects. The listed "Terry Pearce" is cited, and it is uncontestable that they meet the criteria to appear on this list. The likelihood of the name being removed from the list (absent vandalism) is slim. Yes, we could create a Terry Pearce (test cricket umpire) redirect to the page, but for someone looking for this Terry Pearce by searching for "Terry Pearce", the disambiguation page is already as useful. The second Terry Pearce was the head coach of a Paralympic futsal team. The likelihood of the name legitimately being removed from the description of the team is nil. The third Terry Pearce was a candidate who received votes towards a potential election to his national government. It seems highly unlikely that this name will legitimately be removed from the article. The fourth Terry Pearce is a redlinked gold medal winning in a world championship.

Every single one of these could conceivably be searched for in the encyclopedia, and every single one merits inclusion in the articles where they are found, and on the disambiguation page that aggregates these names. Referring to these people as "non-notable people with only trivial mentions in the target articles" is shortsighted and certainly does nothing to serve readers. BD2412 T 23:18, 10 August 2022 (UTC)

Agreed. Don't they therefore merit redirects of their own? Could this debacle be solved by simply creating such redirects and listing them per MOS:DABREDIR? — Guarapiranga ☎ 23:27, 10 August 2022 (UTC)

Whether they merit redirects is, frankly, beyond the scope of this discussion board. Maybe they do, but what would those redirects be, and what would they do beyond what the disambiguation page already does? Terry Pearce (test cricket umpire), Terry Pearce (futsal coach), Terry Pearce (politician), and Terry Pearce (steeplechase rider)? Does it really benefit the encyclopedia to create these if the person searching for "Terry Pearce" can find all four on the existing disambiguation page? Does it benefit anyone to require that such redirects be made, normally an unrelated process, in order to list the name on the disambiguation page? Also, what do we do where there is a person mentioned in multiple articles, such that there is no best target for the redirect? BD2412 T 02:41, 11 August 2022 (UTC)

One benefit of creating disambiguated redirects is that they offer predictable disambiguation, which could show up as suggestions in the search window, making it slightly more accessible than having to navigate a dab page.—Bagumba (talk) 04:42, 11 August 2022 (UTC)

I'll endeavour to asnswer your questions, BD2412 (I don't mean to belabour them):

• Whether they merit redirects is, frankly, beyond the scope of this discussion board.
  Precisely; they are cases for RfD. Under the alternative proposal, if editors agree the redirects are merited, then they can get listed in the dab page. Would there be a case for a dab entry that does not even merit a redirect page?
• Maybe they do, but what would those redirects be, and what would they do beyond what the disambiguation page already does? Terry Pearce (test cricket umpire), Terry Pearce (futsal coach), Terry Pearce (politician), and Terry Pearce (steeplechase rider)?
  Yep, these look fine (per WP:POFR).
• Does it really benefit the encyclopedia to create these if the person searching for "Terry Pearce" can find all four on the existing disambiguation page?
  If the dab page is well maintained, then yes, it's no different. The point of ruling out piped links, in favour of redirects, is tightening the maintenance of non-notable entries in dab pages (which is the concern of those advocating ruling out non-notable entries altogether in the related RfC at WT:NOT).
• Does it benefit anyone to require that such redirects be made, normally an unrelated process, in order to list the name on the disambiguation page?
  Ultimately, it benefits the reader, as an outcome of tighter maintenance of dab pages (and wider coverage too, in case the editors advocating ruling out non-notable dab entries as a solution for tighter maintenance make their case). Ruling out piped links is a compromise between the two.
• Also, what do we do where there is a person mentioned in multiple articles, such that there is no best target for the redirect?
  That's precisely one of the concerns JoelleJay and others have raised about piped links in dab pages. Isn't that a bread and butter issue at RfD?

  — Guarapiranga ☎ 07:31, 11 August 2022 (UTC)

• I have little faith in the "Search" function, so I don't think it particularly matters. If the names are listed on a disambiguation page, we avoid the make-work of making (or thinking about) redirects. Ironically, disambiguation and redirects are my two most engrossing areas of work on Wikipedia. I can tell you that in terms of creating redirects, these are not a priority. BD2412 T 22:40, 11 August 2022 (UTC)

  A few reasons that may warrant the make-work of making (or thinking about) redirects (WP:NOTBROKEN):

  • Redirects can indicate possible future articles (see {{R with possibilities}}).
  • Introducing unnecessary invisible text makes the article more difficult to read in page source form.
  • Non-piped links make better use of the "what links here" tool, making it easier to track how articles are linked and helping with large-scale changes to links.
  • [...] Updating one redirect is far more efficient than updating dozens of piped links. (The Rdcheck tool is extremely useful in such cases for finding which redirects need to be changed after an article is updated.)

  — Guarapiranga ☎ 23:03, 11 August 2022 (UTC)

If you want to make those redirects, you are welcome to do it. We have plenty of disambiguation pages including such redirects as well. BD2412 T 23:47, 11 August 2022 (UTC)

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

DABRED proposed modification

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

---

Closing status is WITHDRAWN as nominator. See comment below. Huggums537 (talk) 17:44, 13 August 2022 (UTC)

MOS:DABRED currently reads: A link to a non-existent article (a "red link") should be included on a disambiguation page only when a linked article (not just other disambiguation pages) also includes that red link. Do not create red links to articles that are unlikely ever to be written, or are likely to be removed as insufficiently notable topics. To find out if any article uses the red link, follow the link, and then use the "What links here" link in the toolbox., and I fully agree with the first and last sentences in this paragraph since they give advice about how redlinks should be linked inside other articles for use in DABS, but the middle sentence is out of place, and has nothing to do with linking redlinks "inside articles" for use in DABS. We already have plenty of guidance such as WP:RED about when to create redlinks to articles, and when not to. So, Do not create red links to articles that are unlikely ever to be written, or are likely to be removed as insufficiently notable topics. is not the place for this kind of guidance, and to be more fully compatible with the rest of the paragraph, it should be replaced with much more relevant guidance that makes more sense for this section; Do not create red links for use in disambiguation pages unless the redlink is also being used in at least one article. So the new text would be: A link to a non-existent article (a "red link") should be included on a disambiguation page only when a linked article (not just other disambiguation pages) also includes that red link. Do not create red links for use in disambiguation pages unless the redlink is also being used in at least one article. To find out if any article uses the red link, follow the link, and then use the "What links here" link in the toolbox.

• Support change as nominator. Huggums537 (talk) 05:44, 13 August 2022 (UTC)
• Oppose. What we have now is fine because there is no harm in re-iterating the salient points of WP:RED, and additionally it's putting the onus of the dab redlink on the editor, and not on the editor of the linked article who had inserted the redlink there. Just because someone added a redlink in some article, whether justified or not, does not give the dab editor the licence to create a redlink at the dab. Oppose the proposed text as well, because now it changes the context from the redlink associated with the article being linked from the dab, to any random article on enwiki. Jay 💬 07:26, 13 August 2022 (UTC)

  How is my wording saying anything different than the first sentence except to add that you should not create the redlink on the DAB yourself unless conditions of previous sentence are met? Huggums537 (talk) 08:28, 13 August 2022 (UTC)

  The current wording is for the article being linked from the dab, the new wording of "at least one article" makes the scope enwiki-wide. I'm fine with Uanfala's suggestion, because it makes the guideline based on policy and not dependent on content of any other article. But as stated by him the current guideline may have come about as a simple forumla to add a red link - add it if the article being linked has it. Jay 💬 16:31, 13 August 2022 (UTC)

  Ok, never mind. I see what you are talking about. I will change the wording to fix that. Huggums537 (talk) 15:59, 13 August 2022 (UTC)

  Looking at it (yet again), I do see what you are talking about, but I think the worry is needless. So what if the scope is enwiki-wide? If the redlink is not correctly associated with the article it links to then it automatically qualifies for deletion. Nothing about my wording says or even suggests that redlinks don't have to be associated with the articles they link to, and the only possible way a redlink would be associated with just some random article enwiki as opposed to the dab topic is from some act of vandalism or something easily reverted. Huggums537 (talk) 16:50, 13 August 2022 (UTC)

• There is a problem with the current guidelines, but I see the solution in the opposite direction. Redlinks are added when you believe the article should eventually be created: that's the essential point of Wikipedia:Red link, and dab pages are no exception. As for the rule to only do that when other articles have the same redlink? This appears to be intended as a shortcut in the thought process: an attempt to shift the judgement calls onto article editors and leaving editors of dab pages with a simple rule that can be followed in a purely mechanical way. But this rule only works some of the time. There's no reason to suppose that notable topics will necessarily have links pointing to them: the majority probably don't (we even have tons of existing notable articles without any incoming links despite people continually working away at the backlog: there are currently over 80,000 of those). Conversely, the fact that a redlink happens to exist does not guarantee anything about the topic's notability. So I'd rather we have the guidelines set the aim of the process ('include redlinks only if notable') and dispense with the additional heuristics that only work part of the time. Uanfala (talk) 11:27, 13 August 2022 (UTC)

  This suggestion makes the problem worse, not better. The problem is now opposite, as you say, except now with this ('include redlinks only if notable') guidance we would have absolutely nothing, not even a simple rule with a mechanical indicator to give us any idea what redlinks are notable because there's no reason to suppose that any redlink is notable or not. We would only have tons of conflict and, endless debate about which redlinks are notable, and most would argue they are not since they are not blue anyway. At least the current way gives us something to go on. Huggums537 (talk) 17:05, 13 August 2022 (UTC)

• Comment: I'm going to close this as withdrawn. My first thought was to just propose the complete removal of the middle sentence, and that is what I should have done in the first place. Huggums537 (talk) 17:38, 13 August 2022 (UTC)

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

Increase visibility of Wiktionary links

A lot of reader/editors seem to expect dictionary definitions on dabs, and end up adding them. I think the main reason for this is that the right-aligned {{Wiktionary}} template is easily overlooked on dabs, which are otherwise very left-heavy, especially on higher resolution displays. So, I propose changing WP:DABDIC and MOS:WTLINK to recommend either 1) a hatnote-style Wiktionary notice (with the existing {{See Wiktionary}} template), or 2) a full-width, single-line version of {{Wiktionary}}, like:

Look up Blah, blah, or blahh in Wiktionary, the free dictionary.

—swpb^{T • go beyond • bad idea} 16:14, 15 August 2022 (UTC)

Support --John Maynard Friedman (talk) 16:31, 15 August 2022 (UTC)

Oppose for two reasons. Firstly, the existing layout with Wikt and ToC right, makes good use of space: it allows more entries to appear above the fold without requiring the reader to scroll down. Secondly, Wikipedia is not a dictionary. A reader seeking a dicdef won't know whether they're about to be disappointed by a dab or by an article, and we don't display the Wiktionary entry prominently in articles, not even dab-like articles such as namelists. For example, even if most visitors to Wills were actually looking for a meaning of Will (as seems likely), we don't have a Wiktionary entry at all on Wills. Certes (talk) 17:17, 15 August 2022 (UTC)

Retired people

If a person has retired from the occupation that made them notable, but are still living, is it useful to mention that they are retired on the disambiguation page? For example, Ramprakash lists Mark Ramprakash as an "English retired cricketer". My thought is that "English cricketer" is sufficient for disambiguation, since that is what he is notable for, regardless of whether he is still doing it. His retirement can be covered in the article itself. Is that sensible? --Jameboy (talk) 16:18, 26 September 2022 (UTC)

• I'm with you on this one. Otherwise, we'd later have to update your example to "English dead cricketer." - Butwhatdoiknow (talk) 05:31, 27 September 2022 (UTC)

Discussion at Wikipedia talk:Organizing disambiguation pages by subject area § RfC: make this page a guideline

 You are invited to join the discussion at Wikipedia talk:Organizing disambiguation pages by subject area § RfC: make this page a guideline. Shhhnotsoloud (talk) 14:50, 4 November 2022 (UTC)

Hatnote explanation in See also section part 2

@Danbloch: I agree that the text should be talking about DAB pages, but the example it cites (Sydney) is an article. Also, the direction to add a hatnote at the top for alternate spellings directly contradicts the third bullet, which says to add alternate spellings within the See also section (at the bottom of the DAB). In my mind, the latter is the best practice for DABs, and was a consensus I thought we reached before I made the edit. If you still think that text belongs, can we clear up the contradiction, reword, and use a different example? Hoof Hearted (talk) 14:51, 7 November 2022 (UTC)

Ah! I see you were still making changes as I was typing this. Thank you! Hoof Hearted (talk) 14:54, 7 November 2022 (UTC)

Sidney (disambiguation) is already listed in Sydney (disambiguation)#See also, which seems like the best place for it. Links which would go in article hatnotes generally go in the See also section instead when linked from a dab. Hatnotes in dabs are for rare cases such as self-references, e.g. dab ARB has a hatnote to WP:ArbCom which wouldn't belong in See also. Certes (talk) 15:25, 7 November 2022 (UTC)

Just to be sure we're all on the same page, the consensus mentioned by Hoof Hearted was based on an incorrect understanding that the text was about article pages, due to the fact that the link in the example (Sydney) should have been Sydney (disambiguation). I've since updated the example and Uanfala has moved the text to a non-obtrusive location at the bottom of the section. But saying that hatnotes in DABs are for rare cases would be a change to the policy. Dan Bloch (talk) 18:25, 7 November 2022 (UTC)

The dab guidelines have had a one-sentence mention of hatnotes for a long time, and that mention only recently got expanded into a full paragraph. My understanding is that the use of such hatnotes is considered a borderline practice that can occasionally be justified by IAR, not something that we should have explicit sanction for in the guidelines. – Uanfala (talk) 10:08, 8 November 2022 (UTC)

This has been a one-sentence paragraph since 2009: When appropriate, place easily confused terms in a hatnote. After the recent corrections this is now a three-sentence paragraph: When appropriate, place easily confused terms or commonly confused alternate spellings in a hatnote instead of a See also section. For example, Sydney (disambiguation) has a hatnote linking to Sidney (disambiguation). There should not be more than a few of these links. But this isn't a change to policy. Also, the last sentence here is meaningless without a clarification. The implied meaning is not more than a few links in an article, but the author probably meant not more than a few links in all of Wikipedia.

Having said that, "Sydney" is an atypical example, and may not be appropriate (along with the "easily confused terms" motivation). Aside from targets in other namespaces like the one Certes points out, I've seen justified uses of this when there are redirects to a DAB, e.g., Wolf (disambiguation), Zionism (disambiguation), Congo (disambiguation). But the policy only talks about easily confused terms. Dan Bloch (talk) 17:36, 8 November 2022 (UTC)

It's hard to know exactly which templates to count, but about a thousand of our 344,000 dabs start with some variant of see also, for or other hatnote. Many of them are self-references, such as WP:BEANS atop Bean (disambiguation). Others fall into groups which should probably be improved systematically, such as Russian place name dabs which use {{see also}} at the end instead of a See Also section (example: Nesterovsky). Certes (talk) 18:13, 8 November 2022 (UTC)

I see you've boldly removed "There should not be more than a few of these links". I agree that the phrasing is imperfect but I think we should replace it by some statement which clarifies that similar titles are normally listed at the bottom, as in our standard example dab Mercury#See also. With that text removed entirely, editors may get the impression that hatnotes should be the norm. Certes (talk) 19:53, 10 November 2022 (UTC)

If I knew what the policy was I would have been happy to clarify it here, but I don't. When is it appropriate to add a {{see also}}? ("Never" would be a great answer if we can agree just remove this.) Dan Bloch (talk) 20:55, 10 November 2022 (UTC)

I can't find a documented guideline, except that there should be a few^{[clarification needed]} hatnotes. We normally use hatnotes for self-references like the ARB example above, so I assume there's quiet consensus for that. Other similar-looking or -sounding terms usually only get a See also entry at the bottom, apart from a vague and undocumented class of exceptions that get a hatnote. Here are some exceptions with the See also, For and *About templates. Certes (talk) 22:03, 10 November 2022 (UTC)

Right, but my point is that this is the document, and if we reach a consensus we can clarify or change the policy here, which I think it needs. I can take a stab at it, but I was hoping to hear from the people more familiar with the policy. Dan Bloch (talk) 20:04, 11 November 2022 (UTC)

It's hard to count them accurately but general practice seems to be that 98% of dabs don't have a hatnote at the top. (Many have a hatnote in the middle, e.g. under Music to say "for artists, see #People"). Certes (talk) 21:15, 11 November 2022 (UTC)

WP:DABMENTION revisited

In the recent discussion at Wikipedia:Articles for deletion/Terry Pearce (2nd nomination) (closed as no consensus), User:JoelleJay asserted that:

There are also thousands of articles listing all winners of extremely minor honors--like "halls of fame" of <40,000 pop. counties, containing people with distinctions like "co-owner of the local Domino's franchise" and "principal of the local elementary school"; how are these in any way equivalent to Olympians in meriting DAB entries?

Although I am skeptical that there are thousands of such articles, I do think that it is reasonable to refine WP:DABMENTION to clearly include subjects like world-class athletes/coaches found in lists of participants in multinational sporting events, and competitive candidates in national elections, while excluding high school officials and owners of unremarkable restaurants and similar local businesses. I'm sure if we put our heads together we can come up with some additional obvious cases for inclusion or exclusion, and come up with a reasonable guideline. BD2412 T 06:02, 6 November 2022 (UTC)

I would suggest holding this discussion at WP:VPI, as it intersects with WP:NOT. BilledMammal (talk) 06:20, 6 November 2022 (UTC)

Agreed, since WP:NOT contains the contradictory and universally ignored policy statement that all such entries must be notable. Certes (talk) 12:18, 6 November 2022 (UTC)

The statement is nonsensical. That would mean that we could never list a song on a disambiguation page if the song did not have its own article, even if it was prominently featured on a highly notable album. It would mean we could not list "John Smith, the protagonist played by Brad Pitt in Mr. & Mrs. Smith" at John Smith. There are too many things wrong with it to be functional. BD2412 T 02:35, 7 November 2022 (UTC)

On the contrary, I'd expect discussions about dab guidelines to happen on the talk page of those dab guidelines. An incidental mention of dabs on an unrelated policy page isn't enough, in my opinion, to shift the focus of such discussions. – Uanfala (talk) 10:21, 8 November 2022 (UTC)

Sadly, someone is going to point out that the four words which were inserted quietly into WP:NOT are Policy and thus trump the mere guideline that we've carefully worked out through years of experience. It would be better to make them consistent, and better still for WP:NOT either to refer the reader to the guideline or to remain silent on the issue. Certes (talk) 11:14, 8 November 2022 (UTC)

Are these really common? That hasn't been my impression, and I've felt like the Terry Pearce AfDs and the intervening discussion have mostly been a waste of editors' time as that dab is a complete outlier (it got created as the result of an RfD: an occasion where an unusually high level of editor attention gets drawn to the meanings and ambiguities of a given search term). I've been working on dabs for years, and I don't think I've ever seen any large scale problems with people adding entries that shouldn't be there. Much, much bigger than that has been the systemic problem of people neglecting to add entries that should be there. – Uanfala (talk) 10:21, 8 November 2022 (UTC)

I have fixed the problem by adding a statement at WP:DABMENTION that "Such entries are notable for purposes of inclusion in a disambiguation page". BD2412 T 16:20, 14 November 2022 (UTC)

Thank you. If WP:NOT reuses the term "notable" to mean "eligible for a dab entry", then our existing consensus on that threshold for inclusion must logically be the definition of "notable" for these purposes. Certes (talk) 16:41, 14 November 2022 (UTC)

Quarter quad

FYI

 – Pointer to relevant discussion elsewhere.

Please see Talk:QQ (disambiguation)#Quarter quad. --Redrose64 🦌 (talk) 20:35, 1 January 2023 (UTC)

Monte Grande

Wasn't sure how to handle an addition to Monte Grande (disambiguation) with 'Montegrande' in the title, so I added it at the end, because the spelling was different from every other entry. Can someone have a look, and adjust as needed? Thanks, Mathglot (talk) 21:27, 4 March 2023 (UTC)

The main issue may be that Montegrande is a redlink. Either Montegrande (archaeological site) is its primary topic, in which case we should move that page to the base name (and make its hatnote link to the dab), or it should redirect to the dab, in which case we can legitimately include meanings of "Montegrande" with equal status to the "Monte Grande" entries. I'm not sure whether WP:SMALLDIFFS applies here. Certes (talk) 22:45, 4 March 2023 (UTC)

That question may interact with the next section below, regarding an Italian Bronze Age site with the same name (with space: Monte Grande) for which no en-wiki article yet exists. Mathglot (talk) 22:57, 4 March 2023 (UTC)

Not sure if this helps, but one of the terms used in English sources to refer to the Peruvian dig site is Huaca Montegrande, currently a redirect. Maybe renaming the article to that title, and making the current title a redirect to it, would be an improvement? The problem is, that "Huaca Montegrande", while used in English, doesn't seem to be the prevailing name for it in English, although that's still impressionistic on my part. Mathglot (talk) 23:01, 4 March 2023 (UTC)

A search in books since 2000 shows that 'Montegrande' is used almost exclusively to refer to a ravine, or a town, near Vicuña, Chile: see es:Montegrande. Mathglot (talk) 23:12, 4 March 2023 (UTC)

I was getting a municipality in Argentina also, which is why I decided it wasn't the main topic. "Monte grande" just means a big hill so there are probably dozens of others given the prevalence of Spanish. Apart from that input, I am fine with whatever people decide, but it's not a trivial question, as apparently the existence of this site was recently discovered and is rewriting pre-Incan history of the region, so the article is likely to expand considerably.Elinruby (talk) 04:44, 5 March 2023 (UTC)

DABRED with interwiki involvement

(edit conflict) In looking into the 'Monte Grande' situation above, I ran into Castelluccio culture, whose "See also" section had a red link to Monte Grande (Palma di Montechiaro) (with two in-links). I upgraded that red link to an interlanguage link, as the article it:Sito archeologico di Monte Grande exists on Italian Wikipedia, and is about an archaeological site in Sicily.

This led me to this question: the Italian article is well worth a translation to en-wiki, and I'm wondering if our Monte Grande (disambiguation) page should include an entry about the Sicilian site in some form, perhaps as an {{interlanguage link}}. (There is even another wrinkle, in that the literal translation of the Italian page would be "Monte Grande archaeological site", which is very similar to the existing en-wiki article about the Peruvian "Montegrande (archaeological site)", so ultimately we might need to change the parenthetical part in the former to '(Italy)' and in the latter to '(Peru)'; but I'm getting ahead of myself.)

To be specific: should we include the interlanguage link {{ill|Monte Grande archaeological site (Italy)|it|Sito archeologico di Monte Grande}} to the dab page Monte Grande (disambiguation), perhaps like this:

• Monte Grande archaeological site (Italy), a Bronze Age site in Sicily

It might encourage someone to translate the Italian article, which would be an improvement to en-wiki to fill a gap in our coverage. Thanks, Mathglot (talk) 22:53, 4 March 2023 (UTC)

Agreed but I have nothing useful to contribute. Don't do Italian. Possibly could at some later point translate from French or Spanish if such an article exists.Elinruby (talk) 04:49, 5 March 2023 (UTC)

I also agree that it's reasonable.  — SMcCandlish ☏ ¢ 😼  06:09, 11 March 2023 (UTC)

What are certain partial title matches?

MOS:DABSEEALSO gives some examples of what entries are appropriate in the See also section of disambiguation pages, including this: Certain partial title matches. What are those? WP:PTM is pretty clear that we should not include partial title matches. I worry that some editors have taken this sentence as permission to stuff See also sections with PTMs that would otherwise not be welcome on disambiguation pages. See 42, 99, 100 (disambiguation), 147.

I found this discussion from 2017 inconclusive. Barnards.tar.gz (talk) 19:26, 10 March 2023 (UTC)

Use judgement. If there's a good chance that a reader might be looking for that entry at this DAB page, then include it; if there's not, then don't.  — SMcCandlish ☏ ¢ 😼  06:10, 11 March 2023 (UTC)

Linking to DAB pages within a table

Reniform (disambiguation) appears to have a primary topic of the leaf shape, meaning that Reniform should redirect to Glossary of leaf morphology#reniform. However, this would redirect to an entry deep into a table, far from any potential hatnotes. How exactly would one go about adding a link to Reniform (disambiguation) in the Glossary of leaf morphology page in this case? A hatnote, as is usually done for links to DAB pages, seems like it wouldn't be appropriate, since none would be visible for a reader who just got redirected there. A note in the table doesn't seem appropriate either.

The easiest solution seems to make Reniform into the disambiguation page instead of obiding by WP:PTOPIC – and that's what's currently done as a temporary solution – but is there a better way? Randi Moth (talk) 16:37, 14 December 2022 (UTC)

I came across something similar recently with a TV episode redirecting to a table cell created by templates in the article for its series. The alternative meaning was a barely notable section so I left it without a hatnote, but similar problems may occur elsewhere. Certes (talk) 16:48, 14 December 2022 (UTC)

It happens every time that a redirect points to a section more than one screenful away from the top of the article: no sign of the "redirected" hatnote is visible to the reader. PamD 23:25, 14 December 2022 (UTC)

The (Redirected from Other page) message will be off the top of the screen, but there can be a {{redirect}} hatnote at the top of the section saying "Other page" redirects here. For the foo, see Bar. Real examples: Airside, Army history, Esca. Certes (talk) 00:01, 15 December 2022 (UTC)

Ahh, of course, sorry. PamD 19:38, 15 December 2022 (UTC)

As a side question, does this exact "temporary solution" fall under WP:IAR? This isn't that strong of a WP:PTOPIC – Reniform stigma/Reniform spot appears to have similar usage to the leaf shape and is also a reasonable target for the DAB – and a DAB page is more helpful to a reader that is not looking for the leaf shape (as there is no way to make the hatnote immediately visible in this case) while not impeding anyone that is by much.
I'll change to a {{Redirect}} at the top of the section for now since DABing Reniform was reverted, but the question for a better alternative in the middle of the table still stands. Randi Moth (talk) 15:22, 15 December 2022 (UTC)

For this particular case, agreement that there is no primary topic would make the problem go away, but the best solution for redirects into tables or deep anchors is still worth discussing. I've experimented with shoe-horning hatnotes into tables, but they aren't really designed for it and the results aren't pretty. Lithopsian (talk) 15:48, 15 December 2022 (UTC)

@Lithopsian: Using {{ghat}} may look better (developed for putting hatnotes inside glossary entries, a similar use case.  — SMcCandlish ☏ ¢ 😼  06:17, 11 March 2023 (UTC)

It's important that we give readers some sort of route from wherever Reniform takes them to other meanings of "Reniform" mentioned in Wikipedia, but I've no concrete suggestions for how best to do that. A dab per IAR seems attractive because the primary meaning is "being kidney shaped", which (quite correctly) isn't a topic covered in Wikipedia, rather like Large. Certes (talk) 15:59, 15 December 2022 (UTC)

I don't think there's a one-size-fits-all solution, but in general, if the supposed primary topic is just an entry in the middle of a table, then that's a very strong signal that there may not be a primary topic after all. And even if there is a primary topic, keeping the dab page at the base title may still be better (as was done with Andante). In the case of Reniform, I don't actually see a primary topic, so I've restored the dab page (with further explanation at User talk:Randi Moth#Reniform). – Uanfala (talk) 16:42, 15 December 2022 (UTC)

I agree with all of that, and would add that in a case where the table entry really, really is the primary topic, that's a good indication that it deserves its own article (if there are enough sources to prove it's the primary topic, there are enough sources to pass WP:N).  — SMcCandlish ☏ ¢ 😼  06:17, 11 March 2023 (UTC)

Listing people on disambiguation pages

@Bagumba: Please see Wikipedia talk:Manual of Style/Disambiguation pages/Archive 43#Listing people on disambiguation pages . The whole point of this thread was to remove the provision "sections such as People with the surname Xxxx or People with the given name Xxxx below the main disambiguation list". That was the what the thread was for. After significant discussion the consensus was to change the wording. We don't need to re-run the arguments.

You have reverted this change ([11]) with a rationale I don't understand: "seeing consensus to outright remove "People with the surname Xxxx", would cause a lot of unnecessary existing churn". Consensus was achieved: it is not your place to revert it without discussion. Shhhnotsoloud (talk) 19:46, 6 December 2022 (UTC)

I had made a WP:DUMMY edit afterwards;[12] the edit summary should have read Not seeing consensus to outright remove "People with the surname Xxxx", would cause a lot of unnecessary existing churn Sorry, but I don't agree with your take on consensus for a proposal which you also initiated. An independent closer would have been less controversial. Perhaps a new RfC with clear "support" and "oppose" !votes can resolve this. —Bagumba (talk) 00:33, 7 December 2022 (UTC)

@Bagumba: Perhaps it would; you're welcome to try. In the meantime your edit reversion is out of order. I did assess consensus on a proposal I initiated and no-one disagreed in that thread, including you. If you want to change the wording, please discuss it here, as I did. In the meantime I have restored the change. Shhhnotsoloud (talk) 13:09, 11 December 2022 (UTC)

...no-one disagreed in that thread, including you...: For the record, I didn't agree either, nor even participated. So I'm somewhat independent on this topic.—Bagumba (talk) 03:01, 13 December 2022 (UTC)

@Bkonrad, JHunterJ, Uanfala, Ivanvector, PamD, Thryduulf, and BD2412: Notifying all the previous thread's participants. In the event there remains objections to removal of "People with the [name]" header guidance,[13] an option is to re-open the discussion and get an independent close.—Bagumba (talk) 03:01, 13 December 2022 (UTC)

Rereading that discussion, there was a clear consensus in my view that short* lists of people should be included on disambiguation pages and a rough consensus that both formats are acceptable, and no objections to the suggestion that pages should not be changed between the two formats just because they use one and not the other.

*There was no consensus on a definition of "short", although the limited discussion suggested that the limit is somewhere in the 12-30 entries range. Thryduulf (talk) 12:02, 13 December 2022 (UTC)

I agree Thryduulf's review of the evident consensus, though I still disagree with it. Dab pages are meant to be a solution to the technical problem that the software can't handle multiple topics have exactly the same title. Over time through decisions like this they've evolved instead into a manually-curated keyword search, much like Yahoo! was in the 1990s. If that's what we want them to be then we ought to just program a bot to crawl pages and spit out results. But I'm getting off-topic again, Thryduulf's read of that discussion is correct and I don't see a need to revisit it. Ivanvector (^Talk/_Edits) 21:50, 13 December 2022 (UTC)

Dab pages are meant to be a solution... that may have been it, but only in a parallel Wikipedia where redirects haven't been invented. – Uanfala (talk) 15:01, 14 December 2022 (UTC)

Redirects solve the problem of a topic with multiple titles. Dabs solve the different problem of a title with multiple topics. The problems are related and sometimes interact, requiring both solutions: the many meanings of lift include lift (elevator). Certes (talk) 16:53, 14 December 2022 (UTC)

The slippery slope of keyword search should be handled by WP:PTM, but human names are so commonly used mononymously that they present a legitimate issue of ambiguity. --Joy [shallot] (talk) 19:14, 19 December 2022 (UTC)

The consensus was that short lists could (not should) be included on disambiguation pages, because an editor might not feel like doing the work to create the proper list article. A short list could also be split to their own list-article surname page, and any such split should not be undone, because that what should happen: non-dab lists shouldn't be on dabs. -- JHunterJ (talk) 12:55, 19 December 2022 (UTC)

The consensus I read from the linked discussion is that short lists of names are lists that belong on disambiguation pages, and as such are not "non-dab lists". My personal view is that unless the dab page is so long that it needs splitting, and/or the list of names is so long that it overwhelms the other entries, it is significantly more beneficial for readers to have a single disambiguation page listing both people and other topics. Thryduulf (talk) 18:51, 19 December 2022 (UTC)

It wasn't. It's a list of non-dab things, and for expediency when "short enough" was permitted to squat on a dab page until any editor decided to take the few steps to place it correctly. Surname lists are valid wikilink targets, no matter how short. It is helpful for readers to have a single disambiguation page listing both people and other topics that are ambiguous with the title (which most surname-holders are not), but it is not helpful to readers to have to go to a disambiguation page when they seek a surname list article. -- JHunterJ (talk) 20:40, 20 December 2022 (UTC)

To take a typical example: Anne Panther is, I presume, commonly referred to as "Panther", so has some defence against eviction as a PTM. But, if she's going to squat on dab Panther, she needs to abide by the house rules such as WP:DABENTRY and not bring her refs, surname etymology and other unwelcome baggage with her. Certes (talk) 22:57, 20 December 2022 (UTC)

How do either of these arbitrary rules benefit readers? They strike me as just making it harder for people to find the information they are looking for, which is the exact opposite of the purpose of disambiguation pages. Thryduulf (talk) 10:50, 21 December 2022 (UTC)

It's the opposite of the purpose of Wikipedia, which is why we have surname pages. The traditional role of dabs is to aid navigation rather than to provide encyclopedic information. Consensus can change on that but the impact, good or bad, would be much wider than just surnames. Certes (talk) 18:15, 21 December 2022 (UTC)

• As I've been pinged above ... If we have any sourced content about a name (derivation, distribution, etc) then of course we need a separate page for it (was there any suggestion that such info on the surname "Panther" should be included on the dab page, or was that just a hypothetical example?). But otherwise, I reiterate what I said two years ago in the thread mentioned above:

The reader does not care whether the page they are looking at is a dab page or a surname page: they want to find their chosen topic. Surname entries for people are important, as many readers will have a reference to "Bloggs's work on the subject" or similar, and want to find a person by their surname. If that surname has perhaps 2 meanings, with articles, as a common noun and is the surname of 3 notable people, a dab page including those 5 entries is best for the reader, even if 3 of them are PTMs. It is less helpful if they find a page with 2 entries plus a link to follow to a surname page with 3 entries. If the surname list goes above ... well I'd think perhaps a dozen entries ... or if there is sourced encyclopedic content about the surname itself, then we need a surname page, linked from the dab page. For smaller numbers, help the reader by minimising their clicks. PamD 5:36 pm, 23 December 2020

I think it is more helpful to the reader, and more consistent with what I believe to be (or have been?) our MOS, to include a "People with the surname Xyz" page as a section at the bottom of the Xyz dab page, after "Other uses" but before "See also". It highlights that these are not standard dab page entries but are a listing which the reader may find useful. PamD 14:47, 21 December 2022 (UTC)

PamD 14:47, 21 December 2022 (UTC)

I concur with PamD.  — SMcCandlish ☏ ¢ 😼  06:33, 11 March 2023 (UTC)

I’m new to the finer points of disambiguation policy, so please can you help me understand… If a reader is searching for a person because all they have is a surname, then surely that’s good evidence that the person is commonly referred to solely by their surname, and hence entries for that person on a dab page for that surname would not fall foul of the PTM rule? Add a link only if the article's subject (or the relevant subtopic thereof) could plausibly be referred to by essentially the same name as the disambiguated term in a sufficiently generic context seems to me to allow such people to appear on disambiguation pages. And so I think what you’re saying is an interpretation of existing policy rather than a suggestion that any change or exception to policy is needed? Barnards.tar.gz (talk) 08:28, 11 March 2023 (UTC)

"I encountered one case, thus such cases must be common" is fallacious, though.  — SMcCandlish ☏ ¢ 😼  08:39, 11 March 2023 (UTC)

True, but I think reality bears out that people are in fact commonly referred to by only their surname. Barnards.tar.gz (talk) 09:01, 11 March 2023 (UTC)

People are usually identified by their full name initially and then subsequently referred to by their surname since that's more important part, making it much easier to forget their given name. It's far more likely people search for surnames because that's all they can remember. JoelleJay (talk) 17:52, 11 March 2023 (UTC)

@Barnards.tar.gz I think there's a distinction (perhaps a spectrum) between people like Gandhi, Lincoln, Shakespeare, who are indeed commonly referred to by surname alone, and anyone who may sometimes be referred to, in the text our reader has just read off-wiki, by surname only as "recent work by Bloggs showed ... " or "McGonagall's classic guitar riffs", although they're generally known as Jane Bloggs or Bill McGonagall. PamD 17:56, 11 March 2023 (UTC)

Confusing example at MOS:DABREDIR

The "Jim Cary" example here complicates matters unnecessarily. The entry under discussion is Jim/James Carrey. The point being made depends on whether he is called "James Carrey" in the lead of his article, and nothing to do with the variant surname Cary (the full lead of the dab page is "James (or Jim) Carey, Cary, or Carrey may refer to:" but is quoted as "James Cary may refer to:"). Can we find a clearer example to offer our readers? (Fyunck(click) and I studied this section recently in connection with the entry at Dere for Laslo Djere). PamD 07:11, 29 April 2023 (UTC)

And per the MOS example I changed the Laslo Dere entry at Dere to "Laslo Đere or [[Laslo Djere]] (born 1995), Serbian tennis player" . It looks like it fits the footnote example well, but I guess I could be reading it incorrectly. Fyunck(click) (talk) 07:17, 29 April 2023 (UTC)

I agree that the multiple spellings of Cary/Carey/Carrey adds complexity that dilutes the clarity of point being made. Perhaps Jimmy Stewart on Jimmy Stewart (disambiguation) would be a clearer example for this section. older ≠ wiser 11:11, 29 April 2023 (UTC)

Agreed, and thank you for finding a clearer example. Certes (talk) 12:01, 29 April 2023 (UTC)

The problem with using the redirect Jimmy Stewart is that the example should illustrate (like James Carrey does) MOS:DABREDIR's the redirect could serve as an alternative name for the target article, meaning an alternative term that is already in the article's lead section. (emphasis added) However for Stewart, the common hypocorism "Jimmy" really shouldn't be in the lead per MOS:QUOTENAME: If a person is known by a nickname used in lieu of or in addition to a given name, and it is not a common hypocorism of one of their names, or a professional alias, it is usually presented between double quotation marks following the last given name or initial. (emphasis added) —Bagumba (talk) 14:52, 29 April 2023 (UTC)

This seems to be getting in to some very tall weeds. Jimmy is mentioned in the article (regardless of whether it is a hair-splitting common hypocorism or something else). The actor was really far more commonly known as "Jimmy" even if his formal credits and descriptions in formal reference works use "James". I'm open to other examples, but I really don't see how MOS:QUOTENAME has any relevance here. older ≠ wiser 15:04, 29 April 2023 (UTC)

My point is that "Jimmy" really shouldn't be quoted in the lead (MOS:QUOTENAME), and if it wasn't, it wouldn't be a clear example of MOS:DABREDIR, which asks that "Jimmy" actually be in the lead. Likewise, I'm open to other examples. Best. —Bagumba (talk) 15:10, 29 April 2023 (UTC)

I see. I suppose it is reasonable for various guidance pages to not conflict although I'm not sure how rigorously MOS:QUOTENAME is followed (and for that matter, the relevant portion of MOS:DABREDIR is prefaced by Linking to a redirect can also be helpful -- emphasis added -- indicating the guidance is flexible)

Perhaps the entry for George Raymond Wagner aka Gorgeous George on George Wagner might work? older ≠ wiser 16:45, 29 April 2023 (UTC)

If so, the dab entry at George Wagner would need to be tweaked to George Raymond Wagner or Gorgeous George (1915–1963), American professional wrestler, aka "Gorgeous George" to be consistent with the current MOS. —Bagumba (talk) 17:59, 29 April 2023 (UTC)

The lead of Jim Carrey contains James Eugene Carrey and the lead of James Stewart contains James Maitland "Jimmy" Stewart. Neither literally contains the redirect title (James Carrey or Jimmy Stewart) as a substring, but they're both close enough to be there in spirit. Examples which fit the bill to the letter seem very rare. The last link on Carlos Mendoza may qualify. Certes (talk) 16:02, 29 April 2023 (UTC)

NOTOC

Tangentially, a different TOC behavior in the Vector 2022 skin that I find a little more of an issue -- if you place the __NOTOC__ magic word on the page, it suppresses display in left-hand pane. Even with relatively short page, I often look first to the TOC for the section I am looking for rather than scan through the page. It is somewhat discombobulating to find the TOC missing. I'm not really sure there is reason to use __NOTOC__ on any disambiguation pages (or perhaps any pages for that matter). older ≠ wiser 16:00, 16 May 2023 (UTC)

You're right that NOTOC should never be used on dabs, that's long been the case. I hope you don't mind me splitting this off, since it is, as you say, tangential. —swpb^{T • beyond • mutual} 16:08, 16 May 2023 (UTC)

Table of Contents behavior in Vector 2022

The default Vector 2022 ToC behavior—expanding an L2 section expands all levels of subsections (L3, L4, etc.) at once—is IMO detrimental to dab page navigation, especially on long dabs. I started a thread (now archived) on this at MediaWiki when V22 was implemented: Could we default to (or at least allow) default collapsing of level 3+ headers in TOCs?

I'm pushing for a new magic word to allow ToCs to be expanded one level at a time (see phabricator ticket). I'm thinking this magic word could be added to the dab page templates (with an override if desired) to make this the default behavior on dab pages.

The workings of developers are a bit of a mystery to me, but I think some expressions of support here (maybe a consensus to use the magic word?) might go some way to boosting the priority of the tech work. —swpb^{T • beyond • mutual} 15:18, 16 May 2023 (UTC)

I actually like that behavior. Why force extra clicks to see each subheading separately? There are very few cases where there are so many subheadings as to cause a problem (and perhaps a reorganization might help in cases where there are too many subheadings). The example given of Star (disambiguation) doesn't appear problematic to me. older ≠ wiser 15:30, 16 May 2023 (UTC)

Try looking at it from the perspective of someone looking for Star (TV series). I know it will be under "Arts and entertainment", so I expand that. Now, I don't need to see that the L3 section "Music" has L4 sections within it—that just makes for more reading before I spot that there's a "Television" section. And if I did want something in Music, there's no reason for an extra click to expand "Music" in the TOC—clicking "Music" will both take me to the section (where I can see its subheaders), and will expand it in the TOC. In this case, there are only two L4 headings, but some dabs have many more—and in the case of dabs with tons of entries, flattening the section scheme (the reorg I think you're describing) is often counterproductive to navigation. There's a reason almost all computer menus work this way. —swpb^{T • beyond • mutual} 15:39, 16 May 2023 (UTC)

I can see the Television section pretty clearly. There is a lot of 'stuff' on every disambiguation page that is mostly irrelevant to any particular reader. I'm not sure the TOC is comparable to a typical menu. It is a somewhat different sort of navigational device. It is not a menu of different function or navigation to different pages, it is a grouping of entries on the same page. With the old style of Vector (as well as with paper-based TOCs), the headings at all levels are all expanded by default. I wouldn't object to an enhancement to enable something similar to the limit=n parameter in the TOC templates, but I wouldn't want that to be the default. I guess I just don't see this as being a significant problem for most readers or for most pages. older ≠ wiser 15:54, 16 May 2023 (UTC)

I don't see dab ToCs as being different from other menus in any way that would justify an "expand all" default, and I think the new ToC appearance (no numbering, very slight indentation) makes it much harder to visually track header levels than in the old Vector. The magic word would only have an effect on pages that have L4's or below; on flatter dabs, it would have no effect at all: expanding an L2 shows L3's, and that's as far as it goes. —swpb^{T • beyond • mutual} 16:07, 16 May 2023 (UTC)

I find the indentation sufficient, but it could perhaps be enhanced. However, given the often convoluted and idiosyncratic manner in which items can be grouped on a dab page, I find it advantageous to be able to see all of the subheadings in a section at a glance. Otherwise, I might expect to find something under one subheading, but someone else may have put it under something else (these sort of cases are not as uncommon as you might think, especially for human name dabs or for listings of organizations -- the categories are not always clear-cut). I would much prefer to be able to see the organizational framework at a glance rather than have to open each subsection separately. older ≠ wiser 16:22, 16 May 2023 (UTC)

Note, I don't look at phab tickets much, but it seems https://phabricator.wikimedia.org/T317818 is applicable for this (more so than T333017 linked above). Update: it seems T317818 is the original ticket that discusses several possible enhancements and that T333017 was spun off as a more specific sub-task. older ≠ wiser 15:48, 17 May 2023 (UTC)

Correct, T317818 is the parent. Whether this falls under T333017 depends how the developers want to interpret that ticket, but it seemed like the place to start. —swpb^{T • beyond • mutual} 17:47, 17 May 2023 (UTC)

Wikipedia_talk:What_Wikipedia_is_not#Proposed_variation_to_WP:NOTDIRECTORY_(revisiting_simple_lists) has an RFC

Wikipedia_talk:What_Wikipedia_is_not#Proposed_variation_to_WP:NOTDIRECTORY_(revisiting_simple_lists) has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Huggums537 (talk) 18:36, 2 June 2023 (UTC)

MOS:DABMENTION

To my mind, this section is out of place in a style guide. A Style guide should tell us how to format DAB links and pages… not when to create them. I am not proposing that we change the guidance, just suggesting that the proper place for it would be at WP:DAB. Thoughts? Blueboar (talk) 21:35, 3 June 2023 (UTC)

A large part of MOS:DABMENTION is about how to present entries which are mentioned in other articles. That does belong in the MOS. That is, MOS:DABMENTION is predicated on there being something that can be disambiguated. It actually does not provide much in the way of guidance about whether any particular mention should or should not be included. older ≠ wiser 02:20, 4 June 2023 (UTC)

Meh… The opening 2 sentences (“If a topic does not have an article of its own, but is discussed within another article, then a link to that article may be included if it would provide value to the reader. Such entries may be notable for purposes of inclusion in a disambiguation page.”) discuss when to include a DAB link. I agree that the rest (beginning with “In this case, the link…”) shifts to how to do so. Blueboar (talk) 14:02, 4 June 2023 (UTC)

Most of the other subsections of Wikipedia:Manual of Style/Disambiguation pages#Specific entry types have a similar formulation -- If condition XXXXX applies, then the entry should look like FOOBAR. In a few cases, such as MOS:DABACRO there is a corresponding WP:DABABBREV in the main guideline. And the section MOS:DABNOENTRY is all about which entries should not be created, although that corresponds to WP:DABNOT in the main guideline.

Perhaps some refactoring is in order. The last major overhaul was from 2010 led largely by Kotniski, who at the time seemed more or less impervious to the resultant criticisms and was able to keep the updates moving along.

For example, why does the section WP:DABSTYLE even exist on the main guideline when there is a separate WP:MOSDAB? And there are several ancillary supporting spin-offs such as Wikipedia:Disambiguation dos and don'ts, Wikipedia:Long dab dos and don'ts, even a separate subpage of the MOS Wikipedia:Manual of Style/Organizing disambiguation pages by subject area. older ≠ wiser 16:30, 4 June 2023 (UTC)

Yup… Again, I am not proposing we change the guidance, but I do think we could reorganize it. Blueboar (talk) 17:57, 4 June 2023 (UTC)

I think that a separate explanatory page would be useful, and that we have sufficient experience in these matters to delineate some broad categories of WP:DABMENTION topics that should by default be included on a disambiguation page. I would include on such a list (subject to inclusion in an appropriate article based on confirmation in reliable sources):

• Names of athletes and coaches who have participated in world championship and national championship-level sports.
• Names of characters appearing in a literary work, film, or television series, with sufficient prominence to merit mention by name in the plot summary.
• Names of actors who have played credited roles in theatrically released films.
• Names of military personnel for whom vessels have been designated.
• Names of persons for whom settlements or populated places are named.
• Names of persons for whom NHRP-listed buildings are named.
• Names of flag officers in military forces.
• Names of major-party candidates and second-place candidates coming ahead of major-party candidates in elections for national offices.
• Names of persons who have received a national award or honor for achievement in their field.

This is not at all intended to be an exclusive list, but I think these represent a workable baseline for discussion. BD2412 T 02:13, 6 June 2023 (UTC)

Whatever this discussion leads to, this is a fantastic list that should absolutely find a home somewhere, ideally at the guideline level. —swpb^{T • beyond • mutual} 16:59, 6 June 2023 (UTC)

I'm not sure if we even need to go into this much detail, since some more general guidance (e.g. "People who are the namesake of an article", "People involved in a more than incidental manner in an event with an article", "People with significant roles in organizations with articles") with a handful of the above examples underneath would convey the gist of it without devoting time to thinking of a potentially limitless scenarios where DABMENTION is met. -- Patar knight - ^chat/_{contributions} 22:24, 6 June 2023 (UTC)

If there are broader descriptions that encompass these items, I would welcome that. Namesakes for an article subject is a good one. BD2412 T 23:15, 16 June 2023 (UTC)

There is a diverse but related discussion at WT:NOT#Proposed variation to WP:NOTDIRECTORY (revisiting simple lists). A sentence added to WP:NOT nine years ago is being interpreted as limiting dab entries to topics which have entire articles of their own. As WP:NOT is a policy, that interpretation would render most of the WP:DABMENTION guideline moot by banning all entries without their own entire article. Certes (talk) 09:53, 6 June 2023 (UTC)

@Certes That's an interesting list, but of course only includes people. There are plenty of other dab page entries, whose inclusion can also be argued about. My head is spinning with the various current related discussions about DABMENTION, NOTDIRECTORY, and so on.

As I see it, disambiguation pages, redirects and hatnotes need to be considered together. They are the navigational aids which help the reader who wants to learn about "X" to find information on it in the encyclopedia, even if it is not in an article called "X". The decisions should be something like this:

1: Here is a word or phrase which a reader might use to look for topic X on which the encyclopedia has information, but not at that title (it's in article Y). It may be a standalone article, or a section of an article, or a short mention which will provide the reader with some information, better than nothing. This word or phrase may be an alternative form of someone's name (extra middle name etc), or an alternative name (before or after marriage, or many other reasons); or the title of a book, album, painting, etc, mentioned in the creator's article but without its own article; or a place within a larger place; or an abbreviation or short form of a title (omitting "HMS" or "River", perhaps); or a very likely variant spelling, or many other things.

2: Is X already in use as an article title, dab page title, or redirect?

If not, then create a redirect.

If X is already an article title, consider whether this different use of X might be the Primary Topic

If so, ... (consider a RM, dab page creation, ...etc)

If not, then add the topic to an existing dab page of the form "X (disambiguation)" if it exists, or add a hatnote directing readers to topic Y, or add topic Y to the existing hatnote. If this becomes too unwieldy, create a "X (disambiguation)" to replace the existing hatnote and leave a hatnote pointing to the new dab page.

If it is already a dab page title, then create an entry in that dab page for the different use of X, following style guidelines about piping, format, etc.

If it is a redirect, add a {{Redirect}} hatnote (ie "X redirects here, for xxx see Y") to the target article to direct readers to Y, (or possibly consider Primary Topic matters).

The main point is that there should not be a higher bar for inclusion in a dab page than for the creation of a redirect: that would mean that whether we help the reader using a particular search term depends on the random factor of whether there is already another article/redirect at that word or phrase.

I suspect that this set of thoughts on redirects and dab pages doesn't belong here, but can't see where to most helpfully add it. Feel free, anyone, to copy it to any debate to which it might usefully contribute. PamD 16:40, 6 June 2023 (UTC)

Yes, I agree with all of that; I'd had some of those thoughts myself but hadn't collated them so coherently. The role of dabs as "ambiguous redirects" or "complex hatnotes" is useful and should be recorded more clearly and prominently, but I'm also not sure where. Certes (talk) 21:43, 6 June 2023 (UTC)

I think this is essentially what the DAB guideline does at Wikipedia:Disambiguation#Disambiguation_page_or_hatnotes?, without an explicit direction to create a redirect if there is no conflict at all, which is just implied? -- Patar knight - ^chat/_{contributions} 22:03, 6 June 2023 (UTC)

Also, WP:RPURPOSE eseentially has the same guidance as MOS:DABMENTION: "Sub-topics or other topics which are described or listed within a wider article. (Such redirects are often targeted to a particular section of the article.)". This is essentially justified with a relatively low bar at WP:RKEEP, which includes: "Someone finds them useful. Hint: If someone says they find a redirect useful, they probably do. You might not find it useful—this is not because the other person is being untruthful, but because you browse Wikipedia in different ways...". -- Patar knight - ^chat/_{contributions} 22:06, 6 June 2023 (UTC)

• I agree with all of the above… the question is: Is a STYLE page the right place to say all of this? The guidance on when/whether to include something in a DAB page is not a style issue. The style issue is how to link it once that decision has been made. Blueboar (talk) 22:28, 6 June 2023 (UTC)

  DABRELATED says it's acceptable and MOS:DABMENTION just says how to style it. It's really just a cultural quirk that people cite the latter and not the former and I'm not really sure why that is. One possible explanation is that the latter was created in 2010 [14]and the former in 2012 [15] so one had a head start. -- Patar knight - ^chat/_{contributions} 23:25, 6 June 2023 (UTC)

• It looks as if we need to reword the section. Instead of:

If a topic does not have an article of its own, but is discussed within another article, then a link to that article may be included if it would provide value to the reader. Such entries may be notable for purposes of inclusion in a disambiguation page. In this case, the link does not start the line, but it should still be the only blue wikilink.

perhaps we should write something like:

If an entry is for a topic which does not have an article of its own, the entry must include a blue link to an article giving information on the topic. In this case, the link does not start the line, but it should still be the only blue wikilink. That is the "style" issue. The sentence below about piping is unproblematic, but we can omit that last sentence: "If the topic is not mentioned in the other article, that article should not be linked to in the disambiguation page, since linking to it would not help readers find information about the sought topic" as irrelevant.

If there is, elsewhere, an appropriate, agreed, text about which such entries should and should not be included in disambiguation pages, we could include a link to it as an aside in the above text, but that choice is not a matter of style. PamD 07:31, 7 June 2023 (UTC)

Making it clear why an item belongs, and disambiguators in the description

At GOE, a disambiguation page, a couple of the items are

• Go (airline), a defunct British airline
• Gongduk language, spoken in Bhutan

I have in mind that these ought to be written as

• GOE, the ICAO code for Go (airline)
• GOE, the ISO 639–3 code for the Gongduk language

Question 1: Is "my" way preferable, equally acceptable, or to be avoided?

Question 2: If introducing the items with "GOE," and adding the clarification is correct, should the link in the first item be piped or left with the disambiguator in place? Largoplazo (talk) 23:26, 19 June 2023 (UTC)

@Largoplazo Or possibly:

Go (airline), ICAO code GAO

Gongduk language, ISO 639–3 code GAO

PamD 04:22, 20 June 2023 (UTC)

I like that option, I'll go with it. Thanks. Largoplazo (talk) 10:35, 20 June 2023 (UTC)

I suspect that most readers probably don't know much about the specific code system, nor is it relevant for disambiguation. For example, a reader suspects GOE is an airline, but "ICAO code" doesn't help disambiguate. However, it's useful as a hidden comment for editors who might be inclined to delete an entry that might not be obvious why it's included, and is convenient to not have to click to the target.—Bagumba (talk) 11:23, 20 June 2023 (UTC)

Order of entries

We've lost something over the years. MOS:DABORDER used to say "Within each group within a section, and within each non-subdivided section, entries should be ordered to best assist the reader in finding their intended article. This might mean in decreasing order of likelihood as user's target, alphabetically, chronologically, or geographically, not to the exclusion of other methods." [emphasis mine]. A sequence of edits by User:Swpb in 2015 replaced this guidance with "Within each group or section, entries should be ordered to best assist the reader in finding their intended article. Entries are typically ordered first by similarity to the ambiguous title, then alphabetically or chronologically as appropriate."

Ordering dab page sections alphabetically does not make sense, except as a fallback when there is no other way to order entries. If a reader has ended up on a dab page, the one thing they do not know is the exact title of the article they want. Sorting the list by the one thing the reader does not know is not ordering "to best assist the reader in finding their intended article." It is often possible to order entries by their likelihood as a target. Feature films should appear above individual episodes of television programs. Band names should appear above album titles, which should appear above song names. Common things should be listed before obscure ones. Countries should be listed above states, and states above cities. Ordering dab pages based on this principle is common practice, but the current guidelines have lost the documentation of it.

I propose to replace the text quoted above with "Within each group or section, entries should be ordered to best assist the reader in finding their intended article. Articles that are more likely to be the reader's target should be listed above those on more obscure topics. Other methods such as chronological ordering may be used where appropriate. Alphabetical ordering should be used when no other method is suitable. Entries may also be organized by similarity to the ambiguous title." Srleffler (talk) 17:15, 1 July 2023 (UTC)

I'd go back to the original wording, unless there was a consensus to change it. Alphabetical order is not deprecated nor a last resort. However, nor is it always best: I've carefully organised a few dabs only for another editor to undo the painstaking work with an automated bullet list sorter. Certes (talk) 20:35, 1 July 2023 (UTC)

Country codes and MOS:DABACRO

MOS:DABACRO requires abbreviations to be mentioned in the respective article. This means that it is illegit to list any three-letter country code in a disambiguation page with a link to the respective country (as only the ISO 3166-1 alpha-2 code is added in the infobox). But practically, the situation is different, however inconsistent. CAN does contain a link to Canada. JPN is even a redirect to Japan, and for good reasons. Conversely, the respective entry in DEU does not link to Germany, but only to the ISO 3166-1 alpha-3 list, following the rule. But this is an exception and hardly meaningful.

I would like to question the rule for situations like these. Default practical usecase for a country code in a disambiguation page is someone having read this code in an external source and then looking up which country this is. For example, a reader may have seen SMR in a sports result list and now wants to find out which country this is. In the disambiguation page, he will find it's San Marino, and maybe he has further interest in the country. So, where to link to than the country itself?? I think the rule should be adapted for cases like this. --KnightMove (talk) 11:44, 4 July 2023 (UTC)

Fyi, I've inquired at Template talk:Infobox country#ISO 3166-1 alpha-3 about why there is no option to include the alpha-3 code for countries. Note that there have been some previous discussions that have touched on this, in particular Wikipedia talk:Manual of Style/Disambiguation pages/Archive 37#Including ISO/IATA/ICAO codes, chemical element symbols, etc.. on dab pages. older ≠ wiser older ≠ wiser 13:12, 4 July 2023 (UTC)

I support adding the alpha-3 to Infobox country, which should remove any objection to its appearance in dabs. DEU etc. are probably allowed anyway on the technicality that they're codes rather than abbreviations. Such codes are used increasingly, especially in sport, and the fact that their presence helps the reader should override any pedantic objections. After all, we'd only be adding/retaining about 200 entries across Wikipedia. Certes (talk) 13:54, 4 July 2023 (UTC)

Thank you both so far. I will take some more time to browse through the older discussions and extract their results, but a remark right now: This is not only "about 200 entries", but many more. There are several defined sets of three-letter country codes with many differences to each other: ISO 3166-1 alpha-3, List of IOC country codes, List of ITU letter codes, List of UNDP country codes, List of FIFA country codes and many an International vehicle registration code. --KnightMove (talk) 07:49, 5 July 2023 (UTC)

While I can sympathize a bit, the issue becomes where do we draw the line? There are many, many, many lists of miscellaneous acronyms and initialisms. Why are articles on countries exceptional? older ≠ wiser 14:28, 5 July 2023 (UTC)

Well, those are well-defined lists by notable international organisations, and those lists have unquestioned separate Wikipdia articles in their own right. There are "many, many, many lists of miscellaneous acronyms" out there not meeting those criteria. For those that do, I am all for adding the respective acronyms in disambiguation pages. --KnightMove (talk) 14:37, 5 July 2023 (UTC)

So are you proposing to specify those particular lists as exceptions? While there are certainly many crufty lists of acronyms, I mean list of acronyms and initialisms published by reputable organizations. For me, the issue comes down to maintenance and the burden of confirming that an entry added to a page is in fact correct. If the linked article contains nothing to allow verification, it becomes considerably easier for mistakes (or the deliberate addition of spurious entries) to go unnoticed. older ≠ wiser 15:12, 5 July 2023 (UTC)

That's a fair point. But this can be solved with linking the list in the edit summary. --KnightMove (talk) 20:53, 5 July 2023 (UTC)

I'd rather it be in a hidden comment with the entry as not all edits are reviewed immediately and looking back through edit history for something like that is not practical. older ≠ wiser 01:08, 6 July 2023 (UTC)

I'm fine with that, although I would word this rather as a recommendation than a rule when someone expresses doubt - I do not se a necessity to spam disambiguation pages with Wiki code for no real use. And certainly it is better to link the external source of the list - otherwise this may be faulty, too.

Now the question remains how to go on with modifying the rule like this? I suggest the following addition (outdenting again): --KnightMove (talk) 09:46, 6 July 2023 (UTC)

Suggestion: Amend MOS:DABACRO with the following sentence:

"An exception are codes by established authorities which are relevant enough for a Wikipedia article in their own right and for which the meaning of the specific code is to be considered the primary interest of the reader. For example, the List of IOC country codes is a Wikipdia article. A reader seeing the country code VIN in a sport results list may want to know which country this is (Saint Vincent and the Grenadines in this case - the code is different from the ISO 3166-1 alpha-3 code, VCT). So it is legit to add this meaning in the disambiguation page Vin and link to the country. If any such case provokes doubt, an external source should be added as an invisible Wiki comment (in <!-- (link to the source) -->)."

--KnightMove (talk) 09:46, 6 July 2023 (UTC)

WP:NOT overriding MOS:DAB

Discussion continue at Wikipedia talk:What Wikipedia is not# Alteration to NOTDIRECTORY about which entries may be included in disambiguation pages. As WP:NOT is a policy, conclusions reached there might override MOS:DAB. Certes (talk) 10:03, 31 July 2023 (UTC)

Discussion at Wikipedia talk:Disambiguation § Best practices when a similar name is massively less notable

 You are invited to join the discussion at Wikipedia talk:Disambiguation § Best practices when a similar name is massively less notable. -- Tamzin^{[cetacean needed]} (she|they|xe) 23:48, 5 August 2023 (UTC)

Or variants

On Balthazar, Iterresise and I had a little back and forth editing about the intro line. I know that many dab pages that treat multiple variants spellings use the phrase "or variants" or something similar to avoid an exhaustive listing of each and every variation. I had thought something to this effect was in MOSDAB, but I may have been mistaken

Currently Wikipedia:Manual of Style/Disambiguation pages#Introductory line states:

Where several variants of a term are being disambiguated together, significant variants may be included in the lead sentence. For example:

Bang or bangs may refer to:

or

Bang(s) may refer to:

Arc or ARC may refer to:

Angus McKay, MacKay or Mackay may refer to:

However, it is not necessary to mention minor variations of capitalization, punctuation or diacritics. For example, AU may refer to: is preferable to AU, au, Au or A-U may refer to; and Saiyuki may refer to: is preferable to Saiyuki, Saiyūki or Saiyûki may refer to.

On Balthazar, there are four distinct, although relatively minor, spelling variations treated on the same page: Balthazar, Balthasar, Baltazar, and Baltasar (all of the last three redirect to the same dab). Does (or should) MOSDAB have any recommendation as to how the intro line should be presented in such cases?

• Simplify to only the main spelling as per Iterresise's initial edit
• Use ", or variant spellings," to abbreviate the list as it had been previously
• List each of the variants (for example, although this omits Baltasar)

Or is this something best left to hash out on case by case basis? Although even so, some might argue that a strict reading of MOSDAB doesn't allow for using ", or variant spellings," language. older ≠ wiser 12:07, 26 September 2023 (UTC)

Case-by-case basis. In one case, the variants may be very rare; in another, they may be nearly as common as the WP:COMMONNAME. And there may be many, many variants, with a handful worth mentioning because they are common, then followed by something like "or other variants". This is not a one-size-fits-all kind of thing. There might be wording tweaks we can make, though, to be clearer about this. Some of what I just wrote might be adaptable for this purpose.  — SMcCandlish ☏ ¢ 😼  13:03, 26 September 2023 (UTC)

I have to disagree with both of you. I believe all variants should be listed (in the intro line). For example: Balthazar#See also lists Belshazzar (disambiguation) (a variant) and Belshazzar (disambiguation) lists Baghdasar, "a form [variant] of Belshazzar". If there are variants, the normal case is to create other disambiguation pages. Iterresise (talk) 20:34, 27 September 2023 (UTC)

That's not even on the same continent as practical. There are hundreds of variants of "Elizabeth" as just one example, and there are at least 100 spellings of my own surname, counting all the attested Irish and Scottish anglicizations (with and without M[a]c and O' or Ó).  — SMcCandlish ☏ ¢ 😼  20:41, 27 September 2023 (UTC)

Do you have any citations to support this? Iterresise (talk) 20:53, 27 September 2023 (UTC)

This is a discussion, not an article, and we don't need citations to simply have a discussion. But if you want to be a WP:WIKILAWYER and try to WP:WIN every discussion you get into with pointless arguments and bluster, instead of employing common sense and considering that some people may actually know something you don't, and instead want to make out like they're blatantly lying to you, here you go: [16], [17].  — SMcCandlish ☏ ¢ 😼  14:41, 28 September 2023 (UTC)

I'm not even sure what it is you are suggesting. Are you saying Balthazar should include Belshazzar, Belshazzar, Baghdasar in the intro line? Why? That seems bizarrely at odds with both current practice and any portion of disambiguation style guidelines. BTW, my preference is to list all of the significant variants in the intro although for very long lists I'm perfectly happy to abbreviate with "or variants". BTW, the first of your edits to the page left only Balthazar in the intro line and one of your subsequent edits omitted one of the variants. As you can see, listing every variant can be messy. older ≠ wiser 21:34, 27 September 2023 (UTC)

Well disambiguation pages are for articles which have the same name, isn't it? From what I understand, User:SMcCandlish believes it is impractical to be doing this yet Baghdasar, "a form [variant] of Belshazzar", has been split off from Belshazzar (disambiguation).

With regards to Elizabeth, it seems Elizaveta (disambiguation) would be a variant and is correctly disambiguated. I am not convinced that taking a case-by-case approach is ideal or the best practice. There are 100s of variants of "Elizabeth" and his last name but that doesn't mean the ones with articles cannot be disambiguated or listed. Just because disambiguation may take a long time, it doesn't mean that disambiguation pages shouldn't be created. Iterresise (talk) 06:07, 30 September 2023 (UTC)

You're straw manning. I never said anything about, much less against, the idea of having separate disamibuguation pages for things that seem to warrant them (like, say McCandlish and McCandless (surname)?) but which could also be considered by some to be variants of one name. Rather, you proposed that "all knownn variants should be listed" in the lead a disamgiuation page, which is a very different proposition. And your dependent idea of particularly including in the DAB intro any variants with their own disambiguation pages is not what we do; they go in the "See also" section lower in the page.  — SMcCandlish ☏ ¢ 😼  07:23, 30 September 2023 (UTC)

What do you mean strawpersoning? What you did say is "that's not even on the same continent as practical" which I interpret as "User:SMcCandlish believes it is impractical to be doing this".

I do believe any variants with their own disambiguation pages should go in the "See also" section lower in the page. Yes, I believe we agree on that. Example cases:

• Baghdasar ("a form [variant] of Belshazzar", it is listed in the "See also" section on Belshazzar (disambiguation) lower in the page )
• Elizaveta (disambiguation), a variant of Elizabeth. Elizaveta (disambiguation) is listed as a redirect in the "See also" section on Elizabeth lower in the page.

I didn't propose "that "all known variants should be listed" in the lead in disambiguation pages, which is a very different proposition". Example: I mistakenly omitted "Baltasar" in [18]. I will fix that. Iterresise (talk) 01:00, 3 October 2023 (UTC)

I'm really not interested in playing long-winded "he said, she said" games. I've made my points clearly, and other people can have their input, and we'll move on.  — SMcCandlish ☏ ¢ 😼  01:37, 3 October 2023 (UTC)

You did in fact literally say I believe all variants should be listed (in the intro line). [19]. But are you going to continue removing '(or variants)' and similar language from the intro line? older ≠ wiser 01:49, 3 October 2023 (UTC)

Is there a problem? I omitted "Baltasar" and fixed it. Iterresise (talk) 08:09, 4 October 2023 (UTC)

The problem is that you've opened a worm-can discussion, proposing that all variants should be listed (in the intro line), treated other editors poorly when they disagreed with you, ignored practical concerns with the idea and ignored actual practice when it comes to handling of variants, then denied making the argument you made, instead of just conceding that you made a poor argument, and you're going round in circles with a bunch of hand-waving. It's a tedious drain on editorial time and goodwill. This smacks of WP:WIKILAWYERING and WP:WINNING behavior. See also [20]. This is not a discussion forum for endless argument-for-sport with "Internet enemies".  — SMcCandlish ☏ ¢ 😼  08:58, 4 October 2023 (UTC)

@Iterresise: The original question I raised concerned use of "or variants" and similar language in the intro line. Balthazar was only an example where this came to a head. You had previously made several similar edits to other disambiguation pages removing "or variants" language from the intro line. Hence my repeating the question to clarify what is the understanding of whether "or variants" is acceptable in the intro line to abbreviate multiple minor variations. older ≠ wiser 10:51, 4 October 2023 (UTC)

Whatever Iterresise's view on this, mine is that it is obviously permissible, because we routinely do it and there is not a rule against it, nor a clear rationale to institute a new rule against it.  — SMcCandlish ☏ ¢ 😼  13:31, 4 October 2023 (UTC)

What do you mean permissible? Both of you have misunderstood me: when I stated "all variants should be listed (in the intro line)", I didn't mean to include cases where there are already on separate disambiguation pages for other variants.

In addition: SMcCandlish: you misunderstood me when you state: "treated other editors poorly when they disagreed with you, ignored practical concerns with the idea and ignored actual practice when it comes to handling of variants, then denied making the argument you made, instead of just conceding that you made a poor argument, and you're going round in circles with a bunch of hand-waving.... This is not a discussion forum for endless argument-for-sport with "Internet enemies". And this is just a joke right? Iterresise (talk) 07:42, 6 October 2023 (UTC)

Repeating me back to myself but adding nothing to it other than vague handwaving like "you have misunderstood" without explaining any such alleged misunderstanding, is not an argument, it's just noise.  — SMcCandlish ☏ ¢ 😼  20:19, 9 October 2023 (UTC)

WP:AGF Mr. SMcCandlish Iterresise (talk) 07:06, 11 October 2023 (UTC)

Observing that your input has not been cogent has nothing to do with assumptions about the faith behind the input.  — SMcCandlish ☏ ¢ 😼  17:26, 11 October 2023 (UTC)

Cut it out. Iterresise (talk) 09:00, 13 October 2023 (UTC)

I'm not doing anything to you. You are doing it to youself. See First law of holes.  — SMcCandlish ☏ ¢ 😼  02:49, 15 October 2023 (UTC)

I agree that it is permissible but not ideal. Do we have consensus that all variants should be listed (in the intro line) that are not already on separate disambiguation pages for other variants? Iterresise (talk) 02:58, 9 October 2023 (UTC)

No, not at all. I see nothing wrong with using "or variants" (or similar) to abbreviate a longish list of minor variants. older ≠ wiser 09:12, 9 October 2023 (UTC)

Right. There is obviously not a consensus to list every single variant as a general principle, and I've laid out impossible-to-ignore reasons why, like names that have 100+ variants. The most that can be said is that if there were five known variants, then listing four of them plus "or other variants" would not be helpful.  — SMcCandlish ☏ ¢ 😼  20:19, 9 October 2023 (UTC)

Here is another example. Why shouldn't we list all the variants that don't have disambiguation pages? Iterresise (talk) 07:21, 11 October 2023 (UTC)

Including Irrawaddy in the intro line on that page doesn't make any sense since Irrawaddy has its own page and there is not any redirect. That page at present is only disambiguating topics with the spelling 'Ayeyarwady' and it doesn't even need to include 'or variants'. older ≠ wiser 10:41, 11 October 2023 (UTC)

PS, if there are only these two uses, there is a good case that Ayeyarwady should be restored to being a redirect to the river and address ambiguity in a hatnote (or perhaps redirecting it to the already existing dab page at Irrawaddy. older ≠ wiser 10:51, 11 October 2023 (UTC)

I see. My edits wholesale removing "or variants" and other variants may not be ideal but in some cases they are. Maybe that is what user:SMcCandlish means when he says on a "case-by-case" basis. I've made a lot of removals. Maybe you can suggest which ones were incorrect/inappropriate. Iterresise (talk) 09:08, 13 October 2023 (UTC)

I've redirected it to the target you suggested as I agree. Iterresise (talk) 09:39, 13 October 2023 (UTC)

This is an interesting case since I redirected the variant to the most common variant/spelling. What about keeping the most common variant and making redirects to the disambiguation page? Iterresise (talk) 20:57, 14 October 2023 (UTC)

I've no idea what you are proposing. older ≠ wiser 21:05, 14 October 2023 (UTC)

What I am proposing is to remove ", or variant spellings," and similar language. It might be a good idea to add the language to the project page.

Our disambiguation pages should not list all the minor variants and only minor variants should be made into redirects to the disambiguation page. This is in accordance with WP:ARTICLETITLE. Take Kara Dag for example. It includes approximately 5 minor variants. Kara-Dagh redirects to the page but is not a listed [minor] variant. The disambiguation page lists hyphenated minor variants which are legitimate minor variants. If we were to include all legitimate minor variants, it might not be practical though Kara Dag has language explaining the hyphenated variants. The question is if we want to include in the manual of style this sort of language. I would oppose it because it would be unwieldy and impractical. So what I am proposing is to remove ", or variant spellings," and similar language and redirect minor variants to the disambiguation page and it may be a good idea to add this language to the manual of style. Iterresise (talk) 13:04, 16 October 2023 (UTC)

As I've indicated before, I think it is perfectly fine to use "or variants" language. Kara-Dagh is a difficult page in that there are numerous other variant transliterations in addition to those listed, for example Garadagh/Garadag. The page needs other MOSDAB attention beyond the intro line and perhaps is not a great example at this time to discuss the intro line. older ≠ wiser 14:21, 16 October 2023 (UTC)

Completely agreed with Bkonrad. And Iterresise, just re-re-re-repeating the same proposal over and over again after it has met with a poor reception is not magically going to make it meet with consensus. Cf. WP:IDHT and argument by repetition.  — SMcCandlish ☏ ¢ 😼  20:43, 16 October 2023 (UTC)

I'm not sure what you are saying here. You didn't make your case clear so I reiterated the proposal. Iterresise (talk) 19:31, 18 October 2023 (UTC)

It's perfectly fine to be discussing this topic here. You raised the concern and currently there is no consensus or language in policy or guidelines which indicates "or variants" language is allowed. All the examples in the manual of style has a sentence fragment ["... may refer to:"] as the intro line. Iterresise (talk) 19:47, 18 October 2023 (UTC)

Why not include minor variants that are used in reliable sources? Iterresise (talk) 19:57, 18 October 2023 (UTC)

I decline to get drawn into an endlessly repeating circular discussion. All of this has been addressed already, so there is no need for us to continue an unproductive two-person argument.  — SMcCandlish ☏ ¢ 😼  20:38, 18 October 2023 (UTC)

Your are not obligated to opine. The vast majority of pages don't have "or variants" language. No consensus exists for standardization of the intro line. I see no harm in removing "or variants" language at this time. Iterresise (talk) 22:40, 19 October 2023 (UTC)

You need to stop. Multiple editors here oppose your mass removal of such language, so until there's a positive consensus in your favor, WP:STATUSQUO must stand: the absence of consensus does not allow you to continue removing "or variants" language, now that you are aware of the opposition. And the opposition does not have to keep repeating their position for you to be bound by it. If you want to try for a consensus to remove, you can neutrally advertise the discussion, but I don't think you'll get what you're seeking. —swpb^{T • beyond • mutual} 13:58, 20 October 2023 (UTC)

Yes: I understand: You've added your opinion with the opposition. However: making accusations that I will continue to revert is similar to WP:ASPERSIONS. Iterresise (talk) 20:38, 21 October 2023 (UTC)

To the contrary, the WP:ICANTHEARYOU pattern you have been demonstrating throughout this entire discussion is a prefectly valid reason for other editors to make it clear that you need to stop and not re-start this activity, especially when your last comment on the matter was "I see no harm in removing "or variants" language at this time", which is difficult to read as anything but a declaration that you're going to continue no matter what.  — SMcCandlish ☏ ¢ 😼  22:07, 21 October 2023 (UTC)

I've already asked you to give it up but this WP:TAGTEAMING is unwelcome. So let me say to both of you to give it up and that both of you need to stop. Iterresise (talk) 00:08, 23 October 2023 (UTC)

Two editors independently reaching the same conclusion that you're behaving badly isn't WP:TAGTEAMING, and telling you not to do what you said you would keep doing is not WP:ASPERSIONS, but I think you know that. Since you seem to like pages in Wikipedia space, give WP:LAWYERING a read, then touch grass. —swpb^{T • beyond • mutual} 13:23, 23 October 2023 (UTC)

Yes, of course, it's not tag teaming. You don't see it as tag teaming so fair enough. I totally understand now after touching grass: Making unsubstantiated accusations is tendentious editing. Iterresise (talk) 03:36, 24 October 2023 (UTC)

I'd also recommend having a look at WP:The Last Word. older ≠ wiser 14:04, 23 October 2023 (UTC)

And "My edits wholesale removing 'or variants' and other variants may not be ideal .... I've made a lot of removals. Maybe you can suggest which ones were incorrect/inappropriate." They should arguably all be reverted, because you did it without consensus, came here after the fact in an "ask forgiveness not permission" manner, and have completely failed to establish that what you're doing has consensus.  — SMcCandlish ☏ ¢ 😼  02:48, 15 October 2023 (UTC)

"a redirect ... should be created at that location [if one doesn't exist]"

Rather than continue a revert pattern, let's just talk this out. The long-standing material read:

In the See also section of a disambiguation page, an intentional link to another disambiguation page that does not contain "(disambiguation)" in the title should be written as [[Foo (disambiguation)]], and a redirect to [[Foo]] should be created at that location.

Danbloch changed this to:

In the See also section of a disambiguation page, an intentional link to another disambiguation page that does not contain "(disambiguation)" in the title should be written as [[Foo (disambiguation)]], and a redirect to [[Foo]] should be created at that location if one doesn't exist.

I reverted back to the original with the rationale: "Not actually helpful. If one does already exist, a new one cannot be created at that location, and if it does already exist it's because someone already created it at that location."

Danbloch then restored their version, with: "Read the text again. Without the addition, the text says to create the redirect from "Foo (disambiguation)" to "Foo" unconditionally, implying that it never exists beforehand." That does not appear responsive to what I said.

I have read the text again, twice. My position remains that the addition is pointless verbiage, because it is not possible to "create at that location" a redirect that already exists at that location (that is, "create the redirect ... unconditionally" is literally not possible, since two pages cannot occupy the same title). Thus, "if one doesn't exist" is an instruction without any use cases that have to be distinguished by such an addition, and is therefore just WP:Instruction creep. It might be a trivial case of creep, but due to the MOS:BLOAT problem, we should keep this material as concise as possible and not state the obvious. There is no potential for confusion here that I can see. But maybe Danbloch can lay out a scenario in which confusion arises, and arises often enough that we need to change MoS's wording to account for it.

PS: Maybe this micro-conflict just goes away entirely by changing the wording to and ensure that a redirect to [[Foo]] exists at that location.  — SMcCandlish ☏ ¢ 😼  04:02, 29 October 2023 (UTC)

I would be perfectly happy with "and ensure that a redirect to Foo exists at that location".

Presumably that ends the discussion, but for the record my position is that without the qualifier (or the above change), the instructions are wrong. They're telling people do do something which may not be possible (create a redirect which already exists). This can lead inexperienced users to think that they're doing something wrong, or that they don't understand how Wikipedia works. Being correct is more important than being four words shorter. Dan Bloch (talk) 04:35, 29 October 2023 (UTC)

This should resolve it then. But I still disagree with your premise. Anyone who would be unable to understand that "go create a redirect here" can't literally apply when the redirect already exists there because someone already did that work, would not be competent to work on this project. It is important that we do not bloat these pages with "treat our editors as if they have severe brain damage" redundancies.  — SMcCandlish ☏ ¢ 😼  07:06, 29 October 2023 (UTC)

Honsestly: I'm not sure which version is best. However: I found Dan Bloch's version to be precise. Iterresise (talk) 12:25, 30 October 2023 (UTC)

"Precise" and "concise" are very often at odds, especially in policy-writing. If MoS were as precise as it could be made to be, it would be about the same length as Chicago Manual of Style, and no one wants that.  — SMcCandlish ☏ ¢ 😼  12:36, 30 October 2023 (UTC)