Template talk:Further

Fix Template:See redirections

This request concerns not Template:Further, but rather pages which redirect here, or should.

Transclusions of Template:See seem to be breaking, see e.g. the top of Wikipedia:Citing sources#Inline_citations. This may be due to the double-redirection (Template:See redirects to Template:Further information, which in turn redirects here to Template:Further), or it may be due to the inclusion of Template: R from move on the intermediate Template:Further information page. Either way, the request is the same:

• Request: Please edit Template:See to redirect directly to Template:Further. Here's an edit link which includes &redirect=no.

I have already corrected Template talk:See to redirect directly here to Template talk:Further, along with Template talk:Further information, which had somehow been circularly redirected to itself. -- FeRD_NYC (talk) 04:58, 9 December 2017 (UTC)

 Done Redirect for Template:See changed. -- Alex^TW 06:10, 9 December 2017 (UTC)

Requested move 18 February 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: withdrawn Things won't break as long as the closer pays attention and fixes the double-redirects. But I do kind of get some of the other points. Galobtter (pingó mió) 17:14, 18 February 2018 (UTC)

---

Template:Further → Template:More information – clearer title and text (further what?), (along with accompanying text change to "More information:") Galobtter (pingó mió) 07:07, 18 February 2018 (UTC)

There are really two things here, so taking them separately:

• OPPOSE the text change from "Further information" to "More information". We have four distinct hatnotes that perform this basic function: {{Main}}, {{Details}}, {{Further}}, and {{See also}}. (With Template:Details slated to go away, I guess, folded into Template:Further.) They could all be described as "more information" links. Having distinct and non-generic text makes them each appropriate for linking to different types of additional information. And a distinctive word provides a better mnemonic for the template.
• OPPOSE the rename to the longer {{Further information}} (or {{More information}}) form. Typing {{Further}} is a helpful and concise mnemonic, and one point of templates is to save keystrokes. That can be taken to too great an extreme (the truly staggering number of template-linking templates with names like {{tlxb}} and {{tltts3}}, for example), but "the template's name isn't the exact thing it substitutes in" is a feature, not a deficiency, as far as I'm concerned.

Now, as jmcgnh (talk · contribs) wrote at Template talk:Main, "Ordinarily, I would be indifferent as to which name was considered the primary," as long as I could still type {{Further}} — in fact, normally I might favor the longer name being the primary, and the shorter an alias. But these templates have been shuffled around so much that they're a rat's-nest of redirects, things already broke in the last shuffling (see the section literally right above this one), and things are bound to break even more with another unnecessary renaming. You can already type {{Further information}} or {{More information}}, if that's what floats your boat, and get the effect desired. Renaming the templates is just more rearranging of the Titanic's deck chairs. -- FeRD_NYC (talk) 13:03, 18 February 2018 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Should pages in draft be used in hatnotes

I'm sure I've seen that this is not permitted, but an experienced editor has been inserting {{See|Draft:xyz}}. Can someone either give me a reference to where it is disallowed, or else disabuse me of my error? Thanks, Martin of Sheffield (talk) 09:55, 8 July 2020 (UTC)

@Martin of Sheffield:, was this ever resolved to your satisfaction? I believe you're correct, but I'd have to hunt down the guideline. Mathglot (talk) 02:28, 21 March 2022 (UTC)

No, nothing further ever came of it. To be honest, it was nearly two years ago now and I'd have to hunt to find out who and where. Would you like me to? Martin of Sheffield (talk) 08:25, 21 March 2022 (UTC)

Adding nowrap

A sidebar floated right
of the correct width
causes the 'Further'
template to wrap
to the next line
but using a new param
prevents it from breaking
in the middle of a link.

Further information: World War II, Events preceding World War II in Europe, and Causes of World War II

Further information: World War II, Events preceding World War II in Europe, and Causes of World War II

Further information: World War II, Events preceding World War II in Europe, and Causes of World War II

