Talk:Interwiki map

Interwiki request: remove

• prefix: git • global-search

• related Wikidata item: Wikimedia Gerrit (Q106171018)

Conflicts with language code. See phab:T360792. Has 700 uses so cleanup would be a pain, and this is a very theoretical issue and probably not going to come up, so feel free to decline this, but putting it here for the record. * Pppery * _{it has begun} 04:41, 29 April 2024 (UTC) Reply

I would be okay leaving it in place for now, but with the understanding that if a git language project materializes, developers are on the hook of migrating even more links in the future. Legoktm (talk) 04:31, 9 October 2024 (UTC) Reply

On the other hand it's better practice to link to "gerrit:" anyway now that Wikimedia Gitlab et. al are a thing. Still, there's no urgency here (as you can see from the fact that I let this lapse for six months without action), and this was largely a procedural filing, so I'm fine with leaving as is for now. * Pppery * _{it has begun} 04:27, 24 October 2024 (UTC) Reply

I propose introducing a replacement like gitiles: and at least initiating a migration. Of course there is no urgency so it does not have to proceed posthaste or anything but then we can at least move this to in progress. —Uzume (talk) 14:46, 16 July 2025 (UTC) Reply

I've added the gitiles: prefix pointing to the same place as "Git" since that seems uncontrobersial (especially since we have GitLab now so "git:" is ambiguous). I'm not going to spend any of my own effort migrating; others may do as they see fit. * Pppery * _{it has begun} 01:15, 13 October 2025 (UTC) Reply

Interwiki request: remove

• prefix: zum • global-search

• related Wikidata item:

Conflicts with language code. See phab:T360792. Has 100 uses so cleanup would be a pain, and this is a very theoretical issue and probably not going to come up, so feel free to decline this, but putting it here for the record. * Pppery * _{it has begun} 04:44, 29 April 2024 (UTC) Reply

It's highly unlikely I will take the initiative here unless actual effort toward creating a Kumzari Wikipedia happens. If someone else does the cleanup they could convince me to remove. * Pppery * _{it has begun} 22:36, 24 October 2024 (UTC) Reply

Interwiki request: remove

• prefix: twl • global-search

• related Wikidata item:

Conflicts with language code. See phab:T360792. Surprisingly few uses so suggest renaming to something longer. * Pppery * _{it has begun} 04:49, 29 April 2024 (UTC) Reply

See Talk:The Wikipedia Library#Rename twl interwiki. * Pppery * _{it has begun} 21:14, 1 July 2024 (UTC) Reply

@Pppery I don't mind this being updated to something else, it seems sensible to avoid language codes. Do you have any suggestions for a new prefix? wikipedialibrary: perhaps? Not sure if that would be too long. Samwalton9 (WMF) (talk) 13:28, 30 July 2024 (UTC) Reply

The English Wikipedia page en:Wikipedia:The Wikipedia Library lists the following shortcuts. w:WP:TWL, w:WP:LIB, w:WP:LIBRARY, w:WP:WIKILIB. "twl" is the current prefix. "Lib" has the same problem (w:Likum language). "Library" probably doesn't work because there are two other libraries on the interwiki map. That leaves only "wikilib" which is awkward and rarely used. Another possibility, in addition to that and the full name, is "wplibrary". * Pppery * _{it has begun} 15:13, 2 August 2024 (UTC) Reply

@Pppery wplibrary sounds good to me :) Samwalton9 (WMF) (talk) 16:09, 23 September 2024 (UTC) Reply

