About this template

edit

This template was made as a result of the discussion at Wikipedia talk:WikiProject Disambiguation#Disambig and setindex meta-template.

Currently this template uses the CSS id "disambig" when "type=disambig" is set or no type is set. The reason is that that is the id that the javascript in MediaWiki:Common.js uses to determine if a page is a disambiguation page or not, so it knows when to display the {{disambig editintro}}. But I find that id name too generic to be clear. Also that id is/was used to set the styles for the old disambig and setindex boxes. To keep the usage apart I intend to later change to use the id "disambigbox", which should only be used to trigger the javascript. While the looks should be determined solely by the dmbox CSS classes.

--David Göthberg (talk) 14:54, 12 October 2008 (UTC)Reply

I've now added the finalised dmbox style to Common.css; decaching expires 9 May 2009. Happymelon 11:35, 8 April 2009 (UTC)Reply
I just want to note why I didn't add that class before:
It probably isn't necessary to have the dmbox style in MediaWiki:Common.css. Since I don't think the disambig boxes will be styled in other skins, and I don't think people will build hand coded disambig boxes. And users that want to style them in their own user /monobook.css can use the !important keyword.
But it is only one class, since {{dmbox}} uses the generic mbox-* classes for its cells, so it isn't much CSS code. And it is a very widely used template. So it doesn't hurt much to add the styles.
--David Göthberg (talk) 13:14, 8 April 2009 (UTC)Reply
I was prompted to add this after finding #disambig styled in common.css, which I agree is semantically dubious: that tag should be used only for identification, not styling. So if we can remove that class in compensation, there's not actually much new code added to common.css Plus it's more consistent with the other mbox templates to have the styles in common.css; it's where most people would automatically go to find mbox styles. Happymelon 14:17, 8 April 2009 (UTC)Reply
We have now updated the code in MediaWiki:Common.js so both the id "disambig" and the new id "disambigbox" triggers the showing of {{disambig editintro}}. But web browsers cache our CSS and javascript files for up to 31 days. So we can change the id used in {{dmbox}} to "disambigbox" on 17 April 2009, 03:01 UTC. After we have updated dmbox we can removed the old id "disambig" from the javascript and then that id will be fully deprecated.
--David Göthberg (talk) 09:48, 16 April 2009 (UTC)Reply
 Y Done - I see that RockMFR has finished the change from the id "disambig" to the id "disambigbox". He has updated this template and also removed the old id from MediaWiki:Common.js. Thanks RockMFR.
--David Göthberg (talk) 17:33, 22 October 2009 (UTC)Reply

Category:All disambiguation pages

edit
This discussion was moved here from Template talk:SIA since it concerns all the disambig, set index and name message boxes. --David Göthberg (talk) 08:58, 2 March 2009 (UTC)Reply

Considering the following from WP:SETINDEX:

A set index article is not considered a disambiguation page, and need not follow the formatting rules for disambiguation pages.

shouldn't the {{SIA}} template not add the hidden category Category:All disambiguation pages? I use this category in many of my toolserver scripts that identify orphans and dab pages with links, and it looks like SIAs are being miscategorized. --JaGatalk 06:15, 2 March 2009 (UTC)Reply

I agree with JaGa: it doesn't make sense to add SIAs to a global disambiguation category. —hike395 (talk) 07:12, 2 March 2009 (UTC)Reply
I think I agree. The set index boxes should probably have a separate "all" category.
Here's the technical details about this:
The {{SIA}} template, and all other message boxes that use the same style, such as set index, disambig and human name boxes use the meta-template {{dmbox}}. In December Remember the dot added category code to that meta-template. That code adds Category:All disambiguation pages to all pages that use any of these boxes (except when in template space), and it also adds Category:All article disambiguation pages to all articles (main space pages) that use any of these boxes.
Usually I am opposed to having a style meta-template like {{dmbox}} handle the categorising, since it usually causes problems. But in this case it might be acceptable since there are so many different disambig boxes that use it that it perhaps is easier to have this category code in the meta-template.
The {{dmbox}} meta-template is aware of when it is used for a disambig template versus when it is used as something else, for instance a set index or human name box. That is, it has a parameter "type = disambig / setindex". (The "type=disambig" parameter makes it so the {{disambig editintro}} is displayed when editing a page with any disambig template on. It means that {{dmbox}} internally sets the CSS id "disambig". The id is used by the javascript in MediaWiki:Common.js to determine if a page is a disambiguation page or not.)
So, we can make it so {{dmbox}} instead adds for instance Category:All set index and name pages when it is used for set index and name boxes. Or, we could even add the parameter "type=name" to {{dmbox}} so we could categorise the name pages separately from the set index pages.
If/when you people have decided how we should categorise this, then feel free to contact me and I'll implement it in {{dmbox}}. (Since I built the {{dmbox}} and know all the details about how it works and what things depend on it in what way etc.)
--David Göthberg (talk) 08:58, 2 March 2009 (UTC)Reply
I would support a different category for set indexes, but would prefer hndis etc to stay in the "All disambiguation pages" category, since (unless I'm missing something and I very well may be) I believe hndis etc are still disambig pages. --JaGatalk 18:03, 2 March 2009 (UTC)Reply
Oh, and I forgot: Thanks for moving this discussion to the correct place and providing the explanation, David. :) --JaGatalk 18:04, 2 March 2009 (UTC)Reply

The whole reason for Category:All disambiguation pages was so that we could get count the number of articles in Wikipedia excluding disambiguation pages and the main page: {{Number of actual articles}}. So, it sounds reasonable to not count set index articles in that category. —Remember the dot (talk) 00:07, 3 March 2009 (UTC)Reply

JaGa: Oops, sorry I was a bit fuzzy in my description above. Right, {{hndis}} are for "human name disambiguation pages". But with the "name pages" I meant pages that use the {{given name}} and {{surname}} boxes. And such pages are not disambig pages. But I am not sure if they count as set indexes or something else. (All this disambig political stuff is new to me.) Anyway, they currently use "type=setindex" to not trigger the {{disambig editintro}}.
So, it seems we all agree on making the non-disambig boxes categorise somewhere else. So should we simply not categorise them? Or what exactly should we call that other category? And if we categorise, then do {{given name}} and {{surname}} need special treatment?
Here's one suggestion for category name: Category:All set index articles. And I think that category should be placed under Category:Set indices.
--David Göthberg (talk) 03:13, 3 March 2009 (UTC)Reply
1: Okay, I have done the update to {{dmbox}}. And pages are starting to arrive in Category:All set index articles.
2: We still need to decide what to do with {{given name}} and {{surname}}.
3: Many of the disambig and set index boxes need clean-up of their category code. I will perhaps have some time to fix that. I won't bore you guys with the details. But you who understand these things are welcome to look over those templates.
--David Göthberg (talk) 22:17, 4 March 2009 (UTC)Reply
Thanks for a quick and useful solution! This is working perfectly. --JaGatalk 06:01, 10 March 2009 (UTC)Reply

Set index image

edit
 
The disambig and set index box image

Today JHunterJ disabled the image on the generic set index article box {{SIA}}. He used the edit comment: "Remove disambig icon; is there an appropriate "set index" or "list" icon that can be substituted?"

I assume he did so to make the set index box differ more from the {{disambig}} boxes, since disambiguation pages and set index articles are not considered to be the same thing.

I think that not using an image at all is much worse than using the current image, so I reverted him for now.

I kind of agree that set index boxes should perhaps use a separate image. But the current image is pretty good for set index articles too, since they too are one name that then splits to several names. So the only reason I see to use another image would be to make it clearer if a page is a disambig or set index page.

We could use the current symbol, but with a different colour. I just tried a blue-grey version (pretty nice) and a light brown version (very nice) in my image editing program. I might make full SVG versions of them and upload them. Actually, I think the light brown version fits better for disambig pages, since it has some resemblance to the yellow and orange warning colours, and {{disambig}} partly is a cleanup notice since it says: "change the link to point directly". So perhaps we should instead keep the set index image grey and make the disambig image light brown?

I also tried to make or find a list symbol, but I couldn't come up with any nice list symbol.

So, does anyone have any suggestions for a better image?

--David Göthberg (talk) 21:59, 6 April 2009 (UTC)Reply

Those who are interested in the images, and not the disambig vs. set index policy discussion, can skip directly to the section "List icon" below. --David Göthberg (talk) 21:13, 7 April 2009 (UTC)Reply

