Module talk:Hatnote

This module was considered for merging on 2018 July 4. The result of the discussion was "no consensus".

Text and/or other creative content from this version of Module:Hatnote was copied or moved into incubator:Module:Wp/nod/Hatnote with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

Stale

 – Discussion restarted at #Inline hatnotes, below, 2+ years later.

I added a test to handle an "inline" parameter, to output hatnotes as spans instead of divs. This will have various applications. One I've already deployed is {{Ghat}} for non-indented hatnotes atop glossary definitions (it wraps the inline hatnote span inside a <p>...</p>; other use cases could wrap inline hatnotes inside table cells or list items or whatever, as needed). Another is {{Hatnote-inline}}, a meta-template for inline "see also..." and "for more information...", etc., notes.

We've gone to great length to provide templated consistency for hatnotes above content, but their use embedded within content is a totally "unregulated" mess. When I get back from doing other stuff this weekend, my first use of templates based on that will be in WP:Manual of Style and its subguidelines themselves, since they make frequent use of such cross-references, but do so in a haphazard manner. Seems the best place to start, since cleaning up the style guide will be automatically exemplary.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:27, 23 May 2014 (UTC)[reply]

I've reverted, as this could have far-reaching consequences, and I think a discussion is necessary to find consensus first. If I'm understanding you correctly here, you want to put hatnotes inside definition lists and inside body text. Firstly, I'm not sure that calling such inline use a "hatnote" makes much sense. And secondly, in the inline case this would presumably mean that we change text text like "blah blah (see Foo for more details)" into "blah blah ({{see also inline|Foo}})". I think we should avoid adding more templates when inline wikitext will do just as well. — Mr. Stradivarius ^{♪ talk ♪} 23:48, 23 May 2014 (UTC)[reply]

Three separate issues:

1. Hatnotes atop definitions (or sets of definitions) in dl lists serve precisely the same function they do atop sections in articles, etc., but can be formatted to suit the environment better by not being inside a div that's being indented and spaced in a way that doesn't work well in such circumstances.
2. As for actually inline-in-body-text notes, I suppose they are not really hatnotes, but it seemed pointless to duplicate all of that code just to avoid calling it a hatnote; whatever we call them if not hatnotes, the same metatemplate and module can be called via redirects that don't call them hatnotes, and no more "problem". The only difference at all between the block and inline ones would be div vs. span (and the positioning applied to the div to indent it). There is no reason to standardize the block ones but let chaos reign with inline ones. The styles used in the latter case are all over the map, and frequently take the form of unencyclopedic-tone asides and directives. This sort of random noise could be minimized if there were a standard set of inline "unhat"notes (tienotes?) No one would be prevented from creating custom inline ones, just as they can use the bare wikicode I use below, or {{Hatnote}}, to create custom block ones. Good for good, good for gander.
3. I don't really get your "avoid templates" rationale, since it could be used to oppose most templates (at all, period), including the entire family of block hatnotes (a simple :''Insert your [[cross references here]]'' can replace pretty much every hatnote on the system, if you want freeform cross-referencing like that. The rationale would also get rid of almost every inline dispute/cleanup template and various inline typing aid templates, since most of them can be replaced with "inline wikitext [that] will do just as well". We put these things in templates when they're used repeatedly and it'll be faster and more consistent to to template them than to keep typing them out by hand. The very frequently added (See also article name.) and (for more information, see article name) parentheticals people add to articles all the time, serving exactly the same function as block hatnotes, just in a more localized context, are case crying out for templating. This isn't some idea that just crossed my mind, it's something I've been thinking about for, I dunno, 8 years or so. :-)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:41, 24 May 2014 (UTC)[reply]

Given the background provided by SMcCandlish, I don't think allowing a hatnote inline is a good thing. This is not from formatting issues, but from basic hatnote meaning (is that semantics?).

