Wikipedia talk:Shortcut/Archive 2

Archive 1 Archive 2 Archive 3

Shortcuts distinguished by capitalization only?

Does this policy say anything about shortcuts differing only by case that redirect to different pages?

For example:

I understand that separate articles can capitalize the same name differently. But for shortcuts, particularly those that cannot be meaningfully distinguished by case only, this practice seems to create unnecessary confusion. —Cheng  04:04, 2 April 2011 (UTC)

New Prefix

I propose that the prefix "WX:" be used in shortcuts to any article/talk/category/portal/subpage/userpage/project pertaining to weather. such as: WX:TC (Tropical Cyclone), WX:TCPORTAL (Tropical Cyclone Portal), WX:DCATE (DCATE list in my user subpage), WX:TCPROJECT (WikiProject Tropical cyclones), WX:TS (Thunderstorm), WX:TOR (tornado), WX:WS (Winter Storm), etc. — Preceding unsigned comment added by Bowser423 (talkcontribs) 22:29, 16 July 2011 (UTC)

I don't think topical shortcuts would be setting a good precedent. Won't be long before every wikiproject/portal/user's favorite subject demands their own prefix. -- œ 12:23, 4 August 2011 (UTC)

Semi-protection of shortcuts

Today, I fixed some vandalism on the shortcut WP:UPIMAGE. It has been in a vandalised state since May 27, a full two months of undiscovered vandalism on a shortcut. I'm sure for very popular shortcuts, that would be noticed and fixed. I've suggested at RfPP that WP:UPIMAGE be given indefinite semi-protection even though WP:SC shortcuts aren't really covered specially by protection policy.

It seems like shortcuts should probably be semi-protected for a handful of reasons:

  1. They don't contain encyclopedic content that needs editing. Full or Semi PP are kept to a minimum in article space to enable IP editors to contribute to articles and also to help develop consensus on policy, but once, say, the redirect to an obscure essay is put in place, the need to change it is minimal.
  2. Lack of watchlisting: there are probably a couple dozen shortcuts that very active Wikipedia users point to every day (in AfD, talk pages, user talk, whatever) but how many of us are actually watching shortcut redirect pages? I'm guessing not that many. (I'd tell you but MZMcBride's Watcher tool isn't working and I can't seem to figure out how to get that data out of Toolserver.)
  3. Potential disruption: how many of us actually go and check frequently that redirects we use go where we want them to go?
  4. Potential confusion for newbies: if a newbie gets a warning message or a potentially bitey warning containing pipelinks to shortcuts, and they click on them and it goes to vandalism, that's a confusing and crap experience for them. It would be quite nice if that didn't happen.
  5. Permanence: the nature of these kinds of shortcut redirects is that they aren't going to suddenly develop into a full article or policy page. Yes, perhaps the page pointed to by WP:NOTBLOG might develop into a separate policy, but the actual shortcut page isn't going to change any time soon. Given this, it seems eminently reasonably to suggest that if someone who isn't autoconfirmed wants to change the redirect, they should make a editprotected request on the talk page or just approach an autoconfirmed user or admin about it.

This seems utterly uncontroversial to me: a tiny downside with a huge benefit. Anyone got any reasons why we shouldn't start semi-protecting shortcuts to protect against potentially hard-to-detect vandalism? —Tom Morris (talk) 08:16, 31 July 2011 (UTC)

Can't think why it's not done as standard, really .... no reason not to do this, every reason to do it. So do it! Pesky (talkstalk!) 08:43, 31 July 2011 (UTC)
  • On general princple, things should be non-protected, unless there's good reason to do so. In this case protection actually only assists people who are not following WP:WOTTA in the first place, so I'm not sure if that's really the best approach. --Kim Bruning (talk) 23:53, 31 July 2011 (UTC) doubly so because WP:WOTTA is specifically aimed at assisting new users :-P
  • Oppose, we should keep the number of places where you need permission to edit at an absolute minimum, and most shortcuts are not essential. The suggested semiprotection also doesn't really solve the problem, which is that apparently shortcuts are not being monitored enough. —Kusma (t·c) 08:59, 1 August 2011 (UTC)
  • Oppose, the potential just isn't high enough to even bother. -- œ 12:27, 4 August 2011 (UTC)

I think this should talk more about the "WP" shortcut.

It doesn't talk enough about "WP" in place of "Wikipedia". Ian Streeter (talk) 14:21, 25 November 2011 (UTC)

???

Why did you put 50 Shortcuts in each help page !? It's so horrible. --Nouill (talk) 11:22, 21 August 2012 (UTC)

Category:Shortcuts that are English words

Category:Shortcuts that are English words is linked from the readability section on this page to give examples of shortcuts that are easy to recognize. However this category was recently nominated for deletion. I thought the people here might want to offer an opinion on whether this category is useful and should be kept or not. Dragons flight (talk) 21:45, 27 November 2011 (UTC)

Well I for one thought it was useful. -- œ 04:40, 28 August 2012 (UTC)

T: template redirects

I have listed 13 of the T: template redirects at Wikipedia:Redirects for discussion/Log/2013 November 18#T:WPTECH for deletion. Currently T: has many strange entries, defying an attempt to provide guidance on when T: is acceptable. If the majory of those 13 are deleted, the remaining T: shortcuts should be indicative of permitted uses, and this guideline could be updated to state that T: shortcuts are permissible for template pages that have a lot of traffic. John Vandenberg (chat) 16:09, 18 November 2013 (UTC)

H: prefix

The H: prefix is currently listed as 'less commonly used'. There are quite a few pages under special:prefixindex/H: given the number of pages in the special:prefixindex/Help: namespace. As far as I could so, there is only one H: redirect to mainspace, being H:CEA to Halo: Combat Evolved Anniversary.

