Link: Do we really need to have an option in the toolbar for link in desktop? Maybe it could be included within the "Insert" menu.

Given it's the most-used tool, I would think it is the strongest candidate to stay in the top-level toolbar?

Special characters: same, do users really need this option visible in the toolbar or could it be within the "Insert" menu?

Special char is fairly high up the list, and I'd like to see the breakdown by wiki. There are likely languages where users don't necessarily have access to all the characters they need, and this would is an invaluable tool on these wikis that we wouldn't want to hide. I'd also hesitate to go down the route of varying toolbar config by wiki:

1. There is value in having a consistent interface across wikis
2. Maintenance debt: it makes it harder to test all variations of the toolbar when making changes
3. We think we have solved the problem by removing it from major languages where we can hide the special character tool, but it persists on other wikis.

Publish button: Using ellipses at the end of actions (Publish changes...) is not a good practice (even when the button is loading) and we don't use ellipses to communicate actions that are not loading.

Using an ellipsis to show the button starts a process is a commonly used affordance in toolbars, examples:

Google Chrome	LibreOffice

I would rephrase to "Publish changes" or simply "Publish".

This label changes responsively, so the longer message is only used when there is space, so making it always shortened doesn't get us any extra space. It is also consistent with the 2010 wikitext editor:

4. Use a text button to display the mode (e.g. "Visual editing")

Without creating a lot more space I'd be hesitant to add a long label like that - the toolbar is already cramped and wraps very early.

Warning icon: it's used for any page notices for the current page, but we could find a better place for that. Also, this warning icon in the toolbar is competing with the Edit Check warning icons.

So, the design constraints are:

1. this needs to be shown when people start editing
2. people need to be able to refer back to it later -- particularly new users, who don't know the things that are being communicated here

(The classic editor satisfies this by literally showing all the notices above the editor, so you may have to scroll down to edit things on particularly heavily-noticed articles. Technically, we could do this in VE as well, but it would violate our paradigm pretty hard.)

As such, I think it pretty much has to be in the toolbar. There's nowhere else in the VE setup to put a control like that, and putting it into one of the right-hand submenus means that it won't be findable -- the hamburger menu contains a number of important tools, but none of them are really what new editors are looking for.

I'd be open to it if you can think of a place to move it that satisfies the conditions, of course.

(Also, it might be slightly disingenuous of us to pop up with "we have added a new feature that uses this icon, and so the long-existing feature has to change". 🤔)

Link: Do we really need to have an option in the toolbar for link in desktop?

Yes. Link is the single most-used tool, and we cannot assume that people know about the keyboard shortcut for it -- it's nowhere near as standardized as things like bold/italic.

I think there are two tools that are so fundamental that they must be in the toolbar, because they're what it means to be editing a wikipedia: link and cite.

Group the options within the Insert menu to make them easier to find by usage, and use dividers to separate each group

This is technically sort of a nuisance to accomplish, just because the tools are being contributed by various extensions that don't know about each other. We could probably work something out, but it might need some consideration. I think it looks better grouped, though, so it may be worth pursuing regardless of the rest of the proposal.

Special characters: same, do users really need this option visible in the toolbar or could it be within the "Insert" menu?

In addition to what Ed said about popularity and avoiding a testing burden from inconsistency and configuration-combinations, we'd also need to redesign it for it to work okay in a submenu. As-is, it's a toggle that turns the special characters panel on/off, so having the way to collapse the panel hidden away after you open it seems sub-ideal.

@louisparra Hello, please stop spamming tickets with ChatGPT-produced useless comments. If you do this one more time, I'll lock your account for spam.

While redesigning the edit toolbar, we should design a responsive version that allows to make the same actions on desktop and mobile. This relates to T397748: Make editing interfaces responsive.

mostly as inspiration, i recently tried out ia presenter on iOS, and they have a neat setting to customize your own menus

tap on ⚡️	tap 'configure menu'	drag&drop or add new

El T400903#11297376, @AAlhazwani-WMF escribió:

mostly as inspiration, i recently tried out ia presenter on iOS, and they have a neat setting to customize your own menus

tap on ⚡️	tap 'configure menu'	drag&drop or add new

Nice! I wonder if it would be possible to customize a menu/toolbar in a non-app environment.

Nice! I wonder if it would be possible to customize a menu/toolbar in a non-app environment.

The last time I looked into this, the answer was no. There's no way to interact with the built-in context menus, and there's also no way to suppress the built-in context menus so you can replace them while still having native-selections be allowed -- and having to completely rip out and reimplement all text-selection behavior is a bit of an ask. (We do have custom selection behavior for block elements, but we get a lot by offloading text selection to the browser.)

In T400903#11719297, @DLynch wrote:

Nice! I wonder if it would be possible to customize a menu/toolbar in a non-app environment.

The last time I looked into this, the answer was no. There's no way to interact with the built-in context menus, and there's also no way to suppress the built-in context menus so you can replace them while still having native-selections be allowed -- and having to completely rip out and reimplement all text-selection behavior is a bit of an ask. (We do have custom selection behavior for block elements, but we get a lot by offloading text selection to the browser.)

@DLynch i guess what @bmartinezcalvo is asking is the following: would be possible to let people customize the 5 buttons selection (undo, style text, cite, link, switch editor) that they currently find in the mobile VE toolbar? take this with a grain of salt - but imagine if you have access to a dialog or a preference page where you can basically sort features top to bottom, and the top 5 are the once that the person will then have in their own mobile VE toolbar.

where you can basically sort features top to bottom

We could, but this will likely only ever be a power-user feature used my a small minority, and so it becomes harder to justify the investment. I don't think it helps with making sure we get the initial configuration right for 99%+ of users.

There's no way to interact with the built-in context menus

I think David was going by the screenshot that showed the system-level context shown above the keyboard (which made the question a bit ambiguous). He is correct in saying we have no way of customising that system-level context, but we have full control over the VE toolbar.

I think David was going by the screenshot that showed the system-level context shown above the keyboard (which made the question a bit ambiguous). He is correct in saying we have no way of customising that system-level context, but we have full control over the VE toolbar.

Yeah, sorry, I was specifically responding to the part of it about customizing menus in an app. We can absolutely customize the inside-VE toolbars however we want, though we have not currently implemented any such thing. (And I agree with Ed that it would likely be a rarely-used feature that wouldn't obviate the need to come up with defaults that cover most users needs.)

i wanted to share some early learnings from the article guidance research project T414812! we knew that inserting headings (h2, h3, etc.) isn't currently possible in the mobile VE (without using wikitext syntax, eg. === for h3), and we assumed the article guidance features would be enough.

but it's looking like surfacing that kind of text formatting could actually be helpful too. sharing since you're exploring improvements to the mobile VE toolbar too!