Wikipedia:VisualEditor/Feedback

VisualEditor is available here at the English Wikipedia alongside the original wikitext editor if you opt-in, by changing your preferences. VisualEditor is not available to unregistered users here or to users of Internet Explorer at any Wikipedia. The developers are working on support for IE9, IE10, and IE11.

Share your feedback

Report bugs

Your feedback about the VisualEditor beta release

This page is a place for you to tell the Wikimedia developers about issues that you encounter when using the VisualEditor here on Wikipedia. It is still a test version and has a number of known issues and missing features. We do welcome your feedback and ideas, especially on some of the user interface decisions we are making and the priorities for adding new functions. All comments are read, but personal replies are not guaranteed. If you have encountered a problem or have found a bug, then please include your web browser, computer operating system, and Wikipedia skin (usually Vector, sometimes Monobook).

A VisualEditor User Guide is at Wikipedia:VisualEditor/User_guide.

Add a new comment – View known bugs – Report a new bug in Bugzilla
Join the IRC channel: #mediawiki-visualeditor ^connect – Test VisualEditor! (no account required)

Please click here to file a new bug report on this page

Archives: (generated by MiszaBot II)

• 2012: 1
• 2013: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
• 2014: 1, 2, 3

Wikitext error message

Tracked in Phabricator
Task T53751
Declined

In VE edit mode, when I click on the indicator/icon of a (hidden) comment (an orange ball with a white exclamation point inside), I get a popup window with an icon and (part of) the text of the comment. I want to edit the comment, so I click on the icon/popup. Next, I change the text. So far, so good. Finally, I click "Done". And ... a warning message is displayed in the upper right hand corner: "Wikitext markup detected. You are using VisualEditor ..." . I hate to be impolite, but: WTF? -- John Broughton (♫♫) 04:23, 11 August 2014 (UTC)

John Broughton, is this reproducible in multiple places? I had one paragraph giving me that error last week, and there really was wikitext in it (I'd deliberately nowiki'd a code). Even if I didn't touch that sentence, I kept getting that error on that one paragraph. Whatamidoing (WMF) (talk) 18:13, 11 August 2014 (UTC)

@Whatamidoing (WMF): - There in fact is some nowiki'd text in that paragraph. So let me redo my posting (and I've changed the section heading):

1. Why does VE warn me about nowiki'd text that already exists? I'd understand if this were new text, but it's not.
2. Why does VE warn me only when I change something within the specific paragraph that contains the nowiki'd text. If I change anything else (including hidden comments) anywhere else on the page, I get no warning.
3. Why does VE give me that warning if, in that paragraph, I (a) modify a hidden comment or (b) insert a citation/reference, but does not warn me, if, in that paragraph, I create a link? [I've only tested these three things.] -- John Broughton (♫♫) 22:26, 11 August 2014 (UTC)

You have reverse-engineered our wikitext warning code with impressive accuracy :) . The wikitext warning code is pretty hacky right now, because it's hard to check if any given change a user makes introduces wikitext (it's contextual: typing a single bracket is not wikitext, except if it's next to another bracket; an equals sign is fine, except if it's next to another equals sign and it's at the beginning of a line; etc.). So right now what is does is check whether the paragraph that you touched contains something that looks like wikitext. This explains #1 (blames you for pre-existing wikitext) and #2 (but only if you get close enough to it) above, but doesn't explain the difference between 3a and 3b. If anything, I'd expect those two to be reversed.

As for 3a vs 3b, if you can give us a detailed example that we can use to reproduce that difference, that would be great, because then we can file a bug for it and fix it. As for 1 and 2, I don't know if we have a bug filed for that yet, but we should probably have one. I think we can probably make it better by checking if the paragraph looked like wikitext before you changed it; we have some unrelated code coming in soon that should make that easier (right now it would be laborious to figure out what the paragraph looked like right before you changed it). --Catrope (talk) 00:16, 13 August 2014 (UTC)

@Catrope: I'm withdrawing point #3; I now think that VE is consistent about warning when any dialog is completed within a paragraph with wikitext. But I do consider #2 to be a problem worthy of a bug: VE should be able to distinguish old wikitext from new - that is, it should be able to tell that text that existed, before the edit began, which already had surrounding nowiki tags, is different than something that did lacks these tags. It's not like Parsoid strips off the nowiki tags during conversion, is it? -- John Broughton (♫♫) 22:13, 13 August 2014 (UTC)