I ran into a situation at Vichy regime where there was a "Further" template with three links, and because of an adjacent right-float sidebar, the last of the three links wrapped in the middle of the link onto the next line, leaving "World War II" split between two lines at an awkward location, with "World War" at the end of one line, and the "II" all by itself on the next line.

In any case, I'm thinking about how we can do something to remedy this, which would effectively reproduce the effect of the {{nowrap}} template. In a single wikilink, one could do that like this: {{nowrap|[[Causes of World War II]]}}, or to protect just the 'II' at the end, one could even do: [[Causes of World War II|Causes of World {{nowrap|War II}}]], and so on. (The Html entity '&nsbp;' could be used there as well.)

I tried to reproduce the effect I saw using the example above, but not sure if the demo will work for you on other devices, fonts, browsers, etc. You can probably reproduce it by going to Vichy regime#Overview and playing with the window width until the last link in the "Further" links starts to wrap to the next line. In the example above, the top line uses the (live) {{Further}} template copied from Vichy regime; the second one is from the template sandbox using the same params; the third line is the sandbox again, but this time with proposed new param |nowrap=y as a proof of concept. If there is consensus for this, it could be ported to the module. Mathglot (talk) 06:00, 21 March 2022 (UTC)

On further reflection, I'd be tempted to make the new behavior the default, and dispense with the need of a new parameter. However, that would represent a change to current behavior, and although it seems like a beneficial one, I'm not sure if that's acceptable. Trying to think of any cases where a change in behavior of this type might cause problems; possibly in the case of very long article names, or narrow windows or mobile devices perhaps. Maybe we should test for mobile device (there's a template for that) and disable it in that case. Mathglot (talk) 06:16, 21 March 2022 (UTC)

Note: I have the mobile view gadget installed, and there's no change in mobile view; in both cases, all links appear on one line, running well past the right margin, and a horizontal scroll bar appears (in the gadget) so if you want to view the rest of the links, you have to scroll right. In an actual mobile device (iOS) it's about the same thing: all three lines look identical, and you have to swipe left to see the rest of the line off the right edge. So there seems to be no change and therefore no downside for mobile, if this became default behavior. Mathglot (talk) 06:22, 21 March 2022 (UTC)

Ping @Galobtter, Trialpears, Sdkb, and Wikmoz:. Mathglot (talk) 06:26, 21 March 2022 (UTC)

And Primefac. Mathglot (talk) 06:32, 21 March 2022 (UTC)

I'm relatively neutral on whether this should be implemented, as I'm not sure about potential side effects, but if it is to be implemented, it should probably happen for all hatnotes by default, and be implemented by adding the nowraplinks class (implemented at MediaWiki:Common.css) to the default hatnote classes in Module:Hatnote. This would require also editing Module:Hatnote group to reflect the new default class so as not to break that module. If it's to be optional, then it's already implemented through the extraclasses parameter, where one could manually add that class to the hatnote as needed. In that case, we might want to advertise the option better in template documentation and perhaps on Wikipedia:Hatnote. If certain hatnote templates don't support that parameter, let me know and I'll work on getting it implemented for them. {{Nihiltres |talk |edits}} 16:34, 21 March 2022 (UTC)

I don't see any reason why it should be optional, as I see zero reason why someone would want the link to be split. It's a problem that seems to need fixing, and the nowraplinks change sounds like it will do that. Primefac (talk) 17:30, 21 March 2022 (UTC)

I'm somewhat hesitant with making this change for such a large amount of templates without proper testing. If someone adds the behaviour to the hatnote class in their user css and plays around with window sizes and long links on computers and phones without encountering significant problems this proposal sounds good though. --Trialpears (talk) 08:42, 24 March 2022 (UTC)

@Trialpears:, that seems like reasonable caution. I was going to support your idea and propose that we all add something to our common.css and monitor it for a while, but in the current environment, I don't think that will work. Although Module:Hatnote supports extraclasses, Module:Labelled list hatnote does not, afaict, and Template:Further invokes Labelled list hatnote. @Nihiltres: (or anyone), can you advise on the best way to set up the conditions which would enable the type of interim test suggested by Trialpears involving changes to common.css to be a valid test? Does this require a change first to Module:Labelled list hatnote to even allow a test period to be run, or what's the best way forward here? Mathglot (talk) 17:56, 25 March 2022 (UTC)

