Considerations:

• Visual and source modes have different inspector behavior, and lots of our fancy behaviors will only apply to visual mode. Source mode just inserts the link wikitext -- if you put your cursor in it and deliberately trigger the inspector via the shortcut you'll see it, but it's much less amenable to the whole "you backspaced into this" stuff.
• T250332 could result in what's inserted by the autocomplete not being a link. If it's a template, entirely different behavior applies.

That said:

In visual mode we do have a lot of leeway to insert something which will on-save get turned into whatever the autocomplete replacement wikitext is supposed to be, but which behaves differently until then. For instance, our current behavior for signatures (in the rare places where you can access them in VE) is this:

...which is turned into the normal ~~~~ on-save.

This sort of fake block-level link would let us avoid people editing it outside of the username-picker. We could also style that however we wanted, if we don't mind breaking our normal "VisualEditor is a fairly-accurate preview of what will be posted" behavior.

Links becoming out of sync with their labels is not a problem unique to user links:

• In VE, press ctrl+k / cmd+k
• Type 2015, then enter to insert a link to 2015 ([[2015]])
• Press backspace and change the 5 to a 6
• Your link is still to 2015, but the label says 2016 ([[2015|2016]])

Links becoming out of sync with their labels is not a problem unique to user links:

Notably, we debated this general topic and behavior around it a lot while we were talking about the link-label field in the inspector in T55973.

I'm concerned about creeping perfectionism here. Let's get a link on the page. Let's let editors try it out. Let's let editors tell us if they want @ symbols added to the link labels, or if they want the user link locked in place, or anything else. Let's not try to guess the perfect behavior first.

For right now, I think we should treat this as https://en.wikipedia.org/wiki/Special:Search?ns2=1 with nothing else. Just search for a username, and make a link. For right now, I think that the link I get from the "mention" search should work exactly the same as a link I create with the regular link tool. That's consistent with the idea that this is a lightweight tool, and it's consistent with its status as a Beta Feature that can be changed in response to user feedback.

In T252083#6116848, @Whatamidoing-WMF wrote:

Let's get a link on the page. Let's let editors try it out.

For sure – I do not see this task, or anything being discussed in it, as blocking our plans to test the tool with people.

Where "people" means:

• People who are new to using Wikipedia talk pages (via T246190)
• People at our partner wikis who have experience using Wikipedia talk pages (via T252265)
• People from other projects who have experience using Wikipedia talk pages (via T246191)

Updating the task description to include the approaches @Esanders, @iamjessklein and I discussed this morning.

Note: as mentioned in T252083#6126549, we have not yet decided on an initial approach or prioritized deciding on said approach.

Feedback from @Demian
The "Issues with current treatment" are copied from this conversation: https://w.wiki/SEh.

The issues Aron surfaced below (some of which, like a link's text and target getting out of sync, we've talked about) lead me to think the best short-term approach is either: Approach #1A: temporary block that remains a link or Approach #1B: block that is treated as a template (see task description for details).

Note: I figure we can implement something more robust if it turn outs that @-mentions looking and behaving like regular links when people go from Visual --> Source --> Visual or if they were to edit an old comment presents issues.

Reasons:

• Approaches #1A and #1B seem like they will prevent issues I., II., and III. from occuring.
• In cases where people want to ping someone different from the person they currently created a ping for, I do not think the the level of effort and complexity in involved with 1) editing an existing @-mention to link to a different person's user page and 2) deleting an existing @-mention and creating a new one to link to someone else vary significantly enough for it to be worth preserving the "edit" functionality.

Next steps

• Discuss and decide on which approach to take next: Approach #1A: temporary block that remains a link or Approach #1B: block that is treated as a template.

Issues with current treatment

I. "Having "User:" in the link was surprising and I might have edited that part by mistake."

II. "Users without userpage are not offered by the look-ahead search."

III. "I've chosen a userpage, but the link text did not update, I had to find out how to do that too."

@ppelberg Thank you for the screenshots!

I think in lack of builtin templates the operational burden of installing a template on all wikis (including third-parties) for "Approach #1B: block that is treated as a template" is best avoided, therefore I'd go with "Approach #1A: temporary block that remains a link".

It seems like Approach #1B would be a lot more feasible as a parser function (ala T128535) rather than a template.

Documenting some the feedback @Dvorapa shared in https://www.mediawiki.org/wiki/Topic:Vmu502mrhvk3l7ex:

• The current treatment could lead people to think they've changed who they are pinging when in reality, only the link text has been changed (read: It's easy for the link target and text to get out of sync).
• In general, the current link inspector, in this context, is confusing. For example, the dialog does little to help people understand how to change who they are pinging.

Full text:

It was a bit confusing. I tried to rewrite the text as I would do on StackOverflow, but it rewritten just the text, not the user to be pinged. I know this is wiki code limited, but I would expect the popup to help me figure out, how to change user and edit text. The popup is completely confusing, the worst experience of the 2.0 version. First there is a link header that does nothing. I don't know, why is it there. Then there is a unlink button, which to me is unnecessary. Then there is an edit button. What exactly this edit button edits? After clicking it opens edit link menu. What? Why? Follows red link and question mark image. While this might make sense in terms of Wikipedia, for people with less experience this is completely confusing. Do I have a typo in the name? Does that mean the user does no exist? Don't get me wrong, the text in Visual mode should have red link, but this menu? Again, why? Finally there is this "Text" header, again not editable. I have to click the "change text" button. Which confusingly does nothing noticeable?It was a bit confusing. I tried to rewrite the text as I would do on StackOverflow, but it rewritten just the text, not the user to be pinged. I know this is wiki code limited, but I would expect the popup to help me figure out, how to change user and edit text. The popup is completely confusing, the worst experience of the 2.0 version. First there is a link header that does nothing. I don't know, why is it there. Then there is a unlink button, which to me is unnecessary. Then there is an edit button. What exactly this edit button edits? After clicking it opens edit link menu. What? Why? Follows red link and question mark image. While this might make sense in terms of Wikipedia, for people with less experience this is completely confusing. Do I have a typo in the name? Does that mean the user does no exist? Don't get me wrong, the text in Visual mode should have red link, but this menu? Again, why? Finally there is this "Text" header, again not editable. I have to click the "change text" button. Which confusingly does nothing noticeable?

In T252083#6191172, @kaldari wrote:

It seems like Approach #1B would be a lot more feasible as a parser function (ala T128535) rather than a template.

I wonder if a solution would be possible

1. without using <nowiki> for conciseness in source editor
2. without doing subst, so the wikitext remains the same when later editing a comment

I've been thinking about whether these would cause conflicts with other meanings:

1. [[User:NAME]] rendered as '@NAME': visible text changed from 'User:NAME' to '@NAME'.
   • Would change rendering of current talk pages in a non-confusing way.
2. [[@NAME]]: renders as '@NAME' currently
   • Changes the wikilink parser, conflicts with page names starting with '@' - if there's any
3. [[@:NAME]]: renders as '@:NAME' currently
   • Conflicts with the namespace '@' - if that's used, maybe by 3rd parties?
4. [@NAME]: rendered as '@NAME'
   • Changes the external link parser, no conflict with protocols like 'http?:*'
5. [@:NAME]: rendered as '@:NAME'
   • Changes the external link parser, no conflict with protocols like 'http?:*'

I'm not yet familiar with the code involved. From a uniqueness aspect I think some of these might be feasible.
The wikilink editor would be disabled for these in DT's visual editor, the link could be deleted as one entity.

In T252083#6191172, @kaldari wrote:

It seems like Approach #1B would be a lot more feasible as a parser function (ala T128535) rather than a template.

We should definitely consider it. I'd want to check with the people who worked on Echo to see what the potential issues are. It may also require changes to DisucssionParser in Echo.

If we go with 1A for now we can still easily switch to this or 1B later without breaking anything.

What would happen when you write [[User:NAME|OTHERNAME]]?

In T252083#6192301, @Lofhi wrote:

What would happen when you write [[User:NAME|OTHERNAME]]?

A link to the page 'User:NAME' that reads OTHERNAME. Ex.: OTHERNAME.

In T252083#6191323, @Demian wrote:

I've been thinking about whether these would cause conflicts with other meanings...

@Demian can you elaborate on what the ideas you shared above are in response to? Are they an effort to overcome certain constraints/side effects of Approach #1B? If so, which constraints/side effects?

...I ask the above in an effort to more clearly understand what you're describing and the implications of it.

In T252083#6196954, @ppelberg wrote:

In T252083#6191323, @Demian wrote:

I've been thinking about whether these would cause conflicts with other meanings...

@Demian can you elaborate on what the ideas you shared above are in response to? Are they an effort to overcome certain constraints/side effects of Approach #1B? If so, which constraints/side effects?

Yes, T252083#6191323 is a spin on @kaldari's idea:

It seems like Approach #1B would be a lot more feasible as a parser function (ala T128535) rather than a template.

The syntax alternatives I've proposed are neither templates, nor a parser function: it's an addition to the syntax of wikilinks or external links.
It could be considered an alternative for Approach #1B using a link instead of a template.

Kaldari's idea could be called #1C and the wikilinks #1D, if need be.

I don't want "1B" (the "let's put templates on every wiki" approach).

In T252083#6197066, @Demian wrote:

In T252083#6196954, @ppelberg wrote:

In T252083#6191323, @Demian wrote:

I've been thinking about whether these would cause conflicts with other meanings...

@Demian can you elaborate on what the ideas you shared above are in response to? Are they an effort to overcome certain constraints/side effects of Approach #1B? If so, which constraints/side effects?

Yes, T252083#6191323 is a spin on @kaldari's idea:

Understood – thank you for confirming this, @Demian. Initially, we're going to take Approach #1A: temporary block that remains a link. More details below.

DECIDED
Initially, we are going to take Approach #1A: temporary block that remains a link.

REASONS
We think Approach #1A will:

• Reduce the likelihood people will experience issues I., II., and III. described in T252083#6178541.
• Afford us the flexibility to revise this approach should other issues arise and/or more robust functionality be required (e.g. editing pings rather than having to delete and recreate them).
• Not require people at local wikis to do any kind of customization
• In cases where people want to ping someone different from the person they currently created a ping for, I do not think the the level of effort and complexity in involved with 1) editing an existing @-mention to link to a different person's user page and 2) deleting an existing @-mention and creating a new one to link to someone else vary significantly enough for it to be worth preserving the "edit" functionality.

The above is now represented in the task description.

In T252083#6220148, @ppelberg wrote:

Initially, we're going to take Approach #1A: temporary block that remains a link. More details below.

For future reference I've added a brief summary of #1C-#1E approaches, these are small alterations of #1A. I think #1D will be worth considering from a UX perspective at the appropriate time.

In T252083#6220736, @Demian wrote:

In T252083#6220148, @ppelberg wrote:

Initially, we're going to take Approach #1A: temporary block that remains a link. More details below.

For future reference I've added a brief summary of #1C-#1E approaches, these are small alterations of #1A. I think #1D will be worth considering from a UX perspective at the appropriate time.

Oh, that's helpful...thank you for doing this, @Demian.

Change 608073 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Create a PingNode so user pings are single focusable nodes

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

Change 608073 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Create a PingNode so user pings are single focusable nodes

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