The guideline for hatnotes is in WP:HATNOTE. It says "Hatnotes help readers locate a different article they might be seeking", which is a very practical and useful rule on when to apply (at least for me. For readers: "Am I on the right page/place?)". This rule also implies: the hatnote is not part of encyclopedic/body/content text. It is a navigation aid, always. So when we use it inline, we are injecting non-content into the body text.

From this background, hatnote has outer <div> tag only, not <span>. This way, it is set out of body/content by html handling in general, and by format too. This also explains the "chaos" SMcCandlish sees in inline and table uses: it is not intended for that place for a reason. Another intended behaviour by hatnote is a sort of "noprint" effect. Because a hatnote is not content, it is omitted in content export (print, make wikibook, create pdf, republish on a website as the BBC does). This is achieved by some class= technique. Now when used inline, there could be a part of a sentence being cut out. And it is idle hope to write some warning in the documentation: we are not there to advise or check when such a mistake would be made.

In general, every inline issue that makes us think about a hatnote can be solved differently as content. First and foremost: why not use a wikilink? Second: why not write as we would write it in a lead?

Let me apply this general statement to the example {{Ghat}} as provided by SMcCandlish. As it shows, the inline hatnote does not exactly answer the readers question "am I on the right page". It is more like a lead part: this very word is spelled in various ways. It could be that a template is needed, but so far it a hatnote is not needed. It looks like this is an glossary internal question to be solved (what to do with unclear glossary terms).

Adding re 1: as described in my main point, hatnotes may have that same "function" (visual effect, format, layout, css effect even) but do not have that same semantics (WP:HAT guideline, not content, noprint effect). re 2. With SMcCandlish I agree that a hatnote does not need to be in top just because of its name. For example {{further}} is used at the bottom too. OTOH, this usage of {main} standing alone in a table cell is bad, because the content-only will show an empty cell -- it should be a wikilink.

-DePiep (talk) 06:31, 26 May 2014 (UTC)[reply]

The important things that DePiep says here about hatnotes in the strict sense apply exactly to their inline variants (the ones that would be templated instead of rewritten away):

• Navigation aid to help readers locate another article they may really be seeking
• Not part of encyclopedic content text
• Injection of non-content into an article (i.e. WP self-refs in the form of references to other parts of WP as such)
• Not printworthy.

Beyond this, DePiep is making unsupportable assumptions:

When addressed in series, DePiep's points actually unintentionally support what I'm proposing here. Which again is not a question of "should we allow inline crossreferences, i.e. equivalents of hatnotes?", it's "should we repurpose this code to help bring consistency to the many thousands of inline crossreferences we already have, or should that be be addressed some other way?". I'll be addressing it one way or another.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:47, 30 May 2014 (UTC)[reply]

Hello SMcC, your plans for inline style unification interest me greatly and I would like to subscribe to your hatnoted newsletter. I think implementing such points of style in the code here makes sense, rather than (say) a bot-mediated workaround. – SJ + 01:25, 14 June 2014 (UTC)[reply]

Folding serious comments by the OP (instead of replying)? Useless. I wont even go into this. That also implies, there cannot be a change form this talk. -DePiep (talk) 22:23, 13 August 2014 (UTC)[reply]

• @Mr. Stradivarius, @Sj, @DePiep:: Inline "hat"notes – i.e., inline cross-references marked up as such in definable ways – have been used now for about two years with zero incidents or objections, and in multiple ways, from {{Crossreference}} mostly used between pages to {{See above}} used inside a particular article, to {{Ghat}} used as a hatnote (as such) inside glossary entries. We should probably merge the modules again, perhaps as Module:Crossreference (or Module:Cross-reference if you prefer the hyphen). "Hatnote" was is a weird name, a bit of jargon from WP's early days, that isn't terribly meaningful. Two years is more than long enough for proof-of-concept and for any problems to have been identified.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:58, 28 March 2016 (UTC)[reply]

No. Please read WP:HATNOTE first. And don't ping me for this any more. -DePiep (talk) 22:03, 28 March 2016 (UTC)[reply]

Since your input is just WP:IDONTLIKEIT filibustering, I won't.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:13, 28 March 2016 (UTC)[reply]

No. My input is: the concept of "Hatnote" does not accomodate inline usage. As others have decribed here too. -DePiep (talk) 21:04, 30 March 2016 (UTC)[reply]

Which is a classic case of IDONTLIKEIT. In the end, it doesn't matter whether your personal reality tunnel for categorizing things by their names isn't happy with the genuine reality that hatnotes as <div>...</div> structures do not work well or at all in every scenario. That genuine reality is not going to magically change just because you frown about it. If the cognitive dissonance is just too much for you, we can rename them to not have "hat" in the name. Even the <div>-based ones are often used at the end of things, not atop them (e.g. {{More}}). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:34, 21 June 2016 (UTC)[reply]

@Mr. Stradivarius: any idea why this module is causing this list to not be empty? Frietjes (talk) 22:12, 13 August 2014 (UTC)[reply]

@Frietjes: Yep, it's Module:Redirect hatnote grabbing the text of this redirect via Module:Redirect so that it can populate Category:Invalid redirects. See Module talk:Redirect hatnote for the initial request for the feature. It's also being discussed at VPT. — Mr. Stradivarius ^{♪ talk ♪} 01:36, 14 August 2014 (UTC)[reply]

Maybe there could be done something to fix such cases automatically? For example, creating new module/extending current module, so the template {{Distinguish}} could have such code: {{#invoke:Hatnote|hatnote|pre=Not to be confused with|sep=or}} Just for consideration. --Edgars2007 (talk/contribs) 16:17, 7 April 2015 (UTC)[reply]

Hello, Edgars2007. I can certainly implement a function that trims leading and trailing whitespaces (which I assume are the problem in your example) without resorting to such elaborate fixes that you explained. Would that do for you?

Best regards,

Codename Lisa (talk) 18:24, 7 April 2015 (UTC)[reply]

Of course, yes. --Edgars2007 (talk/contribs) 19:20, 7 April 2015 (UTC)[reply]

@Edgars2007: I've implemented a trimmer. Finally. I've been making a fool of myself all along, looking for the code in the module. It turns out it was in the template. Best regards, Codename Lisa (talk) 00:03, 15 April 2015 (UTC)[reply]

What changes have been made when Template:Hatnote started using Lua? Because it is not working on .sr wiki properly: text is not italicized and not spaced from the left side... Example. --Obsuser (talk) 04:13, 16 December 2015 (UTC)[reply]

@Obsuser: The styles are defined in MediaWiki:Common.css, so you would need to make sure that they are defined in sr:MediaWiki:Common.css as well. The class name to use is "hatnote". (Previously "dablink" and "rellink" were used as well, but those have since been removed.) — Mr. Stradivarius ^{♪ talk ♪} 06:37, 16 December 2015 (UTC)[reply]

@Mr. Stradivarius: OK, we’ll update it. Thank you for help! --Obsuser (talk) 16:52, 16 December 2015 (UTC)[reply]

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

p._formatLink() is special cased for category and files links, but interwiki links with a prefix of language code need this too or they're treated as language links. Actually, does it harm if we add colon to all links? Main Page works the same as Main Page. Liangent (talk) 20:38, 28 January 2016 (UTC)[reply]

@Liangent: I don't see any reason not to just add the colon by default, as plenty of other templates already do. I just commented out the "if" statement for now so we can assess if this breaks anything, but if it doesn't we can optimize the code a little bit more --Ahecht (TALK
PAGE) 23:58, 28 January 2016 (UTC)[reply]

I've tidied the code up. I can't think of any downsides to this, unless _formatLink is being substituted somewhere, but Template:Format link isn't set up for substitution and I'm not aware of any other places that _formatLink is directly exposed to wikitext. — Mr. Stradivarius ^{♪ talk ♪} 23:30, 28 January 2016 (UTC)[reply]

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

(See also previous discussion at Template talk:Hatnote)

Since using <aside> tags isn't yet feasible, I suggested adding equivalent accessibility context using the role attribute. Module:Hatnote/sandbox has the changes (diff). If anyone wants to check the results on a screen reader, I made a comparable edit to mw:'s hatnote template: mw:Special:WhatLinksHere/Template:Hatnote. Matt Fitzpatrick (talk) 22:24, 5 February 2016 (UTC)[reply]

Updated diff. Matt Fitzpatrick (talk) 07:09, 11 February 2016 (UTC)[reply]

Done No objections from anyone, so done. — Mr. Stradivarius ^{♪ talk ♪} 01:36, 12 February 2016 (UTC)[reply]

I am trying to get Scribuntu templates to work on another trial wiki. When I attempted to Module:Hatnote over to the other wiki, it failed to import.

The instructions for importing infobox templates at MediaWiki.org lack a solution to importing Templates that have Scribunto and lua elements. GodBlessYou2 (talk) 16:00, 28 March 2016 (UTC)[reply]

@GodBlessYou2: You need to install the Scribunto extension. Then it should work. Although you might have to delete the modules and create them again so that they have the correct content type. — Mr. Stradivarius ^{♪ talk ♪} 16:12, 28 March 2016 (UTC)[reply]

Once you get Scribunto installed, you will also need to copy over Module:Arguments and Module:Yesno --Ahecht (TALK
PAGE) 16:24, 28 March 2016 (UTC)[reply]

Thanks! I had Scribuntu installed but at some point in my testing had commented out the LocalSettings line enabling it! That's why my attempts to import Modules failed, since Sribuntu enables that namespace. Thanks Ahecht for identifying some key modules I needed. To help others, I expanded the documentation at Manual:Importing Wikipedia infoboxes tutorialGodBlessYou2 (talk) 20:32, 28 March 2016 (UTC)[reply]

I've been toying around with the forSee function I've added to Module:Hatnote/sandbox. The basic idea is that since a ton of hatnotes produce some variation on a list of "For X, see [[Y]]" statements, formatting those should be available through Module:Hatnote.

The main function currently takes three functions:

• A list of arguments, with empty parameters and whitespace pre-trimmed (well, _forSee takes argument list directly, forSee uses getArgs(frame))
• A "from" number, which causes it to start from the parameter of that number (e.g. set to 2 to skip past the initial parameter used in {{redirect}})
• An options table, because that's pretty standard.

The function appears to work reasonably well, but it could probably be more elegant. In particular, I'm thinking it would probably make sense to split out the part that preprocesses the arguments list, to make it easier for variants to make sneaky additions. Or perhaps the function should be its own module. Or perhaps there are other places it should be tweaked…

Initial results from some quick hacks at Module:Redirect hatnote/sandbox suggest that it mostly works, although some edge cases may be off, i.e.

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

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

Anyways, since this would presumably be put into widespread use, I'd appreciate it if I'm not the only person looking over it. Thoughts? {{Nihiltres |talk |edits}} 16:13, 7 April 2016 (UTC)[reply]

I am still missing the core analysis of hatnote templates. That is: Category:Hatnote templates has ~60 hatnotes, and more in subcategories. What is the pattern in all these? My first throw:

Primary: class=hatnote. Then there are topics ('about topic X'), and there are target pages ('see page Y') possibly in a list, and their semantics (describe relevance for hatnoting). The rest is filler & format.

Secondary: the templates use <PAGENAME>, labels (as in [[page|label]]), incoming Redirect and automatic addition of (disambiguation) --(dab) for short--. [First behaviour I'd like to kill is the automatic addition of '(dab)' in hatnote templates. Even worse: it is combined with <PAGENAME> to double the frustration. Please stop 'helping' me this way: when I write a hatnote, I know what I'm talking about. Actually, nowadays I only use {{hatnote}} and compose the text myself)].

Tertionary: listing handling, grammar

Quartiorinario and below:

-- texts applied

-- style options (allow page style adaptions, ENGVAR)

-- other stuff: errors, categorising, option 'internal wikipedia', ...

Now the generic module:hatnote should cover or plainly plainly reject all these issues with the right priority. (I don't think this sandbox proposal does. Why should the core module contain sentence stuff, or words like "for"? That's for the specialised modules to add, eg using "opening text, prefix list text, list separator", not main mod:hatnote).

-DePiep (talk) 17:19, 7 April 2016 (UTC)[reply]

@DePiep: I very much like thinking about the underlying design principles of hatnotes, but that's outside of the scope of this discussion.

My first goal in the Grand Hatnote Overhaul (or whatever) is to modernize the existing set of templates, normalize existing usage, excise needless variant templates, and restrict the scope of each remaining variant template to a singular purpose.

In other words, the rough plan for the Grand Hatnote Overhaul:

1. Clean up, centralize, and modernize existing stuff ("simplify the landscape")
2. Hold discussions on how hatnotes ought to be: scope, intent, features, etc. (design questions)
3. Work towards implementing hatnotes as they ought to be (implementation of improved designs)

There is a lot of work that needs to be done to clean up the existing system, and that should be prioritized so that once we start asking questions they're more meaningful and productive. Perhaps we should start a WikiProject to coordinate the cleanup work…

In the meantime, for the purpose of making this existing pattern more standard, without regard to how good or bad the pattern may be, is this function a good implementation? How can it be improved upon, again excluding changes to the pattern from the scope? {{Nihiltres |talk |edits}} 19:20, 7 April 2016 (UTC)[reply]

Of course, I am a commentor and you carry the can so that's the end point.

But. I am not talking about an existing pattern, I mean to say intrinsic pattern: the core essential of any hatnote (my Primary notes).

Since you propose to change the top hatnote module, one cannot skip the top hatnote issues (in your reply and sandbox you do: in creeps a 'for every hatnote a dedicated function').

Skipping the core (say #0 in your listing above) will not solve anything. It will just postpone things.

For example, when I wrote my #New docstyle section below, I was flabbergasted to learn that the word "Topic2" is used both as topic and! as pagename (and another! weird thing happens in the current sandbox). This mixup/separation should be prevented in any mod:hatnote.

So, mod:hatnote must handle topics & pages distinct, must be able to make a listing, and must organise those say grammatically (ie allow text additions and formatting, but not prescribe them). Otherwise, you are not cleaning but replacing the dirt. (I'm writing tough to be clear) -DePiep (talk) 19:44, 7 April 2016 (UTC)[reply]

I'm happy to "replace the dirt" if it means replacing random dirt with centralized, standard, reusable dirt. {{Nihiltres |talk |edits}} 19:15, 8 April 2016 (UTC)[reply]

You are too arrogant to be trusted with such a job. -DePiep (talk) 21:03, 8 April 2016 (UTC)[reply]

I'd like to read the advise of Mr. Stradivarius about this (Strad wrote this module). -DePiep (talk) 20:00, 7 April 2016 (UTC)[reply]

Can we please change our example-habit? There is just "Pagename" and "Topic" to be used. In titlecase of course. Really, after ten years the example text "USE1" still does not say anything to me (I really mentally have to translate it to "Usage1", meaning "Topic1", to understand).

Example from previous topic, now improved:

• {{redirect|FromRedirectPage|Topic1|Targetpage1|Topic2}} →
  "FromRedirectPage" redirects here. For Topic1, see Targetpage1. For Topic2, see FromRedirectPage (disambiguation).
• {{redirect/sandbox|FromRedirectPage|Topic1|Targetpage1|Topic2}} →
  "FromRedirectPage" redirects here. For Topic1, see Targetpage1. For Topic2, see FromRedirectPage (disambiguation).

Nihiltres, is that final link change intended? (see what good demos do ;-) ). -DePiep (talk) 19:55, 7 April 2016 (UTC)[reply]

I find the all-caps part of the existing style extremely helpful, since it adds visual contrast that helps highlight where input text is passed through (since the rest of the text is sentence-case). I'm not terribly attached to the naming scheme, but as patterns, we should probably:

1. include the string "PAGE" on example inputs that are intended to reflect page names
2. include the string "TEXT" on example inputs that are passed through as plain text
3. have example inputs reflect their intended replacements in actual use.

So, for example:

• {{redirect2|REDIRECTPAGE1|REDIRECTPAGE2|USAGE1|PAGE1}} →
  "REDIRECTPAGE1" and "REDIRECTPAGE2" redirect here. For USAGE1, see PAGE1.
• {{about|TOPICTEXT|USAGE1|PAGE1|and|PAGE2}} →
  This module is about TOPICTEXT. For USAGE1, see PAGE1 and PAGE2.

{{Nihiltres |talk |edits}} 20:11, 7 April 2016 (UTC)[reply]

No. Not even in lowercase that doc scheme helps. You keep mixing up topics and pages, (even adding texts by now!) which is not OK at this module level. (btw, did you notice your sandbox alters parameter usage, as I noted & showed?). [I suppress the invitation to write this in all uppercase. For now]. -DePiep (talk)

@DePiep: OK, so what are the principles behind your proposed scheme? I don't quite understand what you're criticizing in my example. Also, yes, I'm aware of the discrepancy in my sandboxed code, since I was the one who pointed it out above. However, given this:

• {{redirect|REDIRECTPAGE1|TOPIC1|PAGE1|other uses}} →
  "REDIRECTPAGE1" redirects here. For TOPIC1, see PAGE1. For other uses, see REDIRECTPAGE1 (disambiguation).
• {{about|ABOUT-TEXT|TOPIC1|PAGE1|other uses}} →
  This module is about ABOUT-TEXT. For TOPIC1, see PAGE1. For other uses, see Hatnote (disambiguation).
• {{redirect/sandbox|REDIRECTPAGE1|TOPIC1|PAGE1|other uses}} →
  "REDIRECTPAGE1" redirects here. For TOPIC1, see PAGE1. For other uses, see REDIRECTPAGE1 (disambiguation).

…perhaps my sandboxed code's behaviour is actually preferable. {{Nihiltres |talk |edits}} 23:04, 7 April 2016 (UTC)[reply]

Writing uppercase is actually shouting. Stop it. -DePiep (talk) 00:23, 8 April 2016 (UTC)[reply]

Ergh? This thread is about how to document, demo, describe a template. Not about whether the template works well. (sandbox changes are discussed elsewhere). Now can you go back about my proposal? -DePiep (talk) 23:10, 7 April 2016 (UTC)[reply]

You keep using uppercase. That is to troll me, right? To trick me into abusive (uppercase) responses, right? Now, to get back to peace, can you point to any serious documentation that actually does use uppercase and wins? -DePiep (talk) 23:14, 7 April 2016 (UTC)[reply]

Boy, your example is even worse. I tried to demo and use "|other uses" (from your demo here), but I had to discover that it is input text, not template code text. Etcetera, etcetera: always mixing up texts & structures & meanings. What a lousy approach. I can not help you any more. Last (& first) advise: do not use uppercase. -DePiep (talk) 23:57, 7 April 2016 (UTC)[reply]

re OK, so what are the principles behind your proposed scheme? : 1. use Titlecase, not uppercase. Ever. (Or next week you won't even understand your own documentation). 2. Read #1 again. 11. Use "Topicn" and "Targetpagen" throughout. Whatever the cost. 12. (later more). -DePiep (talk) 00:14, 8 April 2016 (UTC)[reply]

Suffice to say, I support the uppercase status quo and oppose moving to title-case; I've already said that I believe it offers readability benefits, and you're not offering any substantive counterargument (past the claim that it's "shouting", which doesn't make sense given the clear documentary context). I'll leave it at that, until others comment at least. {{Nihiltres |talk |edits}} 19:12, 8 April 2016 (UTC)[reply]

Well, don't WP:SHOUT is reason enough to stop it (#1). I also asked for examples where uppercase makes good documentation - none so far (#2). And, I pointed out that only after using readable input, it shows that one input was used for double semantics (topic & pagename mixup) (#3). After these three, you personal opinion & preference does not matter that much, does it? -DePiep (talk) 21:01, 8 April 2016 (UTC)[reply]

I've started a discussion at Wikipedia talk:Hatnote#Standardizing for-see lists about standardizing and centralizing the code that generates lists of "For X, see Y" items in hatnotes. The discussion may affect this page, but is located there as it's relevant to others as well. Please comment there if interested. {{Nihiltres |talk |edits}} 17:26, 27 April 2016 (UTC)[reply]

As I've been working on Lua-fying hatnotes, I've noticed that this module's _hatnote() function doesn't really support categories. Most of the time categories are either awkwardly concatenated in as strings, or appended after the call to _hatnote(). Moreover, this means each one needs to reimplement category handling, and there have been inconsistencies between the various templates/modules. For example, {{About}} had some category-handling that I left out when migrating it to Lua (category was emptied, so not urgent, but…), and used a _nocat parameter, while the standard for Module:Hatnote-based templates seems to be args.category.

Would anyone object to my adding a category argument to _hatnote()? I'd code it to accept a table (or nil), with category name keys (prevents duplicates) and false or category-key (string) values, and output a list of categories after the hatnote text. I'd also add a helper function addCategory() to add items to category tables, so that that wouldn't need to be reimplemented in each hatnote module. The main thing I'm hesitating on is that since _hatnote() doesn't itself get template arguments, templates would each need to include something like yesno(args.category) to toggle output—it's not self-contained.

I'm not 100% sure of the approach and welcome suggestions on other ways to handle categories. {{Nihiltres |talk |edits}} 14:44, 11 May 2016 (UTC)[reply]

SMcCandlish pointed out at Wikipedia talk:Hatnote#Discussion (Standardizing for-see lists) that there exists Module:Hatnote inline and {{hatnote inline}}, which largely duplicate the functionality of this module and {{hatnote}}. I've therefore prototyped a simple enhancement to this module that adds support for inline hatnotes, with a simple inline parameter or argument that causes the module to emit a <span> element rather than a <div>. This would naturally deprecate the inline-specific module and template, which probably shouldn't be duplicating the functionality of this module anyway. Any comments, ideas, or objections? {{Nihiltres |talk |edits}} 20:26, 21 June 2016 (UTC)[reply]

An "inline hatnote" sounds like a contradiction in terms to me. The "hat" in "hatnote" means that it goes above the content, doesn't it? It can't be inline at the same time. Module:Hatnote inline looks like a fork that SMcCandlish created because he couldn't find a consensus at the discussion section you linked, and should probably be sent to MFD. And if we do decide to use something like this, we should at least change the name. — Mr. Stradivarius ^{♪ talk ♪} 23:02, 21 June 2016 (UTC)[reply]

Except that they often do not. Various ones, like {{further information}} and {{detail}} are often used below content, and we have probably over a million cases of people manually inserting inline cross-references in prose in their own wording (often poor, e.g. "Please note that this is covered at more detail at ..."), the maintenance of which can be greatly improved with further templating.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:19, 22 June 2016 (UTC)[reply]

I'm neutral on the issue besides wanting to simplify the hatnote system in general. Module:Hatnote inline should be deprecated/merged/deleted either way, and I'm willing to get rid of "inline hatnotes" entirely, but we'll have to deal with its uses, which include {{crossreference}}, {{see above}}, and {{see below}}. There's a mess of both Lua and wikitext supporting those, but only 300ish transclusions overall. Actually, now that I look closer, {{see above}} and {{see below}} are … frightening monsters of needless customizability. {{Nihiltres |talk |edits}} 23:51, 21 June 2016 (UTC)[reply]

I was going to scrap {{see above}} and {{see below}}, and replace them with something simpler anyway. As for Module:Hatnote inline, most of the Lua is just redundant code from Module:Hatnote; as noted earlier, the only real difference is <div>...</div> vs. <span>...</span>.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:19, 22 June 2016 (UTC)[reply]

I originally posted this above, but will just move it here:

What we get out of this is practical terms is at least all of the following:

• <span>-based hatnotes (in the traditional "hat" position or otherwise) can be used in layout scenarios where insertion of a <div>...</div> would be disruptive to document flow or even invalid markup. See, e.g., {{ghat}}.
• Cross-references need not be done as distracting top-sitting hatnotes, but can be placed less obtrusively, inline, as needed. (We're already doing this in innumerable places, in probably hundreds of thousands of articles, just inconsistently with hand-added notes instead of consistent templated ones.)
• We can reduce template profusion by merging (and discouraging the re-forking) of templates and modules that differ only in whether they use inline or block CSS.

There are no costs associated with these benefits, beyond enabling support for a parameter in extant templates that should have them, to trigger use of <span> instead of <div>. (Not all existing hatnotes need this; those intended for disambiguation, for example, should always be page-top hatnotes, while contextual cross-references, like {{further information}} and {{details}}, should have the flexibility.) Whether we continue to call the underlying meta code by the name Template:Hatnote and Module:Hatnote is completely immaterial (see WP:COMMONSENSE, WP:BUREAUCRACY, and WP:IAR, not that there is actually an "rule" about how the code that generates hatnotes may be repurposed). The fact that this "hat" bugbear is an imaginary pseudo-problem was pointed out over two years ago (see #Inline variant), during which time the forked inline hatnote code has been working without any problems. Just merge it and let's get back to something more productive than trying to prevent new functionality on the basis that it doesn't match the cute name someone came up with for the old functionality. I mean really.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:19, 22 June 2016 (UTC)[reply]

Some recent change, possibly to Module:Hatnote inline, seems to have broken at least {{Crossreference}}, which is now displaying as block content despite its explicit intention to create inline content. See Wikipedia:Identifying reliable sources#Exceptions for some examples. Hairy Dude (talk) 14:47, 17 July 2016 (UTC)[reply]

@Hairy Dude: Can't reproduce the issue here. I double-checked my rewrite of Module:Hatnote inline and it looks fine; the {{crossreference}} instances at the example are appearing properly as (inline) span elements; and the CSS in MediaWiki:Common.css doesn't apply block-level styles to .hatnote, but only to div.hatnote. {{Nihiltres |talk |edits}} 16:40, 17 July 2016 (UTC)[reply]

@Nihiltres: I'm definitely seeing the block display at Wikipedia:Identifying reliable sources#Exceptions (the "see <link>" bits). Inspecting the offending element shows that this rule from load.php applies: .hatnote { display: block !important }. Hairy Dude (talk) 19:21, 17 July 2016 (UTC)[reply]

@Hairy Dude: Tracked it down to User:Hairy Dude/common.css. {{Nihiltres |talk |edits}} 19:59, 17 July 2016 (UTC)[reply]

@Nihiltres: I am an idiot. Thanks :) Hairy Dude (talk) 00:05, 18 July 2016 (UTC)[reply]

"Hatnote" no longer describes the function of this module and the meta-template that uses it, and its descendant templates. Rather, it describes only the most frequent use case. Confusion stemming from this has lead to over two years of unproductive circular discussions that deny the reality of the code's live deployment.

• At very least, the templates that are directly categorized in Category:Cross-reference templates and which are using Module:Hatnote are often not used as hatnotes above content, but as "shoenotes" below it.
• Some, like {{More2}}, can only be used this way, since they would make no sense at the top. (There's generally not much point in forcing these to use {{Hatnote}}'s presently mandatory <div>; it just wastes space and interrupts the flow of the document in many cases.)
• Others, like {{Qnote}}, are something completely different (in this case, asides or footnotes, which can optionally be numbered), and are not cross-references or WP self-references at all.
• The inline variants (using <span> and produced by what is presently Module:Hatnote inline) need not continue to have a forked codebase. They are not often used in "hat" position ({{ghat}} being an exception).

Clearly, the "hat" scenario limitation has nothing to do with how the actual codebase of this module and its dependent meta-template are being used in reality.

Since at least two editors in previous discussions on this page want to take a literal interpretation of the term "hatnote", as a note that sits at the top of content like a hat, the obvious (perhaps only) solution is to just rename this. Module:Meta-note and Template:Meta-note would work fine. Simple solution, zero drama. The term "hatnote" would then, much more clearly, continue to be used at Category:Hatnote templates, etc., as a description of templates that are in fact used in hatnote position (whether they are generated by this module or not). This solution would allow us to separate form and function here in a way that increases clarity and prevents further unproductive approaches to this module.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  05:37, 22 June 2016 (UTC)[reply]

I'm concerned that the renaming, and/or expanding of scope, would undo some structural norms currently set by hatnotes. Right now, there is at least broadly the expectation that hatnotes always go at the top of pages or sections, and that most navigational meta-content—excepting big topical navboxes—comes in the form of hatnotes. For example, consider how important {{main}} is to summary style. These structural norms help make hatnotes valuable because people can rely on them occurring in the same places in the same roles; consider the case in particular of someone who might decide to restyle the hatnote CSS class—the class has no value if it isn't used consistently and semantically.

Of course, broadening isn't necessarily bad if it makes things more consistent. "Hatnotes" were originally more strictly for the tops of pages, rather than for sections … and I had a hand myself in broadening that standard when I created {{rellink}} in 2009 (now merged to {{hatnote}}), lumping together "related links" under a meta-template in the same way that "disambiguation links" ({{dablink}}, since renamed to {{hatnote}}) did.

I can see value in allowing hatnotes to be used inline for a few cases where <div> elements would be disruptive, but we should be sure, before we jump to broadening scope, that we could not exercise discipline and normalize articles that are using hatnotes in unusual ways (e.g. your "shoenote" example), rather than broadening the templates to fit the myriad uses. Moreover, many of the examples here are exceptions: Module:Hatnote inline is only used on ~300 articles, while the main, normative Module:Hatnote has broken the 1 million mark. Your example {{more2}} currently has 1 mainspace transclusion and is described in its documentation as "where {{details}} is too verbose}}"—it acknowledges its own redundancy!

I'm sympathetic to the idea that there exist good use-cases, but there's huge value in having the hatnote system be as simple and uniform as possible, since it's a key element of article structure that should be made accessible to newbies. It doesn't help your case that I think I can reasonably pull off the devil's-advocate argument in the other direction: why shouldn't we instead tighten scope and eliminate {{hatnote inline}} and its like entirely? {{Nihiltres |talk |edits}} 00:46, 23 June 2016 (UTC)[reply]

I'll take that in the spirit offered and go for a rebuttal of these points. This broad expectation of "topness" is a phantasm. Various templates of this sort long pre-date the existence of this module, and used the original {{Hatnote}} meta-template before Lua, and many of them have routinely been used below not above content since Olden Tymes. E.g., {{Details}} dates to mid-2005 and has frequently been used this way (which is not against any guideline or policy, or common sense), and {{More2}}, which makes no sense at all above content, dates to 2009.

I agree, of course, that we have structural norms, but these are not set by obscure Module:-namespace pages, that probably most editors and certainly almost all readers don't even know exist; they're set in plain English by MOS:LAYOUT, WP:HATNOTE, WP:SUMMARY, etc., which aren't suddenly going to change and say "by the way, you can use a confusing layout with inline notes", but will continue to recommend the traditional indented-div hatnote at the top for most purposes (proof: they still do, despite the availability of inline hatnotes for some time now, which remain used for specific, other things.) What the meta-template is called has no effect on whether SUMMARY recommends {{Main}} or what that template's name is. Reuse for a new purpose of a tool more commonly used for another purpose does not endanger or invalidate the original use (I regularly use my comb as a backscratcher, my phone as an MP3 player).

There is no scope expansion, only a scope merger between two modules with mostly redundant code. This is not a request for permission to create a new set of templates; it's a suggestion to combine two extant overlapping ones for efficiency and maintenance ease.

There is no way around the fact that some markup situations cannot have divs shoved into them. (And it's not template editors' job to act as Layout Police, forcing all articles to conform to a limited set of layout possibilities just for the sake of avoiding, for no clear reason but at all costs, the merger of two almost identical modules; that would be one dog's tail wagging the whole breed.) In other cases (e.g. that addressed by {{Ghat}}) there's no way around the problem that the indentation is not desirable in certain circumstances (other than by doing some other custom code, which puts us back in the same boat).

The inline functionality isn't widely deployed mainly because of the div and span template/module split, the consequent lack of documentation support, and the low priority level of converting inline cross-references to use {{crossref}} (it's more of a AWB or bot kind of task). If I or anyone else decided to spend an hour with AWB on it, it would be used in an order of magnitude more pages. All new-ish templates are used in few pages, until they're used in lots of pages. All templates with limited applicability are used in fewer pages than those with much broader applicability. Those with formally prescribed functions will be found more consistently than those without them. There is no "delete templates that aren't used 1mil times" standard. By TfD standards, 300 is more than sufficient to keep, and it will eventually be much, much higher.

Your devil's advocacy case could be made to eliminate every single template on the system that is not absolutely essential for WP to function. Yet we don't do that; editors are free to create, improve, and merge templates in useful, sane ways. We have millions of inline cross-references, being formatted manually, willy-nilly in wildly inconsistent ways, often quite unhelpfully. There is no practical argument against cleaning that up, and the most obvious way is the way already under active deployment: by repurposing the hatnote code, with templates using a span instead of a div, and starting to normalize these cross-refs into some predictable formats (notwithstanding that the experimental see-above template needs to be clean-slated and replaced, which is already on my to-do list). The very fact that we had manually-created, random, and confusingly inconsistent proto-hatnotes all over the place was why the hatnote template was created in the first place; the cases are closely parallel. And the guidelines and norms for their use developed after efforts began to standardize them.

The gist: WP works by incremental improvement, and is not bound by bureaucracy. The code is already working. It's just more practical to have merged code. This "it must be killed because its not a hatnote and isn't a div" stuff is putting form before function, and past above the present.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:53, 26 June 2016 (UTC)[reply]

• The proposed name "meta-note" OTOH is too wide. It suggests to include other notes like ENGVAR messages, and maintenance tags (these are meta too). Also, to "separate form and function" this would make a descriptive template title for the module/template instead of a name. This being editors space (not content space), there is no requirement to be this correct. We can freely choose & keep a catchy name, and fill in its meaning as we prefer. It may be incorrect in descriptive minor points, as a name it is OK. -DePiep (talk) 11:43, 27 June 2016 (UTC)[reply]

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Per T164781, we should add the 'navigation-not-searchable' class to the output of this module. That will remove hatnotes from search snippets and also prevent the contents of hatnotes from biasing search results. See the Phabricator task for more info. Kaldari (talk) 03:17, 9 May 2017 (UTC)[reply]

Done — JJMC89 (T·C) 05:20, 9 May 2017 (UTC)[reply]

It would be helpful if the _formatLink function would automatically replace underscores with spaces. Ideally people would always insert links with spaces, but that doesn't always happen; see this section in the current revision of History of the Slovak language. Both the page name and the section have underscores and it looks terrible. This would be avoided if the module always displayed spaces. I've made the roughly equivalent function on Wiktionary do this (the section_link function in Module:links). — Eru·tuon 17:53, 21 July 2017 (UTC)[reply]

• It's not the responsibility of templates and modules to fix every potential issue with input. There exist titles that canonically contain underscores, and linking those in hatnotes should not require working around the functionality of this module. If someone leaves underscores in a link inappropriately, the solution is to edit that link and replace them with spaces. {{Nihiltres |talk |edits}} 19:39, 25 June 2018 (UTC)[reply]

  I would lean the other way on this one. The number of "crap links" that have pointless underscores still in them is many orders of magnitude larger than the number of titles that technically should have an underscore (and they'll work without one anyway). That is, the amount of editorial time wasted cleaning up links manually to remove unwanted underscores will dwarf the time spent manually adding one for a weird title, probably on the order millions to one. And it's surely the no. 1 bit of link cleanup we do, by a very wide margin.  — SMcCandlish ☏ ¢ 😼  03:27, 26 June 2018 (UTC)[reply]

  @Nihiltres and Erutuon: Agreed with SMcCandlish. If my open WP:ER is accepted, I'll make another one implementing this. Psiĥedelisto (talk • contribs) ^{please always ping!} 09:53, 13 June 2020 (UTC)[reply]

  Oh—I should clarify before it's too late—either I'd add it as an optional parameter, e.g. _=r (read as "underscores equals replace"), or, do research into how many instances of underscores would need to be manually checked, and commit to checking them all. Definitely I won't open a template-protected edit request that will change the default behavior without knowing all the effects this will have, and having a plan for those. So don't worry about that Nihiltres. Psiĥedelisto (talk • contribs) ^{please always ping!} 01:40, 14 June 2020 (UTC)[reply]

  • @Psiĥedelisto: It's not the worst idea if optional, but I'm still not a fan of reformatting underscores because it's both a) potentially unexpected and b) potentially breaking (if an underscore is desirable). The extant formatting stuff might match (a) but probably won't match (b). That said, I did a quick test using a regex-based search, which timed out (regex searches are expensive) but produced 220 hits of pages calling {{main}} with input containing an underscore, where {{main}} is transcluded to approximately 280k pages. Of the first 20 hits, 6 used the "labeln" syntax to override the link and display something else (without an underscore). This is probably few enough to justify fixing instances manually rather than filtering at the module level. I'll fix some manually and see if more instances pop up on further searches. {{Nihiltres |talk |edits}} 20:44, 15 June 2020 (UTC)[reply]
    • @Nihiltres: What do you think about filtering at the level of {{format link}} via {{replace}}, instead of the module level? Psiĥedelisto (talk • contribs) ^{please always ping!} 20:48, 15 June 2020 (UTC)[reply]
      • @Psiĥedelisto: A search hastemplate:"format link" insource:/\{\{ *format link[^\}_]*?_[^\}_]*?\}\}/ does not time out and has no results, showing that no extant transclusions would be changed by the behaviour. That suggests it's not a change worth making at that level. {{Nihiltres |talk |edits}} 20:56, 15 June 2020 (UTC)[reply]

The |selfref=true feature says in the documentation that it replicates {{selfref}}. However, in the module it adds the class "selfref", while {{selfref}} adds "plainlinks selfreference noprint". Shouldn't these be the same? --Ahecht (TALK
PAGE) 18:53, 23 August 2018 (UTC)[reply]

• @Ahecht: Yes, we should probably make selfref and selfreference consistent; the question is simply which to choose. Based on some searches, e.g. insource:selfreference -insource:/tl\|selfref/ -insource:/\{\{selfref/ -hastemplate:selfref in the MediaWiki and Template namespaces, it looks like selfref may have more extant uses. I'm not picky about that, though. The additional classes are redundant: noprint because hatnotes are excluded already in MediaWiki:Print.css, and plainlinks because hatnotes should never contain external links. {{Nihiltres |talk |edits}} 20:07, 19 December 2018 (UTC)[reply]

  I wouldn't depend on that last point; we can't future-predict exactly what this will be used for, and the idea "hatnotes should never contain external links" really only pertains to mainspace and other reader-facing content. There is no "rule" to apply when it comes to projectspace and userspace, where there are potential use cases for such links (e.g. to Wikia I mean Fandom.com [what a dumb rename], or Meatball, or some other wiki).  — SMcCandlish ☏ ¢ 😼  06:51, 16 June 2020 (UTC)[reply]

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Hello. For legal articles, we often need to italicize. E.g., quo warranto, Ex parte Quirin, Toth v. Quarles. However, we cannot do this currently with {{format link}}. Quo warranto § Philippines appears, therefore, counter to WP:MOS. While often automatically italicized as used in {{hatnote}}, {{see also}}, etc., I often find occasion to use this template alone. Therefore, I have fixed it:

• {{format link|Quo warranto#Philippines|italicizearticle=y}}

Now gives: Quo warranto § Philippines

• {{format link|Cybercrime Prevention Act of 2012#Disini v. Secretary of Justice|italicizesection=y}}

Now gives: Cybercrime Prevention Act of 2012 § Disini v. Secretary of Justice

While I can't think of an example where it would be useful, both work together. See User:Psiĥedelisto/sandbox for examples. (Note: Italic page name not a bug, it's caused by the Supreme Court template also tested on that page.)

Please therefore copy:

1. Module:Sandbox/Psiĥedelisto/Hatnote → Module:Hatnote
2. User:Psiĥedelisto/Format link → Template:Format link

Thanks! Psiĥedelisto (talk • contribs) ^{please always ping!} 09:52, 13 June 2020 (UTC)[reply]

@Psiĥedelisto: Thank you for the edit request! I added some new test cases for your code at Module:Hatnote/testcases, which brought up a couple of problems, so I had a go at fixing them in Module:Hatnote/sandbox. While I was making the fix, I also changed _formatLink to use named arguments, as I thought it made the code easier to understand. For example, if you want to italicize a section, then without named arguments the function call looks like _formatLink("Foo#Bar", nil, nil, true). With named arguments this becomes _formatLink{link = "Foo#Bar", italicizeSection = true}, which means that you don't have to look at the function definition to see what all the parameters do. Using named parameters will require changing dependent modules, but according to my search the only dependent modules are Module:Cat main and Module:Hatnote list, so the damage is not too bad. I also changed the italicizearticle parameter to italicizepage, as this module can be used with all namespaces, not just article space. Let me know what you think, and if there's anything I've missed in my edits. Best regards — Mr. Stradivarius ^{♪ talk ♪} 08:03, 14 June 2020 (UTC)[reply]

@Mr. Stradivarius: Your changes all seem broadly positive to me, and I haven't find any bug in your version. Psiĥedelisto (talk • contribs) ^{please always ping!} 15:18, 14 June 2020 (UTC)[reply]

 Done @Psiĥedelisto: I've updated Module:Hatnote with the new changes, and also udpated Module:Cat main and Module:Hatnote list with the new _formatList function syntax. I also updated the documentation for Module:Hatnote and Template:Format link. Let me know if you notice any problems with the various changes. Best — Mr. Stradivarius ^{♪ talk ♪} 15:26, 16 June 2020 (UTC)[reply]

User pages are the majority in Category:Hatnote templates with errors, and it make the category less usable. Right now only talk pages are excluded automatically. Should user pages be excluded from it as well? —⁠andrybak (talk) 13:34, 4 July 2020 (UTC)[reply]

@Andrybak: That sounds like a reasonable suggestion to me. I've implemented the code to do this in Module:Hatnote/sandbox (diff). If no-one objects in the next day or so I will put it up live. — Mr. Stradivarius ^{♪ talk ♪} 13:05, 11 July 2020 (UTC)[reply]

@Andrybak: The code is now up live. You should see it slowly start to filter out userspace pages from the category. — Mr. Stradivarius ^{♪ talk ♪} 15:06, 14 July 2020 (UTC)[reply]

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

The module's _formatLink function adds an unnecessary space when fed just a section. E.g.:

Therefore please copy the sandbox to the main module. I checked that it was synced first. Test cases were also added; those who for some strange reason want the old behavior back can specify |italicizePage=true, which will do it as a side effect of adding an empty <i>...</i>. Psiĥedelisto (talk • contribs) ^{please always ping!} 23:36, 28 July 2020 (UTC)[reply]

@Psiĥedelisto:  Done * Pppery * _{it has begun...} 00:47, 29 July 2020 (UTC)[reply]

@Psiĥedelisto: Thanks for spotting this and for making the fix. Having section-only links that add an empty <i>...</i> also sounds like a bug to me, so I added another test case and made a fix in the sandbox. Do you think this would be a good addition to the module? Best — Mr. Stradivarius ^{♪ talk ♪} 13:29, 29 July 2020 (UTC)[reply]

@Mr. Stradivarius: I certainly do, I only didn't fix it myself so that there would be a way to get the old behavior back, no matter how broken; some TP ER implementers care about that sort of thing quite a lot, and I never know who I'm gonna end up with when I make my requests. Psiĥedelisto (talk • contribs) ^{please always ping!} 16:14, 29 July 2020 (UTC)[reply]

@Psiĥedelisto: It looks like the extra initial space for section-only links has been in the template for a long time, so I suppose it's possible that some people might have come to rely on that behaviour. This seems unexpected enough to me, though, that such people are probably in a small minority, if indeed they exist. I say we go ahead and fix it, and then see if anyone complains. We can work out any next steps to take after that. Best — Mr. Stradivarius ^{♪ talk ♪} 13:43, 30 July 2020 (UTC)[reply]

I've gone ahead and put my fix up live. — Mr. Stradivarius ^{♪ talk ♪} 13:48, 30 July 2020 (UTC)[reply]

On a few hatnote templates, MB has requested that I add redlink detection, because it's a reasonably common error that could be tracked and fixed. I've sandboxed a basic implementation of that functionality, adding Category:Articles with hatnote templates targeting a nonexistent page. I'd like feedback that this looks okay; the obvious misgiving that people might have is that checking for a page's existence is an "expensive operation", so this would introduce many thousands of "expensive" operations across the site. On the other hand, it's not that expensive on balance, and it wouldn't take up much of the limit for most pages. The other issue is that it might produce "false positives" via uses of {{format link}}, which reuses the hatnote functionality; this could probably be mitigated in several ways. {{Nihiltres |talk |edits}} 21:17, 11 December 2021 (UTC)[reply]

I don't know if your solution will apply to all hatnotes and you don't need a list of specific templates to update or not. If the latter, I recently found a case of {{main}} with a redlink target. this version of Rivière de la Tortue (Delson) has a redlink target in {{other uses}}. That template has the "poorly implemented" check, but it didn't seem to work. Just mentioning this in case it is of interest or use in developing/testing your implementation. MB 02:49, 15 December 2021 (UTC)[reply]

This solution would apply to essentially all hatnotes that use automatic lists, by adding the check to the automatic formatting that those use. It wouldn't apply to wikitext-based hatnotes, which would have to have the functionality added manually per template, which should be easy. In the Rivière de la Tortue (Delson) example, the "poorly implemented" check failed because it only checks for a redlink when defaulting is used, while that page specifies the disambiguation page manually. My design checks for redlinks in all "target" links (it won't catch links in text inputs, but that's okay). {{Nihiltres |talk |edits}} 18:15, 16 December 2021 (UTC)[reply]

I think that adding redlink detection for hatnote templates is a good idea, but I'm not sure that coupling it to the formatLink function is the way to go. {{Format link}} is used in several templates that don't relate to hatnotes, and having pages using these templates outputting a hatnote tracking category would be confusing. How about creating a separate function in Module:Hatnote that does the check for existence and then calls formatLink? Existing hatnote modules would need to be updated to use the new function, but it should only be a one-line fix for each module, and it would avoid any potential confusion. — Mr. Stradivarius ^{♪ talk ♪} 05:30, 15 December 2021 (UTC)[reply]

I've updated the sandbox implementation to mitigate the problems somewhat. The prototype requires passing an option, allowing the category to be changed by supplying it as a category name string (an empty string disables categorization), or using the default with any non-string truthy value. I've specified "true" for most of the native methods (AFAICT only formatLink is used outside hatnotes), and added a parameter passthrough for the formatLink method that {{format link}} uses. That means the current prototype shouldn't affect {{format link}} and similar unless the user explicitly asks for it by specifying a category name to use in case of a redlink. That's probably a good "quick" solution. That said, having done that work, the cleanest solution would probably be to extract the link-formatting functionality into its own module (including the optional redlink categorization I've prototyped)—since it's being used outside hatnotes in the first place—and then to call that module inside Module:Hatnote's link-formatting functions, which could then (more) safely assume that they were hatnote-specific. I'm not eager to do the work for that, but it'd probably be a better long-term solution. {{Nihiltres |talk |edits}} 18:15, 16 December 2021 (UTC)[reply]

I've done a decent chunk of the work to extract the functionality of formatLink and _formatLink to Module:Format link, as that seems to be the most sensible restructuring given that {{format link}} doesn't necessarily concern hatnotes.

The code at that module integrates improvements I've made that allow an option, specified as a parameter to formatLink or a string option to _formatLink, to enable redlink categorization if and only if specified, with the specified category name. Similarly, Module:Hatnote/sandbox has been updated to remove the base formatLink functionality, to call the new module, and to specify a default hatnote redlink-target category name.

A few other modules will need updating to match, but … does this look reasonable as designed? It still couples formatting a link to error detection (meh), but it's done in a much more generalized way that's not hatnote-specific where implemented. I'll need to do some more work to update testcases (migrating some from the hatnote module to the new module, adding some to test the new functionality) and (re)write documentation, but it's largely ready to go, so I'd appreciate further feedback (Mr. Stradivarius, especially). Thanks, {{Nihiltres |talk |edits}} 18:50, 20 December 2021 (UTC)[reply]

@Nihiltres: Yes, I think this is a good direction to take, and I agree with splitting _formatLink out into its own module. Thank you for all of your work on this. Thinking about it, p.formatPages and p.formatPageTables might be better off in Module:Format link than Module:Hatnote - they seem conceptually closer to formatting links than to hatnotes per se, and they are not used elsewhere in the Hatnote module. Having said that, moving them will create extra work, and I don't feel incredibly strongly either way. — Mr. Stradivarius ^{♪ talk ♪} 14:10, 21 December 2021 (UTC)[reply]

Thanks for your review; it really helps my motivation for the less-fun work on documentation and tests. :) I finally took a good look at those two methods, which I'd earlier assumed were widely integrated into hatnote modules. The first, formatPages has a couple of uses, so I added a generalized analogue (allowing the categorization option) to Module:Format link. The second, formatPageTables, can probably be simply deleted as it's unused outside of sandboxes. I think it's probably safe for me to (boldly) implement the changes, but I'll definitely get documentation, tests, and such working first. {{Nihiltres |talk |edits}} 19:32, 21 December 2021 (UTC)[reply]

(←) (ping MB)  Done — all hatnotes with redlink targets that use automatic formatting will now point to Category:Articles with hatnote templates targeting a nonexistent page, and it's done through a separated Module:Format link. {{Nihiltres |talk |edits}} 22:50, 26 December 2021 (UTC)[reply]

I see there are over 400 pages in the category already, so this is definitely worthwhile. Can you restrict the detection to article space only? There is no real reason to care about these in other name spaces. Thanks. MB 22:57, 26 December 2021 (UTC)[reply]

Actually, some of these are See also in category headers, so those should probably be clean-ed up also. MB 23:04, 26 December 2021 (UTC)[reply]

Nihiltres, not sure if you saw the above. Many cases are in USER and DRAFT space, for which there is little or no reason to care. Can these be excluded from the tracking? MB 04:39, 31 December 2021 (UTC)[reply]

MB Ah, OK, I'd thought your second comment totally negated the first. I'll draft a namespace-based filter and implement it in the next round of updating—there's also some feature request stuff happening over at Module talk:Format link that I'm looking at. I'm thinking to exclude the user namespace, the draft namespace, and all talk namespaces. {{Nihiltres |talk |edits}} 05:05, 31 December 2021 (UTC)[reply]

Nihiltres, at first I was thinking to exclude everything except article. But then I saw that hatnotes are used on Categories. Definitely exclude User, Draft, all talk. I saw some in Templates, but if those are actually transcluded, they will show up in the articles. I'm not sure if there are any "reader facing" namespaces to track except article and Category, so an include list may be shorter than an exclude list. Certainly not a big problem, just something to improved when you can. Thanks. MB 05:18, 31 December 2021 (UTC)[reply]

MB  Done in Special:Diff/1063743122. {{Nihiltres |talk |edits}} 18:26, 4 January 2022 (UTC)[reply]

FYI @Nihiltres, MB, and Mr. Stradivarius: Above changes broke {{format linkr}}. Diagnosis at User talk:TryKid § {{format linkr}}. (Yes, I do note the irony of using {{format linkr}} to talk about {{format linkr}}.) I think template editors need to start checking systematically for uses of exposed APIs, not just changing common templates/modules. This broke a ton of pages, including some in article space. No disrespect, it's obviously a volunteer project, I'm just making you aware that this change did not go smoothly and breakage only found/corrected days later. Psiĥedelisto (talk • contribs) ^{please always ping!} 13:19, 27 December 2021 (UTC)[reply]

That's on me. I did check for uses, but changed my search query early on to something Lua-specific that no longer showed {{format linkr}}, and thus missed that one. My apologies. {{Nihiltres |talk |edits}} 16:12, 27 December 2021 (UTC)[reply]

@Nihiltres: No problem, just was making you aware since you have the right so hopefully will remember next time. I've broken plenty of running production systems in my time lol. Also, it's a good reminder to me that {{format linkr}} has a special role, I really made it for talk pages and not article space (it's much more convenient to paste a section from URL bar with the linkr version), but it seems at some point I forgot and started just using it everywhere. It's been copied to Vietnamese Wikipedia, not by me, so seems others find it useful, but it's a good point to keep in mind, not to use it if the link I'm writing won't benefit. Psiĥedelisto (talk • contribs) ^{please always ping!} 01:00, 28 December 2021 (UTC)[reply]

Template:Category pair is a specialized form of hatnote which takes two arguments ("preceding" and "succeeding"), checks for their existence, then produces a hatnote if one or both exist. Right now, the template code is ugly, and it can be easily implemented in Lua. I've implemented it in Module:Geological time, but I think it should belong in a more central module.

What do editors think of adding an entry point in this module for Template:Category pair? — hike395 (talk) 07:42, 16 December 2021 (UTC)[reply]

The proposed functionality should probably be its own module rather than being implemented in this module, but otherwise, sure, it seems like a good target for Luafication, and you've already written most of the necessary code. I'd probably tweak the design a little (more static format-strings that are easily translated, less concatenation-based formatting) but that's mostly my style. {{Nihiltres |talk |edits}} 18:23, 16 December 2021 (UTC)[reply]

Seconded - we use a separate module for e.g. Module:Cat main, so having a Module:Category pair would follow that pattern. — Mr. Stradivarius ^{♪ talk ♪} 00:33, 17 December 2021 (UTC)[reply]

Thanks! I'll implement it as its own module. — hike395 (talk) 05:13, 17 December 2021 (UTC)[reply]

Just came to tell you the formatLink variable is declared but not used. @Nihiltres, given this edit, maybe you have the clue. Jack who built the house (talk) 22:32, 22 December 2023 (UTC)[reply]

For a while now, hatnotes have had a somewhat different styling on mobile. Whereas at all resolutions we have the contents of Module:Hatnote/styles.css:

.hatnote {
	font-style: italic;
}

/* Limit structure CSS to divs because of [[Module:Hatnote inline]] */
div.hatnote {
	/* @noflip */
	padding-left: 1.6em;
	margin-bottom: 0.5em;
}

.hatnote i {
	font-style: normal;
}

/* The templatestyles element inserts a link element before hatnotes.
 * TODO: Remove link if/when WMF resolves T200206 */
.hatnote + link + .hatnote {
	margin-top: -0.5em;
}

on mobile we've had the following additional styles:

.hatnote {
	padding: 5px 7px;
	color: var( --color-subtle ); /* this is a "mid" grey */
	font-size: @font-size-minerva-smallest; /* font-size: 0.8125rem; which on Minerva produces 13px text */
	background-color: var( --background-color-interactive-subtle ); /* this is a light grey */
	margin-bottom: 1px;
	overflow: hidden;
}

.hatnote a {
	color: var( --color-progressive ); /* not all that important the specific color */
}

which produces a grey bar for your average hatnote (that stops at anything floating, but that's a non-issue there) and seems to cause some minor grief for various inline hatnotes (e.g. in the lead of [1]) that I am not going to spend too much time thinking about for this discussion. Notably, before we added TemplateStyles, these were the differences between what was on desktop and what was on mobile (from the mobile point of view):

• Hatnotes were straight text
• Hatnotes were not indented
• Hatnotes have a grey background
• Hatnotes have a lighter foreground
• Hatnotes have a smaller text.

I've been working with one of the WMF engineers on other matters (dark mode!) who introduced the idea of being able to configure some of the "hack" CSS that ends up on our pages, which would provide the option to remove the additional mobile styles at some point. Assuming that becomes an option, do we want to adjust any of our styles? Add the mobile only to desktop? Scrap them altogether? Pick and choose? United States is pretty emblematic for the cases of top of page and of section (and multi top of section), and probably the only other case of interest is the multi-top of page hatnote. (contrast United States and WP:Citation templates). (We could override the ones we don't like even on mobile today if we wanted, but this just introduces more CSS for negligible benefit to anyone.)

(Brief history: It looks like the styles were added as part of rellink/dablink (classes we no longer use) in 2014 (around the time MF was getting some overhaul or even creation! I think), hatnote in phab:T91160 in 2015, and then some rework done in 2017 in phab:T173600. I'm not sure how much of this CSS was design and how much was "oh that looks nice".) Izno (talk) 07:20, 8 April 2024 (UTC)[reply]

The smaller text with lighter foreground is easy to miss. It reminds me of image captions (for which article United States is also a good example). I think that some hatnotes, like {{main}}, need to be more prominent to the reader.

As a reader, I would also like to have more consistency between mobile and desktop. I read more on desktop, and my pattern recognition for isolating the hatnotes doesn't work as well on the mobile version.

With the above in mind, I wouldn't mind scrapping the additional styles on mobile. —⁠andrybak (talk) 20:10, 30 May 2024 (UTC)[reply]

Looks like something related to mixing of mobile vs desktop styles for hatnotes has been deployed – Wikipedia:Village pump (technical)#Thursday 13 June style changes. —⁠andrybak (talk) 19:47, 13 June 2024 (UTC)[reply]

Please see Wikipedia:Village pump (technical) § Redlinks are blue in mobile hatnotes (permanent link). Thanks, Sdrqaz (talk) 03:53, 5 February 2025 (UTC)[reply]