Module:Labelled list hatnote already has complete support for extraclasses; no changes are needed. To test the CSS changes for all hatnotes, one would add .hatnote a {whitespace: nowrap;} to their personal CSS. I think that adding the same (plus appropriate whitespace) to Module:Hatnote/styles.css would likely be the best way to implement the final change. It might be useful for the sake of testing to find some hatnotes linking to pages with very long titles. {{Nihiltres |talk |edits}} 21:10, 25 March 2022 (UTC)

Thanks. I anticipated the suggestion, and was looking around for articles with long titles. I thought there was a category for very long article titles, but I can't find it now. I added that line to my common.css, but the behavior of {{Further}} at Vichy regime#Overview (or in the top example) hasn't changed for me, and still breaks at white space. Mathglot (talk) 08:45, 26 March 2022 (UTC)

My mistake: I made a typo; it should be "white-space" with a hyphen. Try again with that corrected. {{Nihiltres |talk |edits}} 19:55, 26 March 2022 (UTC)

Yes, that worked, thanks! May I request @Galobtter, Trialpears, Sdkb, Wikmoz, Primefac, and Nihiltres: that we all add this line to our common.css:

.hatnote a {white-space: nowrap;}

so that we can all monitor results for a while, and then if no problems are noticed after some time, we can change in the module to make it the default. I will look around some more for long, multi-word article titles, and if anyone can help find some examples please post them below. Thanks, Mathglot (talk) 20:53, 26 March 2022 (UTC)

• Oppose I don't see why this is necessary. There is no problem with linebreaks occurring mid-link: all browsers handle it perfectly well, and I've never come across a user who has complained because they thought that there were two separate links. I shall repeat what I have written often: you have no idea how wide my screen is, nor any of the myriad other factors that can affect the wrapping point, so please don't presume that what works for you will necessarily work for everybody. In short: let's build the encyclopedia and not mess around with low-impact aesthetics. --Redrose64 🌹 (talk) 22:23, 27 March 2022 (UTC)

Examples

So, what I'm finding in some trials, is that several, long-ish, titles within the "normal range" of title length are much improved by nowrap on white-space:

Further information: New Scotland, Regional Municipality of York, Ontario; North Vancouver, British Columbia (district municipality); and Wedgewood Park, Newfoundland and Labrador

Further information: 19th-century vice presidents of the United States, Face masks during the Coronavirus disease 2019 pandemic, and Federal Bureau of Investigation Ten Most Wanted Fugitives

Further information: Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch railway station

But the rare, extremely long titles are not improved by it. There are a few rare titles that are so long, that even just one of them wraps to two lines in a normal-width laptop screen, such as Letters Patent under the Great Seal of the United Kingdom erecting and establishing the Province of South Australia and fixing the boundaries thereof. If you put that in a "Further" link with the nowrap, it creates a horizontal bar because the window isn't wide enough for it, even if it's the only one.

I don't know if that's a deal-breaker, or not. I think for mobile, it's not a deal-breaker, because we've already established that for mobile you have to swipe right to see much shorter titles, and this would be no different, just longer. On mobile, either of these cause a horizontal scroll bar to appear:

Further information: World War II, Events preceding World War II in Europe, and Causes of World War II

Further information: Letters Patent under the Great Seal of the United Kingdom erecting and establishing the Province of South Australia and fixing the boundaries thereof, United Kingdom, and South Australia

But on the desktop, if you have the custom line in your common.css the top one will wrap between links, but not internally. That's true of the second one too, of course; it's just that that one link is so long, not wrapping internally means there is no alternative but to add a horizontal scrollbar even in desktop view (unless you have a screen wide enough to contain it) before wrapping just before the second link.

Before considering whether it's a deal-breaker for desktop or not, we should find out how unusual a pagename like that really is (a database query request will do it), and secondly, practically speaking, is anybody really even going to attempt to use template {{Further}} with a link that long? I know I wouldn't.

