In T392775#10775623, @hector.arroyo wrote:

I think the work done in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1139193 for this task may already be covered by the patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1138396 we are working on for T389474: CheckUser: Special:GlobalContributions should highlight temporary accounts, since we are moving the logic to determine the CSS classes to apply form CheckUser's GlobalContributions (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1137000) to core.

Those two patches are orthogonal. My 1139193 patch ensures that the user-related link colors are reported properly in various places (the api, the parser, etc); the 1138396 patch adds new user-related link colors. I believe the '396 patch should probably be rebased on top of the '193 patch.

@cscott Hi! What's the status of this task?

It is stuck awaiting review. It got to a C+1 and never managed to get merged. It's not clear which team is ultimately responsible for the review.

Change #1139193 merged by jenkins-bot:

[mediawiki/core@master] Add user-related link colors to LinkRenderer::getLinkClasses

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

Change #1167232 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/core@master] Revert "Add user-related link colors to LinkRenderer::getLinkClasses"

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

Change #1167244 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/core@wmf/1.45.0-wmf.9] Revert "Add user-related link colors to LinkRenderer::getLinkClasses"

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

Change #1167232 merged by jenkins-bot:

[mediawiki/core@master] Revert "Add user-related link colors to LinkRenderer::getLinkClasses"

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

Change #1167244 merged by jenkins-bot:

[mediawiki/core@wmf/1.45.0-wmf.9] Revert "Add user-related link colors to LinkRenderer::getLinkClasses"

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

