Requests for comment/Wikimedia Commons interwiki prefix

The following request for comments is closed. The 2011/2012 RFC did not show clear global consensus for linking the "C" prefix to Wikimedia Commons, and there were two main issue with it: the lack of participation (only 23 editors) failed to convince MediaWiki developers that the change was necessary, and there was lack of notice given to wikis currently using the prefix for their own reasons, leading to the appearance of Meta overriding local consensuses before consulting with individual wikis. That was the basis for restarting the 2014 RFC, which solved those two issues and provided a much clearer representative of where the actual global consensus lay, with a not insignificant number of opposers in the mix.

Nonetheless, when considering also the amount of supporters in the previous RFC, there is a clear (84%) consensus favoring implementation. Though individual opposes were raised, at least there has not been an entire local wiki community objecting to this proposal, and Meta still strives to factor in the input of independent local communities as much as possible without overriding them. Among the concerns raised were conflicts with existing page titles used by local communities and a lack of readability. There was also side discussion about implementation of "com" as a possible alternative prefix, but due to the conflict with a Comanche Wikipedia and its irrelevance to this discussion, it was not considered as part of this RFC. The first concern has largely been resolved thanks to the efforts of those below in the "next steps" section; and for the second concern, I would strongly discourage overusing the "C" prefix in favor of the "Commons" prefix to newcomers. With over one hundred participants in several different language editions and wiki projects, this RFC concludes with implementation of bugzilla ticket 4676. A great thanks to everyone who commented. TeleComNasSprVen (talk) 01:42, 27 March 2014 (UTC)

---

I propose the creation of another interwiki prefix, "c", to our database for Wikimedia Commons. The prefix is been used, but not actually leading to Wikimedia Commons. It would minimize inacuracies, and for some, make the use of interwiki usage easier. For those who do not understand, it will serve the same purpose as the "commons" prefix in any case.  Hazard-SJ  ±  05:04, 31 August 2011 (UTC)

Proposal to add a "c" interwiki prefix for Wikimedia Commons

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

bugzilla:4676 reopened. Tiptoety ^talk 18:56, 4 January 2012 (UTC)

---

• The c: prefix doesn't seem to be currently in use at all. — Kudu ^~I/O~ 20:18, 1 September 2011 (UTC)

• This was discussed somewhat in bug 12600. See bugzilla:12600#c20 for a larger explanation of why this schema might not work. Killiondude 06:33, 18 September 2011 (UTC)

• This RfC is about bugzilla:4676 (Interwiki prefix c: could be used as a shortcut for commons:) which was closed as WONTFIX, and bugzilla:14448 (Bypassing an interwiki redirect), also closed WONTFIX. There are three pages on English Wikipedia which start with "c:", and many redirects starting with "c:", so these need to be addressed before this can be resolved. John Vandenberg 07:22, 24 November 2011 (UTC)

  I have started a discussion at w:Wikipedia:Village pump (miscellaneous)#commons interwiki about the English Wikipedia problems. --John Vandenberg 08:26, 24 November 2011 (UTC)

  I have searched all Wikipedias with 10,000+ articles and besides English Wikipedia there are three articles (fi:C:enter:pound, pound, pound, ru:C: The Contra Adventure and el:C:Real) and redirects at ja, pt, sv, ro, simple, ceb, and bn. These will need to be renamed or removed before this proposal can be implemented. John Vandenberg 06:53, 28 November 2011 (UTC)

Support (2011)

1.  Support -- Hazard-SJ  ±  05:04, 31 August 2011 (UTC)
2.  Support--^Email Vaibhav ^Talk 07:33, 31 August 2011 (UTC)
3.  Support. Considering this hasn't been already implemented, is there some technical reason that would nix it? — Huntster (t • @ • c) 23:43, 31 August 2011 (UTC)

   No. — Kudu ^~I/O~ 20:19, 1 September 2011 (UTC)

4.  Support, why not? — Kudu ^~I/O~ 20:19, 1 September 2011 (UTC)
5.  Support we do have m: and [[:meta:]], so why not c: and commons:. Bennylin 06:41, 2 September 2011 (UTC)
6.  Support, could be useful (not in use according to Interwiki map). VIGNERON * ^discut. 14:17, 3 September 2011 (UTC)
7.  Support, seems reasonable and would shorten manual typing. --Túrelio 22:26, 17 September 2011 (UTC)
8.  Support - good idea - Jcb 22:35, 17 September 2011 (UTC)
9.  Support - oh yeah, that's a good idea (sparing some typing work and links like Commons:Commons:Village Pump). Grand-Duc 01:46, 18 September 2011 (UTC)
10.  Support - A.Savin 06:06, 18 September 2011 (UTC)
11.  Support I wld lk ths chc. --99of9 06:20, 18 September 2011 (UTC)
12.  Support Excellent idea. mickit 06:57, 18 September 2011 (UTC)
13.  Support Why not? /Esquilo 10:02, 18 September 2011 (UTC)
14.  Support Unless someone can come up with some reason not to. I don't believe any other projects start with c (and various language Wikipedias always use two letter codes). Dcoetzee 13:03, 18 September 2011 (UTC)

    Not "always". Some use three, and I know that the Simple English Wikipedia (simple) uses six :) 216.10.218.17 06:19, 4 October 2011 (UTC)

    The two and three letter combinations should be reserved for w:ISO 639 codes. simple is special ;-) John Vandenberg 21:45, 11 October 2011 (UTC)

15.  Support --Gavin.collins 08:33, 19 September 2011 (UTC)
16.  Support as per nom and Bennylin. --Skeezix1000 19:45, 22 September 2011 (UTC)
17.  Support Good idea. hiwiki will be affected. English Wikipedia has only three articles which will be affected. en:C:enter:pound, pound, pound, w:C: The Contra Adventure and w:C:Real, and the name of en:C:enter:pound, pound, pound is already a problem because of other technical limitations. John Vandenberg 04:55, 24 September 2011 (UTC)
18.  Support we have "m" for "meta" and several other one char abbrevs to sister projects, why not have "c" for "commons"? a×p_de^Hello! 19:13, 11 October 2011 (UTC)
19.  Support --Microcell 19:50, 11 October 2011 (UTC)
20. Support, per my comment below. Ajraddatz (Talk) 00:27, 12 October 2011 (UTC)
21.  Support, seems like a good idea, problem at hiwiki has been addressed below. --Philosopher ^{Let us reason together.} 22:47, 23 November 2011 (UTC)
22.  Support Please. I'm tired of typing out [[:Commons:Commons:(Policy name)] to link files. WhatamIdoing 03:32, 27 November 2011 (UTC)
23.  Support --Guerillero 19:22, 13 December 2011 (UTC)

Oppose (2011)

Moved to support. Why not? Because it could conflict with the c: prefix on larger wikis that use it for category. Ultimately, it makes more sense to allow the larger wikis to continue with that, considering that there is more of a need to locally link to a category than there is to link to commons IMO. Ajraddatz (Talk) 16:38, 20 September 2011 (UTC)

I think only hiwiki uses 'C' for category; everyone else uses 'CAT'. See InitialiseSettings.php. John Vandenberg 04:22, 24 September 2011 (UTC)

Thanks for that - if it is only hiwiki, and they would be willing to modify their C, then I'd support this proposal. Ajraddatz (Talk) 04:55, 24 September 2011 (UTC)

Informed some of the hindi Wikipedians. Waiting to hear from them. -- Tinu Cherian - 05:11, 24 September 2011 (UTC)

This array setting was proposed by me and approved by the community however I don't think that Hindi wiki community will object this change, I have no issue with this--Mayur ^{(talk•Email)} 17:01, 24 September 2011 (UTC)

Thank you Mayur. Could you find the bugzilla for the Hindi Wiki configuration change? John Vandenberg 05:07, 25 September 2011 (UTC)

The configuration change is bugzilla:29940. --John Vandenberg 22:50, 11 October 2011 (UTC)

Thanks; I've changed to support per my comment above. Ajraddatz (Talk) 00:26, 12 October 2011 (UTC)

Neutral (2011)

1. • "The prefix is been used, but not actually leading to Wikimedia Commons". Where is it used, and how, leading to where? If the prefix is already leading somewhere, and you change the destination, then the change will cause confusion.
   • What is better with ":c:" than with ":commons:"? On the one hand ":c:" is quicker to type, but on the other hand, its meaning is more difficult to understand. So, all in all, the longer one could be better. Teofilo 13:51, 31 August 2011 (UTC)

     Teofilo, for Meta-Wiki, we have both m and meta Are you saying "m" is difficult to understand too?  Hazard-SJ  ±  21:43, 31 August 2011 (UTC)

     Considering we use en: and not english: for english Wikipedia I don't think c: would be more difficult to understand? /Esquilo 10:02, 18 September 2011 (UTC)

2. The reason pointed out in the bug is that "c" may also be used for Categories on various projects and this change would break those existing links. --Philosopher ^{Let us reason together.} 06:43, 19 September 2011 (UTC) Concern addressed above. --Philosopher ^{Let us reason together.} 22:42, 23 November 2011 (UTC)
3. I think the last time this proposal was rejected because it conflicted with Wikia syntax. Is this no longer the case? -- Liliana • 16:28, 20 September 2011 (UTC)

   It is not longer the case, and I also think that what Wikia does should not be any concern of ours, and should certainly not be considered in a proposal like this. Linking to commons is far more important on Wikimedia than linking to a Wikia site. Ajraddatz (Talk) 16:36, 20 September 2011 (UTC)

4. I'm mostly interested in non-Wikimedia MediaWiki projects. It's rather confusing when I have to use m:, w:, and mw: vs. metawikipedia:, wikipedia:, and mediawikiwiki: depending on the wiki. It is also not nice for portable templates. –mw:Be..anyone 89.204.137.235 09:40, 21 September 2011 (UTC)

   Both interwiki links can be used, and there are even more (e.g. [[:meta:]]). The one char links are for those using them frequently. a×p_de^Hello! 19:19, 11 October 2011 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Necessary distinctions and portability

1. metawikipedia: does not exist anywhere. meta: works everywhere... except on MetaWiki otself because it is used as the local name of the "project:" namespace (and abbreviated in the root namespace using shortcut redirect pagenames starting by "MW:")). That's why we need "m:" as it is portable.

   wikipedia: seems to work as well everywhere as an interwiki link... except on Wikipedia itself where it is also the local name of the "project:" namespace (and abbreviated in the root namespace using shortcut redirect pagenames starting by "WP:"). That's why we need "w:" as it is portable as the interwiki prefix.

   wiktionnary: seems to work as well everywhere as an interwiki link... except on Wiktionnary itself where it is also the local name of the "project:" namespace (and abbreviated in the root namespace using shortcut redirect pagenames starting by "WT:"). . That's why we need "wikt:" as it is portable as the interwiki prefix.

   wikidata: seems to work as well everywhere as an interwiki link... except on Wikidata itself where it is also the local name of the "project:" namespace (and abbreviated in the root namespace using shortcut redirect pagenames starting by "WD:"). . That's why we need "d:" as it is portable as the interwiki prefix.

   commons: seems to work as well everywhere as an interwiki link... except on Commons itself where it is also the local name of the "project:" namespace (and abbreviated in the root namespace using shortcturs starting by "WC:"). . That's why we will need "c:" as it is portable as the interwiki prefix.

   In summary, we need a short interwiki code distinct from the full name of the wiki itself, to make the distinction with the local aliased name of the "project:" namespace.

   verdy_p (talk) 00:24, 23 February 2014 (UTC)

