Requests for comment/Set short project namespace aliases by default globally

Dialog-information on.svgThis is a subpage; for more information, see the Requests for comments page.


Many projects, including English or Czech Wikipedias, use WP as an alias for the project namespace (ie. Wikipedia: at Wikipedias; NS_PROJECT). I think it's quite an useful feature for projects to have, as it allows for short shortcuts like WP:NPOV to work as links, without cluttering the main namespace.

Right now, each project needs to separately request it. That creates a barrier for using this feature, as communities need to know they can request it (which is not always the case, especially for small new communities).

This proposal intends to make using this feature easier for new communities, similar to Small wiki toolkits iniciative.

Note: Communities without an active alias will be informed via massmessage.


Make two-letter project code as an alias for NS_PROJECT at all Wikimedia wikis. This means:

  • WP will be an alias for NS_PROJECT (ie. Wikipedia:) at all Wikipedias
  • WB will be an alias for NS_PROJECT (ie. Wikibooks:) at all Wikibooks
  • WV will be an alias for NS_PROJECT (ie. Wikiversity:) at all Wikiversitas
  • WS will be an alias for NS_PROJECT (ie. Wikisource:) at all Wikisources
  • WN will be an alias for NS_PROJECT (ie. Wikinews:) at all Wikinewses
  • WQ will be an alias for NS_PROJECT (ie. Wikiquote:) at all Wikiquotes
  • WT will be an alias for NS_PROJECT (ie. Wiktionary:) at all Wiktionaries

Proposed by: --Martin Urbanec (talk) 10:57, 18 February 2021 (UTC)

Note: This is already the case for Wikivoyages, which have a default alias of WV:. --Martin Urbanec (talk) 10:59, 18 February 2021 (UTC)

Some clarifications about the namespace aliasesEdit


To be honest, I didn't anticipate there would be some opposes in this proposal. But they are, and it seems they are based on incorrect understanding of namespace aliases and this proposal.

Clarification of the proposalEdit

I would like to make one thing clear:

This proposal is about providing a default set of namespace aliases to projects, not circumventing local communities or taking away some powers from them. If a project wishes so, they can simply decide not to use the alias (just as they can decide to not use one of the default provided namespaces, like Help:). Alternatively, they can request a different alias, or even request them to be removed altogether. That is all possible.

Usage of namespace aliasesEdit

Also, it seems that some of the opposers think this won't be actually used in the wikis. I do not think that's true. In fact, communities (even estabilished ones) request such aliases regularly, and even those who didn't have such a system, they just place the pages that should start with WP: into the main namespace.

I quickly looked into the data to provide some more insight into how this is already used in the projects we have. I looked into 100 of Wikipedias, and prepared (if someone is interested in the full data pre-aggregation, let me know and I can publish that as well).

The most interesting section is Aggregate data. If you scroll down there, it has several variables calculated:

  • NonzeroPrefixedPages – number of projects with non-zero number of pages in main namespace that start with WP:
  • ZeroPrefixedPages – the complement for NonzeroPrefixedPages
  • TotalProjects – total number of projects (ie. Wikipedias) considered
  • LessThanThousandContentPages – number of projects with less than a thousand of content pages (this is mostly for context, I wanted to know how many of the projects in the dataset are very small)
  • MoreThanOneShortAlias – number of projects that have more one short (defined as three chars long or shorter) alias for the project namespace
  • MoreThanShortAliasOrNonzeroPrefixedPagesMoreThanOneShortAlias plus NonzeroPrefixedPages

As you can see, 63 % of the analyzed projects use this sort of a feature, allowing them to shorten page name for pages in the project namespaces.

To summarize, I think this is actually a feature that's going to be used by the projects.

Best, --Martin Urbanec (talk) 00:07, 20 February 2021 (UTC)