This (which you said is #2, but I think you meant to type #1?) appears to be Template:Bug, which was unfortunately WONTFIXed for performance reasons. Whatamidoing (WMF) (talk) 00:02, 14 August 2014 (UTC)

Yeah, I see it's currently marked as WONTFIX because it sounded pretty much impossible at the time, but I think I'll probably be able to do something about this in the next few weeks. I may not be able to fix it completely, but I'm pretty sure I'll be able to make it happen less often. --Catrope (talk) 21:05, 17 August 2014 (UTC)

Cannot reuse a citation multiple times in the same edit.

Here's a sandbox which demonstrates the problem. Try it for yourself. --99of9 (talk) 12:20, 13 August 2014 (UTC)

Per this discussion this is likely to be fixed tomorrow. Mike Christie (talk - contribs - library) 12:28, 13 August 2014 (UTC)

Thanks User:Mike Christie I hope so. --99of9 (talk) 13:16, 13 August 2014 (UTC)

It works for me now. Please post if it isn't working for you. Whatamidoing (WMF) (talk) 20:42, 14 August 2014 (UTC)

Yes it worked for me too. Thanks. --99of9 (talk) 03:50, 17 August 2014 (UTC)

Wikilinking is cumbersome

Tracked in Phabricator
Task T71711

I am finding that wikilinking is very disruptive to the workflow in VE. The wikimarkup of double square brackets allows links to be inserted without breaking the flow of typing. In VE I must first stop typing, then select the text I want to link, then click link, then select the link, then click to close the dialogue. It is disruptive because it forces going from keyboard to mouse and the text insertion point has to be moved while selecting the link. The VE system is good for suggesting links to use, but when I know perfectly well what I want to link I don't want to bother with all that.

It would be good if the double square brackets were autocorrected to a link by VE. An autocorrection facility could have numerous other uses if it were implemented. I can see user defined autocorrection having many benefits as well. SpinningSpark 09:35, 16 August 2014 (UTC)

There's an equivalent keystroke sequence in VE to the "double bracket, linked word, close double brackets" sequence in the wikitext editor. For example, if you're typing the sentence "K2 is a mountain" and you want to wikilink "mountain", type this: "K2 is a ", then Ctrl-K, then "mountain", then <enter>, then <enter> again. Same number of keystrokes as before. If you want to pipe the link, one way to do it is "mountain", then Ctrl-K, then type the name of the target page, then <enter> twice. Mike Christie (talk - contribs - library) 12:25, 16 August 2014 (UTC)

Thanks for the info, but that failed on the very first attempt at using it. I did not need to contrive an example to break it, this is actually the very first thing I tried. In attempting to write

• The Republic of Vietnam is a country in South-East Asia

What actually came out was

• The Republic of Vietnam Airborne Division is a country in South-East Asian theatre of World War II

On attempting it again, but this time clicking "done" after typing instead of "enter" I got

• The Republic of Vietnam is a country in South-East Asia

which as well as defeating the object of using keystrokes only is obviously still not right if you hover over the links. It seems that unless the link wanted is the first link in the list, one will always be forced to break off typing and select the correct link. There appears to be no way to force selection of the link "as typed". SpinningSpark 13:13, 17 August 2014 (UTC)

You're right that I hadn't thought about spaces in the displayed text name. I'm a keyboard shortcut user, so I typed in a couple of variations on the links you were creating to see what my fingers would automatically do. To get Republic of Vietnam I typed "Republic of Vietnam" Ctrl-Shift-LeftArrow Ctrl-Shift-LeftArrow Ctrl-Shift-LeftArrow Ctrl-K <enter> RightArrow, which worked. Then I tried the same thing, but instead of just hitting <enter> immediately I typed "Republic of Vietnam" in the dialog box. I got "Republic of Vietnam Navy" as the link target (not sure what happened to the Airborne Division, but this is essentially what you got). So in this case there is a fast way to do it, by simply not typing anything, but that's not a general solution when you want to pipe and the pipe target is not the first on the list. In that case I suspect the fastest way is to use arrow keys to scroll to the right place on the list (but see below; I think this will be rare). In neither of your examples was this necessary for me. I suspect you're on a different browser/OS combination than I am, though, because I get slightly different results from what you describe, so I can't be certain that what I describe would work for you.

I thought it would be worth doing some speed tests, so I compared two sequences that created the text "The Republic of Vietnam". In VE, the fastest seems to be: "The Republic of Vietnam" Ctrl-Shift-LeftArrow Ctrl-Shift-LeftArrow Ctrl-Shift-LeftArrow Ctrl-K "South Vietnam" <enter> <enter> RightArrow. That last "RightArrow" is to unselect the link text so that continuing to type does not erase the link. I timed myself adding five of these links in VE and five in wikitext: it took me 49 seconds to add five wikitext links, and 61 seconds to add five via VE. I don't think I could get much faster with either, so I would say it's about 10 seconds to add a complicated link in wikitext and 12 seconds in VE. It would add one or two additional seconds to arrow down to a particular item in a list and select that.

This isn't a big enough difference for me to prefer wikitext, but I could see it influencing others to prefer it, so I thought about what changes to the UI would speed up this interaction. Here's one suggestion:

1. When exiting the VE link dialog, don't leave the link selected. There seems to be no benefit to doing so, and it adds a keystroke (RightArrow) on exit to avoid deleting the link.

I was also going to suggest that we add a shortcut key inside the VE link dialog that means: "Take whatever text I have typed, assume that it should be left exactly as typed (i.e. don't pick the checkmarked one off the list), and jump back out of the link dialog". However, I had some trouble coming up with an example where this would add value. It would require that you're piping the link (otherwise you can just hit <enter> as described above, bypassing the whole issue of selecting from a list), and it would also require that you are typing something that is not the actual target -- in other words, you're typing a redirect or dab name, which is unlikely if you're piping; or you're typing something that is ordered lower on the list than the bare text you typed, which isn't particularly common. An example is "Manchester", which is lower on the list than "Manchester United F.C.", so if you're redirecting a link to Manchester you would have to select "Manchester" when the list pops up. A single DownArrow would do the same thing, though, so I'm not sure a shortcut key is worth it.

I think the enhancement mentioned above is worth requesting. Can you see any other way to improve the user interaction on the link dialog? Mike Christie (talk - contribs - library) 16:47, 17 August 2014 (UTC)

Ok, I accept that it is possible to do this with keystrokes (but the sequence you gave at the beginning doesn't work, at least in Firefox). However, my complaint is that it is not "linear" within the activity of typing. I would like it to be like the insertion of italics or bolding which use Ctrl-I and Ctrl-B respectively. That is I would like "Ctrl-<foo> <link foobar> Ctrl-<foo>" where the link can be complete with #anchor and pipe etc as necessary and without something getting in the way trying to interpret what I already know perfectly well what I'm doing. SpinningSpark 18:04, 17 August 2014 (UTC)

Or even more generally, why not have a Ctrl-<foo> that escapes into wikitext until another Ctrl-<foo> is entered. That could get around any number of other shortcomings of VE and make it much more acceptable to those that currently don't like VE. SpinningSpark 18:08, 17 August 2014 (UTC)

That's the obvious solution, as I argued right at the start. Unfortunately the architectural choices made by the developers appear to have made that approach pretty much impossible. It was clear right from the start that the architecture was flawed, so we're where we are. No amount of additional work is going to change this sow's ear into a silk purse. Eric Corbett 18:27, 17 August 2014 (UTC)

I can see why some people would like a feature such as you describe. I was just trying to see if there was an equally easy way to do what you wanted within the current VE approach. @WhatamIdoing: What do you think of the enhancement suggestion above -- to leave link text not selected on exit from the dialog? It would cut out a keystroke and I don't see any value to the current behaviour. Mike Christie (talk - contribs - library) 02:51, 18 August 2014 (UTC)

I think it's a good idea, and with any luck, we'll also convince them that the cursor belongs at the end of the word that you just typed (and linked) instead of at the start of the word.

Feel free to remind me if I don't get a bug number posted here within the next couple of days. WhatamIdoing (talk) 04:01, 18 August 2014 (UTC)

This is now Template:Bug.

What are people thinking about the "don't bother me with the search results, just link exactly what I typed" idea? Whatamidoing (WMF) (talk) 19:26, 18 August 2014 (UTC)

Tracked in Phabricator
Task T71716

Seems a bit of an overcorrection. I would rather say that the dialog should not auto select a DIFFERENT page if there is an exact match to a redirect.. perhaps it should not autoselect at all when opened via a keyboard command and just let the user explicitly select something from the list if he wants to use the suggestions. There is a strong separation between pages and redirects pages now in the suggester, which in general is a good thing, but NOT in this specific situation of for instance trying to enter "Republic of Vietnam", which is an exact match, yet ignored by the autoselection logic of the dialog. —TheDJ (talk • contribs) 20:26, 18 August 2014 (UTC)

That's a good idea no matter what's decided about how to link efficiently. Whatamidoing (WMF) (talk) 21:08, 18 August 2014 (UTC)

Page options menu gets cut off

Tracked in Phabricator
Task T71707

The page options menu gets cut off, making you scroll to see what the items say. The menu seems to be fixed to the button instead of shifting over to fit on the screen. Firefox 31, Windows 7, Monobook:Jay8g [V•T•E] 19:17, 17 August 2014 (UTC)

Filed a report for this. —TheDJ (talk • contribs) 16:46, 18 August 2014 (UTC)

What's the current status on the look and feel of image slugs?

I just bit a new editor by using Visual Editor to clean up their article, and managed to delete three images in the process. The edit is [1]. As you may be able to see if you open Visual Editor on the "before" image, the images themselves are off-screen, and the image slugs are invisible. Mac Chrome. I saw a note in the comments for (resolved fixed) bug 47790 that there was some thought at one point about making these more visible in general, but I couldn't find more information on what the current plan is to try and avoid this sort of UI difficulty?

This is a really easy error to make on new editor AfC submissions, since excessive vertical space is a common feature of such drafts. --j⚛e decker^talk 21:21, 17 August 2014 (UTC)

I'm really glad you posted this, I nearly just made the same mistake myself and only didn't because I read this first. I still don't know what an image slug is though, presumably it's not one of these. SpinningSpark 08:59, 18 August 2014 (UTC)

It's a known problem. I'll ask what the current status is. Do you have any suggestions for what it should look like? Whatamidoing (WMF) (talk) 20:48, 18 August 2014 (UTC)

Well for sure rendering it as a blank line is about the worst possible thing to do. That positively encourages editors to delete it, while rendering it invisible (like it is in the article) will most likely be left alone (unless a block spanning a paragraph boundary is deleted). If the line is going to be rendered it should have an icon on it so we know that it is an image. A better approach in my view though is to render exactly as in the article, but not to delete any images unless they are positively selected. That means that if a block of text is selected and deleted (or copied, or moved), any embedded images should not be deleted, copied or moved. If it is intended to delete the image as well then select it with Ctrl-select. By the way, Ctrl-select allows non-contiguous portions of text to be selected but only one actually gets deleted on pressing delete. Seems like another bug (ed:Bug 69737 raised) to me. SpinningSpark 02:21, 19 August 2014 (UTC)

Whatamidoing, I'm honestly not sure. I'm used to working in systems that have a variety of kinds of slugs that need to be differentiated (visual HTML code editors, page layout tools, etc.), and part of me expects something looking like an image icon. But I may very well not be the average user. Hmm. --j⚛e decker^talk 18:21, 21 August 2014 (UTC)

Mess while editing a Further reading section

Someone try to edit this with VisualEditor. It's a mess -- it suggests to edit these templates in a big pile instead of separately. I can't possibly discern which book is where. Gryllida (talk) 23:47, 17 August 2014 (UTC)

Yes these are very complicated template structures. Would you have ideas on how to improve the representation of this complexity ? —TheDJ (talk • contribs) 16:43, 18 August 2014 (UTC)

If VE is editing template parameters, and the template parameter meets the parsing definition of a template itself, can it treat it the same way it treats a template in the rich text interface -- allow you to click on it and recursively bring up another template editing interface? Mike Christie (talk - contribs - library) 17:32, 18 August 2014 (UTC)

It's not editing template parameters. It's a complex transclusion, in this case, a series of nested templates, and some of the templates are supposed to be applied to all of the internal ones. VisualEditor necessarily sees it as one block that contains many parts, rather than a series of unrelated parts.

The simplest workaround is not to use {{refbegin}} to change the font size. (Some of our users with poor eyesight would probably appreciate this anyway.) Another workaround is to apply the font change as a proper span tag rather than as a series of templates that each apply partial HTML codes. The solution that's eventually going to be implemented is to improve the design of VisualEditor's advanced transclusion editor. However, that's likely to take a long time. If you've got ideas about how to improve the design, then please post your ideas. Whatamidoing (WMF) (talk) 20:53, 18 August 2014 (UTC)

Deleting tables

Tracked in Phabricator
Task T71706

If I select a portion of text that includes a table and delete the selection the table disappears with it. However, on saving the page, the table is still there. There is also some similar odd behaviour when repeatedly pressing delete in a table cell and the material being deleted crosses a cell or row boundary. I realise that tables in VE are not fully implemented, but this kind of mess shows that for sure VE is still not ready for mainspace. Features should fail gracefully, even ones that are not implemented yet. SpinningSpark 15:55, 18 August 2014 (UTC)

BTW, at Wikimania i picked up that some external party had done some design for table editing, which was enthusiastically received by the development team. This probably means that work starting on table editing might be a bit closer to arriving than was anticipated some 4 weeks ago. —TheDJ (talk • contribs) 16:42, 18 August 2014 (UTC)

Old bug? Reference in explanatory footnotes missing

Tracked in Phabricator
Task T52749

Last year i reported (bugzilla:50749): a problem with references in explanatory footnotes (when you add a (sfn) template inside an (efn) template). The error was marked as fixed, but has probably reappeared? Please check, example article is Otto I: it should have 63 references, VE does show only 62 references - the Thompson reference #18 is missing. Thank you. (P.S. browser is actual FF with Windows XP) GermanJoe (talk) 22:54, 18 August 2014 (UTC)

Thanks for the note, GermanJoe. I've re-opened the bug for you. Whatamidoing (WMF) (talk) 00:08, 19 August 2014 (UTC)

Doubled article title following a VE edit

Tracked in Phabricator
Task T71857

I edited High Frequency Active Auroral Research Program using VE (actually a fairly pleasant experience - cut-and-paste worked well, and so did creating a new cite web citation). When I saved my edit, the result is what is shown in the screenshot - the title of the article is repeated in a smaller font below the normal title.

I did a second edit to confirm what I'd seen. (Mac OS, Chrome, Vector). I'm not inclined to believe this has something to do with my selecting, as a preference, the gadget "Display an assessment of an article's quality as part of the page header for each article", but I note that for the sake of completeness. -- John Broughton (♫♫) 03:15, 19 August 2014 (UTC)

It appears to be a conflict between VE and the gadget "Add an [edit] link for the lead section of a page", which I suppose you have enabled. Someone ought to fix the gadget. — This, that and the other (talk) 09:53, 19 August 2014 (UTC)

Yes, disabling the gadget appears to solve the problem in Firefox. Safari doesn't seem to be affected. (I've seen triple titles in Firefox.) I'll leave a note at the gadget's talk page about this. Whatamidoing (WMF) (talk) 22:41, 20 August 2014 (UTC)

I filed this as Template:Bug. The blame is split between VE and the gadget, but it's a lot easier to fix in VE. :) Matma Rex talk 16:32, 21 August 2014 (UTC)

Junk "if !supportLists" injected + table destroyed

Tracked in Phabricator
Task T71821

In this edit, junk was massively injected by VE and the existing table has been destroyed by VE. --NicoV ^{(Talk on frwiki)} 11:15, 19 August 2014 (UTC)

It looks like another round of copying from MS Word, only with a different kind of brokenness. I'll post a bug number after a while. Whatamidoing (WMF) (talk) 22:47, 20 August 2014 (UTC)

Language link ending up in a title

Tracked in Phabricator
Task T71822

Hi, in this modification, a language link was moved inside a title by VE. --NicoV ^{(Talk on frwiki)} 17:33, 19 August 2014 (UTC)

This looks like another round of "editing next to an invisible item". VisualEditor didn't "move" the interlanguage link (which probably ought to be on Wikidata); the editor unwittingly typed new material next to it. There's no way for editors to avoid doing that unless they can see that there's something (invisible) on that line. There's probably a bug for this, but if I can't find it, I'll file another. Whatamidoing (WMF) (talk) 22:52, 20 August 2014 (UTC)

Odd asterisk

If you use VE to edit Sirens of TI, you'll see an asterisk at the end of the "References" section. I can't figure out how to delete this using VE, and I also can't figure out why it's visible in VE edit mode (and wikitext edit mode) but not in Read mode. (Additional information: There was an external link after the asterisk, which I deleted.) -- John Broughton (♫♫) 20:32, 19 August 2014 (UTC)

I fixed it for you. The process is: Place your cursor on the line. Go to the List formatting menu. Choose the bullet list item (to de-select it/remove list formatting from the line). Save page.

The theory as I understand it (i.e., not extremely well) is that the MediaWiki parser suppresses such stray/empty lists, because readers don't need to know about that. VisualEditor displays them, because otherwise editors would be unable to (intentionally) remove unwanted blank list entries. This is another instance of VisualEditor being a rich-text editor rather than a WYSIWYG editor. Whatamidoing (WMF) (talk) 23:06, 20 August 2014 (UTC)

Thanks. Very helpful. -- John Broughton (♫♫) 16:41, 21 August 2014 (UTC)

Different behaviour for tab / shift+tab in template/cite dialogues

Further to Wikipedia:VisualEditor/Feedback/Archive_2014_3#Excess_tabbing_through_Cite_mini-editors (bugzilla:69512): In template / citation edit dialogues, the behaviour of ⇧ Shift+Tab ↹ is not tabbing through the info and delete icons, while Tab ↹ is tabbing through those icons. Which tabbing behaviour is preferable might be debatable, but in either case, ⇧ Shift+Tab ↹ should just do the opposite of Tab ↹. I'm using Vector / Chrome / Win 7 if that's relevant. - Evad37 [talk] 05:29, 21 August 2014 (UTC)

I get the same behavior in Safari and Firefox on my Mac, so it's probably happening everywhere. TheDJ has mentioned this on the bug, along with a suggestion for fixing both of these annoyances at the same time. Whatamidoing (WMF) (talk) 17:21, 21 August 2014 (UTC)

Utter waste of money

@Jdforrester (WMF): (and other WMF people) Why is the WMF, when it is not bullying through MediaViewer, failing with Flow or repeating all the previous experiences with Winter, still spending most of its developer money and resources on VE instead of on the wikitext editor?

On the French Wikipedia, which is probably the largest wiki-version where VE is the default, the results are that after more than a year of VE deployment, less than 10% of the edits are made using the default editor (VE) and more than 90% are made with the cumbersome, old-fashioned, outdated, editor-frightening wikitexteditor.[2]. In every single user group, including IPs and newly created accounts, is the wikitext editor more popular than the VE. The same applies (with slaightly different figures) to the Italian wikipedia[3], the Swedish one[4], Russia[5], Poland[6], ...

The reality is that after all the work you spent on VE, it simply isn't what the editors in general want or need. What probably many of them would appreciate though is some improvements in the wikitext editor, incorporating ideas and improvements from VE, like e.g. the file chooser, the template editor, and, er, that's about it I think. Plus some unrelated but much needed improvements, as indicated by e.g. the cries for help from the mathematics editors.

Are there any plans to match WMF spending and resource allocation to this reality? Fram (talk) 07:14, 21 August 2014 (UTC)

You know you won't get any answer, except maybe the development of a new special right to prevent contributors to say anything bad about WMF... Otherwise, I agree with your statement about how badly the resources are spent, while there are some rather easier things that could be accomplished to help all editors... --NicoV ^{(Talk on frwiki)} 10:11, 21 August 2014 (UTC)

My preferred view is the breakdown as a percentage of users in a particular group (anon,new,regular). Those present a less grim picture for anons on fr with about 34% of anons using VE, 17% of new users and 3% of regular users. I've taken the averages of percentages for the last month for a few wiki's

Site	Anon	New user	Regular user
fr	34%	17%	3%
it	24%	15%	4%
sv	30%	10%	5%
ru	34%	11%	2%
en	0.003%	0.8%	0.6%
de	0.001%	1.7%	0.2%

Obviously figures are much lower for de and en where its opt in, but there is very little take up by regular users across the board. It would be interesting to see how many new users continue to use VE after a month or so if they decide to switch. Comparing results from 6 months ago might be interesting.--Salix alba (talk): 15:28, 21 August 2014 (UTC)

I was an early critic of VE, and continue to believe that it should have stayed in beta testing mode for at least another six months. But it has become significantly better (more features, fewer major bugs), and - as importantly - it's starting to have functionality that the wikitext editor doesn't (and can't) have - image searching, checking the validity of external links, easier creation of citations, etc.

It's going to be years - if ever - before VE is a better choice for the most experience (wikitext) users, particularly some power users doing wikignome chores. But that's not VE's target audience - it's those who have never edited Wikipedia. For them, today, I'd definitely recommend VE, despite its numerous shortcomings. Slightly buggy software, missing some advanced features, is still preferable (for newcomers) to dealing with gnarly text that looks like code.

So yes, the way that VE was introduced was botched, badly, and the VE team still lacks the openness and interactivity with the community that would not only build confidence but would better focus its programming efforts. But VE continues to improve, and eventually Wikipedia will be the better for it. -- John Broughton (♫♫) 16:53, 21 August 2014 (UTC)

John, why do you say that wikitext can't have some functionality ? I do believe that everything you have listed could be implemented in the wikitext editor, it would only require WMF to dedicate a small portion of the resources that have been allocated to VE development. In my opinion, many features could be added to the wikitext editor, probably at a lower cost, and for a much larger audience. --NicoV ^{(Talk on frwiki)} 17:19, 21 August 2014 (UTC)

Citations are on the list of planned improvements for the wikitext editor. mw:Citoid is intended to be useful everywhere, even though the immediate work has been integration into VisualEditor.

As for why the WMF is doing this, I suspect that the community's identification of a rich-text editor as the #1 product priority recommendation a few years back has something to do with it.

Salix alba, one of the problems with the "edits" numbers is that we call them "VisualEditor" and "wikitext", but it's actually "VisualEditor" and "not VisualEditor". If you add a tag via Twinkle, that's labled as "wikitext", even though the wikitext editor wasn't actually used. Looking at fr.wp right now, about 15% of the allegedly wikitext edits didn't actually use the wikitext editor. (I'm sure it varies; I just looked at the last 100 mainspace edits.) A similar trip through en.wp's RecentChanges page shows 27% of allegedly wikitext edits that were done by script, bot, undo, or other methods that aren't actually someone choosing to use the wikitext editor. I suppose it would be possible to make undo use VisualEditor (which it would, if VisualEditor were actually "the default", rather than merely being "available by default"), but why bother? It would make more sense to have accurate statistics that differentiate between "I choose to use this editor" and "I was using a script or tool instead of choosing which editor I wanted to use". Whatamidoing (WMF) (talk) 17:44, 21 August 2014 (UTC)

":::::As for why the WMF is doing this, I suspect that the community's identification of a rich-text editor as the #1 product priority recommendation a few years back has something to do with it. " In what way does that page, written completely by WMF people, represent the community and its priority recommendations? As far as I can tell, this is the vision of a few Wikipedia developers based on some nebulous research, some cherry-picked quotes from non-editors, and no real community input. One of the major forces behind this paper is still the main force behind most botched WMF software of the last few years. Oh, and you have at least one error in the rest of your reply as well: bot edits are explicitly excluded from the stats I linked to, so you shouldn't remove these from the wikitext editing percentages we are discussing. Plus, of course, things like AWB edits are equally useful as many VE edits, which are also often typo corrections and the like. That AWB (and its users) doesn't want or need VE doesn't mean that these edits shouldn't be taken into account in a comparison.

Finally, none of what you say explains one bit why the usage of VE isn't growing, if it is so good, or why the drop in new editors hasn't been reversed now that we have the long-awaited top priority intuitive user friendly modern tool. Apparently, somehow, it isn't working as predicted. Fram (talk) 19:58, 21 August 2014 (UTC)

@NicoV: I generally find debating counterfactuals ("what if X had been done instead of Y") to be not all that useful. But in this case, I want to point out that with wikitext editing, the MediaWiki software doesn't understand what's happening until either (a) a preview is done or (b) a page save is done. That makes it impossible, in wikitext editing, to have a generalized interaction with editors (if they do X, then the software does Y, to help them). It also makes it impossible for editors to get instant feedback (as in, for example, moving or resizing an image). That is why Parsoid was written, as a new underlying basis for editing, and why VE has taken so much time to create (because it can't build on the wikitext system).

Again, I'm not trying to defend the process by which VE has reached its current state. I'm just saying that VE is now perhaps 70% or 80% of being a virtually flawless (albeit still limited) piece of software. Nor am I saying that the VE team will make the right choices to get to 100% (as opposed, say, to giving priority to the Chinese version of VE, which after all is in the VE team's annual plan, and so is clearly more important than fixing minor VE user experience problems that affect hundreds of language versions of Wikipedia). I'm just saying that the VE team, as unresponsive and misdirected as its software development process may be, is still improving VE, so VE will get better. -- John Broughton (♫♫) 17:54, 21 August 2014 (UTC)

It would struggle to get any worse, and it's an absolute disgrace that it's unavailable to users of IE. Eric Corbett 22:11, 21 August 2014 (UTC)

@Whatamidoing (WMF): You have a point about semi-automated edits. I've just used the data from the dashboard so it might be an idea to ask the stats team to add this data. I suspect this will not change the anon and new editors as they will not be using these tools. The dashboard stats exclude bots so the correction factor would be smaller. In the last 500 mainspace non-bot edits 13 were reverts (includes Twinkle and huggle), 8 undone, 18 hotcat and 2 AWB, 41 in total. Lets call this 10%. If we adjust the percentages to exclude semi-automated edits it may change the values for VE edits by regular editors on fr/it/sv/ru by half a percent upwards.--Salix alba (talk): 21:32, 21 August 2014 (UTC)

Template trashed by VE

Tracked in Phabricator
Task T71865

Hi,

In this edit, VE completely trashed a template. It's easily reproduceable:

• Edit the Infobox with VE template editor
• In the "Parcours junior" field, remove the last two lines
• Save the modification to the template
• The template is damaged, VE has put some nowiki but not correctly to keep the template

--NicoV ^{(Talk on frwiki)} 10:06, 21 August 2014 (UTC)

The user was confused by the wiki markup for the table code and removed the "end of table": }}. This should improve as support for table editing and support for editing template fields that contain markup improves over the next few months. —TheDJ (talk • contribs) 13:37, 21 August 2014 (UTC)

TheDJ There's no table involved in the example: the user incorrectly removed the end of the template "deux colonnes" (which is used inside the infobox). So VE managed to escape the pipes but completely failed to escape the {{ which was previously the beginning of the "deux colonnes" template. The result is a completely trashed template. --NicoV ^{(Talk on frwiki)} 15:04, 21 August 2014 (UTC)

Template yes. I'll file an issue for seeing if the nowiki detection can be improved for this case of unmatched brackets. —TheDJ (Not WMF) (talk • contribs) 18:08, 21 August 2014 (UTC)

On testing this, I noted that on the French Wikipedia, the text a the top of the "show changes" box ("Relire vos modif...") is obscured by the "Revenir au formulaire d'enregistrement" button. After using that "Revenir" button, I notice the exact same thing on the "Enregistrer vos modificati..." screen, which is partially obscured by the "Enregistrer la page" button. Anywhere else? Oh yes, when I open the infobox, I see at the top "Infobox F..." with the rest obscured by the "Appliquer les modifications" button. And the same when editing a reference, inserting a comment (I think something is hidden beneath the button)...

NicoV, is this a new thing, or is it always like this? Does every single user on the French Wikipedia who wants to save anything with VE (not a common occurrence, but still...) get this very poor layout? Rather staggering, this. Fram (talk) 14:02, 21 August 2014 (UTC)

Fram, this is a long standing issue, reported a long time ago, even marked as High, but as usual, even if it gives an awful experience for new comers, its priority doesn't really seem so high. I think most people have simply given up complaining about VE, since most reports are marked as enhancements or minor, and stay open for so long... --NicoV ^{(Talk on frwiki)} 15:04, 21 August 2014 (UTC)

That's certainly what I've done, as things just don't get fixed in any kind of timely manner. Eric Corbett 22:03, 21 August 2014 (UTC)

Is there a way to add or change a template description?

Tracked in Phabricator
Task T71866

When editing Hepburn romanization#Hepburn romanization charts using VE, I can double-click on the word "red" and it opens a popup that reads "This template changes the color of any supplied text to red." (Very handy!) When I double-click on the word "blue" below it, a popup opens that reads "You are adding the "Blue" template to this page. It doesn't yet have a description, but there might be some information on the template's page." If I wanted to change that description to something more descriptive, like exists for "red", is there a way to do that within VE? 28bytes (talk) 14:06, 21 August 2014 (UTC)

@28bytes: Template pages can't be edited with VE, either natively or via the template dialog. Personally, I think it would be a mistake to add such functionality to the dialog, since mucking with TemplateData isn't something we want relative newcomers to do. (Consider the length of the documentation at Wikipedia:VisualEditor/TemplateData.)

On the other hand, it would be nice if there was a way for editors to post a comment or request on a Template Talk page, directly via VE, rather than having to do this as a separate edit (assuming they can figure out how to).

It would also be nice if the system were to gather (queryable) data for which templates have been seen (and with what frequency) in the VE template dialog where such templates lacked TemplateData.

Finally, fyi, I've added TemplateData for the template {{blue}}, at the page Template:Blue/doc, and did the same for the other color templates lacking TemplateData. -- John Broughton (♫♫) 17:31, 21 August 2014 (UTC)

Thanks John. I like your idea about gathering stats for TemplateData-less template views; that would be a great report that people could use to prioritize which TemplateDatas need to be added. 28bytes (talk) 17:57, 21 August 2014 (UTC)

Filed as bugzilla:69866. —TheDJ (Not WMF) (talk • contribs) 18:24, 21 August 2014 (UTC)

Category additions with VE are FUN!

Open a random page in VE. My luck of the draw gave me Zprdeleklika. Use the three lines button to get to the categories. You have two of them. Cancel the category screen. Open it again. You now have four categories. Cancel. Open. 6 Categories...

Now, add one. Whichever one you add, you get it as many times duplicated as you have done to the pre-added ones.

Let's try something. I don't know if everyone will get the same results, but again add a category. Start with typing e.g. "1995 es". Perhaps you will get a scroll bar to the right (I don't always get this for some reason). Click the scroll bar button at the bottom (to scroll down). Oops, there goes the selection list... Now, when looking through the few suggested categories, something extremely strange happens: the tool proposes some completely made-up ones. In this case, I get Category:1995 establishments in 1995 as a suggestion. Other tries gave me Category:1991 estabilshments in Belgium (sic!), Category:1992 estabishments in Indonesia (again sic!) and Category:1998 establishments) (with the final round bracket, sic).

Now, I cancel. I open the cats again. Oh, all the cats I added before the cancel are still there? So what was the point of cancelling? Oh well, then I just open one I don't want, and use the trash can icon. Perhaps use it twice? Three times? No, nothng happens. Perhaps I need to use the "apply changes" instead? Ooh, nice, the top of the cat frame starts to display slowly moving diagonal stripes, as if something is happening. And it goes on, and on, and on... Cancel? Too late, you're stuck!

As a user of VE, you have no way of knowing which cats exist and which don't. I fully understand that the possibility to add non-existing cats exists, this is necessary. But the system should never suggest cats which don't exist. And it should use a workable interface, obviously, not what we have here.

Basically, the category interface of VE totally and utterly sucks. Completely. More than a year after VE was implemented as the default editing environment. The general arrogance of some important people at the WMF is staggering when one takes into account the abysmal track record they have in implementing new tools and communicating with the editor community. Things like this only make people less willing to give them the benefit of the doubt. Fram (talk) 14:44, 21 August 2014 (UTC)

The doubling of categories is a bug scheduled to be fixed shortly, per Wikipedia:VisualEditor/Feedback/Archive 2014 3#Category duplication bug (display). Problems with redlink categories have been noted here, and there are related bug reports: Wikipedia:VisualEditor/Feedback/Archive 2014 3#Displaying categories, particularly redlink ones. -- John Broughton (♫♫) 17:38, 21 August 2014 (UTC)

And the invention of new cats by VE, that's a new one? Or just one that hasn't been reported yet? And the complete breakdown of all functionality? (Not a question for you, John Broughton, your help is appreciated). Fram (talk) 20:01, 21 August 2014 (UTC)

The duplication bug seems to have gone together with most of the other problems, the very peculiar "let's suggest cats that don't exist and don't make any sense" one clearly remains, I just got a suggestion for Category:1895 establisANONYMOUS IS LEGIONhments. Has ANONYMOUS hacked Wikipedia or VE? Anyway, can anyone else duplicate these very strange cats? Just try anything, and after a few trie syou are bound to get very strange categories in your suggestion list. :-)

Fram, I'm reproducing the problem with the strange cats: If I try adding a category starting with "1895 es", the categories suggested are: "1895 essays" (good!), "1895 esta6blishments" (bad!), "1895 establisANONYMOUS IS LEGIONhments" (bad!), ...

And an other problem: when I try to click on the vertical scrollbar of the dropdown list of suggested categories, the dropdown list simply disappears. The only way I've found to view what is after the 5th suggestion is to use the arrow keys, the mouse doesn't work at all. Win XP, FF ESR 17.0.2. --NicoV ^{(Talk on frwiki)} 09:44, 22 August 2014 (UTC)

nowiki added in otherwise unmodified part of the article

Hi, in this modification, VE added nowiki tags in a paragraph that wasn't modified by the contributor. As usual, the nowiki tags are not necessary, and even if escaping the single quote was necessary, there's no need to escape half a sentence when there's just a single quote. --NicoV ^{(Talk on frwiki)} 07:00, 22 August 2014 (UTC)

Sure the editor did not make a change to that section ? I think he tried to remove the space before Homo Sapiens..... —TheDJ (Not WMF) (talk • contribs) 07:13, 22 August 2014 (UTC)

Ah yes, missed that one. But the second remark stays: it's the single quote that needs escaping, not half the sentence. --NicoV ^{(Talk on frwiki)} 07:59, 22 August 2014 (UTC)