I think the real-life test of adding the line to common.css, and just going through our normal activities for a month or whatever will be a good test of how this would pan out in reality, especially if we can get several of us on board with this. Or maybe even request some more test-volunteers at WP:VPT perhaps? Mathglot (talk) 01:00, 27 March 2022 (UTC) updated to add Llanfair PG; by Mathglot (talk) 22:53, 29 March 2022 (UTC)

Found another long title:

Further information: The Federalist: A Collection of Essays, Written in Favour of the New Constitution, as Agreed upon by the Federal Convention, September 17, 1787; The Federalist; and Constitutional Convention (United States)

But maybe that doesn't count, because the first link is just a redirect (to the second one), and the link on this page is one of only two uses of that redirect. (Why do folks even create redirects like that?) Mathglot (talk) 02:38, 27 March 2022 (UTC)

If a title is too long that it breaks something but works for the current system then add a parameter option that will allow to manually disable the nowrap. Gonnym (talk) 10:01, 28 March 2022 (UTC)

That sounds smart; the param would basically take them back to the previous default. And if mobile turns out to be a problem, the default for mobile could be the old way. Mathglot (talk) 05:47, 31 March 2022 (UTC)

There are several comments objecting to this proposal at WP:VPR, from where this discussion was linked. Mathglot (talk) 08:55, 31 March 2022 (UTC)

Volunteer sign-up

We are seeking volunteers as low-involvement testers for the proposed change to Module:Hatnote described above. In around a month (or whatever period seems right) we'll ping you and ask for your comments, and if feedback is supportive, we'll make the change. "Volunteering" means adding the following line to your common.css, and then just going about your business as before:

.hatnote a {white-space: nowrap;} /* Test for nowrap hatnote links, per WP:VPR and Template talk:Further */

If you can help, please add your name to the list below. Hoping for a dozen volunteers, at least.

Sure, I'll make that change to my common.css, and you can ping me for feedback later, or I'll comment if I see anything worth noting.

• Volunteered. Mathglot (talk) 19:51, 27 March 2022 (UTC)
• Sure. MB 21:18, 27 March 2022 (UTC)
• Happy to do this. Thryduulf (talk) 11:06, 30 March 2022 (UTC)

No difference between See also and Further information

Hi everyone, there's no real difference between the See Also and Further Information templates is there? So we should delete the latter is it's longer and less common and redirect if possible, to See also please? Tom B (talk) 12:03, 12 December 2023 (UTC)

No, the two are not the same. "Further information" is for when there is more detail about this topic at another article, "See also" is for when there is information about a related topic that the reader might be interested in. Thryduulf (talk) 14:37, 2 January 2024 (UTC)

thanks Tom B (talk) 14:40, 2 January 2024 (UTC)

topic in Templatedata

I've attempted to add the |topic= do the templatedata documentation so that it might appear in visual editor, but it doesn't seem to be showing up. I'm not sure what I've done incorrectly, or if it just takes time to update Bejakyo (talk) 22:46, 13 October 2024 (UTC)

@Bejakyo: Did you go to Template:Further and perform a WP:PURGE? --Redrose64 🌹 (talk) 22:58, 13 October 2024 (UTC)

I had not, but it appears to be working now anyway. Seems odd but I'm not complaining. Is purge something that should normally be done following an update of templatedata, or is it only if it takes a certain amount of time to register the update on visual editor? Bejakyo (talk) 23:29, 13 October 2024 (UTC)

Visual editor looks at the current version of the main template, but the templatedata is normally in the template's documentation which is transcluded to the main template. When transcluded pages are edited, the pages that transclude those aren't updated in real time, only when they are next edited or purged. Thus, if you edit the template data, it won't show on the main template immediately, and so VE won't see it either; but a purge of the main template will force a retransclusion of displayed content. This is why the green documentation box has a [purge] link at top right, beside the [view] [edit] [history] links. --Redrose64 🌹 (talk) 08:52, 14 October 2024 (UTC)