@Martin Urbanec: There is absolutely no misunderstanding on my side. There is one massive oversight in your stats: you only looked at Wikipedia. Wikipedia in Afrikaans, Brezhoneg, Dutch, English, French, German, Lojban, Polish, Portuguese and Spanish is respectively Wikipedia, Wikipedia, Wikipedia, Wikipedia, Wikipédia, Wikipedia, Wikipedia, Wikipedia, Wikipédia and Wikipedia. Wiktionary in Afrikaans, Brezhoneg, Dutch, English, French, German, Lojban, Polish, Portuguese and Spanish is respectively Wikiwoordeboek, Wikeriadur, Wikiwoordenboek, Wiktionary, Wiktionnaire, Wikiwörterbuch/Wiktionary, Uikivlacukt, Wikisłowniku, Wikcionário and Wikcionario. Your proposal shouldn't have been for all the projects. It may make some sense for Wikipedia, but it's completely outrageous for Wiktionary. This proposal is actually 7 proposals in one. And all these various English-based aliases may result in unforeseen conflicts. You say that communities can request the removal of this new alias. But if they can do that.. what's the friggin' point? A universal shortcut that isn't universal? Sorry. — Alexis Jazz (talk or ping me) 12:33, 20 February 2021 (UTC)
@Alexis Jazz I didn't propose an universal shortcut. I proposed a default shortcut. An universal shortcut (like Project:) exists at all projects, and is intended to help users from other projects to navigate easily (which is not the purpose of my proposal). A default shortcut is intended to provide a default experience at all projects, that can be customized. As you can see, 44 % of Wikipedias use this feature without the alias itself. If the alias was set, the experience might be more similar to what they know from the other (often bigger) wikis. Opt out is simply more convenient for many projects, who do not have users who have a clue about what Phabricator is.
Ad "completely outrageous for Wiktionary", [citation needed]. I just ran the same script I used for Wikipedias for Wiktionaries. 10 % of Wiktionaries use a short alias already (additional 17 % have more than one page starting with WT: in main namespace). WT is the only alias reused by multiple projects. See for more details. Martin Urbanec (talk) 14:37, 20 February 2021 (UTC)
@Martin Urbanec: Just to note, it's a universal shortcut (not an) because "universal" is pronounced "youniversal". I know you're not a native speaker so I don't blame you, but it disrupts the flow when reading.
Thanks for the stats. I think they actually prove my point quite nicely. Out of a 100 tested Wiktionaries, WT is used by cswikt, dewikt, enwikt, and mywikt. That seems to be four instead of five, but it matters little for the result: not counting enwikt, three (or four) out of 99 Wiktionaries using "WT" doesn't exactly prove that all Wiktionaries are eagerly anticipating this shortcut. For your 17%, beware of pages like wikt:sr:WT:FAQ. These are untranslated pages that were imported from English Wiktionary. If this proposal was limited to Wikipedias I probably wouldn't oppose it, but as it is I do. As for your "citation needed", what are you expecting? I demonstrated how much more diverse the localized names for Wiktionary are, and with many of those a shortcut named "WT" makes no sense at all. You haven't provided any citation to clearly prove that WT is already widely accepted by Wiktionaries. (and frankly you couldn't, because it isn't)
Opt out is simply more convenient for many projects, who do not have users who have a clue about what Phabricator is.
That is a completely separate problem that should be addressed in other ways. — Alexis Jazz (talk or ping me) 00:24, 21 February 2021 (UTC)
Alternatively or in addition to a shortcut for Wikipedia, I could understand enabling a WT: shortcut for small Wiktionaries that are already intentionally using it (so excluding imported pages like the srwikt example) by creating WT: pages in main space. Perhaps that's a better method to explore for the other projects as well. — Alexis Jazz (talk or ping me) 00:32, 21 February 2021 (UTC)


  • I think this makes sense. Just for the record, there are no ISO 639-1 codes assigned to wp, wt, etc., so no problems will arise on that front. --MF-W 11:39, 18 February 2021 (UTC)
  •   Support, I really wanted this. -- CptViraj (talk) 14:14, 18 February 2021 (UTC)
  •   Support Uncontroversial. Camouflaged Mirage (talk) 14:18, 18 February 2021 (UTC)
  •   Support --გიო ოქრო (talk) 14:20, 18 February 2021 (UTC)
  •   Support Wikivoyage should be WY? Đức Anh (talk) 14:25, 18 February 2021 (UTC)
    @Đức Anh Wikivoyage already has a default shortcut, WY. Changing this is out of scope for this GRFC, I think. Martin Urbanec (talk) 15:10, 18 February 2021 (UTC)
  •   SupportT@hmid02016 (talk) 14:28, 18 February 2021 (UTC)
  •   Support --Novak Watchmen (talk) 14:33, 18 February 2021 (UTC)
  •   Question: Can the abbreviation be customized on a language-specific basis? For example, the Esperanto alphabet does not use the letter W. On Esperanto Wikinews it would be more appropriate to have this appear as VN:. (For comparison, Esperanto Wikipedia already makes use of VP: as the shortcut instead of WP:.) Aŭdrea (talk) 14:52, 18 February 2021 (UTC)
  • Yes, a good question: using a Latin-alphabet code on non-Latin-alphabet Wikimedia projects would be awkward and unacceptable to many. --Lanhiaze (talk) 14:56, 18 February 2021 (UTC)
    (as a note) For some projects, that might lead to a problem with the codes, f.e. Icelandic Wikiorðabók "wo" interfering with the code for Wolof. --OosWesThoesBes (talk) 15:07, 18 February 2021 (UTC)
