Template talk:Further

message: 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)
replies: text: Redirect for Template:See changed. -- AlexTW 06:10, 9 December 2017 (UTC)
thread_title:  Fix [[Template:See]] redirections 

message: I'm sure I've seen that this is not permitted, but an experienced editor has been inserting .  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)
replies: text: , 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)
replies: text: 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)
thread_title:  Should pages in draft be used in hatnotes 

message: 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  template. In a single wikilink, one could do that like this: , or to protect just the 'II' at the end, one could even do: Causes of World , 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)  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  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)
replies: text: 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)

text: 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)

text: Ping . Mathglot (talk) 06:26, 21 March 2022 (UTC)

text: And Primefac. Mathglot (talk) 06:32, 21 March 2022 (UTC)
replies: text: 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.  16:34, 21 March 2022 (UTC)
replies: text: 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)
replies: text: 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)
replies: text:  , 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.  (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)
replies: text: 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.  21:10, 25 March 2022 (UTC)
replies: text:  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  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)
replies: text: My mistake: I made a typo; it should be "white-space" with a hyphen. Try again with that corrected.  19:55, 26 March 2022 (UTC)

text: .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)

text: 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)
replies: text:  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)

text: .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)
thread_title:  Adding nowrap 

message: 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:
 
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:
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  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)
replies: text: 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)
replies: text:  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)
thread_title:  Examples 

message: 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)
thread_title:  Volunteer sign-up 

message: 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)
replies: text: 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)
replies: text: thanks Tom B (talk) 14:40, 2 January 2024 (UTC)
thread_title:  No difference between See also and Further information