Template talk:Shortcut/Archive 1

Archive 1

Archive 2

Archive 3

Use of shortcut template

I asked this question at Wikipedia talk:WP, but I thought I'd ask it here as well in case anyone is watching this page. I was just wondering if there has been any discussion on the use of this shortcut template. I see it on some of the [[WP:]] pages, but not all. Should I (or someone else) go around and stick this on every single one, or is there a reason why it's only on a few now? Thanks.  – Jrdioko (Talk) 20:00, 22 Jun 2004 (UTC)

I'm going to be bold and start adding these, since I don't see any reason why that would be a bad thing. If I'm missing something, feel free to revert.  – Jrdioko (Talk) 16:19, 23 Jun 2004 (UTC)

There should be one piece of data stored that does these things:

• Update Wikipedia:WP to include that page
• Cause "WP:(page name)" to redirect to "Wikipedia:(page name)"
• Cause "Wikipedia:(page name)" to contain the shortcut template.

There are other places where some standardisation like this would be useful too.

Brianjd 05:01, Jul 18, 2004 (UTC)

I actually did find a few instances where it seemed the template was distracting or not necessary (at least in my opinion), but other than those cases I agree that's a good idea.  – Jrdioko (Talk) 02:09, 19 Jul 2004 (UTC)

What would those instances be? I have not seen any and Wikipedia should be consistent!

Brianjd 09:10, Jul 19, 2004 (UTC)

I don't remember the specific cases now, but there were a few of the pages where it seemed to be cluttering or distracting on a certain page. For example, when new users come to the sandbox, they should be able to experiment with editing easily without being distracted by excess information. I feel that putting the template on that page would cause many of those newcomers to click on the shortcut links and perhaps get overwhelmed with information about templates and redirects that they don't understand yet. That's one of the situations where I feel it shouldn't be included.  – Jrdioko (Talk) 04:19, 20 Jul 2004 (UTC)

The Shortcut page says that this template is for Wikipedia project reference pages, but I was wondering if I can use this for normal articles as well. For example, there was a note at the beginning of the List of sets of unrelated songs with identical titles mentioning a shortcut, UrSWIT, which I replaced with the template. Chiphead 21:06, 25 October 2005 (UTC)

There have been a few edits to that page since, and the shortcut template is still there, so I'm going to assume there are no objections. Chiphead 20:08, 28 October 2005 (UTC)

Link

Why is the shortcut linked in all uses of this template? It's not very useful to have a link to a redirect that goes to the page you're already on. Goplat 01:40, 6 Sep 2004 (UTC)

I think it's useful, since most people using pages in the Wikipedia: namespace are active Wiki users, and therefore usually find it useful to be able to visit a page by its name directly. For example, I use WP:RD all the time to access Wikipedia:Reference desk. You can also use it in intra-wiki links like this (goes to the reference desk), and if you're like me and have a Firefox or Opera plugin set up for Wikipedia articles, it's handy. (I have Opera set up to replace "wiki <something>" with "http://wiki.riteme.site/wiki/<something>". :-)) splintax ^(talk) 09:43, 30 September 2005 (UTC)

Text overlapping the div box

Now that portals are becoming more common, this template is being placed within one of the portal's information boxes, usually in the introduction box. The problem that arises then is that the first line of text in the intro box will often overlap the divbox for {{Shortcut}}. I've tried a few different strategies on the trains portal, but nothing short of a much shorter first line of text in the intro box seems to work reliably. Is there a CSS guru who can sort this out? AdThanksVance. slambo 15:50, August 23, 2005 (UTC)

Tableless rewrite

This is a tableless rewrite of the current template. Source:

<div class="noprint" id="shortcut" style="border:1px solid #999; background:#fff; margin:0 0 .5em 1em; text-align:center; padding:5px; clear:right; font-size:smaller;float:right;">
'''[[Wikipedia:Shortcut|Shortcut]]''':<br />
'''{{{1}}}'''
</div>

– TTD Bark! (pawprints) 23:33:01, 2005-09-03 (UTC)

I tried using this rewrite on Portal:Trains, but the text still overlaps the box for me (Firefox on both WinXP and SuSE Linux 9.0). This code reduces the overlap, but doesn't completely solve the issue. Complicating the problem is that the box on the portal is used within another div box for the portal intro. slambo 10:57, September 8, 2005 (UTC)

Redirect link

I'm thinking that rather than having the link to the redirect page be a regular internal link, it should be an external link that removes the redirecting function (i.e. in the shortcut box for Wikipedia:Criteria for speedy deletion, rather than having the link be to WP:CSD, have it be to http://wiki.riteme.site/w/index.php?title=WP:CSD&redirect=no (so it would read: WP:CSD)). That way, if one clicks on the link, they don't automatically get redirected right back to where they started, they get to actually see the redirect, which is presumable why they clicked the link to begin with. They can, of course, click on WP:CSD and then once they're redirected click it again (where it says "Redirected from WP:CSD") and get there, but this eliminates the unnecessary interim bit. Granted, it doesn't look as nice, but I'd think it'd work better. Any thoughts? --Blackcap | talk 04:23, 19 October 2005 (UTC)

Use Wikipedia:Tools/Navigation popups? Alphax ^τεχ 16:17, 21 December 2005 (UTC)

Guideline

Please replace WP:V / Wikipedia:Verifiability by WP:SHORT / Wikipedia:Shortcut in the <noinclude>...</noinclude> part. As example WP:SHORT is as good as WP:V, additionally it offers the relevant guideline with links to related information. Omniplex 10:58, 4 March 2006 (UTC)

Done. Stifle 15:38, 7 March 2006 (UTC)

Template:Shortcut (edit discuss links history) is fine now. Omniplex  17:59, 7 March 2006 (UTC)

Request to administrators

I suggest the box read: Shortcut(s) —Markles 20:17, 14 March 2006 (UTC)

More than one shortcut is often a dubious idea, see some IMO bad examples on WP:WP, better don't encourage it. Check out Template:Editprotected(edit talk links history) for similar proposals, the admins might miss it otherwise.

Unrelated point keeping Markles' fitting header, please add...

[[Category:Wikipedia header templates]]

...near the end of Template:Shortcut(edit talk links history) in its <noinclude> section. Omniplex 18:18, 24 March 2006 (UTC)

added cat. Gflores^Talk 04:30, 29 March 2006 (UTC)

Oops, I forgot to mention category sort key ...|{{PAGENAME}}]] - not so important, thanks. -- Omniplex 13:54, 30 March 2006 (UTC)

Template:Shortcut/

TfD nomination of Template:Shortcut/

Template:Shortcut/ has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you.

Next section copied from User talk:Omniplex in conjunction with the pending TfD. -- Omniplex 10:49, 20 April 2006 (UTC)

Please stop forking

Look, I understand you're using an older OS and browser and some things don't look right to you, but forking is not the answer. Please stop forking templates (such as {{ifdef}} and {{shortcut/}}), it adds far more complexity to a system that's already accused of being too complicated. —Locke Cole • t • c 09:52, 20 April 2006 (UTC)

Even if {{Shortcut}} would be not protected I couldn't add the funtion of {{Shortcut/}} into it, they use different sizes, the latter creates an optional table cell, the former is standalone, it would be like two very different templates in one with at least two #if:. Maybe the code could share the WP:Short link, big deal.

On the other hand as they are they use no if at all, and by their name it's clear that they are related but different. I've taken exactly the CSS as developed for {{Villagepumppages}} weeks ago, nobody said that this is bad. I've added the "optional shortcut" feature to {{Villagepumppages}} as you proposed it weeks ago. I've added your new <noinclude>|</noinclude> trick.

It is exactly the look and feel as all those weeks, and nothing was wrong with that. And if you suddenly don't like it there is now one place to change it. -- Omniplex 10:16, 20 April 2006 (UTC)

There is nothing wrong with #if (or even {{qif}}), both are practically free (the resulting pages are cached, they are not evaluated every time). Ergo, there's no reason to avoid them if it cuts down on the number of templates in use (and especially if it cuts down on the number of forks). Things were fine how they were; things were even fine when I integrated {{shortcut}} directly into (for example) {{historical}}. Things stopped being fine when you forked shortcut to shortcut/ just because it wasn't visually appealing to you.

We had this same problem yesterday with {{ifdef}}, so I get the impression it's not something you plan on stopping (hence my request: please stop forking). If you think you need to fork a template, get outside opinion first, there may very well be a solution (or you may find that people don't agree with the changes you're proposing). —Locke Cole • t • c 10:26, 20 April 2006 (UTC)

It's no fork, repeating that can't make it true. It uses precisely the same number of templates (= one) as your proposal. But no if. It's so far the best solution, tune it as you like. We'll use #if: or ifndef when we really need them, which isn't the case anymore for shortcuts. -- Omniplex 10:37, 20 April 2006 (UTC)

Saying it's not also doesn't make it not a fork. Your method uses {{shortcut/}} a fork of {{shortcut}}. My method uses a pre-existing template ({{shortcut}}), your method uses a new template because you (seemingly) have an issue with how it appears. And again, there is no reason to avoid #if or {{qif}}. WP:AUM was rejected, and #if is, as I explained, basically free. —Locke Cole • t • c 10:50, 20 April 2006 (UTC)

Fix the html

The html in this box is missing the </th> currently. -The DJ 15:26, 21 April 2006 (UTC)

Edit protected request

Please add the sort key to the category by changing

[[Category:Wikipedia header templates]]

to

[[Category:Wikipedia header templates|{{PAGENAME}}]]

Done. --CBDunkerson 11:57, 28 April 2006 (UTC)

Obvious printing issue

Hi guys, I would just like to use class="noprint" for the whole table, so that one doesn't get the borders (and only them) when printing. —Gennaro Prota^•Talk 18:39, 22 May 2006 (UTC)

Yes, now after you've said it it's obvious. I've fixed it for Template:Shortcut (edit · talk · links · history) at Meta, here an admin will do it. AFAIK it's also better to start the table on line one like this:

{{{1{{{1|}}}|<table style="border: 1px solid #999; background: #fff; margin: .5em .5em .5em 1em; padding: 5px; float: right" class="noprint">
<th id="shortcut" align="center" valign="top"><small>[[Wikipedia:Shortcut|Shortcut]]:<br />{{{1|}}}</small>
</table>}}}<noinclude> etc.

-- Omniplex 20:07, 24 May 2006 (UTC)

I've made the noprint change, but not the all-on-one-line one - perhaps someone else can chime in on that... RN 08:33, 25 May 2006 (UTC)

Thanks RN. Though it doesn't hurt, class="noprint" on the th is now superflous (I meant to move that one from the table header to the whole table). Thanks again for the fix. —Gennaro Prota^•Talk 09:50, 25 May 2006 (UTC)

Interwiki

Can you please add interwiki links to:

• he:תבנית:קיצור דרך
• de:Vorlage:Shortcut
• als:Vorlage:Shortcut
• eo:Ŝablono:Mallongigo

and possibly more languages? --Amir E. Aharoni 13:02, 10 June 2006 (UTC)

• sl:Predloga:Bližnjica --Eleassar ^{my talk} 14:31, 10 June 2006 (UTC)

Done. —Ruud 00:59, 11 June 2006 (UTC)

Also hu:Sablon:Rövidítés --Tgr 11:40, 27 August 2006 (UTC)

Done. Slambo (Speak) 15:10, 27 August 2006 (UTC)

And also nl:Sjabloon:Verwijzing - Ronaldvd 15:05, 14 November 2006 (UTC)

Done. Slambo (Speak) 15:29, 14 November 2006 (UTC)

Positioning

Is there a way to position this template on the left/center of a page? If not, could an optional option be added so that, by default (option is not entered) the template appears on the right side, but if an option ("left", "center", "right") is entered, the template is positioned there? 24.126.199.129 07:36, 6 September 2006 (UTC)

Try {{shortcut-r}}. 17:02, 29 June 2007 (UTC)

'Borrowing' this template

I was thinking of importing this template to another project I work on, so I went to view the source and noticed something that I don't understand. Why is the table surrounded by → {{{1{{{1|}}}|}}} ← that mess? –Xoid 07:33, 6 December 2006 (UTC)

Anyone? –Xoid 02:41, 18 December 2006 (UTC)

