Standardize link text and URL terminology across the editor

[afercia]

Description

Links and navigation links / submenus can be edited in the editor via a few components.

Although these user interfaces come from different components, the terminology should be consistend when it comes to:

• The link text.
• The link URL

RIght now, the names of these fields are different and don't contribute to UI clarity, especially when they can be displayed at the same time under the eyes of the users.

• The link editing UI uses the terms 'text' and 'link'.
• The block inspector for navigation links and submenus uses the terms 'label' and 'url'.

I'd vote for what makes most sense for users and I'd think the most familiar terminology for users is text / link.
Regardless, the UI should use the same terminology everywhere.

Screenshot when editing a page link in a navigation:

Screenshot when editing a custom link in a navigation:

The same applies to navigation submenus.

Step-by-step reproduction instructions

• Go to the site editor > Design > Navigation > any menu
• Make sure the Settings panel is open.
• Edit a link by clicking on it, then click 'Link' in the block toolbar and then the 'Edit link' pencil icon button.
• Observe the link editing UI in the popover uses the terms Text / Link while the block inspector uses Label / URL.
• Repeat for various link types: Page link, Custom link...
• Repeat for a navigation submenu.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[afercia]

Some of the relevant files to be checked:

packages/block-editor/src/components/link-control/index.js
packages/block-editor/src/components/link-control/search-input.js
packages/block-library/src/navigation-link/edit.js
packages/block-library/src/navigation-submenu/edit.js

[richtabor]

I had this queued up to write an issue for as well. Yes, we should tweak this.

I'd vote for what makes most sense for users and I'd think the most familiar terminology for users is text / link.
Regardless, the UI should use the same terminology everywhere.

Yes, "Text" and "Link" feel appropriate to me.

We could potentially do the same for the social links as well: #60047. Perhaps one day it uses LinkControl as well even.

[t-hamano]

What do you think about following the core classic editor and using the term URL/Link Text?

[richtabor]

What do you think about following the core classic editor and using the term URL/Link Text?

Sorry, missed this comment before #60116.

I think what we have in #60116 is sufficient, and now at least they are consistent across.

[afercia]

I think what we have in #60116 is sufficient

I don't think it's sufficient.

• in Make sure Social icons links aren't empty and improve UI clarity #60047 (comment) I suggested to just use the terminology WordPress always used: 'Link text'.
• @t-hamano suggestd the same here in a previous comment.
• 'Link text' is the terminology WordPress users are familiar with since ages, I'm not sure there's a good reason to change it.
• 'Text' only isn't sufficient because it doesn't clarify the context. What this 'text' is? While in some cases the UI may provide context, in other cases it doesn't. For example, in the block inspector Page link, Custom links, Submenu, clarify the context in the block card at the top, in a way. However, the Social link card doesn't. See screenshot below.
• When removing the link text in a navigation block, the placeholder text of the contenteditable still says 'Add label...'. This eas missed in Update navigation blocks to use consistent link UI labels and field sizes #60116 and must to be chanced. See second screenshot.

Screenshots of the block inspector cards with various link-related blocks, to illustrate the term 'Text' doesn't clarify sufficiently what the input field is about:

Placeholder text of the navigation items still says 'Add llabel...':

Reopening to allow for broader discussion.

[t-hamano]

This is an additional suggestion. For example, the core navigation menu consistently uses the term "URL". On the other hand, the text to which the URL is applied seems to use the terms "Link Text" and "Navigation Label". Could this basic rule also be applied to Gutenberg?

[afercia]

Yep, that 'Navigation Label' in the classic menus is pretty old. It's inconsistent with custom links and also a little weird to translate. Also, it shouldn't be title case. Not sure changing such an old UI is worth it but, in case, I'd change it to 'Link text'.

Re: the term URL I'm not sure I have strong opinions.

• On one hand, I'd prefer to keep it as 'URL' because that is what WordPress always used and users are familiar with it.
• On the other hand, URL may be a bit too technical for some users. I'd think it's way more common in everyday language to just say 'Link'.

[t-hamano]

Regarding the inline link, I would like to provide two more examples outside of WordPress.

Notion: "Page or URL" and "Link title"

Slack: "Text" and "Link" (This is consistent with the changes made in #60116)

To be honest, I'm also wondering which is the correct answer in WordPress 😅

[richtabor]

in #60047 (comment) I suggested to just use the terminology WordPress always used: 'Link text'.

Link text is fine in that particular context, but if we do what I suggested—to bring the link field there as well—then "Text" and "Link" would work great there as well.

"Link text" and "Link" adds more words with not enough benefit for the increased word count.

On the other hand, URL may be a bit too technical for some users. I'd think it's way more common in everyday language to just say 'Link'.

Agreed. "URL" is a technical term—I'd avoid using terminology that requires additional understanding.

When removing the link text in a navigation block, the placeholder text of the contenteditable still says 'Add label...'. This eas missed in #60116 and must to be chanced. See second screenshot.

This should be "Link" (no ellipsis) — to follow suite of other placeholder text.

[Niyatijain-9]

Hey I wanted to work on the same. Kindly assign me this @afercia

[afercia]

@Niyatijain-9 thanks for willing to work on this. You don't need to be assigned to an issue to work and submit a PR.

[yukta8]

Hello! I came across this issue and found it interesting. Is this still open to work on?
If so, I'd be happy to take it up and submit a PR. Please let me know if I can proceed
Thanks!

[afercia]

I think #60116 took care of this but failed to properly reference this issue to close it.
Noting that in a following PR #65458 the label of the LinkControl was changed to Search or type URL to match the aria-label and because that is what the input field does. The other input in the settings panel is labeled 'LInk' because there's no search functionality there. Screenshot: