Wikipedia talk:Hatnote/Archive 6

This is an archive of past discussions on Wikipedia:Hatnote. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 4

Hatnotes in response to google searches

I reverted a change on Thomas Cubitt which changed "For the British general, see Thomas Cubitt (British Army officer)" to "For other uses, see Cubitt" (the user made multiple edits at this time adding the latter hatnote to every article listed at Cubitt). I was reverted on the Thomas Cubitt page with the rationale "without this hatnote a google search for cubitt leads to this cul de sac." When you search google with Cubitt, the first wikipedia response is Thomas Cubitt, oddly enough. I'm curious, are we applying hatnotes on the basis of google searches now? According to the guidelines the only hatnote on the Thomas Cubitt page should be the one highlighting the ambiguity with Thomas Cubitt (British Army officer). But does this google thing change that? Benea (talk) 14:24, 22 September 2014 (UTC)

Disambiguation considers that hat notes to the DAB page should be included when the topics of several articles can be considered ambiguous, and the evaluation of ambiguity should be assessed through common sense. Cubitt is a common last name, and people can land on that article looking for some other person with that name (for example, searching Google for "cubitt UK wikipedia" and clicking on the first person result). It's the same principle of Ambiguous term that redirects to an unambiguously named article, with the "redirect" being a search query result. It would be reasonable to have a double hat note, linking first for Thomas Cubitt (British Army officer) and then for "other people with thant surname" to the index disambiguation page. Diego (talk) 16:15, 22 September 2014 (UTC)

Opinions differ about how far to carry this. It is foolhardy to attempt to anticipate every poorly formed Google search that might lead someone to an article they selected from search results when they actually wanted something else. older ≠ wiser 00:11, 23 September 2014 (UTC)

That's why linking to the DAB page is a good idea - this way we don't need to worry how the user arrived to the wrong article, we're always offering a relevant navigational path out of it. Diego (talk) 03:44, 23 September 2014 (UTC)

We have a better alternative for such cases called the Search box. older ≠ wiser 22:01, 23 September 2014 (UTC)

Search is not an alternative for navigation, they're complementary but serve different purposes. If you don't understand this principle of information architecture you can't make good suggestions for information retrieving interfaces.Diego (talk) 07:04, 24 September 2014 (UTC)

We can't anticipate the multitude of possible poor choices people might make when clicking links from outside of wikipedia and attempting to design our navigation around such possibilities is foolhardy older ≠ wiser 10:49, 24 September 2014 (UTC).

We can't anticipate them, but we can alleviate them. That's the whole point of hatnotes. We can and we should design our navigation with the assumption that readers can arrive to the wrong article because of similarities in the article titles. Linking to the most general place where such title is disambiguated is a simple and effective strategy that doesn't require knowing in advance which errors are more likely. Diego (talk) 12:03, 24 September 2014 (UTC)

There are different search engines, search results vary with time, and can depend on your location (and maybe which data the search engine has on you). A Google search on "Thomas" gives me two Wikipedia articles on page 1: Thomas the Apostle and Thomas Edison. That doesn't mean they should have ugly hatnotes to Thomas. Hatnotes are an annoying distraction to people who are on the right page, and if there is only one other article with a title which can be confused then a detour to a disambiguation page is annoying for many readers. Most people realize that the Internet is huge and Google gives many results. The scenario here is that a Google searcher is interested in someone else like William Cubitt but only search on "Cubitt" and then click a link saying "Thomas Cubitt". We should not take all such hypothetical scenarios into account if it means annoying the readers who make more meaningful searches and clicks. It would mean a hatnote on most biographies when the majority have a unique name in Wikipedia. PrimeHunter (talk) 13:14, 24 September 2014 (UTC)

I'm not suggesting adding hatnotes to all articles with an ambiguous name. However, Thomas Cubitt already had a hatnote, so it makes sense to use it for reaching Thomas Cubitt (British Army officer) and Cubitt (surname). Diego (talk) 13:25, 24 September 2014 (UTC)

Pandora's box. There simply is no good reason to add a hatnote to the generic surname from the article of a specific individual. It is of course necessary in cases like Einstein, where the base name redirects to the article for an individual, but such cases are the exception. older ≠ wiser 22:35, 24 September 2014 (UTC)

Again, read and understand the argument made. No one added a hatnote, the hatnote was already there. Diego (talk) 08:41, 25 September 2014 (UTC)

Irrelevant. There are hundreds if not thousands of articles about individuals who not only share the same first and last names, and therefore already have a hatnote, but also have the same surname as other persons. This change logically implied that all of those hatnotes should be expanded. I don't think this is a good precedent for all the reasons already given.older ≠ wiser 10:23, 25 September 2014 (UTC)

Your reasoning is irrelevant as well, as we are debating an article that appears as the first page of a search result for the single word "Cubitt" in the major search engine in the world (the first Wikipedia result, in fact), not thousands of other articles or other complex searches. Let's approach this debate in a different way: what exact improvement to Wikipedia do you see in this change? Describe it in terms of benefits for readers, not compliance with rules. Diego (talk) 11:28, 25 September 2014 (UTC)

So we're assuming a reader looking for someone with the surname "Cubitt", but without a clue as to what the first name is and they decide to click on the link to the first Wikipedia article they see (and not even the first or second or third link in the results) thinking that Wikipedia will provide them an easy way to figure out what they don't even know they're looking for. That's a pretty tall order. And by that reasoning EVERY SINGLE PAGE that is remotely ambiguous to anything else should have a hatnote. older ≠ wiser 00:51, 26 September 2014 (UTC)

You say that as if it was a bad thing. And yet, that is not what is being proposed. Start again and read everything that has been written, not what is in your mind. Oh, and you have still failed to explain why this removal of navigational information would be an improvement for the encyclopedia. Diego (talk) 08:56, 26 September 2014 (UTC)

A hatnote is a distraction to readers who are already on the right page. A long hatnote is a distraction to readers who could have found the wanted article with a shorter hatnote. We have no way of telling how many people arriving at Thomas Cubitt are looking for somebody called Thomas Cubitt or just Cubitt or just Thomas, or something with no overlap to the title. Consensus has decided that hatnotes should generally be for topics which can be cofused with the whole title and not just a word in the title. The latter would give lots and lots of extra or longer hatnotes which would distract many readers. I don't think it would be practical to make an exception saying "If a Google search by you (results for others may be different) on a partial article name currently gives that article on the first page of search results then add a hatnote or extend an existing hatnote." Should editors then be expected to make a Google search before changing an odd looking hatnote, just in case somebody had made it for Google reasons? And as mentioned, Google results change with time and with the searcher, and Wikipedia also has reusers who don't get their readers from Google searches. PrimeHunter (talk) 10:09, 26 September 2014 (UTC)

@Diego Moya, 1) Yes it is a bad thing and it is the logical result of what you suggest. 2) I have read everything that's been written here, thank you for the condescension. 3) What I've done is explain how the suggested expansion of the hatnote does not improve the encyclopedia nearly as much as you think it does and in fact sets a bad precedent. older ≠ wiser 10:31, 26 September 2014 (UTC)

(edit conflict)I don't see it as an exception, but as the rule of why hat notes exist. A link to the disambiguation page for the ambiguous name is needed because as Trystan explains below, that's the way people use the Internet. There's no need to tie it to Google searches; the rule can be "if a hat note exists between two articles for other reasons, make sure that it links to the disambiguation page where both articles are listed". This is pretty much in line with "Linking to a disambiguation page"; the hat note exists at Thomas Cubitt because it's used as a primary title.

All these excuses that "we don't know anything about user behavior, yet we know that hat notes bother them" amount to "we shouldn't adapt our navigation tools to the way people actually use navigation"; there's solid research that links pointing back to structural pages improve navigation, and unneeded elements are ignored by banner blindness and thus less distracting that you make them appear. Diego (talk) 10:33, 26 September 2014 (UTC)

This is very much an exception to current practice. We do not in general link to the disambiguation from titles that are not actually ambiguous (or that are at best very weakly ambiguous partial title matches). The very same rationale for adding a link to the disambiguation page for these cases (multiple persons with the same given name and surname) where a hatnote already exists would also apply to any cases where an individual shares a surname with other persons. At best, a link to the surname article might be provided as a link in a see also section, but it is an unnecessary waste of space in a hatnote. older ≠ wiser 14:59, 26 September 2014 (UTC)

We have a substantial body of research on how people search the web. They are comparatively much better at navigation than at search, and much prefer the former. They often try the first search that comes to mind and then click on the first link that looks remotely correct. Consequently, they often end up at the wrong place and look for a clear navigational path to the right one. Effective sites are designed with these principles in mind. By comparison, the mindset that a user landing on the wrong page should go back and search again, only do it better this time, isn't going to result in a highly usable design.

Hatnotes, as they currently exist, may not be the most attractive things, but they aren't quite so ugly that I am willing to hinder people from getting to the right article or choose to disbelieve the research on information seeking behaviour.--Trystan (talk) 13:40, 25 September 2014 (UTC)

Readers coming to Thomas Cubitt from a Google search on "Cubitt" don't have to go back to Google and come up with a better search if they want a Wikipedia article about another Cubitt. They can just search Cubitt in our own search box. If they clicked "Thomas Cubitt" at Wikipedia on Google's page then they probably either want somebody named Thomas Cubitt or they know Wikipedia is large and can be searched further. Google also shows excerpts to help searchers. The one for "Cubitt" is very informative: "Thomas Cubitt (1788–1855), born Buxton, Norfolk, was the leading master builder in London in the second quarter of the 19th century, and also carried out ...". This is typical since we usually start with a definition or main description of the subject. How many are really going to click that link if they want a different name with a different profession? PrimeHunter (talk) 13:06, 26 September 2014 (UTC)

As I commented above, search is not an adequate replacement for navigation, and it's used as a last resort. The behavior you describe is simply not how people use the internet and search engines, it's opposite what studies about information retrieval tell us. Almost anyone wanting to read about a topic on Wikipedia will click on the first link to Wikipedia in the results, and navigate from that page using the information scent of links in it; if the page does not look promising, the user is likely to navigate back to Google and try the next link. This is what people *does*.

There's even a name for this anti-pattern, "pogo-stick navigation". If the target page does not provide a link that suggest how to reach their target, the reader may not even know if we have an article for the person they're looking for. Search is used as a last resort, when everything else fails. You're proposing a design that makes our readers fail, according to well-known behavior models. Diego (talk) 13:46, 26 September 2014 (UTC)

This is a mildly interesting, but highly speculative interpretation about how people navigate Wikipedia and how they use hatnotes and what they actually expect. older ≠ wiser 14:59, 26 September 2014 (UTC)

So, you have more idea of how readers use hat notes, that you feel confident to suggest how we should be writing them? Diego (talk) 18:57, 26 September 2014 (UTC)

Only to the extent that the current practice on Wikipedia seems to work acceptably well. If you want to propose changes to current practices, I think some substantive evidence that the changes are better than current practice would be needed. older ≠ wiser 20:13, 26 September 2014 (UTC)

Reply to Bkonrad: 1) you keep asserting "it's bad" without explaining why it's bad. 2)Then why you keep ignoring that it would affect only already existing hat notes, not all ambiguous pages? 3) So you admit it provides *some* benefit. Diego (talk) 10:36, 26 September 2014 (UTC)

It is bad because it is entirely unnecessary and superfluous. While you can claim it would only affect already existing hatnotes, the very same rationale would justify including hatnotes on any article where the title is an unambiguous partial title match with an existing disambiguation page (or even to any other existing article that is remotely ambiguous -- because, after all, Almost anyone wanting to read about a topic on Wikipedia will click on the first link to Wikipedia in the results, and navigate from that page using the information scent of links in it. older ≠ wiser 14:59, 26 September 2014 (UTC)

Is hatnoting mandatory, or is it subject to page-decide?

"When two articles share the same title, except that one is disambiguated and the other not, the undisambiguated article should include a hatnote with a link to the other article. It is not necessary to create a separate disambiguation page..." An IP seems to be interpreting this as saying that hatnoting is mandatory: [1]. I believe that both common sense and a reading of the guideline say that it's not mandatory; the guideline merely says that, if a link is desired by the page editors (that is, if it's not a "hatnote a serious topic to a Simpsons episode" situation), there should be a link from the undisambiguated article to the disambiguated article, rather than a separate disambiguation page. Which interpretation is correct? Rolf H Nelson (talk) 05:51, 18 August 2014 (UTC)

I hear you, but you don't consider whether a topic is notable or not when deciding on whether to place a hatnote. So, the parenthetically disambiguated Cryonics (album) is notable, because we have an article on the topic. Now I see it has been tagged with a {{Notability}} template, and it can be taken to WP:AFD on grounds of lack of notability if you want. But, probably an easier way to get it off the top of the Cryonics article is to create Cryonics (disambiguation), noting that Cryonics – Freeze Me and Cryonics Institute could also be listed on the dab. Then you could replace that hatnote you don't like with an {{otheruses}} hatnote. – Wbm1058 (talk) 11:58, 18 August 2014 (UTC)

Cryonics – Freeze Me fails notability, and Cryonics Institute fails WP:PTM. So I'll see if I can get Cryonics (album) deleted. Rolf H Nelson (talk) 05:18, 19 August 2014 (UTC)

If there was a dab page, then the album would merit a dab page entry linking to the band even if it didn't have an article for the album (see WP:DABMENTION). By the same logic there should be a hatnote to the band for the album title, even if the album page was deleted. PamD 07:23, 19 August 2014 (UTC)

It is mandatory that there is a way to get from the title "Cryonics" to the disambiguated title Cryonics (album). If there are enough entries for a dab page, then create a dab page, and add a hatnote to link the dab page from Cryonics. If not, then it has to be a hatnote linking to the album. Yes, there are various cases where a rather minor article then gets a hatnote link from the top of a substantial serious article on a serious topic, but that's just something we have to live with. PamD 15:05, 18 August 2014 (UTC)

The portion of the guideline you cited is straightforward: The need for the hatnote depends on the article titles alone. The relative importance of the topics is not a consideration. If a user lands on the article cryonics looking for the album, we must provide a navigation option, either to the article directly or, as others have suggested above, to a disambiguation page. —99.26.129.92 (talk) 18:58, 18 August 2014 (UTC)

In that case, to avoid confusion for future editors, please change the top of the disambig and/or hatnote WP page to say that more clearly rather than bury this important item halfway through. BTW this policy doesn't make sense to me (if you can't tell). If I search for "Cryonics" on Google, I don't get the album *anywhere* on the first result page, nor the second page, nor the third page (I didn't check any farther)... and yet it's required to be the very first thing on the Wikipedia page? So clearly either Google sucks at displaying relevant information to Internet users, or we do. Peace out. Rolf H Nelson (talk) 05:18, 19 August 2014 (UTC)

That just shows the difference: Google is a collection of links to stuff which is randomly out there on the internet. Wikipedia is an encyclopedia. We do things differently. PamD 07:23, 19 August 2014 (UTC)

WP has nowhere near the sophisticated link-weighting that Google has. We have exactly one page on "Cryonics" and one page on "Cryonics (album)", and so from our search engine they are given equal weight if you search for "Cryonics". Google has likely tracked millions of pages for "Cryonics" and a much smaller number for the album, hence the reason searching there doesn't bring up the latter. --MASEM (t) 13:29, 19 August 2014 (UTC)

Yes, the idea is that we need to make it easier to find the album by searching Wikipedia for it than it is to find it by using Google. Wbm1058 (talk) 14:05, 19 August 2014 (UTC)

If you type "Cryonics" in the standard search box, where everything begins, then a dropdown list appears with 4 items.

Cryonics
Cryonics Institue
Cryonics – Freeze me
Cryonics (album)

So if user wants the album, it's right there in front of them. Must a serious article have a hatnote to a minor album, just because the user can't be bothered to read the list? If they don't see what they want, there's always the last item in the list, which is "containing... Cryonics". They can find it that way.

It says in the article: "Direct links to other articles should be limited to circumstances immediately following a page move or redirect change, or if the other article could be reasonably expected by a significant amount of readers to be at the title in question". To me, that disqualifies the album. I really don't think we have to list every article title that contains related words. – Margin1522 (talk) 21:24, 11 October 2014 (UTC)

Redirect hatnotes for shortcuts

I would like to propose a policy: that hatnotes about shortcuts be discouraged.

For example, today I was trying to find out whether a cleanup message box should be placed above or below hatnotes. I found that information (they go below) in the article Wikipedia:Template messages/Cleanup. But before I could get to it, I had to read the following hatnote:

"WP:TC" redirects here. For WikiProject Tropical cyclones, see WP:WPTC. For the Wikipedia Triple Crown, see WP:CROWN.

I grant that the WikiProject and the Triple Crown are worthy endeavours. But really, how many people arrive on the Template messages/Cleanup page by mistake, because of the shortcut, when they really wanted to go to Tropical cyclones project? And even if they do, presumably they've been there before. Surely they should be able to find it again.

To me, it seems like these shortcut hatnotes are a prime cause of hatnote clutter at the top of useful articles. The same goes for this article. It has the following hatnote:

"WP:HAT" redirects here. For Wikipedia essay on hat collecting, see WP:HATSHOP.

Again, this is worthy essay. But it has nothing to do with this article except a 3-letter shortcut that doesn't lead to it.
Shouldn't redirect hatnotes be limited to cases where the two articles are related in some way other than that one of them has a cryptic 3-letter shortcut that could conceivably point to either? To me that seems like an abuse of both hatnotes and shortcuts. Shortcuts are supposed to save typing. They were never intended to be the primary navigation method or the primary way to identify an article. If someone gets an unexpected result from typing a shortcut, it's not like they are lost and have no other options. So why clutter up the top of the article worrying about that? – Margin1522 (talk) 20:41, 11 October 2014 (UTC)

"Shouldn't redirect hatnotes be limited to cases where the two articles are related in some way other than that one of them has a cryptic 3-letter shortcut that could conceivably point to either?" I think you've got a point, they do add to clutter, and if the user searches for the right term they will be told what the shortcut was in the shortcut box. Now if you were to delete these hatnotes, would you being going against policy/guidelines? I'm not really sure to be honest, it would be something you would need to look up.

By the way, I personally don't like the look of hatnotes above message boxes, I think it looks ugly. The hatnotes look better beneath message boxes I think. But it is a guideline so I guess we have to do it. --Mrjulesd (talk) 19:11, 14 October 2014 (UTC)

I've boldly removed the WP:HATSHOP note. I can't see how anyone would be end up here looking for it. In fact I can hardly imagine anyone looking for it. They might stumble across it elsewhere in a relevant list of essays or related topic. Or it will be linked to directly using its full name or the shortcut by someone who thinks it useful guidance. But it's not like an article on a topic someone can't remember the precise name of. If someone isn't aware of it they're not going to be searching for it. If they're aware of it they'll either know its name or be able to find it easily, among e.g. the handful of essays on administration.--JohnBlackburne^words_deeds 21:09, 14 October 2014 (UTC)

Thank you. I think these can be safely removed under the policy that to deserve a hatnote the article titles should be similar. Shortcuts are mainly for the Wikipedia namespace, and I grant that they are very handy on Talk pages. My concern is just that they are appearing in hatnotes over frequently viewed Help pages and guidelines. I think that could be handled with a sentence or two on the WP:Shortcut page, just to remind people of the policy that these are informal names and shouldn't appear in "official" places like hatnotes or the "See also" section in articles and guidelines. – Margin1522 (talk) 23:58, 14 October 2014 (UTC)

Notice above transcluded content

I added a {{Notice}} just above the transcluded content from Template:Hatnote templates documentation. This will help readers who are looking for this content in the wikitext and can't find it. Explain that they have to go to that page if they want to edit anything. The Notice also creates a little space for the weird "This overview/view talk edit" message that floats up above the "Hatnote templates" header.

It also helps people understand why it says "For the full guideline on hatnotes, see Wikipedia:Hatnote.", when we are on Wikipedia:Hatnote already, and is better than the old hatnote ("For hatnote templates documentation, see Template:Hatnote templates documentation.") because if you just want to read the templates documentation, you don't have to go there. You can read it here. – Margin1522 (talk) 07:18, 25 October 2014 (UTC)

That seems sensible. --Mrjulesd (talk) 12:19, 25 October 2014 (UTC)

NAMB, again

Hello, Sroc. The sentence "The presence or absence of such hatnotes has been a contentious issue, and this guideline doesn't prescribe one way or the other" at the WP:NAMB section was a added to signal that the whole idea of removing hatnotes at disambiguated articles is disputed. That sentence was added as a compromise, as an alternative to removing the whole section (which has been done several times), to indicate that this section should not be considered to have the weight of a guideline, yet still allowing editors to read it.

When you say it "should only apply to cases like Matt Smith (comics)", I don't know if you mean that those cases should include the hatnote or not; in any case, the example of "tree (set theory)" shows that this is always a muddy area, since that very article contains a hatnote to Tree (descriptive set theory) - despite what the guideline saying that it shouldn't have any. Diego (talk) 12:14, 5 January 2015 (UTC)

Hatnotes without links

There's a discussion at Template talk:Distinguish#Under what circumstances should this template be used without linking to an article? concerning the possibility that a hatnote might contain no links at all. --Redrose64 (talk) 14:21, 23 January 2015 (UTC)

Advice on hatnote to foreign language version

Hi. I added a hatnote to List of birds of Poland pointing to the Polish language version of the article. None of the current examples of proper and improper use given here at Wikipedia:Hatnote seem to directly apply to this case. The closest is WP:RELATED which, if anything, suggests not to use a hatnote but I don't think it well matches the circumstances. A good fraction of readers of List of birds of Poland would be specifically interested in the Polish version. Yes, there's a link to the Polish language version in the sidebar but in the case of a list like this, I think it the Polish version makes sense to stand out in particular. As a birdwatcher in Poland, I use this list personally and I find the hatnote to be a nice convenience over just the sidebar link (which usually requires scrolling). Wikipedia:Hatnote doesn't mention interwiki links in hatnotes at all. This must be a fairly rare case or it'd already be there. But maybe adding a new section discussing them is worthwhile. Do you agree or disagree with my usage of a hatnote in this list? Jason Quinn (talk) 12:17, 5 January 2015 (UTC)

I'd recommend against it. I can see how it would be helpful sometimes but hatnote space is precious and too much is distracting. It's not necessary since the link is already in the sidebar and people are used to looking there. It opens the door to slippery slopes; it could apply to millions of articles and some articles, like anything Swiss, would need links to multiple language versions. SchreiberBike talk 18:36, 6 January 2015 (UTC)

I too disagree with this: the interwiki links are there for this, and using a hatnote just has too many issues. Many many pages have ties to countries other than English speaking ones, so their articles in the languages of those countries may be better, or provide especially pertinent information such as names in the local language. So it would involve many many hatnotes. Hatnotes are already contentious because of their prominence and would become even more so with the question of whether and which language versions to link to. Versions as countries can have two or more national languages, which alone can be a source of contention.

One solution that might be acceptable would be a gadget. It might be possible for a script to detect whether a page has an equivalent on another wiki, the Polish one say, and highlight it more prominently at the top of the article. This would work across all pages, not just one, and be under user control so they make the choice over language. It could also display other information such as the page's name, whether it's a good or featured article. All this information's in Wikidata now so could in theory be retrieved. I imagine a few people would find this useful.--JohnBlackburne^words_deeds 19:29, 6 January 2015 (UTC)

I agree a general hatnote is not advised. Another possibility is {{Expand language}}. older ≠ wiser 00:37, 7 January 2015 (UTC)

Yes, and in this case the template would be {{Expand Polish}}. That would be a good idea if the OP wants to suggest that the article could be improved by adding the photos from the Polish version. That seems reasonable to me, since the photos would be useful to birdwatchers and even to readers in general. But about the idea of adding a section about interwiki links, if we did it would be to say "Don't do it". In general, the only consensus-based reason for adding a hatnote is to help readers who wanted a different article on the English Wikipedia and ended up at this article by mistake. Obviously nobody expects to find an article in Polish on the English Wikipedia. They may well come to this article hoping that it will have a link to the Polish version in the Language bar. But in that case they know exactly what they are doing and this article is the one they want. We don't need to suggest a different one. – Margin1522 (talk) 06:13, 7 January 2015 (UTC)

An "expand language" template would have the problem of being temporary, though. If the intent is to allow the reader to find the names of birds in the original language, it would make sense to have it even when both articles have the same content. Maybe it would make sense to have a dedicated template like those for Wiktionary and Wikibooks, but for articles in other Wikipedias which are particularly relevant because of their official languages? Meanwhile, an WP:Ignore all rules solution for such cases could be linking to the article as an external link directly in the prose of the lead paragraph, if there's consensus to do so. Diego (talk) 09:48, 7 January 2015 (UTC)

My view is, that while the use of hatnotes in these situations should not be encouraged, likewise it should not be prevented. It is a clear case of common sense use of hatnotes, slightly outside of guidelines, but acceptable all the same. My personal animosity to hatnote use is mainly when there is an excessive number. Clearly in this case it is not an issue.

I see now it has been removed, which I personally would not have wished. To me it would be acceptable to mention the Polish article in the lead, but of course that could be removed too.--Mrjulesd (talk) 11:44, 7 January 2015 (UTC)

The Polish article is mentioned in the lead. Feel free to revert my bold edit if you prefer the version with the hatnote. Diego (talk) 13:19, 7 January 2015 (UTC)

I still have reservations about that, since the policy at Help:Interlanguage links is to let Wikidata handle the links between articles in different languages. As a compromise, I moved it down to the External links section, which is the normal place for interwiki links. And as a bonus I added a link to Polish birds on Commons. I realize that this defeats the OP's purpose of making it easier to navigate to the Polish article. But at least we're letting readers know that images exist and where to find them. Is this OK? – Margin1522 (talk) 15:58, 7 January 2015 (UTC)

Moving it below the fold sort of defeats the purpose of the link, which was to give readers fast access with a link at the top, above the "Languages" section. Interlinks are not forbidden by policy, as Wikidata so far has proven itself incapable of supporting exceptional situations; complex cases are still handled through classic links, and local links allows them; so this is a good case for WP:IAR rather than blind rule-following for the sake of rules. I don't see why having the link as prose should pose any problem - it's no different from using the [[wikt:]] template to include an inline definition. Diego (talk) 16:49, 7 January 2015 (UTC)

You are misunderstanding the guideline. That at local links is about overriding the wikidata links, to provide e.g. a more precise link to a section, but still in the sidebar. For inline links the guideline is inline links and they are for articles that don't have a corresponding English WP article. It doesn't explicitly say it's not for links to another WP's version of this article but it doesn't need to, as the entire guideline up to that point has been on how to do such links, in the sidebar.--JohnBlackburne^words_deeds 17:10, 7 January 2015 (UTC)

I think Diego Moya's suggestion above and edit worked well. It's not overly obtrusive but it's in a useful place for the reader. I would suggest adding that the link is to Polish Wikipedia. SchreiberBike talk 20:38, 7 January 2015 (UTC)

I really disagree with using a hatnote for this. The inline link, later in the lead, is okay. We should allow the lead sentence to be the top thing the reader sees whenever possible. Hatnotes and lead sentences are already full of excessive trivia on many pages; if we start including external links the whole design of the page goes to hell. Yeah, somebody could save a few seconds but that, by itself, is not sufficient to crowd out the principal text of the page. There are too many conceivably useful things someone might want to "fast access"; not every hypothetical should override the basic design of the article. —Designate (talk) 23:09, 7 January 2015 (UTC)

There is currently a discussion at Wikipedia:Templates for discussion/Log/2015 May 7#Template:Main article interwiki which may be relevant to the above. PC78 (talk) 16:43, 11 May 2015 (UTC)

Demonstrate only one improper use at a time

The current examples for TRHAT and LEGITHAT also violate HATEXTRA. It might be less confusing for readers if we remove some or all of the wikilinks from those examples so as to demonstrate only one problem at a time; do you agree? --SoledadKabocha (talk) 01:27, 6 June 2015 (UTC)

@SoledadKabocha: No, these are actual real-life cases that existed at the time that the page was created.

The example for WP:TRHAT is in the original version of this page, 17:05, 14 September 2005; it was taken verbatim from this version of Investment. It is no longer exactly the same, because it was copyedited to add a comma at 21:09, 21 March 2006.

The example for WP:LEGITHAT is also in an early version of this page, 19:33, 14 September 2005; it was taken verbatim from this version of Aisha and remains unchanged to this day.

If any changes are made, I think that the comma added at 21:09, 21 March 2006 should be removed again in order to show the actual example that presumably prompted the creation of this page. --Redrose64 (talk) 12:26, 6 June 2015 (UTC)

Yeah, I realized that shortly after posting but was too lazy to look for the actual oldids. I know my original suggestion would be bad for historical authenticity reasons; I thought it wouldn't matter if we're not linking to the oldids anyway, but apparently you disagree.

In that case, could we add some wording under HATEXTRA to mention that the TRHAT and LEGITHAT examples also demonstrate said problem, or perhaps at the top of the whole "improper use" section to mention that some examples may demonstrate multiple problems?

I acknowlege that this idea is also dubious though. The real fix would be to find better examples that only show one problem each, but that would take time. --SoledadKabocha (talk) 18:26, 6 June 2015 (UTC)

Hatnote to similar names, but both are redirected

I moved the article at National Heritage Museum to Scottish Rite Masonic Museum and Library because the name changed. When I went to add a redir for the name previous to that, I found an redir for a National Heritage Museum (Arnhem) that redirs to Netherlands Open Air Museum. I added the hatnote, but does it make sense to hatnote the Scottish Rite Museum article for the Netherlands museum even though both similar names have been redired? MSJapan (talk) 21:43, 31 August 2015 (UTC)

Scottish Rite Masonic Museum & Library currently uses {{About}} to say:

That doesn't make sense. It could use {{Redirect}} to say:

However, it only makes sense if Netherlands Open Air Museum actually mentions "National Heritage Museum". But there is another problem: A search on "National Heritage Museum" shows other countries apparently have something which is sometimes called National Heritage Museum in English. Maybe there should be a disambiguation page. PrimeHunter (talk) 00:23, 1 September 2015 (UTC)

Where to draw the line on triviality?

This example strikes me as being too trivial to have a hatnote for; said otherwise, it is more distracting than useful. Should there be a guideline against including topics so trivial that a reader might be expected to use the search function rather than having examples like this dotted all over WP? —Quondum 14:01, 9 July 2015 (UTC)

Please see Wikipedia talk:Hatnote/Archive 3#Trivial hatnote links (a failed proposal). The rationale differed from yours, but the question of where to draw the line was addressed. Essentially, if a topic is sufficiently notable to have a Wikipedia article, it isn't too trivial to be linked via a hatnote.

Of course, if a hatnote must provide navigation to multiple articles, it might be appropriate to simply link to a disambiguation page. —David Levy 14:17, 9 July 2015 (UTC)

There's no such thing as trivial articles on WP. If a topic is notable enough to have its own article, then it's non-trivial, and if there is ambiguity about that article's title, then it should be disambiguated. --Deeday-UK (talk) 14:22, 9 July 2015 (UTC)

Thanks for the links. The archived discussion is voluminous and I have not thoroughly read it. It is clear that a hatnote for disambiguation of some sort is reasonable. The only question might be whether to create a disambiguation page with two topics for the hatnote to link to, but this appears to be a fuzzy area with conflicting opinions. —Quondum 19:10, 9 July 2015 (UTC)

I would've justified this with WP:PRIMARYUSAGE rather than triviality. Anyone looking for a small ghost town called Farad, California will already know that typing in just "Farad" probably won't take him to his article. -- œ^™ 05:49, 6 October 2015 (UTC)

Anyone looking for that ghost town has a right to expect that typing "Farad" will lead him/her there either directly or via a hatnote or dab page. But I found a Hungarian village of Farád which justifies the dab page I've just created at Farad (disambiguation). PamD 07:41, 6 October 2015 (UTC)

Creating a disambiguation page is a good solution to avoid an awkward link to a topic that is very trivial compared to the topic itself (which happens frequently, despite the 'trivial' topic being sufficiently notable for Wikipedia). In the extreme case, people could even be tempted to purposely name songs, novels, etc. after very common topics whose articles receive many page views, but do not have a hatnote yet, simply to attract ongoing attention to it. Gap9551 (talk) 23:20, 11 November 2015 (UTC)

Hatnote to articles outside English Wikipedia

What is the stance on adding a hatnot to an article that redlinks English Wikipedia, but does have an article on another language. Here is an example. It feels to me like we should not use hatnotes in this manner, but I did not see it covered specifically in this section. In the example given I undid the edit as both English WP articles don't exist. Rikster2 (talk) 19:45, 7 December 2015 (UTC)

@Rikster2: This sounds like Wikipedia talk:Hatnote/Archive 6#Advice on hatnote to foreign language version. --Redrose64 (talk) 20:12, 7 December 2015 (UTC)

NAMB needs better example

Currently, the WP:NAMB section of this guideline gives tree (set theory) as an example not needing a hatnote. But that article does have a valid hatnote (different from the one in the example) because there are actually two different notions of trees used within set theory and we have separate articles on both of them. Maybe we should find a different example? —David Eppstein (talk) 18:10, 15 January 2016 (UTC)

Done :) Codename Lisa (talk) 14:40, 16 January 2016 (UTC)

@Codename Lisa:There's some text right after the example that you might want to change too, it's talking about the old example. — Mudwater^(Talk) 14:54, 16 January 2016 (UTC)

Inline nested hatnotes CSS discussion

I suggested an improvement to hatnote CSS over at MediaWiki talk:Common.css#Inline nested hatnotes; please comment there. {{Nihiltres |talk |edits}} 06:38, 19 January 2016 (UTC)

Why not templates?

While reading the statement "In most cases, hatnotes should be created using a standard hatnote template", I wondered in what cases should we not use a hatnote template. I scanned the archives and didn't see any mention of this. Could someone please help me understand? Thanks! GoingBatty (talk) 18:19, 27 January 2016 (UTC)

I suspect it might have to do with using {{hatnote}} directly to make custom-phrased hatnote vs using the canned language in the many other "standard" templates. older ≠ wiser 20:19, 27 January 2016 (UTC)

Hi.

Given the status quo, I strongly believe that a hatnote must never ever be created using manual coding, e.g. using '' or :''. There are hatnote-like text in Japanese film and TV articles using manual coding but they are not hatnotes.

Best regards,

Codename Lisa (talk) 11:33, 2 February 2016 (UTC)

Dodge Tomahawk

Is this how to indicate edit history (with a hatnote)? We're in discussion at Talk:Dodge Tomahawk -- 70.51.45.100 (talk) 05:06, 14 April 2016 (UTC)

Distinguish templates

Is there some reason why {{distinguish}} and it variants are not currently mentioned as a subsection of Wikipedia:Hatnote#Examples of proper use? I could add such a subsection by copying the reasons from Template:Distinguish/doc and Template:Distinguish2/doc, as well as some of the points made in the last deletion discussion. Otherwise, they are not properly explained here as well as the other types of hatnotes. Zzyzx11 (talk) 23:13, 4 June 2016 (UTC)

Sounds reasonable to add. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:56, 18 June 2016 (UTC)

Standardizing for-see lists

At the moment, we have two primary hatnote templates that produce lists of "For X, see [[Y]]" disambiguation messages (here "for-see lists" for short): {{about}} and {{redirect}}. These have slightly different behaviours, especially as {{redirect}} is coded in Lua (via Module:Redirect hatnote) and {{about}} is still using wikitext. I've already made some changes to Module:Redirect hatnote to eliminate a few of its odder behaviours (see Module talk:Redirect hatnote for details).

I propose to standardize and centralize the behaviour of these lists. I've put together a prototype at Module:Hatnote list, which is in use at the prototype Module:About to implement {{about/sandbox}}, and at Module:Redirect hatnote/sandbox to implement {{redirect/sandbox}}. As a result, we can directly compare the current outputs of {{redirect}} and {{about}} with their implementations using Module:Hatnote list. I would like to migrate templates to use the code from this module, and this discussion will hopefully serve to establish consensus for that change.

For typical usages, the implementations produce identical output, but they vary in their defaulting/terminating behaviour. The implementations differ in their defaulting/terminating behaviour in two main ways: when they encounter empty parameters generally ("basic gaps"), and when they encounter empty parameters involving the and keyword ("and-gaps"; the and keyword allows lists of target pages within a single for-see item). For and-gaps, note that {{about}} supports and-lists of only up to 2 items; where this applies, the "ABOUT" text parameter has been changed to "UNSUPPORTED".

Centralizing will involve moving to a single standard behaviour. Where a move to centralized behaviour might change output "in the wild", I would add tests first to categorize affected pages into Category:Hatnote templates using unusual parameters or similar, as I did with updates to Module:Redirect hatnote. Those cases could then be fixed with more typical parameterization before migrating their affected templates to the new code.

In the following subsections are:

a list of examples of behaviour
a short explanation/justification of the behaviours used in the sandbox templates as implemented with Module:Hatnote list
a discussion section where we can discuss the desirability of the proposed changes

Feel free to add examples as needed. {{Nihiltres |talk |edits}} 17:26, 27 April 2016 (UTC)

Examples

Examples, now collapsed because obsolete

Empty

No parameters beyond basic:
{{redirect|REDIRECT}} →

{{redirect/sandbox|REDIRECT}} →

{{about|ABOUT}} →

{{about/sandbox|ABOUT}} →

</noinclude>

Basic gaps

USE1 gap:
{{redirect|REDIRECT||PAGE1}} →

{{redirect/sandbox|REDIRECT||PAGE1}} →

{{about|ABOUT||PAGE1}} →

{{about/sandbox|ABOUT||PAGE1}} →

</noinclude>

USE1 gap with USE2/PAGE2:
{{redirect|REDIRECT||PAGE1|USE2|PAGE2}} →

{{redirect/sandbox|REDIRECT||PAGE1|USE2|PAGE2}} →

{{about|ABOUT||PAGE1|USE2|PAGE2}} →

{{about/sandbox|ABOUT||PAGE1|USE2|PAGE2}} →

</noinclude>

PAGE1 gap with USE2/PAGE2:
{{redirect|REDIRECT|USE1||USE2|PAGE2}} →

{{redirect/sandbox|REDIRECT|USE1||USE2|PAGE2}} →

{{about|ABOUT|USE1||USE2|PAGE2}} →

{{about/sandbox|ABOUT|USE1||USE2|PAGE2}} →

</noinclude>

Double USE1/PAGE1 gap with USE2/PAGE2:
{{redirect|REDIRECT|||USE2|PAGE2}} →

{{redirect/sandbox|REDIRECT|||USE2|PAGE2}} →

{{about|ABOUT|||USE2|PAGE2}} →

{{about/sandbox|ABOUT|||USE2|PAGE2}} →

</noinclude>

USE2 gap:
{{redirect|REDIRECT|USE1|PAGE1||PAGE2}} →

{{redirect/sandbox|REDIRECT|USE1|PAGE1||PAGE2}} →

{{about|ABOUT|USE1|PAGE1||PAGE2}} →

{{about/sandbox|ABOUT|USE1|PAGE1||PAGE2}} →

</noinclude>

USE2 gap with USE3/PAGE3:
{{redirect|REDIRECT|USE1|PAGE1||PAGE2|USE3|PAGE3}} →

{{redirect/sandbox|REDIRECT|USE1|PAGE1||PAGE2|USE3|PAGE3}} →

{{about|ABOUT|USE1|PAGE1||PAGE2|USE3|PAGE3}} →

{{about/sandbox|ABOUT|USE1|PAGE1||PAGE2|USE3|PAGE3}} →

</noinclude>

PAGE2 gap:
{{redirect|REDIRECT|USE1|PAGE1|USE2}} →

{{redirect/sandbox|REDIRECT|USE1|PAGE1|USE2}} →

{{about|ABOUT|USE1|PAGE1|USE2}} →

{{about/sandbox|ABOUT|USE1|PAGE1|USE2}} →

</noinclude>

PAGE2 gap with USE3/PAGE3:
{{redirect|REDIRECT|USE1|PAGE1|USE2||USE3|PAGE3}} →

{{redirect/sandbox|REDIRECT|USE1|PAGE1|USE2||USE3|PAGE3}} →

{{about|ABOUT|USE1|PAGE1|USE2||USE3|PAGE3}} →

{{about/sandbox|ABOUT|USE1|PAGE1|USE2||USE3|PAGE3}} →

</noinclude>

And-gaps

First and-gap of 2:
{{redirect|REDIRECT|USE1||and|PAGE2}} →

{{redirect/sandbox|REDIRECT|USE1||and|PAGE2}} →

{{about|ABOUT|USE1||and|PAGE2}} →

{{about/sandbox|ABOUT|USE1||and|PAGE2}} →

</noinclude>

Second and-gap of 2:
{{redirect|REDIRECT|USE1|PAGE1|and}} →

{{redirect/sandbox|REDIRECT|USE1|PAGE1|and}} →

{{about|ABOUT|USE1|PAGE1|and}} →

{{about/sandbox|ABOUT|USE1|PAGE1|and}} →

</noinclude>

First and-gap of 3:
{{redirect|REDIRECT|USE1||and|PAGE2|and|PAGE3}} →

{{redirect/sandbox|REDIRECT|USE1||and|PAGE2|and|PAGE3}} →

{{about|UNSUPPORTED|USE1||and|PAGE2|and|PAGE3}} →

{{about/sandbox|ABOUT|USE1||and|PAGE2|and|PAGE3}} →

</noinclude>

Middle and-gap of 3:
{{redirect|REDIRECT|USE1|PAGE1|and||and|PAGE3}} →

{{redirect/sandbox|REDIRECT|USE1|PAGE1|and||and|PAGE3}} →

{{about|UNSUPPORTED|USE1|PAGE1|and||and|PAGE3}} →

{{about/sandbox|ABOUT|USE1|PAGE1|and||and|PAGE3}} →