2. About the rare current usages in page names: we can still rename the pages using a wide ideographic version of the colon for the effective name: plain text searches (tested in external Google or in local CirrusSearch engine) will continue returning the name when searching for "C:xxx" (due to its Unicode "compatibility equivalence" and mappings of the its collation algorithm, aka UCA). The wide ideographic colon is very well supported in fonts on lots of systems. The wide ideographic colon looks like a standard colon followed by a space, or could look like a colon centered in a square. Most users won't notice the difference. But most often, these page names don't need the "C:" prefix in their name. If the C letter is effectively significant, the colon may be replaced by an hyphen if one wants to ease its input (but it will redirect to the name using the wide ideographic colon, so the page's title will display correctly. verdy_p (talk) 02:01, 23 February 2014 (UTC)

Can you link to a demonstration of a CirrusSearch query with a regular colon returning a page using the fullwidth colon (：) in its title, please? — Scott • talk 14:32, 26 February 2014 (UTC)

Sure. testwiki:Special:Search/m：RFC is with fullwidth colon. Note that creating this page also makes testwiki:Special:Search/m:RFC (with regular colon) return the correct result. See also [1]. PiRSquared17 (talk) 16:15, 26 February 2014 (UTC)

Cool! That would probably be an acceptable compromise for the only "C:" article on enwp, C:Real. — Scott • talk 17:26, 26 February 2014 (UTC)

2014 Post-closure discussion

Temporarily reopening ticket. The C: prefix is still being used on hiwiki, creating interwiki and namespace-prefix conflict, see hi:Special:PrefixIndex/C: which automatically gets redirected by the MediaWiki software to hi:Special:PrefixIndex/श्रेणी:. As Mayur seems to be retired, I've posted a notice to the hiwiki community on what is hopefully their village pump, linked from the English Wikipedia' Village Pump in the interwiki sidebar on the left. If anyone could find another way to contact the hiwiki admins, perhaps through email, and preferably find one who can speak English and comment here, it'd be much appreciated. Or find some way to resolve this issue. TeleComNasSprVen (talk) 23:28, 7 February 2014 (UTC)

A proposed re-opening of this closed RfC was reverted by me and discussion moved to Talk:Requests for comment/Wikimedia Commons interwiki prefix. Discussion may continue there, or a new RfC started if there is a current issue or problem. --Abd (talk) 14:26, 12 February 2014 (UTC)

This RFC was closed in this revision 4 January 2012 by Tiptoety (talk · contribs) and was reopened again to allow the hiwiki community a chance to provide their commentary, as well as affirm the current state of affairs - that bugzilla tickets 61431 and 4676 have still not been resolved, pending consensus of the hiwiki community. Ticket 4676 has had some activity recently, with Mayur reaffirming his assent to the change proposed in 2011, and since we are close to a resolution, it's time to give hiwiki a chance. TeleComNasSprVen (talk) 21:38, 16 February 2014 (UTC)

Copied from 4676 comment #29:

I have told earlier when it was asked that C: prefix can be used for commons as it is not as much used in hindi wikipedia. Intead a prefix Cat: can be used. Regards Mayur (talk) 07:19, 16 February 2014 (UTC)

TeleComNasSprVen (talk) 21:38, 16 February 2014 (UTC)

The hiwiki community has given their consent, but according to this report generated by PiRSquared17, it seems the change would likely disrupt the functioning of plenty of other wikis. Therefore, the scope of this RFC has shifted focus from the hiwiki community to attention on the more global Wikimedia community and their response to this issue. TeleComNasSprVen (talk) 03:18, 18 February 2014 (UTC)

Some meta-discussion is found at Talk:Requests for comment/Wikimedia Commons interwiki prefix
transclusion of 42 kb talk page removed, link is adequate --Abd (talk) 22:10, 18 February 2014 (UTC) @Abd: before you remove this again, I recommend you do a study of how many Meta RFCs have talkpages, with comments about the RFC process, compared to how many comments about the RFC itself are placed directly on the RFC page itself. TeleComNasSprVen (talk) 20:50, 18 February 2014 (UTC) I removed the above, because it adds nothing, it's discussion of this page, already, as a Talk page attached. How many pages, of any kind, have their talk pages transcluded to them? In this case, it makes the page much larger for download, a problem with mobile devices. This page is ostensibly 22,700 bytes. With the transclusion, another basic 42,000 bytes are added. When I wrote comments on the Talk page, it was explicitly not to be included in the RfC itself. Talk is about the RfC, not argument in it. In addition, the transclusion will incorporate all new discussion. Why even have a talk page? Since TCNSV reverted my removal, I'm requesting an independent decision. --Abd (talk) 21:25, 18 February 2014 (UTC) Since the collapse was not signed, I edited it, to remove collapse and simply refer to the Talk page, as a now-signed comment. --Abd (talk) 22:10, 18 February 2014 (UTC) I'm going to explain it again: Comments about the propriety of the RFC discussion should be shown on the RFC page for transparency, and not relegated to the obscure talkpage hidden away where no one will see it. In this case, it gives more context to the processes behind reopening the RFC. I recommend you do one of your 'studies' on how many meta-discussion comments about the RFC process belong on the RFC page itself, versus belonging on the RFC's talkpage. TeleComNasSprVen (talk) 22:42, 18 February 2014 (UTC) The transclusion was reverted independently, and TCNSV accepted that.Commons interwiki prefix&oldid=7552639#Transclusion_of_this_talk_page_into_the_RfC_page

• As this discussion relates to Wikimedia Commons, I've notified their users of its existence. To attract more participation from users on this wiki, I've added it to Goings-on and Talk:Interwiki map. — Scott • talk 16:30, 19 February 2014 (UTC)

Procedurally, announcing this on Commons, where users might be more expected to favor the change, isn't neutral. Some effort should be made to notify users on wikis with a c: conflict. En.wiki on the RfD page is probably not enough. My idea was a fresh RfC to seek comment, globally announced, after we are quite clear on details of implementation and can present a complete picture. But this, here, might be enough. The proof is in the developer pudding. --Abd (talk) 21:21, 19 February 2014 (UTC)

I don't think it's reasonable to discuss a major technique for linking to a particular project without involving that project's users. The nature of our system is also such that users of one project are often users of the other; the people making these links are going to be Commons users as often as not.

I agree that efforts should be made to notify users on wikis where conflicts exist. On the English Wikipedia, I've left a note at at the Village Pump advising users of both this RfC and the RfD discussion. — Scott • talk 22:50, 19 February 2014 (UTC)

Did the 2011 RfC have enough participation to rate the outcome as consensus?

Let's just put this theory to the test. Who here would agree that 23 editors is considered enough consensus for a sitewide developer-level configuration change on the English Wikipedia? Who here would also agree it's enough for a global community consensus for a Wikimedia-wide developer-level configuration change affecting the English Wikipedia and then some? TeleComNasSprVen (talk) 12:52, 19 February 2014 (UTC)

Theory: "23/23, with global participation, is strong evidence of global consensus."

Comments made so far in bugzilla:4676 suggesting otherwise, that this is not strong consensus, nor by extension global consensus, at all:

I very strongly oppose the developers actioning this change until there is evidence of a much stronger community consensus than just 23 people two years ago (in a discussion that does not seem to have been massively advertised) and the non-objection of one person on one project.Much stronger evidence of consensus has typically been required for less significant changes that affect only one project (the addition of a new namespace at en Wiktionary for example). --Chris

That RFC probably needs to be reopened; 23 editors should not decide the fate of the Wikimedia Community, which Hindi Wikipedia is a large player of, before requesting such a change. --TeleComNasSprVen

TeleComNasSprVen (talk) 13:06, 19 February 2014 (UTC)

• original text, to which others responded specifically, restored in strike-out --Abd (talk) 20:43, 19 February 2014 (UTC)
• The user reverted that correction. The original signature above, at the end of the block quote, was not "TeleComNasSprVen" but "Alexander." With that altered, and without this note, the comments below by Scott and me, now in collapse, would make no sense. --Abd (talk) 00:02, 20 February 2014 (UTC)

It's even possible for Meta admins to add interwikis without asking devs, but I agree we should do it the same way d: etc. are defined. PiRSquared17 (talk) 13:21, 19 February 2014 (UTC)

discussion of the 2011 RfC result and "consensus."
In case it's not obvious to you or other editors, "Chris" is Thryduulf. But "Alexander" is... TeleComNasSprVen. Who are you trying to fool? — Scott • talk 14:15, 19 February 2014 (UTC) [...] anyone who doesn't investigate carefully. The actual comment does not have "Alexander" in it, the name was supplied in this edit here by TCNSV. Is 23 editors enough? That depends on a number of factors not stated: 23 out of how many? Was the global community represented in the 23? What is the opposition? In the original RfC, there was some opposition expressed, but completely withdrawn as satisfied. Then there is a structural issue here: what if there is a global consensus, expressed here at meta -- which is where global consensus is sought and expressed -- and developers don't respond? One of them closed the request based on a personal opinion, and no developer objects, however, the request was re-opened promptly. I know what we do, but I'm not going to do it myself. The first steps, however, were done. See Bugzilla:4676, and [ Request history]. This much is clear: 23/23 (not just "23") was quite enough to claim global consensus, and make the request on Bugzilla. At that time, if more support or discussion were needed, it could have indeed been requested by providing site message link to this RfC. It is doing this two years later that is a problem. The solution is clear: either convince developers to implement this, as-is, which seems possible in short order, with a little patience, or, if that route fails to complete, create a new RfC, a clean one, ready for, essentially, a vote, having considered all reasonable issues previously, and reporting the results of that consideration, and site-message it on all the wikis. Most of this discussion would normally be on the Talk page, not cluttering up the RfC, but TCNSV revert warred and disrupted attempts to move post-close discussion to Talk, so the RfC has become more of a train wreck. All of the legitimate purposes of this "re-open" were easily accomplished with Talk discussion and other actions. The attention to the unresolved issue is appreciated. The disruptive actions to force this are not. --Abd (talk) 15:01, 19 February 2014 (UTC) Chris (Thryduulf) is not responsible for TCNSV's abuse of his comment, which contained factual error. I assume that Chris, at that point, had not reviewed all the comment here, which showed that it was not only one hiwiki user who had consented, but two or three, and evidence was shown that hiwiki had formally been notified of the proposal. At the time TCNSV re-opened this RfC, he cited the hiwiki problem as the reason to re-open. When that was shown to be spurious, he then found another problem. This re-opening was a solution (TCNSV's action) in search of a justification (See! I was right! There is this -- new -- Big Problem!). There is no end to that. The Big Problem is a small one, and it was already known as an issue.[2] et seq. On enwiki, TCNSV -- properly -- began an RfD to consider the largest of the issues, redirects beginning with c:.[3][4] It is likely that deletion or soft redirect on Commons for such will need to be handled before implementation. (I.e, the big one is w:c:CSD, which could quickly become a page on Commons (Commons:CSD), as one proposed fix, that disambiguates to Wikipedia w:Category:Candidates for speedy deletion, to the Commons equivalent page, or other wikis if issues exist (note that the CSD redirect on Commons has no local incoming links), more quickly implemented than editing all the WP instances of the redirect, though the latter is only a few hours' work. --Abd (talk) 15:21, 19 February 2014 (UTC) Apologies, Scott. Was a tad sleepy and misplaced my name with someone else, did not mean to try to deceive anyone. Aye, that's what happens when you try to work on two documents simultaneously. Well, I think it's obvious to most people in this discussion that Chris was Thryduulf. Anyway, lesson learned. @Abd, I fail to see how that's "abuse" of Thryduulf's comment when it's been quoted verbatim. What "factual errors" were introduced that you feel the need to vaguely point at without specifying? TeleComNasSprVen (talk) 16:44, 19 February 2014 (UTC) Well, you asked for response. It's abuse because the comment was made early on, in another context, and he made an error, out of his newness to the issue, which you might know enough, if you have been paying attention, to recognize. But because you are looking for support for your position, you didn't point out the error, because it would make that comment look less powerful and clear. In fact, the placement of that opinion, with the different name, made it look like there was more support for your position than actually exists. As people are becoming aware of this RfC, you can see what's happening. And that's without banners. (I assume that banners would be discussed before being requested or used.) The entire line of conversation is irrelevant. All these comments would really belong on the attached Talk page, which I haven't done because of your behavior here, TelComNasSprVen or Alexander, whomever you are. I'm known in RL by "Abd Lomax". And I see that TCNSV has edited his comment, to which others responded. Not after response. I'll fix it, per traditions on that. --Abd (talk) 20:43, 19 February 2014 (UTC) Can we please discuss the topic at hand rather than discussing other users? PiRSquared17 (talk) 20:46, 19 February 2014 (UTC) Let's hope so. --Abd (talk) 20:59, 19 February 2014 (UTC) This entire "Neutral" section is not about the topic at hand. I would move it all to Talk if not for prior revert warring over similar, here. So I request that. --Abd (talk) 21:11, 19 February 2014 (UTC) Pending removal, I'm collapsing. Moving to talk is superior, because collapsed text must still be downloaded, inhibiting participation from mobile devices. --Abd (talk) 21:30, 19 February 2014 (UTC)

2014 RfC

Should c: be added as an interwiki prefix for Wikimedia Commons?

• This RfC ran from 18 February 2014 to 24 March 2014.

Reasoning

Pro

• c: is easy to type, and Commons is often linked to from other wikis.
• Will help to prevent the frequent mistake of users forgetting to type [[commons:commons:Page name]] by allowing them to type [[c:commons:Page name]].
• Not a frequently used namespace or namespace alias (see below).

Con

• c: conflicts with the Hindi Wikipedia's Category namespace alias which is not really used (bugzilla:61431).
  • The Hindi Wikipedia community has given their consent for it to be reassigned - see above.
• C: is used as a pseudo-namespace on the English Wikipedia for categories, and some other wikis.
• "C:" is used in various article titles (full list).

Support (2014)

1.  Support. No objections have been raised adequate to overturn the consensus of 2011. Tasks remain to be done, that's all, the removal of the c: -> category feature at hi.wiki, and, now, some conflicting pseudonamespace redirects on Wikipedia,[5] minor issues not requiring a global RfC. I reverted the re-opening here, revert warring maintained re-opening, and so I still ask for speedy close on substance and procedural grounds. --Abd (talk) 00:08, 18 February 2014 (UTC)

   Are you saying that post-closure comments like Thryduulf's should be considered invalid? Because he was late to the party, we should discount his opinion as having no weight? Well, I know that a latecomer to the discussion would consider that process a tad insulting. TeleComNasSprVen (talk) 05:40, 18 February 2014 (UTC)

   No, I'm saying that by revert-warring over maintaining closure, and digging elsewhere, you finally found a user to actually object to the closure, on an entirely new basis (i.e., pseudonamespace usage of c:, mostly for redirects, something fixable without developer intervention), which is not "adequate" to overturn that consensus. He has a right to his opinion, but could have expressed it at any time, then or now. If the Wikipedia discussion shows objection to this conclusion, then there would be something of weight. If not, it's simply an isolated user, who has the right to his opinion, as do I. I do not have the right to re-open old discussion fora, closed with consensus including consensus to close, just because I disagree. I have the right to re-open issues, until and unless the wikis reject me for it. --Abd (talk) 14:00, 18 February 2014 (UTC)

   I believe all editors should have the right to an opinion, whether an RFC is closed or not. And what better way to express that opinion than in the RFC page itself? Meta Wiki has no easy way for oneself to express dissenting opinions about the result of an RFC, therefore I'm providing him with such a way. TeleComNasSprVen (talk) 16:20, 18 February 2014 (UTC)

   Do you think this meta-discussion should take place here, on Talk:Requests for comment, on Meta:Babel, or even in its own meta-Meta-RfC? PiRSquared17 (talk) 16:40, 18 February 2014 (UTC)

   Small-scale discussion can and should take place in many places. One such place would be the talk page here. If support is gathered for reconsidering the consensus from 2011, then a new RfC for that purpose could easily be opened. Otherwise we are looking at implementation issues, for example the Redirects for deletion discussion on Wikipedia, and Bugzilla discussion. If developers want to see broader consensus, then a new RfC would also be filed, with a much better title than the one of this RfC (which gave people no clue as to the real topic), and it would be site-messaged, I'd say to all wikis (because all users will benefit, so comment should not just be targeted to wikis where there is a problem). Otherwise, my opinion, unanimity among 23 users, with substantial consideration for a year, notices on hiwiki, thought to be the only Wiki seriously affected, with plenty of enwiki user participation -- and, in fact, there is more impact on enwiki than anywhere, due to the pseudonamespace issue, was more consensus than usual for such discussions. What remains clear is that almost everyone who has considered it wants this change. PiRSquared, you have done some great work researching the extent of the real problem (pseudonamespace). The other problem is that developers have not been engaged, and I'm not sure why.

   However, this RfC has been re-opened, there is now comment in it. I still request speedy close, because I don't see any possibility that this is going to come up with a different conclusion. Not my call any more, though. --Abd (talk) 18:18, 18 February 2014 (UTC)

   @PiRSquared17: Well I did suggest something like that here. Meta-Meta-RFCs are a thing, you know. ;-) TeleComNasSprVen (talk) 20:41, 18 February 2014 (UTC)