I think that no image is better than an incorrect image. SIA and dab things are too interleaved now (like using {{dmbox}} as the basis of {{SIA}}). Because SIAs are articles (and valid link targets) and dabs are not articles (and normally not valid link targets), they really need to be separated more. -- JHunterJ (talk) 11:13, 7 April 2009 (UTC)Reply
I disagree that SIAs are either "articles" or valid link targets. This is a long-festering confusion. Some name-related pages do have article-like content, but many, perhaps even most, are little more than lists of items sharing a similar name, much like a disambiguation page. However, as David has noted, it is uncertain that given names or surname pages are properly considered as SIAs. For other types of set indices, the similarity with disambiguation pages is even more pronounced. Links to SIAs should be disambiguated, where appropriate links exist on the set index page. The only time links to the set index page are appropriate is where the corresponding article for a particular item in the index doesn't exist yet. olderwiser 12:23, 7 April 2009 (UTC)Reply
If they aren't articles, then they aren't set index articles. If they need to have incoming links disambiguated, then they are disambiguation pages. You're right, it's a long-festering confusion, but I think it's driven by some desires to have dab pages that don't follow the dab page guidelines, and I think it's a confusion that can be cleaned up by recasting the SIAs that are really dabs as dabs and the dabs that are really SIAs (if any) as SIAs. -- JHunterJ (talk) 15:02, 7 April 2009 (UTC)Reply
Or perhaps by restoring the MOSDAB to its 2006 version so it again makes sense to most editors who are actually trying to make the dab pages useful, not just mindlessly "clean" and "MOSDAB-compliant"? With users not "desiring" the sets to be marked as dabs, one would think there must be a good reason or two for why that is so. But we've already been through that with no avail... better not open the same can of worms once more.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 15:21, April 7, 2009 (UTC)
I agree that the dab project tends to attract people who enjoy working with a rigorous set of rules. And I've been trying to avoid rules-creep where it doesn't actually help navigation. But I also don't think actual disambiguation pages need to be "mindlessly" cluttered with lots of red and blue links that don't help navigation either, in the name of "usefulness" when they aren't actually useful to a reader who has reached the dab page and intended to reach an ambiguous article. -- JHunterJ (talk) 15:41, 7 April 2009 (UTC)Reply
Like I said, I don't burn with desire to re-open this particular can, but I'd still like to point out that usefulness is in the eye of a beholder. Even red links, when added under a certain set of rules (which may quite possibly be incompatible with the MOSDAB regulations, but still make perfect sense to a WikiProject that deals with them), can be quite useful to readers. Aiding navigation is great, but sometimes it is simply insufficient or leads to suppression of little bits of information which cannot be immediately added elsewhere. Since disambig pages guidelines would not allow for that information to be added, sets are a perfect place for it—so the "avoidance" is not a blind desire to bypass the dab rules for the heck of it, but actually to communicate as much available information to the readers in the only way that seems to be available. I personally think that sets are a dumb, confusing, and redundant concept, as they add nothing to what a slightly relaxed set of disambig rules wouldn't be able to handle.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 16:31, April 7, 2009 (UTC)
Absolutely, red links have good uses on articles. They have no use on disambiguation pages without a corresponding blue link to aid the reader in navigation to the article in need of disambiguation. Disambiguation pages are navigational aids. I also agree that set index articles are not particularly useful, but I think their lack of utility would not be remedied by moving their non-WP-article entries to WP dab pages. -- JHunterJ (talk) 16:42, 7 April 2009 (UTC)Reply
On the contrary, red links can be very helpful on disambig pages on their own. I am by no means saying that any random red links possess that quality, but there are definitely situations when some do. For examples, I refer you to my previous (and very long posts) here (the discussion was about something else, but the red-link reasons I outlined there apply to this discussion just as well).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 17:37, April 7, 2009 (UTC)
Only if you redefine what a dab page is. If it's a page to assist users in navigating to a Wikipedia article based on a search term that might refer to more than one Wikipedia article, then having red links in entries without blue links is not useful there. -- JHunterJ (talk) 17:56, 7 April 2009 (UTC)Reply
Thank you, you are getting very close to my point. Disambig pages are there to assist users in navigating to a correct page; to a page readers are looking for. Having red links in certain cases helps users understand that none of the blue-linked pages are the ones they need, so they either need to check back (when the red links turn blue), or keep searching elsewhere (in which case easing restrictions on external links may be very helpful; heck, for geo-places even the {{coord}} would do!). This is not that far outside of the definition, isn't it?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:17, April 7, 2009 (UTC)
Our points started out very close together. The remaining disagreement seems to be on whether red links are necessary to tell the reader that the article she's looking for isn't in the list, or whether the absence of the article from the list would suffice to tell her that. And the drawback to changing the function of dabs from simple navigation to navigation and explanation/education is that, once the line is moved, there is nothing as specific to refer to to keep other editors from clogging the dab pages with red links and external links. I've seen some doozies. -- JHunterJ (talk) 10:54, 8 April 2009 (UTC)Reply
So, relinquishing control is the only problem? Just kidding :) Seriously, though, the line can be moved wherever if the rules are adjusted appropriately. Take red links, for example (you are right, by the way, that they are my biggest grudge regarding MOSDAB, although by no means the only one). There are plenty of ways to retain the useful red links and yet still have them in a clearly-defined rules framework. Instead of the current draconian rule, each red link can be required to be referenced, or followed by an external link (just one, and to the point), or by an interwiki link (if the target is referenced), or (for geo-places) by coordinates, or whatever—the details can always be discussed at length later. Relegate all red links to the bottom; heck, to a separate section in a small font even, and here we go—you've got a useful and non-misleading page that aides in navigation as well as in research. What's the big deal about the dabs being purely navigational anyway? It's like playing with a balloon—you push down in one place only to see the stuff jutting elsewhere: over-regulate dabs—deal with sets; over-regulate sets—deal with "multi-stub articles"; over-regulate those—deal with another crazy thing someone is bound to come up with. In the end, you'll be getting the same rules creep you are trying to avoid—only instead of MOSDAB the rules will creep to other pages. I am sure that works for many Dab-project folks who, as you pointed out, enjoy working under a strict and limiting set of rules, but in the long run we are just getting more and more editors confused. I am yet to meet an editor who is not particularly involved with disambigs and who could tell the difference between the concepts of a dab and a set.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 13:28, April 8, 2009 (UTC)
(re-indent for readability). Two questions for Ezhiki: First, since your clear SIA-example Lvovo is limited to Russian places by (subject-driven) definition, how would I navigate and search for and find say 'Lvovo (album)' Or 'Lvovo (motorcycle)'? Already I see the same happening between DAB-page and surname-page (I am struggeling to get that one). Second question. You write about squeezing rules here sees unruliness elsewhere. In general, I don't disagree. But the opposite would be true too, innit: if we leave the rules on SIA as is now or as you describe (that's with few or lax rules), wouldn't that create worst-Wikipedia-pages: external links, red links, overlinking, interwikilinks, and at least three (three colors) per line. For me: imo we can use SIA very well as an article/navigational aid, diffferent from DAB by principle, style, standards. Now enter the surnames in this subject ;-) -DePiep (talk) 18:13, 8 April 2009 (UTC)Reply
DePiep, your first question is actually a very simple one. Sets are topic-specific, while dabs are not. So, taking your hypothetical Lvovo example—if "Lvovo" refers to many other things besides "inhabited localities in Russia", we would simply set up "Lvovo" as disambiguation page listing all items that need to be disambiguated (motorcycles, albums, etc.), and add a link to "Lvovo (rural locality)", which would be a SIA on Russian inhabited localities. Alternatively, if there are many inhabited localities and only one other concept (an album, say), then "Lvovo" would be kept as a set, and the album link would be added to the "see also" section of that set or added as a {{this}}/{{for}} hatnote. Surnames can be handled pretty much in the same manner, although, not having worked with the surnames extensively, I can't easily say how well it would work in practice. I've been treating the surnames articles effectively as "SIAs on surnames", and did not have any troubles with that approach, but again, my experience in that area was quite limited.
Regarding the second question, I am sorry, I do not quite understand what you are asking. You are saying that SIAs formatted using lax rules would create the "worst pages" with "external links, red links, overlinking, interwikilinks, and at least three (three colors) per line". To me, that's a description of a typical Wikipedia article, and since "A" in "SIA" stands for "article", what seems to be the problem? The major difference of SIAs and dabs is that the latter are purely navigational aides, while the former also include content, just as any other, "normal", article would.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:50, April 8, 2009 (UTC)
RE First answer: This way the difference between DAB and SIA is blurring. Then it becomes navigation/list/article in one. That leaves editors with multiple, overlapping sets of guidelines/styles to choose from. And the reader will always see/experience the effect, being: unclear. And our example was just quite simple.
RE Second answer (I meant to ask: since you propose to allow all types of say links in every line, the page-face will be crowded with colors and not at ease): Indeed we use these link-types already in regular articles, sparsely or at separated locations. External links in references or their own subsection, interwikis sparsely. It would be chronically Overlinked.
Adding: I have the impression that the strive for completeness here is overloading that one SIA: being an extensive list, having a small article about each item, and navigating to all the big articles - people like me wouldn't see the wood for the trees, I think. -DePiep (talk) 19:34, 8 April 2009 (UTC)Reply
Well, a regular article can be chronically overlinked, too. Editors just need to try keeping balance between useful and redundant, is all. There is no need to fit as many links as possible to every entry—linking related items that need explanation in the contest of the definition and providing a source that verifies the entry is usually all that is needed. Also, there are just too many useful things that dabs do not allow and sets do; omission of vital information because it cannot be immediately put into a disambig due to MOSDAB constraints is a big one, for WP:RUSSIA, at least.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 20:34, April 8, 2009 (UTC)
Ezhiki: Since you reverted me: I lowered the indentation in the comments above to make the text readable for people like me who use devices with lower screen resolutions. Not every Wikipedia editor use a 21" screen with 1600×1200 resolution. So indentation is not a matter of taste, but about if we should be able to read your comments in a sane manner. (And using such devices also is not a matter of taste, but sometimes a matter of that one can't afford to buy that 21" screen.)
--David Göthberg (talk) 19:07, 8 April 2009 (UTC)Reply
David, I don't have problems with excess identation even when I browse using a PocketPC; surely one can't go any more low-res than that? Also, while identation is of course a matter of taste, why not keep one's own tastes to one's own edits?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 20:34, April 8, 2009 (UTC)
The precise layout of a page is so heavily browser-dependent that it's impossible to say with any certainty whatsoever that if it looks ok on X it must work on Y. Our policy is that pages should be viewable on 800x600; I can tell you for a fact or you can check if you've got FF with the Web Developer toolbar, that the level of indentation above looks utterly ridiculous. Refactoring talk page comments for the purposes of readability is explicitly permitted by WP:TPG. Happymelon 20:45, 8 April 2009 (UTC)Reply
I could argue that editor's conscious choice of identation hardly qualifies as "formatting errors" under TPG, but seeing how this thread, which is unrelated to the topic of discussion, is already growing to ridiculous lengths, I'd say let's not make it any longer. From now on, on this particular page, feel free to refactor my comments any way you like, formatting-wise. Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 21:20, April 8, 2009 (UTC)
Ezhiki, maybe that would be a good topic for WT:MOSDAB: segregating "bare" red links and possibly even external links at the end of a page (after "See also"). Maybe with smaller text, maybe in a collapsible section that starts off collapsed. But I'd agree that such a section wouldn't interfere with the navigational aid that should remain the dab page's primary focus. -- JHunterJ (talk) 00:46, 9 April 2009 (UTC)Reply
I am OK with re-visiting this, even though in all honesty I am not exactly overjoyed with the prospective. Would you like to start the discussion there? It doesn't need to be a vote (probably even shouldn't be one at this point), but at least we could try collecting other people's ideas on how the red links can be handled differently. I think, a separate section might work for just fine, but others of course may view it differently.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 14:49, April 9, 2009 (UTC)