</noinclude>

Last and-gap of 3:
{{redirect|REDIRECT|USE1|PAGE1|and|PAGE2|and}} →

{{redirect/sandbox|REDIRECT|USE1|PAGE1|and|PAGE2|and}} →

{{about|UNSUPPORTED|USE1|PAGE1|and|PAGE2|and}} →

{{about/sandbox|ABOUT|USE1|PAGE1|and|PAGE2|and}} →

</noinclude>

Explanation/justification of approach

Basic gaps

Behaviour with basic gaps either matches existing behaviour (easier to transition) or tries to avoid unexpected behaviour (usability).

The hatnote list module terminates for-see lists at the end of a "for-see" item if the "use" parameter was blank. This mirrors existing behaviour and avoids defaulting to "other uses" twice, and it's pretty consistent/predictable.
There's no termination if the "page" list of a "for-see" item is empty. This mirrors existing behaviour. It might be neat to allow setting up the fallbacks with a table, but for now this isn't implemented.
The behaviour is consistent, with minimal special-casing for the first item (it's handled completely passively by the repeat … until structure in the code).
The hatnote list code tries to avoid awkward skipping of specified parameters, as in § Basic gaps # 6 "USE2 gap with USE3/PAGE3".

And-gaps: Behaviour with and-gaps mostly matches the behaviour introduced in Module:Redirect hatnote of ignoring empty parameters, but defaults a little more strongly, forcing the first and-item to be defaulted. Note, as mentioned earlier, that {{about}}'s current wikitext-based functionality only supports up to 2 items in an and-list.

Discussion (Standardizing for-see lists)

Discussion goes here. Is there a particular behaviour that's particularly desirable or not? Is there any objection to centralizing the functionality and/or adopting the behaviours from Module:Hatnote list? {{Nihiltres |talk |edits}} 17:26, 27 April 2016 (UTC)

Hi. From the programming angle this change is definitely beneficiary. Editors and readers can also benefit from added features like performance and implementation of _formatLink. (You can see a summary of FormatLink support status in my sandbox User:Codename Lisa/sandbox § Hatnote section signs.) But to ensure that absolutely nothing break, one has to set up tracking categories and then track them. (I can help with that.)

Maybe we should invite the creator of the Lua scripts to this discussion. All of them, except three are created by Mr. Stradivarius.

Best regards,

Codename Lisa (talk) 07:47, 28 April 2016 (UTC)

The technicalities of this are beyond me, but I note that none of the examples includes the very common scenario where about is used an empty first parameter, just {{about||another thing|Something else}} (or {{about||another thing|Something else|second alternative|Yet another article}}. Does that matter? Should some of these variations be included for completeness? It's commonly used. PamD 08:14, 28 April 2016 (UTC)

For an example, though it should probably have a dab page by now, see Red Wilson. (In this version, in case anyone later tidies it up.) PamD 08:16, 28 April 2016 (UTC)

@PamD: There is a reason for this exclusion: A similar usage of {{redirect}} in the form of {{redirect||another thing|Something else}} does not exist; hence there is nothing to compare and nothing to standardize. {{Redirect}}'s first parameter is a mandatory one. Best regards, Codename Lisa (talk) 08:47, 28 April 2016 (UTC)

@Codename Lisa: That makes sense, thanks. I said it was beyond me! PamD 08:49, 28 April 2016 (UTC)

Simplifying these templates sounds like a very good thing to me. The only reason that the Lua modules have such varying behaviours now is that the templates had the same behaviours when I converted them. A top-down approach like this will ensure that the templates are easier and more intuitive for end users, which I wholeheartedly agree with. The trick, as Codename Lisa says, is to make sure that things don't break, and CL's suggestion of adding tracking categories for those situations is the best solution, I think. — Mr. Stradivarius ^{♪ talk ♪} 02:31, 29 April 2016 (UTC)

I've added some parameterization tests to {{about}}, and that should catch most of the pages affected by basic cases here and add them to Category:Hatnote templates using unusual parameters. Specifically, I added tests for parameters 5–9 being specified when 4 isn't, parameters 7–9 when 6 isn't, and parameter 9 when 8 isn't. The template currently maxes out at 9 parameters. The category's up to about 50 pages so far; I'll leave it a bit before jumping to fix them, out of curiosity at how how many pages are affected. {{Nihiltres |talk |edits}} 05:06, 1 May 2016 (UTC)

Overnight the count stayed at 49, so I've repaired the 40 cases in the article namespace. Next is presumably to catch cases from {{redirect}} and {{redirect2}} through tests in Module:Redirect hatnote. {{Nihiltres |talk |edits}} 16:03, 1 May 2016 (UTC)

@Nihiltres and Codename Lisa: I just found this discussion going on. I'm absolutely in support of centralizing the behavior of hatnote lists. However, I think I recently blundered after a good faith suggestion to "be bold" with this diff to Module:See also. The discussion was here, which I revived yesterday after it was dormant, and made the changes after significant testing in the sandbox. The suggestion in the discussion was to use Oxford commas for list lengths > 3, use a comma for list length = 2 when the first link contains a section link (' § '), and use semicolons to separate items when any item contains a comma. It's live for "see also". I'm aware that this change puts it out of sync with at least: Module:Further, Module:Other uses, Module:Redirect hatnote, and Module:Hatnote list. Please accept my apologies about the neglect for reading some extra pages and finding discussions going on. — Andy W. (talk · contrib) 18:38, 1 May 2016 (UTC)

That being said, I'd love to help out. I made a Lua version of {{For}} at Module:Sandbox/Andy M. Wang (if it helps at this point). I'm willing to sync behaviors of modules under Category:Hatnote modules. As for behavior, I'd support Oxford commas, Oxford "semicolons" when list items have commas, and a comma/semicolon if the first element contains a section link. Let me know if that behavior is under discussion. — Andy W. (talk · contrib) 18:54, 1 May 2016 (UTC)

@Andy: Good ideas! Module:Hatnote list's andList and orList functions currently implement the Oxford comma, but not section-link commas or comma-detection semicolons—there's definitely room for improvement there, and longer-term I'd like to use those functions more broadly as we Lua-fy more hatnote templates. Regarding {{for}}: I'd like to implement it using parts of Module:Hatnote list's _forSee function, to keep its form in sync with other hatnote templates as part of its code structure… but that'll involve some minor function restructuring, since {{for}}'s parameters produce an and-list in the form of a single for-see item, rather than producing a for-see-list in the style of {{about}}. {{Nihiltres |talk |edits}} 21:30, 1 May 2016 (UTC)

@Nihiltres: Thanks. I'd agree my sandbox module shouldn't be used at this point for {{For}}. If I have time, I'll look into andList and orList and test some potential suggested changes in a sandbox. And I'll keep an eye on this page. — Andy W. (talk · contrib) 21:40, 1 May 2016 (UTC)

@Andy: I've prototyped the improvements to andList and orList at Module:Hatnote list/sandbox; probably could be polished significantly, but it's a start. {{Nihiltres |talk |edits}} 22:25, 1 May 2016 (UTC)

@Nihiltres: I haven't had enough Lua experience to comment too much, but it honestly looks fine to me. Another suggestion I saw on some talk (somewhere on a hatnote template) is to omit the full stop if the last link contained a sentence-ending punctuation. It'd be something like: [code removed for readability]

End result might look cleaner. I suppose that might complicate forSeeForm and adding the check to the end of pagesStr? Cheers! — Andy W. ‎(talk · contrib) 21:21, 2 May 2016 (UTC)

@Andy: Updated the sandbox. I implemented the punctuation collapse as a simple pattern-replacement filter just after the point that the data's stringified with forseeForm; no need to overcomplicate things. Also, while these are great and I'd absolutely like to continue, they're out of scope in a section nominally about defaulting/terminating behaviours in for-see lists. Can we please move to Module talk:Hatnote list for these? :) {{Nihiltres |talk |edits}} 22:41, 2 May 2016 (UTC)

@Nihiltres: Will do, thanks for the notice. On a general note, hatnote unification with this module seem to be the way to go. :) — Andy W. (talk · ctb) 03:24, 3 May 2016 (UTC)

I've added tracking for the basic-gaps discrepancies to Module:Redirect hatnote. To date only one mainspace page has shown up at Category:Hatnote templates using unusual parameters, Tasmania, which I fixed with this edit. I'm now figuring out how best to check for any discrepancies with and-gaps in redirect hatnotes. {{Nihiltres |talk |edits}} 19:46, 3 May 2016 (UTC)

I've now added further tracking that will add uses of Module:Redirect hatnote with and-gaps to Category:Hatnote templates using unusual parameters. With that and the extant {{about}} gap-tracking, we should be able to eliminate all the potential edge cases before merging the functionality … unless I'm missing something. Am I missing something? :) {{Nihiltres |talk |edits}} 17:23, 4 May 2016 (UTC)

Done! Module:Hatnote list is implemented in {{about}} (via Module:About) and Module:Redirect hatnote. :) Let me know if there are any problems! {{Nihiltres |talk |edits}} 15:09, 7 May 2016 (UTC)

@Nihiltres and Andy M. Wang: Does this mean that all of this is taken care of: "The suggestion in the discussion was to use Oxford commas for list lengths > 3, use a comma for list length = 2 when the first link contains a section link (' § '), and use semicolons to separate items when any item contains a comma. It's live for "see also". I'm aware that this change puts it out of sync with at least: Module:Further, Module:Other uses, Module:Redirect hatnote, and Module:Hatnote list."? It would be highly desirable to have this behaivor, as described, and have it be consistent across such templates. Also, Module:Hatnote inline will also need to be updated (and it probably has redundant code in it that can be pruned). PS: I realize some people do not favor the use of the Oxford/Harvard comma in running prose, but this is a special case where it is needed for clarity, and even style guides that do not usually recommend the Oxford/Harvard comma (e.g. Chicago Manual of Style) do recommend it for cases where it aids clarity. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:55, 18 June 2016 (UTC)

@SMcCandlish: Thanks for the ping. Just some are done, but Module:Hatnote list is still being rolled out to Category:Hatnote modules. I haven't been keeping track as much as Nihiltres, and have this item on a backlog... I have some other immediate things to take care of, but am willing to assist. I don't have a concrete list of items needing an update. — Andy W. (talk · ctb) 05:21, 18 June 2016 (UTC)

@SMcCandlish and Andy: All of the listed features are present in Module:Hatnote list, though my perfectionism says that I should be improving on some of them to make them aware of the difference between actual and display values. I hadn't made a list specifically for converting modules to use Module:Hatnote list, but a quick survey shows that Module:Further, Module:Key people, and Module:Main don't use it. Module:Key people should be cut down to reuse mSeeAlso._seeAlso(); the others just need basic updating. My main focus has been on updating or deprecating templates, and there's a slightly-out-of-date table at User:Nihiltres/Sandbox with some notes. The biggest barrier to converting many of the templates is how many of them use "TEXT", i.e. allowing free-form text in spots instead of more-structured parameters; in particular there's a ton of misuse of those, e.g. as fixed in this edit. More stuff later; busy today. {{Nihiltres |talk |edits}} 17:19, 18 June 2016 (UTC)

No hurry. Just didn't want Module:Hatnote inline to get missed, and really it should just be merged with this one, with the inline feature triggered as an option. There's not really any need for a stand-alone codebase for it, as long as the functionality remains for the small but growing template family that use it (the short version is that is just converts the typical hatnote div to a span for uses in structures where a div will booger things badly). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:40, 20 June 2016 (UTC)

@SMcCandlish: I've prototyped an update that adds basic inline support to Module:Hatnote. I'll raise that at Module talk:Hatnote and include pointers to the topic at Module talk:Hatnote inline etc.; once the support's added in Module:Hatnote we can presumably deprecate the secondary templates/modules, rewrite them as thin wrappers, and finally delete them once uses have been migrated. {{Nihiltres |talk |edits}} 20:20, 21 June 2016 (UTC)

Manual of Style hatnotes?

Is it appropriate to insert a hatnote that is mainly of interest to Wikipedia editors? I didn't see it included in the list of what not to do, so I am unclear. For an example, see decimal mark. Praemonitus (talk) 21:33, 25 August 2016 (UTC)

It's okay, as long as it's properly formatted as a self-reference, either by using {{selfref}} to generate the hatnote, or by using |selfref=true in hatnote templates that support that; not all do). That said, self-references should be used sparingly; see also Wikipedia:Manual of Style/Self-references to avoid. {{Nihiltres |talk |edits}} 22:36, 25 August 2016 (UTC)

Disambiguation discussion related to hatnotes

A proposal that would affect the usage of hatnotes is taking place at Wikipedia talk:Disambiguation#Proposal: keep two-item dab pages. Interested editors are welcome to participate.— Godsy^(TALK_CONT) 04:44, 29 September 2016 (UTC)

Frequency

I'm not quite sure what to make of the hatnote for the Frequency article, but it looks bloated and perhaps includes some improper use. What should be done with it? Praemonitus (talk) 19:16, 20 October 2016 (UTC)

A few points:

The page shouldn't have both {{about}} and {{other uses}}; the former should generally replace the latter. We can merge the {{other uses}} into the {{about}} by adding an extra unnamed parameter containing "other uses" at the end of the {{about}}.
We should probably remove the {{broader}} entirely—it's a glorified "see also" in this case.
We should consider removing the Aperiodic frequency "for-see" in the {{about}}; the article's a stub that should probably be merged somewhere unless someone will expand it.
We should probably keep, but reword, the "for-see" for Frequency (statistics); the description ("the general concept beyond the temporal domain") is vague and unhelpful but the target page is highly relevant even if we're also linking to Frequency (disambiguation).

These changes would bring us down to one hatnote, slightly on the longer side depending on what's trimmed, which would be quite reasonable. {{Nihiltres |talk |edits}} 14:18, 21 October 2016 (UTC)

Perhaps there needs to be a way of tagging possible improper hatnote usage for potential cleanup? Say with an inline tag. Praemonitus (talk) 22:01, 8 November 2016 (UTC)

It's a pretty niche area; I'd be inclined to use categories. There's already a few subcategories of Category:Hatnote template tracking categories in active use, but they reflect issues detected automatically rather than ones tagged by hand. {{Nihiltres |talk |edits}} 20:47, 10 November 2016 (UTC)

Combining hatnotes onto a single line

Out of the "five basic rules" of hatnotes, there's a principle suggesting that people try to limit hatnotes to just one at the top of the page:

If at all possible, limit hatnotes to just one at the top of the page. This also applies to the usage of hatnotes in subsections of articles. Such usage is not discouraged, and subsections should also have a maximum of one hatnote as well.

This has long seemed an awkward rule to me, for two reasons:

Sometimes line-breaks provide distinguishing context for hatnotes. For example, an alternative target page might be offered in the context of a particular redirect, and would be confusing if presented separately. Similarly, if two hatnotes were written with separate "other uses" messages on the same line, it'd look oddly repetitive.
Limiting hatnotes to one conflicts with another principle, which is to use the standard templates to generate hatnotes when possible rather than generically using {{hatnote}}. Some editors are willing to revert edits on the basis of multiple standard templates using multiple lines, e.g. this edit.

In the context of the second example in particular I decided to play around and create {{hatnote group}} (powered by Module:Hatnote group) as an experiment. It rewrites hatnote divs in its input into a single hatnote composed of spans with their original content, separated by spaces. Here's a fairly straightforward example:

{{hatnote group|
{{about|USE1||PAGE1}}
{{redirect|REDIRECT|USE2|PAGE2}}
}}

is parsed into

{{hatnote group|
<div role="note" class="hatnote">This page is about USE1. For other uses, see [[:PAGE1]].</div>
<div role="note" class="hatnote">"REDIRECT" redirects here. For USE2, see [[:PAGE2]].</div>
}}

which the module then transforms into

<div role="note" class="hatnote">
<span>This page is about USE1. For other uses, see [[:PAGE1]].</span> 
<span>"REDIRECT" redirects here. For USE2, see [[:PAGE2]].</span> 
</div>

which, finally, displays as (live example):

In short, it gives us some interesting if somewhat hackish flexibility. In particular, I like the potential it has for letting us carve up hatnote messages into reusable, recombinant pieces; we'd need fewer templates overall as a result, even if we used more individual templates in many cases.

That said, I'm not saying flat out that that's what we should do; I'd like to consider the relative merits of various approaches. In particular, some questions I'd like to discuss:

Would the {{hatnote group}} approach make sense?
Is the "single hatnote" principle desirable?
When are linebreaks between hatnotes desirable?

What's your take on the issue? {{Nihiltres |talk |edits}} 19:34, 6 October 2016 (UTC)

I'd never consciously noticed that point 5, and I think that hatnotes are probably clearer where each specific hatnote is on a different line. So my answers are (1) probably not, (2) no. (3) most of the time. There can be, for example, several different "redirect" hatnotes, which belong on separate lines as they speak to different audiences and offer different onward links. PamD 22:16, 6 October 2016 (UTC)