2.  Support - I would have supported the original RfC if I'd noticed it in 2011. This is a deliciously natural complement to m: and w: - Commons is one of the Big Hitters and deserves a top-tier shortcut. Formalizing this shortcut would also neatly resolve the issue of whether we should allow "C:" pseudo-namespace shortcuts on the English Wikipedia (short answer: we shouldn't). As Abd notes on the talk page, the lack of opposition in the 2011 RfC should be a strong indicator that this is a good thing for us to do. — Scott • talk 17:44, 18 February 2014 (UTC)
3.  Support. Certainly makes more sense than w: leading specifically to en-wiki. - Jmabel (talk) 16:48, 19 February 2014 (UTC)

   Actually w: works based on the language of the project (although not for Meta, Commons, Wikidata, Incubator etc.). Say for example, if w: was used in German Wiktionary, it would be a link to German Wikipedia. --Glaisher [talk] 16:54, 19 February 2014 (UTC)

   Glaisher is completely correct, and just beat me to comment (edit conflict x3). :P PiRSquared17 (talk) 16:56, 19 February 2014 (UTC)

4. Always has been cumbersome typing commons, +6 letters compared to c. But COM would be also acceptable as this is already used at Commons for our project namespace and thus for shortcuts. -- Rillke (talk) 16:53, 19 February 2014 (UTC)
5.  Support for C or COM--Jarekt (talk) 16:58, 19 February 2014 (UTC)
6.  Support for C or COM. INeverCry 18:07, 19 February 2014 (UTC)
7.  Support for C (ideally) or COM (if the community decides that C: as a pseudonamespace for Category is more useful). PiRSquared17 (talk) 18:08, 19 February 2014 (UTC)

   Oppose com, it is an ISO 639 code. PiRSquared17 (talk) 23:03, 19 February 2014 (UTC)

8.  Support "C:" and/or "COM:". All the other projects have a similar shortcut, so I see no reason that commons should remain the exception. HJ Mitchell | Penny for your thoughts? 19:12, 19 February 2014 (UTC)
9.  Support may be C (maybe also COMM, but simplier C). --Tn4196 (talk) 20:48, 19 February 2014 (UTC)
10.  Support for C. --Alan ^(talk) 21:26, 19 February 2014 (UTC)
11.  Support for C or COM --Indeedous (talk) 23:00, 19 February 2014 (UTC)
12. FDMS (WP: en, de) 23:10, 19 February 2014 (UTC): Commons is the 2nd most important Wikimedia project, so I prefer the short c. Shortcut for Category could be CAT, altough CAT as well as COM might conflict with language codes.

    'cat' is the ISO 639-3 code for Catalan, but Wikimedia uses the two letter code ('ca'), so this is a non-issue. Comanche, on the other hand, does not have a two letter code, so 'com' is the only option. I'd rather not prevent the future development of a Comanche Wikipedia or other Wikimedia project. PiRSquared17 (talk) 23:39, 19 February 2014 (UTC)