Mentioned in SAL (#wikimedia-operations) [2025-07-08T16:32:34Z] <mszabo@deploy1003> tchanders, mszabo: Backport for [[gerrit:1167244|Revert "Add user-related link colors to LinkRenderer::getLinkClasses" (T392775 T398714 T398717 T398952)]], [[gerrit:rWFSP1167243d5f96|Revert "UserLinker: remove back compat with old arguments of UserLinkRenderer"]], [[gerrit:1167256|UpdateMessageJobTest: Read expected transver from latest (T398904)]] synced to the testservers (see https://wikitech.wikimedia.org

Mentioned in SAL (#wikimedia-operations) [2025-07-08T16:39:38Z] <mszabo@deploy1003> Finished scap sync-world: Backport for [[gerrit:1167244|Revert "Add user-related link colors to LinkRenderer::getLinkClasses" (T392775 T398714 T398717 T398952)]], [[gerrit:rWFSP1167243d5f96|Revert "UserLinker: remove back compat with old arguments of UserLinkRenderer"]], [[gerrit:1167256|UpdateMessageJobTest: Read expected transver from latest (T398904)]] (duration: 09m 10s)

Change #1167245 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Revert^2 "UserLinker: remove back compat with old arguments of UserLinkRenderer"

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

Change #1207792 had a related patch set uploaded (by Mszwarc; author: C. Scott Ananian):

[mediawiki/core@master] Add user-related link colors to LinkRenderer::getLinkClasses

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

Change #1208289 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/extensions/CheckUser@master] Don't add Show IP buttons when there's no data-mw-target

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

Change #1208289 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Don't add Show IP buttons when there's no data-mw-target

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

Change #1208330 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Replace GetLinkColours hook with a new one, supporting link text

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

Change #1210512 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Parsoid DataAccess: Support passing link texts to getPageInfo

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

Change #1210524 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/services/parsoid@master] AddRedLinks: Support coloring wrt. link text

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

Change #1207792 merged by jenkins-bot:

[mediawiki/core@master] Add user-related link colors to LinkRenderer::getLinkClasses

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

I've submitted all the patches needed for this task:

• The one that's been already merged is a modified version of the original patch from June-July (which was originally reverted because it causes too many links to be colored). After the changes, it takes into account both the link target and the link text to determine the link classes. This patch has effect only on content produced by the legacy parser (because Parsoid doesn't pass the link text to the relevant methods at this time)
• https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1208330 updates the GetLinkColours hook, introducing a replacement for it, GetLinkClasses. The signature is IMO more forwards-compatible and allows new data to be passed to this hook in future. Updating of this hook in theory isn't necessary for bringing the gray backgrounds to the Parsoid output, but makes the code cleaner (especially, around the hook invocation in Parsoid).
• https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1210512 adds support for accepting links with text in Parsoid's DataAccess class. On itself the patch brings no new effect, but lays ground for the next one.
• https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/1210524 actually makes Parsoid's AddRedLinks processor pass the link text where it's necessary. Combined with the above patches, it emits the mw-tempuserlink class on the relevant links.

Note that the patches don't affect ApiQueryInfo, for which I submitted T410880.

We reviewd this in CTT Tech Forum today. We're pretty uncomfortable with link color depending on the full link text. There are a number of subtle issues there with respect to HTML and URL encodings and language variants (language conversion can alter the digits in the temp account name, have you tested this?), and this approach seems pretty fundamentally incompatible with ApiQueryInfo T410880. Link colors need to be queryable in bulk, because they are typically used in postprocessing to update link colors for an entire page at once.

The alternative we'd like to suggest is to replace the string/HTML "link text" with just a boolean "default caption" or "default link text". This fits well with T410880: Update ApiQueryInfo to accept link text for linkclasses because it could just be one additional checkbox that would apply to all the links in a batch, and when doing a bulk query it would just requiring splitting the query in two -- one query for all the links with "default link text" and a second query for all the links with "non-default link text". Still doubles the round-trips, but this seems reasonable. Parsoid's DataAccess was designed to mirror ApiQueryInfo, because Parsoid still can operate in standalone mode as well as integrated with mediawiki, so Parsoid's integrated DataAccess would do the same two requests that a standalone API request would do: one call for all of the links with default link text, then a second call for all the others.

There are a number of subtle issues there with respect to HTML and URL encodings and language variants (language conversion can alter the digits in the temp account name, have you tested this?)

Thanks for pointing it out. I tested it locally in a few configrations, but for sure there can be one that I didn't think of and that will break (e.g. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1210512/comment/48a8d1f1_bf42e051/ ).

The alternative we'd like to suggest is to replace the string/HTML "link text" with just a boolean "default caption" or "default link text".

Would you suggest not to process the link text at all or just not to pass the text to the backend? If the former, I think it's might be impossible to find a solution to reliably color the links to temp. accounts – it's likely that a similar set of issues like T398714, T398717, T398952 happens again. If the latter, I think it's possible to settle on some solution, which doesn't involve passing the link text as much as this one.

What would be the "default caption" for a link in your proposal? Essentially, we'd be interested in recognizing links [[User:~2025-1|~2025-1]] (ns == User && pageName == linkText) and [[Special:Contributions/~2025-1|~2025-1]] (ns == Special && subPageName == linkText). I guess a definition that would satisfy both is going to be rather counterintuitive...

I'm thinking that the additional boolean parameter could be something like "isUserLinksMode". Then, the API clients would determine themselves if something is potentially a link to user page or contributions thay we may want to color gray, and the API would then return the additional classes (currently mw-tempuserlink). As an example:

This is of course moving the link text processing to a different place – in the API client, instead of the backend. But I think it may be more feasible, given that the client can know better the input structure, what to (un)escape etc.

I think a "include user link classes" might be a reasonable option. It seems like "default caption" could also work, if we carefully define the "default caption" -- for example, as matching the link title either completely, excluding the namespace, or in a special page subpath. Or maybe even just a trailing substring match, as long as the character before the substring is [:/] or start-of-string.

The other option considered, and I don't know what the final resolution was, was to accept mw-tempuserlink on more/most places that link to a temp user, and just to be more specific with CSS in applying the highlight. DiscussionTools adds a <span data-mw-comment-sig> preceding a signature block, for example, so the CSS could limit the grey background to [data-mw-comment-sig] + a.mw-tempuserlink for example. That is, instead of starting by applying styling to all mw-tempuserlink and then trying to restrict where that class appears, does it make more sense to apply mw-tempuserlink to all links to temporary users and then restrict where the *styling* applies?

In T392775#11410961, @cscott wrote:

That is, instead of starting by applying styling to all mw-tempuserlink and then trying to restrict where that class appears, does it make more sense to apply mw-tempuserlink to all links to temporary users and then restrict where the *styling* applies?

This might indeed solve the issue with signatures. However, it won't help in cases like pinging a temp. user (which I imagine will be hard to target using just CSS).

It seems like "default caption" could also work, if we carefully define the "default caption" -- for example, as matching the link title either completely, excluding the namespace, or in a special page subpath.

It might work. And, given that it's more general than my proposal, I think it's better than the "user links mode".

Or maybe even just a trailing substring match, as long as the character before the substring is [:/] or start-of-string.

Even though this has a potential for false-positives (e.g., see my analysis about [[User:Me/~2025-1|~2025-1]]), I think this is better generalizable (i.e., special pages won't be a special case in this rule, and it'll be defined for special pages with no subpage part). I'll update my patches with this approach in mind.

Change #1212112 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Link colors: use isDefaultCaption, instead of linkText

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

This task (or at least attributed to this task) has been noticed onwiki and not in the intended way. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#.mw-userlink_now_applied_to_non-interface_parts_(edit_summaries)

In T392775#11413903, @Izno wrote:

This task (or at least attributed to this task) has been noticed onwiki and not in the intended way. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#.mw-userlink_now_applied_to_non-interface_parts_(edit_summaries)

Yeah... I spent a good three hours trying to figure out why a number of scripts I wrote were suddenly not working. I thought that maybe I had done something, and spent a lot of time scratching my head over it. It wasn't until I finally asked for help that I realized that this was the cause. I normally would've attributed the sudden issues with something changing under-the-hood, but I happened to make some code improvements only 1-2 days beforehand and thought that it was something that I did...

Umm... is there a way that we can accomplish what's trying to be done here and while not affecting or breaking .mw-userlink, .mw-usertoollinks, etc. for those who use it the way that they've been doing?

Change #1167245 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Revert^2 "UserLinker: remove back compat with old arguments of UserLinkRenderer"

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

Change #1212439 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Fix mw-userlink class being added to broadly

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

Hi and sorry for breaking things...

The patch that we deployed did two things:

• Changed the code that adds CSS classes to user-related links, and
• Added the grey backgrounds for temp. account in content areas

Unfortunately, in the first part, the mw-userlink class was put in a wrong place, which we didn't catch (neither in July, when the patch was originally created, or now). This caused the ill behavior of some scripts that was observed on enwiki. I have prepared a fix for this problem andI'll ensure that it's deployed to production as soon as possible (which is probably Monday, because I don't think this issue constitutes a reason for an emergency deployment).