I like the hatnote group approach, especially if there were some sort of collapsible option for the odd cases where there are so many hatnotes that they do seem like a bit of clutter. While I do think hatnotes should be combined where possible and kept to a minimum overall, there are cases where several different types of hatnotes may be needed (such as Entropy or Wood). In such cases, I think it can help readers parse the hatnotes when there are line breaks between different hatnotes. For some earlier discussion along somewhat similar vein, see Wikipedia talk:Hatnote/Archive 3#Less is more and several subsequent sections in that same archive. older ≠ wiser 11:33, 7 October 2016 (UTC)

Pretty much what PamD and Bkonrad said. Hatnotes may be caused by different terms or different concepts, which should be represented in one line for each term or concept. At the very least, the not to be confused and for other meanings hatnotes should always have their own separate lines, IMHO. When there are several out links for the same term and/or concept, it makes sense to keep those in the same line, though. Diego (talk) 12:02, 7 October 2016 (UTC)

Hatnotes should do their job then get out of the way. They are only there for the minority of visitors who are at the wrong page. I dislike seeing pages that have 4-5 rows of hatnotes. It's unnecessary bloat that badly detracts from the article. I like anything that will further the goal of reducing hatnote bloat. Praemonitus (talk) 14:56, 7 October 2016 (UTC)

OK, interesting discussion so far. A couple of obvious trends are for a) "one line per concept": using spacing to separate unrelated concepts and generally improve readability, and b) pushback against "hatnote bloat" above the lead, particularly on pages that may have three or more hatnotes. It leads me to think that we should recommend a maximum size for hatnote use and then offer techniques (like {{hatnote group}} and disambiguation pages) for reducing the "bloat" when needed.

On another note, I did some poking around in the history and traced the "five rules" text back to an original four, added in this edit by Red Slash. A look at this talk page around that time doesn't show discussion of the change, suggesting that it was added unilaterally. I don't think that rule five's supported by consensus, and do think it should be removed, but I equally think that there is a good case for including a clear instruction to editors to keep hatnotes concise and few, avoid needless hatnotes, and reduce clutter when possible. (Tangentially, it might be worth adding some verbiage explicitly supporting edits for concision like this one, but let's limit the scope of this discussion.)

Either way, my personal goal here is to reduce our reliance on custom uses of {{hatnote}} (or worse, the awful :'' markup) to construct messages virtually identical to the standard templates—it's bad for maintenance. For example, this search shows a number of examples that use {{hatnote}} that should probably use {{about}} instead.

In short: would it be acceptable to replace the "one hatnote" rule with a "minimize use, and aggressively minimize if above a standard maximum" rule? I'm open to refining the idea further, and welcome discussion of specifics. {{Nihiltres |talk |edits}} 18:17, 8 October 2016 (UTC)

The sentence "X redirects here" makes it grammatically awkward to group hatnotes. Couldn't it say "For other uses of redirect X, see..." instead? If you arrived there as a result of the redirect, then you already know; if you didn't, then you probably won't care what redirects there. Length-wise it's about the same. Praemonitus (talk) 20:59, 8 October 2016 (UTC)

@Praemonitus: In most cases, that text would be needless and should be omitted, but it'd be trivially easy to add an optional parameter that produced that behaviour for use with combined hatnotes. {{Nihiltres |talk |edits}} 22:45, 8 October 2016 (UTC)

Possibly combined hatnotes such as {{About-distinguish2}} could all be rebuilt using {{hatnote group}} and a smaller set of hatnote primitives? Praemonitus (talk) 21:15, 27 October 2016 (UTC)

I've considered this. I like the core idea: a few small pieces that can be recombined as needed. In practice, I would prefer a single template that used keywords to compose named fragments in user-specified order, perhaps something like {{composed hatnote|about|SUBJECT|distinguish|SIMILARCONCEPT|for|USE|PAGE|text|TEXT}} →

<div role="note" class="hatnote">This article is about SUBJECT. It is not to be confused with SIMILARCONCEPT. For USE, see PAGE. TEXT.</div>

; and then included some diagnostics to check whether the usage is "unusual". (I'm not happy with the resulting complexity of the idea.) I would prefer that approach because composable fragments should never be used on their own; in my hatnote cleanup work I've accumulated many edits deleting nonstandard hatnotes that don't have any purpose, e.g. :''This article is about X'' or :''X redirects here'' without any target link to make the hatnote plausibly useful.

That said, we've drifted across topics. I started this discussion to look at solutions to improve cases where we aren't using the standard templates simply to consolidate hatnotes, e.g. your (Praemonitus') edit to the "Mathematics" article. I believe using {{hatnote}} with raw text to be inferior to using {{about}} and {{redirect}} or similar. The standard templates can apply diagnostics (e.g. Category:Missing redirects) and be updated centrally, while fixing or updating custom-text {{hatnote}}s requires a lot of work. My view is that we should use linebreaks in some cases to make context obvious (Mathematics being a good example where the "other uses" statements are context-dependent on the first part of their note) but group up the longest cases with {{hatnote group}} or similar to help reduce them to a manageable size. Is there any problem with that approach?

Further, I think that the guideline's recommendation to use only a single hatnote whenever possible is out of line with practice and possibly popular opinion, and I want to update the guideline—but we should establish a reasonable consensus for that, or it'll just be me establishing guidelines unilaterally, which would be just as bad as how the one-hatnote-only principle was added in the first place. {{Nihiltres |talk |edits}} 19:47, 28 October 2016 (UTC)

Is focusing on "popular practice" appropriate here? I don't think so. We should be employing a holistic perspective instead. Editors who prioritize adding hatnotes to articles probably aren't representative of the whole, and have different priorities. The target audience should be those who visit the page to read the article. The hatnotes are presumably targeting a small minority of misdirected visitors, and should be treated as such. Praemonitus (talk) 21:25, 28 October 2016 (UTC)

@Praemonitus: Let me clarify: out of the five editors who've contributed to this talk section, four appear to support using separate lines, and the rationale is, broadly, that the linebreaks separate hatnotes visually into their distinct contexts—making things easier for readers. While we can definitely expand on the guideline in terms of encouraging concision in hatnotes, I don't think that a single-hatnote rule is supported by consensus; I think that your goals of minimizing clutter would be better served by stylistic recommendations. For example, the phrase "with the same name" is often included in hatnotes and is almost always needless, and I almost always remove it when standardizing hatnotes.

Beyond concision in text, we can encourage use of disambiguation pages over long hatnotes—perhaps some crossover with Wikipedia:Disambiguation#Hatnotes? In the meantime, encouraging use of standard templates (rather than custom {{hatnote}}s) allows for the possibility of automatically diagnosing the longest hatnotes; for example, it'd be trivial for me to add a line or two to Module:Hatnote list in forSeeTableToString() that would add a tracking category to articles using hatnotes with at least 4–5 "For X, see Y" items.

The biggest issue I have with your position is not your singlemindedness in consolidating hatnotes, but in unexpected support for keeping hatnotes on separate lines for context. I think that the two of us probably agree that using {{hatnote group}} to consolidate hatnotes is preferable in most cases to rewriting standardized hatnotes as custom {{hatnote}}s; the issue is that I don't see broader support for consolidating hatnotes, and I myself strongly believe that consolidating just two hatnotes into one is overkill. Thus, I've suggested a compromise: establishing a guideline threshold (of perhaps 2–3 lines of hatnotes) past which we would aggressively consolidate them, while tolerating lesser cases as trivial: readers are quite capable of glossing over a couple of lines that are clearly formatted as notes with their indented, italicized style. {{Nihiltres |talk |edits}} 20:05, 30 October 2016 (UTC)

In short, we're just recycling what has already been said. So be it. Praemonitus (talk) 02:02, 31 October 2016 (UTC)

I wish I had your tool now, to fix the hatnote on The_Nutcracker. Right now it has an About, a Redirect with 2 pages, and 2 different versions of redirects to the same disambiguation page. Thus:

This article is about the ballet and the music by Tchaikovsky. For other uses, see The Nutcracker (disambiguation).

"The Nutcracker Suite" redirects here. For the albums, see The Nutcracker Suite (Tim Sparks album) and The Nutcracker Suite (Duke Ellington album). For other uses, see Nutcracker (disambiguation).

(I can't remember how to format block quotes. Maybe I or someone can clean it up after.)

I think it would be better all on one line, but either way could work. It's the redirects and wording that need sorting, but (at my skill level) the templates don't seem to allow it. Egmonster (talk) 02:30, 23 November 2016 (UTC)