13.  Support Seems like the conflicts can be overcome.--Saehrimnir (talk) 23:44, 19 February 2014 (UTC)
14.  Support for either "C" or "COM" or both Beyond My Ken (talk) 23:49, 19 February 2014 (UTC)
15.  Support for "c:". (Oppose "com:" per PiRSquared, it is a language code for w:Comanche language.) It is always inconvenient and frustrating to have to type "commons:". Also per FDMS4: "Commons is the 2nd most important Wikimedia project". Why should it not have a short interwiki prefix when all the others do? This, that and the other (talk) 00:26, 20 February 2014 (UTC)

    We should have a short interwiki prefix for Incubator too. Bad idea? --Glaisher [talk] 09:58, 20 February 2014 (UTC)

    Any specific suggestions so I can evaluate them? PiRSquared17 (talk) 18:34, 20 February 2014 (UTC)

    @Glaisher and PiRSquared17: Rather than adding a short prefix for Incubator, I would rather see all ISO language codes added to the interwiki map. That way, if you want to link to (say) the Ancient Greek Wiktionary test project at incubator:Wt/grc, I could simply type [[wikt:grc:]] and the automatic Incubator redirection system would take me there, just as it already does for test projects with known language codes (eg. wikt:diq:). I should file a bug for this. This, that and the other (talk) 03:47, 21 February 2014 (UTC)

    If someone starts to work on a Coast Miwok wiki, will links like w:CSI: Miami still work? PiRSquared17 (talk) 03:56, 21 February 2014 (UTC)

    Well, no, they wouldn't. But we could always create an exemption for csi: for the time being (there isn't even a test project on Incubator for Coast Miwok yet - and I highly doubt any project in this now-extinct language would ever be approved by Langcom). This, that and the other (talk) 06:18, 21 February 2014 (UTC)

16.  Support for "c:"; any conflict doesn't outweigh the advantage of the shortcut and could probably be dealt with anyway. --CyberXRef (talk) 00:56, 20 February 2014 (UTC)
17.  Support for "c:".--88.130.64.194 01:12, 20 February 2014 (UTC)
18.  Support Go ahead, as long as conflicts with local wikis are provided for.--Aschmidt (talk) 01:28, 20 February 2014 (UTC)
19.  Support --99of9 (talk) 02:23, 20 February 2014 (UTC)
20.  Support Tuvalkin (talk) 04:42, 20 February 2014 (UTC)
21.  Support with some preference to "C:". We can deal with changing some of the C: redirect at the English Wikipedia. Commons is very important and deserves it's own letter. Royalbroil 04:46, 20 February 2014 (UTC)
22.  Support. Allan Aguilar | discussion 05:01, 20 February 2014 (UTC)
23.  Support. It's ok for me --Joergens.mi (talk) 06:21, 20 February 2014 (UTC)
24.  Support C, not COM, since that is an ISO code. Ajraddatz (Talk) 07:03, 20 February 2014 (UTC)
25.  Support for C or COM --Tobias talk · contrib 07:52, 20 February 2014 (UTC)
26.  Support for C or COM Raymond (talk) 08:12, 20 February 2014 (UTC)
27.  Support for C (or also COM) --Minihaa (talk) 09:15, 20 February 2014 (UTC)
28.  Support for C, NNW (talk) 09:30, 20 February 2014 (UTC)
29.  Support for C (or COM). --Túrelio (talk) 10:38, 20 February 2014 (UTC)
30.  Support for C or COM --Zinnmann (talk) 10:40, 20 February 2014 (UTC)

    Comment This RfC is specifically about the proposed prefix c:. com: is not an option. If people want to support com: as a prefix, please start a separate RfC for that when this one has concluded. Thank you! — Scott • talk 10:57, 20 February 2014 (UTC)

    I'd like to echo Scott's concerns; this RFC is strictly about using C as a prefix for Wikimedia Commons. Do note commons: already exists as an interwiki prefix. Mentioning COM has made it a bit harder to determine consensus as far as determining which interwiki prefix to use. I'm tempted to create a separate section here specifically for collecting people's opinions on COM as prefix to better assess consensus. And perhaps another suggestion titled "Suggestions for other interwiki prefixes" or similar, as I see suggestions like WC: crop up. TeleComNasSprVen (talk) 23:35, 20 February 2014 (UTC)

    Sorry, I'm going to put your tally in a collapse - I still think it's muddying the issue by adding a question to the RfC after it's started. It strikes me that there are two reasons why we might want a com: RfC: firstly, if this one fails to establish consensus for c: (which looks pretty unlikely at this point), or secondly, if people express the desire for having another prefix in addition to commons: and c:. There are enough implementation issues with this one to resolve (mainly on en.wp) that it's in our best interests to keep it as simple as possible. — Scott • talk 16:17, 21 February 2014 (UTC)

31.  Support What is about the shortcut "CS" (COMMONS). Does it work? -- Ra'ike (talk) 11:28, 20 February 2014 (UTC)

    cs is the ISO code for Czech. NNW (talk) 11:40, 20 February 2014 (UTC)

    Ok, than only "C" ;-) -- Ra'ike (talk) 12:14, 20 February 2014 (UTC)

32.  Support for C --Horgner (talk) 11:51, 20 February 2014 (UTC)
33.  Support c:, because after about 10 years people still don't realise they have to write commons:commons:requests_for_xyz, when they want to put a link to a page from the Commons name space on Wikimedia Commons in another wiki. -- 32X (talk) 12:18, 20 February 2014 (UTC)
34.  Support for c: -- Lord van Tasm (talk) 12:20, 20 February 2014 (UTC)
35.  Support for c: --Hubertl (talk) 12:54, 20 February 2014 (UTC)
36.  Support for c: Viciarg ᚨ 13:09, 20 February 2014 (UTC)
37.  Support for c: --Mauerquadrant (talk) 15:47, 20 February 2014 (UTC)
38.  Support for c: --Faolin42 (talk) 17:01, 20 February 2014 (UTC)
39.  Support for c: (I'm opposed to com: as it should remain available for projects in the Comanche language). odder (talk) 17:39, 20 February 2014 (UTC)
40.  Support for c: --Sebastian Wallroth (talk) 18:26, 20 February 2014 (UTC)
41.  Support for c: --Toter Alter Mann (talk) 18:32, 20 February 2014 (UTC)
42.  Support for c: --Stefan »Στέφανος« ‽ 19:20, 20 February 2014 (UTC)
43.  Support for c: --Aconcagua (talk) 19:41, 20 February 2014 (UTC)
44.  Support for c: --Martina Nolte (talk) 20:31, 20 February 2014 (UTC)
45.  Support c/com IW 21:27, 20 February 2014 (UTC)
46.  strong oppose to anything longer than [[c:]]. –Be..anyone (talk) 22:43, 20 February 2014 (UTC)

    @Be..anyone: Can we interpret this, then, as a support comment for c:, and if so would you mind if it were moved to that section? Thanks. — Scott • talk 11:27, 25 February 2014 (UTC)

    For my own contributions elsewhere, yes, I'd like to have a c:; C:\ articles discussing Windows can't be good—unsourced+unlicensed+pointy original research prejudice ;-) –Be..anyone (talk) 11:59, 25 February 2014 (UTC)

47.  Support c with weak support for com per Comanche conflict.HueSatLum (talk) 22:45, 20 February 2014 (UTC)
48.  Support for c: --Michael Barera (talk) 22:52, 20 February 2014 (UTC)
49.  Support for c: --TeragR (talk) 23:12, 20 February 2014 (UTC)
50.  Support for C or COM --Packa (talk) 01:03, 21 February 2014 (UTC)
51.  Support for c:, if possible! So many different opinions! Just commons fine. -- ɑηsuмaη «Talk» 04:50, 21 February 2014 (UTC)
52.  Support for c: --Ireas (talk) 09:15, 21 February 2014 (UTC)
53.  Support for c: as this would be consistent to :w, :s, :d etc. Even if there are some obstacles, we should move forward in the interest of simplicity and usability. --AFBorchert (talk) 09:34, 21 February 2014 (UTC)
54.  Support YES!!!!! Arctic Kangaroo (talk) 16:25, 21 February 2014 (UTC)
55.  Support for c:, oppose com: per odder darkweasel94 (talk) 22:17, 21 February 2014 (UTC)
56.  Support for c:, oppose com: --Nouill (talk) 12:50, 22 February 2014 (UTC)
57.  Support FrankyLeRoutier (talk) 13:02, 22 February 2014 (UTC)
58.  Support for "c:".--Wdwd (talk) 20:21, 22 February 2014 (UTC)
59.  Support for c: Ukko (talk) 21:30, 22 February 2014 (UTC)
60.  Support for "c:" (after searching for current usages on various wikis). (Strong opposition to "com:") verdy_p (talk) 01:44, 23 February 2014 (UTC)
61.  Support for "c:", oppose "com:" per odder though pity. Perhaps then "comm:" -that is shorter than commons: anyway?. Devs shall care about articles prefixed with that as it's annoying to move lost ns0 pages via API using pageid then. --Base (talk) 16:39, 23 February 2014 (UTC)
62.  Support for C --Anka Friedrich (talk) 23:16, 23 February 2014 (UTC)
63. C: ...Aurora... (talk) 02:46, 24 February 2014 (UTC)
64.  Support - this will definitely ruin some links on English Wikipedia (w:C:, w:C:SD), but I think it's worth it. Magog the Ogre (talk) 01:53, 25 February 2014 (UTC)
65.  Support --MichaelMaggs (talk) 02:06, 25 February 2014 (UTC)
66.  Support --Stefan2 (talk) 02:19, 25 February 2014 (UTC)
67.  Support --Glaisher [talk] 12:08, 25 February 2014 (UTC)
68.  Support --Denis Barthel (talk) 21:04, 25 February 2014 (UTC)
69.  Support. Most helpful idea, strong support. -- Cirt (talk) 03:27, 26 February 2014 (UTC)
70.  Support for "c:". Prenn → Talk 11:15, 26 February 2014 (UTC)
71.  Support for "c:". --Micha (talk) 13:36, 26 February 2014 (UTC)
72.  Support c:. The alias at EN:WP and others could be refined as cat: and easily fixed per bot, just before the c: is enabled for Commons.. --Matthiasb (talk) 22:16, 26 February 2014 (UTC)
73.  Support for "c:". --Pharos (talk) 23:36, 26 February 2014 (UTC)
74.  Support --Brackenheim (talk) 11:19, 27 February 2014 (UTC)
75.  Support Yep, do it!--AldNon^Ucallin?☎ 19:50, 27 February 2014 (UTC)
76.  Support for c: --Osiris (talk) 21:07, 27 February 2014 (UTC)
77.  Support introduction of c:. On this one, the positives outweigh the points against. (Thank you to the proposers, whose evaluation was diligent and useful.) AGK [•] 20:30, 1 March 2014 (UTC)
78.  Support for c: Regards, Christoph Braun (talk) 10:22, 2 March 2014 (UTC)
79.  Support for c: --An-d (talk) 13:44, 2 March 2014 (UTC)
80.  Support --Perhelion (talk) 20:12, 2 March 2014 (UTC)
81.  Support Elvaube ?! 08:03, 7 March 2014 (UTC)
82.  Support for c:,  Oppose com: because of the Comanche language. 1. To be consistent with the rest of the project links (s:, q:, d:, b:, v:, etc.) 2. Only has a few conflicts (which can and should be fixed in my opinion) 3. No other project begins with a C, which means no confusion (unlike v: for Wikiversity and Wikivoyage, which has to use voy:). The Anonymouse [talk] 18:06, 10 March 2014 (UTC)
83.  Support for c: it's time! --Marimarina (talk) 09:42, 11 March 2014 (UTC)
84.  Support for "c:" ~ DanielTom (talk) 23:16, 11 March 2014 (UTC)
85.  Support c: John Vandenberg (talk) 15:21, 12 March 2014 (UTC)
86.  Support Writing commons: has always bugged me. Conflicts with category namespace shortcuts are being resolved by deleting or migrating them to CAT: . Conflicts with article names / article redirects can be circumvented by using a full-width colon, which is (at least for East-Asian languages) easy to type directly on a standard keyboard. --朝彦 (Asahiko) (talk) 16:29, 16 March 2014 (UTC)
87.  Support --Tahir mq (talk) 05:59, 17 March 2014 (UTC)
88.  Support for "c:" or "com:", though only after the existing conflicts are solved. Trijnstel_talk 20:27, 18 March 2014 (UTC)
89.  Support for "c:" or "com:"--Oursana (talk) 01:14, 23 March 2014 (UTC)