@Audreycious Yes, they can. If any project would dislike the default provided shortcut, they would be able to request another one (either in addition to the default one, or in place of the default one), via the usual site configuration process (see Requesting wiki configuration changes). This does not force any projects to use (or have) such a shortcut, it only makes it a part of the default toolkit each project has by default. Martin Urbanec (talk) 15:12, 18 February 2021 (UTC)
  •   Oppose, you can already type «Project:» in any language project to switch to the Project: namespace. Thus, it would be easier to create a single two-letter code for the Project: namespace, something like pr or pj (neither of which would interfere with ISO 639-1 codes, by the way). As an example, try to copy «Project:الميدان» (without quotes) and paste it in any Arabic Wikimedia project. For this reason, I see no sense in creating multiple codes, one for every project, where a single code will do equally well. In addition, I would like to see some examples of how and where the proposed codes would be used. --Lanhiaze (talk) 14:53, 18 February 2021 (UTC)
    @Lanhiaze See w:WP:B for w:Wikipedia:Bots, w:WP:BP for blocking policy, w:cs:WP:NPOV for neutral point of view policy, w:sk:WP:NS for administrator noticeboard, ... Those are just the projects that already use such a shortcut. While you can use Project: as an universal way to get into a project namespace on a wiki in a language you don't speak, the usecase for this shortcut are different - they mainly serve to provide very short page names, to be easy to type as a wikilink. Best, Martin Urbanec (talk) 15:15, 18 February 2021 (UTC)
