Page MenuHomePhabricator

Support recognizing temporary user links created in the "noping" way
Closed, DeclinedPublic

Description

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


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.

Event Timeline

Given the above outline, I propose that we take the option 3 ("do nothing").

Following a discussion on Slack, we're going to stick with Option 3 ("do nothing") for now. If we were to build an API for gadgets, it should happen in T372180.

JJMC89 changed the task status from Resolved to Declined.Dec 8 2025, 3:50 PM

In case a community is interested in updating their version of noping template, below is an example updated code of Module:No_ping, which can be used on wikis where the implementation is inspired by enwiki's.

-- This module implements {{no ping}}.

local p = {}

function p.main(frame)
	local args = frame:getParent().args
	return p._main(args)
end

function p._main(args)
	local ret = {}
	local fullUrl = mw.uri.fullUrl
	local format = string.format
	for i, username in ipairs(args) do
		local label = args['label' .. tostring(i)]
		local url = ""
		local targetUser = username
		if (username:sub(1, (mw.site.namespaces.User.name .. ':'):len()) == (mw.site.namespaces.User.name .. ':')) then
			targetUser = username:sub((mw.site.namespaces.User.name .. ':'):len() + 1)
		end
		if targetUser:sub(1, 2) == '~2' then
			-- Temporary user target; use internal contributions link
			url = mw.site.namespaces.Special.name .. ':Contributions/' .. targetUser
			url = format('[[%s|%s]]', url, label or username)
		else
			-- Named user target; use external link
			url = fullUrl(mw.site.namespaces.User.name .. ':' .. targetUser)
			url = tostring(url)
			url = format('[%s %s]', url, label or username)
		end
		ret[#ret + 1] = url
	end
	ret = mw.text.listToText(ret)
	ret = '<span class="plainlinks">' .. ret .. '</span>'
	return ret
end

return p

That code appears to work in the test cases... but only for Parser.php and not in Parsoid (via ParserMigration extension).

image.png (84×395 px, 9 KB)

Apparently Parsoid doesn't have the mw-tempuserlink class.

Apparently Parsoid doesn't have the mw-tempuserlink class.

Yes, Parsoid support is implemented separately, and the relevant patches are waiting for code review (tracked in T392775). Once they are merged and make it to wiki, both parsers should see the same behavior.

And on a separate social note to the above, there are some non-0 amounts of people on English Wikipedia that in the context of WP:SPI (not many other places, so I expect there will be some further thought) are tagging even temporary accounts (uh, how do I even explain tags -- the infrastructure of SPI has some reliance on categories containing prior socks and those categories are added by templates placed on user pages), and replacing this link with the contribs link is likely to cause consternation on that point.

But no_ping use is outside of that forum so I'll have to leave something on a talk page I guess.