Apologies @Oshwah, a few of us missed this - we'll get the fix deployed on Monday.

Thinking through what to do here, now we've had a bit of time for discussion...

We had (before this task)

• mw-userlink meaning a user link in a non-content area <--- widely used, using this definition
• mw-tempuserlink meaning a temporary user link in a non-content area <--- less widely used so less disruptive to tinker with
• also mw-extuserlink and mw-anonuserlink equivalents

We need (for adding "Show IP" and UserInfoCard buttons)

• some way to recognize a user link anywhere (to add UIC in content area links)
• some way to recognize a temporary user link anywhere (to add Show IP)
• we don't need to recognize external or anon user links in content, but maybe someone will in the future, e.g. IPInfo and anon user links?

We tried

• adding mw-tempuserlink to content area links that look like user links <--- this didn't cause problems as far as we know
• adding mw-tempuserlink and mw-userlink to content area links that look like user links <--- this violated a long-held assumption and caused disruption

Proposals

(It would be nice to do something holistic here, beyond just the problem in this task)

• add brand new classes for links that looks like user links in content areas, with equivalents for the all different types of user
• expand all the user link classes to content areas, but allow a period of warning user to update scripts to scope them to non-content areas
• add a single new class to indicate that this a content-area link that looks like a user link, and let features decide for themselves what type of link it is

Change #1212584 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@wmf/1.46.0-wmf.4] Fix mw-userlink class being added too broadly

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

Change #1212439 merged by jenkins-bot:

[mediawiki/core@master] Fix mw-userlink class being added too broadly

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

add brand new classes for links that looks like user links in content areas, with equivalents for the all different types of user

This seems like the obvious way to go (maybe except the "with equivalents for the all different types of user" part).

Change #1212584 merged by jenkins-bot:

[mediawiki/core@wmf/1.46.0-wmf.4] Fix mw-userlink class being added too broadly

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

Mentioned in SAL (#wikimedia-operations) [2025-12-01T07:55:03Z] <mszwarc@deploy2002> Started scap sync-world: Backport for [[gerrit:1212584|Fix mw-userlink class being added too broadly (T392775)]]

Change #1208330 abandoned by Mszwarc:

[mediawiki/core@master] Replace GetLinkColours hook with a new one, supporting link text

Reason:

This is no longer needed in the "is default caption" approach

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

Mentioned in SAL (#wikimedia-operations) [2025-12-01T08:18:35Z] <mszwarc@deploy2002> mszwarc: Backport for [[gerrit:1212584|Fix mw-userlink class being added too broadly (T392775)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-12-01T08:33:38Z] <mszwarc@deploy2002> Finished scap sync-world: Backport for [[gerrit:1212584|Fix mw-userlink class being added too broadly (T392775)]] (duration: 38m 35s)

In T392775#11415755, @Tchanders wrote:

• adding mw-tempuserlink to content area links that look like user links <--- this didn't cause problems as far as we know
• adding mw-tempuserlink to content area links that look like user links <--- this violated a long-held assumption and caused disruption

typo? presumably the two cases aren't meant to be identical?

In T392775#11424695, @cscott wrote:

In T392775#11415755, @Tchanders wrote:

• adding mw-tempuserlink to content area links that look like user links <--- this didn't cause problems as far as we know
• adding mw-tempuserlink to content area links that look like user links <--- this violated a long-held assumption and caused disruption

typo? presumably the two cases aren't meant to be identical?

Yes, thanks for spotting that - updated the comment:

• adding mw-tempuserlink and mw-userlink to content area links that look like user links <--- this violated a long-held assumption and caused disruption

The patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1212112 implements the approach from T392775#11410961.

@cscott Could someone in CTT give it a glance and let us know if you're happy with this? We're happy with the approach.

As for doing something more holistic (T392775#11415755) that could be done later, on top of this work, and will be needed for tasks like T396709: UserInfoCard: Display icon button in DiscussionTools. Seems like the favoured option is:

• add brand new classes for links that looks like user links in content areas, with equivalents for the all different types of user