Vis kilden til Moduldiskusjon:Hatnote

{{Old TfD|date= 2018 July 4 |merge=self |result=no consensus |disc=Module:Hatnote inline}}
{{copied|from=Module:Hatnote|from_oldid=779487706|to=:incubator:Module:Wp/nod/Hatnote|to_diff=4241185}}

==Inline variant==
{{stale|Discussion restarted at [[#Inline hatnotes]], below, 2+  years later.}}
I added a test to handle an "<code>inline</code>" parameter, to output hatnotes as spans instead of divs.  This will have various applications.  One I've already deployed is {{tlx|Ghat}} for non-indented hatnotes atop [[MOS:GLOSSARY|glossary]] definitions (it wraps the inline hatnote span inside a {{tag|p}}; other use cases could wrap inline hatnotes inside table cells or list items or whatever, as needed). Another is {{tlx|Hatnote-inline}}, a meta-template for inline "see also..." and "for more information...", etc., notes.<p> 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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 21:27, 23 May 2014 (UTC)</p>
: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 (<code><nowiki>{{see also inline|Foo}}</nowiki></code>)". I think we should avoid adding more templates when inline wikitext will do just as well. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 23:48, 23 May 2014 (UTC)
::Three separate issues:
::#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.
::#As for actually inline-in-body-text notes, I suppose they are not really {{em|hat}}notes, 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 {{em|prevented}} from creating custom inline ones, just as they can use the bare wikicode I use below, or {{tlx|Hatnote}}, to create custom block ones.  Good for good, good for gander.
::#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 <code><nowiki>:''Insert your [[cross references here]]''</nowiki></code> 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. :-) <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 09:41, 24 May 2014 (UTC)
:{{od}}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 &lt;div> tag only, not &lt;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 <code>class=</code> 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 {{tl|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 ''hat''note does not need to be in top just because of its name. For example {{tl|further}} is used at the bottom too. OTOH, [[Three foot six inch gauge railways#Installations|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.
:-[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 06:31, 26 May 2014 (UTC)
::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:
{{collapse top|title=Lots of them}}
:::*That we're talking about allowing or disallowing the inline equivalent of hatnotes (we {{em|do}} allow them; there are tens of thousands of them already deployed, they're simply done haphazardly and inconsistently); this discussion is about consistently formatting them, and using this module (or an offshoot of it, it doesn't really matter) to do this, instead of using old-school template code to do it.
:::*That the decision of some editors in some contexts to not use wikilinking or another form of rewriting and to instead make an explicit WP self-ref in the form of hatnote-style "See..." or "For more..." wording, is either a) a decision that must be countermanded, or b) a decision that must be left exactly as it was originally made.  This is a false dichotomy.  There is absolutely no reason that hatnotes ''per se'' should be standardized and templated while their inline but otherwise directly equivalent counterparts should be left to random whim and vagary.
:::*That the difference between divs and spans is that divs are "set out of body/content by html handling in general" (which is not correct conceptually or technically; it seems to be a miremembering of the "outside the normal document flow" wording of the description of the float CSS directive).
:::*That the chaos I'm talking about with regard to the form and formatting of inline cross-references ("inline hatnotes") has anything at all, even slightly, to do with div vs. span, much less that the difference "also explains" this chaos.  That doesn't even parse.  The inline stuff needs to use span because it's inline, and span is an inline element that can be styled and classed just like a div, but isn't block-level as a div is.  The chaos (inconsistency, encyclopedic tone problem, POV pushing, etc.) rampant in untemplated inline crossreferences is unrelated in any way to div/span, but is a matter of the lack of templates that shunt these cross-references into canonical forms the way we do with "traditional" hatnotes.
:::*That there is some special difference between a hatnote at the top of a page versus one used atop a table or in some other infra-page context; if this were actually the case, we would have no section-level hatnotes, yet {{tlx|Main}} is exclusively such a hatnote and one of the most-used hatnotes on the system.  DePiep latermakes a point of observing hatnotes even in the more formal sense being used in his view correctly at the bottoms of pages, so the entire point is moot.
:::*That DePiep's own re-wording of [[WP:HATNOTE]] as asking "Am I on the right page?" is accurate or even relevant, or that the wording there, intended to cover hatnotes at the tops of pages only, indicates anything about how they (or things like them, but inline) are and should be used elsewhere than at page-top.  It's a [[red herring]].
:::*That {{tlx|Ghat}} has anything to do at all with "unclear glossary terms" (its principal use is for {{tlx|Main}}-style cross-references).
:::*That because "there could be a part of a sentence being cut out" that templating inline equivalents of hatnotes "is idle hope"; but one cannot simultaneously suggest that a) the way around using what amounts to an inline hatnote is to write more carefully, and also say b) that we can't use inline hatnotes (cross-references) because it's impossible to write more carefully.  Cases where an inline cross-reference is integrated so tightly into a sentence that it cannot be templated, that's obviously a good case for rewriting to just flow into the sentence with wikilinking of words in context instead of making explicit cross-references, exactly as DePiep suggests in the first place.
:::*That the semantics between the uses (true hatnote and inline crossreference) are in fact different (they are not, except, as already noted, in cases where an inline crossreference is so integrated into a sentence that it should be rewritten to not be a WP self-ref, rather than be rewritten to use an inline crossreference template such as we're discussing here.
:::*And so on.
{{collapse bottom}}
::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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 11:47, 30 May 2014 (UTC)
::: Hello [[user:SMcCandlish|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.  <span style="color:#666">&ndash;&nbsp;[[User:Sj|SJ]][[User Talk:Sj|<span style="color:#f90;">&nbsp;+</span>]]</span> 01:25, 14 June 2014 (UTC)
::::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. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 22:23, 13 August 2014 (UTC)
*@{{U|Mr. Stradivarius}}, @{{U|Sj}}, {{ping|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 {{tlx|Crossreference}} mostly used between pages to {{tlx|See above}} used inside a particular article, to {{tlx|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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 21:58, 28 March 2016 (UTC)
::No. Please read [[WP:HATNOTE]] first. And don't ping me for this any more. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 22:03, 28 March 2016 (UTC)
:::Since your input is just [[WP:IDONTLIKEIT]] filibustering, I won't. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:13, 28 March 2016 (UTC)
::::No. My input is: ''the concept of "Hatnote" does not accomodate inline usage''. As others have decribed here too. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 21:04, 30 March 2016 (UTC)
:::::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 {{tag|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 {{tag|div|o}}-based ones are often used at the end of things, not atop them (e.g. {{tlx|More}}).<span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 22:34, 21 June 2016 (UTC)

== Transcluding articles ==

{{ping|Mr. Stradivarius}} any idea why this module is causing [//en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Electronic_musician&hidelinks=1 this list] to not be empty? [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 22:12, 13 August 2014 (UTC)
:{{ping|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 [[WP:VPT#Dablinks: link to redirect|discussed at VPT]]. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 01:36, 14 August 2014 (UTC)

== Just a note ==

Maybe there could be done something to fix [[Special:Diff/651635481|such cases]] automatically? For example, creating new module/extending current module, so the template {{tl|Distinguish}} could have such code: <code><nowiki>{{#invoke:Hatnote|hatnote|pre=Not to be confused with|sep=or}}</nowiki></code> Just for consideration. --'''[[User:Edgars2007|<span style="color:#FF6600;">Edgars2007</span>]]''' <small>([[User talk:Edgars2007|talk]]/[[Special:Contributions/Edgars2007|contribs]])</small> 16:17, 7 April 2015 (UTC)
:Hello, {{u|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,
:[[User:Codename Lisa|Codename Lisa]] ([[User talk:Codename Lisa|talk]]) 18:24, 7 April 2015 (UTC)
::Of course, yes. --'''[[User:Edgars2007|<span style="color:#FF6600;">Edgars2007</span>]]''' <small>([[User talk:Edgars2007|talk]]/[[Special:Contributions/Edgars2007|contribs]])</small> 19:20, 7 April 2015 (UTC)
:::{{Ping|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, [[User:Codename Lisa|Codename Lisa]] ([[User talk:Codename Lisa|talk]]) 00:03, 15 April 2015 (UTC)

== Italics and padding ==
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... [https://sr.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:Main Example]. --[[User:Obsuser|Obsuser]] ([[User talk:Obsuser|talk]]) 04:13, 16 December 2015 (UTC)
:{{ping|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 [[Special:Diff/642595099|since been removed]].) — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 06:37, 16 December 2015 (UTC)
::{{ping|Mr. Stradivarius}} OK, we’ll update it. Thank you for help! [[File:Face-smile.svg|22px]] --[[User:Obsuser|Obsuser]] ([[User talk:Obsuser|talk]]) 16:52, 16 December 2015 (UTC)

== p._formatLink() for interwiki links ==
{{edit protected|answered=yes}}
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]]. <span class="signature signature_2539476">[[User:Liangent|Liangent]] ([[User talk:Liangent|talk]])</span> 20:38, 28 January 2016 (UTC)
:{{ping|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 --[[User:Ahecht|Ahecht]] ([[User_talk:Ahecht|<span style="color:#FFF;background:#00f;display:inline-block;padding:1px 1px 0;vertical-align:-0.3em;line-height:1;font-size:50%;text-align:center;"><b>TALK<br />PAGE</b></span>]]) 23:58, 28 January 2016 (UTC)
::I've tidied the code up. I can't think of any downsides to this, unless <code>_formatLink</code> is being substituted somewhere, but [[Template:Format link]] isn't set up for substitution and I'm not aware of any other places that <code>_formatLink</code> is directly exposed to wikitext. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 23:30, 28 January 2016 (UTC)

== role="note" ==

{{edit template-protected|Module:Hatnote|answered=yes}}
(See also previous discussion at [[Template talk:Hatnote#Hatnotes_in_HTML5:_.3Caside.3E_instead_of_.3Cdiv.3E|Template talk:Hatnote]])

Since using &lt;aside> tags isn't yet feasible, I suggested adding equivalent accessibility context using the role attribute. [[Module:Hatnote/sandbox]] has the changes ([[Special:Diff/702218800/703499537|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]]. [[User:Matt Fitzpatrick|Matt Fitzpatrick]] ([[User talk:Matt Fitzpatrick|talk]]) 22:24, 5 February 2016 (UTC)
: [[Special:Diff/702218800/703509838|Updated diff]]. [[User:Matt Fitzpatrick|Matt Fitzpatrick]] ([[User talk:Matt Fitzpatrick|talk]]) 07:09, 11 February 2016 (UTC)
:[[File:Yes check.svg|20px|link=]] '''Done'''<!-- Template:ETp --> No objections from anyone, so done. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 01:36, 12 February 2016 (UTC)


==How are Modules like this Copied to another Wiki??==

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 [https://www.mediawiki.org/wiki/Manual:Importing_Wikipedia_infoboxes_tutorial#Step_2a:_Export_Wikipedia_Modules importing infobox templates at MediaWiki.org ] lack a solution to importing Templates that have Scribunto and lua elements. [[User:GodBlessYou2|GodBlessYou2]] ([[User talk:GodBlessYou2|talk]]) 16:00, 28 March 2016 (UTC)
:{{ping|GodBlessYou2}} You need to install the [[mw:Extension:Scribunto|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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 16:12, 28 March 2016 (UTC)
::Once you get Scribunto installed, you will also need to copy over [[:Module:Arguments]] and [[:Module:Yesno]] --[[User:Ahecht|Ahecht]] ([[User_talk:Ahecht|<span style="color:#FFF;background:#00f;display:inline-block;padding:1px 1px 0;vertical-align:-0.3em;line-height:1;font-size:50%;text-align:center;"><b>TALK<br />PAGE</b></span>]]) 16:24, 28 March 2016 (UTC)

:::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 [https://www.mediawiki.org/wiki/Manual:Importing_Wikipedia_infoboxes_tutorial Manual:Importing Wikipedia infoboxes tutorial][[User:GodBlessYou2|GodBlessYou2]] ([[User talk:GodBlessYou2|talk]]) 20:32, 28 March 2016 (UTC)

== forSee addition ==

I've been toying around with the <code>forSee</code> 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 "<code><nowiki>For X, see [[Y]]</nowiki></code>" 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, <code>_forSee</code> takes argument list directly, <code>forSee</code> uses <code>getArgs(frame)</code>)
* 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 {{tl|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…

[[Template:Redirect/testcases|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.

<code><nowiki>{{redirect|REDIRECT|USE1|PAGE1|USE2}}</nowiki></code> → {{redirect|REDIRECT|USE1|PAGE1|USE2}}
<code><nowiki>{{redirect/sandbox|REDIRECT|USE1|PAGE1|USE2}}</nowiki></code> → {{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? <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 16:13, 7 April 2016 (UTC)
:I am still missing the core analysis of hatnote templates. That is: {{cl|Hatnote templates}} has ~60 hatnotes, and more in subcategories. What is the ''pattern'' in all these? My first throw:
:{{purple|Primary}}: <code>class=hatnote</code>. 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''.
:{{purple|Secondary}}: the templates use '''&lt;PAGENAME>''', '''labels''' (as in <code><nowiki>[[page|label]]</nowiki></code>), 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 &lt;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 {{tl|hatnote}} and compose the text myself)].
:{{purple|Tertionary}}: listing handling, grammar
:{{purple|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).
:-[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 17:19, 7 April 2016 (UTC)
::{{re|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:
::#Clean up, centralize, and modernize existing stuff ("simplify the landscape")
::#Hold discussions on how hatnotes ought to be: scope, intent, features, etc. (design questions)
::#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? <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 19:20, 7 April 2016 (UTC)
:::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 {{purple|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) -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 19:44, 7 April 2016 (UTC)
:::::I'm happy to "replace the dirt" if it means replacing random dirt with centralized, standard, reusable dirt. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 19:15, 8 April 2016 (UTC)
::::::You are too arrogant to be trusted with such a job. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 21:03, 8 April 2016 (UTC)
::::I'd like to read the advise of {{U|Mr. Stradivarius}} about this (Strad wrote this module). -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 20:00, 7 April 2016 (UTC)

==New docstyle== 
: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:
* <code><nowiki>{{redirect|FromRedirectPage|Topic1|Targetpage1|Topic2}}</nowiki></code> → {{redirect|FromRedirectPage|Topic1|Targetpage1|Topic2}}
* <code><nowiki>{{redirect/sandbox|FromRedirectPage|Topic1|Targetpage1|Topic2}}</nowiki></code> → {{redirect/sandbox|FromRedirectPage|Topic1|Targetpage1|Topic2}}
:{{U|Nihiltres}}, is that final link change intended? (see what good demos do ;-) ). -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 19:55, 7 April 2016 (UTC)

::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:
::# include the string "PAGE" on example inputs that are intended to reflect page names
::# include the string "TEXT" on example inputs that are passed through as plain text
::# have example inputs reflect their intended replacements in actual use.
::So, for example:
::* <code><nowiki>{{redirect2|REDIRECTPAGE1|REDIRECTPAGE2|USAGE1|PAGE1}}</nowiki></code> → {{redirect2|REDIRECTPAGE1|REDIRECTPAGE2|USAGE1|PAGE1}}
::* <code><nowiki>{{about|TOPICTEXT|USAGE1|PAGE1|and|PAGE2}}</nowiki></code> → {{about|TOPICTEXT|USAGE1|PAGE1|and|PAGE2}}
::<span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 20:11, 7 April 2016 (UTC)
:::'''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]. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]])
::::{{re|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:
::::*<code><nowiki>{{redirect|REDIRECTPAGE1|TOPIC1|PAGE1|other uses}}</nowiki></code> → {{redirect|REDIRECTPAGE1|TOPIC1|PAGE1|other uses}}
::::*<code><nowiki>{{about|ABOUT-TEXT|TOPIC1|PAGE1|other uses}}</nowiki></code> → {{about|ABOUT-TEXT|TOPIC1|PAGE1|other uses}}
::::*<code><nowiki>{{redirect/sandbox|REDIRECTPAGE1|TOPIC1|PAGE1|other uses}}</nowiki></code> → {{redirect/sandbox|REDIRECTPAGE1|TOPIC1|PAGE1|other uses}}
::::…perhaps my sandboxed code's behaviour is actually preferable. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 23:04, 7 April 2016 (UTC)
:::::<small>Writing uppercase is actually [[WP:SHOUTING|shouting]]. Stop it. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 00:23, 8 April 2016 (UTC)</small>
:{{od}} 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? -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 23:10, 7 April 2016 (UTC)
::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? -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 23:14, 7 April 2016 (UTC)
:::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. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 23:57, 7 April 2016 (UTC)
: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 "Topic''n''" and "Targetpage''n''" throughout. Whatever the cost. 12. (later more). -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 00:14, 8 April 2016 (UTC)
::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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 19:12, 8 April 2016 (UTC)
:::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? -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 21:01, 8 April 2016 (UTC)

== Standardizing for-see lists ==

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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 17:26, 27 April 2016 (UTC)

== Category handling ==

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

Would anyone object to my adding a <code>category</code> argument to <code>_hatnote()</code>? I'd code it to accept a table (or <code>nil</code>), with category name keys (prevents duplicates) and <code>false</code> or category-key (string) values, and output a list of categories after the hatnote text. I'd also add a helper function <code>addCategory()</code> 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 <code>_hatnote()</code> doesn't itself get template arguments, templates would each need to include something like <code>yesno(args.category)</code> 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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 14:44, 11 May 2016 (UTC)

== Inline hatnotes ==

[[User:SMcCandlish|SMcCandlish]] pointed out at [[Wikipedia talk:Hatnote#Discussion (Standardizing for-see lists)]] that there exists [[Module:Hatnote inline]] and {{tl|hatnote inline}}, which largely duplicate the functionality of this module and {{tl|hatnote}}. I've therefore [[Special:Diff/719915352/726349474|prototyped a simple enhancement]] to this module that adds support for inline hatnotes, with a simple <code>inline</code> parameter or argument that causes the module to emit a <code>&lt;span&gt;</code> element rather than a <code>&lt;div&gt;</code>. 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? <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 20:26, 21 June 2016 (UTC)
: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 [[WP:MFD|MFD]]. And if we do decide to use something like this, we should at least change the name. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 23:02, 21 June 2016 (UTC)
:::Except that they often do not. Various ones, like {{tlx|further information}} and {{tlx|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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 04:19, 22 June 2016 (UTC)
::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 {{tl|crossreference}}, {{tl|see above}}, and {{tl|see below}}. There's a mess of both Lua and wikitext supporting those, but only 300ish transclusions overall. Actually, now that I look closer, {{tl|see above}} and {{tl|see below}} are … frightening monsters of needless customizability. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 23:51, 21 June 2016 (UTC)
:::I was going to scrap {{tlx|see above}} and {{tlx|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 {{tag|div}} vs. {{tag|span}}. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 04:19, 22 June 2016 (UTC)

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:
* {{tag|span|o}}-based hatnotes (in the traditional "hat" position or otherwise) can be used in layout scenarios where insertion of a {{tag|div}} would be disruptive to document flow or even invalid markup.  See, e.g., {{tlx|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 {{tag|span|o}} instead of {{tag|div|o}}. (Not all existing hatnotes need this; those intended for disambiguation, for example, should always be page-top hatnotes, while contextual cross-references, like {{tlx|further information}} and {{tlx|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 {{em|really}}. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 04:19, 22 June 2016 (UTC)
: Some recent change, possibly to [[Module:Hatnote inline]], seems to have broken at least {{tl|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. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 14:47, 17 July 2016 (UTC)
::{{re|Hairy Dude}} Can't reproduce the issue here. I double-checked my rewrite of [[Module:Hatnote inline]] and it looks fine; the {{tl|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 <code>.hatnote</code>, but only to <code>div.hatnote</code>. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 16:40, 17 July 2016 (UTC)
:::{{re|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 {{code|load.php}} applies: {{code|.hatnote { display: block !important {{)}}}}. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 19:21, 17 July 2016 (UTC)
::::{{re|Hairy Dude}} Tracked it down to [[User:Hairy Dude/common.css]]. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 19:59, 17 July 2016 (UTC)
:::::{{re|Nihiltres}} I am an idiot. Thanks :) [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 00:05, 18 July 2016 (UTC)

==Rename the module and meta-template to reflect actual usage==
"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 {{tlx|More2}}, can {{em|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 {{tlx|Hatnote}}'s presently mandatory {{tag|div|o}}; it just wastes space and interrupts the flow of the document in many cases.)
* Others, like {{tlx|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 {{tag|span|o}} 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 ({{tlx|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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 05:37, 22 June 2016 (UTC)

: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 {{tl|main}} is to [[Wikipedia:Summary style|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 <code>hatnote</code> 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 {{tlf|rellink}} in 2009 (now merged to {{tl|hatnote}}), lumping together "related links" under a meta-template in the same way that "disambiguation links" ({{tlf|dablink}}, since renamed to {{tlf|hatnote}}) did.
:I can see value in allowing hatnotes to be used inline for a few cases where &lt;div&gt; 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 [https://tools.wmflabs.org/templatecount/index.php?lang=en&namespace=828&name=Hatnote+inline only used on ~300 articles], while the main, normative [[Module:Hatnote]] [https://tools.wmflabs.org/templatecount/index.php?lang=en&namespace=828&name=Hatnote has broken the 1 million mark]. Your example {{tl|more2}} currently has ''1'' mainspace transclusion and is described in its documentation as "where {{tl|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 {{tl|hatnote inline}} and its like entirely? <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 00:46, 23 June 2016 (UTC)
::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 {{tlx|Hatnote}} meta-template before Lua, and many of them have routinely been used below not above content since Olden Tymes.  E.g., {{tl|Details}} dates to mid-2005 and has frequently been used this way (which is not against any guideline or policy, or common sense), and {{tl|More2}}, which makes no sense at all above content, dates to 2009.<p>I agree, of course, that we have structural norms, but these are not set by obscure <code>Module:</code>-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 {{tl|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).</p><p>There is no scope {{em|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.</p><p> 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 {{tl|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).</p><p>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 {{tl|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.</p><p>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.</p><p>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 {{em|hat}}note and isn't a div" stuff is putting form before function, and past above the present. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 16:53, 26 June 2016 (UTC)</p>
* 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. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 11:43, 27 June 2016 (UTC)

== Add navigation-not-searchable class ==

{{edit template-protected|Module:Hatnote|answered=yes}}
Per {{phabricator|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. [[User:Kaldari|Kaldari]] ([[User talk:Kaldari|talk]]) 03:17, 9 May 2017 (UTC)
:[[File:Yes check.svg|20px|link=|alt=]] '''Done'''<!-- Template:ETp --> —&thinsp;[[User:JJMC89|JJMC89]]&thinsp;<small>([[User talk:JJMC89|T]]'''·'''[[Special:Contributions/JJMC89|C]])</small> 05:20, 9 May 2017 (UTC)

== Replace underscores with spaces ==

It would be helpful if the <code>_formatLink</code> function would automatically replace underscores with spaces. Ideally people would always insert links with spaces, but that doesn't always happen; see {{oldid2|767159247|Proto-Slavic basis of Slovak|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 <code>section_link</code> function in [[wikt:Module:links|Module:links]]). — [[User:Erutuon|Eru]]·[[User talk:Erutuon|tuon]] 17:53, 21 July 2017 (UTC)

* 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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 19:39, 25 June 2018 (UTC)
*: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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 03:27, 26 June 2018 (UTC)
*:{{ping|Nihiltres|Erutuon}} Agreed with {{u|SMcCandlish}}. If my open [[WP:ER]] is accepted, I'll make another one implementing this. [[User:Psiĥedelisto|Psiĥedelisto]] ([[User talk:Psiĥedelisto|talk]] • [[Special:Contributions/Psiĥedelisto|contribs]]) <sup>please ''always'' [[Help:Notifications|ping]]!</sup> 09:53, 13 June 2020 (UTC)
*::Oh—I should clarify before it's too late—either I'd add it as an optional parameter, e.g. <code>_=r</code> (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 {{u|Nihiltres}}. {{=3|8}} [[User:Psiĥedelisto|Psiĥedelisto]] ([[User talk:Psiĥedelisto|talk]] • [[Special:Contributions/Psiĥedelisto|contribs]]) <sup>please ''always'' [[Help:Notifications|ping]]!</sup> 01:40, 14 June 2020 (UTC)
**{{ping|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 [https://en.wikipedia.org/w/index.php?search=hastemplate%3A%22main%22+insource%3A%2F%5C%7B%5C%7B%5Cs%2Amain%5B%5E%5C%7D%5D%2A%3F_%5B%5E%5C%7D%5D%2A%3F%5C%7D%5C%7D%2F&title=Special:Search&go=Go&ns0=1 a regex-based search], which timed out (regex searches are expensive) but produced 220 hits of pages calling {{tl|main}} with input containing an underscore, where {{tlc|main}} is transcluded to approximately 280k pages. Of the first 20 hits, 6 used the "label''n''" 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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 20:44, 15 June 2020 (UTC)
***{{ping|Nihiltres}} What do you think about filtering at the level of {{tl|format link}} via {{tl|replace}}, instead of the module level? [[User:Psiĥedelisto|Psiĥedelisto]] ([[User talk:Psiĥedelisto|talk]] • [[Special:Contributions/Psiĥedelisto|contribs]]) <sup>please ''always'' [[Help:Notifications|ping]]!</sup> 20:48, 15 June 2020 (UTC)
****{{ping|Psiĥedelisto}} A search <code><nowiki>hastemplate:"format link" insource:/\{\{ *format link[^\}_]*?_[^\}_]*?\}\}/</nowiki></code> 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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 20:56, 15 June 2020 (UTC)

== Selfref ==

The {{para|selfref|true}} feature says in the documentation that it replicates {{tl|selfref}}. However, in the module it adds the class "selfref", while {{tl|selfref}} adds "plainlinks selfreference noprint". Shouldn't these be the same? --[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</span>]]) 18:53, 23 August 2018 (UTC)

*{{re|Ahecht}} Yes, we should probably make <code>selfref</code> and <code>selfreference</code> consistent; the question is simply which to choose. Based on some searches, e.g. <code><nowiki>insource:selfreference -insource:/tl\|selfref/ -insource:/\{\{selfref/ -hastemplate:selfref</nowiki></code> in the MediaWiki and Template namespaces, it looks like <code>selfref</code> may have more extant uses. I'm not picky about that, though. The additional classes are redundant: <code>noprint</code> because hatnotes are excluded already in [[MediaWiki:Print.css]], and <code>plainlinks</code> because hatnotes should never contain external links. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 20:07, 19 December 2018 (UTC)
*: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). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 06:51, 16 June 2020 (UTC)

== Italicize ==

{{Edit fully-protected|answered=yes}}
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 {{tl|format link}}. {{format link|Quo warranto#Philippines}} appears, therefore, counter to [[WP:MOS]]. While often automatically italicized as used in {{tl|hatnote}}, {{tl|see also}}, etc., I often find occasion to use this template alone. Therefore, I have fixed it:

* <code><nowiki>{{format link|Quo warranto#Philippines|italicizearticle=y}}</nowiki></code>
:: Now gives: {{User:Psiĥedelisto/Format link|Quo warranto#Philippines|italicizearticle=y}}
* <code><nowiki>{{format link|Cybercrime Prevention Act of 2012#Disini v. Secretary of Justice|italicizesection=y}}</nowiki></code>
:: Now gives: {{User:Psiĥedelisto/Format link|Cybercrime Prevention Act of 2012#Disini v. Secretary of Justice|italicizesection=y}}

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:
# [[:Module:Sandbox/Psiĥedelisto/Hatnote]] → [[:Module:Hatnote]]
# [[:User:Psiĥedelisto/Format link]] → [[:Template:Format link]]

Thanks! [[User:Psiĥedelisto|Psiĥedelisto]] ([[User talk:Psiĥedelisto|talk]] • [[Special:Contributions/Psiĥedelisto|contribs]]) <sup>please ''always'' [[Help:Notifications|ping]]!</sup> 09:52, 13 June 2020 (UTC)
:{{ping|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 <syntaxhighlight lang=lua inline>_formatLink("Foo#Bar", nil, nil, true)</syntaxhighlight>. With named arguments this becomes <syntaxhighlight lang=lua inline>_formatLink{link = "Foo#Bar", italicizeSection = true}</syntaxhighlight>, 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 <code>italicizearticle</code> parameter to <code>italicizepage</code>, 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 — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 08:03, 14 June 2020 (UTC)
::{{ping|Mr. Stradivarius}} Your changes all seem broadly positive to me, and I haven't find any bug in your version. {{=3|8}} [[User:Psiĥedelisto|Psiĥedelisto]] ([[User talk:Psiĥedelisto|talk]] • [[Special:Contributions/Psiĥedelisto|contribs]]) <sup>please ''always'' [[Help:Notifications|ping]]!</sup> 15:18, 14 June 2020 (UTC)
:::[[File:Yes check.svg|20px|link=|alt=]] '''Done'''<!-- Template:ETp --> {{ping|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 — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 15:26, 16 June 2020 (UTC)

== User pages in [[:Category:Hatnote templates with errors]] ==

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? —⁠[[User:Andrybak|andrybak]] ([[User talk:Andrybak|talk]]) 13:34, 4 July 2020 (UTC)
:{{ping|Andrybak}} That sounds like a reasonable suggestion to me. I've implemented the code to do this in [[Module:Hatnote/sandbox]] ([[Special:Diff/962884663/967153198|diff]]). If no-one objects in the next day or so I will put it up live. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 13:05, 11 July 2020 (UTC)
::{{ping|Andrybak}} The code is now up live. You should see it slowly start to filter out userspace pages from the category. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 15:06, 14 July 2020 (UTC)

== Spacey space ==

{{edit template-protected|answered=yes}}
The module's <code>_formatLink</code> function adds an unnecessary space when fed just a section. E.g.:

{| class="wikitable"
!Input
|{{Code|<nowiki>({{format linkr|#Italicize}})</nowiki>}}
|-
!Output (expected)
|([[:#Italicize|§&nbsp;Italicize]])
|-
!Output (actual)
|([[:#Italicize| §&nbsp;Italicize]])
|}

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 {{para|italicizePage|true}}, which will do it as a side effect of adding an empty {{tag|i}}. [[User:Psiĥedelisto|Psiĥedelisto]] ([[User talk:Psiĥedelisto|talk]] • [[Special:Contributions/Psiĥedelisto|contribs]]) <sup>please ''always'' [[Help:Notifications|ping]]!</sup> 23:36, 28 July 2020 (UTC)
: {{ping|Psiĥedelisto}} {{done}} [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 00:47, 29 July 2020 (UTC)
:: {{ping|Psiĥedelisto}} Thanks for spotting this and for making the fix. Having section-only links that add an empty {{tag|i}} also sounds like a bug to me, so I [[Special:Diff/970053730/970133728|added another test case]] and made a [[Special:Diff/970133456|fix in the sandbox]]. Do you think this would be a good addition to the module? Best — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 13:29, 29 July 2020 (UTC)
:::{{re|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. {{=3|8}} [[User:Psiĥedelisto|Psiĥedelisto]] ([[User talk:Psiĥedelisto|talk]] • [[Special:Contributions/Psiĥedelisto|contribs]]) <sup>please ''always'' [[Help:Notifications|ping]]!</sup> 16:14, 29 July 2020 (UTC)
::::{{re|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 — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 13:43, 30 July 2020 (UTC)
:::::I've gone ahead and put my fix up live. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 13:48, 30 July 2020 (UTC)
:Why is it <code>[[:#Section|…</code> and not just <code>[[#Section|…</code>?
:With a colon, it links to the Main Page via https://en.wikipedia.org/wiki/#…: [[:#Spacey space|§&nbsp;Spacey space]] (except in the reply preview, apparently...). Without a colon, it links to the relevant section of the current page: [[#Spacey space|§&nbsp;Spacey space]].
:If for some reason I want the former, I can explicitly add <code>Main Page</code> before the <code>#</code>. However, I pretty much always want the latter, such as to link between related sections of a disambiguation page.
:There is a workaround for this, but it's somewhat ugly, and avoids using this module: https://en.wikipedia.org/w/index.php?title=E_(disambiguation)&diff=1366588289&oldid=1366583972
:Is the current behavior intended, and could it be changed?
:[[User:Sollyucko|Solomon Ucko]] ([[User talk:Sollyucko|talk]]) 16:37, 3 September 2026 (UTC)

== Redlink detection in _formatLink ==

On a few hatnote templates, {{u|MB}} has requested that I add redlink detection, because it's a reasonably common error that could be tracked and fixed. I've [[Special:Diff/1059393371|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 {{tl|format link}}, which reuses the hatnote functionality; this could probably be mitigated in several ways. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 21:17, 11 December 2021 (UTC)

: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 {{txl|main}} with a redlink target. [https://en.wikipedia.org/w/index.php?title=Rivi%C3%A8re_de_la_Tortue_(Delson)&oldid=1060368099 this version] of [[Rivière de la Tortue (Delson)]] has a redlink target in {{txl|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. [[User:MB|<b style="color:#034503">MB</b>]] 02:49, 15 December 2021 (UTC)
::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). <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 18:15, 16 December 2021 (UTC)
: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. {{tl|Format link}} is [https://en.wikipedia.org/w/index.php?title=Special%3AWhatLinksHere&target=Template%3AFormat+link&namespace=10 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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 05:30, 15 December 2021 (UTC)
::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 {{tl|format link}} uses. That means the current prototype shouldn't affect {{tlf|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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 18:15, 16 December 2021 (UTC)

===Extracting formatLink===
I've done a decent chunk of the work to extract the functionality of <code>formatLink</code> and <code>_formatLink</code> to [[Module:Format link]], as that seems to be the most sensible restructuring given that {{tl|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 <code>formatLink</code> or a string option to <code>_formatLink</code>, 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 <span class="plainlinks">[https://en.wikipedia.org/w/index.php?search=hastemplate%3A%22Module%3AHatnote%22+insource%3A%2FformatLink%2F&title=Special:Search&profile=advanced&fulltext=1&ns828=1 few other modules]</span> 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 ({{u|Mr. Stradivarius}}, especially). Thanks, <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 18:50, 20 December 2021 (UTC)
:{{ping|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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 14:10, 21 December 2021 (UTC)
::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, <code>formatPages</code> has a couple of uses, so I added a generalized analogue (allowing the categorization option) to [[Module:Format link]]. The second, <code>formatPageTables</code>, 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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 19:32, 21 December 2021 (UTC)
{{undent}}(ping {{u|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]]. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 22:50, 26 December 2021 (UTC)
: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. [[User:MB|<b style="color:#034503">MB</b>]] 22:57, 26 December 2021 (UTC)
::Actually, some of these are See also in category headers, so those should probably be clean-ed up also. [[User:MB|<b style="color:#034503">MB</b>]] 23:04, 26 December 2021 (UTC)
:::{{u|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? [[User:MB|<b style="color:#034503">MB</b>]] 04:39, 31 December 2021 (UTC)
::::{{u|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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 05:05, 31 December 2021 (UTC)
:::::{{u|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. [[User:MB|<b style="color:#034503">MB</b>]] 05:18, 31 December 2021 (UTC)
::::::{{u|MB}} {{done}} in [[Special:Diff/1063743122]]. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 18:26, 4 January 2022 (UTC)
==== {{tl|format linkr}} ====
FYI {{ping|Nihiltres|MB|Mr. Stradivarius}} Above changes broke {{tl|format linkr}}. Diagnosis at {{format linkr|User_talk:TryKid#%7B%7Bformat_linkr%7D%7D}}. {{small|(Yes, I do note the irony of using {{tl|format linkr}} to talk about {{tl|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. [[User:Psiĥedelisto|Psiĥedelisto]] ([[User talk:Psiĥedelisto|talk]] • [[Special:Contributions/Psiĥedelisto|contribs]]) <sup>please ''always'' [[Help:Notifications|ping]]!</sup> 13:19, 27 December 2021 (UTC)

:That's on me. I ''did'' check for uses, but changed my search query early on to something Lua-specific that no longer showed {{tl|format linkr}}, and thus missed that one. My apologies. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 16:12, 27 December 2021 (UTC)
::{{re|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 {{tl|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. [[User:Psiĥedelisto|Psiĥedelisto]] ([[User talk:Psiĥedelisto|talk]] • [[Special:Contributions/Psiĥedelisto|contribs]]) <sup>please ''always'' [[Help:Notifications|ping]]!</sup> 01:00, 28 December 2021 (UTC)

== Implement [[Template:Category pair]] in this module? ==

[[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]]? — [[User:Hike395|hike395]] ([[User talk:Hike395|talk]]) 07:42, 16 December 2021 (UTC)

: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. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 18:23, 16 December 2021 (UTC)
::Seconded - we use a separate module for e.g. [[Module:Cat main]], so having a [[Module:Category pair]] would follow that pattern. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 00:33, 17 December 2021 (UTC)

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

== <code>formatLink</code> is not used ==

Just came to tell you the <code>formatLink</code> variable is declared but not used. @[[User:Nihiltres|Nihiltres]], given [https://en.wikipedia.org/w/index.php?title=Module:Hatnote&diff=prev&oldid=1062158757 this edit], maybe you have the clue. [[User:JWBTH|Jack who built the house]] ([[User:JWBTH|talk]]) 22:32, 22 December 2023 (UTC)

== Mobile styling ==

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]]:
<syntaxhighlight lang=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;
}
</syntaxhighlight>

on mobile we've had the following additional styles:

<syntaxhighlight lang=css>
.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 */
}
</syntaxhighlight>

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 [https://en.m.wikipedia.org/wiki/Wikipedia:Redirect]) 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? [https://en.m.wikipedia.org/wiki/United_States 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 [https://en.m.wikipedia.org/wiki/Wikipedia:Citation_templates 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) [https://phabricator.wikimedia.org/rEMFRca26dee1daca1f7bfbb9af4859be7427c128c7c9#change-yqJy2NPI4RsE 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".) [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 07:20, 8 April 2024 (UTC)

:The smaller text with lighter foreground is easy to miss. It reminds me of image captions (for which article [https://en.m.wikipedia.org/wiki/United_States United States] is also a good example). I think that some hatnotes, like {{tl|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. —⁠[[User:Andrybak|andrybak]] ([[User talk:Andrybak|talk]]) 20:10, 30 May 2024 (UTC)
: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]]. —⁠[[User:Andrybak|andrybak]] ([[User talk:Andrybak|talk]]) 19:47, 13 June 2024 (UTC)

== Mobile hatnotes discussion at VPT ==

Please see {{slink|Wikipedia:Village pump (technical)|Redlinks are blue in mobile hatnotes}} ([[Special:Permalink/1274029609#Redlinks are blue in mobile hatnotes|permanent link]]). Thanks, [[User:Sdrqaz|Sdrqaz]] ([[User talk:Sdrqaz|talk]]) 03:53, 5 February 2025 (UTC)