Oppose (2014)

1.  Oppose There are many conflicts with content pages and redirects on wikis. "COM:" would be significantly less problematic. Thryduulf (en.wikt,en.wp,commons) 12:12, 17 February 2014 (UTC)

   Anyone else support COM as iw prefix? I didn't find any uses. PiRSquared17 (talk) 16:38, 18 February 2014 (UTC)

   I just ran a query on all public, open Wikimedia wikis, and found just 2 uses. Both of those could easily be fixed by adding content to Commons. In particular, the issue with w:COM:FR (see its talk page on enwiki) could be fixed with a soft redirect from commons:FR to the file renaming page. I still think "C:" is fine, but this is a viable alternative if the community decides against it. PiRSquared17 (talk) 17:11, 18 February 2014 (UTC)

   This is not a viable option! It is an ISO 639 code. PiRSquared17 (talk) 23:37, 19 February 2014 (UTC)

   So what? As interwiki prefixes only language codes are important, but ISO 639 is a country code. The language code is different from COM --Tobias talk · contrib 07:51, 20 February 2014 (UTC)

   @Church of emacs: ISO 639 are language codes, not country codes. Not sure where you got that from. And I am referring to Comanche (with only 100 speakers). ISO 639-3 is not a country code! PiRSquared17 (talk) 13:04, 20 February 2014 (UTC)

   Sorry, you're right. "Com" as a country code lead me to Comoros, and the Comoros language code is different. "COM" is in ISO 639-3 and it is indeed a valid language code. --Tobias talk · contrib 14:48, 21 February 2014 (UTC)

   Even ignoring the incubator to preserve the language com:, this is a very bad idea. COM: used to be a pseudo-namespace on commons: like WP: on w:, it's now an alias of project:. –Be..anyone (talk) 22:00, 20 February 2014 (UTC)

2.  Oppose
   • No c: (as the headline suggests) for two reasons:
     1. Conflict with multiple existing pages.
     2. Not self-explaining. There is m:, but there is also meta: with four letters. Short enough for manual typing of an interwiki link.
   • But com: is fine with me.
     • The Comanche Wikipedia might get a problem according to ISO 639-3, but CSI: Miami gets in fight with Coast Miwok, too.
   • Using drag&drop & copy&paste no shortcut is required.
   • Greetings --PerfektesChaos (talk) 23:01, 19 February 2014 (UTC)

   Good point about Comanche, I totally forgot about that (incubator:Wp/com). PiRSquared17 (talk) 23:05, 19 February 2014 (UTC)

   meta: as well as commons: actually conflict with their internal project: namespace. Good interwikis should be portable, i.e., work also on their own wiki and major projects down to wikia, and stay away from potential language codes; m: is fine, but mw: is not. –Be..anyone (talk) 21:49, 20 February 2014 (UTC)

   How is that a problem with the c: proposal? It doesn't conflict with any namespace on Commons. PiRSquared17 (talk) 21:51, 20 February 2014 (UTC)

   @Be..anyone: I guess this is because MW is listed on IWM, but M is here. Not sure. PiRSquared17 (talk) 21:57, 20 February 2014 (UTC)

   @PiRSquared17:: it was only a comment why meta: mentioned by PerfektesChaos is not a good example, but of course also no problem, because we have m:, a.k.a. metawikimedia: on wikia:community:MediaWiki:Interwiki map, or even the sick metawikipedia:. I liked the c: idea, but reading fix all articles starting with C:' I'm not sure how bad it is. –Be..anyone (talk) 22:21, 20 February 2014 (UTC)

