VisualEditor: Link input widget should have separate inputs for target and display text
Open, Needs TriagePublic


The link input widget should have separate fields for the link target and the displayed text.

From various comments at T50789

There are essentially two ways to create a link:


#2 You click the link button first, enter the target and get out of the dialog, at which point the link text (identical to chosen link target) will be entered.

With this method, the user will often have to adjust the link's text afterwards, for instance in the case of plurals or if the target article is disambiguated with parentheses. But it is not clear to the user that adjusting the link text is safe and won't create a broken link; indeed the crucial distinction between link text and link target remains obscure. (Changing a singular to a plural is especially difficult since editing links at the end is not allowed.)

I have checked the workflow of entering links in LibreOffice, Gmail and Word; they are all basically the same as in the Visual Editor, with two major differences:

a) the dialog popup window has a clear OK button, and [T54462]

b) the dialog popup window contains separate clearly labeled boxes for the link text and the link target.

I believe both of these changes make a lot of sense.

An English Wikipedia user comments that the current behaviour of the input widget is not intuitive at all:

"I clicked the link tool while not focused on any text, to try and add a new link. I got a largely empty box with no instructions, and the next word in the article highlighted within the box. I fiddled with it a few times, and still don't know if typing in the box A. changes the text of the link. B. allows me to select more words. C. Changes what is linked to, or D. is followed by another, nearly identical box for a secondary function"

To me this is further evidence that we need two boxes: one to enter the link target and one to enter the link display text. The second box would default to the same as the link for internal links and for external links either (ideally) the page title or (less ideally but probably easier) the filename sans extension.

See also T53438

Adam Cuerden comments again on the suggestion to have separate boxes for link target and link title:
"Yes [that would be better], but do make sure it's on the same page. Don't give one dialogue, then a second. Also, if one of the boxes is left blank, it should be auto-completed from the other box. "

For the second part of the comment they mean that if someone gives a link target (e.g. Fish) and doesn't specify any title, produce a link: [[Fish]]
If someone gives a link title (e.g. Hedgehog) but doesn't specify a target, produce the link: [[Hedgehog]].

Version: unspecified
Severity: enhancement
See Also: T52945


bzimport set Reference to bz53973.

This is not a WONTFIX, but it comes close in terms of making the user experience too heavy (for detailed reasoning, see endless bugs passim).

  • Bug 51438 has been marked as a duplicate of this bug. ***
Elitre added a comment.EditedSep 2 2014, 11:46 AM

Copy Google Docs solution?

To elaborate, I don't think that labelling this solution as "ugly" is a strong rationale to why it shouldn't actually work for us. I'm fairly sure there must be a fair amount of research behind something that Google came up with for millions of people, and editors are constantly confused by our current interface instead.

Melos added a subscriber: Melos.May 17 2015, 6:29 PM

I've made some edits yesterday evening with VE in order to add an external link. Here is what I did:

  1. select the text
  2. click on the link icon
  3. type my URL in the field
  4. click on "Done" button
  5. See a red link
  6. Realize there is a special tab for external links
  7. Start again...

The same happens to me quite all the time. :/

@Trizek-WMF: It's supposed to automagically switch to the External links tab if you type "http://" at the start. Is the automatic detection not working for you?

@Whatamidoing-WMF Works with Chromium, but not on Firefox (38.0 canonical 1.0 for Ubuntu).

Changing a wikilink to an external link is not so smart, because text in the External links tab is not automatically selected, and therefore needs to be selected before being replaced by typing or pasting.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 22 2015, 3:57 PM
Cirdan added a subscriber: Cirdan.Feb 8 2016, 6:32 PM
Cirdan awarded a token.Feb 8 2016, 6:42 PM
Cirdan rescinded a token.
Cirdan awarded a token.
MartinK added a subscriber: MartinK.
Tacsipacsi edited the task description. (Show Details)Feb 21 2016, 9:40 AM
Jdforrester-WMF closed this task as "Declined".Feb 22 2016, 8:58 PM

With the benefit of four years' discussion in dozens of places, I'm now happy to conclude that this is indeed Declined.

With the benefit of four years' discussion in dozens of places, I'm now happy to conclude that this is indeed Declined.

Because of...?

Cirdan added a comment.EditedFeb 23 2016, 8:03 PM

I'd like to second this question. You could at the very least state the reason why you decline this, as from this feature request it's not clear at all why one would not add this little, extremely helpful textbox in the link widget.

I'd like to third this question.
In informal discussions of VE this is one of the most frequent issues brought up. Indeed I'm astounded that anyone could be "happy" at this decision.

Thinking more about it, that you have had to have discussions about it in "dozens of places" (none of which are linked so we can verify this) suggests that actually there is a very strong desire for a two-box solution.

WONTFIXing something that is so strongly desired by the editing community needs justification, particularly why two boxes would "mak[e] the user experience too heavy" - the only explanation actually given, and that was a musing two years ago.

The only current way to be sure that both link target and link title are correct when editing is to delete what is currently there, write the title, select it, and then create a link. I am unable to correlate this with the goal of creating an editing interface that makes editing easy.

Cirdan reopened this task as "Open".Feb 26 2016, 9:32 PM
Cirdan raised the priority of this task from "Lowest" to "Needs Triage".

Sorry Jdforrester, I re-opened this task. I don't doubt that a lot of thinking went into this idea - but could you please provide a concise summary of the reasons you don't want to see this implemented? Again, I don't doubt that there are good reasons, I just don't see any and haven't seen a discussion anywhere. Thank you!

NicoV added a subscriber: NicoV.Mar 1 2016, 12:50 PM
Krinkle removed a subscriber: Krinkle.Mar 8 2016, 10:20 PM

It's now approaching two months since this was declined without adequate explanation and reopened pending that explanation. Please can we now have the reasoning (or a pointer to it) that led to the decline - this remains the biggest single hindrance to simple, intuitive use in my experience.

DLynch added a subscriber: DLynch.Apr 13 2016, 2:50 PM

Off in T124305 there's a patch to make it easier to select the link-contents, which avoids many of the issues a "display text" field has (most notably: it's not just text). It's held up on general "what design do we want?" concerns.

Add Comment