I've added "wplibrary" as a prefix, while leaving "twl". I'll copy over all uses and remove it the next interwiki update cycle (which probably won't be for a while). * Pppery * _{it has begun} 04:06, 24 October 2024 (UTC) Reply

Cleaned up a bunch of uses. Although now that I think about it it might make more sense to just leave both until a Shona Wikipedia actually approaches happening - incubator:wp/twl doesn't exist and the language isn't even enabled on translatewiki. * Pppery * _{it has begun} 22:27, 24 October 2024 (UTC) Reply

Interwiki request: Redirect..?

• prefix: quality • global-search

• related Wikidata item: Wikimedia Quality Wiki (Q33120967)

I noticed this as an entry at w:Help:Interwiki linking#Interwiki linking from and within Wikimedia, it's a closed wiki, all it gives you is a page with a manual redirect. Whatever way the {{Interwiki request}} template parses sort-of-kinda-internal URLs, it hates this one.

It has a "longform" IW link - [[quality:]]

Following the most relevant option at the redirect you end up at Wikiquality/Portal (actually located here on meta-wiki), which is itself a vestigial page with the {{historical}} template applied.

So, obviously not important, but maybe the target should be changed to save people the extra click.

One cookie (talk) 20:14, 24 February 2024 (UTC) Reply

Why would we need a shorthand to link to a closed wiki that has basically no content? —Justin (koavf) ❤T☮C☺M☯ 20:25, 24 February 2024 (UTC) Reply

We don't, but that is what we have already. It exists, I'm not requesting that it be created.

There's basically no content at the Special:AllPages link for the wiki because "this wiki has been closed and its content has been moved to meta.wikimedia.org". Some of the content you're looking for is at the correct address for the shortcut's target, meta.wikimedia.org/wiki/Wikiquality/Portal - but, since most of the content created for the project was as articles for a mailing list, the bulk of it is at listarchive:list/wikiquality-l@lists.wikimedia.org/latest.

The project was seen as important, enough so that it was given a shortcut link, and its link was used as one of the 29 examples of prefix codes included at w:Help:Interwiki linking, so what we currently do actually have is a shorthand link which: has been used, can be found on pages of projects which are not closed and which will be seen by users, was functional when it was used, is now broken and points to a dead page.

The shortcut should either be fixed or removed from that list, but removing it from that list won't remove it from anywhere anyone's ever used it, where it will remain an annoying broken link! One cookie (talk) 14:38, 25 February 2024 (UTC) Reply

"The shortcut should either be fixed or removed from that list". 100% agreed. I'd lean toward remove, as the quality wiki was closed a long time ago and I doubt there are any/many links, but that can be checked. Thorough response: thanks. —Justin (koavf) ❤T☮C☺M☯ 17:54, 25 February 2024 (UTC) Reply

┌─────────────────────────────────┘
I've fixed the template above. Don't feel comfortable removing this because we currently have a convention that each Wikimedia project has an interwiki link, which I don't want to break. I.e aa: exists too despite pointing nowhere. * Pppery * _{it has begun} 23:59, 28 April 2024 (UTC) Reply

Interwiki request: update

• prefix: etherpad • global-search
• updated formatter url: https://etherpad.wikimedia.org/p/1ドル
• related Wikidata item:

Currently, the formatter URL is 'https://etherpad.wikimedia.org/1ドル'. Each time this interwiki link is used, users need to manually add the '/p/' prefix to make it work correctly. It would be helpful to update the formatter URL to include this prefix, so users don’t have to add it manually each time. As of now, out of 5,582 pages, 4,948 are already using the correct prefix..-❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 08:05, 8 July 2025 (UTC) Reply

Hence if I were to change this all 4,948 of those links would stop working, right? * Pppery * _{it has begun} 16:27, 13 July 2025 (UTC) Reply

Yes @Pppery. Technically it will. But it can be easily get fixed with a bot right.- ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 16:39, 13 July 2025 (UTC) Reply

Running a bot to fix thousands of pages on hundreds of different wikis is not easy in my book. * Pppery * _{it has begun} 16:54, 13 July 2025 (UTC) Reply

It would surely make sense to change this, however, it needs someone to run a bot fixing all links. -Barras talk 23:40, 13 July 2025 (UTC) Reply

So when I checked last the majority of the links are on meta, mediawiki, wikidata, commons and dewiki (more than 100). So If that's the case I can request the permisson to run my bot (GnoeeeBot) to fix this.- ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 06:11, 14 July 2025 (UTC) Reply

Follow up to this, I have started the discussion for the bot flag at here.- ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 17:06, 23 July 2025 (UTC) Reply

@Pppery. I plan to run my bot to update the existing Etherpad interwiki links so they continue working correctly after the formatter URL change. Before I start, I’d like to hear your advice on the best timing for this—should I wait until the formatter URL is updated, or begin preparing the fixes in advance? ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 11:34, 21 August 2025 (UTC) Reply

My thinking is that it would be best for the bot to be seen as fixing rather than breaking links at the time, otherwise people are likely to revert it. Which I was going to do now (subject to the usual fact that interwiki map updates need a config change deploy), but then I discovered phab:T402554. * Pppery * _{it has begun} 16:10, 21 August 2025 (UTC) Reply

@Gnoeee if these are going to be fixed, can the http:// be changed to https:// at the same time? — xaosflux ^Talk 12:51, 26 July 2025 (UTC) Reply

That's an error in the request itself. The current formatter URL at Interwiki_map/list is already HTTPS. * Pppery * _{it has begun} 14:35, 26 July 2025 (UTC) Reply

I have updated the request.-❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 19:09, 26 July 2025 (UTC) Reply

Things have changed a bit given phab:T415237 deleting etherpads and some (hopefully all interwiki uses, but you never know) being backed up. I've setup a quick tool at https://etherpad-redirector.toolforge.org. What it does is:

• https://etherpad-redirector.toolforge.org and https://etherpad-redirector.toolforge.org/p/ redirect to https://etherpad.wikimedia.org. This means that links with no path will work.
• https://etherpad-redirector.toolforge.org/<padname> and https://etherpad-redirector.toolforge.org/p/<padname>, where padname is one of the pads listed in P89822, redirects to https://etherpad-backup.toolforge.org/p/<padname> (example: https://etherpad-redirector.toolforge.org/2015-08-19_NYC-WikiWednesday, https://etherpad-redirector.toolforge.org/p/2015-08-19_NYC-WikiWednesday
• Otherwise https://etherpad-redirector.toolforge.org/<padname> and https://etherpad-redirector.toolforge.org/p/<padname> redirect to https://etherpad.wikimdia.org/p/<padname>. Examples: https://etherpad-redirector.toolforge.org/p/aa, https://etherpad-redirector.toolforge.org/p/aa

I propose to change the "etherpad:" interwiki to point to "https://etherpad-redirector.toolforge.org/1ドル", which seems like it's a best of all worlds scenario. What do people think? * Pppery * _{it has begun} 05:19, 8 March 2026 (UTC) Reply

If there are no further comments I intend to perform the above change on April 30 when the etherpad instance is wiped. * Pppery * _{it has begun} 01:00, 20 March 2026 (UTC) Reply

So if a new pad is created after the purge with a name which was already used before, the interwiki link would always point to the backup? I don't think that's a good idea. --Tkarcher (talk) 06:02, 20 March 2026 (UTC) Reply

I was trying to avoid the need for a messy thousands-of-edits bot run, especially since it seemed to me like pad names were unlikely to be reused (if there was going to be a name reuse problem then there would have been one already). Bot I guess we need a messy thousands-of-edits bot anyway for URLs so you could replace with the etherpadbackup: interwiki I added a while ago ... * Pppery * _{it has begun} 00:14, 21 March 2026 (UTC) Reply

I'm not personally asking for the addition to be reversed; but I thought that this was probably worth noting (as it doesn't appear that this was mentioned in the most recent discussion) -- the interwiki github:, which was added to the interwiki map in March (Talk:Interwiki map/Archives/2026 § github), was previously requested & declined in January 2017 (Talk:Interwiki map/Archives/2017 § GitHub). Best, ‍—‍a smart kitten _[meow] 09:26, 5 May 2026 (UTC) Reply