List icon

edit
 
File:List gray.svg
 
File:List.svg
 
File:List2 gray.svg
 
File:List2.svg
Here are my quick renditions based on the disambig icons. EdokterTalk 12:40, 7 April 2009 (UTC)Reply
I personally like the first one, at least as an interim solution. Any other thoughts?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 15:21, April 7, 2009 (UTC)
Edokter: You are a frickin' genius! I love your List gray.svg.
So let's try how it looks. I added the generic set index article box below but with your image. And for comparison I added some other versions and the generic disambig box.

__DISAMBIG__

I think the grey list icon looks great! I would like to deploy it right away, as the default image for type="setindex" in {{dmbox}}. But Edokter, could you make a separate version with the lines slightly thinner, and the dots slightly smaller? But just very very slightly thinner/smaller. I would like to see how that looks.
--David Göthberg (talk) 17:04, 7 April 2009 (UTC)Reply
  Done. I've updated the images (removing an error in the process), but it is hardly noticable here, but it should look less 'cramped' for space. EdokterTalk 18:05, 7 April 2009 (UTC)Reply
Ah, you added some more images. I see what you mean by   so it is also a valid option. But I think it is too similar to the old disambig icon  , thus making the difference less noticeable. So I still prefer  .
I see you made the lines in   somewhat thinner, and I think it now is perfect, you added just the right amount of space.
Some other language Wikipedias prefer the red-blue disambig icons   and  . I guess that is why you made those versions already from starters? As a service to the other Wikipedias, in case they want to use them, right? Or do you prefer the colourful versions?
--David Göthberg (talk) 21:42, 7 April 2009 (UTC)Reply
If I may, I also prefer  , whether in color or grayscale. Nice work! —Remember the dot (talk) 21:55, 7 April 2009 (UTC)Reply
I have no strong preference, but I also lean toward  ; I just hope to make a contribution while brushing up on my Inkscape skills. I made the colored icons because they do seem to come in pares, and they might be usefull in other message templates. So whatever the outcome, I'm glad I could help. Please note that whatever is used must be protected at Commons. EdokterTalk 21:58, 7 April 2009 (UTC)Reply
While I've no problem with leaving the disambig icon on set indices, if it is to change, then I also prefer   in gray. Thanks. olderwiser 22:09, 7 April 2009 (UTC)Reply
Ditto. Happymelon 11:05, 8 April 2009 (UTC)Reply
Prefer parallel lines over the three-way (whatever colors). Having read the Talk(s) on this, SAI differs systematically from DAB (and, btw, all from surname-lists). -DePiep (talk) 17:39, 8 April 2009 (UTC)Reply
I've implemented the   icon in the sandbox. See the result on the testcases page. EdokterTalk 21:30, 8 April 2009 (UTC)Reply
Looks good. Protected on commons, implemented here. Break out the champagne :D Happymelon 21:34, 8 April 2009 (UTC)Reply
I did some checks and tests: Code good, looks good, all good!
Happy-melon: Ah, good that you also protected the local page here at enwp for the image.
/me sips some champagne, gets drunk, and goes editing some site wide CSS...
Oh, and we need to update the documentation of {{dmbox}} accordingly.
--David Göthberg (talk) 22:44, 8 April 2009 (UTC)Reply
Updated the /doc, having a beer. EdokterTalk 23:44, 8 April 2009 (UTC)Reply