I think H: should be moved up to the 'Commonly used' table. John Vandenberg (chat) 15:53, 18 November 2013 (UTC)

  Done John Vandenberg (chat) 12:53, 27 November 2013 (UTC)
I don't think H: can be said "commonly used" given the numbers from prefix. Better no "un/commonly" judgement in the lists at all? -DePiep (talk) 17:58, 27 November 2013 (UTC)

Disputed-inline

In section "List of Prefixes", I edited this. Paine Ellswoth reverted[1], admitting "good faith". PE however did not source the "dispute", did not point to any discussion mentioned, and did not open the talk that they state is needed.
Since PE did not back-up any claim, I conclude that the reversal is unfounded. -DePiep (talk) 13:57, 9 January 2014 (UTC)

Request for Paine Ellsworth to point to the actual "dispute" where my edit (you reverted) is discussed. Also, please point out how the pre-text (you reverted to) is correct in itself. -DePiep (talk) 12:45, 10 January 2014 (UTC)
Hi, DePiep – You're correct, I should have pointed to the discussion in question, which is the RFD discussion at the Village pump. The text that was in place that I reverted to is yet to be decided upon whether or not it is correct, so it should stay in place as the status quo. If the community decides that these are not pseudo-namespaces, only then should it be altered. Joys! – Paine Ellsworth CLIMAX! 14:18, 10 January 2014 (UTC)
So that is a discussion. Where in there is proposed to change current facts so that C:, MP:, INTRO: are to become pseudo-namespaces? Then, why should we leave that incorrect startement in this page? -DePiep (talk) 12:01, 11 January 2014 (UTC)
Because as noted in that discussion, the developers consider all shortcut redirects that are titled with single or multiple letter combinations followed by a colon to be in a "pseudo-namespace". You can easily confirm this. Just go to Bugzilla and search for "cross-namespace" and "pseudo-namespace", then read the discussions. – Paine Ellsworth CLIMAX! 23:11, 11 January 2014 (UTC)
The developers at mw do not decide what pseudo-namespaces are. Also, developers talking "if it is any namespace it has a colon" (understand) does not imply "if it has a colon it is a namespace" (wrong logic). So in developers environment there is no argument at all for this (btw, you did not give any useful link for your statement -- I am not here to do your homework).
On top of this, your claim about "based upon community consensus, longstanding consensus" is not sourced either. Again I ask: how and where are these defined as pseudo-namespaces? -DePiep (talk) 21:31, 13 January 2014 (UTC)
This discussion must stop so as to avoid the confusion of multiple discussions on the same subject. I've answered these questions time and again. It is your homework that needs to be done, not mine. If you want to continue this, then please take it back to the centralized discussion at the pump. Joys! – Paine Ellsworth CLIMAX! 03:59, 14 January 2014 (UTC)
It is you who should source your statements. Also, there is no confusion because there is not even a content overlap (actually, nowhere in your links & suggestions the definition I ask for is even mentioned).
And when I describe the limited reach of mw-talks (whatever your links into there would be), it is not up to you to stop the discussion. Once again, where are they defined to be pseudo-namespaces? -DePiep (talk) 07:31, 14 January 2014 (UTC)

Semi-protected edit request on 27 April 2014

Please remove "C:" and "INTRO:" from the pseudo namespace section as they no longer exist. 31.100.23.203 (talk) 11:32, 27 April 2014 (UTC)

  Done -- John of Reading (talk) 13:42, 27 April 2014 (UTC)

Template shortcuts

RFC RECOMMENDED:

A close was requested at WP:ANRFC. As noted by editors here, this was a normal talk page discussion, not an RfC. The discussion about how to handle template shortcuts was unstructured in that editors discussed different questions throughout the discussion. The lack of structure makes participation by uninvolved editors less likely and assessing consensus difficult.

I recommend creating an RfC titled something like "RfC: Template shortcuts", with subsections for discussing each question or topic. Perhaps list the RfC at Template:Centralized discussion to encourage participation from the wider community, as was done with Wikipedia:Village pump (policy)/Archive 112#RFC: On the controversy of the pseudo-namespace shortcuts. This will result in a clearer consensus for each of the questions discussed here.

Here are the main questions I've found from the discussion (feel free to use these questions as a rough draft for the RfC):

  • Should template redirects for project banners and their equivalent project shortcuts always/usually be harmonized?
  • Should a very short template redirect for a WikiProject template always/usually have "WP" as a prefix?
  • Should all variations of case for WikiProject template shortcuts point to the same target?
  • Should T:XYZ and Template:XYZ always/usually point to the same place?
  • Should the 500 WikiProject template redirects at User:Scott/WikiProject template redirects that have no transclusions and do not begin with "WikiProject" or "WP" be deleted?
  • Likewise, should the WikiProject template redirects that have no transclusions and do begin with "WikiProject" or "WP" be deleted?

I recommend spending several days to a week deciding on the wording of the RfC's questions before formally listing it as an RfC and at Template:Centralized discussion.

I am closing this discussion as editors are recommended to create an RfC with subsections for each of the questions or topics. Cunard (talk) 05:17, 12 June 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Replying to this post by user:Mendaliv , redirects have been so poorly maintained that a policy discussion would be useless on its own. Having these thoughtful discussions about individual cases helps to find what parts of a new policy might have consensus. WP:SHORTCUT was rewritten recently *after* the weirdest cases of (mainspace) WP:PNR were deleted at RfD. (Before the weirdest cases were removed, the discussions were dominated by people seeking to protect their baby, or resisting any and all change) This policy needs more heavy revision to improve guidance regarding other aspects of shortcuts, and it seems template shortcuts are the topic of the 'month', with user:Jax 0677 creating so many, so we should at least start with the basics.

This guideline already deals with case (lower vs upper) and prefixes of 'shortcuts to subpages'.

This guideline doesnt cover relationships between shortcuts of WikiProjects and their templates. IMO, we should move towards consistency between project shortcuts and template shortcuts and category shortcuts, where possible. I dont think it needs to be a hard rule, but guidance should be given so that shortcut creators know they should take that into consideration when choosing a name, as RfD will consider it.

The other recurring naming issue is when should wikiproject templates use a WP prefix. There is a lot of variance in existing practises here, but I see some consistency in 'WP prefix is needed if the postfix could reasonably refer to a real topic'. John Vandenberg (chat) 05:22, 14 April 2014 (UTC)

I agree generally with this, and hope we can add some clarity to policies and guidelines so that we don't need to have people on either side firing their blunderbusses (whether to create new template redirects to avoid what caused deletion in the last RfD, or in starting scores of new RfDs on single templates when the issue could be resolved simply by a policy clarification). In short, I think it's reasonable that when dealing with WikiProject banners, we should follow WP:SHORTCUT consistently. I have a few specific points I'd like to address, however:
  • I absolutely agree that the structure of a very short template redirect for a WikiProject template should always have "WP" as a prefix. I cannot envisage a situation where a two- or three-character string would unambiguously refer to a WikiProject versus something else. I do, however, think that there are a number of longstanding banner template redirects that are not prefixed with WP (but are long enough to be unambiguous), so I don't think this should be an absolute requirement.
  • Template redirects for project banners and their equivalent project shortcuts should always be harmonized. I do not, however, think there should be a hard-and-fast rule for which one wins. Longest established is probably a good rule of thumb, but it's entirely possible the former is for a dead project. This is in fact a problem that has come up at RfD presently: we have {{WPCM}}, WP:CM and WP:WPCM, which all point to different targets.
  • I don't necessarily agree that the case variant issue should cover WikiProject templates, mostly because the reasoning behind preferring one casing has to do with the case-insensitivity of the search box, and that preferring uppercase seems to be a stylistic preference when creating links; neither of these really apply for templates (the former because all uses of these templates will be in case-sensitive places, and the latter because the uses are virtually invisible). While I think creating case variants should not be encouraged, I don't think that the existence of one should put it outside policy.
Anyway, I think those are the big issues that have come up in the recent RfDs that sparked at least my call for this discussion. Thank you, John, for taking the time to start it. —/Mendaliv//Δ's/ 05:44, 14 April 2014 (UTC)
@Mendaliv:, as we agree broadly on all but the casing of shortcuts, would you agree that all variations of case should point to the same target, and that any use of 'T:<XYZ>' should point to 'Template:<XYZ>' (i.e. T: shortcuts should be in sync with the template name. I think we have a few outstanding cases where this does not hold, and those are hard discussions, but we can give better guidance/policy for future creations to prevent new instances of this problem occurring). John Vandenberg (chat) 05:53, 14 April 2014 (UTC)
I am racking my brain to come up with a circumstance in which you might want two casing variants to point to different targets. I feel like COP/CoP/cop might be an instance where you'd have plausible variation, but I think even that you'd want to resolve. And yeah, the T:XYZ is pretty clear, though for me... I don't see much point in creating T:XYZ shortcuts for project banners anyway. —/Mendaliv//Δ's/ 06:01, 14 April 2014 (UTC)
Yes, T:XYZ should always point to Template:XYZ, I always thought the point of the shortcut was just to save a bit of typing for editors (for that matter were we staring from scratch we could have had the Template: namespace just called T: since anyone familiar enough with Wikipedia to use or write templates would surely get the hang of that). As far as casing goes, since the search bar s case-inseinsitive it is not useful to have different casing going to different places. (I would argue this even for articles let alone for things in Wikipedia's internal plumbing: I know historically that disambiguating titles simply by case has been quite common but I think it is harmful).
However, I raise another issue in that there are templates such as {{-}} which are probably not covered just by the "casing" rules since they have no letters in them. I am not saying there is a problem there, only that the wording of the guideline better be careful so as not accidentally to ban these kind of well-established templates. Si Trew (talk) 09:05, 14 April 2014 (UTC)
No, T:XYZ and Template:XYZ should not always point to the same place because as was established in a discussion a few months ago they are used differently and without confusion: T:XYZ shortcuts are used to link to a template, they are not used to transclude templates. Template:XYZ shortcuts are used when linking using {{temp}}, {{tlx}}¸ etc. (e.g. {{temp|XYZ}}) or when transcluding (e.g. {{XYZ}}). New creations (of both formats) should be encouraged not to use shortcuts already in use by other templates, but nothing stronger is required or desirable. Thryduulf (talk) 11:39, 14 April 2014 (UTC)
Yes, the only really established T: shortcuts are ones like T:ITN, T:DYK and T:TDYK (which is actually a Template talk: shortcut), and what they all have in common (apart from being undisputedly shortcuts, unlike the Template: shortcuts/redirects) is that while they're commonly typed into the search box or used to link to a page (like non-template shortcuts) they are not usually used for transclusions or substitutions (again like non-template shortcuts). In other words, they're purely navigational aids.
It wouldn't hurt to clarify somewhere that T: shortcuts are only meant to be used that way, though (insofar as we agree that's the appropriate use). Sideways713 (talk) 12:06, 14 April 2014 (UTC)
"T" is short for "Template". T:XYZ should point to Template:XYZ or it should not exist at all. — Scott talk 14:53, 17 April 2014 (UTC)
"T:" is a pseudo-namespace for use in shortcuts. Thus, the XYZ in T:XYZ is likely to be some kind of abbreviation. By contrast, the XYZ in Template:XYZ is usually not an abbreviation but will be something longer.
That is the same way it works with other pseudo-namespaces, and shortcuts in general; for instance, "P:" is short for "Portal:", but most of the time P:XYZ doesn't point to Portal:XYZ. I looked at a random sample of four consecutive "P:" shortcuts - P:BSAS, P:BUCKS, P:BUL and P:BURMA. Of these, P:BSAS points to Portal:Buenos Aires, and there's no corresponding redirect at Portal:BSAS; similarly, P:BUCKS leads to Portal:Buckinghamshire, with no Portal:BUCKS anywhere to be seen. P:BUL leads to Portal:Bulgaria - again, Portal:BUL doesn't exist. Only P:BURMA comes close to meeting your expectation, being a shortcut to the lower-case Portal:Burma.
And all of those four are entirely valid shortcuts; that's exactly how the "P:" pseudo-namespace is supposed to be used. If P:XYZ so often doesn't point to Portal:XYZ, I see no reason why things should be any different for T:XYZ and Template:XYZ. Sideways713 (talk) 10:24, 18 April 2014 (UTC)
Part of the problem here is the issue of whether WP:SHORTCUT applies to these short template redirects at all. It was argued by BDD at Wikipedia:Redirects for discussion/Log/2014 February 25#Template:Wpcm that shortcut guidelines don't apply since these redirects are not shortcuts, and it's not that hard to see why; the lead of WP:SHORTCUT, viz. A shortcut is a specialized type of redirect page that provides an abbreviated wikilink to a project page or one of its sections, usually from the Wikipedia namespace. They are commonly used on community pages and talk pages rather than in articles themselves. If there is a shortcut for a page or section, it is usually displayed in an information box labelled Shortcuts:, as can be seen at the top of this page, seems to be talking about something quite different, and Wikipedia:List of shortcuts lists no template shortcuts expect T:ITN and WP:TBACK, neither of which starts with "template" like these redirects. On the other hand, most of these redirects have the same basic idea as shortcuts - cutting down on characters needed - intuitively, you'd think they were shortcuts, and maybe that if the definition of "shortcut" doesn't cover them now it should in the future. Further, while missing from the list of shortcuts, there actually are quite a few template shortcuts that own up to being just that; the documentation of {{db-g7}}, for instance, lists several... although none of them are in allcaps like normal shortcuts, and many of them are actually longer than the regular title. Finally, there's the matter of origin: Jax 0677's redirects were meant to be "shortcut-like", but some other similar redirects (like {{Beer}}) were the actual original titles and thus by definition not shortcuts.
As for overturning the consensus formed at Wikipedia talk:WikiProject Council/Archive 8#WikiProject Banners - the need for more standardized names and Wikipedia talk:WikiProject Council/Archive 8#Standardising WikiProject banner names (cont) and represented by the essay Wikipedia:Banner standardisation that redirects to WikiProject banner templates don't have to start with Template:WP, I don't think that's a good idea; people are claiming using redirects not of this type confuses people unduly, but I suspect deleting established redirects would confuse them more. What are they expecting to see in talk page banner sections, navigational templates?
However, like Mendaliv, I don't think very short (two-character, maybe three-character) acronyms with no WP prefix make for good redirects to WikiProject talk page banners unless well-established over the years. In those cases, mandating the WP prefix is likely a good idea. Sideways713 (talk) 10:58, 14 April 2014 (UTC)
I think the only things that are needed are (1) a strong encouragement that new shortcuts should being with "WP" and be unambiguous, (2) a prohibition on the nomination for deletion of existing shortcuts (whenever created) (i) on the sole grounds that they do not start with WP, and/or (ii) on the grounds of confusion without evidence of confusion being included in the nomination rationale, and (3) in the case of evidential confusion between multiple targets a nomination should seek to clarify what the target for all the related redirects should be rather than simply deleting one or more for deletion (e.g. discuss confusion between "Template:GAO" and "Template:Gao", don't just nominate the latter for deletion).
Things to note are that redirects like {{DisambigProject}} are not at all ambiguous and deletion would not help anybody. Short names may not be ambiguous at the time of creation, but may become so later - e.g. {{GAO}} would be unambiguous for a "Giant African Organisms" wikiproject created today, but would become ambiguous if "WikiProject:Great American Orations" were created in the future - this would not automatically make {{GAO}} problematic. Just because something is theoretically problematic does not mean that there is any actual problem on the ground - e.g. {{UAe}} for a WikiProject about a "Universal Aerospace Corporation" would be theoretically confusing with {{UAE}} for the United Arab Emirates, but if neither is ever referred to using the other capitalisation there would be no problem in practice. Thryduulf (talk) 11:39, 14 April 2014 (UTC)

I've been expecting this discussion to commence so have been spending a while in the background doing analysis to provide a bit of quantitative basis. Please see User:Scott/WikiProject template redirects (big page, will take a moment to load). The high-level summary of my findings is:

  • There are close to four and a half thousand redirects to "Template:WikiProject [something]" templates.
  • Three quarters of those redirects begin with "WikiProject" or "WP".
  • Out of the remaining quarter, 500 have no transclusions at all, and 200 have ten or fewer transclusions. Together that makes 60% of the inconsistently-named redirects, and 15% of the total number of redirects.

In other words, 85% of WikiProject template redirects that are actually being used in the wild are named beginning with "WikiProject" or "WP". If we raise the threshold for how we define actually being used - 10 or fewer is a very low bar - it's probably more like 90%, which is entirely in line with the belief that various RfD participants have expressed recently that there is a standard of naming for shortcuts. However, there are some very well-established exceptions; there are over 80 shortcuts not beginning with "WikiProject" or "WP" that have transclusion counts in the thousands. Obviously there's no possibility of changing those - and really no argument for it either.

I would suggest that the first thing we do is delete those 500 unused redirects en masse. Zero transclusions means they're not even documented; they have no realistic prospect of useful function and only serve to clutter the namespace and confuse the issue. Next, those 200 redirects with very low use almost certainly represent redirects that were either created as an alternative, or left over after a project template redirect was moved. They should all be replaced with their projects' standard template shortcut, and then deleted. Once this spring clean, if you will - it is in fact spring in this part of the world as I type - has been completed, we'll be able to obtain a much more accurate numeric picture of what people are actually doing with project template redirects. — Scott talk 13:26, 14 April 2014 (UTC)

  • P.S. My thoughts on capitalization are thus. Naming a shortcut "Wpxyz" is, basically, a hack. It takes advantage of the way MediaWiki handles page titles in order to allow typing them in lowercase when transcluding a shortcut. But lowercase shortcuts only make sense when you're typing a word in the English language (like {{album}}, with 100k+ transclusions). "WPXYZ" isn't a word, it's an initialism, and conventional orthography represents initialisms in uppercase (as reflected for encyclopedic content in our manual of style at MOS:ACRO). We would do better to enforce a standard that reflects common practice in language and discourages hacks that represent a very poor saving of effort. — Scott talk 13:39, 14 April 2014 (UTC)
  • How many of the redirects that do start with "WP" or "WikiProject" have zero transclusions, and how many have 10 or fewer? I'm not sure what we would gain from a mass deletion of unused redirects (redirects being cheap), and in general redirects aren't deleted just because they're not used; but if we were to delete them en masse in this case, the unused redirects that do start with "WP" or "WikiProject" are just as cluttering as those that don't and should also go. Sideways713 (talk) 14:05, 14 April 2014 (UTC)
  • "Redirects are cheap", but technical debt is expensive. This discussion right here, and all the other ones at RfD, are technical debt in action; discussions are work. In the real world, engineers get paid to have the sort of meeting we're having right now! Regarding the unused WP/WikiProject redirects - I agree with you. I didn't generate figures for those yet, because I wanted to triage this and address the most inconsistent area first; but should we clean up that area as well? Absolutely. — Scott talk 14:11, 14 April 2014 (UTC)
  • You shouldn't claim that 85%-90% of redirects seeing actual use start with "WP" or "WikiProject" if you've only removed little-used "anything else" redirects from consideration and not little-used WP/WikiProject redirects. The only number that you've consistently calculated so far is 73.93% (for all these redirects, regardless of how much they're used); I strongly suspect the actual numbers for "redirects with at least one transclusion" and "redirects with more than 10 transclusions" are in that same ballpark, certainly nowhere near eighty-five or ninety percent. Sideways713 (talk) 14:23, 14 April 2014 (UTC)
  • Hm, I concede your point - that was an incorrect assumption on my part. Thanks. Right, I'll be back with more numbers in a bit. — Scott talk 14:53, 14 April 2014 (UTC)
  • Okay, the new numbers are in. Thanks Sideways713 for spotting my erroneous assumption that "WikiProject"/"WP" redirects would be more orderly; in fact, the numbers are abysmal across the board. 60% of all WikiProject template redirects are unused. (And again, this is using the very, very low threshold of >10 transclusions to rate as "used".) Out of the remainder, 20% begin with "WP", 10% with "WikiProject" and 10% with anything else - so the latter are outnumbered in the wild 3 to 1. — Scott talk 00:46, 18 April 2014 (UTC)
  • NOTE there are several bots that go around and replace the redirects with direct transclusions, so the redirect being unused at the moment is not an indication that it is actually not being used, since a bot may have gone through and replaced the transclusions with direct ones. -- 70.24.250.192 (talk) 07:12, 22 April 2014 (UTC)
  • [citation needed] What bots would those be? And why were they approved, given that editors are explicitly instructed not to perform make-work of that nature? — Scott talk 00:37, 3 May 2014 (UTC)
  • Further to the anonymous user's point, transclusion do not count in page view statistics either and the majority of people have little need (if any) to view the actual template. This means that knowing when such a redirect is actually unused is very nearly impossible. For this reason "unused" should not be considered as any reason to delete a redirected. Conversely, telling when a redirect is used is much easier so it is a good reason to keep a redirect. Thryduulf (talk) 09:21, 22 April 2014 (UTC)
  • transclusion do not count in page view statistics Page view statistics aren't being discussed here. — Scott talk 00:35, 3 May 2014 (UTC)
  • @Scott: The whole technical debt argument is not really a good one. Once the redirect is created, we gain absolutely nothing by deleting it. We may try to establish policy regulating their creation to reduce the impact of such creations, but in the end it's pointless to go through and delete them on those grounds. Cf. Wikipedia:Tools/Navigation popups/About fixing redirects; see also WP:DWAP. —/Mendaliv//Δ's/ 16:38, 14 April 2014 (UTC)
  • The viewpoint that you're espousing is mired in the worst kind of short-termism. I hate to have to be the one to point this out to you, but the very discussion that you're taking part in right now is the latest offshoot of dozens, if not hundreds of editor-hours spent on discussing what to be done about inconsistent redirects of all stripes. And how long do you expect the participants in this discussion to stay around with the project for? Will we be here in four years? Eight? Sixteen? What happens when some editor of 2024 comes across one or a hundred strangely-named shortcuts? Do you expect them to dig through hundreds of pages of discussions like this, or like this - I hesitate to picture how much more of this back-and-forth will be generated in the years to come - only to discover that the best we came up with was to throw our hands up in the air and say "who cares"? What if a future generation of editors decides that actually, having clean namespaces and link indexes is a good idea? How much needless work will be our legacy to them, how many more weeks of discussions rehashing the same old subject over and over again? And how about people who download our database dumps? I bet you didn't think of them. All the junk we generate will be cloned and saved and shoved about the Web ad infinitum, increasing the complexity of future analysis and processing of all types.
    Everyone pushing the narrative that the back streets of this project are some kind of harmless landfill of infinite size needs to start thinking of themselves as the builder of the house that their children, and their children's children, will have to live in and maintain. I, for one, don't want my descendants to have to live in the digital equivalent of the Winchester Mystery House. — Scott talk 19:07, 14 April 2014 (UTC)
  • See, that's a good point: inconsistency and poor documentation of standards is problematic to editors. That's what I hope this discussion will resolve (rather than the endless back-and-forth we've been seeing of redirect creation followed by RfDs). If the standard is documented, it will at least blunt the point-counterpoint going on. Now, if we determine that such-and-such editor is being disruptive by creating multitudes of pointless redirects, then that's a behavioral problem. Taking care of it at RfD is not the right solution. Treat the roots, not the branches. —/Mendaliv//Δ's/ 19:15, 14 April 2014 (UTC)
  • But, conversely, if someone is being a loose cannon while thinking they're permitted to do so by the status quo, then that's the branch, and (lack of) policy or guidelines is the root. — Scott talk 19:51, 14 April 2014 (UTC)
  • Agreed, completely. The ideal here is to focus policy to the appropriate extent, and using common sense to handle disruption. There we get into how to handle behavioral disruptions (i.e., whether someone's wikilawyering). But the first task should be to clarify policy to the extent necessary to make behavioral outliers distinct from zealous advocates. —/Mendaliv//Δ's/ 22:42, 14 April 2014 (UTC)
  • We're in full agreement on that. — Scott talk 18:58, 15 April 2014 (UTC)

Comment - I will agree with the proposal given, that most of the time, with some exceptions, that redirects to WikiProject Templates that have less than four letters should be prefixed with "WP" or "wp". Per WP:CHEAP, I do not see any harm whatsoever with lower case variants such as {{wpcw}} being accepted, unless a better use for them is found. With that being said, if a better use for the lower case variant is found, we should probably consider retargeting the upper case variant to the same location. --Jax 0677 (talk) 04:52, 17 April 2014 (UTC)

The harm is, Jax 0677, that lowercase variants are introducing a mental load to the editor (each and every editor) that sees the variant. That can be in code, talkpage, WP-discussion, es, and whatever. Because that editor is required to remember, know or research the difference between lowercase/uppercase name. This applies for every lowercase variant that exists. That requirement is contadicting the shortcut essence.
Your WP:CHEAP argument may literally be applicable here as with every redirect, but for its spirit is does not hold. CHEAP is well understood for mainspace redirects, where it can cover loads of typo's and variant names for good reasons. But given the harm I mentioned, they are not cheap in situations discussed here. And of course if CHEAP were a WP pillar for "anything goes" (as you use it), we would not need RfD at all. I also note that creating redirects because they are cheap is unacceptable behaviour for being WP:POINT. -DePiep (talk) 07:21, 17 April 2014 (UTC)
Well, I don't necessarily agree with that. Sure, WPCW vs. WPCN vs. WPCT (if all those were created and pointed to different things) is not good, though I don't think so much because it imposes a mental load on editors (if you only tag for the "CW" project, you probably won't even know about or care about the "CN" project) but because it leads to a lot of arbitrary rules over who gets what acronym (Do we always follow the ISO 3166 country code? What about WPCM where the Cameroon project is nonexistent and the Classical Music project does exist?). I also think this is a general shortcutting issue; WP:ZH is acceptable, so why shouldn't {{WPZH}} be acceptable? Anyway, as to the capitalization issue, I think that if you have WPCW and wpcw, and they both point to the same thing, it's not something we should care about. I don't see a mental load issue, and by reserving the case variant, you foreclose the chance of having another unnoticed collision like was formerly present with {{COP}} and {{cop}}. Anyway, I think my point is this method of framing the discussion—cheapness versus expense—isn't particularly helpful. —/Mendaliv//Δ's/ 14:16, 17 April 2014 (UTC)
This requirement of country codes taking primacy isn't based in any existing convention that I know of (barring being an impromptu extension of how we allocate Wikimedia project subdomains, which is very strictly regimented). WikiProjects get their initials on a first come first served basis; Classical Music can't be expected to move aside for Cameroon. What I do believe in is that where Wikproject Xample Xample exists with the shortcut WP:XX, Template:WPXX should be a shortcut to Template:WikiProject Xample Xample. Having {{WPXX}} match [[WP:XX]] is a completely unambiguous, predictable and convenient system. — Scott talk 15:07, 17 April 2014 (UTC)
Yeah, I know it's not really a rule, but it has come up at RfD a lot recently and I've kind of latched onto it. I think it's actually a sensible rule of thumb in a number of cases, especially where you're talking about a redirect that isn't being used and there's an active WikiProject at the other end. Anyway, I agree that the classical music project isn't going to lose its shortcut to the Cameroon project. I also agree with your general pattern. I guess we're kind of coming up with a number of factors that should be considered when determining who should get a shortcut: first in time, matching project initials, country code, project inactivity. —/Mendaliv//Δ's/ 15:40, 17 April 2014 (UTC)
"Per" WP:CHEAP? It's an essay. — Scott talk 13:54, 17 April 2014 (UTC)
It is an essay that represents a very wide, long-standing consensus. Thryduulf (talk) 10:04, 19 April 2014 (UTC)
Mendaliv. I was responding to Jax 0677, who promoted shortcuts like Template:Wpxyz. Your examples (WPCW WPCN WPCT) are a different subthread in this. I stated that bad abbreviations are not helpful. -DePiep (talk) 07:44, 18 April 2014 (UTC)
Who are you to decide which abbreviations are "bad"? Why is there a need to have any regimentation about who can use which shortcuts? Surely it is for the WikiProjects themselves to determine which abbreviations they use rather than for a bunch of outside editors arbitrarily impose a solution - doubly so when there isn't actually any problem that needs solving. Thryduulf (talk) 10:04, 19 April 2014 (UTC)
Do I hear a commanding tone? -DePiep (talk) 13:12, 19 April 2014 (UTC)
Thryduulf. The real response is that WikiProjects are not working isolated, they are working in the open. For example a WP-membership does not imply privileges. WikiProjects cannot claim a shortcut. And also, I have responded in many occasions we met over this, which you don't seem to have processed. So I save my trouble of repeating them.
The more worrying response is that, since we first met over this last November 2013, you seem to be entrenched in a position. I get the impression that no argument, not any argument, arrives being read in your house. For me, that is tainting you editorship. I'd wish you a more relaxed handling of the XfD issues, and have the editor's fun & quality I remember from earlier meetings on this site. A break in some form could cheer you up. -DePiep (talk) 20:28, 20 April 2014 (UTC)
Sorry, but you don't get to win an argument by telling your opponents to get lost. I stand by my position that there is no need to legislate a standard when there is no evidence of any problems that need to be solved. Redirects are primarily useful to the people who use them, and the people who are most likely to use redirects to Wikiproject templates are members of that project. This may seem "entrenched" to you, but until someone comes up with any evidence that redirects are not cheap, and evidence that this is a problem, I will continue to believe that keeping things which benefit people is a Good Thing. Thryduulf (talk) 21:09, 20 April 2014 (UTC)
No "get lost" was said. I wrote responses to your comments, that introduced a non helpful and incorrect personal angle. -DePiep (talk) 10:30, 22 April 2014 (UTC)
While you did not use the words "get lost" that was the exact impression I got from your comment. When someone presents an argument, here or at XfD, I evaluate it. I have yet to see any rationale argument or evidence that either validates your position or demonstrates that my position is incorrect. Until that changes, then I will not be changing my mind. Your comments read to me as though you have realised that your position can never be supported by such evidence and rather than change your opinion you are hoping that if I disappear for a while then you might win by attrition. Thryduulf (talk) 15:54, 22 April 2014 (UTC)
  • Comment - If one does not use a redirect themselves, it will not take up mental bandwidth. If a redirect with all capital letters points to one location, why would we want the corresponding redirect with all small letters to potentially point to something else? If we delete lower case redirects for this reason, then will may need to delete {{songs}} and {{albums}} as well. Also, as of late, I have refrained from creating WikiProject redirects, and I plan to comply with the decision to be made here. --Jax 0677 (talk) 01:44, 22 April 2014 (UTC)
  • Comment
    • WikiProject redirects - almost all wiki-projects have their template banner at the same name as the WikiProject. OF the three I am aware that don't, two have (or had last I looked) redirects from the name of the WikiProject (US Roads, and Canada Roads), only WikiProject Mathematics has (or had last I looked) solely a banner at a different, page, and the person who WP:OWNed that seems to have retired.
    • WP:AWB replaces most short-cuts as a general fix.
    • Some very valuable namespace is occupied by these redirects - for example {{Physics}}. Most of the stuff beginning with "WP" is less valuable, and if WP were not also the abbreviation for Wikipedia, would be of negligible value.
    • I have some software that produces a comprehensive list of WIkiProject banners and their redirects somewhere. Of course I am not allowed to post the results here, but they can be shared by other means if someone has a need for them
All the best: Rich Farmbrough13:57, 25 May 2014 (UTC).
  • Comment: all this fight against lowercase redirects in "Template:" namespace is misguided. Such redirects don't create mnemonic load ("mental load"? really?), they just make the lifes of some people easier, particularly of those without habbit of typing in ALLCAPS. While I personally avoid using redirects in this namespace at all, I see no reason for ruining experience for other people, and more so with non-existent rationale like in this discussion. — Dmitrij D. Czarkoff (talktrack) 07:07, 31 May 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Semi-protected edit request on 20 August 2014

90.148.75.121 (talk) 23:10, 20 August 2014 (UTC)

  Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. -- ferret (talk) 00:01, 21 August 2014 (UTC)

Discussion at a WP shortcut

There's a discussion at Wikipedia_talk:DEFINING about whether that redirect should be changed. Input from other editors would be welcome. DexDor (talk) 20:57, 29 September 2014 (UTC)

Copy edits for Readbility section

I'd like to propose some copy edits to the Readbility section. Currently it reads as follows:

Shortcuts are often used on talk pages in their abbreviated form, without any piped links, decreasing readability for the general reader. For example, some editors are familiar with the bulk of the Wikipedia namespace shortcuts, even recognizing what they stand for on sight; however, others are faced with pages full of incomprehensible jargon, the meanings of which are not immediately decipherable, if the reader happens to be offline.

While shortcuts can help with linking, it is best, when referring to a project page, to be mindful of the general reader and not use the shortcuts as a title, without piping their links. For example, the piped link: [[WP:SHC|shortcuts]], gives readers an idea of the subject of the target page, while just using the abbreviation WP:SHC is unintelligible to those unfamiliar with the term. For this reason, many shortcuts are also created as common English words that are easily identifiable and memorable.

Shortcuts are sometimes (ab)used to make a WP:POINT and best described by WP:WOTTA.

I'd like to change it to read as follows:

Shortcuts are often used on talk pages in their abbreviated form, decreasing readability for the general reader. For example, some editors are familiar with the bulk of the Wikipedia namespace shortcuts, recognizing what they stand for on sight. Others, however, are faced with pages full of incomprehensible jargon, the meaning of which is not immediately clear.

Shortcuts may also be (ab)used to make a WP:POINT, best described by WP:WOTTA.

To avoid these problems, a good practice when creating shortcuts is to choose common English words that are easily identifiable and memorable. Another good practice is to to be mindful of the general reader and use piped links when citing an obscure shortcut. For example, the piped link [[WP:SHC|shortcuts]] gives readers an idea of the subject of the target page, while the bare abbreviation WP:SHC is unintelligible to those unfamiliar with the term.

I think most of this should be uncontroversial, but would appreciate any comments. – Margin1522 (talk) 20:14, 15 October 2014 (UTC)

Shortcut hatnotes considered harmful

I'd also like to suggest one addition to the Readbility section. This is prompted by a discussion, started by me, at WT:Hatnote. The problem is a proliferation of shortcut hatnotes at the top of Wikipedia Help pages and guidelines.

For example, Help:Footnotes (WP:FN) currently has a hatnote directing readers to Wikipedia:Fringe theories/Noticeboard. Wikipedia:Template messages/Cleanup (WP:TC) has a hatnote directing readers to Wikipedia:WikiProject Tropical cyclones and Wikipedia:Triple Crown. None of these other pages have anything to do with the hatnoted pages, other than obscure shortcuts that could conceivably point to them.

So I would like to suggest adding the following two sentences to the end of the Readbility section.

It should also be remembered that shortcuts are a convenience, not a substitute for article titles. Shortcuts should be avoided in article text and should not appear in hatnotes or any other place where an article title is expected.

The effect of this would be to justify zapping these shortcut hatnotes on sight. In my opinion, they add clutter to the top of frequently viewed Help pages, and nobody would be seriously inconvenienced if they were eliminated. – Margin1522 (talk) 20:18, 15 October 2014 (UTC)

I agree in principle (e.g. it would enable removal of the hatnote at Wikipedia:Template messages pointing to Wikipedia:Terminal Event Management Policy). However I'm not sure the proposed wording is quite right - surely it shouldn't be referring to articles. DexDor (talk) 20:32, 15 October 2014 (UTC)
Yes, you're right. Even in mainspace articles you don't see many article titles in the text. Change the last sentence to 'Shortcuts should not appear in "See also" sections, hatnotes, or any any other place where an article title is expected." ? – Margin1522 (talk) 11:23, 16 October 2014 (UTC)
Done.– Margin1522 (talk) 07:34, 21 October 2014 (UTC)

Boy, I can sure attest to this, Margin1522, and declare that I was both irritated and confused when I landed on this page while searching desperately for information on how to cite the same source multiple times while specifying different pages for each reference but w/o having to post redundant data - and immediately saw a distracting link for "Wikipedia:Fringe theories/Noticeboard" at the top of the page!

I was like, "WTF?" and almost abandoned the page because fringe theories have nothing to do with the information I thought I was going to find here. I just like to read and edit articles, and yet I'm amazed by how difficult some ostensibly more experienced Wikipedia users seem to want to make the process of finding useful information on how best to actually add and edit encyclopaedic content. To the user who claimed so surely otherwise (not you, Margin), I can assure you that "a hatnote which says "For the fringe theories noticeboard, see Wikipedia:Fringe theories/Noticeboard" is absolutely [not] better than nothing", and it defies credulity that they think that the work of the editor is facilitated by adding distracting links to unrelated material at the top of how-to guides that are already hard enough to find. Azx2 03:05, 3 December 2014 (UTC)

Semi-protected edit request on 5 May 2015

70.185.246.89 (talk) 23:33, 5 May 2015 (UTC)

  Not done as you have not requested a change. Please mention the specific changes in a "change X to Y" format. --I am k6ka Talk to me! See what I have done 23:51, 5 May 2015 (UTC)

Shortcut boxes in article space

I've just removed all of the extant transclusions of {{shortcut}} in main space, all but one of which were errors in trying to tag articles with a cleanup notice. The one which was not came up in an instance where an editor tried to create a mainspace shortcut for themselves to get to an article, which is probably fine in and of itself (although it's at RfD and I've tagged it for speedy WP:R3) but even in that instance I can't think of any case where it would be proper to have a shortcut box in an article. In the interest of that, I've made a small change to the guideline suggesting that they not be used in articles (the guidance was a bit weak before). Please take a look and feel free to comment. Ivanvector 🍁 (talk) 18:08, 26 October 2015 (UTC)

Shortcuts that don't work, and anchors

Hi. I am a little confused. Very often, I find that shortcuts to a specific section don't work, they don't take me to the section, just to the top of the page. Apparently, this may be browser-specific behavior.

I have just been trying to sort out WP:NOPAGE. I may have succeeded, but can someone check?

It seems to me that Wikipedia:Notability#NOPAGE will take your browser to Wikipedia:Notability and then do a page search for the text "NOPAGE". I am guessing that some browsers are finding that text in the linkbox, and others don't.

I understood (from where I can't remember) that to make shortcuts robust, they must match the anchor template parameter. Exactly how this works I don't know. The anchor template produces no visible features on the page. I found that to make the shortcuts work, I needed to change the #field in the redirect.

This guideline says:

To learn more about the different shortcut box templates and their functions, see documentation at {{shortcut}}. Among other things, there are templates for making boxes flow to the left and now, anchors are automatically added, making it much simpler to link to a page section.

I don't understand. "anchors" are added automatically? Is this a reference to the anchor template? The NOPAGE shortcut used the shortcut template, and yet it was not working for me. I am using Windows 7 with a year or so old chrome. I don't think that people should be required to be more up to date than that for Wikipedia to work properly.

Any advice or thoughts? --SmokeyJoe (talk) 04:49, 18 December 2015 (UTC)

Shortcut redirected to wrong place

I've noticed that WP:ASPERSIONS, while clicking on the link, redirects to the section below the intended target while cutting off the correct section at the top of the screen (and makes for an awkward redirect subject to boot). Everything seems to check out at the actual redirect page though. Any ideas on what's causing this? I haven't been able to pick out what's going on after checking it out for awhile, so I figured it would be worthwhile mentioning here. I've noticed this both on Chrome and Firefox. Kingofaces43 (talk) 22:58, 13 September 2015 (UTC)

Looks like the shortcut has been redirected, so the issue has been fixed in a way. Kingofaces43 (talk) 05:24, 18 December 2015 (UTC)