Actually, this seems not specific to DiscussionTools.

@KColeman-WMF Another idea that would have a much lower technical lift: add a "View user info" menu entry in the DiscussionTools overflow menu.

That would be much simpler, although we'd have to figure out where the popover should attach to -- it would probably be simplest to have the popover connect to the ellipsis menu, although it might be possible to figure out how to get it to point to the username in the signature for the comment.

@kostajh I would prefer if we can keep the entry point consistent across pages so users can build the muscle memory for it and use it effortlessly without needing to remember how to trigger it based on where they are. If we implement it one way now it would be confusing to change it later.

In T396709#11030264, @Niharika wrote:

@kostajh I would prefer if we can keep the entry point consistent across pages so users can build the muscle memory for it and use it effortlessly without needing to remember how to trigger it based on where they are. If we implement it one way now it would be confusing to change it later.

I agree with this. I'd also be wary of triggering a popover from a menu button, as it feels like we are getting into multiple popups territory.

Fair enough, let's not go with the overflow menu proposal.

I think this would be useful not only in DiscussionTools but also in Convenient-Discussions :)
fyi @Jack_who_built_the_house

Please provide a public API if it's not available already so that tools like Convenient-Discussions could hook up.
Update: Created T405008: Provide a flexible public API for UserInfoCard.

We should break this down into a few smaller tasks.

This is sort of complicated for DiscussionTools to handle because it doesn't deal with usernames, it deals with "signatures". A signature doesn't have to contain a username, notably. The only requirements are a timestamp, and a link to one of the user page, user talk page, or user contributions.

The flow here is:

1. Someone posts a comment and signs it with ~~~~
2. That’s substituted with the signature wikitext, which is generally a link to the user page followed by a timestamp, but can be heavily customized so long as some rules are followed.
3. DiscussionTools comes along later and detects signatures of all types in the Parsoid DOM output, in a fairly flexible way.
4. DiscussionTools sticks a bunch of markers into the DOM for later use. These get into the parser cache.
5. As a post-processing step, DiscussionTools replaces those markers with its actual output.

The problem here for you is that at no point does DiscussionTools do something we could call "rendering a user link". There's never a point where it would make sense for it to use UserLinkRenderer, or even to call that hook manually itself.

(In fact, choosing to not engage with the contents of a signature was a deliberate design decision that let us avoid a whole bunch of hubbub about custom signatures. We felt that the only way it'd work would be if we stopped custom signatures working, e.g. the debug view here, and we judged that to go against the mandate we had from the community consultation.)

There's further exciting issues to consider: what about other user links inside parser output? What if someone has pinged some users inside their comment?

Arguably it'd make the most sense for Parser.php / Parsoid to handle this, but you'd need to consider changes to our parsed output and whether that'd break things people expect. You'd also need to write it in a way that it could be completely disabled by CSS, because we presumably wouldn't want to split the parser cache for this. (Concerns like this are why the grey highlight for temporary usernames also aren't applied within parser output, as I understand it.)

The drawback to applying it post-load with a JS API you provided, as was requested for Convenient Discussions, would be that this changes the layout of the page -- a sudden flash of all the text on a talk page reflowing because every single signature now takes up 20px more horizontal space is going to cause some problems with things like following header/comment permalinks.

In short: using the overflow menu would be significantly simpler.

In T396709#11185798, @DLynch wrote:

The drawback to applying it post-load with a JS API you provided, as was requested for Convenient Discussions, would be that this changes the layout of the page -- a sudden flash of all the text on a talk page reflowing because every single signature now takes up 20px more horizontal space is going to cause some problems with things like following header/comment permalinks.

I can be corrected by @Jack_who_built_the_house, but for CD is ok :) СD is currently redrawing part of the interface to display normal signatures.

Yeah, it's fine if you're already doing it, but DT has avoided it so far.

Change #1248313 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/DiscussionTools@master] CommentFormatter: Add DiscussionToolsAddSignatureMarkup hook

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

Change #1248315 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/CheckUser@master] UserInfoCard: Extract shared button rendering logic

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

Change #1248316 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/CheckUser@master] UserInfoCard: Add DiscussionTools signature hook handler

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

Change #1248389 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[integration/config@master] Zuul: Add DiscussionTools as CheckUser dependency

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

Change #1248389 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/extensions/CheckUser] Add DiscussionTools dependency

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

Convenient Discussions now displays User Info cards on discussion pages! 🥳