Category proposal

edit

Please see Wikipedia:Village pump (proposals)#Message box categories. Thanks. Dragons flight (talk) 07:01, 3 June 2009 (UTC)Reply

Surname pages should be considered by bots as disambig pages

edit
This discussion was moved here from Template talk:Surname, since it is a continuation of the "Category:All disambiguation pages" discussion above. --David Göthberg (talk) 17:04, 17 February 2010 (UTC)Reply

Recently bots on other languages are removing (correctly placed) iw to surname pages on english wikipedia. The problem is that (new?) interwiki bots are removing in disambig pages any interwiki to non-disambig pages. Surname pages are actually disambig pages (and very often they also contain links to non-surname pages eg.1, 2, 3, 4, etc. but this template is no longer considered a disambiguation template. I suggest to urgently categorize this template as disambiguation template in order to block this wrong behaviour. -- Basilicofresco (msg) 07:03, 17 February 2010 (UTC)Reply

I agree with Basilicofresco. The biggest part of the other languages are managing the list of surnamees as disamb pages (and, actually, they are disamb pages). Fale (talk) 16:12, 17 February 2010 (UTC)Reply

End of section moved here from Template talk:Surname. --David Göthberg (talk) 17:04, 17 February 2010 (UTC)Reply

The bots that remove those links are broken and we need to inform their owners about it. Bots are supposed to allow interwiki links between set index articles and disambig pages, the pywikipedia bot library even has special functions for that.
Here's the long explanation:
Right, many pages that use {{surname}} look more or less like plain disambig pages. But look at pages like O'Reilly and Bernard, they are articles about a name, and of course also have a list of notable people with those names. And those names are of course wikilinked if we have an article about that person. Those articles are clearly not disambig pages, they are simply articles or perhaps set index articles.
And the surname pages that currently just look like plain disambig pages don't have to remain like that, I think they may at any time be extended to become articles about that name. So they should not show the {{disambig editintro}} and should probably remain categorized in Category:All set index articles instead of Category:All article disambiguation pages.
But since set index articles and disambig pages are similar it was decided long ago to allow interwiki links between them. So bots are supposed to allow interwiki links between set index articles and disambig pages (and most interwiki bots do). The bots identify set index and disambig pages with the help of the list on MediaWiki:Disambiguationspage. As can be seen there the set index articles are listed in a special way, so other bots and tools that need to know only disambig pages don't react on the set index articles. While the interwiki bots are supposed to treat set index and disambig pages the same.
See the old discussion at MediaWiki talk:Disambiguationspage#Re-add ((surname)) for the technical details.
Over at Wikipedia:Bot owners' noticeboard#New interwiki bots behaviour: problems DJSasso mentioned something about what settings the interwiki bots should use. (I don't understand that part, since I don't run bots.)
--David Göthberg (talk) 22:25, 17 February 2010 (UTC)Reply
Surname-holder lists are not disambiguation pages -- the articles they list are not ambiguous with each other or with the title. No one expects to find an article on a general person to be titled with the person's last name (or first name) alone. Surname articles, whether they are list articles or set index articles (a subset of list articles, not of disambiguation pages) or fully-developed Wikipedia:WikiProject Anthroponymy articles, are valid link targets. Sometimes list articles look like dab pages, but that doesn't make them dab pages. None of them should be categorized as disambiguation pages, unless the name-holder list version is currently short enough that it is just a section in a dab page, waiting until it gets large enough to be spun off to its own article. See also Wikipedia:WikiProject Anthroponymy#Background reading. Whether the bots need to continue to enforce this separation of surname articles on one Wiki when they may be considered disambiguation pages on other Wikis is a separate question. -- JHunterJ (talk) 14:06, 18 February 2010 (UTC)Reply
While some very small portion of links to set index articles or surname pages might be valid links, unless the list article is titled uniquely as "list of Foo" or "Foo (surname)", it is very likely that most of the links to such a page are in fact incorrect and should be disambiguated (and yes, that is the correct term to use for activity of correcting mistaken links to such pages, even though some would like to pretend that there is a meaningful distinction based merely on arbitrary definitions). In my opinion, such ambiguously titled pages should be included in the lists of pages that require disambiguation. olderwiser 23:19, 18 February 2010 (UTC)Reply
JHunterJ: Your description of what the surname articles are is correct. But I think you might have misunderstood what the interwiki bots usually do (or perhaps I am misreading your comment). Most interwiki bots (the correctly working ones) allow links between set index articles here on enwp and disambig pages on other Wikipedias. So the interwiki bots do not enforce a separation, on the contrary they consider our set index pages to be "disambig similar". Interwiki bots that do not consider set index pages as "disambig similar" are malfunctioning, and as usual should be blocked until the bot owner has fixed his bot.
I live in Sweden. I speak three languages and can read most of the Northern European languages since they are fairly similar. So I use interwiki links a lot. And I agree with the bots, a disambig page on the German or Swedish Wikipedia often is the best interwiki target from a set index page here on enwp.
That's why MediaWiki:Disambiguationspage lists both disambig templates and set index templates, since that is the page that the bots look at to learn what templates to look for to identify what a page is.
But that page is also used by MediaWiki to know what pages are not articles but instead disambig pages, so MediaWiki can list the correct number of articles on Special:Statistics and other places. So we list the set index templates in a special way on that page, so that MediaWiki can count only the disambig pages, while the bots can count both the disambig and set index pages.
older ≠ wiser: I don't understand how what you just said relates to interwiki links? I assume it was just a comment about set index and surname pages in general, right?
--David Göthberg (talk) 02:08, 19 February 2010 (UTC)Reply
Sorry, I may have gotten this confused with some other discussions. I agree that iw links should be able to cross-link between disambiguation pages in one language and sia/surname pages in English wikipedia. olderwiser 02:23, 19 February 2010 (UTC)Reply
Yep. Whether some disambiguation pages are incorrectly tagged as set index articles is a different question. If an article is a set index article or a surname article or a surname list article, then it isn't a disambiguation page. If it's a disambiguation page, then it isn't any of those. The only potential overlap is when a disambiguation page has a surname-holder list embedded, and then it still only gets the disambig template. -- JHunterJ (talk) 05:00, 19 February 2010 (UTC)Reply
Those are precisely the arbitrary definitions I was referring to. What you seem to consider as a separate question (Whether some disambiguation pages are incorrectly tagged as set index articles) is really the crux of the issue as the vast majority of such pages are that. There is a disconnect between the arbitrary definitions you quote and actual practice. Decisions should be based on actual practices not arbitrary definitions. olderwiser 12:04, 19 February 2010 (UTC)Reply
There is a disconnect, yes, but it's between the English language and useful navigation on one side and poorly-formed SIAs on the other. If there's ambiguity, disambiguation is needed. If disambiguation isn't needed, there's no ambiguity. If a page is disambiguating entries, then it's a disambiguation page, and should be labeled as such. If a page isn't disambiguating entries, then it's not a disambigation page, and shouldn't be labeled one. Those definitions aren't arbitrary at all. Labeling a disambiguation page as a set index article instead, possibly because one would rather not follow the dab style guidelines, is a problem, and the fix is to identify them correctly (that is, either replace the SIA tag with a dab tag, or make the SIA tag part of the dab umbrella, which also means cleaning up SIA articles according to the dab guidelines, since the guidelines are there to help the readers who are apparently being served the same navigational assistance by SIAs as by dabs). -- JHunterJ (talk) 12:32, 19 February 2010 (UTC)Reply
David Göthberg: Yep, the bots and the lists that they use can make any cross-connections they like. I was just correcting the statement at the top of this section that "Surname pages are actually disambig pages" -- they aren't. -- JHunterJ (talk) 05:04, 19 February 2010 (UTC)Reply

Editprotected to add alternative attribute

edit

{{editprotect}} Please add blank alt attribute and link attribute, |alt=|link= to those file embedding syntax, Image:List gray.svg and Image:Disambig gray.svg, as per WP:ALT# Blank alt text problem for image-disabled browser or screen reader users because those icons are purely decorative. Thx. -- Sameboat - 同舟 (talk) 09:02, 14 April 2010 (UTC)Reply

  Not done Both images have attribution requirements, so need to link to their description pages. —TheDJ (talkcontribs) 15:36, 14 April 2010 (UTC)Reply
@TheDJ: If that's the case, then surely using |link= on any image is forbidden, which it clearly isn't. I agree with Sameboat that the presence of an extraneous link for this decorative icon is an accessibility problem. — Scott talk 12:51, 28 June 2014 (UTC)Reply
Not all freely licensed images (ie. public domain) require attribution. -- [[User:Edokter]] {{talk}} 14:13, 28 June 2014 (UTC)Reply

{{editprotected}} That's true, but we should still have some sort of alt text on there. I propose

  • adding |alt=Diverging arrows to [[Image:Disambig gray.svg|30px]]  
  • adding |alt=List of arrows to [[Image:List gray.svg|30px]]  
  • at the same time, Image: could be changed to File:

Is the wording of the alt text ok? Can anyone come up with something better? --h2g2bob (talk) 21:49, 6 February 2011 (UTC)Reply

Second thoughts, using "Disambiguation icon" as the alt text in both cases may be more appropriate? --h2g2bob (talk) 01:35, 23 February 2011 (UTC)Reply
  Added — Martin (MSGJ · talk) 19:22, 27 February 2011 (UTC)Reply

Please put DISAMBIG inside includeonly tags

edit

Please put the __DISAMBIG__ magic word inside <includeonly> tags. This will prevent disambiguation templates from accidentally showing up as disambiguation pages. Thanks. Kaldari (talk) 22:44, 2 September 2014 (UTC)Reply

It already is inside a #ifeq: function, so there is no chance of that happening. If this happens in other templates, putting it inside <noinclude> tags here won't help. -- [[User:Edokter]] {{talk}} 23:27, 2 September 2014 (UTC)Reply

Should talk pages be categorized?

edit

...or should categorization into Category:All disambiguation pages be suppressed, as it is for templates? See Template talk:Disambiguation#Edit request - Limit categorization to article space. – Wbm1058 (talk) 13:46, 22 September 2014 (UTC)Reply

After a read of Category:All disambiguation pages, it looks like those who formed this template actually do want all namespaces except template space:
This category lists disambiguation pages in all namespaces. (For technical reasons it does not list pages in the template namespace, but there should be no disambiguation pages there anyway.)
It appears that this template was designed to, among other reasons, help maintainers track usage in namespaces other than mainspace. They probably wanted to track template space, as well, but couldn't because of technical limitations. – Paine 
I went ahead and put a talk-page exclusion in the sandbox; however, I still have to wonder why the designers wouldn't have done that if they didn't want to monitor dab usage on talk pages. – Paine  13:04, 24 September 2014 (UTC)Reply

Disambiguator not using parameter

edit

As well as there could be a need to use a template which normally would categorize the page on a page, there could be need to use a disambiguation template without marking page as a disambig. (e.g. Wikipedia:Template messages/Cleanup is no disambiguation but is marked as one now). For the first case we have nocat, for the second we have nothing atm. Thus I suggest to create a parameter which allows use templates without marking page as a disambiguation. Nodisambig or whatever. I don't have a TE flag so it's up to ya :) --ᛒᚨᛊᛖ (ᛏᚨᛚᚲ) 17:38, 22 April 2015 (UTC)Reply

