I'm not incredibly familiar with namespaces, but it looks like this is happening because WikiBase declares the Property namespace whereas meta has no awareness of that namespace. I think is bug is similar to T380903: Display wiki-specific namespaces in external article links on Special:GlobalContributions but won't be resolved by that, as in this case the comment is being interpreted incorrectly and with what I know I'm not sure there's an easy way to fix those links without doing something odd in the comment parser/formatter pipeline.

Triaging this to the nice to have column for now as that's where we've prioritized the other namespace problems although we were able to do a good-enough fix for the other issue while waiting to see if we can do something more robust. Would it be preferable if there was no link formatting at all and instead just plain text, @Warudo? It might be a possible solution for now, assuming comments don't tend to link out.

In T398108#10992895, @STran wrote:

I'm not incredibly familiar with namespaces, but it looks like this is happening because WikiBase declares the Property namespace whereas meta has no awareness of that namespace.

I don't know exactly what's happening under the hood, but I don’t think that's what's causing this; as e.g. my edit here links to the testwiki page for [[Sandbox]] (in the main namespace), but GlobalContributions interprets it as a link to the metawiki [[Sandbox]] page instead.
It seems like this is a bug of all wikilinks in edit summaries pointing to that page on the central wiki, rather than necessarily the page on the wiki the edit was made.

In T398108#10992895, @STran wrote:

Would it be preferable if there was no link formatting at all and instead just plain text, @Warudo? It might be a possible solution for now, assuming comments don't tend to link out. It might be a possible solution for now, assuming comments don't tend to link out.

Assuming that edit summaries don't contain links doesn't really work because of Wikidata. Any edit that modifies a property contains a link to the property that was modified. So, unless you know what Property:P​2002 is without looking you need the links. In fact, something like T308811 is needed here as well. Not only should the links work, the label also needs to be loaded from Wikidata.

Despite that, I acknowledge that disabling the links is better than the current situation as long as there is some visual indicator that the links are there so anyone who sees it can go to the local wiki to find the link. I'm assuming that when you say plain text, you mean that the wikitext is shown with the angle brackets and all. If you meant to just delink the text, then no, that's worse than the current situation.

In T398108#10992895, @STran wrote:

Triaging this to the nice to have column for now as that's where we've prioritized the other namespace problems although we were able to do a good-enough fix for the other issue while waiting to see if we can do something more robust.

Nice to have makes no sense to me. This is a bug that breaks every single link in Special:GlobalContributions. Since when are working links just a nice to have? Also the justification doesn't make sense. This has nothing to do with namespaces or anything like that. It's just that Special:GlobalContributions assumes all the links to be pointing to meta when it shouldn't.

Sorry I think I may have misunderstood the issue. I thought the bug was only affecting Property: links as they were being interpreted as an interwiki wiki and falling back to being considered a local link as they aren't actually one but I see that A _smart_kitten's links are also being interpreted as local so instead then, I think this is an issue somewhere in CommentParser/CommentFormatter which probably never expected to have to translate plaintext local revision comments in a global context.

EDIT: If a link starts with a prefix that is both a namespace name and an interwiki prefix you can end up on the right wiki but the wrong page.

I think this is a separate issue and may be expected behavior? I'm not immediately aware of how you'd declare to the parser that you want <wikiId>: to be interpreted as that and not as part of a page title but it sounds like it should be discussed independent of this task.

I'm assuming that when you say plain text, you mean that the wikitext is shown with the angle brackets and all.

Yes, the raw/lightly-sanitized revision comment without any link processing. If that's acceptable I'll note this as a fallback acceptance criteria. Just quickly mocking this locally, instead of seeing "Wikipedia:Articles for deletion" as a red link, you'd see "[[Wikipedia:Articles for deletion]]".

In T398108#10995931, @STran wrote:

I think this is a separate issue and may be expected behavior? I'm not immediately aware of how you'd declare to the parser that you want <wikiId>: to be interpreted as that and not as part of a page title but it sounds like it should be discussed independent of this task.

If you think it's expected then you have misunderstood the issue, I'm afraid. Let's say I preform an edit in the English Wikipedia and I type [[Wikipedia:Articles for deletion]] in the edit summary. That link must point to https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion. That's its meaning in enwiki where the edit was made. However, in meta [[Wikipedia:Articles for deletion]] gets interpreted as https://meta.wikimedia.org/wiki/wikipedia:Articles_for_deletion instead. The issue then is exactly the same. Special:GlobalContributions interprets the link as internal to meta instead of enwiki, which incorrectly turns it into an interwiki link.

If a link starts with a prefix that is both a namespace name and an interwiki prefix you can end up on the right wiki but the wrong page.

The issue then is exactly the same. Special:GlobalContributions interprets the link as internal to meta instead of enwiki, which incorrectly turns it into an interwiki link.

Have I misunderstood the EDIT? I can replicate the former situation by creating an edit with a link to "[[Wikipedia:Articles for deletion]]" which links to https://en.wikipedia.org/wiki/Articles_for_deletion as expected. If I change my local namespace with $wgMetaNamespace = "Wikipedia"; then I see it start pointing to a local page (eg. /w/index.php?title=Wikipedia:Articles_for_deletion&action=edit&redlink=1). This is a different issue than comments assuming all links are internal.

No, that's not always expected. On the English Wikipedia, [[Wikipedia:Articles for deletion]] is supposed to link to https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion which is the same as https://en.wikipedia.org/wiki/Project:Articles_for_deletion, not to mainspace as "Wikipedia" is the name of the project namespace. On meta, it's supposed to link to https://en.wikipedia.org/wiki/Articles_for_deletion in mainspace as "Wikipedia" is the interwiki prefix for the English Wikipedia. Both of these are expected and correct. Therefore, when the link [[Wikipedia:Articles for deletion]] shows up in Special:GlobalContributions, its destination should depend on where the edit was made. If the edit was made on the English Wikipedia then it should lead to Project:Articles for deletion. If it was made on meta it should lead to Articles for deletion on the English Wikipedia.

In T398108#10997245, @Warudo wrote:

No, that's not always expected. On the English Wikipedia, [[Wikipedia:Articles for deletion]] is supposed to link to https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion which is the same as https://en.wikipedia.org/wiki/Project:Articles_for_deletion, not to mainspace as "Wikipedia" is the name of the project namespace. On meta, it's supposed to link to https://en.wikipedia.org/wiki/Articles_for_deletion in mainspace as "Wikipedia" is the interwiki prefix for the English Wikipedia. Both of these are expected and correct. Therefore, when the link [[Wikipedia:Articles for deletion]] shows up in Special:GlobalContributions, its destination should depend on where the edit was made. If the edit was made on the English Wikipedia then it should lead to Project:Articles for deletion. If it was made on meta it should lead to Articles for deletion on the English Wikipedia.

I think this has always been an issue with Special:CentralAuth as well. Random example from meta:SRG: https://meta.wikimedia.org/wiki/Special:CentralAuth/Semuel_Dolf_Runturambi shows a block on idwiki, but the link leads to https://en.wikipedia.org/wiki/Investigasi_pengguna_siluman/Mayor_jenderal_Semuel_Dolf_Runturambi instead of https://id.wikipedia.org/wiki/Wikipedia:Investigasi_pengguna_siluman/Mayor_jenderal_Semuel_Dolf_Runturambi. It works if you open CentralAuth on any Wikipedia language version, https://en.wikipedia.org/wiki/Special:CentralAuth/Semuel_Dolf_Runturambi correctly links to the idwiki investigation page.

By the way the link issue with GlobalContributions doesn't just affect wikilinks, but also section links in edit summaries (/* Section title */) which all point to meta.

Change #1170340 had a related patch set uploaded (by STran; author: STran):

[mediawiki/core@master] Support external wiki links in revision rows

https://gerrit.wikimedia.org/r/1170340

Change #1170340 merged by jenkins-bot:

[mediawiki/core@master] Support external wiki links in revision rows

https://gerrit.wikimedia.org/r/1170340

This was probably simple enough to bypass QA.

Seems like links in the Wikidata edit summaries is not fixed.

In T398108#11160303, @SerDIDG wrote:

Seems like links in the Wikidata edit summaries is not fixed.

I checked several Wikidata edit summaries in Special:GlobalContributions, all of them are fixed except for the automatically created edit summaries when reverting an edit in the main namespace. Compare your edit to this one which appears fine in Special:GlobalContributions. Notice that the edit summaries look different as well – even though there is a link, your edit summary is grey.