Motivation
On pages like WP:SPI, some wikis use the external link syntax, so that the reported users are not pinged. These links may look exactly like their internal counterparts, with one exception – links to temporary accounts are not recognized and thus, have no gray background (nor Show IP etc.).
For consistency of on-wiki workflows, it should be possible to add the missing features of temporary account links to links in such places as well.
Acceptance criteria
- Temporary user links like these (https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/Fairyspit#08_November_2025) can have gray backgrounds and support for IP Reveal.
Proposed approaches
Option 1. Add a link class to external links
In this option, the effect is going to be similar to what's implemented in T392775 – external links with an appropriate text are going to receive a class, which can be then used for styling and by extensions to add their features to the links (such as "Show IP" buttons).
Advantages:
- Consistent UX – what behaves as a temp. user link looks like a temp. user link.
- Works out of the box, there's no on-wiki code which supports this gray coloring and additional features.
Disadvantages:
- It would make a precedent of adding "semantic" linkclasses to external links in core – currently, the only ones refer to the syntax from which a link was created.
- May require considering alternative URLs and URL variants – e.g., en.wikipedia.org, en.m.wikipedia.org, but maybe also meta.wikimedia.org (even if it's not the current domain).
- On wikis with variants, should we also recognize e.g., https://zh.wikipedia.org/zh-sg/ as a valid link beginning?
- Additional work on normalizing will be needed e.g. for index.php?title=Special:Contributions&target=~2025-1 to be treated as Special:Contributions/~2025-1.
- In general, this is untrivial and may require knowledge about extension's special pages.
- External links are currently not processed by the software in any special way (e.g., they don't cause pings, categorization, interwiki etc.). Here we're breaking that convention (slightly, but still).
Option 2. Provide an API for community to trigger Show IP by a local gadget
Alternatively, we can expose an API, so that a community can hook their templates and workflows, so that links are colored gray and all the additional features appear on demand, trigerred by some gadget.
Advantages:
- Communities may add the temporary account indications where it's expected, but no broader than that.
- It will also solve T372180: Allow third-party scripts to show "Show IP" buttons, which the community requested.
- We won't own the code handling the primary complexity of option 1 (URLs can be resolved in a context of local wiki needs, so no universal variant processing, the set of extensions is well known and expectations as well).
Disadvantages:
- There will be a number of gadgets on wikis, which will become desynchronized in a while.
- The gray backgrounds will require JS to work (even though the functionality per se doesn't need it).
Option 3. Do nothing
The convention in MediaWiki is that temporary accounts are linked to their contributions and not user page. It can be replicated in on-wiki templates, such as {{userlinks}}, which may have external link replaced with an internal contributions link. (eg. [.../wiki/User:~2025-1 ~2025-1] to [[Special:Contributions/~2025-1|~2025-1]]).
Advantages:
- No work needed at our side.
- Preserves the already-existing conventions and consistency (temp. accounts are linked to contribs and not user page; external links are not processed).
- Preserves the functional expectations from users (no ping).
- Uses the already existing functionality to support gray backgrounds, IP Reveal etc.
Disadvantages:
- Requires the communities to update their templates.