3.  Oppose c: but  Support com: or coms: Technical 13 (talk) 23:09, 19 February 2014 (UTC)
   • On second thought, I don't support those alternatives either. As I've mentioned on the BZ ticket, ignoring PNR's, the results of http://tools.wmflabs.org/pirsquared/c.txt simply show too many legitimate articles that start with C: such as C:, C:\, C:\\, C:\\Window, C:\\Program files, etc. I've heard a suggestion that these pages simply be put on Commons, but commons is for media, and not content so that would first violate the spirit of commons and secondly since some of those pages are in multiple languages, this would require multiple translations of some already large articles making it difficult or possibly impossible to load the pages (I'm thinking of mobile devices). Technical 13 (talk) 02:40, 20 February 2014 (UTC)

     Not exactly legitimate; for NT5 it was perfectly possible to have a DOS on C: (plus NTLDR and BOOT.INI for dual boot), and Windows on D:. I still have a box where that's the case. Good Windows articles would avoid to mention C:\ explicitly outside of examples, let alone in their title. –Be..anyone (talk) 12:04, 22 February 2014 (UTC)

     It's not even an accurate representation of the facts. There are no computing articles titled "C:...". As a look at en:Special:PrefixIndex/C: will demonstrate, all of those titles are redirects. There is in fact only one article on the English Wikipedia beginning with "C:" ("C:Real"). — Scott • talk 18:00, 22 February 2014 (UTC)

4.  Oppose Let's make wikitext as cryptic as possible to alienate all occasional users not familiar with all the abbreviations and technical terms we are using. Wikitext should only be edited by a small group of experts. --TMg 00:01, 20 February 2014 (UTC)

   Interwiki prefixes already exist. commons: prefix exists. Is c: really cryptic? Certainly no more so than d:, w:, or v:. PiRSquared17 (talk) 00:03, 20 February 2014 (UTC)

   You know this is in no way a reason to create more of these insanely confusing, not self-explaining shortcuts? It's the amount of possibilities that makes wikitext cryptic. This is the opposite of the original idea of wikitext to be lightweight and easy to understand. There is absolutely nothing wrong with commons:. Come on. How many typing errors can you make in such a short word? Neither c: nor com: is unique. COM: is a communication port, command or computer, C: is the name of a hard disk or possibly a category or class. Look at the v: in your example. It's obviously an abbreviation for wikivoyage:, right? No, it's not. Congratulations. You reached the end of the alphabet. --TMg 00:21, 20 February 2014 (UTC)

   TMg, how do you feel about my suggestion of coms:? I think it is still specific enough to not be confusing. Technical 13 (talk) 00:25, 20 February 2014 (UTC)

   The project is called Commons, not Coms. That's not even a word and it's definitely not obvious. What's wrong with commons:? How often do you type this and why? Files are linked with File:, not commons:. --TMg 00:30, 20 February 2014 (UTC)

   Too many times this year, and as long as wikia: has no mw:InstantCommons there's no end in sight, transwiki ends up as copy + paste horror, e.g., the GNU zoo. –Be..anyone (talk) 23:03, 20 February 2014 (UTC)

5.  Oppose Too many current and potential conflicts. We would certainly need significantly more global participation in an RfC prior to consuming a namespace with such a high potential use for other things. Given the objection to com:, to which I would also object, would comm: work for people? Makyen (talk) 07:50, 20 February 2014 (UTC)
6.  Oppose c: is to short and not descriptive at all. I found myself often typing com: (and then remembering that this does not exist) so I would support that. This is however only true if it's possible technically. Actually I'm afraid that I don't like this RFC at all since the technical feasibility is not discussed at all. This should be clarified first and only afterwards some kind of voting in an RFC makes sense... --Patrick87 (talk) 09:40, 20 February 2014 (UTC)

   Yeah, this is definitely technically feasible, but do we want it? I've submitted a patch (see the bug), but it would also be possible to do it on IWM. PiRSquared17 (talk) 16:14, 20 February 2014 (UTC)

   I second that; there are no technical barriers to the proposed changes, other than the practically unused C: namespace alias on hiwiki. This, that and the other (talk) 03:41, 21 February 2014 (UTC)

   PiRSquared17 and This, that and the other: By "technically feasibile" I did not have MediaWiki support in mind (which is not an issue for sure). What I was talking about were restrictions like "c:" already being used as a shortcut and/or in article names throughout Wikimedia projects and "com:" being a valid language code as PiRSquared17 states himself further down the page. As long as issues like these are not evaluated a proper RfC is not possible (e.g. consider at least half of the supporting voices being invalid as the respective users were not aware that those problems existed). For a useful RfC I expect at least that all known pros and cons are collected and presented in an objective and for everybody comprehensible way. Only then any useful outcome can be expected. --Patrick87 (talk) 05:09, 23 February 2014 (UTC)

   @Patrick87: I actually usually do summarize things in an objective way, e.g. here. I have added a section to the bottom of the page with some reasons. Feel free to expand. PiRSquared17 (talk) 05:22, 23 February 2014 (UTC)

7.  Oppose we already have :commons: and instead of using more shortcuts, we should use fewer. Too cryptic for the non initiated and too many potential conflicts. If I could go back in time i'd vote against some of the others. TheDJ (talk)
8.  Oppose not self-explaining & somewhat nerdish. It gets harder, esp. for new people, to understand what other contributors in discussions are linking to. Alexpl (talk) 11:10, 20 February 2014 (UTC)
9.  Oppose I consider 6 letters less to type not worth a worse comprehensibility of the source code (it's clear where 'commons:' links to while it might not be clear for 'c:'). Putting articles to Commons (in what language? English only? All languages in one article?) is another problem being caused by the 6 letter saving. Yellowcard (talk) 15:54, 20 February 2014 (UTC)
10.  Oppose I'm fine with "com:" but "C:" is both confusing and will lead to problems, especially on en-wiki, where it's currently used as a abbreviation for "Category:". Regards SoWhy 20:27, 20 February 2014 (UTC)

    That does not appear to be exactly true for enwp as CAT: is the most widely used shortcut for categories. See the difference between en:Special:PrefixIndex/C: and en:Special:PrefixIndex/CAT:. Also see the relevant guideline page at enwp. --Glaisher [talk] 16:51, 21 February 2014 (UTC)

11.  Oppose. Personally I oppose all one-letter shortcuts for Wikimedia projects. Because of these shortcuts we have to rename many articles. We should have some other way to use shortcuts, I don't know what. If we have some band called "C:xxx" we need to move it to "Ccolonxxx" or smth like that just because we want to make a link to Commons shorter. What's more important: articles or shortcuts? --Stryn (talk) 12:19, 22 February 2014 (UTC)
12.  Oppose. Firstly, C letter looks like "С" in Russian or other languages which used Cyrillic script. Moreover it's too short to be very recognized. I think "com" or "comm" would be better. --Brateevsky (talk) 17:40, 22 February 2014 (UTC)

    com is a valid ISO 639-3 language code. PiRSquared17 (talk) 17:49, 22 February 2014 (UTC)

    CA also looks like Cyrillic letters ess+a, but it is still used to designate Catalan (same remark for AK, AZ, CE, CO, CU, HA (vs. NA), HE, HU (vs. NU), KA, KO, KU, MT, QU, TA, TE, TH (vs. TN), XH, ZH... or also HI, IA, IO, MI, TI in Belarusian and Ukrainian Cyrillic alphabets..). The argument of similar-looking Cyrillic letters (or Greek letters, or Amerindian letters or syllabics, etc.) is definitely not convincing !!!

    "cat" is also a valid ISO 639-3 language code, but it is invalid in BCP 47 where it uses ISO 639-2 code "ca" instead, so "CAT:" is free to be used to create shortcuts (in the root namespace) for categories, or it can be used also an alias for the Category namespace (Hindi Wikipedia uses "C:" as an alias for that category, without needing to create shortcut redirect pages in its root namespace).

    Conflicts would have been simpler to use if we had made distinction of letter case for interwiki prefixes (starting only by lowercase letters) and local pagenames or namespace prefixes (starting by uppercase letters... except in Wiktionary where the root namespace or the associated talk space use pagenames starting by lowercase).

    unfortunately, MediaWiki cannot distinguish interwiki prefixes from pagename/namespace prefixes (namespaces prefixes are purely local convention of naming where namespaces are fully considered as being case insentive, something that is also potentally nefast in Wiktionnary, where they block naming valid pagenames in the root namespace needing case distinctions).

    I would advocate another non ambiguous syntax for interwiki prefixes, such as:

    [:interwiki[namespace:pagename|link description]]

    instead of current: where the "interwiki" is too dependant on the mapping of namespaces (and their aliases) on the local wiki (and notably with the local "project:" namespace):

    [[interwiki:namespace:pagename|link description]]

    (note that if I oppose COM, I do not find any real problems with C) verdy_p (talk) 00:42, 23 February 2014 (UTC)

    All uses remaining for COM: are just redirecting shortcuts left almost orphaned (or just remaining in old discussions about it in user pages). It should be considered deprecated anyway for this use; let's reserve it for language codes, even if it's not used for that, because we don't want to manage long very lists of valid ISO 639-3 language codes usable in BCP47 for language tagging (nly complete lists of ISO 639-1/2 codes are viable and it's easy to parse them for handling possible exception in them). All pccurences of 3 ASCII letters + colon prefixes should be reserved for BCP47 language codes to be used in interwiki links without creating conflicts depding on local wikis where they could be inserted in its pages (and not even used for local redirecting shortcuts in the main namespace). The only viable options for these prefixes can only be 1 letter, or 4 letters or more (but still distinctly fro mthe local project name and to avoid it these prefixes should be limtied to 4 letters only (so only "C:" and "COMM:" are viable for the long term). verdy_p (talk) 23:53, 23 February 2014 (UTC)

13. I do not want C nor COM, I want WC for Wikimedia Commons. --Pustekuchen2014 (talk) 14:45, 20 February 2014 (UTC)

    wc is not an ISO 639 code, but I prefer c. There are several usages of this (cy:wikt:Special:PrefixIndex/WC:,pl:q:Special:PrefixIndex/WC:, pt:wikt:Special:PrefixIndex/WC:), in addition to the fact that it is an alias for the Project namespace on cswikiquote. Would prefer "C". Nonetheless, 34 for WC definitely beats 146 or so for C. PiRSquared17 (talk) 16:29, 20 February 2014 (UTC)

14.  Oppose Too cryptic. We should probably get rid of the d: and v: prefixes too. --Avenue (talk) 22:31, 25 February 2014 (UTC)

    Re the second sentence: that would break many links. Why should we just remove v: ? Why not w:, s:, q:, m: too? I would be opposed to these anyway, as it would just add to linkrot. PiRSquared17 (talk) 22:38, 25 February 2014 (UTC)

    Sorry, I'm not familiar with all the prefixes. Yes, I think all of those should probably go too, except perhaps w:, and for the same reason. I presume they could be removed from links semi-automatically, before the prefixes were turned off. --Avenue (talk) 08:10, 26 February 2014 (UTC)

15.  Oppose It should be "com" like "commons". --Mogelzahn (talk) 21:23, 26 February 2014 (UTC)

    Did you read the other comments? PiRSquared17 (talk) 21:26, 26 February 2014 (UTC)

16.  Oppose "c" and "com" will cause too many conflicts. We shouldn't choose abbreviations matching real or potential article titles. Also, they are too short, and "c" is not descriptive at all (applies to other single-letter shortcuts as well). If we need something shorter than "commons" (I don't think so), perhaps "cmn" or "@c@" would be good enough. Alternatively, we should implement some escape/breakout syntax for symbolic names, which is much less likely to conflict with name space articles. --Matthiaspaul (talk) 18:01, 1 March 2014 (UTC)
17.  Oppose "C:_The_Contra_Adventure" gets 70+ hits a month on enwiki (a ton for a redirect), while "C:", "C:\Program Files", "C:\Windows" get a couple dozen. "C:_The_Money_of_Soul_and_Possibility_Control" gets a couple dozen as well. Where this exist on otehr wikipedias, they get another couple dozen hits. (redirects do not normally get crawler\bot hits, so those are almost entirely human). "C:Real", an article, gets 400 hits a month. It is not worth confusing say 600 users a month to make life easier for editors. In the future, there will, no doubt, be other legitimiate article/redirects that start "c:". Also, looking at the raw log files several people a day type in "c:\some\random\file.ext". While this is clearly an error on their part, it would be far more confusing to be redirected to commons rather than just given a "not found" page. So, even exluding the c: for category: shortcuts there seems to be enough traffic to "c:..." --ThaddeusB (talk) 19:05, 5 March 2014 (UTC)

    Why wouldn't renaming to e.g. C：Real work for you? It would override the c: interwiki in the search box, and Google would still list the article. PiRSquared17 (talk) 19:50, 5 March 2014 (UTC)

    Does the "wide colon" trcik also work for redirects? (e.g C：The Contra Adventure) --ThaddeusB (talk) 15:56, 6 March 2014 (UTC)

    I would think so. testwiki:Special:Search/C:The Contra Adventure. PiRSquared17 (talk) 16:00, 6 March 2014 (UTC)

    Hm, I guess not, which is strange. Maybe you can test it some more on testwiki and file a bug under CirrusSearch? PiRSquared17 (talk) 16:03, 6 March 2014 (UTC)

    @PiRSquared17: Testwiki often runs on a different version of MediaWiki than the rest of Wikimedia does in order to test run a few bugfix deployments. Can you check to make sure that version of MediaWiki is compatible with ours? TeleComNasSprVen (talk) 16:15, 6 March 2014 (UTC)

    @TeleComNasSprVen: testwiki seems to be running MediaWiki version 1.23wmf16, the same as Meta. Even this is not the latest version of MediaWiki. Deployment should be the latest (or close). All Wikimedia projects except Wikipedia are using 1.23wmf16; Wikipedia is using 1.23wmf15. See also wikitech:Deployments, mw:MediaWiki 1.23/Roadmap. I was just thinking the reason this wide colon trick is not working may be because of bugzilla:61879, but m:RFC still seems to work on testwiki. File a bug under Extensions->Cirrus maybe? PiRSquared17 (talk) 17:01, 6 March 2014 (UTC)

    Since writing, group 0 (MW.org, testwiki, etc.) have been upgraded to 1.23wmf17. Wikipedias (group 2) are on wmf16 now. PiRSquared17 (talk) 20:56, 6 March 2014 (UTC)

    Maybe the pages Commons:\WINDOWS and Commons:\PROGRA~1 (and possibly others) could be created with an explanation for people who accidentally end up on Commons when looking for w:C:\WINDOWS and w:C:\PROGRA~1... --Stefan2 (talk) 00:04, 9 March 2014 (UTC)

    +1 to place navigations on Commons. I would add

    The syntax [[C:CSD]] currently generates a link to here from Wikimedia projects, because [[c:]] is a interwiki prefix for Wikimedia Commons. Before 2014, [[C:CSD]] have generated a link to en:Category:..., ja:Category:..., .... You might want to update the link you followed and rename the local page.

    or something similar, onto the top of commons:CSD. whym (talk) 12:05, 10 March 2014 (UTC)

18.  Oppose Based on the above, seems to be more trouble than it is worth. I could agree to "comm:". Keφr 06:29, 17 March 2014 (UTC)

    A mere finite amount of trouble now saves us lots of work well into the future. --朝彦 (Asahiko) (talk) 15:11, 17 March 2014 (UTC)

    Typing six more letters is "lots of work"? First world problems. Introducing this prefix would result in surprising redirects (try searching for "D:\AUTORUN.INF" on Wikipedia, for example) and requires projects to resort to awkward substitutions in the titles of real, mission-relevant pages. Forever. Because once we start relying on the "c:" prefix, we will be stuck with it, unless we intend to break internal or external links — just like Wikipedia is stuck with "MOS:IDENTITY" now, much to the chagrin of those who intend to deprecate pseudo-namespace shortcuts. Keφr 17:32, 18 March 2014 (UTC)

    I was referring to, e.g., the recurring instances of people forgetting the first "commons:" in [[commons:Commons:pagename]] and work related to locating and fixing them; an issue mentioned elsewhere on this page. The "MOS:" shortcut that you cite is a bad example. The main reasoning behind the intention to deprecate them is that they mix up namespace distinctions (Shortcuts are in main space). A C: prefix is a prefix, and it is part of the MediaWiki syntax; unlike confusing usage in shortcuts, which is an "abuse of notation" using page names. --朝彦 (Asahiko) (talk) 13:56, 19 March 2014 (UTC)

    "MOS:IDENTITY" is a perfectly good example of something that some people would like to get rid of, but are unable to, because of heavy internal and external reliance upon it. Just like the situation we might end up if we ever find out that a "c:" prefix is not such a great idea after all. Keφr 17:28, 19 March 2014 (UTC)

    Your comment condenses to "If in the future some unspecified people want to get rid of the c: prefix for some unspecified reason, they won't be able to." That is hardly a useful observation. — Scott • talk 18:10, 19 March 2014 (UTC)

19.  Oppose c:a is an abbreviation of cirka (=circa) in Swedish, which makes troubles on Wiktionaries, and c:\ is problematic on Wikipedias. Why don't use commons: or comm:? Olaf (talk) 09:58, 19 March 2014 (UTC)

    Meaning that it will join the ranks of n:o (Unsupported_titles/n:o), s:a (Unsupported_titles/s:a), and v:a (Unsupported_titles/v:a). Certainly not pretty, I have to agree, but instances already exist. --朝彦 (Asahiko) (talk) 14:08, 19 March 2014 (UTC)

    The Swedish Wiktionary has moved c:a to their own list of unsupported titles. — Scott • talk 20:59, 22 March 2014 (UTC)

20.  Oppose for "c:", but  Support for "com:", "comm:", or "coms:". Reason: "c:" has been used for namespace of shortcut to category on some wikis for a long time. For instance, "C:CSD" is a popular shortcut. On the other hand, "com:", "comm:", and "coms:" are vacant now. Why don't we choose one of them? If people want to preserve "com:" (ISO 639-3 code for Comanche-language) for the future Comanche-language Wikipedia even though it does not exist at this moment, we can still use "comm:" or "coms:". As we have used "wikt:" for Wiktionary without trouble, "comm:" or "coms:" would also be acceptable. Even for "com:", we could use it at least until Comanche-language Wikipedia is actually established (I don't know when). I believe we should avoid to use the one which conflicts with existing namespace many people have been using actually. --Penn Station (talk) 18:36, 24 March 2014 (UTC)

Other discussion

The proposal says to add this to IWM, but it seems other prefixes like m: and d: are in the maintenance script. I have already submitted a patch r112920 (yes, I said "Do not merge") based on r31887 by Chad H. and Reedy. Pinging This, that and the other for advice. PiRSquared17 (talk) 21:46, 19 February 2014 (UTC)

• I'm not so familiar with internals (what's the maintenance script? :) ), so didn't know that when I added it. The precise technical details aren't necessary for the question so I've edited that bit out. — Scott • talk 22:36, 19 February 2014 (UTC)
  • namespaceDupesWT.php and cleanupTitles.php are maintenance scripts used to recover broken page titles left behind by the switchover to the interwiki prefix, as the original titles were still considered entries in the wiki database, but inaccessible to anyone besides developers. See Meta:Babel#Broken/outreach:Cherokee as an example of this (and the only one left on this wiki). Because of the possible conflict in the pagetitle when the Outreach Wiki was introduced, it was moved to the "Broken" namespaces. Besides breaking lots of links, this is another possible outcome of the configuration change from the developers. TeleComNasSprVen (talk) 00:25, 20 February 2014 (UTC)
    • Thanks. I had been vaguely considering how changes like this had been handled in the past and that more or less matches what I came up with. — Scott • talk 14:19, 20 February 2014 (UTC)
  • @PiRSquared17: Your patch is indeed correct. This, that and the other (talk) 00:29, 20 February 2014 (UTC)

@PiRSquared17: This page links to a couple of discussions about the viability of COM before it was changed to become a namespace alias on Wikimedia Commons, located here and here. — The preceding unsigned comment was added by TeleComNasSprVen (talk)

I don't know. I would have opposed those, but now that they're created perhaps there is a precedent for com. I'm still worried that it will prevent a Comanche Wikipedia, but for some reason I doubt there will be one soon. PiRSquared17 (talk) 05:23, 20 February 2014 (UTC)

"COM:" has already been rejected several times in conversations not on Meta, due to precluding the possibility of a Comanche-language Wikipedia, while "C:" seems to create a large number of minor but annoying technical issues. Another possibility is "CM:", since there's no ISO two-letter language code cm, and the list of ISO two-letter language codes is not supposed to be added to in future... AnonMoos (talk) 07:02, 20 February 2014 (UTC)

I would not oppose "cm". PiRSquared17 (talk) 13:12, 20 February 2014 (UTC)

Only one page uses this prefix, w:CM:SF. Cf. toollabs:pirsquared/cm.txt. PiRSquared17 (talk) 16:30, 20 February 2014 (UTC)

• I'd like 'WCM'. Ziko (talk) 22:48, 20 February 2014 (UTC)

  WCM does not conflict with any page titles or namespace aliases. PiRSquared17 (talk) 22:56, 20 February 2014 (UTC)

  Oppose: WCM, like all 3-letter codes proposed (COM) will conflict later with one of the many language codes (unless these languages, like Catalan, also have a 2-letter code which is prefered in BCP47, so "CAT:" is usable in Wikimedia project to create shortcut prefixes for categories without conflicting with Catalan "CA:"...)

  There's no conflict with 1-letter codes (like the proposed "C:" alias) because they ill never conflict with BCP47 (which use them only as special singleton prefix followed by a mandatory hyphen and an extension subtag). verdy_p (talk) 20:20, 22 February 2014 (UTC)

• cm sounds like a good idea to me. -Eric ^{my en.wp talk page}

• WMC might be nice because WM can be seen as the abbreviation of Wikimedia. 'd be consistent. Ziko (talk) 00:35, 28 February 2014 (UTC)

  @Ziko: But that conflicts with the code for the Wamas language. PiRSquared17 (talk) 01:07, 28 February 2014 (UTC)

• If we can't use "com" because of the Comanche Language, should we also move the Wikipedia Multilingual portal page (as you see, the "www dot wikipedia dot org") to another domain because of the Wawa Language?!--Liuxinyu970226 (talk) 09:39, 10 March 2014 (UTC)

  @Liuxinyu970226: um, LangCom already decided to use wxwa for Wawa. AFAIK there is no similar decision for Comanche... PiRSquared17 (talk) 20:50, 24 March 2014 (UTC)

COM as prefix

Tally of people who expressed an opinion on com:, which isn't the topic of the RfC
Supports thus far Rillke Jarekt INeverCry HJ Mitchell Indeedous Beyond My Ken Church of emacs Raymond Minihaa Túrelio Zinnmann Inkowik HueSatLum Thryduulf PerfektesChaos Patrick87 SoWhy Opposes thus far PiRSquared17 This, that and the other Ajraddatz odder Be..anyone Technical 13 TMg Makyen Pustekuchen2014 AnonMoos Darkweasel94 Nouill Verdy_p (keep all 3-letter codes for the many possible interwiki language codes ! 2-letter language codes are frozen and allow some interwiki extensions like "WP" so they are much less a long-term problem) -sche (for much the same reason as Verdy_p)

Next steps

Discussion is looking very much in favor of C: with some legitimate opposes this time around, so I think we should start the process of cleaning up any interfering page titles sometime soon. What needs to be done, and what's the plan of attack here? (I already started the RFD process over at enwiki, but we still can't override the consensus of wikis affected by this change in PiRSquared17's list.) TeleComNasSprVen (talk) 12:53, 23 February 2014 (UTC)

Pinging @Wikitanvir: Can you start a discussion on bnwiki whether or not to remove C:\WINDOWS as a redirect? I think as an administrator there you're most suited at translating this message to the local wiki community. TeleComNasSprVen (talk) 12:58, 23 February 2014 (UTC)

Please could you wait for the discussion to be closed before taking any action based on the outcome. The opposes are actually based on legitimate arguments that need evaluating to determine whether they outweigh the supports, particularly those that don't address them. Thryduulf (en.wikt,en.wp,commons) 19:46, 24 February 2014 (UTC)

We would have to get these issues resolved with each wiki community before going forward anyway. The developers who initially rejected this request wants to see the global consensus required for this large configuration change. We are also opening a chance for bnwiki users to voice their objections to this, if they have any. It's important we extend this RFC to the wikis most affected by this change. TeleComNasSprVen (talk) 05:12, 25 February 2014 (UTC)

This is, for all intents and purposes, a "deletion discussion" for all pagetitles on all wikis starting with C, as it makes such titles no longer usable - an effect almost exactly equivalent to deleting said pages. Because of the potential for disruption with improper use of the deletion button, developers and stewards generally leave such processes to the interests of the local communities if there exists one to handle them; by extension the problem is that we have no authority to force the "deletion" of such pages on them either. Like on the English Wikipedia, I believe it a common courtesy to at least "notify" the original "authors" of such pages that what they've made might soon be "deleted", and they should be free to oppose it if they so choose. TeleComNasSprVen (talk) 05:25, 25 February 2014 (UTC)

• FWIW wikia should be now aware of this plan. –Be..anyone (talk) 06:30, 3 March 2014 (UTC)
• Hypothetical scenario, what if say we come to a consensus here to implement the prefix, which is looking very likely, the developers implement the change, and suddenly one of the people from the smaller wikis affected notice it and ask the developers to revert. Would we say to them "nuh-uh, you had your chance to comment" when we did not even notify to the local community of the pending change, or would the developers listen to them and revert, effectively invalidating the purpose of this whole RFC? And keeping in mind that the Meta community cannot override the consensus of local wikis... TeleComNasSprVen (talk) 08:37, 26 February 2014 (UTC)
  • We can't close this until the other wikis have been notified, for sure. Here are the clashes and who we need to notify. Note: strikethrough means all the titles have been renamed or deleted since the original time of this post.

Bengali Wikipedia (1 redirect)

Catalan Wikibooks (3 redirects) Done

Cebuano Wikipedia (1 unused redirect)

Chinese Wiktionary (1 article) Done

Estonian Wikibooks (6 unused redirects) Done

French Wikipedia (1 unused redirect)

Greek Wikipedia (1 redirect) Done

Japanese Wikipedia (26 redirects) Done

Oriya Wikipedia (1 redirect) Done

Polish Wiktionary (1 article) Done

Portuguese Wikipedia (17 redirects) Done

Romanian Wikipedia (12 redirects) Done

Russian Wikipedia (2 redirects) Done

Russian Wikisource (1 redirect) Done

Simple English Wikipedia (2 redirects) Done

Simple English Wiktionary (1 redirect) Done

Spanish Wikipedia (4 redirects) Done

Swedish Wikipedia (1 redirect)

Swedish Wiktionary (1 article) Done

Urdu Wikipedia (2 redirects) Done 1, 2

Welsh Wikipedia (1 unused redirect) Done

Wikimedia Commons (22 redirects) Done

Can we please get some multilingual volunteers together to do this? The process will be made much easier if we are able to find native speakers to convey this to each community. I propose using this message, both in English and in translation:

Request for Comments: c: link prefix for Wikimedia Commons

There is a cross-wiki discussion in progress as to whether c: should be enabled globally as an interwiki prefix for links to the Wikimedia Commons. As your wiki has several pages or redirects whose titles begin with "C:", they will need to be renamed if this proposal gains consensus. Please take a moment to participate in the discussion. Thank you.

It would be advantageous if the link to the definition of "interwiki" could be replaced in translation with a link to local documentation, and "several pages or redirects" altered to more accurately describe the local situations (e.g. "4 redirects", etc.). — Scott • talk 17:52, 26 February 2014 (UTC)

