When I'm in Visual Editor, and type a "\", I see this toolbar. However, the "\" is inserted into the text of the page being edited, as is illustrated at https://commons.wikimedia.org/wiki/File:Visual_editor_toolbar_search_feature.png Is that the expected behavior?

I'm still seeing a problem:

Regarding "Your idea also doesn't seem to relate to dialogs where information is being input from multiple different places in the article", I'm not proposing this for all situations. In fact, I'm primarily interested in getting some action on the problem of more easily adding categories to articles.

I haven't thought this through, but, for example, to add a category to Wikipedia page, one could (1) select some text, and (2) tell VE that you want that text to be a category. The process would be similar to linking, where one selects text and then clicks on the link icon.

https://ux.stackexchange.com/questions/81134/should-modal-dialogs-be-movable seems to show a (rough) consensus that when a proposed solution to a dialog is to make it moveable, the dialog itself is poorly designed. That implies looking for a different solution that addresses the underlying user problem.

https://ux.stackexchange.com/questions/81134/should-modal-dialogs-be-movable seems to show a (rough) consensus that when a proposed solution to a dialog is to make it moveable, the dialog itself is poorly designed. That implies looking for a different solution that addresses the underlying user problem.

To slightly restate the suggestion, a good starting goal would be for the content of a reference to be editable in cases where VE is able to identify the reference and open the Reference dialog. This essentially requires being able to figure out how to edit the element that now "only can be editing in source mode".

I thought that the page was only to describe how to create links using VisualEditor. That's certainly not the situation now. In fact, in some cases, such as the description of how to create category links, the only information is how to do that using the wikitext editor, not how to do so in VisualEditor.

Okay, I've registered. Am I supposed to create the task(s), or has someone already done so, and I can just attach my name to it/them? (I have listed my name at https://www.mediawiki.org/wiki/Google_Code-in_2016 , for what that's worth.) If I can just attach my name, how exactly do I do that?

@Whatamidoing-WMF - Sure, I'll be happy to try mentoring for this project.

Why isn't this given a higher priority, and/or assigned to someone? This issue affects every article that has an infobox with one or more citations, and that's a VERY large number, and continually increasing - and a high percentage of the most viewed articles DO have infoboxes.

Can we be more specific? A quick Google search (generate citation from ISBN) shows a number of tools that generate citations from a database; in at least one case, that's WorldCat, via its API (https://www.worldcat.org/affiliate/tools?atype=wcapi ). Maybe it takes a lawyer to negotiate the price, but it's perhaps calling this "Epic" is a bit of an overstatement - it looks like other organizations have done so, and - given that at least one appears to have as its business model getting revenues from online ads - perhaps the price is quite reasonable?

I'm going to repeat most of an earlier comment, because I think it gets to the heart of the issue, and because no one has responded to it:

The last two comments have identified two specific problems with having two tabs, not one:

In my last 50 edits in mainspace, I used VE 22 times. For some things (doing a citation, using citiod, for example), VE is clearly superior to the wikieditor. But VE can't do some things (or, at least, I can't figure out how to do them using VE); for other things (cleaning up a ref=name problem) wikitext editing is better. What I like, now, is that with one click, I can be in the editor of my choice. So it's not clear to me what problem is being solved by a single edit tab. [Q: Would there also just be one selection to the right of each section heading, rather than - as at present - two?]

Other websites with editing interfaces - Quora comes most readily to mind - don't provide a URL as feedback after making a link (in the sense of showing both the external link and the clickable text that leads to it), they just show the text that, when clicked, will lead somewhere. So leaving the cursor inside the link is counter to what editors experience elsewhere.

Implementing this - or not - is a question of costs versus benefits.

It would be a definite improvement if the user could reach categories either via a top menu, or by scrolling to the bottom of the page. As several people have pointed out, there are disadvantages of the user being able to do only one of these, and - of course - there is no reason, from a programming viewpoint, why there can't be two paths to the same dialog.

The relevant documentation about messages (i18n system) appears to include

• https://www.mediawiki.org/wiki/Help:System_message
• https://www.mediawiki.org/wiki/Localisation#Adding_new_messages
• https://www.mediawiki.org/wiki/Localisation_file_format
• https://www.mediawiki.org/wiki/Help:System_message#Finding_messages_and_documentation

Those who noticed the contextual help on the meta (page settings) menu - I'm not one of them - apparently didn't think it was worth commenting at WP:VE/F, or its equivalent at mediawiki.org. That may because contextual help was added to the VE menu least used. Or because no one was overwhelmed by the wording in the contextual help popups. Or because there was no obvious way to suggest improvements in wording. Regardless of the reasons, the lack of a response should absolutely not be taken to be a polling of the user community.

This is being addressed by Citoid

At the moment, Citoid's building a citation from a URL is wrong at least 75% of the time. (I'd have said "close to 100%, but I was surprised the other day to see a NY Times citation built that looked fully correct.) By "wrong" I mean that the article title includes the publisher, or one or more of the six suggested fields (see https://en.wikipedia.org/wiki/Template:Cite_web#TemplateData ) are not filled in when in fact information is available at the URL.

I'm not clear as to why this is shown as "Closed, Resolved". VE still won't edit citations/footnotes where the body of the citation is in the References section (that is, within the reflist template), as demonstrated by the first two citations here: http://en.wikipedia.org/wiki/Pope_Francis#Name

I agree that the dockable model is trying to modify something where we might better look for alternatives. For example, one way to create a new category might be to highlight some text, then select (say) Insert > Category. That could open a dialog (for example, to allow a different sort key than the default, and to offer the opportunity to create a category if one being created didn't already exist.

The discussion is complicated by the unnecessary "Options" menu on the left side of the dialog box. (I believe this is the only place in VE where selecting a choice from a top menu results in a dialog box that shows all the other choices on that menu; that would make sense if an editor were likely to want to do two or three page-related things at once, but in fact he/she almost certainly does *not*.) While redoing the entire approach to how the three-line (should be "Page") menu choices work is probably outside the scope of this topic, I will note that what the requester needs (access to all the text on the page, *while* the dialog is open) is applicable only to two choices - categories and default sort.

This seems, well, almost trivial to implement. Here's what I have in my common.css to do this when I edit: