The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was keep. My own calls for a procedural close notwithstanding, there's pretty clearly consensus for keeping these for now. Of course, the issue may be revisited pending the resolution of the Commons discussion. --BDD (talk) 17:53, 3 March 2014 (UTC)[reply]

• c:ATT → Category:Candidates for speedy deletion as attack pages (links to redirect • history • stats)     [ Closure: keep/delete ] 

• c:ATTACK → Category:Candidates for speedy deletion as attack pages  (links · history · stats)     [ Closure: keep/delete ]
• c:CVSD → Category:Candidates for speedy deletion as copyright violations  (links · history · stats)     [ Closure: keep/delete ]
• c:PROD → Category:Proposed deletion  (links · history · stats)     [ Closure: keep/delete ]
• c:SD → Category:Candidates for speedy deletion  (links · history · stats)     [ Closure: keep/delete ]
• c:CSD → Category:Candidates for speedy deletion  (links · history · stats)     [ Closure: keep/delete ]
• c:FUR → Category:Non-free use rationale templates  (links · history · stats)     [ Closure: keep/delete ]
• c:HM → Category:Wikipedians looking for help  (links · history · stats)     [ Closure: keep/delete ]
• c:NNSD → Category:Candidates for speedy deletion as importance or significance not asserted  (links · history · stats)     [ Closure: keep/delete ]
• c:OMMONS → Category:Copy to Wikimedia Commons  (links · history · stats)     [ Closure: keep/delete ]
• c:SPAM → Category:Candidates for speedy deletion as spam  (links · history · stats)     [ Closure: keep/delete ]
• c:AB → Category:Administrative backlog  (links · history · stats)     [ Closure: keep/delete ]
• c:OTRS → Category:Wikipedia OTRS  (links · history · stats)     [ Closure: keep/delete ]
• c:UNB → Category:Requests for unblock  (links · history · stats)     [ Closure: keep/delete ]
• c:RTSP → Category:Redirects to special pages  (links · history · stats)     [ Closure: keep/delete ]
• c:NON → Category:Candidates for speedy deletion as nonsense pages  (links · history · stats)     [ Closure: keep/delete ]
• c:Images → Category:Wikipedia images  (links · history · stats)     [ Closure: keep/delete ]

Pending the resolution of this requests for comments meta:Requests for comment/Wikimedia Commons, these administrative category redirects need to be deleted before the C interwiki prefix for Commons Wiki can be implemented. TeleComNasSprVen (talk • contribs) 22:27, 16 February 2014 (UTC)[reply]

• Oppose as a premature request. Reading the bugzilla ticket and the meta page it is not at all clear that the developers will implement this, especially as it's been WONTFIXed at least twice previously and 23 commenters in a 2 year old discussion is far less evidence of consensus than they normally seek for lesser changes. I am about to comment to this effect at bugzilla:4676. If the change doesn't go ahead then there is no reason to change these redirects and edit archived talks, etc as noted above. Thryduulf (talk) 23:19, 16 February 2014 (UTC)[reply]
• Is this the right forum for this discussion? (I'm not very experienced with enwiki.) Perhaps something more visible than RfD would be better. Also, note that on the gerrit patch I explicitly said not to merge it and -1'd pending further discussion.πr² (t • c) 23:31, 16 February 2014 (UTC)[reply]
  • Yes, something more visible is needed. Probably it's best to have it as an RfC that is phrased in such a way that any consensus to change C: to something else only takes effect if there is consensus on meta to implement C: as an interwiki to Commons. That might get more people to the meta discussion too. Thryduulf (talk) 02:49, 17 February 2014 (UTC)[reply]
• Deprecate them asap and delete, as C: was never accepted as a pseudo-namespace in the first place (just used as such). Shortcuts that have a deviating name (C: not CAT:) are the first example of unhelpfulness: how and why to remember the exceptions? If some are proven useful as a redirect, move to CAT: . Note that deprecation makes the process easier (reduction of instances used). Talkpage archives cannot take us hostage. -DePiep (talk) 01:55, 17 February 2014 (UTC)[reply]
  • DePiep, we've been through this time and again, C was de-facto accepted as a pseudo-namespace for years (being used as a PNR was all the recognition that was possible, let along required, until recently) and no consensus was reached about it in the recent RfC, so that part of your comment can be safely ignored. Every single edirect that is used has value, almost by definition, but this value needs to be weighed against all other relevant factors, which you don't mention at all, so that part of the comment is pointless. The comment about exceptions is also not really relevant as there is no limit to the number of shortcuts a page can have, so those who expect to find a page at c:Blah and those who expect it at CAT:Blah can both find it equally easily. Talk page archives are not holding anyone hostage, so please feel free to leave your hyperbole at the door and comment on the actual situation based on the policies and consensuses that exist rather than those you would prefer. Thryduulf (talk) 02:49, 17 February 2014 (UTC)[reply]

It was you who proposed repetition of arguments, remember. So here we are.

You are turning indifference into "de-facto accepted" as a consensus: your're free to this gymnasiastics, but that still does not establish C: as a pseudo-namespace.

Of course you (not me) know by heart which CAT:-shortcuts do not have their C:-twin. Doubling only some names makes it soo easy to work with, right? You have not written a single argument why there should be two shortcut-pseudos for the same.

Contrary to what you say, I did mention all the pro's that should be weighed in. It's just: there are none. And that is after reading your !vote.

I've made the list. The list shows a pollution of mainspace, and all but one is useless doubling. The C:OMMONS trick is not shortcut practice at all. -DePiep (talk) 03:18, 17 February 2014 (UTC)[reply]

@DePiep: I assume that the above CAT redirects which you added to the list are not meant to be deleted, but the ones which will be moved to when the C prefix is switched over? That's a reasonable outcome I could support, given that in my experience the CAT prefix enjoys a greater consensus historically behind its use than does the newer C prefix (de facto, but not de jure as CAT is according to Thryduulf).

@Thryduulf, I recommend commenting in the Meta RFC then if you disagreed with the outcome, which I completely understand. I don't think the developers would take too kindly to a debate on Bugzilla, though of course in a sense that's already in progress. The specific dev changes to MediaWiki and the bugzilla ticket have all been frozen, pending a show of actual community consensus discussion onwiki deciding either way, so there is no hurry to prevent nor enact the changes. A show of the disagreement onwiki, and more visibly on the Meta RFC which is linked to in the bug ticket's summary, is generally enough to convince developers otherwise not to go through with the change. TeleComNasSprVen (talk • contribs) 06:26, 17 February 2014 (UTC)[reply]

Good point. They are *not* listed for deletion here. I added a note. -DePiep (talk) 07:06, 17 February 2014 (UTC)[reply]

I add, see the CAT:-list: all these C:-redirects are already present in their CAT:-named age page with their same target page, except for CAT:OMMONS.

C:OMMONS is a shortcut name by spelling trick, not regular shortcut naming. I suggest no creation of CAT:OMMONS for that would be bended. If needed, it should be named CAT:COMMONS more corrctly & simple. (In the RfD above I'll detail C:WPCATSUP in this). -DePiep (talk) 08:38, 17 February 2014 (UTC)[reply]

Question Are there going to be pages/alternative redirects used should this 'C' prefix be adopted? If not, then why not keep the ones that have been created? Declaration - I created the C:ATT, C:NNSD and C:SPAM redirects, as I find it quicker and easier to type in the search box than their CAT equivalents. Also, I know my suggestion essentially boils down to something not unlike the RFA argument WP:WTHN. Stephen! ^Coming... 10:29, 17 February 2014 (UTC)[reply]

@StephenBuxton. When that prefic "c" is introduced for "commons", it will be used like the language prefixes we know. For example our English wikipage Congo River. From the German wiki (dewiki), it can be wikilinked directly by writing: en:Congo River (or En:Congo River, is wiki standard). And we here can simply wikilink to the German page: de:Kongo (Fluss) (or De:Kongo (Fluss)). And today, to go to the Congo River page on the commons wiki, we can write: Commons:Congo_River. So far so good.

In the future, proposed, we could link to that page by writing the wikilink c:Congo_River. But when we have a regular page here that is named C:ATTACK, there is no way to know for the software whether it is a page on en-wiki or on commons-wiki. (It could mean pages commons:ATTACK or en:C:ATTACK equally). That is why the deletion is proposed: prevent ambiguous pagenames.

One set of pages will remain troublesome: content articles that are correctly named like C︰Real here (so that is en:C︰Real not commons:Real). A solution for this situation will exist, but it is better not to overuse that with non-essential redirects because it's logical outcome may surprise the reader. -DePiep (talk) 11:17, 17 February 2014 (UTC)[reply]

Please also consider that commons:ATTACK means something else on Commons itself, where it actually means the page "ATTACK" in the "Commons:" namespace (the local prefered alias of the "Project:" namespace) to the full name of that page would be commons:commons:ATTACK... but it will never work on Commons itself. If then one want to unambiguously refer to the page named "ATTACK" in the root namespace of Wikimedia Commons wiki, we need another interwiki alias that will work also correctly on Commons. The "C:" interwiki alias is perfect for this use (it is not concievable to rename the project namespace on Commons without breaking lots of page in it and lots of links from external sites). Unfortunately, this kind of ambiguity exists since long between interwiki codes pointing to distinct sites managed in separate databases with distinct administrations, and local namespace names recognized on the local wiki.

My opinion is that MediaWiki should improve the recognition of interwiki codes by moving them outside the second square bracket, like other external links, such as [:interwiki[namespace:pagenamẹ|displayed text]] instead of [[interwiki:namespace:pagenamẹ|displayed text]].

• Note that it is not ambiguous with external URIs, as there's no URI scheme name before the initial colon after the first open bracket. The syntax for links with default URI schemse (HTTP: or HTTPS:) also starts with two slashes (without any colon before the two slashes), and is also distinguished easily.
• Note also that this syntax is exactly the same length as the existing one, it clearly separates what indicates an external site supported, from the internal naming scheme on that site (using an optional namespace and a pagename possibly with subpages). It just requires moving the colon before the interwiki code instead of after it and puttin these interwiki codes outside the internal brackets.

Without this syntax, the resolution of links will continue working like now, but the interpretation as local namespaces will continue taking the priority to the interpretation as external interwiki codes. So for the local part of the wikilink, between the two brackets, the prefix "commons:" will always match a local namespace first; attempting to resolve prefixes followed by colons will be attempted as before trying an external wiki, but ONLY if there's no external part before the second open bracket that unambiguously designates the interwiki code(s). Each wiki then will be able to manage themselves its own local naming conventions.

Examples with this improved syntax for wikilinks:

• [:[commons:ATTACK|displayed text]] unambiguously means (on all source wikis) the pagename "ATTACK" in the "commons:" namespace of the local wiki (the ":" interwiki part means "local wiki", it is necessary for the new improved syntax because its absence before the second bracket would trigger the current dual interpretation; which is not portable across wikis).
• If you want to force only the local interpretation without any interwiki, you'll use [:[ instead of [[, and you immediately know when parsing that this is is really an internal link. you can then know that "C:" (used in the internal part of a wikilink starting by [:[C:) is not an interwiki code. You can however use [:C[ or [:commons[ instead of [:[ to designate a resource on Commons:
• [:commons[ATTACK|displayed text]] unambiguously means (on all source wikis) the pagename "ATTACK" in the root namespace of Commons.
• [:commons[commons:ATTACK|displayed text]] unambiguously means (on all source wikis) the pagename "ATTACK" in the "commons" project-namespace of Commons.

verdy_p (talk) 23:36, 26 February 2014 (UTC)[reply]

But all this is of relevance only if there is a global consensus to use C: as an interwiki shortcut to Commons, which at present there is not. Thryduulf (talk) 12:08, 17 February 2014 (UTC)[reply]

No not all this. My argument that we should not duplicate the pseudo-namespace (CAT: into C:) is valid anyway. Also, deprecation to start with is a good outcome (prevent future habitues, to be disappointed). Let me point out that these are not just a shortcut variants (like WP:TPG#YES and WP:TPYES are), but the namespace(-suggestion) is variated. And of course the argument of mainspace pollution stands irrespective of the outcome. -DePiep (talk)

I would say that until the decision is made that the c: prefix is to be used only for Commons, those pages that are using it as handy abbreviated redirects can carry on using it, as they were clearly made for peoples convenience (I know my ones were). If and when the decision is made, then by all means delete them. OK, they might not fit the appropriate rules now, but isn't WP:IAR something that the project is ok about? Stephen! ^Coming... 12:42, 17 February 2014 (UTC)[reply]

Clearly the rules are not clear in this, so there is no cut & dried and outcome. But at least we could just deprecate them (as an outcome of this RfD). No advertisement, not used in new pages & templates, point to the alternative, but keep them working as is. That way experienced users like you can keep on using them, but we don't create new such users. All this independent of & before any C:=commons:-decision. (And maybe over time you happen to start using the CAT:-redirects because they're so easy to remember -- without clinical enforcement ;-) ). -DePiep (talk) 07:18, 19 February 2014 (UTC)[reply]

• Better to let that Meta discussion resolve before we start changing things that may not need to be changed. --BDD (talk) 17:12, 18 February 2014 (UTC)[reply]
  • IMO this is a good place to draw attention to the Meta discussion; resolution of issues here is directly related to resolution of issues there. TeleComNasSprVen (talk • contribs)
• This discussion, and its knock-on effect on the discussion at Meta, are examples of the consequences of allowing technical debt to accumulate through ad-hoc systems implementation. The long-term interests of this project and its editors would be best served by the removal of all C: shortcuts. At the very least there should be an immediate moratorium on the creation of any further similar shortcuts and the deprecation, as DePiep suggests, of those that do exist. C:OMMONS in particular is grotesque and should be deleted immediately. — Scott • talk 14:24, 19 February 2014 (UTC)[reply]
  • That is a valid opinion, but you have neglected to back it up with any evidence. Thryduulf (talk) 15:34, 19 February 2014 (UTC)[reply]
    • Here you go. Set it to "future". — Scott • talk 15:43, 19 February 2014 (UTC)[reply]
      • Thank you for the personal attack in the edit summary and the evidence that you do not regard the needs or opinions of people other that yourself seriously. Now, please could you give some evidence to back up your opinions? Thryduulf (talk) 09:56, 20 February 2014 (UTC)[reply]
        • That you are asking for "evidence" of something that will happen in the future says everything that needs to be said here. And no, pointing out that your doing so is ironic in the light of your regular appeals to the needs of imaginary people in RfD discussions is not a "personal attack", because it was not a comment on your person. I hope this information aids you to correctly distinguish the nature of commentary in future discussions. — Scott • talk 10:09, 20 February 2014 (UTC)[reply]
• Oppose as this is a useful PNR. I also oppose the alternate use of c: as a PIR (pseudo-interwiki redirect), and will comment as such on the appropriate proposal. — ((U|Technical 13)) ^{(t • e • c)} 23:04, 19 February 2014 (UTC)[reply]
  • @Technical 13: How would "c:" be a "pseudo-interwiki redirect"? There's nothing "pseudo" about interwiki prefixes such as d:, b: etc. — This, that and the other (talk) 00:52, 20 February 2014 (UTC)[reply]

• Yes, it's technically an alias. An alias that there's no need for. The interwiki prefix is "commons:" adding a an alias to this prefix, especially one this ambiguous, isn't a good idea. That's just my opinion, and other opinions may vary. — ((U|Technical 13)) ^{(t • e • c)} 01:03, 20 February 2014 (UTC)[reply]

• I think you're confusing things a bit here Technical13. As far as I know, there are no "interwiki aliases" in existence; the presence of c: is just as arbitrary a prefix as commons: is, like the non-distinction between m: and meta: prefixes. There are however two versions of the interwiki map, one which is hardcoded into the MediaWiki software at Special:Interwiki and another which is human-editable at meta:Interwiki map. On meta:Talk:Interwiki map which is the talkpage for the human editable version, there was also some discussion among the developers about abolishing the interwiki map entirely, given how troublesome they seem to have been over the years, blocking legitimate titles etc. TeleComNasSprVen (talk • contribs) 07:46, 20 February 2014 (UTC)[reply]

  T13, if you do not understand the interwiki map and related scripts, you can ask TTO or me for help. TTO has really been helping with interwiki prefix maintenance recently, and I've been the most active Meta admin involved in 2013 (since I was an admin)/2014. I do not think you understand how interwiki prefixes work, but I may be wrong. πr² (t • c) 22:30, 20 February 2014 (UTC)[reply]

Adding: an alias is not a pseudo. Aliases are encoded (set) in wiki software, while pseudos are only a users convention (possibly in an unrelated namespace). -DePiep (talk) 12:03, 21 February 2014 (UTC)[reply]

• I still think a procedural close is the right thing to do here. Would anyone seriously insist on keeping these if there's consensus for the Commons proposal (as appears likely)? And if there isn't, there's really nothing to discuss, though of course these redirects can still be discussed in the future for other issues. --BDD (talk) 17:23, 24 February 2014 (UTC)[reply]

That would bypass all other arguments. Then you want them discussed one by one? -DePiep (talk) 21:40, 24 February 2014 (UTC)[reply]

The redirects were nominated here on the basis of a discussion on meta. If that discussion does not lead to consensus to introduce C: as an interwiki link then the nomination is without a reason. If you still want them deleted then you will need to renominate them based on other reasons. Whether you do that individually or as one or more groups is entirely up to you, but do look at the way previous discussions have gone when making a decision (and note that there was not consensus for wholescale deletion in any of them). To make it clear I fully support a procedural close with another pointer to meta. Thryduulf (talk) 01:13, 25 February 2014 (UTC)[reply]

Why should other arguments not be allowed? Since you, Thryd, are even closing RfD's, it is worrying that you have this attitude. (what you say is: !vote!). On top of that, you talk for me (ouch) while abusing my written & quotable argument here. That's two points against you. I suggest you withdraw both wrong statements to show that you get the logic. -DePiep (talk) 06:29, 25 February 2014 (UTC)[reply]

Of course other arguments are allowed, but they have to actually be presented before they can be considered. As BDD notes above, this discussion is tied to the one on meta - if there is global consensus to use C: as an interwiki prefix then this discussion is irrelevant. If there is no such global consensus then the reason for deletion presented in this nomination (to allow c: to be used as an interwiki prefix) is not relevant. If people want to express an opinion about the use of C: as an interwiki prefix they need to do so on meta, not here. I have literally no idea what you even mean by the rest of your comment. Thryduulf (talk) 10:04, 25 February 2014 (UTC)[reply]

Nothing merits your snarky editsummary [1]. -DePiep (talk) 11:29, 25 February 2014 (UTC)[reply]

That wasn't snarky, that was just a comment by Thryduulf that he didn't understand all of your argument. AGF a bit more - try reading it as a request that you rephrase your reasoning. — Scott • talk 11:38, 25 February 2014 (UTC)[reply]

Indeed, no snark intended at all. Merely an accurate summary of my edit to this page. Thryduulf (talk) 12:23, 25 February 2014 (UTC)[reply]

Scott Martin Just a comment? That is was a question is your reading. Thryd did not ask anything. Not even after your cmt here. See also my next cmt #1 (and #2) BELOW. -DePiep (talk) 09:30, 26 February 2014 (UTC)[reply]

Thryduulf, re your 01:13 cmt.

1. "Whether you do [renominate] individually or as one or more groups is entirely up to you" -- A suggestion of coordinated edit? Are you saying that I am rigging a discussion? Withdraw that. (Or, theoretically possible, prove it).

2. "If you still want ..." - this is a bad reading of my cmt here. Then drawing conclusions from that bad rephrasing is misleading. If you cannot represent my statement correctly, then don't re-phrase it at all. One could just ask for clarification. Also, you rephrase BDD here "As BDD notes above, this discussion is tied to the one": the stronger wording "is tied to" is not used by BDD, and is a shift in intention, again building a conclusion on a misquote.

3. "If that discussion [at meta] does not lead to consensus [...] then the nomination [here] is without a reason". The nomination is here, and there are no arguments barred. Once nominated, the discussion cannot be nullified. It could be that one argument presented (even in the nom) is less valid, still the XfD must consider the whole discussion including all arguments presented. It is not up to you to put the discussion content aside for your individual reasons.

As long as a closing admin can see your faulty logic, this is no problem as it is just a commenters opinion. But you also close XfD's. And in that capacity you should not impose this incorrect reasoning, corrupting the process. This time you say explicitly to discard the discussion unread. Already earlier last November you applied this implicitly, which caused an editor to say I also can't help but feel you didn't really read through the discussion [2], (I seconded that [3]). Discarding the discussion this way is not a freedom of the closer. It is this applied attitude I object to.

4. "do look at the way previous discussions have gone when making a decision" -- I just did. Both here and in November (as a closer) you are paternalistically saying how the XfD process should go, unbased in guidelines or reasoning. That is a prejudiced approach.

5. In your 10:04 comment here, you repeat your paternalistically approach, you repeat that you have not read my comment or !vote here, and you did think formulating a question for clarification, or even a suggestion to that. Really, "Of course other arguments are allowed, but ..." says it all: you did not read the discussion, and then prescribe others how to proceed. Here it is just some reasoning, but in a closing process this is unacceptable.

6. Concluding, I request you address #1 and after #3, #4, #5 you start showing an open mind to XfD discussions instead of inventing your own process while skipping the discussion. -DePiep (talk) 09:30, 26 February 2014 (UTC)[reply]

1. Eh? When nominating multiple redirects (or articles, templates, etc for that matter) there are three possible ways to do it - individual nominations, one nomination that includes all the redirects, or several nominations of smaller groups of them. That is a simple statement of fact. I'm not accusing you of anything.
2. If this discussion is procedurally closed (as I believe it should be but I think you don't, it's hard to tell) then, if you still want them deleted you will be free to renominate them but, in those circumstances, a renomination by you or someone else will need to happen. If you don't want these deleted then I really have no idea what your statements mean. I do not see how my statement about how this relates to the discussion on Meta differs from that made by BDD? Please could you explain.
3. You appear to be confusing the reasons you gave to delete these redirects with the reasons given by the nominator. The nominator said "Pending the resolution of this requests for comments meta:Requests for comment/Wikimedia Commons, these administrative category redirects need to be deleted before the C interwiki prefix for Commons Wiki can be implemented." The RfC on meta has been restarted/reopened. If the resolution of the current discussion there is that C: should be implemented as an interwiki link then these must be deleted to enable that. If the resolution of that discussion is that C: should not be implemented, then the nomination statement provides no reason to delete these. You have presented different arguments, and if the closer feels that other commenters have considered these and formed a consensus to delete for that reason then they may close as delete based on that. If the closer feels that they have not been considered by others then they will not close the discussion based on them. Procedural closes are perfectly valid closures, and there is nothing to stop an uninvolved administrator performing one if they believe (as BDD and I do) that it is correct.
4. Please assume good faith. Just because I close some XfDs does not mean that my views hold more or less weight in discussions than those of people I don't. I am offering suggestions that people are free to treat as they wish. My point was simply that we have had recent discussions on these sorts of redirects that have not reached a consensus, so simply repeating the same arguments in the same way is unlikely to result in consensus this time.
5. I really have no idea what you are on about here.
6. I am not inventing any process at all. I am free to express my opinions in the same way you are. You are free to disagree with them, but that does not mean you get the right to tell me to stop expressing them. Thryduulf (talk) 09:59, 26 February 2014 (UTC)[reply]

1. Argh! Misunderstood, I read it meaning "You individually or as a group doing ...". Clear now. Struck.

2. You repeat your misquote "if you still want to delete them": that was not my statement, and so cannot be "still". There cannot even be an "if ... still". You misquote and then build conclusions from that: stop it. About you using BDD I wrote the "tied to" issue. BDD did not use that verb. I don't see what is unclear about that.

3. In an XfD I am free to add other arguments than the nom does. Those arguments must be handled and may not be discarded beforehand just because you feel like that. As an opinion you are free, but as a closer that is a manipulation. Simplified, I say: the proposed page is the topic. Or can you point to a guideline that restricts argumentation beforehand as you say?

3b: you base you procedural closure point on the statement that if nom's reason fails, and then further arguments do not matter. No way: just your opinion about that argument. not procedural at all. Just content reasoning.

4. AGF - yeah, sure. I actually point to your replies that show you did not read nor process. This #4 for example, is again about you are telling others what to to & what to conclude. If I read a duck, I can call it a duck.

5. Telling others what they should do, without having a base, is paternalistic. You can keep not hearing this point, but I can repeat it. As an opinion go ahead. As a closer, no right to do so (even worse: my November link shows you did so after the discussion, closing saying like 'It was not as I expected, so I skip things as I like').

6 (and 4.): The problem is, as I described: in a discussion go ahead, but as a closer such reasoning is a manipulation of the discussion. Afterwards using closer's power. That is unacceptable.

-DePiep (talk) 12:37, 27 February 2014 (UTC)[reply]

• Keep all for now. No reason to delete them unless c: becomes a commons: shortcut. And if it does, non-pseudonamespace redirects will have to be deleted as well (C:\WINDOWS is such an example, and the biggest problem is C:Real, an actual article). C:CSD has not been tagged for deletion, and so should not be deleted at all at this point. I would prefer not to see it tagged, as I use it daily. Anyway, this discussion is a bit useless. Either c: is implemented as a commons: shortcut (in which case C:Real has to be moved and all other pages at Special:PrefixIndex/C: should be deleted as WP:CSD#G6 non-controversial maintenance before they become inaccessible to normal admins), or it isn't, in which case no valid reason for deletion exists. —Kusma (t·c) 19:37, 26 February 2014 (UTC)[reply]
• Keep all, close discussion and reassess later. This discussion is going round in circles, and will not be resolved until a separate debate comes to a decision about use of c: for Commons. Until then, close this discussion, remove the tags from the redirect pages (I want to get back to using the shortcuts) and then reopen the deletion debate if necessary. Declaration - I created the C:ATT, C:NNSD and C:SPAM shortcuts. Stephen! ^Coming... 10:23, 27 February 2014 (UTC)[reply]

• I personally think that this is the best way to have notified the English Wikipedia community, which is perhaps most affected by this change. The closure and determination of the RFC on Meta is dependent on the decision for what to do with these redirects here. If we leave them as is and the software rolls over to allow C as commons iwprefix, then we have to clean up and deal with the mess later rather than deciding now whether their interference with Commons is sufficient enough to delete them. In the Meta-Wiki RFC, I wrote (diff) that the RFC is like, for all intents and purposes, a Wikimedia-wide "deletion discussion" for all page titles prefixed with C, as they are rendered unavailable in the software not only to outside readers but also to community members, editors and admins alike. Whereas the "deletion" function on a wiki simply hides the content of a pagetitle from readers and editors, changing up an iwprefix not only does the same thing but also hides it from administrators (and perhaps oversighters) as well, effectively replacing their entire content with a wikilink to Wikimedia Commons instead. The caveat however is that Meta Wiki cannot by design override the consensus of local communities - which naturally means that this huge "deletion discussion" needs to be approved by each individual wiki, including English Wikipedia, before discussion can move forward. (Unless you naturally consent somehow to Meta Wiki overriding your use of C for category, and then dealing with the mess later. Either way, I would be just as happy turning C into a prefix for Commons.) Also, please do provide your opinion in the Meta RFC; it's very important that we gauge the consensus of each individual wiki and the consensus of the global Wikimedia community quite fairly. TeleComNasSprVen (talk • contribs) 05:24, 28 February 2014 (UTC)[reply]

At least we could decide now & here to deprecate the C: prefix. That is: leave the existing ones alone (in general), but don't advertise, don't use in shared spaces (say outside of userspace), and don't create new ones nor new addictions. Especially: don't guarantee or promise any future existance. Apart from the meta discussion, this aligns with (my) objections that next to CAT: a "C:"-variant page does not help as a shortcut. -DePiep (talk) 05:40, 28 February 2014 (UTC)[reply]

That sounds like a good solution. This is after all a redirects for discussion page and there are alternatives to outright deletion. TeleComNasSprVen (talk • contribs) 06:44, 28 February 2014 (UTC)[reply]

I oppose deprecating the C: prefix without need. Sure, it saves me only two keystrokes, but it does no demonstrated harm. —Kusma (t·c) 09:14, 28 February 2014 (UTC)[reply]

As explained, deprecation is a keep. They will stay. The "need" is to prevent future problems, mainspace pollution with non-content and creating new addicts.

And there is harm. Creating a C: variant next to a CAT: redirect, sometimes, defies the essence of a shortcut: an easy to remember route. Introducing that variant adds a load to the easiness: was my shortcut in C:? For this harm (a mental load for the editor), this second pseudo-ns is to be prevented. It is a source for editor's frustration. That is a harm. -DePiep (talk) 10:43, 28 February 2014 (UTC)[reply]

• Keep - I use C:CSD ten times a day. It's ingrained in my muscle memory. If it conflicts with Wikimedia Commons, delete Commons, which ain't that helpful anyhow. WilyD 10:09, 28 February 2014 (UTC)[reply]
  • Note too, that a notice wasn't added to C:CSD until yesterday night, which is why I didn't notice this blatantly inappropriate request until now. The same appears to be true of at least some of the others. This request should be left open until at least March 6th to ensure community input, rather than allowing a terrible, terrible, terrible proposal to be snuck past the community by stealth. WilyD 11:00, 28 February 2014 (UTC)[reply]
    • There is no problem extending the deadline for this discussion. I only added the tag recently because I had no easy way earlier to mass tag the affected redirects to point to this discussion, and I do not have AWB access to do so. I'm not trying to sneak this proposal past anything, so please don't accuse me of that. TeleComNasSprVen (talk • contribs) 16:49, 28 February 2014 (UTC)[reply]
• Speedy keep all per Kusma and Stephen Buxton, until any decision about using C: for Commons makes it actually necessary to delete. Meanwhile, close this discussion a.s.a.p. and remove the ((mfd)) tags: some of these are widely used and it is a substantial inconvenience to have them suddenly disabled. I agree with WilyD - I use C:SD constantly. No objection to deprecating C: redirects to discourage the creation of more, but existing ones should not be removed until necessary. JohnCD (talk) 12:44, 1 March 2014 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page.

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was deleted to make way for move. — Scott • talk 17:07, 16 February 2014 (UTC)[reply]

• Turkish Naval Forces → Turkish Navy (links to redirect • history • stats)     [ Closure: keep/delete ] 

Need this redirect page deleted so I can move the Turkish Navy article to the title currently held by this redirect. Thanks for the help. Antiochus the Great (talk) 15:39, 16 February 2014 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page.

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was BOLDly retargeted to Windows 2000. — Scott • talk 17:11, 16 February 2014 (UTC)[reply]

• Safely remove hardware → Features new to Windows 7 (links to redirect • history • stats)     [ Closure: keep/delete ] 

This has been around since Windows 2000 � (talk) 13:36, 16 February 2014 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page.

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was delete. --BDD (talk) 17:08, 24 February 2014 (UTC)[reply]

• Chazwozzer → American bullfrog (links to redirect • history • stats)     [ Closure: keep/delete ] 
• Chazwozza → American bullfrog (links to redirect • history • stats)     [ Closure: keep/delete ] 

This is nothing but a one-line joke from one episode of The Simpsons, in which episode the word is not even spelled out (so you see it quoted as "chazzwozzer", "chozwozzer", etc.) Moreover, this redirect is causing nonsense to appear in resources that scrape Wikipedia blindly [4]. I realize that the solution for such sites is not to do that, but we should also delete the problematic redirect here. 172.9.22.150 (talk) 01:14, 16 February 2014 (UTC) Update: Added the similar redirect Chazwozza to this nomination. 172.9.22.150 (talk) 22:14, 16 February 2014 (UTC)[reply]

• Delete. If the word actually had any coverage in the article as a topic, like cromulent does in Lisa the Iconoclast, it would be worth keeping, but as the nomination states, it's a throwaway joke. As it doesn't even have a defined spelling, this redirect is original research. — Scott • talk 17:18, 16 February 2014 (UTC)[reply]

Procedural note: This comment was made before the Chazwozza redirect was added to the original nomination. 172.9.22.150 (talk) 22:14, 16 February 2014 (UTC)[reply]

Thanks, I apply the same reasoning to both now. — Scott • talk 18:44, 17 February 2014 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page.