I just realized that links like w : work too. I'll have to modify the query, but I'm not sure there are even any pages named like this. Please forgive me. PiRSquared17 (talk) 13:10, 27 February 2014 (UTC)

There weren't any of these, so no problem. PiRSquared17 (talk) 15:59, 27 February 2014 (UTC)

I informed Portuguese users on w:pt:WP:EA. Helder.wiki 14:17, 27 February 2014 (UTC)

Ongoing discussion at pt:Wikipédia:Esplanada/anúncios#Pedido de Opinião: prefixo "c:" nos links para o Wikimedia Commons. John Vandenberg (talk) 14:37, 19 March 2014 (UTC)

Es:WP has been informed yesterday and there is no redirect or page under c:. --Ganímedes (talk) 16:31, 28 February 2014 (UTC)

I've notified the Romanian Wikipedia. — Scott • talk 21:45, 6 March 2014 (UTC)

A user there has said that they're unlikely to have a problem with losing C: redirects as they can use CAT: ones instead. — Scott • talk 15:24, 9 March 2014 (UTC)

Hi, I have moved all C: shortcuts to CAT: format, now the „c:” namespace is free to use on the Romanian Wikipedia. Please update the list above accordingly. Thank you. --Gikü (talk) 16:29, 18 March 2014 (UTC)

Osiris at the Simple English Wikipedia also indicated the same thing. — Scott • talk 13:36, 12 March 2014 (UTC)

That discussion archived without a contrary position, but also without deletion of the offending redirects: archive of discussion. John Vandenberg (talk) 02:39, 16 March 2014 (UTC)

I've notified user:Foxj and user:PiRSquared17 that there simple.wp shortcuts are being discussed here, and suggested they use speedy deletion criteria A7 on their respective pages. John Vandenberg (talk) 04:45, 16 March 2014 (UTC)

Done. PiRSquared17 (talk) 13:51, 16 March 2014 (UTC)

Thank you John and Pi. — Scott • talk 10:37, 17 March 2014 (UTC)

I've notified Estonian Wikibooks. FWIW, that project appears to be almost abandoned, including the six pages in question (largely untouched since 2007). I don't anticipate any objection arising there. — Scott • talk 15:39, 9 March 2014 (UTC)

As it seems nothing's happening over there, I've renamed the six pages using the fullwidth colon and fixed the only incoming links, meaning its conflicts are now limited to six unused redirects. — Scott • talk 14:17, 19 March 2014 (UTC)

John Vandenberg has improved on this by moving the pages to subpages, and all the redirects have now been deleted. — Scott • talk 21:01, 22 March 2014 (UTC)

@Ajr: Do you think it would be worthwhile to also delete wikibooks:et:Arutelu:C:Sissejuhatus and wikibooks:et:Arutelu:C：Sissejuhatus? TeleComNasSprVen (talk) 06:02, 23 March 2014 (UTC)

I've removed them under the scope of general maintenance. Thanks for the catch. Ajraddatz (talk) 06:26, 23 March 2014 (UTC)

I've notified the zhwikt, however there hasn't any comments, so Diff/4019031. --Liuxinyu970226 (talk) 09:52, 10 March 2014 (UTC)

I've notified the Russian Wikipedia. — Scott • talk 16:49, 10 March 2014 (UTC)

Did the same for Russian Wikisource, hope you don't mind if I used the same translation from your message on Russian Wikipedia. TeleComNasSprVen (talk) 09:54, 11 March 2014 (UTC)

This redirect was deleted. -- Sergey kudryavtsev (talk) 12:53, 11 March 2014 (UTC)

Did Urdu Wikipedia. TeleComNasSprVen (talk) 10:14, 11 March 2014 (UTC)

I added Whym's translation to the Japanese Wikipedia's shortcut documentation talk page as well in the hope of more people seeing it. — Scott • talk 17:09, 12 March 2014 (UTC)

I've just submitted a Redirects For Deletion request for the 26 redirects at the Japanese Wikipedia. JaWP rules say that an RFD should remain open for a minimum of 5 days. We'll see about how other users respond. --朝彦 (Asahiko) (talk) 19:24, 15 March 2014 (UTC)

Some discussions on JaWP.[6][7] So far, participants as of now seem to be okay with migrating category shortcuts from C: to CAT: and using full-width colons for anything else. A speedy rename by one admin was reverted by another, so it will be a normal RfD with a duration of 5 days minimum. I'll keep you posted. --朝彦 (Asahiko) (talk) 16:17, 16 March 2014 (UTC)

I have raised an objection against this on jawiki [8]. In my understanding, there has been NO consensus yet - only few people discussed and decide it only in a few days! Thus, I have opposed the RfD request on condition that *until* we achieve a consensus [9]. --Penn Station (talk) 20:55, 18 March 2014 (UTC)

• I propose that we close this RfC in a week's time, meaning it will have run for a month. Given the degree of support on display (80%), and the rate at which new comments are appearing, it seems unlikely that leaving it to run much longer will result in any change of consensus. With that in mind, I've added a note at the start. Any objections? Remove it if you think that's unfair, but a month seems like a good duration for this. — Scott • talk 14:11, 12 March 2014 (UTC)

• • I would prefer the compromise of two weeks time instead of one week, to give the affected wikis time to respond, at least since some of the smaller communities can take weeks to notice the message or come up with a response. It would also give me and whoever intends to close this a week to assess consensus and another week to decide how to close the RFC. But if we are on time constraints, I am not averse to the current deadline of one week, although the closure explanation might not be as satisfactory. Also, I just noticed Greek Wikipedia's el:C:Real article complement to English Wikipedia's also needs to be moved. The tag has been up since 2012 or so, which was the last time this RFC was brought up, but I don't think they paid enough attention to our requests for comment yet. What say them? TeleComNasSprVen (talk) 08:24, 13 March 2014 (UTC)
    • Greek Wikipedia notified. I'm assuming good faith here that the C:Real article they have is not heavily monitored to reflect the changes here. TeleComNasSprVen (talk) 08:31, 13 March 2014 (UTC)
      • Hmm, how did that slip through the cracks? Thanks. No objection from me, there's no time constraint here. I've modified the RfC header. Incidentally - wow, that banner on el:C:Real... it's interesting seeing how differently other projects operate. — Scott • talk 15:13, 13 March 2014 (UTC)
        • Well, it was in my list. Also, that banner was added by a non-Greek-speaking (at the time) steward, el:special:diff/3064967. I think just renaming it to use full-width colon would be okay. PiRSquared17 (talk) 15:35, 13 March 2014 (UTC)
          • When I say "slip through the cracks", what I really mean to say is "I missed it like a dum-dum". >_< — Scott • talk 21:30, 13 March 2014 (UTC)

User:Olaf mentioned wikt:c:a in an oppose comment. Have we been missing this one because Wiktionary distinguishes upper/lower case for the first letter? Anyone know about any other instances of lowercase [[c:foo]] as page names? --朝彦 (Asahiko) (talk) 14:31, 19 March 2014 (UTC)

It was in my list from the start, so don't blame me. PiRSquared17 (talk) 15:00, 19 March 2014 (UTC)

It appears that there were several omissions on my part (which honestly surprises me, because I'm sure that I went through the list carefully...) - for which I can only apologize. I've now added them to the list above. It appears that TeleComNasSprVen has been zooming about attending to some of them, but there are still a few cases where notifications need to be made. — Scott • talk 15:59, 19 March 2014 (UTC)

@Scott: c:a is the only title like this, although it exists on three Wiktionaries. I have regenerated the list in (what I think is) a nicer format, toollabs:pirsquared/c_recheck.txt (blame petan for the last line). The only wikis not in the above list are commonswiki, enwiki, enwiktionary, ptwiktionary (Edit 16:47, 19 March 2014 (UTC): meant plwiktionary). No need to apologize; to err is human. PiRSquared17 (talk) 16:30, 19 March 2014 (UTC)

Thanks, that's much clearer! TCNSV has notified the Wiktionaries, and I've left a note on the Commons village pump. — Scott • talk 16:42, 19 March 2014 (UTC)

• I have notified Urdu Wikipedia Village Pump (ur:ویکیپیڈیا:دیوان_عام/متفرقات#C:_shortcuts). I'll see if I can round up someone with Polish language skills to create the polish version of wikt:Appendix:Unsupported titles. John Vandenberg (talk) 20:08, 24 March 2014 (UTC)
  • Perhaps Olaf could suggest someone? See m:pl:wikt:Wikisłownik:Bar#Request for Comments: c: link prefix for Wikimedia Commons. — Scott • talk 12:23, 25 March 2014 (UTC)
    • Polish Wikisłownik has already Zasady tworzenia haseł ("Article creation guide") as well as pretty specific chapter on Nazewnictwo ("Naming conventions") that possibly could be expanded to document existing technical limitations.  « Saper // talk »  13:01, 25 March 2014 (UTC)
• For the reference of anyone who didn't see it - the RfD discussion for "C:" redirects at the English Wikipedia earlier this month was subject to a procedural closure as being dependent on the result of this RfC. As I read the comments over there, if consensus is found here for the implementation of this link prefix, the English Wikipedia community will respect it as a rationale for deleting them. — Scott • talk 20:32, 22 March 2014 (UTC)

• An update from Japanese Wikipedia: What I see as their position at large is, similarly to English Wikipedia, "pending until what the global community gathering at Meta will decide," while Penn Station seems uncomfortable with giving up the long-time administrative shortcuts including C:CSD. They said they would participate here, so I expect a more accurate explanation of the opposition will be provided soon. whym (talk) 09:59, 25 March 2014 (UTC) The local discussions are at ja:Wikipedia‐ノート:ショートカット#ウィキメディア・コモンズへのリンクに使える接頭辞として「c:」を新設する提案 and ja:Wikipedia:リダイレクトの削除依頼/2014年3月#3月11日から15日. --whym (talk) 10:05, 25 March 2014 (UTC)

Thank you, whym. Could you please remind the participants at Japanese Wikipedia that this RfC has now reached its end date and is waiting to be officially closed? Personally speaking, if it is just one user raising an objection, I don't think that can override the wider consensus here. I will look forward to hearing what Penn Station has to say. — Scott • talk 12:09, 25 March 2014 (UTC)

Sorry, I apparently overlooked Penn Station's edit in the "Oppose" section. If it was the participation he/she meant, then that was already done. whym (talk) 12:26, 25 March 2014 (UTC)

Implementation

Should gerrit:112920 and gerrit:113656 be merged, or should we just add to IWM and merge the latter? I would prefer to use gerrit:112920, since that is what Wikidata, Meta, etc. prefixes come from. PiRSquared17 (talk) 12:17, 25 March 2014 (UTC)

112920 strikes me as cleaner, but then again I'm not a dev so weigh my opinion appropriately... if you could get some more devs to weigh in (I did ask over at bugzilla:4676 but haven't had a reply), that would be great. — Scott • talk 12:28, 25 March 2014 (UTC)