@Base:, May be just enouph to modify code like that:
Magic word for disambiguation pages: {{#if:{{{nocat|}}}||{{#ifeq:{{{type|}}}|disambig|__DISAMBIG__|}}}}

I dont see where nocat parameter would be used without nodisambig and vice versa--Avatar6 (talk) 06:49, 6 May 2016 (UTC)Reply

I'm not sure I understand the problem. What Wikipedia:Template messages/Cleanup templates currently mark a page as disambiguation where it soul not? {{disambiguation cleanup}} should mark a page as disambiguation. Is there another? olderwiser 10:51, 6 May 2016 (UTC)Reply
Bkonrad, The page "Wikipedia:Template messages/Cleanup" itself is now marked as a disambiguation technically, while it should be not as it is not a disambiguation semantically. Avatar6 you are probably right, though personally I am in favour of providing more flexibility just in case. In any case, as it's a meta template we need to also think on how to then use the way we provide in based on it templates. --ᛒᚨᛊᛖ (ᛏᚨᛚᚲ) 14:48, 6 May 2016 (UTC)Reply
I came here about the same issue. If a page for example says {{disambig|nocat=yes}} then it's demonstrating how {{disambig}} looks and not marking a real disambiguation page, so __DISAMBIG__ should not be added. I think we can use nocat to both omit a category and the magic word. I doubt a caller ever wants the magic word without a category but if they do then they can just write the magic word themselves. It's technically possible to remove the magic word at the call with code like {{Replace|{{disambig|nocat=yes}}|__DISAMBIG__|}}, but it's a kludge few users will know about or use. PrimeHunter (talk) 23:28, 7 November 2017 (UTC)Reply
This is still an issue with other templates in the same family. While {{disambiguation}} itself was fixed as indicated above, which stopped the miscategorization of Wikipedia:Template messages/Cleanup, Wikipedia:Template messages/General is currently still being miscategorized by its {{geodis}}, {{hndis}}, and {{numberdis}} example transclusions. I've made the same fixes from {{disambiguation}} in the sandbox version of each of the three templates, and submitted {{editprotect}} requests on their talk pages to get those fixes installed. -- FeRDNYC (talk) 01:46, 30 January 2019 (UTC)Reply
Thanks to Alex 21 who processed my {{edit template-protected}} requests, this is now cleared up and Wikipedia:Template messages/General is no longer miscategorized as Category:Disambiguation pages with short description.
( All of the other templates in Category:Disambiguation message boxes lack the same protections, and can't be used in examples without triggering miscategorization... though as far as I can tell, there are no current uses where that would be a problem. Still, if someone's feeling ambitious, for the most part the templates in question — I'm talking about {{Airport disambiguation}}, {{Biology disambiguation}}, and the like — don't seem to be edit-protected. All they probably need is the addition of | nocat = {{{nocat|}}} parameter propagation inserted into the existing {{Dmbox}} transclusion.) -- FeRDNYC (talk) 12:11, 31 January 2019 (UTC)Reply

Marking setindex pages as __DISAMBIG__

edit

I want to suggest the following change.

Before:

{{#if:{{{nocat|}}}||{{#ifeq:{{{type|}}}|disambig|__DISAMBIG__|}}}}

After:

{{#if:{{{nocat|}}}||__DISAMBIG__}}

Reason: Currently only type=disambig is marked as a __DISAMBIG__, and not type=setindex pages. But setindex pages such as Valcke and Bass Lake (Ontario) are disambiguation pages and should be marked as such to make it easier to notice when you've accidentally linked to a setindex page.

--213.220.69.160 (talk) 13:15, 14 June 2019 (UTC)Reply

No set index pages such as Valcke and Bass Lake (Ontario) are NOT disambiguation pages and should not be marked as such. olderwiser 15:20, 14 June 2019 (UTC)Reply
All right, I'll disable this edit request. However, I thought this would be helpful as linking to Bass Lake (Ontario) will almost certainly have been a mistake by an editor. 213.220.69.160 (talk) 16:10, 14 June 2019 (UTC)Reply
There are also SIAs that it is reasonable to link to (e.g. Nitrogen oxide). A wide range of pages have been badged as SIAs; IMO most, if not all of them, should be changed (back) to a dab, changed to an article or deleted... DexDor (talk) 16:37, 14 June 2019 (UTC)Reply

accidental coding of this Talk page as a disambiguation page

edit

This page is coded, somehow, to be a disambiguation page. For editors with settings that show a different color (orange for me) for disambiguation pages, the link Template talk:Dmbox from another page shows that. I can't figure out where/how it is coded, to remove it. --Doncram (talk) 04:27, 8 September 2019 (UTC)Reply

The #List icon section had an active __DISAMBIG__. I have placed it in <nowiki>...</nowiki>.[1] PrimeHunter (talk) 10:16, 8 September 2019 (UTC)Reply

Recent revert

edit

I have reverted a recent change to this template that converted a table tag to a div tag. This change had caused Linter div-span-flip errors (a div tag inside of a span tag, which is invalid) in more than 75,000 articles. – Jonesey95 (talk) 18:51, 20 February 2021 (UTC)Reply

Jonesey95: Thanks! Yet, six days later, over 750 pages using Template:Surname, Template:Human name disambiguation, Template:Given name, Template:Place name disambiguation, and their aliases are still bogusly listed at Linter div-span-flip errors. I hope Wikipedia's automated processes remove these bogus lint errors soon. —Anomalocaris (talk) 22:31, 26 February 2021 (UTC)Reply
Yes, that's T132467 and the related T157670, a very old feature request that has not gotten better over the years. Page refreshes are sometimes slow, sometimes fast. – Jonesey95 (talk) 23:21, 26 February 2021 (UTC)Reply
They're finally all gone now. —Anomalocaris (talk) 01:09, 27 February 2021 (UTC)Reply
I null-edited them. I don't have the right level of access to refresh thousands of articles, but I can get rid of a few hundred. – Jonesey95 (talk) 02:10, 27 February 2021 (UTC)Reply
Did you go to the lint error page, right click on each "edit", open a new tab, and save, like 750 times, or do you have a more automated method? —Anomalocaris (talk) 05:32, 28 February 2021 (UTC)Reply
I'd rather not go into specifics. I use scripts to help with a variety of tedious editing tasks. – Jonesey95 (talk) 18:44, 28 February 2021 (UTC)Reply

Categorisation

edit

Would it be possible for templates that use this meta-template with |type=disambig to be automatically placed in Category:Disambiguation message boxes? — Martin (MSGJ · talk) 14:22, 1 December 2023 (UTC)Reply

Template-protected edit request on 20 April 2024

edit

Hi, the icon is clickable, which leads to the image page of the icon, which should preferrably not happen. Therefore I suggest adding an empty "link" tag:

Change this: |30px|alt=Disambiguation icon]]

To this: |30px|link=|alt=Disambiguation icon]]

Thanks. --CyberOne25 (talk) 13:30, 20 April 2024 (UTC)Reply

  Not done Clickability of the icon is required for attribution. * Pppery * it has begun... 17:32, 20 April 2024 (UTC)Reply
I don't understand. All icons i try to click on don't lead to an image page. E.g. look at Wikipedia:Policies and guidelines and try to click on the nutshell or checkmark icon. You can't click them. Clickability is useless in such cases. Btw. you also cannot click the padlock icon at the top of this section. This clickability is rather infuriating e.g. when your finger accidentally touches the icon. CyberOne25 (talk) 17:40, 20 April 2024 (UTC)Reply
Those examples (File:Green check.svg, File:Walnut.png, and File:Template-protection-shackle.svg) do not have licenses that require attribution, unlike the image used in this template (File:Disambig gray.svg). SilverLocust 💬 18:02, 20 April 2024 (UTC)Reply
Oh right, I understand now, thanks. CyberOne25 (talk) 18:45, 20 April 2024 (UTC)Reply