Template talk:Shortcut

A little help

Would somebody mind helping me fix the short cut at WP:CITE#Citations in explanatory footnotes? I changed the title of the header, and that seems to have broken it. The name of the shortcut is WP:EXPLNOTESECT.---- CharlesTGillingham (talk) 16:03, 1 July 2026 (UTC)

@CharlesTGillingham: Done, like this. --Redrose64 🌹 (talk) 11:45, 2 July 2026 (UTC)

Thanks. I learned how shortcuts work today! --- CharlesTGillingham (talk) 13:57, 2 July 2026 (UTC)

ER nowrap

This can't possibly be controversial so I'll open an edit request. The module should wrap each shortcut in a nowrap span for cases like Special:PermanentLink/1366587294, where 1 short shortcut uses 2 lines instead of 1, see sandbox.

Line 63:	Line 63:
end	end
end	end
	-- Wrap each shortcut in a nowrap span for shortcuts like [[WP:CFORK/I]] in [[Special:PermanentLink/1366587294]]
	listItems[i] = string.format('<span class="nowrap">%s</span>', listItems[i])
end	end
table.insert(listItems, options.msg)	table.insert(listItems, options.msg)

FaviFake (talk) 19:27, 3 August 2026 (UTC)

Found another error caused by this, see the banner at the top of Wikipedia:Speedy deletion/Overturned speedy deletions FaviFake (talk) 23:11, 2 September 2026 (UTC)

 Done Hopefully nobody uses some insanely long-short-cuts ;) Nux (talk) 14:56, 20 September 2026 (UTC)

Formatting section links?

Should we format section links added with this template (e.g. {{shortcut}}) so that it uses a section symbol (§) like {{Section link}}? It seems like this is more-or-less the correct way to format these (see MOS:SECTLINK, which sort of applies here), and I think it could look nicer. Axolitl (talk | contribs) 23:10, 23 October 2026 (UTC)

Nope. if you copy and paste WP:DRV § NOT it's going to look like this: WP:DRV § NOT. These templates are for easy copying. FaviFake (talk) 09:36, 24 October 2026 (UTC)

Shortcut links with hash broken

Tracked in Phabricator
Task T443177
Invalid

The doc has an example using a hash (URI fragment): MOS:MATH#TONE. While the wikilink scrolls to the section, the shortcut link does not. It stops at the redirect page and presents a link without the fragment. I noticed this at Wikipedia:Image use policy. Jroberson108 (talk) 05:24, 1 November 2026 (UTC)

If you mean that clicking the shortcut inside the box headed "Shortcuts" takes you to the redirect page, that is the design behaviour. --Redrose64 🌹 (talk) 09:48, 1 November 2026 (UTC)

Ok, it's intentional. Seem like adding the fragment to the link that appears on the redirect page might be more clear? Jroberson108 (talk) 10:04, 1 November 2026 (UTC)

It won't necessarily always be the same fragment. Consider Wikipedia:Signatures#Links, which has five shortcut boxes containing a total of six shortcuts - all but one of these begin with WP:SIG# (such as WP:SIG#DLWP:SIG#DL), so for those five only one actual redirect page is involved. There are other shortcuts in other sections on the same page that also lead to that redirect. For these, the fragment is handled by your browser. Redirect pages only include the fragment if that is the only place that could be reached through that redirect, as with WP:SIGLINKWP:SIGLINK. --Redrose64 🌹 (talk) 10:32, 1 November 2026 (UTC)

I wasn't saying update the redirect link in the source, but append it to the displayed redirect, maybe only when redirect=no and one isn'talready in the redirect. That way it mimics what it actually does when a fragment is present. Jroberson108 (talk) 17:42, 1 November 2026 (UTC)

So what you're asking for is that when you reach a redirect page via e.g. MOS:MATH#TONEMOS:MATH#TONE the redirect page should be different from the redirect page that is reached via MOS:MATHMOS:MATH? Similarly for WP:IUP#COPYRIGHTWP:IUP#COPYRIGHT vs WP:IUPWP:IUP and WP:SIG#DLWP:SIG#DL vs WP:SIGWP:SIG? Basically, that the redirect page should be able to detect the link by which it was reached, and change its appearance accordingly? That's nothing that we can do, you would need to file a feature request at phab: - see WP:BUGS. --Redrose64 🌹 (talk) 20:51, 1 November 2026 (UTC)

The fragment is still in the URI, so I figure the change wouldn't be too difficult. Wasn't sure how that page was handled. I may have to check phab to see if anyone already requested. Thanks. Jroberson108 (talk) 00:46, 2 November 2026 (UTC)

See phab:T443177. Jroberson108 (talk) 03:14, 2 November 2026 (UTC)

I've added this to a new "Issues" section. Pbab bug was closed as invalid. If the template maintainers want to pursue this further, they can take the next steps or restrict fragment usage to the redirect. Jroberson108 (talk) 15:33, 2 November 2026 (UTC)

It's not an issue with this template, nor even with shortcuts in general; it's just the way that all redirects work. You might as well say that there's an issue with Module talk:Shortcut/sandbox/styles.css#Shortcut links with hash brokenModule talk:Shortcut/sandbox/styles.css#Shortcut links with hash broken. --Redrose64 🌹 (talk) 19:16, 2 November 2026 (UTC)

Redirects work the way they should with caching, per that phab. This template works the way it should. Issue is with usage. Adding the fragment to the shortcut instead of the redirect to avoid adding a redirect per section works unless you follow the shortcut self-link to "redirect=no". Hence the issue note. If you are saying you don't like the "Issues" label, then maybe something like "Notes" or something else could work. Feel free to soften the label. Jroberson108 (talk) 20:03, 2 November 2026 (UTC)

Seems like the primary purpose of those self-links is to edit the redirect. Editing those instances would break it for the entire group of hashed shortcuts. A simple change that might work is unlink shortcut values containing a hash. The primary shortcut without a hash is usually at the top. Also, I sometimes use them to check to see if the link works, which I had to fix one the other day. Initially, these hash ones not working was confusing. Jroberson108 (talk) 20:36, 2 November 2026 (UTC)

Links in the shortcuts box should work normally

It was decided in 2017 at Template talk:Shortcut/Archive 2#Direct link that the text "MOS:MATH#TONE" in the "Shortcuts" box at MOS:MATH#TONE should not actually follow the shortcut like in this sentence but should stay on the redirect page with https://en.wikipedia.org/w/index.php?title=MOS:MATH&redirect=no#TONE. I don't think that was a good idea. It makes it harder to test whether the shortcut works by going to where you already are (especially when there is an anchor like #TONE), and the different behaviour can easily mislead editors to think it doesn't work. I guess there are few users who actually want to go to the redirect page, and many who want to test the shortcut before they post it somewhere. The benefit of going slightly easier to the redirect page is not worth the potential for confusion. The above section shows an example of confusion caused by the current behaviour which has also annoyed me many times. PrimeHunter (talk) 00:22, 3 November 2026 (UTC)