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:
- 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 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. - 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)
- Three separate issues:
- 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:
- 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):
Lots of them
|
---|
|
- 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)
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)
- Of course, yes. --Edgars2007 (talk/contribs) 19:20, 7 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
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
p._formatLink() is special cased for category and files links, but interwiki links with a prefix of language code need this too or they're treated as language links. Actually, does it harm if we add colon to all links? Main Page works the same as Main Page. Liangent (talk) 20:38, 28 January 2016 (UTC)
- @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)
- I've tidied the code up. I can't think of any downsides to this, unless
role="note"
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
(See also previous discussion at Template talk:Hatnote)
Since using <aside> tags isn't yet feasible, I suggested adding equivalent accessibility context using the role attribute. Module:Hatnote/sandbox has the changes (diff). If anyone wants to check the results on a screen reader, I made a comparable edit to mw:'s hatnote template: mw:Special:WhatLinksHere/Template:Hatnote. Matt Fitzpatrick (talk) 22:24, 5 February 2016 (UTC)
- 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 copy this module over to the other wiki, it does not work.
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)