Module talk:Hatnote

Inline variant

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

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

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

Three separate issues:

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

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

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

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

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

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

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

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

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:

Lots of them

That we're talking about allowing or disallowing the inline equivalent of hatnotes (we 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 {{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 {{Ghat}} has anything to do at all with "unclear glossary terms" (its principal use is for {{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.

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

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

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

Transcluding articles

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

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

Just a note

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

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

Best regards,

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

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

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

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... Example. --Obsuser (talk) 04:13, 16 December 2015 (UTC)

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

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

p._formatLink() for interwiki links

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

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

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

role="note"

(See also previous discussion at Template talk:Hatnote)

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

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

Done No objections from anyone, so done. — Mr. Stradivarius ^{♪ talk ♪} 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 importing infobox templates at MediaWiki.org lack a solution to importing Templates that have Scribunto and lua elements. GodBlessYou2 (talk) 16:00, 28 March 2016 (UTC)

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

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

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