Add this IW

add this pls [[mk:Шаблон:Скратенпат]] Guitardemon666

Done. Slambo (Speak) 15:41, 23 December 2006 (UTC)

Make template more convenient

Right now, this template requires its parameter, {{{1}}}, to be [[WP:WP]] for one shortcut, or the complicated [[WP:WP]]<br />[[WP:CUTS]]<br />[[WP:]] for multiple shortcuts. Would it be possible to automate this? I would not mind switching the formatting for instances of this template. The current version goes:

{{{1{{{1|}}}| <table style="border: 1px solid #999; background: #fff; margin: .3em .3em .3em 1em; padding: 3px; float: right" class="noprint"> <th id="shortcut" class="noprint" align="center" valign="top"><small>[[Wikipedia:Shortcut|Shortcut]]:<br />{{{1|}}}</small> </th></table>}}}

An intermediate version might go this way, for three shortcuts <and adding the somehow missing closing th tag:

<table style="border: 1px solid #999; background: #fff; margin: .3em .3em .3em 1em; padding: 3px; float: right" class="noprint"> <th id="shortcut" class="noprint" align="center" valign="top"><small>[[Wikipedia:Shortcut|Shortcut]]:<br />{{#ifexist:{{{1|}}}|[[{{{1}}}]]|{{{1|}}} }}{{#if:{{{2|}}}|<br />[[{{{2}}}]]}}{{#if:{{{3|}}}|<br />[[{{{3}}}]]}}</small> </th></table>

This would not affect current versions of the template. Or for four shortcuts:

<table style="border: 1px solid #999; background: #fff; margin: .3em .3em .3em 1em; padding: 3px; float: right" class="noprint"> <th id="shortcut" class="noprint" align="center" valign="top"><small>[[Wikipedia:Shortcut|Shortcut]]:<br />{{#ifexist:{{{1|}}}|[[{{{1}}}]]|{{{1|}}} }}{{#if:{{{2|}}}|<br />[[{{{2}}}]]}}{{#if:{{{3|}}}|<br />[[{{{3}}}]]}}{{#if:{{{4|}}}|<br />[[{{{4}}}]]}}</small> </th></table>

Another intermediate version below would use "redirect=no" to go to the shortcut page, rather than back to the target.

<table>style="border: 1px solid #999; background: #fff; margin: .3em .3em .3em 1em; padding: 3px; float: right" class="noprint plainlinks"> <th id="shortcut" class="noprint" align="center" valign="top"><small>[[Wikipedia:Shortcut|Shortcut]]:<br />{{#ifexist:{{{1|}}}|[{{SERVER}}{{localurl:{{{1}}}|redirect=no}} {{{1}}}]|{{{1|}}} }}{{#if:{{{2|}}}|<br />[{{SERVER}}{{localurl:{{{2}}}|redirect=no}} {{{2}}}]}}{{#if:{{{3|}}}|<br />[{{SERVER}}{{localurl:{{{3}}}|redirect=no}} {{{3}}}]}}{{#if:{{{4|}}}|<br />[{{SERVER}}{{localurl:{{{4}}}|redirect=no}} {{{4}}}]}}</small> </th></table>

And when everything is converted (if this change is supported), the following version can be implemented:

<table style="border: 1px solid #999; background: #fff; margin: .3em .3em .3em 1em; padding: 3px; float: right" class="noprint"> <th id="shortcut" class="noprint" align="center" valign="top"><small>[[Wikipedia:Shortcut|Shortcut]]:<br />{{#if:{{{1|}}}|[[{{{1}}}]]}}{{#if:{{{2|}}}|<br />[[{{{2}}}]]}}{{#if:{{{3|}}}|<br />[[{{{3}}}]]}}</small> </th></table>

And for "redirect=no":

<table style="border: 1px solid #999; background: #fff; margin: .3em .3em .3em 1em; padding: 3px; float: right" class="noprint plainlinks"> <th id="shortcut" class="noprint" align="center" valign="top"><small>[[Wikipedia:Shortcut|Shortcut]]:<br />{{#if:{{{1|}}}|[{{SERVER}}{{localurl:{{{1}}}|redirect=no}} {{{1}}}]}} {{#if:{{{2|}}}|<br />[{{SERVER}}{{localurl:{{{2}}}|redirect=no}} {{{2}}}]}}{{#if:{{{3|}}}|<br />[{{SERVER}}{{localurl:{{{3}}}|redirect=no}} {{{3}}}]}}{{#if:{{{4|}}}|<br />[{{SERVER}}{{localurl:{{{4}}}|redirect=no}} {{{4}}}]}}</small> </th></table>

{{User:Gracenotes/Sandbox|WP:SAND|WP:SB}} An example for the above one, using {{User:Gracenotes/Sandbox|WP:SAND|WP:SB}}, is to the (what else?) right. Removed to change sandbox, 15:57, 14 March 2007 (UTC)

Hopefully I haven't screwed up any code. *cough yes the source code gets complicated fast* Any thoughts about this? Gracenotes^T § 00:58, 26 February 2007 (UTC)

Hmm... I've always found it a bit silly that there's only one parameter, it seems a bit of a hack to slip in all those line breaks. One the other hand, using multiple parameters opens up two cans of worms: (1) where do we set the limit -- maybe five, for now? (2) to link the params, or not? Currently, they're all manually linked in the parameter, which means that adding hard brackets to the template will probably break every single current transclusion (easy but tedious to fix). Redirect=no seems to be another issue; I can see the rationale for that, but want to see how other people feel about it. They'll count as external links, at that point, which might be a drawback. (Even if we use plainlinks, it's still a distinct CSS class). – Luna Santin (talk) 19:34, 26 February 2007 (UTC)

The first 3 of 5 suggested modifications won't break a single thing if someone just changed the source code to them right now (because of the #ifexist ParserFunction: the page "WP:SB" exists, but the page "[[WP:SB]]" does not). Gracenotes^T § 00:43, 27 February 2007 (UTC)

Ohhh, very clever. I missed that. Will get around to implementing this, soon. Think I'll avoid the redirect=no bit, for now, but feel free to get a second opinion. – Luna Santin (talk) 01:48, 27 February 2007 (UTC)

Done. Everything seems to check out. If we do want to change the rules for {{{1}}}, it looks like we'll also need to update {{policy}} (and any other templates that might include shortcuts) to match. Haven't looked into this too far, yet. – Luna Santin (talk) 01:57, 27 February 2007 (UTC)

It's broke. The old code made it so if you didn't pass a parameter, nothing was displayed (see {{Rejected}} for an example of where this change caused issues). This new code displays an empty box if no parameter is provided. Please be more careful in the future. —Locke Cole • t • c 02:46, 28 February 2007 (UTC)

It's not broken, since Luna Santin and I implemented condition calls from header templates (that really should have been there from the beginning). I accidentally reverted myself, but self-reverted my reversion. Refreshing a page on which {{rejected}} is transcluded should help. Gracenotes^T § 14:52, 28 February 2007 (UTC)

Merging and sections

This discussion was moved here from Template talk:Policy shortcut due to that that talk page was merged into Template talk:Shortcut. But this discussion is about some policy page merge. --David Göthberg (talk) 10:13, 15 August 2008 (UTC)

Oof. If merging means that people are going to reference individual sections only, and maybe refer to the whole item occasionally, there's not that much of a point. Oh well. Gracenotes^T § 15:45, 16 March 2007 (UTC)

• Only seems to apply to two or three policies though, and WP:NOT has had this problem for ages. >Radiant< 15:51, 16 March 2007 (UTC)
  • I could not imagine someone sane disputing a policy because it doesn't say that it's a policy when they arrive at the page, although I'm sure you could come up with cases of it. In a sense, though, usage is more important than organization. Not everyone's a fan of the WP:ATT merging, but I'm not terribly against it either. WP:NOT is more of a list, of course, than a complex policy with one overarching idea that can be referenced with a wikilink merely for convenience. Gracenotes^T § 16:28, 16 March 2007 (UTC)

Add sk:

Please, add sk:. sk:Šablóna:Skratka —Zacheus ^{Talk • Contributions • Edit counter} 16:02, 15 March 2007 (UTC)

Done. —David Levy 20:57, 3 April 2007 (UTC)

color, css, id

I noticed that the color changed on talk pages, so I came to see how I could override it in my monobook.css. I found that there is no css class for this template; I propose adding class="template-shortcut" to the table. Also, it is not unreasonable to have more than one shortcut template in the same page; see WP:ENGVAR. So the 'id' in the th should be changed. Why is that an id, anyway? It's not used in common.css or monobook.css. CMummert · talk 12:49, 4 April 2007 (UTC)

I made the change. The following works:

table.Template-Shortcut { background-color: #fff !important; border-color: #aaa !important; }

CMummert · talk 13:55, 5 April 2007 (UTC)

How is orange the 'correct' talk page colour? It's awful, and I can't understand what was malfunctioning with an unobtrusive clear box? Splash - tk 21:46, 8 April 2007 (UTC)

I don't know whether it is the "correct" color; I didn't make the original change. It is true that the background color of css style 'messagebox-talk' is an orange/brown color, so the change to the shortcut template makes it match other talk page boxes. You can use css like I quote above, in your monobook.css, to either set a fixed background color or turn off the background color. CMummert · talk 22:51, 8 April 2007 (UTC)

1. I wouldn't describe it as "orange" (it looks more like a pale shade of brown to me), and please see Wikipedia:Talk page templates.

2. The original design (which remains on non-talk pages) is white, not clear. Perhaps your display is inaccurate. —David Levy 23:02, 8 April 2007 (UTC)

It's possible users thought it was clear if set their content background to always be white (like me). If I had been forced to guess, I would have guessed it was clear, not white. CMummert · talk 23:26, 8 April 2007 (UTC)

User:Splash/monobook.css doesn't appear to contain such a setting. —David Levy 23:31, 8 April 2007 (UTC)

1. It's more like the color of egg yolk.

2. Indeed, without a checkered background it's often difficult to tell the difference, but I think we know what he meant to say. The template's background has been white for almost three years. Before that, it was in fact transparent, with a blue dashed border instead of a solid grey one. —freak(talk) 10:28, Apr. 16, 2007 (UTC)

1. It doesn't resemble the color of egg yolk on any display that I've owned. It looks tan to me. It probably would be possible to tweak the settings and arrive at a shade that appears roughly as intended for both of us. (I previously did this with the "messagebox.merge" class, which was supposed to be purple but looked pink on some displays.)

2. Until recently, MediaWiki lacked the conditional syntax through which selective styling (based upon the namespace) is made possible. —David Levy 13:10, 16 April 2007 (UTC)

1. What's wrong with white?

2. What's wrong with white? —freak(talk) 15:45, Apr. 16, 2007 (UTC)

It isn't the standard talk page template color. —David Levy 22:32, 16 April 2007 (UTC)

I don't see how this relates, in the least, to the page you've referred to above. However, I posted some talk about this template on the talk page of the the talk page templates page, if that makes any sense at all, which it probably won't. —freak(talk) 10:28, Apr. 16, 2007 (UTC)

That does make sense, and I've replied to your message. —David Levy 13:10, 16 April 2007 (UTC)

My previous comment was intended neither to make sense, or solicit a response. —freak(talk) 15:45, Apr. 16, 2007 (UTC)

There's no need to be rude. —David Levy 22:32, 16 April 2007 (UTC)

Plural

{{Editprotected}}

Currently if there is only one short cut the template displays the following.

This is fine, however, if you've got more than one, here's what you get.

Notice how the word Shortcut is not pluralised. It's a minor point, though, wouldn't be hard to fix , however, of course, the page is protected. Jimp 04:24, 11 May 2007 (UTC)

The following should work.

<noinclude>{{protected template}}</noinclude><table class="noprint Template-Shortcut" style="border: 1px solid #999; background: #fff; margin: .3em .3em .3em 1em; padding: 3px; float: right"> <th class="noprint" align="center" valign="top"><small>[[Wikipedia:Shortcut|Shortcut{{#if:{{{2|}}}|s|}}]]:<br />{{#ifexist:{{{1|}}}|[[{{{1}}}]]|{{{1|}}} }}{{#if:{{{2|}}}|<br />[[{{{2}}}]]}}{{#if:{{{3|}}}|<br />[[{{{3}}}]]}}{{#if:{{{4|}}}|<br />[[{{{4}}}]]}}{{#if:{{{5|}}}|<br />[[{{{5}}}]]}}</small> </th></table><noinclude>{{/doc}}</noinclude>

I.e. stick an {{#if:{{{2|}}}|s|}} after Wikipedia:Shortcut|Shortcut. Jimp 11&14 May 2007 (UTC)

Done. Cheers. --MZMcBride 00:56, 14 May 2007 (UTC)

Thank you, much nicer. Jimp 05:21, 14 May 2007 (UTC)

I would even prefer "{{plural:{{{2|1}}}||s}}", because it seems more elegant, but functionality over elegance, perhaps :) Gracenotes^T § 04:54, 20 May 2007 (UTC)

New design proposal

I want to propose a new design for this template. It is used in ruWiki, and similar ideas are used in several other wikis, e.g. nl:.

The template code would look like this:

<includeonly>{|class="noprint" style="float:right;clear:right;margin-left:0.75em;border:1px solid #AFCFF2;font-size:smaller;" cellspacing=0
 |style="background:#F0F8FF;padding:4px;"|<imagemap>
Image:Gtk-redo-ltr.svg|17px
rect 0 0 100 100 [[Wikipedia:List of shortcuts|Shortcut]]
desc none
</imagemap>
 |style="padding:4px;vertical-align:middle;line-height:1.25em;font-weight:800;"|{{#if:{{{1|}}}|{{{1}}}}}{{#if:{{{2|}}}|<br/>{{{2}}}}}{{#if:{{{3|}}}|<br/>{{{3}}}}}{{#if:{{{4|}}}|<br/>{{{4}}}}}{{#if:{{{5|}}}|<br/>{{{5}}}}}{{#if:{{{6|}}}|<br/>{{{6}}}}}{{#if:{{{7|}}}|<br/>{{{7}}}}}{{#if:{{{8|}}}|<br/>{{{8}}}}}
 |}</includeonly>

— Kalan 09:57, 22 June 2007 (UTC)

This would be a major change; disabling the editprotected until there's consensus for something like this. Put editprotected back up if a consensus emerges, or if there's been no discussion after a reasonable length of time. --ais523 10:08, 22 June 2007 (UTC)

Thanks, I was unsure about using {{editprotected}} too. — Kalan 10:16, 22 June 2007 (UTC)

My only real objection is the text "click to view full list". Let's avoid click here syndrome. Slambo (Speak) 11:15, 22 June 2007 (UTC)

Be bold! — Kalan 12:50, 22 June 2007 (UTC)

Okay then. B-) Slambo (Speak) 13:30, 22 June 2007 (UTC)

I dislike the proposed design. It sometimes is appropriate to use an imagemap as a supplement to a text-based link, but using one as an outright replacement (and hiding the explanation of the box's nature as alt text) is a nonstandard setup that would only confuse people. —David Levy 11:36, 22 June 2007 (UTC)

It is possible to add a small question mark near the arrow. If the user is confused, he/she will be able to click this mark and read the WP:WP. — Kalan 12:50, 22 June 2007 (UTC)

The current design includes a fully visible "Shortcut" or "Shortcuts" label. What is the advantage of hiding this straightforward explanation behind a nonstandard interface? —David Levy 13:18, 22 June 2007 (UTC)

The label "Shortcut(s)" is annoying and redundant now, so I propose to make the box smaller and more accurate. If a newbie will meet it, he will move his/her mouse over the arrow (because tooltips are an informal Wikipedia standard) and get the information on it's usage. — Kalan 14:03, 22 June 2007 (UTC)

I fail to see how a straightforward explanation of the box's nature is redundant (or annoying), nor do I see how hiding this label behind an icon would make the box "more accurate." The Wikipedia standard is for images to be linked to their description pages (with the rare exceptions usually supplementing text links), so the proposed interface is unintuitive. —David Levy 14:53, 22 June 2007 (UTC)

Shortcut

WP:SHORT

Shortcut

WP:SHORT

I have to agree with David Levy on this. Although the suggested design does look very good it is less accessible. And tooltips doesn't work in several of the browsers I have tested. Ever tried to read tooltips in an older browser or on a touchscreen on a handheld? But I like the colours, it reminds me of the infoboxes we use at Meta. Check out the boxes to the right, I just played around a little. Perhaps the shortcut boxes should be brown on talk pages since that is the standard?

--David Göthberg (talk) 18:59, 12 April 2008 (UTC)

I think I have changed my mind. Let's keep the boxes plain white everywhere so they are easy to recognise.

--David Göthberg (talk) 16:35, 27 April 2008 (UTC)

Extend use from 5 shortcuts to 10

Here we have an example, 7 shortcuts and its not working because the limit is 5:

{{shortcut|WP:NOT#INFO|WP:NOT#FAQ|WP:NOT#PLOT|WP:NOT#LYRICS|WP:NOT#STATS|WP:NOT#NEWS|WP:NOT#TRIVIA}}

Please increase this to 10 shortcuts, that should be enough. --Matt57 ^{(talk•contribs)} 18:47, 28 August 2007 (UTC)

That situation calls for the {{policy shortcut}} template, which I just expanded to accommodate up to ten links. I can't think of a situation in which the standard {{shortcut}} template should require this change. (It seldom should contain more than three links.) —David Levy 19:25, 28 August 2007 (UTC)

Thanks! works now. --Matt57 ^{(talk•contribs)} 01:13, 29 August 2007 (UTC)

Hi everyone,

A recent change to Wikipedia:No climbing the Reichstag dressed as Spider-Man added a 6th link to its shortcut box.

--Kevinkor2 (talk) 11:46, 11 November 2010 (UTC)

Autolinking

Resolved.

This template currently uses #ifexist to indirectly detect whether the passed parameter is already linked, and if it is not, it links it. In the near future, the limit on the number of #ifexist calls per page will be limited to 100. Although this template only adds 1 itself, it can build up on pages that use multiple templates, all with their own calls to this template. After fixing up current usages, is there any reason to maintain this functionality and not autolink the shortcut in all cases? --- RockMFR 17:49, 8 December 2007 (UTC)

no – Gurch 12:04, 2 January 2008 (UTC)

I agree, the brackets [[ ]] for the first parameter should be deprecated and removed in the future. I took the liberty of stating in the /doc that brackets are deprecated. I started to use shortcut boxes fairly recently and I found it confusing that the different parameters could be entered in different ways.

Should we ask some bots to add that to their tasks so they fix it while they go around?

--David Göthberg (talk) 18:12, 12 April 2008 (UTC)

I have added handling of this to the new version, see below.

--David Göthberg (talk) 20:57, 16 April 2008 (UTC)

Now all pages that used brackets in the shortcut parameter have been fixes. And I have removed the #ifexist from the code of all the shortcut templates.

--David Göthberg (talk) 01:18, 11 May 2008 (UTC)

Expand param list

Resolved.

More params please!

Please add: {{#if:{{{6|}}}|<br />[[{{{6}}}]]}}{{#if:{{{7|}}}|<br />[[{{{7}}}]]}}

immediately before the </small> tag. -- Kendrick7^talk 20:34, 15 January 2008 (UTC)

Nevermind, see two sections above! -- Kendrick7^talk 21:07, 15 January 2008 (UTC)

WP:WOTTA has 8 shortcuts, so they aren't all being listed. Policy shortcut makes no sense for this article, so can the number of params be increased? (I'd also prefer if {{essay}} also got the extra params so I can stick the box in there and not worry about it!) nneonneo ^talk 02:38, 20 April 2008 (UTC)

Hahaha! I can see why Wikipedia:WTF? OMG! TMD TLA. ARG! needs so many shortcuts.

1: You should not stick that many shortcuts into the essay box since that would look very strange, so we should not increase the number of possible shortcuts in the essay box. Try sticking the current five shortcuts into that essay box and then preview the page at a screen resolution of 1024×768 or higher and you'll see what I mean.

2: Instead all those shortcuts should be shown in a separate shortcut box flowing to the right, like they are now in that essay. And in this very special case you are right, that page needs to show lots of more shortcuts. But on the other hand, the reason this shortcut box has not been extended before was that we don't want pages to show many shortcuts, we want people to choose the best 2-3 shortcuts for a page and show only them.

3: So I fixed an alternative solution for that page. I substituted the shortcut box and then hand edited it. You now can add any amount of shortcuts to that page. By the way, I checked "what links here" for that page, there are already more shortcuts to that page than the 8 currently shown. You should consider adding them too.

--David Göthberg (talk) 09:54, 20 April 2008 (UTC)

It has 16 shortcuts. I've left out "CAPITALIZEDGIBBERISH" and "CAPITALISEDGIBBERISH" because they would probably distend the box and make it take up a nice chunk of the page. Anyway, the other 14 shortcuts are on there now :P nneonneo ^talk 15:38, 20 April 2008 (UTC)

Hahahaha! I just took a look, hilarious! That ought to get the point through why we should not overuse shortcuts.

--David Göthberg (talk) 16:47, 20 April 2008 (UTC)

Suggestion: enhance {{Shortcut}} to drop anchors

Resolved.

I suggest that the following be added at the beginning of {{Shortcut}}:

{{#if:{{{1|}}}|{{Anchor|{{{1}}}}}}}{{#if:{{{2|}}}|{{Anchor|{{{2}}}}}}}{{#if:{{{3|}}}|{{Anchor|{{{3}}}}}}}{{#if:{{{4|}}}|{{Anchor|{{{4}}}}}}}{{#if:{{{5|}}}|{{Anchor|{{{5}}}}}}}

(or that equivalent functionality be implemented inside the existing conditionals). Discussion which led up to this suggestion can be seen here. -- Boracay Bill (talk) 05:22, 8 April 2008 (UTC)

Does anyone see a problem with this? Does anyone have an objection to this? -- Boracay Bill (talk) 05:17, 10 April 2008 (UTC)

I took a look at your suggestion and the pages you link to. And I ran some tests. Technically it seems to work well. The anchors this would create would look like this: "Article name#WP:SOMETHING", if a shortcut is named the usual way "WP:SOMETHING". I tested and anchors named "#WP:SOMETHING" do work. Thus the shortcut "WP:SOMETHING" should be redirected to "Article name#WP:SOMETHING", not just to "Article name". That the new anchors will have such a rather unusual look is probably a good thing, since that means they will not collide with existing anchors.

I also took a look at the {{anchor}} template. I suggest we do not use it since it would cause a lot of unnecessary code and make this widely used template dependant on the {{anchor}} template. Instead simply use <span id="{{{1|}}}"></span> or if we are lazy: <span id="{{{1|}}}" />. (To not use an end span is kind of against HTML wikimarkup, but currently MediaWiki does support it.)

So what do the rest of you in here think? Is it time to code this up in the /sandbox and test it carefully in /testcases?

--David Göthberg (talk) 17:37, 12 April 2008 (UTC)

I have added this to the new version, see below.

--David Göthberg (talk) 20:57, 16 April 2008 (UTC)

This was funny: I needed to link to this section from another talkpage, but the section name is too complex. So I added an anchor to the section title. So if anyone wants to see how anchors work, take a look at the code for the section title above. Now this section can be linked as Template talk:Shortcut#anchors.

--David Göthberg (talk) 10:18, 28 April 2008 (UTC)

   My guess is that you could have copied to clipboard the URL for the section that appears in the TOC, stripped off its head thru just before "Wikipedia talk:", and put double brackets around what was left -- without changing the page.

--Jerzy•t 10:42, 5 April 2011 (UTC)

Clear right

Is there any specific reason why this template only uses "float:right;" instead of using "clear:right; float:right;"? I had trouble making this template float correctly over at Wikipedia talk:WikiProject Cryptography until I checked the code and then had to code like this to work around it:

<div style="clear:right; float:right;">
{{shortcut|WT:CRYPT}}
</div>

I would like to add "clear:right;" to this template.

--David Göthberg (talk) 17:45, 12 April 2008 (UTC)

I have added this to the new version, see below.

--David Göthberg (talk) 20:57, 16 April 2008 (UTC)

And I removed it again some days ago. Since it caused more problems than it solved.

--David Göthberg (talk) 01:46, 27 April 2008 (UTC)

New version

Resolved.

I have created a new version of this template in its /sandbox. Also see the /testcases. I have added several of the things that have been suggested on this talkpage.

• I have not changed its visual appearance.
• I cleaned up the CSS and HTML code.
• I added a "clear:right;" so it falls below any boxes before it that uses "float:right;" such as archive boxes, instead of positioning itself to the left of them.
• I changed its class name from "Template-Shortcut" to "shortcutbox" since that is more in line with the naming used in MediaWiki:Common.css. In case we would like to move the style code for this template to MediaWiki:Common.css later on.
• I made it so that it places anchors. So if a shortcut box is placed in a section further down on a page then shortcuts can more easily be pointed to that section. Similar to how now WP:NBSP points to a subsection.
• Anchors do not work if the first parameter to the shortcut box is fed with brackets or as several bracketed links with <br> tags in between, so I made it so the template detects when a page feeds it a faulty first parameter and then lists that page in Category:Wikipedia shortcut box first parameter needs fixing. So we can easily find and fix such pages. This also means that when all such pages have been fixed, then we can remove both the old and the new "#ifexist" from the code, which will be a good thing since the MediaWiki developers have announced that they are soon going to lower the number of "ifexists" that can be used on a page.

I will wait some time for your comments and tests before I add this code to {{shortcut}} itself.

--David Göthberg (talk) 20:27, 16 April 2008 (UTC)

I went ahead and updated {{shortcut}} with the new code.

--David Göthberg (talk) 20:23, 17 April 2008 (UTC)

The "clear:right;" caused more problems than it solved. So I removed it.

The anchor span tags caused very ugly rendering with pages that feeds the shortcuts with <br> tags. So I removed the anchors, but only temporarily. When we have fixed all pages that are reported into Category:Wikipedia shortcut box first parameter needs fixing, then we can add the anchors back.

--David Göthberg (talk) 23:30, 17 April 2008 (UTC)

All pages that used brackets in the shortcut parameter have been fixed. And I have removed the old #ifexist from the code of all the shortcut templates. But I am keeping the CAT:SHORTFIX reporting for a while, just in case.

I have added the anchor functionality to all the shortcut templates. See documentation at {{shortcut}}.

--David Göthberg (talk) 01:24, 11 May 2008 (UTC)

Error

Resolved.

Something recently changed about this template that causes it to show code. "span id" and all of that jive. That a look at WP:PHILO. Pontiff Greg Bard (talk) 20:37, 17 April 2008 (UTC)

Using <br /> inside the tag causes it to do that. Many of the shortcuts need to be fixed. See CAT:SHORTFIX. nneonneo ^talk 20:54, 17 April 2008 (UTC)

I think I took care of it on my end. Thanks & be well, Pontiff Greg Bard (talk) 21:41, 17 April 2008 (UTC)

Yes, you guys are right, and the edit you did to that page fixed it. I didn't realise it would be that ugly in that case. (Never enough testing...) This makes me wonder if we should remove the anchor span tags again for some days while people are handling the CAT:SHORTFIX? Since pages that feed the parameters in that way are now reported and handled. Then we can add the anchor span tags back when all pages have been fixed.

--David Göthberg (talk) 22:25, 17 April 2008 (UTC)

More problems

Resolved.

{{Wikipedia category}} is now broken -- it can't take multiple arguments for the shortcut (see CAT:U for an example of this). nneonneo ^talk 21:31, 17 April 2008 (UTC)

I took a quick look. I'll handle that.

--David Göthberg (talk) 22:51, 17 April 2008 (UTC)

Also, do you think a similar category for catching broken shortcuts can be used for {{policy shortcut}}? nneonneo ^talk 21:41, 17 April 2008 (UTC)

Yes. But I thought we would start with this template, and when this one is done go on with {{shortcut-l}} and {{policy shortcut}}. Just to split up the workload a little if we get weird bugs. And we did get weird bugs. I knew I should have started with the lesser used {{shortcut-l}} or so, but I got bold...

--David Göthberg (talk) 22:51, 17 April 2008 (UTC)

Template:Di-no fair use rationale and Template:Di-replaceable fair use should be using the {{Template shortcut}} template, but it's fully-protected, so I can't make that change. nneonneo ^talk 23:58, 17 April 2008 (UTC)

Y Done. Ouch, that was a mess. I suppose you meant "should not be using". Oh, and thanks for helping out with this stuff! --David Göthberg (talk) 00:29, 18 April 2008 (UTC)

One more thing. Can User_talk: also be excluded from the template? nneonneo ^talk 03:24, 18 April 2008 (UTC)

I assume you mean "excluded from being reported to CAT:SHORTFIX"? And I agree, the boxes should normally not even be on such pages, so we don't want to spend work on fixing them. And I'm way ahead of you, I already excluded them from being reported. The code I added for user space exclusion "#ifeq:{{SUBJECTSPACE}}|User" means that both "User" and "User talk" are excluded. Since {{SUBJECTSPACE}} returns "User" for both spaces. (Just like {{TALKSPACE}} returns "User talk" for both spaces.) The MediaWiki devs have made a very nifty set of magic words for us to work with! The few user and user talk pages you still see at CAT:SHORTFIX is because the Wikipedia servers rebuild categories very slowly. (Its a low priority task, which seems right. My experience is that it takes about a week for a complete rebuild of a big category. I think I heard it has to do with that pages that don't get visitors don't get re-rendered in several days.)

But I think that once all the other pages are fixed we can turn on reporting of the user pages so that the users themselves see the category at the page foot informing them of the boxes needing fixing.

--David Göthberg (talk) 09:17, 18 April 2008 (UTC)

Signature removed

Resolved.

This was showing up on WP:ANI, and probably elsewhere, with a user sig. I;ve removed it and hopefully it's OK now. If it isn't, I'll get me coat. --Rodhullandemu (Talk) 21:39, 17 April 2008 (UTC)

Yes, I just noticed it too. Very very very embarrassing. I must have clicked the signature button by accident. I just showed my signature on 11,042 pages. I bet this talkpage will be flooded with questions now. Thanks for fixing it.

--David Göthberg (talk) 22:02, 17 April 2008 (UTC)

Something is still wrong with this template. Fix the code or restore the 11 March version. --Secisek (talk) 22:19, 17 April 2008 (UTC)

Secisek: Can you point to a page that has problems with this new code so we can see what it is about?

--David Göthberg (talk) 22:27, 17 April 2008 (UTC)

I've noticed as well... WP:PJ seems to hold a good example of the problem, though there are several others. -- SonicAD (talk) 22:46, 17 April 2008 (UTC)

Ignore the above, I didn't notice the above section regarding this. -- SonicAD (talk) 22:47, 17 April 2008 (UTC)

The latest revision has fixed the problem, best, -- Secisek (talk) 00:28, 18 April 2008 (UTC)

WHY ALL CAPS?

WOULDN'T IT BE SHORTER TO NOT HAVE TO KEEP SHIFT IN, OR USE CAPS LOCK???!!11 -- Jeandré, 2008-04-19t20:37z

What are you talking about...? nneonneo ^talk 21:01, 19 April 2008 (UTC)

Well, the search box to the left on Wikipedia pages is case insensitive. Try it, type in say wp:short or wt:short and press enter and see what happens. But when used in text like this it is clearer that it is a shortcut when we use WT:SHORT instead of wt:short.

--David Göthberg (talk) 21:11, 19 April 2008 (UTC)

Oh, now I see what he's referring to. Shortcuts are usually abbreviations, which customarily use upper case. There are a few exceptions here and there, but the general convention is to use upper case (besides, mixed-case shortcuts could be interpreted as being actual articles, rather than redirects) nneonneo ^talk 15:41, 20 April 2008 (UTC)

• But it's clumsy for the user to type all caps, and he or she doesn't have to. It would be better for {{Shortcut}} to show a shortcut as H:Search (for example) rather than H:SEARCH   LittleBen (talk) 03:09, 27 April 2013 (UTC)

Double-bullet problem in lists

Unresolved.

I noticed a problem with {{Shortcut}}: it does not coexist nicely with lists. For example, this wikitext:

* A list item
* Another list item
* Let's put a shortcut after this item
{{Shortcut|WP:EIW#Tools}}
** Tools
*** Some more items
*** Some more items

produces this list:

• A list item
• Another list item
• Let's put a shortcut after this item

• • Tools
    • Some more items
    • Some more items

I'm seeing two bullets to the left of the "Tools" item which has the shortcut before it. I've tried a few variations but I don't see a simple way to avoid this problem. It's coming up on the Editor's index which has long, deep lists and I'd like to stick shortcuts on some of the second-level list entries. The double-bullets aren't as bad as the shortcuts are good, so I can probably live with the ugliness, but still it would be nice if the template could slide nicely into a second-level list item. Thanks for any help. --Teratornis (talk) 21:58, 25 April 2008 (UTC)

Ah yes. The left flowing {{shortcut-l}} has problems with list dots too. I had only noticed it for the left flowing one until you pointed it out. Since you wrote I did some tests. The shortcut box already uses the most robust thing you can surround anything with, that is a HTML table. I reverted the sandbox to an old version of {{shortcut}} (prior to my changes) and tested. The old code has the same problem. And look at this:

• Let's put a thumbnail image after this item

• • Tools
    • Some more items
    • Some more items

So it is not a {{shortcut}} specific problem. So I think you have to bring it up at the Wikipedia:Village pump (technical). I bet it is a well known problem among the gurus and something the devs must fix in the MediaWiki page rendering code.

--David Göthberg (talk) 23:24, 25 April 2008 (UTC)

Thanks for checking into this. Since {{shortcut}} uses an HTML table, that means it should coexist more nicely with an HTML list. Here is another test that uses an awkward mix of wiki lists and an HTML list:

• A list item
• Another list item
• Let's put a shortcut after this item, and make the next item an HTML list

• Tools
• Some more items
• Some more items

That fixes the visible problem, but the editing cost would be high on a page like WP:EIW with its giant lists, and then other editors probably would not understand why the hack is there. I will may pose a question on WP:VPT if we don't resolve the problem here. --Teratornis (talk) 04:24, 26 April 2008 (UTC)

Possible workaround in problematic pages:

* A list item
* Another list item
* Let's put a shortcut after this item
{{Shortcut|WP:EIW#Tools}}
:* Tools
::* Some more items
::* Some more items

Producing:

• A list item
• Another list item
• Let's put a shortcut after this item

• Tools

• Some more items
• Some more items

This is top-of-the-head -- I haven't thought about it much. -- Boracay Bill (talk) 05:03, 26 April 2008 (UTC)

I tried that earlier, and I discovered that the :* character sequence doesn't indent by exactly the same amount as ** does:

• A list item
• Another list item
  • Let's put a shortcut after this sub-item

• This item's bullet should vertically align with the bullet above it, but does not

• Some more items
• Some more items

Since I generally only need to display one shortcut per sub-item that has a shortcut, I'm wondering if I can create a box that fits on just one line, using a <span ...> tag, and could go after the list entry:

• A list item
• Another list item
  • Let's put a shortcut after this sub-item
  • This sub-item wants a shortcut
    • Some more items
    • Some more items

That seems to work. Could we make a "Template:Shortcut compact" that would work on list sub-items and possibly other vertically-constrained locations? --Teratornis (talk) 17:13, 26 April 2008 (UTC)

Oh! Nice solution. And yeah sure, since there's a need for it you should not hesitate. Create the {{shortcut compact}}. And I like the name you choose for it. If you do the basic stuff that makes it work right in those lists then I'll be happy to work it over and add the extra bling bling that the others have, link from the others and add anchor dropping and so on. Actually, this will make {{shortcut compact}} the first one with anchor dropping (see other discussions above) since we first have to clear out CAT:SHORTFIX before the others can get it.

But wait, hang on a little. I just discovered another solution. Let me test it a bit more first. It seems I can fix the existing boxes. I'll report back very soon. But perhaps you want that one-liner anyway? Then you should create it anyway.

--David Göthberg (talk) 23:22, 26 April 2008 (UTC)

Yee haw! Problem solved. It was partially my fault. When I did the major work over and clean-up of the code 10 days ago I added some newlines between some tags in the code for code readability. But MediaWiki has problems with that. I have fixed the deployed box now. But note that it has to be placed on the same line as one of the dots, not on its own line since then the list resets and starts from scratch and that gives the double dots again. So look at this, this now works:

* A list item
* Another list item
** Let's put a shortcut after this sub-item {{shortcut|WP:EIW#Tools}}
** This sub-item wants a shortcut 
*** Some more items
*** Some more items

Which renders:

• A list item
• Another list item
  • Let's put a shortcut after this sub-item
  • This sub-item wants a shortcut
    • Some more items
    • Some more items

Teratornis: Thanks a bunch for discovering the bug and then making that one line SPAN variant which helped me find and fix the bug.

Now we have to document this. Note that your one liner box also has to be placed on the same line as a dot and not on its own line, otherwise it too causes double dots.

For completeness since I mentioned them above: Image thumbnail boxes seems to work correctly too as long as they are placed on the same line as a dot:

• Let's put a thumbnail image after this item

  

  • Tools
    • Some more items
    • Some more items

Now I have to test and fix the other shortcut boxes too.

--David Göthberg (talk) 00:47, 27 April 2008 (UTC)

Thanks to everyone for your excellent help at fixing this problem. I will start a {{shortcut compact}} when I get a chance, maybe tonight or tomorrow, and apply the various fixes discussed above to the shortcut entries in the Editor's index. --Teratornis (talk) 19:58, 27 April 2008 (UTC)

We later discovered more problems with this and we have not yet found a solution to it. It seems to be a deeper problem with how MediaWiki renders vertical dotted lists. It affects images and all other kinds of boxes too, no matter if they are table or div based. This needs more investigation.

--David Göthberg (talk) 13:22, 17 June 2008 (UTC)

Shortcut links

I've noticed that the links to the shortcuts when transcluding this template just link to the shortcut, meaning if you follow the link you just get redirected back to the page. Wouldn't it be more useful if you linked it using <span class="plainlinks">[{{fullurl:WP:SHORTCUT|redirect=no}} WP:SHORTCUT]</span>, which would not redirect you back but let you see the shortcut. Otherwise, there is really no point to linking it at all. — Parent5446 ^{(t n e l)} 16:48, 25 May 2008 (UTC)

Oh, nice idea. I added two hard coded example shortcut boxes to the right. The first one with the old style direct link, and the second one with your suggested "redirect=no" link.

It seems like a useful improvement, since at least I often want to take a look at the redirect page for several reasons like checking that it redirects to the right section of the page or add section linking or reach its talk page to add a corresponding talk page shortcut. And now that the shortcut templates add anchors we might have to do such checking and editing a lot. Also, it might discourage people from the current misuse of shortcut templates on (user) talk pages just to link to other pages. (Shortcut templates can of course be used to announce shortcuts like WT:SHORT to the talk page itself.)

The only drawback seems to be that we then can not verify the shortcut by just clicking it once, instead we have to load the redirect page and then click the redirect there. But that is less trouble than now when we want to reach the redirect page itself. The links will also get a slightly different colour than the "Shortcut" heading in the shortcut boxes: Shortcut: WP:SHORT. But that probably doesn't matter.

Let's think about this for some day and see what others think about it.

--David Göthberg (talk) 20:51, 25 May 2008 (UTC)

Ok, I always thought this idea, but never said anything since I kind of had this notion that this is obviously an idea that someone would have thought of already, and it hasn't been implemented due to some consensus. But I am happy to know that this change might finally make its way into the template. — Parent5446 ^{(t n e l)} 02:43, 26 May 2008 (UTC)

Oh, never assume an idea is "too simple". It is the simple ideas that are hard to discover. And even if an idea later is considered "bad" it might inspire others to come up with better ideas, so don't hesitate to share your ideas. Some of the best templates I have created here at Wikipedia and some of the best inventions I have made in my life started out with someone less knowledgeable (and thus still not brainwashed with tradition) saying "I wish we could do X", the rest saying "impossible" and then I saying "but hang on, if we do like this then we perhaps can do it or at least achieve the same goal". :))

And even bad ideas are good since we also learn from mistakes. But your current idea above seems really good.

--David Göthberg (talk) 03:26, 26 May 2008 (UTC)

Comment copied from Wikipedia:Village pump (proposals)#Shortcut template changes:

If I understand this correctly, implementing the proposal will make things a bit more difficult and confusing for non-editor WP users who click shortcuts in order to provide an occasional slight convenience for WP editors who are into the nut & bolt workings of wikinavigation. If I've got that right, the priorities seem reversed. -- Boracay Bill (talk) 03:19, 26 May 2008 (UTC)

Well, when I was a new user I found it very confusing when I clicked the links in those shortcut boxes and just was sent back to the same page I just came from, without any explanation what-so-ever. So back then I decided to just disregard those boxes since I didn't understand what they were for. So for me it would not have meant any difference.

But you have a point. It is sad that the explanation that {{R from shortcut}} supplies on the shortcut redirect pages only gets visible when editing those redirect pages. I don't think there is a way to show an explanation on the redirect pages without changing the MediaWiki software. But we can do like we did with the CAT:SHORTFIX, create a category with a long name that works as a visible explanation. It worked fairly well for CAT:SHORTFIX, lots of people clicked the category name at the bottom of the pages to learn more. Another option is to extend the text in the shortcut box itself. Instead of as now just "Shortcuts:" why not something like the example box you see to the right?

--David Göthberg (talk) 03:59, 26 May 2008 (UTC)

I seem to be following you around, David... Looks like a very good idea, though.

@Boracay Bill: are you sure you've got the right idea about what this will actually change? It's not the case that when I type [[WP:SHORT]] and you click on the bluelink WP:SHORT that's produced, you'll go to the redirect page - that would indeed be silly. Instead it's simply saying that clicking on one of the bluelinked shortcuts in the box produced by {{shortcut}} shouldn't return you to where you started. Happy‑melon 17:19, 27 May 2008 (UTC)

I proposed this a year or so tandem with the change of the parameter format, which was implemented ([[WP:A]]<br/>[[WP:B]] eventually changing to WP:A|WP:B). This still has my full support :) Gracenotes^T § 17:34, 27 May 2008 (UTC)

After thinking about this for some time: I have doubts. I have noticed that people fairly often add shortcut boxes but forget to create the shortcut itself. If we use "redirect=no" links then we won't get red links even if the shortcut doesn't exist. Thus people will not notice that they forgot to create the shortcut.

Technically we can fix this by using an {{#ifexist:}} statement in the code for each link, checking if the shortcut exists, and if it doesn't exist then show a red link. (Then without extra cost we can also automatically list such pages at Category:Wikipedia shortcut box first parameter needs fixing.) This means 5 "ifexists" for each shortcut box. Some pages use more than 20 boxes. It has been announced that MediaWiki are going to have a limit of tops 100 ifexists per page. (Currently the limit is 500. See meta:Help:ParserFunctions##ifexist:. The reason for the limits is that ifexists are heavy on the database.) But I read up on it and ran some tests. Only the ifexists that are really used counts. Most pages that have many shortcut boxes have only one link in each box and thus they will only break if we have more than about 100 boxes.

So I think I can get the new way to work exactly as I would like it, but it will be pretty messy code. I need to think more about this and do some more tests.

--David Göthberg (talk) 11:17, 11 July 2008 (UTC)

I now have even more doubts about this. If we use external links like this then (as far as I know) the links doesn't become visible in the "What links here" list for the shortcut pages. This means that the shortcuts will seem orphaned. And my experience is that it then is likely that some trigger happy admins will delete the shortcuts.

--David Göthberg (talk) 17:41, 2 August 2008 (UTC)

Does not recognise shortcuts containing "="

Greetings. I recently created a shortcut to WikiProject Objectivism at WP:A=A, and it seems to work fine when linked to, but does not show up using this template: {{Shortcut|WP:A=A}}.

I wonder is this necessarily so, or can it be fixed? Thank you for your attention, Skomorokh 22:02, 18 June 2008 (UTC)

Workaround: Use {{shortcut|1=WP:A=A}}. This is required because the "=" is being recognized as defining the template parameter "WP:A" with value "A" (if it's not the first parameter, use |2= or |3= as appropriate).

nneonneo ^talk 00:56, 19 June 2008 (UTC)

Muchas gracias, Skomorokh 01:33, 19 June 2008 (UTC)

Table

{{editprotected}}

Please replace the page with the contents of {{Shortcut/sandbox}} (and don't forget to remove the comments around the protection warning and documentation). There is no reason this should use a table, it works very well with just a div. Thanks. —Ms2ger (talk) 13:12, 7 July 2008 (UTC)

I disagree. Yes in this case the div seems to work fairly well, although I think you did get too tight padding with the div. Experience here at Wikipedia has showed that tables are much more robust and causes much less problems.

I have ran tests together with the local association for the blind here in my city and they have no problem with tables. Tables are really only an accessibility problem when the table cells are meant to be read in another order than they come in the code. Like, when a table is meant to be read in column order instead of in row order. Here is an example of a table that gets read in the wrong order in a screen reader:

First	Third
Second	Fourth

While this table gets read fine in a screen reader:

First	Second
Third	Fourth

--David Göthberg (talk) 14:15, 7 July 2008 (UTC)

Colours

Until recently the {{shortcut}} templates used white background and grey border in all namespaces, even on talk pages (first example box to the right). Some days ago David Levy made it so the {{shortcut}} boxes became brown when on talk pages (third box on the right) and light grey when on other pages (second box on the right). --David Göthberg (talk) 18:14, 7 August 2008 (UTC)

The following part of this discussion was copied from User talk:David Levy#Template:Shortcut and User talk:RockMFR#Template:Shortcut. --David Göthberg (talk) 18:14, 7 August 2008 (UTC)

I've reverted your change to Template:Shortcut. This wasn't discussed anywhere and the exact same change has already been reverted by a different person before. --- RockMFR 21:59, 23 July 2008 (UTC)

On the contrary, this was discussed on the relevant guideline's talk page (where the editor in question initiated the thread). I waited a while for additional feedback, and it never arrived (and at some point, I forgot about the issue). The discussion has remained open for a year and three months without anyone countering my argument.

Given that my edit reflects a guideline (which Freakofnurture erroneously believed applied only to 85%-width banners), the onus is on others to justify an exception. I invite you to do so (and I, of course, will refrain from reverting in the meantime). —David Levy 07:00, 24 July 2008 (UTC)

I see what you mean by having all talk pages have the same color so users know what templates can be used there, but I don't think many people are actually going to see this connection intuitively. Also, why is the color for the other namespaces being changed? --- RockMFR 18:41, 24 July 2008 (UTC)

The talk page template color coding (and later the similar standardization of other namespaces' templates) has been surprisingly effective; as time has gone by, the rate of misuse has sharply decreased.

For the other namespaces, I switched from white to our standard light grey. The only past objection to this that I recall is that the white background looks better when shortcuts are listed within header tags (because of the contrast), so I replaced all such transclusions with a dedicated (white) version of the shortcut box. —David Levy 02:23, 25 July 2008 (UTC)

End of part copied from the talk pages of David Levy and RockMFR. (Some sentences not relevant to this discussion was not copied here.) --David Göthberg (talk) 18:14, 7 August 2008 (UTC)

I agree with RockMFR and disagree with David Levy on this. I have two reasons for this:

1: Sure most talk page templates should be brown. But this template goes on all kinds of pages. Having the same white colour for the shortcut box everywhere makes it easier to recognise. It is usually a very small box and when it is brown it kinds of drowns among the other larger brown boxes on talk pages. So I think I prefer to have it white everywhere.

2: Also, making this template change colours based on page type makes this template unnecessarily complex. You even had to make an extra dedicated white box {{Ombox/Shortcut}} to use inside the light grey "other pages message boxes" such as the {{Guideline}} box. We now have too many different shortcut boxes, it is starting to get hard to keep them all updated and working the same. Well if we move the styles for the shortcut boxes to MediaWiki:Common.css then we could use some (pretty nasty) CSS magic to fix most of that, but I don't think the styles for this template should be moved there since this template is not enough widely used.

--David Göthberg (talk) 18:37, 7 August 2008 (UTC)

0. Given the fact that RockMFR stopped replying, I assume that he no longer objects to the change (though he might want to clarify his position).

1. The box is clearly labeled, so I don't see why anyone would experience difficulty recognizing it. I disagree that it's drowned out by other templates, and to me, the white version screamed out "I'm a nonstandard color! I clash! I don't belong here!".

2. The code that I inserted is very simple, and it's quite a stretch to say that "we now have too many different shortcut boxes, it is starting to get hard to keep them all updated and working the same." We have two of this type, along with the ability to make them look different. There's no need for any nasty CSS hack, as any required update can easily be copied to the other template in a matter of seconds. —David Levy 19:09, 7 August 2008 (UTC)

0: I find it strange to assume that someone has changed their mind and agree with you just because they have not replied.

2: Well, we now have {{shortcut}}, {{shortcut-l}}, {{ombox/Shortcut}}, {{shortcut compact}}, {{policy shortcut}} and {{template shortcut}}. That's six templates. That you weren't even aware of the other templates and failed to apply your change to them just goes to show the problem. And please don't change those before we have had comments from more users.

--David Göthberg (talk) 20:02, 7 August 2008 (UTC)

0. I invited RockMFR to justify deviation from the guideline (and promised to refrain from reverting in the meantime), and a discussion followed. RockMFR appeared to express partial agreement with my logic, and he asked a question (which I answered). I then patiently waited 13 days for him to raise any remaining concerns/objections, and he didn't (despite actively editing). If I explain a rationale to someone and that individual makes no attempt to counter it (after already appearing to have been somewhat swayed by my argument), why should I not interpret that as assent?

2. I was familiar with all of those templates except {{shortcut-l}} (and I created {{policy shortcut}}, in fact). I was careful to state that we have two shortcut templates of this type (new emphasis). I didn't "fail" to change the others; I intentionally changed only the main one. —David Levy 23:01, 7 August 2008 (UTC)

This seems to be a matter of personal preference, as the standardization argument doesn't seem persuasive to me. By my count, there are three people against the change and one person for it. --- RockMFR 21:10, 7 August 2008 (UTC)

Unfortunately, no one is willing to comment until after the change has been made (as evidenced by the lack of response for well over a year). It would have been nice if you'd allowed more than one person to opine before reverting (as David Göthberg seemed willing to do). I mean, we're talking about a simple color change to a template that doesn't even appear in articles. Would it really have been a big deal to have left it in place for a week or so to gauge the community's response? You cited "no consensus to change," but it's impossible to establish consensus when only four people have commented (including one who did so well over a year ago, based on a clear misunderstanding of a guideline).

I'd be interested in an explanation of why "the standardization argument doesn't seem persuasive to [you]." Do you dispute the applicability of the guideline in question. If so, why? —David Levy 23:01, 7 August 2008 (UTC)

Yes, the reason I did not revert your edit was that I thought we could perhaps leave your brown version on-line for 1-2 weeks to perhaps get some reactions. But I can't blame RockMFR for reverting. Another option is that we announce this at the Village Pump to get some more opinions.

I think we have to be careful when applying the Wikipedia:Talk page templates guideline since it wasn't designed with all the different kinds of boxes in mind. The guideline only shows two kinds of message boxes in its examples, the full sized one and the medium sized right aligned "small message boxes". Although I admit I am planning to change (or rather to try to achieve a consensus to change) the archive boxes to talk page brown, since I think they don't need to stand out from the other talk page boxes.

--David Göthberg (talk) 00:04, 8 August 2008 (UTC)

The purpose of establishing a talk page color scheme was to clarify which template belong (and don't belong) on talk pages. Common examples were given (and I don't think that it was common to place shortcut boxes on talk pages yet), but the idea always was to apply the standard to all types of talk page template. I'm certainly not arguing that that the guideline (or any guideline) should be applied blindly, but I regard it as the default condition (in the absence of a strong rationale for an exception). —David Levy 00:43, 8 August 2008 (UTC)

Well, when we standardised the different mboxes (ambox, imbox, cmbox and so on) that reason was just the third reason. The first reason was to make the different templates on a page look good together, the second reason was to help indicate what kind of page you are looking at. I think that the white shortcut boxes do look good together with the other boxes and that such a small box shouldn't have to help out in telling which page you are looking on, thus I feel that reason 1 and 2 are handled. And since {{shortcut}} is used on several different kinds of pages your reason doesn't even apply to it, since it has no fixed type of page to be on and thus can not have a single page colour. After all, you had to make it automatically adapt to the different kinds of pages.

--David Göthberg (talk) 01:51, 8 August 2008 (UTC)

In this case, the idea is that someone can observe the template in use and know that it belongs in that namespace (not necessarily to the exclusion of other namespaces). Someone familiar with the guideline who sees a white template on a talk page could reasonably believe that such transclusion is improper. Meanwhile, someone unfamiliar with the guideline might be led to believe that it's appropriate to use other non-tan templates on talk pages.

In case you overlooked it, please see my reply in the Alternative proposal, continued subsection.  :-) —David Levy 02:52, 8 August 2008 (UTC)

I am well aware of that argument. However me and RockMFR have already listed a number of arguments against using talk page brown for the shortcut boxes. There are good arguments both for and against both sides, thus this is a matter of personal taste, not a matter of logic. So this protracted discussion is a waste of time. See my response below for what more you can do.

--David Göthberg (talk) 05:02, 11 August 2008 (UTC)

Alternative proposal

Is there an objection specifically to the change from white to the standard shade of grey? It would be nice to at least do that for now.
Also, how do the two of you feel about the possible compromise of using the de facto standard secondary talk page color (example displayed below)? I believe that this addresses David's concern that the other shade caused the shortcut box to be drowned out by larger templates. —David Levy 23:01, 7 August 2008 (UTC)

---

Example heading

Example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...example text...

---

Alternative proposal, continued

I think we agree on that the shortcut boxes need to be white when inside an {{ombox}}. (Like at the top of a guideline page.) And that is one of the more common usage cases for shortcut boxes. And when shown on "Wikipedia:" pages but outside the omboxes then I think the shortcut boxes still perhaps need to be white, since they are small and need something to stand out a bit more. Also, I would like to have the shortcut boxes have the same colour everywhere to make them easy to recognise, thus white to match those used inside omboxes.

I don't like the beige colour in the example above, I find it ugly and distracting. I rather have the shortcut box be normal talk page brown, but I of course even more prefer it white.

--David Göthberg (talk) 23:52, 7 August 2008 (UTC)

Okay, let's forget about the beige color.

Do you really think that the shortcut box (clearly labeled "Shortcut" or "Shortcuts") becomes difficult to recognize simply because it's a different color?

Can we at least make the standalone version (not {{Ombox/Shortcut}}) the standard light grey shade (in all namespaces)? With this minor adjustment, it would match the tables of content (including those appearing on talk pages) and ombox tags. At the moment, it doesn't match anything, and that makes it seem out of place (especially on talk pages). —David Levy 00:43, 8 August 2008 (UTC)

If you look at Wikipedia:Template messages/Talk namespace#Discussion thread tags you will see that all the small talk page boxes there use some kind of white. The grey you suggest for {{shortcut}} simply doesn't look good for small boxes.

You can never convince me and RockMFR no matter how long we discuss this, since this is a matter of personal taste, not a matter of logic. So this protracted discussion is a waste of time.

If you really want to go on with this, then I suggest you announce this discussion at the Village pumps and similar places to draw in more users. Then you can find out what the majority of users prefer, your style or the old style. If you achieve a consensus for your new style, then we should of course change to it.

--David Göthberg (talk) 04:52, 11 August 2008 (UTC)

Anchors

This discussion was moved here from Template talk:Policy shortcut due to that that talk page was merged into this talk page. I edited the text slightly to make it clear which template is talked about. --David Göthberg (talk) 10:28, 15 August 2008 (UTC)

{{Shortcut}} was recently modified to drop anchors. Unless there is a good reason not to, could someone please make the same change to {{Policy shortcut}}? The inconsistency is confusing. -- Boracay Bill (talk) 23:35, 13 August 2008 (UTC)

I did add the anchor dropping functionality to {{policy shortcut}} at the same time as I added it to {{shortcut}}. Especially since {{policy shortcut}} probably will use it more. I just checked and the functionality is still there. The doc page says: "This template works in the same way as the {{shortcut}} template, see full documentation there."

To make it clearer I have now added a section title "Usage, examples and anchors" above that sentence to indicate that the {{policy shortcut}} template has anchors and where you can read about it. I don't know if I can make it much clearer without copying the whole documentation to that template, but that would make it harder to keep the documentation updated.

--David Göthberg (talk) 03:07, 14 August 2008 (UTC)

Ah! shortcut-generated anchors are not working as I expected they would, and that prompted the above. I had expected that e.g. "WP:V#SELFPUB" would work (see the discussion here, which led up to the suggestion on the {{Shortcut}} talk page). Rather, as implemented, it is necessary to utter "WP:V#WP:SELFPUB". I think I must have been focused elsewhere during the implementation and missed that difference at that time. My bad. -- Boracay Bill (talk) 21:54, 14 August 2008 (UTC)

Well, you are both right and wrong. Yes, the shortcut anchors use the full shortcut name, such as "#WP:SELFPUB", since in template programming we can not cut apart the string "WP:SELFPUB". But you should not combine that anchor with another shortcut like you did with "WP:V#WP:SELFPUB", since that would create a double redirect. Instead WP:V = Wikipedia:Verifiability, and WP:SELFPUB = Wikipedia:SELFPUB, and the redirect placed on the Wikipedia:SELFPUB page should be:

#REDIRECT [[Wikipedia:Verifiability#WP:SELFPUB]] {{R from shortcut}}

Not:

#REDIRECT [[WP:V#WP:SELFPUB]] {{R from shortcut}}

Of course, redirecting to the section title is in a way better since it means the web browser will scroll to a position right before the title, instead of a position right before the shortcut box. Thus this redirect placed on the Wikipedia:SELFPUB page is also a good choice:

#REDIRECT [[Wikipedia:Verifiability#Self-published and questionable sources about themselves]] {{R from shortcut}}

Only drawback is that section titles might change and then such a redirect will have the wrong anchor name and thus only redirect to the top of the page. So I don't know which is the best choice. But at least now when we have the anchor functionality in the shortcut boxes we have the choice. Tricky stuff this.

--David Göthberg (talk) 23:52, 14 August 2008 (UTC)

Point taken regarding double redirects. However, I think that we are still communicating incompletely with one another. What I had in mind was shortcut anchors which would be useful in human-to-human communications such as talk page discussions - example: "see Wikipedia:Verifiability#SELFPUB", which is clear but does not work as I would hope. Instead, it is necessary to utter "see Wikipedia:Verifiability#WP:SELFPUB", which does work but lacks clarity in human-to-human communications. In order for this to work as I had hoped, as I understand it, it would be necessary to

1. alter the pages with shortcuts and policy shortcuts to remove the "WP:" portion of the shortcut names.
2. alter the redirects similarly to change redirects like

#REDIRECT [[Wikipedia:Verifiability#WP:SELFPUB]]

to read

#REDIRECT [[Wikipedia:Verifiability#SELFPUB]]

(removing the "WP:" from the target anchor ID). -- Boracay Bill (talk) 02:03, 15 August 2008 (UTC)

Ah, now I see what you mean. Yeah, that would be neat. But the problem is that the {{shortcut}} boxes need the full shortcut as parameter. Since they can not simply tack on "WP:" since there are also shortcuts with other prefixes such as "WT:" , "MOS:", "CAT:" and so on. (See Wikipedia:Shortcut#List of prefixes.) And MediaWiki has no parser function that can help us pick apart a string like "WP:SELFPUB" after we have fed it to the template.

The only "solution" I see is to change what parameters the {{shortcut}} boxes should take to something like {{shortcut|WP|SELFPUB|WP|NEXTONE}}. But that would make them messy to use and would take a huge effort to change all existing usage. So I don't think we should do that. We need to think about this for a while.

--David Göthberg (talk) 04:49, 15 August 2008 (UTC)

Perhaps I still misunderstand. I don't see the problem. As examples, let's posit some article names in various namespaces, and some shortcuts and section names which may or may not currently exist (some do, some don't, some do and do not currently correlate as shown here but could):

No.	Article	Section name	Description	Shortcut at section
1a.	Wikipedia:Verifiability WP:Verifiability	Self-published and questionable sources about themselves	Wikipedia verification policy re self-published sources	{{policy shortcut|SELFPUB}}
1b.	Wikipedia:Reliable sources WP:Reliable sources	Self-published sources	Wikipedia style guidelines regarding reliability issues with self-published sources	{{shortcut|SELFPUB}}
2.	Portal:Publishing	Self-publishing	A section about self publishing in the main page of the Publishing portal	{{shortcut|SELFPUB}}
3a.	Template:Citation	Self-published sources	A section in the {{citation}} template documentation sub-page describing how to use {{Citation}} to cite a self-published source	{{shortcut|SELFPUB}}
3b.	Template:Infobox publisher	Self-published	A section in the {{infobox publisher}} documentation sub-page describing how to use that infobox for a self-published source	{{shortcut|SELFPUB}}

Articles named SELFPUB may or may not exist in the Wikipedia or Template namespaces on Wikipedia, or on the Publishing portal. If WP:SELFPUB, for example, exists, it might be a redirect to an anchor ID in an article in the Wikipedia namespace, using #REDIRECT ''Article name''#''Article header'' or using #REDIRECT ''Article name''#''Shortcut name'' (either should work. I would probably target anchor ID #SELFPUB for a redirect from an article named SELFPUB). Alternatively, WP:SELFPUB might be a disambiguation page, disambiguating between shortcut targets named SELFPUB in separate articles in the Wikipedia namespace.

In talk page discussions, "See WP:SELFPUB" would be wikispeak for "See the Wikipedia policy or guideline on self published sources."; "See WP:Verifiability#SELFPUB" for "See the Wikipedia verifiability policy page section on self published sources."; "See WP:Reliable sources#SELFPUB" for "See the Wikipedia reliability policy page section on self published sources. Also, "see WP:RS#SELFPUB" would work if there were such a shortcut in place, I think, even though it would be a double-redirect from its utterance as a talk page comment (I see that "see WP:V#WP:SELFPUB works with the shortcuts currently in place, but I wouldn't use that in a talk page comment because it fails the easy-to-read test). -- Boracay Bill (talk) 07:59, 15 August 2008 (UTC)

Sure, you can have the anchor "#SELFPUB" in a million different pages, no problem. But the problem is the shortcut boxes. See the two example boxes to the right. They are actual real world examples. The first box has two shortcuts to Wikipedia:Manual of Style#Quotations, and the other box has the shortcut to the talk page of the same page.

When we feed a shortcut name as parameter to the shortcut box then it needs to know if that shortcut begins with "WP:", "WT:", "MOS:" or something else, since it needs to show the whole shortcut so we humans can see it in the box. So we can not just feed "QUOTE" to the box, we must feed "MOS:QUOTE". The problem is then that the code inside the shortcut box can not pick the address apart and create a "#QUOTE" anchor, since Wikipedia template programming has no function to split strings like that. So all we can do is to make the shortcut box automatically place the anchor "#MOS:QUOTE". If you want the anchor "#QUOTE" then you must edit the page by hand and add that anchor, the shortcut box can not do it for you. Like this:

{{anchor|MOSQUOTE|QUOTE}}
{{shortcut|WP:MOSQUOTE|MOS:QUOTE}}

But the point of the anchor functionality in the shortcut boxes was to make it so all shortcut names we place on pages automatically at least have the full shortcut names as working anchors. Thus making it easy to make redirects (shortcuts) to those sections in the pages. If you want the human readable variants without the "WP:" or similar beginning then you have to hand add them to the pages as I just showed you above.

So your example above with {{shortcut|SELFPUB}} just doesn't work, since it will display a link to "SELFPUB". And that is not a shortcut, that is an article name in the main space. The box can not know if you meant "WP:SELFPUB", "WT:SELFPUB", "CAT:SELFPUB" or something else. Remember, the primary purpose of the shortcut boxes is to show the full shortcut name on the page (or on a section) so we humans can learn it. And the shortcut WP:MOSQUOTE is not supposed to be combined with something else when you use it. It should be typed exactly as "WP:MOSQUOTE" when you type it in the Wikipedia search box, even though it redirects to a section in the Wikipedia:Manual of Style.

--David Göthberg (talk) 09:15, 15 August 2008 (UTC)

David, Can you tell me where the actual real world example shortcut boxes mentioned above came from? I would like to see the context. Thanks. -- Boracay Bill (talk) 11:58, 15 August 2008 (UTC)

Ehm, they are shortcut boxes with shortcut links in them. Just click the shortcut links in those boxes and that will take you to the pages that use those shortcuts. And there you will see the boxes in actual use on those pages.

Please don't be offended, but I think I have to say this, since it is better to know that one doesn't understand than to be even more confused: I have been thinking that you probably have not understood the purpose of shortcut boxes and how they are used. That you asked this question shows that it is so.

And you know, it wasn't until I had used Wikipedia for some years that I figured out how shortcuts and shortcut boxes worked and how they were supposed to be used. And I have seen many users that use shortcuts and the shortcut boxes in the wrong way. So this is tricky stuff for many of us.

I recommend that you go read Wikipedia:Shortcut. Read all of it, read it carefully and read it again some days later.

--David Göthberg (talk) 21:27, 15 August 2008 (UTC)

Additional parameters

{{editprotected}}

Could we double the number of shortcuts? Ideally there would be no limit but MediaWiki doesn't have a way to handle unlimited arguments (at least that I'm aware of). :P I can provide code to double the number if an admin will add it. The page which needs this added functionality is Wikipedia:Administrators' noticeboard/3RRHeader. —Locke Cole • t • c 22:10, 25 November 2008 (UTC)

N Not done - As the documentation for this template says:

"The point of these templates is not to list every single redirect (indeed, that's what Special:Whatlinkshere is for); for any given page, instead they should list only one or two common and easily-remembered redirects."

Since the more shortcuts you show, the more different shortcuts people will use when they link to the page from talk page discussions and from other pages. And that makes it less likely that other people will recognise the shortcuts when used. Thus showing more shortcuts will just add confusion. Thus we on purpose only support tops five links in the {{shortcut}} template.

This has been discussed several times on several of the shortcut related talk pages. (Sorry, I don't have the time to look up and link to the old discussions, I really am supposed to be on a wikibreak since I am very busy in real life.) And this reason is not my idea, it was discussed around these pages long before I got involved in the shortcut templates. But I agree with the old conclusion that this template should not support more links.

--David Göthberg (talk) 19:39, 26 November 2008 (UTC)

Links

Is there any reason why this template links the shortcuts? By definition the links can only lead back to the same place (at least they ought to), so they serve no purpose.--Kotniski (talk) 08:42, 8 January 2009 (UTC)

The operative phrase is "at least they ought to." The links make it very convenient to verify that the shortcuts lead where they're supposed to (which isn't always the case).

They also serve as demonstrations for users who are unfamiliar with the concept of Wikipedia shortcuts. ("It leads me back to this page. Oh, I see.") —David Levy 09:20, 8 January 2009 (UTC)

OK, makes sense.--Kotniski (talk) 10:13, 8 January 2009 (UTC)

Merge

If there's no objection, I've created a merged version of {{Shortcut-l}}, {{Policy shortcut}} and {{Shortcut}} at {{User:Locke Cole/Template:Shortcut}} which I'd like to replace this template with. It also adds an additional Guideline shortcut option, as well as standardizing on ten shortcut links as the maximum. You can see the shortcut in use at User:Locke Cole/Sandbox, and you are welcome to edit that page to perform any tests on its functionality. —Locke Cole • t • c 18:52, 12 February 2009 (UTC)

Two other things: 1) Here's a diff of the changes, and 2) if someone does decide to do this, can a history merge be performed to maintain the history changes? I don't mind if my userspace version is deleted once the changes are made. —Locke Cole • t • c 19:18, 12 February 2009 (UTC)

1: I took a quick look and it looks good. I'll try to take a closer look within the next few hours or so.

2: I agree with merging these templates and instead use a "type=" parameter.

3: And I like the addition of the name "Guideline shortcut:". That's a new one, isn't it? But it does make the box a bit too wide so I myself would simply use "Shortcut:" on guideline pages. We should try and see how it looks with a line break between "Guideline" and "shortcut:".

4: But I am hesitant about increasing the number of shortcut links it accepts. Why do we even need 10 links in policy shortcuts? The cases I have seen when people "needed" many links were always just silly.

5: What histories do you want merged and why? Wouldn't it be enough with a proper edit comment what is being added and who coded it, something like "Updating to handle all shortcut boxes' functionality here. Coded by User:Locke Cole. See talk page."

--David Göthberg (talk) 20:42, 12 February 2009 (UTC)

Thanks for your comments David. To answer your questions as numbered: 3) Yes, Guideline is a new one, I felt it made sense to add it while doing this update since it seems like a logical extension. It also allowed for the use of #switch so additional options can be added as/if needed without a lot of effort recoding it. 4) Since people seem to request increasing the limit semi-frequently (at least twice on this page I believe) it seems increasing it wouldn't cause any harm. If we wanted to we could add code to categorize pages into Category:Pages with too many shortcut links (or some such) so we can see about trimming them (we'd just need to agree on how many is too many). 5) The page history from User:Locke Cole/Template:Shortcut (everything except the first diff, which is identical to the last diff here). I'm a neat freak, and it makes more sense to merge to me since no edits have been made since I started work on that userspace subpage version. —Locke Cole • t • c 20:52, 12 February 2009 (UTC)

3: Right "Guideline shortcuts:" is a very logical extension, since shortcuts are used on guideline pages the same way as on policy pages where we use "Policy shortcuts:". But as I said, without a line break it is too wide. I hope it is not too ugly with a line break...

4: Gah! So I have to explain this again:

4.1: Most of the requests to increase the number of possible shortcuts in {{shortcut}} have come from people who don't use the box as a shortcut box, but instead use it as a navbox on for instance their own user page to link to many other pages. We have no reason to accommodate such totally erroneous usage.

4.2: But yes, some requests have come from people who actually use the shortcut box to display all available shortcuts to the same page the shortcut box is placed on. Which is close to the intended usage. The difference is that we really should not display all available shortcuts to a page, instead we should only display the 1-3 best ones. (Some pages even have 20 shortcuts to the page top! That is, non-anchor/non-section shortcuts.) Since people are lazy and use shortcuts in talk page discussions. If we display all shortcuts to a page that means different persons will choose a different shortcut name to use to the same page, thus we won't have a chance to recognise what page is meant when we see all the different shortcut names in talk page discussions. Thus we always will have to resort to click on the links to see where they lead. (Which is very time consuming for users with slow connections or slow computers.) Thus displaying all available shortcuts to a page is harmful and decreases their usefulness a lot. <humour>But hey, that is an evil plan. Let's make the shortcut box support 20 shortcuts! Then let's fill the boxes on all policy and guideline pages with 20 links. Then wait and see how usage scatters, until people finally realise it is better to write out full names of links in discussions.</humour>

Note, I haven't come up with reason 4.2 myself, I learnt it from older users. But my experience has shown that that reason still holds.

5: Well, merging histories is a somewhat complicated operation. I for one have never even performed a history merge. And it looks pretty strange in the logs, thus making it hard to figure out what happened. So I think it would be more confusing. And it fills up the history with more edits than simply adding it all with one single edit.

--David Göthberg (talk) 00:18, 13 February 2009 (UTC)

3) I would have no objection to placing a linebreak after "Guideline" if you think it would improve the layout.

4.1) I wasn't aware of this, but you're correct, that wouldn't be a legitimate reason to increase the number of shortcuts supported.

4.2) I have two concerns here; one is compatibility: {{Policy shortcut}} supports 10 shortcuts. I don't know which pages use 10, so maybe we should look at that. See {{User:Locke Cole/Template:Policy shortcut}} for my proposed meta template. The other concern I have is that we shouldn't be dictating how this template is used, it should be decided on each project page. Having said that, since that seems to be the major roadblock to getting this implemented quickly, I would be happy to reduce it back down to the 6 (which is what it is now). I would however like to add code to detect attempts at > 6 shortcuts and categorize them so we can investigate pages and trim as appropriate. What do you think of this?

5) I'm no expert (I've ran MediaWiki on my local IIS setup for whatever that's worth), but I think when you undelete an article you can specify a target, you would delete my userspace version and then undelete it over this template. Truthfully I wish history merges were used more often in situations like this. :P But this isn't necessary, if you'd like to do a copy/paste merge you can do that as well.

If you'd like me to make any of the changes above myself, let me know, or you can do it if you feel comfortable with it. =) —Locke Cole • t • c 01:12, 14 February 2009 (UTC)

I oppose increasing the number of accepted shortcuts (for the reasons cited by David Göthberg). It's rarely advisable to list more than three (at most), let alone ten. —David Levy 01:23, 13 February 2009 (UTC)

See my response to 4.2 above for why I think this is advisable, as well as my proposed alternative (specifically categorizing pages with > 6 shortcuts so we can find and trim excessive usage). —Locke Cole • t • c 01:12, 14 February 2009 (UTC)

Discussion kind of died here, should I add {{editprotected}}? =) —Locke Cole • t • c 23:28, 19 February 2009 (UTC)

6: Sorry to have left you hanging like that, but I have been busy elsewhere. (And I thought we should wait some day for more comments. But there doesn't seem to come more comments.)

3: Have you had time to try how "Guideline shortcut" looks with a line break? I haven't had time to try it yet. I am afraid it might look too ugly, but without the line break it is too wide. So I think we have to see both alternatives to decide which is the least bad one.

4.2: Minor detail: {{shortcut}} accepts 5 links, not 6 links.

4.2: And reporting? Yes, that is a very good idea. I even think we should add the reporting first, and wait with the merge. That is, add the code that reports when more than 5 links are fed, to both {{shortcut}} and {{policy shortcut}}. So we can take a look what cases there are out there. So we can learn more about this. I think that we will then see that even {{policy shortcut}} doesn't really need to have more than 5 links, instead of the 10 it currently can handle. But you never know, investigations like this have sometimes shown I was wrong. We should use a hidden category so most editors won't see (not be disturbed by) the reporting category.

--David Göthberg (talk) 00:31, 20 February 2009 (UTC)

6) Not a problem. 4.2) Agree with 5 links then, sorry for being off. ;) 4.2) By all means add the code for reporting so we can take a look at instances with more than 5 shortcuts. =) {{policy shortcut}} is the one that supports ten currently, but you may wish to add the code to this one as well (so we can see if there are any attempts at > 5 shortcuts). —Locke Cole • t • c 00:34, 26 February 2009 (UTC)

3) I've updated my userspace template with the <br /> for the Guideline usage. See User:Locke Cole/Sandbox for an example. I think it looks uglier on two lines, but I also don't care enough either way to argue about it. =) —Locke Cole • t • c 00:37, 26 February 2009 (UTC)

4.2: Will do, perhaps in a couple of days or so. (I am currently about 5 days behind on my watchlist and 2 months behind on my to-do list.) Any one else is of course welcome to do that addition, but we are not many that are used to code that kind of category error reporting. And right, we should add it to all these shortcut boxes to see what's out there.

3: Ouch, that was not only ugly, it was confusing to have the "Guideline shortcuts" text on two lines. But thanks for testing it. So my suggestion sucked. :) Ah well, I guess we have to accept that it becomes a bit wide and use your version with one line.

--David Göthberg (talk) 12:32, 27 February 2009 (UTC)

Ping

Is this good to go? Chris Cunningham (not at work) - talk 15:31, 6 May 2009 (UTC)

Unless there's still objections over standardizing the number of shortcut links allowed, I don't see a problem. Certainly this is a wiki, if there is a problem we can fix it (or revert it, but I'd hope for fixing it being the preference here). —Locke Cole • t • c 15:34, 6 May 2009 (UTC)

New simpler link for shortcut

I've just created Help:Shortcut, could we link to that from 'shortcut'. This template appears all over the place, and may be one of the first clicks a new user has ( and don't want to bring them into policy etc. before their time). Thought I'd write a simpler intro to it - as advanced editors know what a shortcut is and are unlikely to be using this link (I have included 'further info' linking to current destination for those who require this ), cheers. Lee∴V (talk • contribs) 03:43, 16 November 2009 (UTC)

p.s. fell free to edit if I have missed any useful bits... Lee∴V (talk • contribs) 03:44, 16 November 2009 (UTC)

People are currently working to merge Help and Wikipedia pages on the same subject. Since pages tend to grow and in the end both pages contain pretty much the same information. We already have the Wikipedia:Shortcut page. But your test is a good introduction for beginners, so I suggest you merge that text into the lead of Wikipedia:Shortcut. And that page already has the "How to use a Wikipedia shortcut" section which is aimed at readers.

--David Göthberg (talk) 23:35, 22 December 2009 (UTC)

Positioning

If there is a lot of content after the shortcut template where is it placed on a page, then the header is pushed above the top of the window and cannot be immediately read. A lot of editors are fixing this issue by redirecting to the header title and not the shortcut title. This resolves the issue, but if someone changes the header, then the link is lost. Some also place the shortcut above the header— again this fixes the problem, but makes editing a bit confusing.

For an example of the issue, try the shortcut at short2. The shortcut template is placed below the header, which causes the header to be placed above the window.

I created a sandbox version of the template where the anchor id is placed in a div above the box that is positioned up enough to show the header. Check it with short1. ---— Gadget850 (Ed) ^talk 15:19, 16 July 2010 (UTC)

Sorry, I don't understand the problem here. Do you have a simpler test cases which demonstrates the current problem? Chris Cunningham (not at work) - talk 12:38, 17 July 2010 (UTC)

Actually, I can't find a live example that shows the problem, as they have all been "fixed":

• WP:NEWREF— redirects to the header, not the id generated by {{shortcut}}
• WP:REFNAME— added to the end of the previous section; includes the comment "placed above the header so that the header shows when the shortcut is used"
• There is another that I lost that uses {{shortcut}} in the body, but the the redirect goes to an {{anchor}} in the header that duplicates the id

---— Gadget850 (Ed) ^talk 13:34, 17 July 2010 (UTC)

Ah, I get you. An example would be the different results you get from Wikipedia:Manual of Style (footnotes)#Newline after closing ref tag and Wikipedia:Manual of Style (footnotes)#WP:NEWREF. Not sure this is fixable, to be honest; the shortcut box is a different element from the section header, after all. Chris Cunningham (not at work) - talk 19:48, 17 July 2010 (UTC)

If my change is adopted, then those fixes need can be reverted, but leaving them as is should not do any harm. See the difference between the default behavior through short2 and the sandbox version through short1. ---— Gadget850 (Ed) ^talk 21:17, 17 July 2010 (UTC)

Aha! Yes, I see the improvement. One consideration is accessibility (does a hidden div interfere with that?), while another is different skins (the relative shift may need to be different). Thoughts? Chris Cunningham (not at work) - talk 17:11, 18 July 2010 (UTC)

I can't see that this would have any accessibility issues— the change moved the HTML id, which is not readable. I ran through all the skins— in Classic, it moves down an extra line, in all others it is the same move. I don't see that as a problem. ---— Gadget850 (Ed) ^talk 19:00, 18 July 2010 (UTC)

Okay: can't see any remaining issues. Chris Cunningham (not at work) - talk 19:26, 18 July 2010 (UTC)

Done —-— Gadget850 (Ed) ^talk 15:38, 26 July 2010 (UTC)

Expand from 10 shortcuts to 15

I just went to append WP:NOTTWITTER to what Wikipedia is not. Please could the list be extended to more than ten entries! —Sladen (talk) 16:19, 2 October 2010 (UTC)

Technical question

Due to some recent merges, I've redirected WP:JARGON and WP:Explain jargon to WP:MOS#Technical language (see the discussion at the bottom of Wikipedia talk:Explain jargon). I'd like to see {{shortcut}} used at WP:MOS#Technical language, but I'm not sure how this will interact with the redirects. (I'm not very familiar with how shortcuts are implemented technically.) What's the best way to proceed? ---- CharlesGillingham (talk) 18:20, 3 November 2010 (UTC)

• At WP:MOS#Technical language, add {{shortcut|WP:JARGON|WP:Explain jargon}}, then change WP:JARGON to #REDIRECT [[WP:MOS#WP:JARGON]]. ---— Gadget850 (Ed) ^talk 05:51, 5 November 2010 (UTC)

Plainlist

Please sync from Template:Shortcut/sandbox, where I've created an accessible version, using HTML list markup, styled with no bullets. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:03, 17 January 2012 (UTC)

Done. Killiondude (talk) 05:48, 21 January 2012 (UTC)

Changing wiki-markup to pure HTML in lists

I was trying to make a proper nested HTML list at Wikipedia:Categorization of people#Other exceptions for accessibility reasons, but it wouldn't work. Instead of producing a list of nine items with a nested list of five items, it produced a list of seven items, a second list of 5 items (the examples of particles in names), then a further list of two items (the final two items of the main list of exceptions). I discovered that this template was causing the problem, and I also discovered using my sandbox that changing the "*"'s to HTML markup ("<ul>" and "<li>") made the list nest correctly, hence my change to Template:Shortcut. Let me know if my edit has caused any problems. Is there any particular reason why changing the list markup from wiki-markup to HTML fixed the problem? Graham87 07:56, 9 May 2012 (UTC)

Sorry for the long reply, but this is best explained with examples. Consider this simplified example:

{{Shortcut|WP:TEST}}
* Item 1
* Item 2
** Item 2a
** Item 2b
* Item 3

Before your edit, expanding the template would produce wikitext something like this:

<table><tr><th><small>[[Wikipedia:Shortcut|Shortcut]]:

* [[WP:TEST]]</small></th></tr></table>
* Item 1
* Item 2
** Item 2a
** Item 2b
* Item 3

Note how the shortcut list (with embedded HTML) and the following content list look like part of one big wikitext list. And this is exactly how the parser sees it; the wikitext winds up as HTML something like this:

<table><tr><th><small><a href="/wiki/Wikipedia:Shortcut">Shortcut</a>:

<ul><li> <a href="/wiki/WP:TEST">WP:TEST</a></small></th></tr></table>
</li><li> Item 1
</li><li> Item 2
<ul><li> Item 2a
</li><li> Item 2b
</li></ul>
</li><li> Item 3
</li></ul>

Note how there is one big list combining both the shortcut and the content lists, and the end of the table is in the middle of one of the list items! I don't know how a browser might handle this tag soup, but HTML Tidy (used by Wikimedia wikis to clean up the parser's HTML output) winds up breaking the list and sublists up as you observed.

After your edit, the wikitext after expanding the template looks like this instead:

<table><tr><th><small>[[Wikipedia:Shortcut|Shortcut]]:

<ul><li> [[WP:TEST]]</li></ul></small></th></tr></table>
* Item 1
* Item 2
** Item 2a
** Item 2b
* Item 3

Note there is no more "one big wikitext list" to confuse things. When the parser processes the wikitext list, it winds up entirely outside the table so there is no tag soup to break things.

Another fix would have been to insert a linebreak before the </small></th></tr></table> within the template, which would have created wikitext after expanding templates something like this:

<table><tr><th><small>[[Wikipedia:Shortcut|Shortcut]]:

* [[WP:TEST]]
</small></th></tr></table>
* Item 1
* Item 2
** Item 2a
** Item 2b
* Item 3

Here, the non-list line clearly separates the two lists, so the parser outputs them as two separate lists (one inside and one outside the table) and again there is no tag soup. I can think of no technical reason to prefer one fix over the other, so we may as well keep yours. Anomie⚔ 17:02, 9 May 2012 (UTC)

Thanks very much, that makes it much clearer now! Graham87 03:35, 10 May 2012 (UTC)

parameters

Should we allow more parameters?Curb Chain (talk) 18:07, 9 May 2012 (UTC)

No, I think 5 is enough. — Martin (MSGJ · talk) 20:34, 25 June 2012 (UTC)

Use anchorencode:

This template should use {{anchorencode:}} so if someone uses weird characters, invalid XHTML isn't generated. Replace each of the five id="{{{n|}}}" with id="{{anchorencode:{{{n|}}}}}". ··gracefool☺ 23:33, 23 June 2012 (UTC)

 Done — Martin (MSGJ · talk) 20:33, 25 June 2012 (UTCsamp