Thanks for the information. Krinkle's argument regarding VisualEditor is a good one. NguoiDungKhongDinhDanh 17:45, 5 May 2026 (UTC) Reply

I don't agree with Krinkle's comments there. The so-called "illusion of stability" on which his argument hinges isn't really an illusion as GitHub realistically won't change its URL format given how often it is linked to ... * Pppery * _{it has begun} 05:56, 13 May 2026 (UTC) Reply

(pinging @Krinkle in case you have any thoughts/opinions) ‍—‍a smart kitten _[meow] 21:05, 13 May 2026 (UTC) Reply

Personally, I find interwiki prefixes most useful when:

1. It is at least sometimes easier to handwrite the interwiki link than to obtain and copy the URL.

2. Upon reviewing a diff or editing a link, one is not likely to need to expand/convert/open the link.

3. The linked form is a common and useful link label all by itself.

I'd want an interwiki link to be something you can write and have it just work. This holds up when there is a concept you're likely to have easy access to (e.g. article name, user name, Q-id, Phab task number), or if you can blindly write a query that care about the exact server response (e.g. a search). This can be easier to write than performing an action and copying the URL. Writing w:Banana is quicker than navigating to the article and copying its URL. Writing google:Banana is quicker (and more privacy-preserving) than performing a search and copying its URL.

Likewise, when editing or reviewing wikitext with such a link, it often does not matter what's on the other end. The intent is clear and (usually) independent of the server response. Editing such link is not likely to require translation from/to the real link. Does this hold for GitHub?

• Is it likely that someone creating a link will remember precisely (or have copied) the string gruntjs/grunt-legacy-log-utils/issues/3, without access to its URL https://github.com/gruntjs/grunt-legacy-log-utils/issues/3.
• Can you review such a link without manually expanding it to a URL and opening it?
• Can you edit/replace such a link without browsing GitHub and working backwards from having the new URL?
• Are "github:gruntjs/grunt" or "github:gruntjs/grunt-legacy-log-utils/issues/3" preferred as link labels?

I don't think my personal experience should matter. But, personally, it does slow me down and creates more work when I see such links in diffs and when editing wikitext. When linking to a repository, pull request, or issue; I have the URL already open. Creating a link (or editing an existing link) in wikitext by pasting the URL is quicker and easier, than having to extract and integrate a portion of it (when a previous editor, or VisualEditor, saved it as an interwiki link).

I'd love to hear what @Pppery and others like about having GitHub as an interwiki prefix? Krinkle (talk) 22:30, 13 May 2026 (UTC) Reply

I was thinking about it in the context of a repo author and name - I can remember things like "gruntjs/grunt" myself without browsing GitHub. But really, I don't see the harm in having it, especially since 207 people have apparently found it useful. That's dozens of times more than any of the other recently added interwikis. * Pppery * _{it has begun} 21:39, 16 May 2026 (UTC) Reply

In fairness, I assume it's hard to know how many of those ~200 cases will have been VisualEditor (or VE in DiscussionTools) automatically converting a full URL to an interwiki-link, rather than it being the author's active intention to use the interwiki over the full URL. If I'm understanding correctly, it might therefore just be that links to GitHub in general are made a lot more often than links to the target websites of other recently added interwikis. Best, ‍—‍a smart kitten _[meow] 05:49, 17 May 2026 (UTC) Reply

Ping Star walker as a courtesy since they requested the interwiki be added (under their prior username). * Pppery * _{it has begun} 21:40, 16 May 2026 (UTC) Reply