@User:Martin Urbanec, I still feel it would be easier to make it w:pj:B, w:sk:pj:NS, etc.; definitely easier to remember and possibly easier to implement. --Lanhiaze (talk) 17:39, 18 February 2021 (UTC)
@Lanhiaze Maybe easier to remember, but AFAICS unadopted by any project. The idea is to allow new/small projects to learn from bigger estabilished ones (where such aliases are usually a standard), which would not work if the alias was (much) different. Martin Urbanec (talk) 17:06, 19 February 2021 (UTC)
  • Just for reference, eswiktionary already defines WN (this stands for Wikinews in your proposal), while plwiktionary uses WS (Wikisource). See wikt:es:WN:AT and wikt:pl:WS:WS. Peter Bowman (talk) 15:22, 18 February 2021 (UTC)
    Thanks for the note. If the proposal is approved, we won't change existing aliases, merely add a default one that can be used, or also not, depending on the community. Martin Urbanec (talk) 15:25, 18 February 2021 (UTC)
    @Martin Urbanec and Peter Bowman: And nlwiktionary uses nothing, but WW or WB (WikiWoordenBoek) would make more sense. This proposal makes more sense for Wikipedia which usually doesn't have a localized name. WT is only valid English Wikitionary. I agree with Lanhiaze above, create a shortcut for Project:. — Alexis Jazz (talk or ping me) 09:51, 19 February 2021 (UTC)
  • Neutral  Oppose Thank you for answering my question, Martin Urbanec. I'm all on board with enhancing the toolkit for small wikis. That being said, I would prefer that this feature continue to be made available on an opt-in basis rather than an opt-out basis. There is something vaguely Anglo-centric about this for communities whose autonyms do not use the letters represented by the English abbreviations, or indeed may not even use the Latin script.
  • Related point: Small-wiki contributors who do not speak English may not find it intuitive that, say, WN: automatically redirects to [non-Latin script]. So this functionality might be frequently overlooked anyway. Aŭdrea (talk) 15:39, 18 February 2021 (UTC)
    I have changed this vote to an «oppose» per the below concerns. Upon further reflection, I think this proposal has the potential to cause unnecesary confusion and complication. Aŭdrea (talk) 18:04, 21 February 2021 (UTC)
  •   Support -- Abuluntu ( talk) 16:22, 18 February 2021 (UTC)
  •   Support --Zblace (talk) 16:37, 18 February 2021 (UTC)
  •   Support OK Leaderboard (talk) 17:35, 18 February 2021 (UTC)
  • This proposal may make sense for Wikipediæ, where many Latin-script communities use a name that can be abbreviated as WP (although quite a number of them with V instead of W), but much less for any other project except for Wikiversity (which already has the abbreviation). For example, no custom Wikiquote name has the abbreviation WQ (projects not appearing on the below list use the English names), but it’s also few and far between for other projects. By the way, at least in Hungarian projects it’s a custom to create these redirects without having the namespace alias, so pages like WP:WP are technically NS0 pages. If this change goes live, they need to be mass-renamed (which would actually be impossible in this case, as its NS4 counterpart exists), as they will become inaccessible. —Tacsipacsi (talk) 17:39, 18 February 2021 (UTC)
    The list supporting my comment has been moved away from here, see #Customized site names. —Tacsipacsi (talk) 11:27, 19 February 2021 (UTC)
    @Tacsipacsi Thanks for caring about the implementation details :-). MediaWiki has a standard maintenance script that is used after changing namespace aliases, which automatically moves pages around if they become unaccessible due to a new namespace alias. It can handle even cases when NS4 counterpart exists; it moves it to a different page title. For instance, if WP:WP and Wikipedia:WP both exist, the script moves WP:WP to WP:BROKENWP. Then, we can send affected communities a notice to review the renamed pages. It's basically the same procedure that's applied when new namespace alias is added to a single project. Best, Martin Urbanec (talk) 17:45, 19 February 2021 (UTC)
    @Martin Urbanec: Thanks for reassuring, good to know this. (I have never followed introducing namespace aliases closely. If I knew about this script being used for small-scale alias introductions, I would’ve probably guessed that it can be used on the large scale as well.) However, I still think that the goal of this RfC makes no sense for non-Wikipedia projects, so, to make it clear, I   Oppose it with the current scope. If the scope is narrowed to only Wikipediæ, I’m   Neutral about it—it’s right on a significant proportion of projects, although it’s probably still not an absolute majority. —Tacsipacsi (talk) 00:22, 22 February 2021 (UTC)
  •   Support I was anout to request this HitomiAkane (talk) 20:01, 18 February 2021 (UTC)
  •   Comment I would prefer the PR or PJ solution described above. To be honest, I dislike the project-dependent project namespace names. They create mostly confusion, and unnecessarily make sharing templates and project pages between projects more difficult. Ideally, "Project:" should become the default instead of "Wiktionary:" and similar. This is of course no longer a trivial uncontrovesial issue, and would need a new separate RFC. Taylor 49 (talk) 20:14, 18 February 2021 (UTC)
  •   Support per proposal. Sgd. —Hasley 21:13, 18 February 2021 (UTC)
  •   Oppose. "Project:" is already available and will work on any wiki – no need to change that. On the other hand, the proposed codes "WP"/"WB"/"WV"/"WS"/"WN"/"WQ"/"WT" (for those wikis that do not opt out) would impose an anglocentric code on these wikis (take for example Esperanto [eo] or the Latin language [la] where, if at all, "VP" would be more natural than "WP"). Thus, "WP"/"WB"/"WV"/"WS"/"WN"/"WQ"/"WT" would not be guaranteed to work. Removing a namespace alias later seems difficult (because this might break links that worked before). I therefore suggest to stick with the current situation (where "Project:" works in any case, and where individual wikis can request configuration changes if they actively wish these changes to happen). --UV (talk) 21:40, 18 February 2021 (UTC)
    @UV: I don't see anything in this proposal that would stop other wikis from still requesting additional ns shortcuts, is just an extra component and default part of configuration.  — billinghurst sDrewth 04:44, 19 February 2021 (UTC)
  •   Neutral For the same reason as predecessors. Though I support the idea in principle, it should be possible to localise the abbreviation (for example using VP: instead of WP:). --Eleassar my talk 01:38, 19 February 2021 (UTC)
    Each project can request either additional aliases, or even request removal of the default ones. This proposal merely aims to provide a default set of aliases (reasonably sensible in many languages), not forcing a project into something. Martin Urbanec (talk) 16:33, 19 February 2021 (UTC)
  •   Support. What about Wikidata? -Pavanaja (talk) 05:19, 19 February 2021 (UTC)
    @Pavanaja: This proposal is about projects with local versions (i.e. language versions with different domains). Wikidata is a multilingual project on its own, so it’s out of scope here. It has a large community, which can decide on its own whether a such abbreviation is needed. —Tacsipacsi (talk) 11:32, 19 February 2021 (UTC)
  •   Support This avoids proposal then submit that to phab for each wiki.--Semi-Brace (talk) 01:54, 19 February 2021 (UTC)
  •   Support with customized alias. Labdajiwa (talk) 05:35, 19 February 2021 (UTC)
  •   Support on behalf of af:wp. But please limit the quantity of new shortcuts implemented (Do not spam us!) Thanks, --Aliwal2012 (talk) 08:11, 19 February 2021 (UTC)
  •   Oppose This is indeed "vaguely Anglo-centric" as commented above. If a shortcut is needed at all, Lanhiaze's suggestion to create a single shortcut for Project: makes more sense. — Alexis Jazz (talk or ping me) 10:00, 19 February 2021 (UTC)
    • But as shortcut for "Project" is also anglo-centric. --MF-W 11:39, 19 February 2021 (UTC)
      It's true that a certain baseline of «anglo-centrism» is unavoidable (e.g. the URL will always read, etc.). But the advantage to Project: is that it is at least more internationally recognizable - compare ES proyecto, DE Projekt, EO projekto, RU проект, amid many others, and uniform across all wikis. By contrast, the proposed two-letter abbreviations run the risk of a) causing unforseen issues with existing namespace shortcuts; or b) bearing no relation to the autonym of the project at all - or even corresponding to the autonym of a different project in the same language. Ultimately, I think this proposal has the potential to cause as many problems as it solves. Aŭdrea (talk) 14:44, 19 February 2021 (UTC)
      @MF-Warburg: Indeed, but not as much. Also, as it would work on all projects, it would be more likely to become a meaningless initialism on any wiki where the word "project" or similar isn't commonly used. And being the same on all projects, it'll be easier to remember. This proposal is telling all Wikipedias that they should call themselves Wikipedia and while many do, some don't. It's also telling all Wiktionaries that they should call themselves Wiktionary, and it looks like the vast majority doesn't. — Alexis Jazz (talk or ping me) 12:53, 20 February 2021 (UTC)
  •   Comment I can see the value in such a proposal, but I also see problems where the relevant aliases have already been allocated. May I suggest therefore an alternative: that $WP rather than WP be the alias for NS_PROJECT and similarly that $WB, $WV etc be used as global aliases instead of WB, WV etc. I propose furthermore that any other such global symbols always have a "$" in their name. In this way editors know that such an alias comes from WMF rather than from the project itself. Of course, if there are technical reasons why "$" cannot be used, some other character can be "reserved". In making this suggestion, I am drawing on my experience of using DEC equipment for many years. Their policy was to always include a "$" in any vendor-supplied identifier, so the user knew that if they never used a "$", no clash would occur between their system-wide symnbols and the vendor's product-wide symbols. Ideally such a symbol would be part of the basic ASCII character set (which is a subset of all the ISO 8859 variants and also of UNICODE). Martinvl (talk) 16:19, 19 February 2021 (UTC)
  •   Question: What code will b e used for Wikimedia Commons? Martinvl (talk) 16:38, 19 February 2021 (UTC)
    This request for comment is only about providing a default value for Wikimedia projects with multiple language variants, like Wikipedias or Wiktionaries. Wikimedia Commons is a standalone project (one of its kind). As such, discussion about changing the aliases Commons uses is out of scope for this (and any other) global RfC.
    For the record, Wikimedia Commons already uses COM as an alias for Commons: namespace. If you wish to change that, it can be discussed at Wikimedia Commons directly. Martin Urbanec (talk) 16:56, 19 February 2021 (UTC)
  •   Oppose. A noble idea which I might support if it were properly justified. Why is it acceptable to override Wikipedia communities, but not Commons? Let each Wikipedia choose to make the change if needed. For now, cross-ns redirects work just fine for most projects. At most, if you find that such a change is required by many new communities, you could make it the default for new language projects.--Strainu (talk) 21:33, 19 February 2021 (UTC)
    @Strainu I don't intend to override anyone. Each project can either leave the alias alone (ie. not use it), or request it to be removed, if they wish. Commons is out of scope because it already has such an alias (for the same reason, Wikidata and WIkivoyages are also out of scope). As you can see above (and at; NonzeroPrefixedPages is the number), 44 % of Wikipedias simply put the short aliases (ie. starting with WP:) into the main namespace, which clutters it a bit. Isn't that a good argument to use this everywhere? Martin Urbanec (talk) 00:09, 20 February 2021 (UTC)
  • @Strainu: See my suggestion that all aliases that originate from WMF have a "$" in them, those that are developed within any particular community do not. In this way nobody will override anybody else. Martinvl (talk) 17:46, 20 February 2021 (UTC)
  • When you will enable the "WP:" alias, you will have to resolve all conflicts. How do you intend to do that without deleting the community-created shortcuts (which I call overriding the community)? It's also unclear how are those redirect cluttering the main namespace? I am not aware of any widely-used statistic that is affected by those (tens? hundreds?) redirects. Re Commons, your answer to the question above my vote suggests otherwise. You said there that Commons is out of scope because it is a standalone project, which is insulting for those of us working on non-standalone projects.--Strainu (talk) 15:18, 24 February 2021 (UTC)
  • @Strainu: I don't get your point. Commons has COM defined as alias for ns-4 (API query), there is no need of anything else. Enwiki has WP, as explained above. Rowiki has no aliases for ns-4 but uses pseudonamespace WP from main namespace. As I undestood it, these pages will be identified as ns-4 instead of ns-0. No need of doing anything by the community. Huwikt has no aliases for ns-4 and uses pseudonamespace WSZ. It's up to the community to move to WT, do nothing and ignore it, or to request alias WSZ instead of WT. --Vriullop (talk) 07:57, 25 February 2021 (UTC)
  • There are subtle differences between the two. See ro:WP:NPOV vs en:WP:NPOV, watch for the address bar and what it says at "Redirected from". There are also technical subtleties, such as having to delete the ns0 redirects (IIRC) and the fact that ns0 redirect will remain for other namespaces (e.g. H for Help). Not something the average user would notice, but experienced users will notice and require an explanation; the one Martin gave is equivalent to "it doesn't hurt and it's nice to have". That's not a good reason to impose a change on existing projects. I'm all for enabling this for new wikis, but not existing ones.--Strainu (talk) 08:56, 25 February 2021 (UTC)
@Strainu This RFC is about providing a default alias for all Wikimedia project families. Commons is a family of its own, and it already has an alias, and that's why it's out of scope here. There's no point about proposing anything for Commons. The same applies for Wikivoyages; they are also out of scope here, because the family already has such an alias. There's no insult against anyone working on a particular project, it's just that it's pointless to propose something that is already done ;).
Ad implementation of this proposal, MediaWiki can automatically resolve such issues by itself (namespaceDupes.php script). I talked about that a bit above. Martin Urbanec (talk) 13:50, 28 February 2021 (UTC)
  •   Support --Charitwo (talk) 00:09, 20 February 2021 (UTC)
  •   Support My primary wiki language is Telugu--Arjunaraoc (talk) 01:08, 20 February 2021 (UTC)
  •   Comment @Martin Urbanec: The project namespace is the one causing most confusion and mess. Ideally, it should be renamed to something like Internal: (same for all projects, ie wikipedia, wiktionary, wikidata, commons, ...), with a shortcut IN:, because that is what the namespace is usually or preferably used for. More aliases or more redirects do not necessarily make the world better. I am not surprised by billions of pages beginning with "WP:" in NS ZERO. People do not know how the namespace system works, and it is more complicated and confusing than it should be. After some further thinking, I withdraw my support for "PR" or "PJ". Let's make it simple and obvious: namespace Help: for help pages, namespace Internal: for internal pages. Taylor 49 (talk) 12:16, 20 February 2021 (UTC)
    I appreciate your comment @Taylor 49, but that's way more controversial than this one. A new RFC to discuss this idea can surely be opened. Martin Urbanec (talk) 14:39, 20 February 2021 (UTC)
  •   Support Kays (talk) 13:26, 20 February 2021 (UTC)
  • For non-latin languages, this is not really intuitive. Type WP:, then switch script to Hangul, and type the rest, this is just worse than using local shortcut, which is just "백:". Also, per Strainu. — regards, Revi 15:04, 20 February 2021 (UTC)
    • But is there a problem with the option existing on kowiki? --MF-W 15:17, 20 February 2021 (UTC)
      • What problem? It looks like this proposal is adding a new problem of its own. — regards, Revi 19:56, 21 February 2021 (UTC)
  • Somewhat   Oppose. Not very harmful but likely confusing. I would support a proposal to use WP as a shortcut to all projects named W***p**** (maybe there are some that still use main namespace redirects?). However, this proposal might be confusing for two reasons.
    • First: non-English Wikipedias already have their own shortcuts, for example, Ukrainian Wikipedia heavily relies on ВП: for our Вікіпедія: (Ukrainian for Wikipedia:) namespace, and I would very much prefer to avoid confusion between Project:B (Latin B, should be a shortcut for Bots) and Project:В (Cyrillic B, shortcut for Verifiability and one of the most heavily used shortcuts).
    • Second: any unification of shortcuts between projects will simply not work as different languages use different words. For example, the above-mentioned Project:В will bring you to a page on Verifiability in Ukrainian, but the same Project:В in Russian stands for Vandalism. It is too late to fix it, people are so much used to it. We are even used to Project:В leading to Verifiability in Ukrainian even though we changed the translation for verifiability and it starts with a different letter, but the shortcut is still there.
    NickK (talk) 00:37, 21 February 2021 (UTC)
    • To avoid confusion, I propose to do nothing in projects that already have an alias of 2 or 3 letters, whatever it is. --Vriullop (talk) 08:08, 25 February 2021 (UTC)
  •   Support --mirinano (talk) 12:13, 21 February 2021 (UTC)
  •   Support It will be useful for smaller wikis who do not have time to worry about technical settings or who use shortcuts from the main namespace. Other wikis may ignore these new aliases for shorcuts or may ask setting a local one replacing the default shortcut. --Vriullop (talk) 20:30, 21 February 2021 (UTC)
  •   Support - This would be helpful - Satpal Dandiwal (talk) 04:04, 24 February 2021 (UTC)
  •   Oppose This seems to be only helpful for latin Wikipedia's and users who use Latin keyboard, for others I see no benifit. Also per Tacsipacsi and Strainu. ‐‐1997kB (talk) 06:29, 28 February 2021 (UTC)
  •   Support, In my opinion, confusion is not here. Wikipedia: is can use in all language Wikipedia, never mind customized site names. So if there is an customized short alias, just add more one if not WP:. Other project is same to this. I think it will work well.--LaMagiaaa (talk) 10:42, 1 March 2021 (UTC)
  •   Support Makes sense. --Belwine (talk) 14:29, 3 March 2021 (UTC)
  •   Support This would make working on new wikis easier to navigate, as well. --Balyozxane (talk) 04:16, 13 March 2021 (UTC)
  •   Support Simpler. Veracious (talk) 00:22, 16 March 2021 (UTC)
  •   Support In small wikis, "WP:" for "Wikipedia:" is rendered as a main namespace, not a project namespace. RaFaDa20631 (talk) 12:03, 17 March 2021 (UTC)
  •   Support It would be useful and every project can choose additional ones if wants. JAn Dudík (talk) 21:36, 20 March 2021 (UTC)
  •   Support.--Vulphere 09:41, 12 April 2021 (UTC)
  •   Support - already present in many wikis, making it everywhere makes it easier everywhere. Romaine (talk) 13:31, 29 April 2021 (UTC)
  •   Oppose WV, because on Chinese Wikivoyage, we use that as pointing to Wikivoyage: namespace pages, no idea about others. --Liuxinyu970226 (talk) 23:19, 20 May 2021 (UTC)
    @Liuxinyu970226 I'm sorry, I don't understand why do you oppose this proposal. In the GRFC opening, I said "This is already the case for Wikivoyages, which have a default alias of WV", so yes, all Wikivoyages have WV as an alias to the project namespace (Wikivoyage: or alternative). This proposal will not touch or change that – Wikivoyages are essentially out of scope for this request, as they already have this feature. Could you explain why do you think this is not a good idea? Best, Martin Urbanec (talk) 15:32, 4 June 2021 (UTC)
  • {{support} - Wikimedia projects in Vietnamese will benefit from this proposal. Tân (talk) 14:33, 6 July 2021 (UTC)

Customized site namesEdit

Comment to this listEdit

@Martin Urbanec: So, you missed other* projects, where their namespaces are also localized, but using their local codes:

  • zhwiki: 维基百科 (zh-hans); 維基百科 (zh-hant)
  • zhwiktionary: 维基词典 (zh-hans); 維基詞典 (zh-hant)
  • zhwikibooks: 维基教科书 (zh-hans); 維基教科書 (zh-hant)
  • zhwikinews: 维基新闻 (zh-hans); 維基新聞 (zh-hant)
  • zhwikiquote: 维基语录 (zh-hans); 維基語錄 (zh-hant)
  • zhwikisource: 维基文库 (zh-hans); 維基文庫 (zh-hant)

@Zhuyifei1999: may have ideas where they are come from. --Liuxinyu970226 (talk) 23:23, 20 May 2021 (UTC)