This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Horizontal version of this vertical shortcut box {{shortcut}}
I would like a horizontal (landscape view) version of this vertical (portrait) shortcut box. What I am trying to do, and why, is explained briefly at User:LittleBenW/Template_test8. In short, the vertical shortcut box at Help:Searching would look nicer, fit in better, and take up less room if it were a horizontal shortcut box like Shortcut: H:S or H:Search
At User:LittleBenW/Template_test8, I have hacked the {{shortcut}} code to something that (while probably suboptimal) would probably do the job. However, I don't know how shortcuts work, and I'd prefer that somebody with more experience code and test this, since such a shortcut template could potentially be used on many pages in future. LittleBen (talk) 03:05, 27 April 2013 (UTC)
I've made a little modification to your template for word spacing and made you a User:LittleBenW/Template_test8/testcases page so you can see what your template does with various inputs. Technical 13 (talk) 14:24, 28 April 2013 (UTC)
I made a Lua version that does vertical or horizontal shortcut lists and added some examples to the testcases page. The main difference is it takes any number of shortcut links and doesn't display them unless they're good. If there are no good links then it displays nothing and leaves the cleanup category. Regular shortcut lists would be called like {{#invoke:Shortcut|shortcut|link 1|link 2|link 3}} and horizontal shortcut lists would be called with {{#invoke:Shortcut|hshortcut|link 1|link 2|link 3}}. — Bility (talk) 00:22, 30 April 2013 (UTC)
Added policy and left-aligned shortcut boxes. New usage would be Shortcut|vertical, Shortcut|horizontal, Shortcut|policy or Shortcut|left. — Bility (talk) 17:54, 30 April 2013 (UTC)
Spurious HTML
The {{shortcut}} template without any parameters, as happens when displyaing the template, produces a spurious
</ul>
(on my Wikipedia fork, but not on Wikipedia itself - don't know why). The offending code should be replaced with something as follows (after removing my comments).
--><small>[[Wikimergic:Shortcut|Shortcut{{#if:{{{2|}}}|s}}]]: <!-- should be pluralized also when no shortcuts (if allowed) -->
{{#if:{{{1|}}}|<ul><li> [[{{{1}}}]]</li>
{{#if:{{{2|}}}|<li> [[{{{2}}}]]</li>}}
{{#if:{{{3|}}}|<li> [[{{{3}}}]]</li>}}
{{#if:{{{4|}}}|<li> [[{{{4}}}]]</li>}}
{{#if:{{{5|}}}|<li> [[{{{5}}}]]</li>}}
</ul> <!-- this was spurious when no shortcuts -->
| none <!-- likely could be another error -->
}}</small></th></tr></table><!--
Please replace the current version with this sandbox version. The content/function change (starting from a duplicate of the current template) is here; the subsequent changes change nothing other than the code's presentation.
The key content/function change is the removal of whitespace accompanying the parameters. This, for example, releases restrictions on parameter formatting in templates that call {{Shortcut}}, such as {{Village pump page header}} (see "Third" shortcut output below):
code
{{Village pump page header
| Test
| This parameter, the second, carries text...
...that can be quite lengthy.
|First |Second |Third
}}
Again you're messing with newlines for no apparent benefit. It makes it very difficult to carry about a comparison with the sandbox diff link above. --Redrose64 (talk) 20:41, 4 December 2014 (UTC)
Incorrect – if, that is, you read the request and followed the second link ("here") provided.
This article, in the context of the comprehension of and/or reaquaintance with code, might indicate why I take trouble over ("mess with") spacings, alignments and so on.
Not done: please establish a consensus for this alteration before using the {{edit protected}} template. I also object to this pointless change. I have fully read your request, and that article you link 1) doesn't use this template, so I see no connection and 2) looks horrible as there is way too much whitespace on my screens resolutions. — {{U|Technical 13}} (e • t • c) 16:17, 8 December 2014 (UTC)
I don't understand how this change is seen as pointless. This template assumes parameters are fed to it without whitespace. An example of what happens when this doesn't occur is given above, using a template (Village pump page header) that calls/invokes/transcludes this template. The change therefore strips parameters of whitespace they may include. ("The key content/function change is the removal of whitespace accompanying the parameters.")
If by "that article" you're referring to the article Principles of grouping linked in my reponse to Redrose64, it's not meant as an example of where this template {{Shortcut}} is in use / malfunctioning / etc. It's to suggest (to Redrose64) why I try to give code layout some structure.
I don't understand what you mean by the proposed version looking "horrible ... way too much whitespace". The change made doesn't add any whitespace to what is already a relatively small box on the righthand side of the page.
The parameter whitespace fix seems a positive change. It's the "changes in the code's presentation" which seem to be generating disagreement here. Would you mind doing the former without the latter? — Martin (MSGJ · talk) 21:54, 9 December 2014 (UTC)
The former is here (yes, the same "here" linked in the intial request and again for Redrose64). It's misreading the request that has generated the smoke and mirrors, not the increase in the clarity of the code's presentation – although I suspect that's already recogniszed. Thank you for your post. Sardanaphalus (talk) 22:13, 11 December 2014 (UTC)
Then why not sandbox that change only and leave out all of the unnecessary stuff? --Redrose64 (talk) 22:52, 13 December 2014 (UTC)
Because I believe the other changes are worthwhile. Anyone with the required access is able to make that change only. Sardanaphalus (talk) 12:36, 16 December 2014 (UTC)
This request reminded me - I had previously written Module:Shortcut but forgotten about it. I've fixed it up, and changed the test cases so that they are more useful for comparing the template versus the module. The module also fixes the newline issue that Sardanaphalus had fixed. What would people think of switching this template to use the module instead? — Mr. Stradivarius♪ talk ♪ 14:12, 15 December 2014 (UTC)
Sounds like a timely step forward here; thank you for suggesting. Sardanaphalus (talk) 12:36, 16 December 2014 (UTC)
I've tried using it on WP:COI, because I've been adding images or quote boxes that take up the right-hand side. But the template is repeating all but the first shortcut. You can see it in this section, where the second shortcut is repeated, and in this one, where it repeats the second and third.
Any suggestions for how to fix this? SarahSV(talk) 05:21, 9 December 2015 (UTC)
@SlimVirgin: The template was horribly broken - among other things, it listed shortcuts 2-5 twice. This edit should have fixed it. — Mr. Stradivarius♪ talk ♪ 05:53, 9 December 2015 (UTC)
The module builds a layout table containing a single cell, a <th>. This causes an accessibility error, screen readers treat it as a data table (see WP:LTAB). Changing the <th> to a bolded <td>, and adding :attr('role', 'presentation') to the table would be a quick fix. But would a simple floating div instead of a table be more appropriate? Matt Fitzpatrick (talk) 10:16, 12 April 2016 (UTC)
It really ought to be a floated <div>...</div>. --Redrose64 (talk) 10:55, 12 April 2016 (UTC)
No visual changes, give or take a pixel. But I should explain what's changed under the hood.
<div> instead of <table>.
As there was only one cell, I guess the <th> was just for bolding the text. Replaced with "font-weight:bold".
"background:transparent" to override <th>'s style no longer needed.
role="note" and "font-size:smaller" instead of <small>. Semantically more of an aside or note than small print. Also, tidy doesn't allow a <ul> nested inside a <small> and messes with the output.
line-height and padding tweaks to minimize pixel differences.
Policy shortcut uses a table with a single header cell, and I think it should be similarly changed. I'll drop a note on its talk page. Shortcut-l uses a div already and looks mostly fine to me. Matt Fitzpatrick (talk) 04:12, 19 April 2016 (UTC)
The reason that you can't put <ul>...</ul> inside <small>...</small> is because the former is a block-level element ("flow content" in modern terminology) whereas the latter is an inline element ("phrasing content"). The proper thing to do in HTML 4 (or later) is to add a class attribute to the <ul> tag, and in the style sheet, assign the declaration font-size:smaller; to that class. --Redrose64 (talk) 19:47, 19 April 2016 (UTC)
@Redrose64: Luckily, the table already had class="shortcutbox", and I kept that in the div. If the inline styles are acceptable, should I ask an admin to move them into a .shortcutbox rule in common.css at the same time as making my sandbox edit? Matt Fitzpatrick (talk) 23:47, 26 April 2016 (UTC)
Shortcut boxes are a relatively rare occurence compared to the number of total pages. Let's leave them inline for now and wait for TemplateStyles to be deployed. -- [[User:Edokter]] {{talk}} 10:04, 27 April 2016 (UTC)
This edit request to Module:Shortcut has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Includes a margin fix from User:Edokter, thanks! This replaces the layout <table> containing a single <th> (which is an accessibility error) with a <div>. It leaves styles inline for now, per Edokter, with TemplateStyles coming soon. See also Template:Shortcut/testcases. Matt Fitzpatrick (talk) 21:10, 29 April 2016 (UTC)
Edited - typo on module link. Matt Fitzpatrick (talk) 21:13, 29 April 2016 (UTC)
Redlinked shortcuts currently populate the cleanup category Category:Wikipedia shortcut box first parameter needs fixing. I don't think this behavior is correct, because redlinked shortcuts are just like any other sort of redlink: sometimes the box is on a userspace draft of a policy that'll eventually be promoted; sometimes the box is meant to illustrate a humorous parallel with an actual shortcut. Either way, I don't think redlinks naturally "need fixing". (Pinging Mr. Stradivarius, who wrote the module.) Enterprisey (talk!) (formerly APerson) 03:12, 18 July 2016 (UTC)
@Enterprisey: This category was in the original template, and has been around since 2008. Looking at the rationale for adding it, I see that it was originally meant to be temporary. I don't mind if we take it out. Or we could make it suppressible with something like |nocat=true if that is more desirable. — Mr. Stradivarius♪ talk ♪ 03:31, 18 July 2016 (UTC)
Actually, I see that it already is suppressible with |category=no. — Mr. Stradivarius♪ talk ♪ 03:34, 18 July 2016 (UTC)
Wonderful! Great find. Thanks. Enterprisey (talk!) (formerly APerson) 03:40, 18 July 2016 (UTC)
Protected edit request on 20 August 2016
This edit request to Module:Shortcut has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
At the moment, the error category for an invalid first parameter is added if the first parameter is a valid interwiki link; apparently, mw.title.exists is false in this case. Therefore:
Since this is placed on the policy in question, the links displayed do not do anything but make your browser reload the page. I thought it'd be nice to send them directly to the page of the redirect, as that adds a little bit of use to an otherwise useless link--it makes it easier to check the history, etc. and see if it'd be alright to reappropriate the shortcut in question. Red Slash 02:48, 10 January 2014 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I guess doing this right after you've requested it in an edit request is bad timing, but I've just implemented this as a Lua module - see Module:Shortcut. This will remove the 10-shortcut limit, and will also mean that the template doesn't have to check all 10 parameters if only one or two have been specified in the template invocation. I've adjusted it to add redirect=no, though, so the net effect should be the same. :) Have a play around with it and see what you think. There should probably be some more time for people to discuss this before we make any changes to the main template, so I'm marking this request as answered for now. — Mr. Stradivarius♪ talk ♪ 06:31, 7 March 2014 (UTC)
Continued
This edit request to Module:Shortcut has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hi, could the links in the template please be "redirect-only" links? There's really no need for the links to even be there if they're just going to lead you back to the page you're already on; redirect-only links let you check out what's linking to those exact shortcuts, etc. Thanks! Red Slash 03:41, 10 April 2015 (UTC)
@Red Slash: You put this on as a request to edit Template:Shortcut, but that does pretty much nothing nowadays other than send information to Module:Shortcut for processing. You'd need a Lua specialist to amend that; but regardless, Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. --Redrose64 (talk) 10:29, 10 April 2015 (UTC)
@Red Slash: I definitely agree that the links should land on the redirect page (or otherwise should be removed), and have coded this change in Module:Shortcut/sandbox. Pppery 18:38, 23 November 2016 (UTC)
Reactivating this edit request to respond to this. User:Pppery's sandbox code seems fine to me. Note - the module itself is template protected, but the whole thing is cascade protected. — Train2104 (t • c) 21:16, 6 March 2017 (UTC)
Done — Martin (MSGJ · talk) 15:57, 8 March 2017 (UTC)
Anchor functionality proposal
We should modify this template to emit anchors for the shortcut(s), for the part after FOO:. This would make the shortcut name work in the page in #QUUX form, which seems to be desirable given the frequency with which people insert {{Anchor|QUUX}} for any given case of {{Shortcut|Wikipedia:QUUX}}, so that [[WP:Barbaz#QUUX]] works, as frequently expected to.
This would obviate the need to keep adding {{Anchor}} clutter all over the place; people actually edit-war about that stuff at highly-shortcutted pages like WP:NOT. Just get rid of the whole mess. This would need to be done in Lua, to efficiently parse out strings like "WP:", "WT:", "MOS:". — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 20:04, 12 November 2017 (UTC)
I definitely support this with the option of not anchoring coded. However, couldn't we just use: {{#invoke:String|replace|source=MOS:TEST|pattern=.*:|replace=|plain=false}} → TEST ? Nihlus 20:21, 12 November 2017 (UTC)
Why I suppose we could! — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 22:35, 14 December 2017 (UTC)
Visual redesign proposal
Hello. I see some minor problems with the standard shortcut box. It is oversized. Ideally the shortcuts should be as light and unintrusive as possible, but the current box takes much more space than needed. In some pages (Wikipedia:Talk page guidelines, for example) the shortcut boxes conflict with each other and make the page look messy. In some policy banners, the shortcut list is so long that it pushes the banner out of proportion (see WP:OR, for example). These problems have been addressed in {{policy shortcut}} and {{ombox/shortcut}}, where the line spacing is shorter, but not in {{shortcut}}. Furthermore, the bold font makes the box look heavy; a normal font weight is enough and would make the template look lighter and more unintrusive.
The top and bottom margins would be removed as well. This avoids most conflicts between boxes close to each other, and integrates the box better in the body of text. Here you can see a before and after screenshot of how it would look in Wikipedia:Talk page guidelines. This style can be also applied to {{policy shortcut}} and {{ombox/shortcut}}, creating a totally unified style across all shortcut templates. In short, the proposal entails 1) reducing the line spacing; 2) changing the font weight from bold to normal; and 3) removing top and bottom margins
Before making a formal request I would like to know, would anyone object to the proposed change? Thank you. Atón (talk) 07:30, 25 September 2017 (UTC)
Your description of the current situation is incorrect, in that it uses a <table>...</table>. In fact, it uses a <div>...</div> - for instance, at Wikipedia:No original research, the HTML that is served is basically as follows:
I've corrected the code, thanks for noticing. The number of shortcuts it's ok, I just think we could use less line spacing. Atón (talk) 21:27, 25 September 2017 (UTC)
Protected edit request on 11 October 2017
This edit request to Module:Shortcut has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please reduce the line spacing, margins, padding and font weight per Template talk:Shortcut#Proposal. Changes are the following:
line 89: ('margin', '.3em .3em .3em 1em') to ('margin', '0em 0em 0em 1em')
line 90: ('padding', '.4em .6em') to ('padding', '.3em .6em .2em .6em')
line 93: ('line-height', '2em') to ('line-height', '1.4em')
line 94: ('font-weight', 'bold') to ('font-weight', 'normal')
It would be great if the top 'shortcut' link could be underlined. In wikicode I've done it by placing it in a div block as follows: <div style="display: inline-block; border-bottom: 1px solid #aaa; line-height: 1.5em;">[[Wikipedia:Shortcut|Shortcuts]]</div>. But I don't know how to translate that into Lua code. Thank you. Atón (talk) 12:02, 11 October 2017 (UTC)
Edited sandbox. As I explained above, I would also like to request the separation line between the shortcut heading and the shortcut list, but I don't know how to do it with Lua code. I'd appreciate if someone could do that as well, or explain to me how to do it. Thank you. Atón (talk) 19:21, 11 October 2017 (UTC)
Done. Can't help you with the Lua coding but you could ask at Wikipedia talk:Lua — Martin (MSGJ · talk) 21:08, 12 October 2017 (UTC)
@Atón and MSGJ: I disagree with this change strongly. Please change it back and seek out consensus before changing again. The shortcuts are beneficial when they stand out rather than being hidden or tucked away in similar formatting to the rest of the page. Additionally, on larger monitors, this change makes it difficult to even read. Nihlus 01:46, 13 October 2017 (UTC)
I have undone the change for now. Atón has been seeking consensus on this for several weeks (see above) and is unfortunate that you did not join in earlier. — Martin (MSGJ · talk) 07:14, 13 October 2017 (UTC)
@MSGJ: Unfortunately, I had no way of knowing this conversation was ongoing until the change was processed. Nihlus 14:43, 13 October 2017 (UTC)
@Nihlus:screenshot before afterAs the screenshot shows, the proposal doesn't hide or tuck the shortcuts away. The proposal doesn't change the font size (which is larger than the font in the top and left interface menus) so it shouldn't be difficult to read even in large screens. Atón (talk) 14:36, 13 October 2017 (UTC)
@Atón: I disagree. It is more difficult to see them when they are normal rather than bold, and the spacing causes them to be squished together. It just seems like a case of WP:SLOP. Nihlus 14:43, 13 October 2017 (UTC)
@Nihlus: I agree with you on the spacing. I used the same spacing as {{ombox/shortcut}}, namely 1.4em. It can be tweaked. On the right you have a shortcut box with the same spacing and font size as {{policy shortcut}}. The spacing is slightly larger, and it looks lighter and better than the original proposal. So you are right, 1.4em is on the cramped side. I don't see however the difficulty in seeing the normal font weight—it seems perfectly visible and readable. It is not as flashy as bold all caps, but that is the point of the proposal, to make the shortcuts less heavy and intrusive, which in turns makes Wikipedia pages look cleaner and more uncluttered. Is this a bad idea? Atón (talk) 21:13, 13 October 2017 (UTC)
@Atón: Although better than your first version, I still don't like it and still think it's an unnecessary change (as I mentioned before, WP:SLOP). It's also not perfectly readable for those who have large resolution monitors as I mentioned before as well. Nihlus 20:09, 15 October 2017 (UTC)
@Nihlus: You don't like it and that you think it's unnecessary, what am I supposed to do with that? It is a legitimate tweak that adresses the issues enumerated in Template talk:Shortcut#Proposal. Regarding readability, the original proposal had a 85% font size, which conforms to Wikipedia:Manual_of_Style/Accessibility#Text. I've changed the last version above to 85% as well (it was 80%). Regarding the tucking effect you mentioned earlier, I think maintaining the current bottom margin (.3em instead of 0) will solve it. Atón (talk) 21:32, 15 October 2017 (UTC)
You're not supposed to do anything until you obtain consensus. I've already made my point that nothing should change, so I'm not going to re-argue it over and over again. Nihlus 21:41, 15 October 2017 (UTC)
Consensus is not unanimity; no single editor has veto power. Readability was the issue; the new proposal has a larger line spacing, wider margins, and conforms to all accessibility guidelines. Would anyone else object? Atón (talk) 07:54, 16 October 2017 (UTC)
Line spacing is smaller, not larger. --Redrose64 🌹 (talk) 15:51, 16 October 2017 (UTC)
I meant to say that line spacing in the new proposal -see conversation above- is larger than in the original proposal. Atón (talk) 07:10, 17 October 2017 (UTC)
Agree with spacing compression (it will actually be useful in places with shortcut boxes crowding each other), disagree with de-boldfacing (per Nihlus, above), and am neutral on the underline. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 19:53, 10 November 2017 (UTC)
After looking it over, I am fine with the compression and underline. However, I want to keep the bold. See the example to the right. Nihlus 20:02, 10 November 2017 (UTC)
SMcCandlish and Nihlus, I'm glad we can reach an agreement. I can live with the bolded shortucts. However, and I'm going to sound very nit-picky, would you object to debolding the heading? It would make the shortcuts, the truly important information, stand out more cleary. You can see how it would look in Template:Shortcut/testcases. Atón (talk) 12:04, 12 November 2017 (UTC)
I was going to suggest that myself; the underline serves the same purpose as the bold (emphasis) but is a distinct form of it, and better sets off the actual shortcuts from their label. Shown to the right. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 18:06, 12 November 2017 (UTC)
line 89: ('margin', '.3em .3em .3em 1em') to ('margin', '0em 0em 0em 1em')
line 90: ('padding', '.4em .6em') to ('padding', '.3em .6em .2em .6em')
line 93: delete line to force default line height
To format the heading, please replace line 95 with
if shortcutHeading then
shortcutList
:tag('div')
:css('display','inline-block')
:css('border-bottom','1px solid #aaa')
:css('margin-bottom', '.2em')
:css('font-weight', 'normal')
:wikitext(shortcutHeading)
end
shortcutList
To remove the colon ( : ) from the heading, no longer necessary, please delete it from Module:Shortcut/config.
Thank you. Atón (talk) 16:37, 17 November 2017 (UTC)
Done — Martin (MSGJ · talk) 00:29, 19 November 2017 (UTC)
Thank you Martin. Just one more thing, could you please also remove the colon ( : ) at the end of the 'shortcut-heading' string in Module:Shortcut/config? It has become redundant. Thanks. Atón (talk) 12:06, 19 November 2017 (UTC)
Sure — Martin (MSGJ · talk) 08:47, 20 November 2017 (UTC)
I personally find the shorter line more beautiful, but I guess it's a matter of personal taste, so I wouldn't oppose the change if others agree with it. Atón (talk) 07:39, 15 December 2017 (UTC)
I prefer the shorter line. Nihlus 23:11, 19 December 2017 (UTC)
Transwiki help
I know that this question doesn't have anything to do with the way this template works on this project, but I figured that this is the best place to ask for help. So, I wanted to use this template on Bosnian Wikipedia, so I copied over the module, its configuration and this template that it uses, but the code doesn't seem to generate properly. Take a look at the shortcut box on the right here. This is the code it generates:
Notice that the <ul> tag just opens and then immediately closes instead of opening before <span class="plainlinks"> and closing after </li>, which would get rid of the preceding bullet. Does anyone know how to fix this? – Srdjan m (talk) 09:57, 15 March 2018 (UTC)
What I can think of is that the bosnian wikipedia has switched from HTML tidy (see mw:Parsing/Replacing_Tidy) to Remex, which would produce different output in html. So it may actually be a problem that has to be fixed here too - because we're also supposed to do the switch. I believe I've Fixed it, per [1]. Same fix (or if there's slightly better way that Mr. Stradivarius knows of) should be done here Galobtter (pingó mió) 12:36, 15 March 2018 (UTC)
Oh, yeah... I completely forgot about the Remex switch. Thanks! – Srdjan m (talk) 20:31, 16 March 2018 (UTC)
@Galobtter: I noticed a similar issue here, except the <ul>...</ul> tag is missing altogether. Here's the English version for comparison. Do you mind taking a look? I think it's to do with the Side box module, which was copied from here, so it's probably going to affect this wiki as well when the Remex switch happens. – Srdjan m (talk) 13:37, 21 March 2018 (UTC)
Awesome. Thank you! :-) – Srdjan m (talk) 10:47, 30 March 2018 (UTC)
Rename to linkbox?
I am thinking to propose that this template be renamed to "linkbox". I think I have noticed over many years that some people think new shortcuts need the use of this shortcut template, whereas this template is less about shortcuts and more about WP:LINKBOXES. --SmokeyJoe (talk) 01:07, 22 June 2018 (UTC)
Inline option?
We should provide and 'inline' option for multiple shortcuts, e.g. instead of
{{Shortcut|WP:V|WP:VERIFY}}
giving
would be perfectly reasonable in many cases. @Johnuniq:, something for you? Headbomb {t · c · p · b} 08:14, 26 August 2018 (UTC)
I just added this page to my watchlist and may be able to look in a few days but not at the moment. This sounds like a job where {{hlist}} would be used, or more likely the hlist class which I have seen somewhere but know little about. Johnuniq (talk) 09:53, 26 August 2018 (UTC)
It's certainly not a high-priority option, no rush. Headbomb {t · c · p · b} 10:56, 26 August 2018 (UTC)
Why bother? If people abide by WP:2SHORTCUTS the box will not expand beyond three lines (plus the overhead of padding, border and margin). --Redrose64 🌹 (talk) 18:27, 26 August 2018 (UTC)
There are some spaces where vertical space is limited, and this would be nice to use. And many, many pages don't abide by WP:2SHORTCUTS. Headbomb {t · c · p · b} 18:39, 26 August 2018 (UTC)
Headbomb, can you provide examples where this would be beneficial? Nihlus 19:26, 26 August 2018 (UTC)
One place I was looking to use it was at WP:5P. I was trying to separate the 5P1 on its own line, but keeping two shortcuts interfere with my plans. Headbomb {t · c · p · b} 19:31, 26 August 2018 (UTC)
If redirects are at WP:RFD, WP is expanded to Wikipedia:
I don't know what causes this, but can this be dealt with? Going to @Johnuniq: since you can LUA. See e.g. the shortcut box at WP:CRAPWATCH. Headbomb {t · c · p · b} 18:10, 16 February 2019 (UTC)
The RFD has now been closed, but for a live example, see how {{Shortcut|WP:How to edit a page/HowDoesOneEditaPage}} give Wikipedia: instead of WP: in the fake shortcut on the right. Headbomb {t · c · p · b} 19:21, 16 February 2019 (UTC)
This is actually due {{No redirect}} which is called by the module (try Wikipedia:How to edit a page/HowDoesOneEditaPage); when a page is not a redirect no redirect uses Template talk:Shortcut/Archive 2 which converts the shortcut into the full namespace name. Although this should be pretty rare/temporary and it gives a visual indicator of what shortcuts are not actually a redirect.. Galobtter (pingó mió) 19:32, 16 February 2019 (UTC)
It is pretty rare, yes, but shortcuts don't render as intended, and somethings in relatively crammed spaces. I know the notice in {{JCW-Crapwatch-Warning}} was pretty uglified because of it. If we want to draw attention to RFD's shorcuts, adding a [RfD] or similar would be a clearer way of signaling that. It's even worse with talk shortcuts (e.g. WT:MED → Wikipedia talk:MED, an increase from 6 to 18 characters!).Headbomb {t · c · p · b} 19:49, 16 February 2019 (UTC)
I had a look and, as Galobtter says, the problem was that an RfD notice before #REDIRECT makes the page not a redirect. Therefore the full title is shown. Various kludges could be added to deal with that but I'm not sure the effort would be worthwhile, particularly since it would be pretty ugly in the code. Johnuniq (talk) 00:13, 17 February 2019 (UTC)
It should actually be a relatively easy fix, if I'm reading the code correctly. The expansion of {{No redirect}} (lines 39–42 of Module:Shortcut) just needs to provide a second parameter that is also the shortcut. That way, instead of expanding {{No redirect|WP:How to edit a page/HowDoesOneEditaPage}} → Wikipedia:How to edit a page/HowDoesOneEditaPage it expands {{No redirect|WP:How to edit a page/HowDoesOneEditaPage|WP:How to edit a page/HowDoesOneEditaPage}} → WP:How to edit a page/HowDoesOneEditaPage Providing the second parameter still works with pages that are redirects, e.g. {{No redirect|WP:5P|WP:5P}} → WP:5P - Evad37[talk] 01:14, 17 February 2019 (UTC)
Or the module could invoke {{replace}} or some other LUA voodoo magic to replace 'Wikipedia:/Wikipedia talk:' with 'WP:/WT:' in those cases. Headbomb {t · c · p · b} 02:37, 17 February 2019 (UTC)
Replacing magic text is what I meant by "ugly" mainly because it is good to have modules usable on other Wikipedias without a bunch of customization. However, Evad37's fix seems to be good. That involves adjusting args to read args = {shortcut, shortcut}. I just previewed that and it gives "WP:" in the sample shortcut above, although I haven't thought about any implications. Just try it, I guess. Johnuniq (talk) 03:01, 17 February 2019 (UTC)
Whatever works, not fussy on the technical implementation as long as it works. Headbomb {t · c · p · b} 03:40, 17 February 2019 (UTC)
On my Android-based mobile phone using the Wikipedia app to view Portal:Mathematics, I am seeing 20 copies of the bare wikicode {{#if:{{{1|}}}|{{#tag:span||id="{{{1|}}}"}}}} just before the "P:MAT" shortcut link. These are obviously coming from Template:Shortcut-l, which is called by Portal:Mathematics/Intro. I don't see anything wrong when looking at the portal page in mobile view on my desktop machine, nor when I look at it on my phone through a regular browser window (Google Chrome); it's only a problem when using the Wikipedia app for Android. Does anyone know why the app is not rendering the template correctly? (Figured I'd ask here, since people here are familiar with this particular template, before I try a more general forum.) I'm guessing the error was introduced in this edit by User:Hddty., but I don't know any details about how that added code works. - dcljr (talk) 19:53, 11 February 2019 (UTC)
This is a known bug. {{3x|p}}ery (talk) 23:03, 17 February 2019 (UTC)
I'm pretty sure that when I added {{Shortcut|w.wiki/QP}} to my user page, two days ago, it displayed without a link; that's what currently displays for the equivalent on my Wikidata user page. However, It now displays with a red link, as above. I can see no recent edits to the template or main module, so what (if anything) has changed?
In any case, can we change (fix) this template so we can use it with the WMF short URL service? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:09, 13 April 2019 (UTC)
Please no, the short URLs are exactly that: short URLs, not short wikilinks. They are designed to simplify access from outside sites where space is a premium, such as Twitter. --Redrose64 🌹 (talk) 19:22, 13 April 2019 (UTC)
Thank you, but I already know what short URLs are, and what they are for. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:33, 13 April 2019 (UTC)
I doubt {{Shortcut|w.wiki/QP}} has rendered without a link at the English Wikipedia for a long time, if ever. Both Template:Shortcut and wikidata:Template:Shortcut are only meant for redirects which are pages in the wiki and work when they are entered in the search box or written as a wikilink like WP:V. Your use of these templates is wrong. Wikis have different templates and the version on wikidata:User:Pigsonthewing does not make a link but it causes confusion in readers who know what the term "shortcut" means in Wikidata. As far as I know, neither the English Wikipedia nor Wikidata has a template intended to display a box with the short url produced by meta:Special:UrlShortener. I oppose adding it as a feature to Template:Shortcut. It will cause confusion if there is a parameter telling which of two different features the template should use, and there may be opposition to display a short url on any page outside userspace. We do have {{Short URL}} but it has few uses. PrimeHunter (talk) 19:22, 1 May 2019 (UTC)
Fair enough; though I see there's an interesting work-around, on Wikipedia:Five pillars. Otherwise, I have made {{Short URL box}}, as can be seen on WP:N. As for "opposition to display a short url on any page outside userspace", that would be very harmful; we need to display short URLs on pages in Wikipedia space, such as the aforesaid. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:53, 28 May 2019 (UTC)
When in a list item, Edge and IE have a sad day
Right now, this template seems to be outputting a <divclass="module-shortcutanchordiv"></div> with spans inside which take the anchors generated by the template. This causes bad behavior in IE/Edge when the shortcut template is embedded inside an li. See Wikipedia:Manual of Style/Linking#General points on linking style for an example in that browser. (It does not cause an issue in either Firefox or Chrome.)
Locally on my machine in Edge, setting the div to display none, float right, or moving the div inside the normally-displayed box makes the issue go away. I haven't tested any of those solutions on other browsers, nor have I tested what the result would be of being taken to the anchor since-generated after making that change.
Is there any preferred solution here? --Izno (talk) 23:27, 11 August 2019 (UTC)
There are four shortcut boxes in that section. Does the problem occur with all of them, or just certain ones? --Redrose64 🌹 (talk) 07:53, 12 August 2019 (UTC)
All but the first. --Izno (talk) 12:07, 12 August 2019 (UTC)
Is it definitely the <div>...</div> that Edge doesn't like? I see that before the outer div there is a <link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r886047113" /> element, which I thought was something to be used in the head, not the body. --Redrose64 🌹 (talk) 21:52, 12 August 2019 (UTC)
100% the div. The link is generally in the head but not required (in this case, being injected by TemplateStyles here). --Izno (talk) 00:45, 13 August 2019 (UTC)
The vertical list of items inside the box should be more compact (there's unnecessary vertical margins between them). Please add this to the styles (this was tested by editing the CSS generated inside the "DOM Elements" view of browsers, while the page was loaded):
This removes the vertical margins (currently there's one at the top of each item) and keeps items left-aligned (without any additional horizontal indentation margin), both are implied by default in the "li" elements.
I see no reason for separating them, even if there's a "msg" item (there's a single one, only at bottom of the list of shortcuts; sometimes this is the only item listed, which may also span several paragraphs adding their own margins!).
It'd be very nice to have a parameter for creating horizontal lists for use in rare circumstances, such as here. Would that be possible to create? {{u|Sdkb}}talk 21:41, 7 April 2020 (UTC)
They work for me in Firefox. Maybe it's a browser thing - which browser are you using (my guess is a Microsoft one)? --Redrose64 🌹 (talk) 20:44, 15 May 2020 (UTC)
Brave, Firefox and Chrome. I don't normally use Microsoft browsers, but Edge has the problem as well. GhostInTheMachine (talk) 21:24, 15 May 2020 (UTC)
Only read this post in the rendered text and not the source where I had to do things with & to render as wanted. There is significant confusion here and I'm not sure what Redrose64 is testing. The redirect at WP:RFCCLOSE works but that's not what the report is about. The claim is that Wikipedia:Requests for comment#RFCCLOSE doesn't work. But it's not supposed to work. It is Wikipedia:Requests for comment#WP:RFCCLOSE which is supposed to work. It doesn't actually work for me in Firefox. It's claimed that it produces
<spanid="WP:RFCCLOSE"></span>
I think it would work if it produced that, but it actually produces
<spanid="WP:&#82;FCCLOSE"></span>
The issue is unwanted double HTML encoding in a string contaning "RFC". The R is first encoded as R but then the whole thing is apparently encoded a second time where & is encoded as &, so we end up with the wrong WP:&#82;FCCLOSE. I don't know Lua but the problem may be in this in Module:Shortcut:
Testing shows that strings containing RFC, PMID or ISBN from mw:Help:Magic links give wrong results. When used in wikitext, {{anchorencode:}} encodes the first character in RFC, PMID or ISBN, maybe to avoid a potential clash with the magic link feature. For example, {{anchorencode:RFC}} produces RFC. This seems a bit odd but it would work so far. The problem is a second encoding by Module:Shortcut. I wrote <span id="RFC"></span> here: . This produces a working anchor for Template talk:Shortcut#RFC. But the anchor breaks after a second encoding. I wrote <span id="&#82;FC2"></span> here: . Template talk:Shortcut#RFC2 does not work. PrimeHunter (talk) 21:44, 15 May 2020 (UTC)
Thank goodness for that. I was beginning to question my sanity. Sorry about the #RFCCLOSE vs #WP:RFCCLOSE. That was my typing fail. It is getting late.
The RFC/PMID/ISBN encode magic is in safeEncodeAttribute() (in Sanitizer.php) so probably rather too deep to "fix". GhostInTheMachine (talk) 22:36, 15 May 2020 (UTC)
I don't know how much encoding attr('id', anchor) does. The example Wikipedia:Requests for comment#WP:RFCCLOSE would work if local anchor = mw.uri.anchorEncode(shortcut) was simply changed to local anchor = shortcut. But maybe it would break in other cases, or in the future if something changes. PrimeHunter (talk) 10:04, 16 May 2020 (UTC)
Heading parameter
Pppery I see you added some code for the heading parameter. What's the status on that? ‑‑Trialpears (talk) 20:15, 16 June 2020 (UTC)
It was an attempt at merging in Module:Shortcut/policy and Module:Shortcut/further per the TfD. I never got around to syncing it, partially because of a lingering feeling that the code I had written was "ugly" in some way and partially because I declared myself too involved with Wikipedia and took a break only a few days later. The code should work, and I wouldn't object to another template editor syncing it or someone making a {{edit template-protected}} request. * Pppery *it has begun... 20:56, 16 June 2020 (UTC)
Pppery, I've had a look at it and it seems to be working alright as you said. I've also had a look through the code and everything makes sense. Do you want to implement the rest of the merger or shall I? ‑‑Trialpears (talk) 21:18, 16 June 2020 (UTC)
Shortcuts to sections don't always lead to the sections
WP:RM contains a section that is identified with {{Shortcut|WP:RM#TR}}, which generates a navigation shortcut box on the right side of the page. When I click on the link in that nav box, it does not lead me to that section of WP:RM. Instead of linking to WP:RM#TR, which generates a reference to https://en.wikipedia.org/wiki/Wikipedia:RM#TR, it seems to generate a link to https://en.wikipedia.org/w/index.php?title=Wikipedia:RM&redirect=no#TR, which suppresses the redirection and does not lead to the intended destination. Once it takes me to the redirect, if I click again, the section link is missing, so I am just sent to the top of the redirect target's page instead of to the desired section. I think I have seen this happening on other pages as well – perhaps whenever a shortcut to a section leads through a redirect. What is happening? Can it be fixed? —BarrelProof (talk) 13:19, 2 September 2020 (UTC)
But clicking on one of the shortcuts inside the box isn't supposed to take you to the target of that shortcuts (you're already there). The link goes to the shortcuts itself (hence &redirect=0). – Uanfala (talk) 18:18, 2 September 2020 (UTC)
Why shouldn't clicking on a shortcut take you to the target of the shortcut? I think it should, for four reasons: 1) that is what practically everyone would definitely think is what would happen, since that is what happens when I click on any other Wikilink; 2) I have been clicking on them as a way to check whether they are linking to the correct place (e.g., to see if the shortcut was created incorrectly or leads to a stale section name), and the current behavior makes it appear that they are not linking to the correct place; 3) I have been clicking on them as a way to refresh the page while staying at the same anchor position, and this makes me click again and unexpectedly dumps me off at the top of the page instead; and 4) it is totally not obvious that section-specific shortcuts would behave differently from other shortcuts by leading to a different location than where they appear to go. —BarrelProof (talk) 19:13, 2 September 2020 (UTC)
Would be cool if there were |small=yes that would make this take up less vertical space. Sometimes we need to shortcut a one-liner in a policypage, and if it's immediately followed by a new section, that kind of looks crappy. It could use a slightly smaller font, not have the horizontal line it it, and use less top and bottom padding, maybe even lose the "Shortcuts" text (since it would be apt to be used in proximity to other shortcut boxes). Such a variant might be handy for embedding inside other things (though of course there is already the ombox version). — SMcCandlish☏¢ 😼 07:25, 29 November 2020 (UTC)
Edit request to complete TfD nomination
This edit request to Template:Shortcut has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
.svg){kind=small}
Not done: please establish a consensus for this alteration before using the 
Done Ok, the module is now up live. — Mr. Stradivarius ♪ talk ♪ 12:34, 17 December 2014 (UTC)
Done. 
Fixed it, per [1]. Same fix (or if there's slightly better way that Mr. Stradivarius knows of) should be done here Galobtter (pingó mió) 12:36, 15 March 2018 (UTC)
