From Wikipedia, the free encyclopedia
Jump to: navigation, search
Share your feedback
Report bugs
Your feedback about VisualEditor

Use this page to tell the Wikimedia developers your ideas and issues about using VisualEditor. All comments are read, but personal replies are not guaranteed.


Please click here to report a problem with VisualEditor.
Please include your web browser, computer operating system, and Wikipedia skin (usually Vector, sometimes Monobook).
Please click here to make a suggestion.
Ideas about user interface choices and the priorities for adding new features are especially welcome.

Other ways to contact the team More

Help Local archives

VisualEditor meeting[edit]

This was announced in the newsletter and spammed to several mailing lists, but here's another reminder: The first of a weekly series of open meetings about VisualEditor will be tomorrow (Wednesday, 11 February 2015) at 12:00 (noon) PST (20:00 UTC). These meetings are related to the Engineering team's priorities for the current quarter. We will discuss the release criteria for VisualEditor, jointly prioritise the work of the team, and talk about the bugs and features which are most important to you, including this list of tasks that have been nominated for higher priority.

We particularly welcome the presence of volunteers who enjoy contributing MediaWiki code. The joining instructions have been posted on The meeting will use w:WebEx, which for some computers may require installing a plug-in, so please review the instructions well in advance. Whatamidoing (WMF) (talk) 20:05, 10 February 2015 (UTC)

I was interested in participating, until I looked at the list of 72 tasks to be discussed. Of those, I count five as adding functionality for all users, two as being helpful to beginners, and 65 about fixing bugs, making things run faster, and other matters that tend to result in glazed eyes among non-programmers.
The five "added functionality" tasks include two "rework" tasks (my word) - phab:T76398 and phab:T76397 - and one enabling task (phab:T89054), so what's left under "adding functionality" is just phab:T62768 (the task discussion is about using an ISBN to generate a citation) and phab:T53798 - contextual help everywhere. Nothing about increased table-editing functionality. Nothing about how VE should handle the tens of thousands of articles where it now can't edit citations because their text is within a reflist template. Nothing about the inability to navigate around (or copy from) the main text when adding a category to an article. And I'm sure I'm leaving out lots of feedback about missing functionality, or less-than-ideal design decisions, as posted at WP:VE/F or WP:VE/KP and tracked in Phabricator.
I don't want to minimize the importance of bug fixes, speed improvements, etc. Performance issues and editing glitches are definite turnoffs; people who aren't been paid to edit (and no one is) are generally unwilling to use tools that have a high frustration factor. So have at it. I'm just noting that experienced editors, such as myself, who aren't interested in doing programming, aren't likely to find much of this meeting to be of interest. -- John Broughton (♫♫) 06:20, 11 February 2015 (UTC)
Thanks, but no thanks. That seems like a feeble attempt to say that the community is involved, but it looks like again as just a smoke screen: WMF as decided that VE will be ready (same story as before...) in less than 2 months, and that's all. But there are still bugs that damage articles on a daily basis, which have been reported for months, and still nothing (visible?) is being done about them (nowiki, deleted categories, empty titles, links with wrong destination, ...). Also, is there any recent study about VE related to vandalism ? My impression on frwiki is that the percentage of vandalism is more important among contributors using VE. Added to the bugs, I really have the feeling that VE is not productive at all on frwiki. --NicoV (Talk on frwiki) 12:36, 11 February 2015 (UTC)
Is there a list of bugs/enhancements that the VE team regards as prerequisites to another release on en-wiki? That is, is there a definition in functionality terms of what is required for VE to be ready? Mike Christie (talk - contribs - library) 12:46, 11 February 2015 (UTC)
Mike Christie, the purpose of the meetings is to determine what should be regarded as prerequisites to another release here. This list of tasks shows the ones that have been nominated or accepted so far for that status. The current list is not complete, so if there are particular things you'd like to have added, then please let me know.
NicoV, I haven't seen any recent studies about VisualEditor except small-scale user testing with new editors (e.g., "Question: Can you figure out how to add an external link? Answer: Um, no.") However, the overall impression is that the amount of vandalism has not increased at fr.wp, and if the total vandalism is the same, then which editor is being used to do it is not likely to be relevant.
John Broughton, if you have specific bug numbers that you would like added, then please let me know. Whatamidoing (WMF) (talk) 18:31, 11 February 2015 (UTC)
In addition to the very old bugs I have cited, what about fixing the new ones that damage articles:
Don't you think that, before talking again about putting again VE by default for everyone, it should be nice to have a version that doesn't damage articles? --NicoV (Talk on frwiki) 11:24, 15 February 2015 (UTC)
Hi NicoV, thanks for this. The first might be phab:T89383, which should be fixed in the next update. I've left a note for Jean Po (the only logged-in editor in those diffs). From the bug comments, the bug is in a component of Parsoid that is called "selser".
I can't reproduce the second one. I could (once, but not since then)) add a duplicate category (which should not be permitted), but I can't give different sort orders to the two cats. It keeps blanking one. It's a logged-out editor, so a low chance of finding out any further information.
By the way, is it usual at the French Wikipedia to specify a category sort order that is exactly the same as the article title? Whatamidoing (WMF) (talk) 22:58, 15 February 2015 (UTC)
No, it's not usual, I don't know it's that way on this article (but it's very old). --NicoV (Talk on frwiki) 04:37, 16 February 2015 (UTC)
Whatamidoing (WMF), I tried reproduce the second one without any success, but I saw an other minor one: when I set the sort key for "Villes et villages fleuris" to "Catégorie:Villes et villages fleuris", then VE thinks there's no modification to the page. --NicoV (Talk on frwiki) 04:53, 16 February 2015 (UTC)
Thanks for the update, NicoV. Does it sound like phab:T74168 again to you? Also, there was another bug a while ago (reported as Chrome only, but possibly intermittent) that seemed to depend on whether you used the Return key or the mouse to close it, so it would be helpful to have the exact details on what you did. Tomorrow's a US holiday, but User:Krenair might be working anyway, and he's probably the best person to deal with this anyway.
(I wish that I had a screenshot or diff of the time that I added a second copy of an existing category. Now I'm worrying that I had a typo or something in it, and I've got no way to prove that it really was a duplicate.) Whatamidoing (WMF) (talk) 05:15, 16 February 2015 (UTC)
No, doesn't look like phab:T74168, it really seems to be the "Catégorie:..." in the sort key that makes VE miss the modification (it worked with other things, but not with "Catégorie:..." several times). I think I used the mouse to close the dialog, no Return key. --NicoV (Talk on frwiki) 05:34, 16 February 2015 (UTC)
Jean Po replied that he's using Firefox on Windows 7. Perhaps testing should focus there. Whatamidoing (WMF) (talk) 20:53, 17 February 2015 (UTC)
Whatamidoing (WMF), I completely disagree with your sentence "if the total vandalism is the same, then which editor is being used to do it is not likely to be relevant". VE usage is probably around 10% of total edits, so its impact on total vandalism could be easily masked by other factors: for example, if vandalism is twice as frequent with VE (figures exagerated of course), it would only account for an increase of 10% of total vandalism and other factors (better tools developed to fight vandalism, ...) could easily compensate this increase (if not even hidden by normal fluctuations). --NicoV (Talk on frwiki) 10:44, 16 February 2015 (UTC)
Under those circumstances, then total vandalism would not be the same, would it? In your scenario, total vandalism has increased.
VisualEditor is being used for about 14% of mainspace edits at the French Wikipedia. If vandals were exactly as likely as any other editor to use VisualEditor, then you would naturally expect 14% of all acts of mainspace vandalism to occur in VisualEditor. However, their choice of editing environment is not randomly distributed: Vandals are almost always inexperienced editors, which means that they have a higher likelihood of choosing VisualEditor, and high-volume editors (very) disproporationately use the wikitext editor. Inexperienced editors (and espeially IPs) are far more likely to vandalize an article that high-volume registered editors like you and me. In fact, at the moment, 40% of the edits made by IPs used VisualEditor, and 60% are in the wikitext editor. Since most (but by no means all) vandals are logged-out users, I would not be the least bit surprised to learn that 40% of vandalism happened in VisualEditor, solely because 40% of the group that is most likely to vandalize an article is using VisualEditor.
What matters from the perspective of RecentChanges patrol work is not the editing environment that a vandal chose. What matters is how many times I have to clean up a vandal's mess. If I had to clean up 100 acts of vandalism "yesterday", all of which were perpetrated in the wikitext editor, and "today" vandals are splitting their time 40-60 with VisualEditor and the wikitext editor, but it's still a total of 100 acts of vandalism, then there has been no change in the amount of vandalism. The undo button works identically in both cases; the vandal's choice of editing environment cannot impose an extra burden on me.
What would be worrisome is if vandalism went up—if, for example, the introduction of VisualEditor resulted in the same 100 acts of vandalism in the wikitext editor plus another 40 acts of vandalism in VisualEditor. However, there's no evidence that there has been any change in the amount of vandalism at all. Whatamidoing (WMF) (talk) 21:26, 16 February 2015 (UTC)
Whatamidoing (WMF), are there any statistics available on vandalism ? Because you look like you're carefully avoiding to say that "there's evidence that there has been no change in the amount of vandalism"... --NicoV (Talk on frwiki) 08:32, 17 February 2015 (UTC)
I don't believe that any research on that question been done specifically at the French Wikipedia, which is what you would need to answer a question about what's happened at the French Wikipedia in particular. Previous (now somewhat elderly) research showed no increase in vandalism here at en.wp. I don't know if a final report was ever published. Whatamidoing (WMF) (talk) 20:34, 17 February 2015 (UTC)
NicoV, based on your bug reports and feedback, we spent a couple weeks reworking the nowiki insertion algorithm for quote tags since it disproportionately affects non-english wikis like fr, it, ru, etc. While the problem is non-trivial, we feel we improved it significantly. Those fixes were deployed on Jan 5th, 2015. If you see more problematic nowikis for quotes, can you please point me to diffs so we can work on those? Thanks. SSastry (WMF) (talk) 21:33, 16 February 2015 (UTC)
Hi SSastry (WMF). I wasn't often connected to Wikipedia in the last 2 months (travelling, only came back 2 days ago), but I can see that the situation about nowiki for quotes seems to have improved a lot during this time, and I really thank you for that. I don't recall seeing this kind of problems since I came back (I will tell you if I find some).
But, I still think that there are other situations where adding nowiki tags could be prevented in VE. A few examples from edits in the last hours on frwiki:
  • nowiki around an extraneous whitespace at the beginning of a line, like in Bni Hadifa: even with the nowiki, the whitespace is not visible in the end result, so it could be entirely removed instead of escaped. Other examples: Gyropalette
  • nowiki after an internal link because the whitespace has been included at the end of the link text, like in Ophrys: it would be better to put the space after the link (no nowiki needed) than inside the link. Other examples: Lycée en France
  • nowiki that result in a link not covering all the text, like in Charpentier (1) or (2): it's very rarely what the contributor intended to do
  • Empty title with nowiki, like in Emmaüs Solidarité. Other examples: Kelt 550
  • Existing internal link replaced by an escaped internal link, like in Gare de Nogent-sur-Seine
  • Italics formatting around no text, like in Ben Affleck
  • Strange construction, like in Hervé Marly where a nowiki is after a link with no displayed text...
  • nowiki around a dash in a table, like in Malika Ayane: not entirely sure about this one, but would putting a space between the pipe and dash give the same result?
As you can see with examples that happened in only the last few hours, there are still a lot of problems with nowiki in VE... If they could be fixed like the problem with the quotes has been fixed, that would be great. --NicoV (Talk on frwiki) 22:13, 16 February 2015 (UTC)
NicoV Great! Good to get that confirmation about quotes. As for the rest of the scenarios, in Parsoid, we have resisted changing content we receive from clients, since as a general principle, it is hard to know what is intended vs what is okay to change / fixup since Parsoid caters to clients that is not just the VE. That said, there are some scenarios in your examples above where we could perhaps safely fixup without harm. The whitespace at beginning of line, whitespace at end of link, empty title without content, empty italic/bolds are perhaps scenarios Parsoid can fixup. The other scenarios are a bit more unclear. For example, putting a space between a pipe and a dash will eliminate the nowiki but change rendering in some cases. Similarly, nowikis because of links not covering entire text, or because of link-wikitext chars in text, or the strange construction case are not something Parsoid can fixup arbitrarily since it is possible to imagine scenarios where the HTML rendering that Parsoid receives is exactly what was intended by the client asking Parsoid to convert it to wikitext. But we'll take a look at the other 4 cases and work on them. Thanks! SSastry (WMF) (talk) 00:45, 17 February 2015 (UTC)
SSastry (WMF), thanks for the answer. I don't think that all the problems I reported above should be fixed by parsoid, but some could be prevented (or at least happen a lot less frequently) by changing VE itself (either the GUI or the behavior) and not relying on Parsoid on cleaning up the mess. --NicoV (Talk on frwiki) 08:29, 17 February 2015 (UTC)
As I understand it, VisualEditor never adds nowiki tags, so all of the diffs involving nowikis are Parsoid's territory. The italicized nothing might be due to someone typing something, italicizing it and then removing the text. It looks like the system is trying to preserve the character formatting (just like a word processing document preserves your font and character settings even if you blank the text). Whatamidoing (WMF) (talk) 20:40, 17 February 2015 (UTC)
Whatamidoing (WMF), I didn't mean that VE was adding the nowiki tags, but that what VE gives to Parsoid sometimes requires either adding nowiki tags or changing wikitext. I believe VE should be smarter rather than relying on Parsoid to clean up everything behind it: for example, when editing a table cell, it's obvious when you look at wiki syntax that a "-" at the beginning of a cell is a problem. VE should know that, and for example silently add the extra whitespace in front to have a simple wikitext rather than having to end up with a nowiki tag.
A word processing document like MSWord doesn't preserve your font and character settings in every situation, it's a lot smarter:
  • put some bold characters in a middle of a word, select them and delete them: bold is not kept
  • put some bold characters in a middle of a word, delete them one at a time with backspace: bold is kept if you don't move the cursor (so characters are bold if you start typing again), but is lost if you save or move the cursor (no unnecessary formatting is kept).
--NicoV (Talk on frwiki) 13:50, 19 February 2015 (UTC)
Nico, VisualEditor doesn't deal with wikitext. It "thinks" in HTML. The process is like this: you open a page. The (wikitext) file is sent to Parsoid. Parsoid converts it to HTML and sends the HTML to VisualEditor. You make whatever changes you want, and save the page. VisualEditor sends the HTML back to Parsoid. Parsoid converts the HTML to wikitext, and sends the wikitext back to the database. In theory (although not in practice at the moment), it is possible to use VisualEditor without Parsoid to edit an HTML page directly.
Your analogy to word processing documents is missing the critical point: the unnecessary italics weren't in the middle of the word. They were at the end of the last word in a line, where many (but not all) word processors do retain the "unnecessary" formatting. Personally, I'd be in favor of removing pointless formatting, but the current behavior isn't entirely unreasonable for the model. Whatamidoing (WMF) (talk) 01:13, 20 February 2015 (UTC)
Whatamidoing (WMF), I don't think making a distinction between wikitext or HTML is relevant: VE should be able to handle situations where there's a space before the dash in the table or where the dash is escaped by a nowiki tag... So it could be smart enough to do a correct thing. I wanted to show this on an example, but the only result I managed to do with VE is damaging the existing table: for the first two lines of the table, I tried to put in the 3rd cell the same content as what was in the 1st cell ; the result with VE is a damaged table (2 cells have been fused) and the content I tried to add is nowhere... An other case of VE damaging articles... --NicoV (Talk on frwiki) 13:33, 23 February 2015 (UTC)
SSastry (WMF), I found an edit where nowiki doesn't seem well handled for quotes. --NicoV (Talk on frwiki) 13:35, 19 February 2015 (UTC)

The results from the first meeting were sent out in e-mail: By the way, the next meeting is about 36 hours away, and only eight more items are in the nomination list so far, and a couple of those were leftover from last week. If you've got ideas about what should be considered, then please add them (or give me the bug number, and I'll add it for you). Sooner is better than later, so that yours will be more likely to be discussed this week. Whatamidoing (WMF) (talk) 05:43, 17 February 2015 (UTC)

For me, every bug that leads to damages in articles. For example, the one where categories are moved inside a ref tag like this edit (I don't know the bug number). --NicoV (Talk on frwiki) 07:09, 17 February 2015 (UTC)
And preventing the addition of empty gallery tags, like in Ludovic Bruni. --NicoV (Talk on frwiki) 16:48, 17 February 2015 (UTC)
Phab:T74048 (about categories) was accepted last week.
The diff for the empty gallery tag is tagged as "Switched". Therefore, that may have been added in the wikitext editor (there's a button in the wikitext editing toolbar that adds galleries). I can't get VisualEditor to add empty gallery tags (in Safari/Mac). Can anyone else? Whatamidoing (WMF) (talk) 20:51, 17 February 2015 (UTC)
This edit that shows 2 problems: category moved in the middle of the article and comments moved in places where they won't be useful any more. --NicoV (Talk on frwiki) 06:29, 18 February 2015 (UTC)
This edit where VE created an internal link with only a nowiki tag as the displayed text + other damages to internal links. --NicoV (Talk on frwiki) 10:18, 19 February 2015 (UTC)

Html tags and styles added[edit]

I am not sure if someone reported this before: [1]. -- Magioladitis (talk) 09:46, 20 February 2015 (UTC)

I'm getting tired of fixing these. another one. Bgwhite (talk) 07:28, 21 February 2015 (UTC)
Thanks for the note. The fix is supposed to arrive here in about 39 hours. Whatamidoing (WMF) (talk) 16:38, 23 February 2015 (UTC)

HTTP 503 errors[edit]

For the fourth of fifth time, I've had an edit fail catastrophically - I can't save the edit at all. I can rescue text (by doing a copy/paste to another place), but citations are irrevocably lost. As you can imagine, this makes me quite reluctant to use VE.

I think I've been able to replicate the problem, so I invite someone else to do this:

Update: it now appears to me that only steps 1 (of course), 4, and 5 are needed - the problem is with ending a VE session by using "Cite from URL". Those inclined to test this theory need to enable that functionality via their vector.js page - see User:John Broughton/vector.js for specifics.

  1. Open Seaside, Florida for editing in VE.
  2. In the “Design”section, at the end of the text, press Return/Enter to start a new paragraph.
  3. Paste in this text:  Seaside has no private front lawns. Sod is not allowed, only native plants in front yards.
  4. Put a footnote at the end of that new text: In the Cite menu, select Cite from URL, then use:
  5. Save page. Put “Adding info and cite” as the edit summary. Click “Save page”

What happens then, to me, is the “Save page” button fades to grey. Clicking “Review your changes” generates the following error message, as does resuming editing and trying “Switch to source editing”:

Error loading data from server: Unsuccessful request: parsoidserver-http: HTTP 503.

If someone else successfully makes this edit, please revert the change and post here. I'll then try it again, using both my registered account and another (declared alternative) account to see if the problem persists, and if so, if it's somehow tied to my browser or computer. [I tried both Chrome and Firefox for the above, so I doubt this is browser-related.] -- John Broughton (♫♫) 19:48, 22 February 2015 (UTC)

True, something odd is going on (Windows XP, FF 35.01). While I get no 503 error, the save windows hangs (with disabled save button and an eternal "Saving ..." progress message on top of the save window, when I try to add this citation via Cite from URL at the end of "Escape to Create". Second problem: Cancelling and playing around with save/discard I managed to loose the "Cite from URL" menu item from the VE menu somehow - but can't reproduce it now :/ (the menu item reappeared after leaving and re-starting Firefox). Ignorant guesses: Either the cite function is not ended correctly (and completely) or there is some problem in interaction between cite function and core VE interface. GermanJoe (talk) 21:14, 22 February 2015 (UTC)
Also got the 503 error now, after inserting the cite URL and trying to switch to "edit source" mode with "keep changes" option. GermanJoe (talk) 21:24, 22 February 2015 (UTC)
Some more test info (sorry for the triple-post): The created "cite news" structure appears to be corrupted somehow: Try copy-pasting the cite news item into a completely different article (even after closing your browser and disabling cite URL): the session will hang again. Manually creating a new "cite news" object and copying the single parameters step by step creates a correct citation though and can be saved. GermanJoe (talk) 21:51, 22 February 2015 (UTC)
John, the Citoid service is unstable, and the script you're using to access it is purely experimental. I recommend turning it off, and using the regular (i.e., non-experimental but non-automatic) Cite templates. Once the Citoid service can reliably stay up for more than three minutes in a row, then we'll get the proper tool here. Whatamidoing (WMF) (talk) 16:43, 23 February 2015 (UTC)

Existing ref damaged with nowiki tags[edit]

Hi, in this edit, an existing reference has been damaged by VE by putting nowiki tags around the opening ref tag. The result is that a correct reference has been replaced by escaped ref tags in the middle of the text. --NicoV (Talk on frwiki) 22:18, 22 February 2015 (UTC)

Parsoid edge case bug. Created T90448. SSastry (WMF) (talk) 15:56, 23 February 2015 (UTC)

Wikimania form issue[edit]

Bug report VisualEditor
Description Wikimania form issue, reported for others from Wikipedia_talk:WikiProject_Women's_History#Presentation_proposal_for_Wikimania_2015
Intention: Other users tried to sign a Wikimania proposal linked at the above link
Steps to Reproduce: n/a, reproduced
Results: "Won't let me put in tildes, won't let me put in my UserName. Won't let me do anything. Just says <no wiki>."
Expectations: Ostensibly to sign the proposal
Page where the issue occurs wm2015:Submissions/How_to_Pick_Up_More_Women
Web browser
Operating system
Workaround or suggested solution

czar  13:48, 23 February 2015 (UTC)

Thanks for the pointer. I have replied there. Whatamidoing (WMF) (talk) 16:50, 23 February 2015 (UTC)

br tags inserted inside titles[edit]

In this edit, a br tag was inserted by VE inside a title which is totally useless and makes wikitext more complex. --NicoV (Talk on frwiki) 15:28, 23 February 2015 (UTC)

Known, but no clear idea why it's happening, and James F indicates that they've made no solid progress on it. Whatamidoing (WMF) (talk) 18:15, 23 February 2015 (UTC)

Useless span tags[edit]

In this edit, completely useless span tags were added by VE. --NicoV (Talk on frwiki) 17:27, 23 February 2015 (UTC)

That looks like phab:T78540. My bet is that the editor is using Safari, because this problem happens to me all the time in Safari. It's already on the Q3 blocker list. Whatamidoing (WMF) (talk) 18:19, 23 February 2015 (UTC)

Meeting at 00:00 UTC Thursday[edit]

The next bug triage meeting will be at midnight UTC on Thursday, which is 16:00 PST on Wednesday for West Coast folks. This one is timed to be easier for some people in Asia to attend. Information about how to join is at mw:Talk:VisualEditor/Portal, but as of this message, the "follow this link" will take you to last week's meeting, which won't be very useful. I'm trying to track down the new link (WebEx requires a new link every single week) and it will be posted there before the meeting starts (because if it isn't, then I can't join the meeting, either.  ;-) .

Minutes from the last one can be read on wikitech-l here. Whatamidoing (WMF) (talk) 05:19, 24 February 2015 (UTC)

I hope all the bugs that damage articles are taken into account. An other bug that damage articles is the one where categories get moved in the middle of link inside references, like this edit which also contains an other bug: span tags with id current-appletv spread in the articles in middle of words... --NicoV (Talk on frwiki) 07:30, 25 February 2015 (UTC)
That one was accepted two weeks ago. If you've figured out anything about how to reproduce it, then the devs would still like to have more information. Whatamidoing (WMF) (talk) 23:47, 25 February 2015 (UTC)

Re-use cites doesn't work if cite is in a template[edit]

Bug report VisualEditor
Description Choosing cite re-use doesn't show citations embedded in templates
Intention: I was trying to re-use a cite that is within an infobox template
Steps to Reproduce: #Went to this revision
  1. Delete reference 3, in the first paragraph, and the same cite to reference 3 in the History section.
  2. From the cite menu, choose re-use
  3. Attempt to choose the reference 2, in the infobox, but it doesn't appear.

I haven't checked this on other pages

Page where the issue occurs
Web browser Safari 6.1.6
Operating system Mac 10.7.5
Skin Default
Workaround or suggested solution I suspect the only workaround is the wikitext editor

Oiyarbepsy (talk) 04:41, 25 February 2015 (UTC)

It's a known problem. Transcluded refs are 'invisible' to VisualEditor. I don't expect this to get fixed any time soon (although there's some hope for it being fixed eventually). Whatamidoing (WMF) (talk) 23:43, 25 February 2015 (UTC)


I'm not confident in using Phabricator, so I don't know if these suggestions have already been made, and if so, how they were dealt with. But, nevertheless, I'd like to know if they could make it to the list for the next Triage meeting for acceptance. I listened in to the call on the last meeting but wasn't sure if I could add anything useful so stayed silent :-)

  1. Show Categories while in VE mode. It is possible to add/view/remove categories as part of the "page options dropdown menu on the right hand side of the toolbar. I think this is a bit "hidden away" for a standard feature of an article, but more to the point is that any categories which the article is in are NOT visible to the editor while in VE mode. Unless you know to look, you would never know that they exist. Hiding the categories while in VE mode seems to be deliberately designed to be different from how the "reader" will see the article, which seems to go against the principle WYSIWYG. Wittylama 17:31, 25 February 2015 (UTC)
  2. Section editing. I'm SURE this has been discussed somwhere, but doesn't the inability to edit just 1 section make edit-conflicts a whole lot more likely? Speaking of which, I would also say that a a edit-conflict screen that is consistent with the UI of the VE should be part of the VE rollout criteria.
  3. While not directly the VE-coding team's responsibility, I would like to see at least 1 pre-existing documentation page for en.wp style conventions written to include parallel instructions for how to achieve the "correct" formatting in both traditional and VE modes. Perhaps for example Wikipedia:External_links#How_to_link which could be augmented with info already produced for Wikipedia:VisualEditor/User_guide#Editing_links. Eventually the communities of all wikis will need to rewrite all documentation to explain to people who have ONLY used VE what is the correct methodology. I think there should be at least 1 example of how this should be achieved. Perhaps a two-column approach for every example - "the old way, and the VE way". This is NOT the same as the VE User Guide which has been produced for people learning to swap from the old to VE systems. Rather, this is about starting the process of updating documentation of the normative approach to a task: the expectation is that VE will be used for normal editing, and 'code editing' will be for unusual circumstances. We need to have at least 1 example of documentation that conveys that.
  4. Adding template within a template doesn't show as intended. This is a genuine bug report (as opposed to feature request). See this edit. While in Visual Editor I double-clicked to open a pre-existing "blockquote" template, and moved the cursor to the "source" field within the VE template dialogue popup. I then clicked "show options", "add template" and typed in "cite book" to chose the template I wanted to add to that field - so far so good. I put in some placeholder content ("test test, 1, 2, 1900") and saved the edit. As you can see (here's the code-editor view of the same edit, what should have appeared as a footnote within the "blockquote" template appears without "ref" tags and outside the blockquote template. It also adds a bunch of blank fields to the code view that I never input data for: {{Cite book|title = test test|last = 1|first = 2|publisher = |year = 1900|isbn = |location = |pages = }}.
  5. Screen jumping when focusing on external links. This is another "genuine" bug report, but more difficult to reproduce consistently (which is part of what makes it so irritating). Go here: User:Wittylama/SAI, which is (at the time of writing) a userspace sandbox article with LOTs of tables. This makes the load time for VE VERY LONG (that's not the problem though, just a warning). Now, once you're in VE, focus the cursor one of the links inside one of the tables by double-clicking. Then, focus the cursor on a different link in a different table (sometimes this requires double-clicking to activate, sometime triple-clicking. I'm not sure why yet). After you've clicked between a few different links (try alternating between internal article, external website, external PDF and internal footnote links) you'll see that the screen jumps around seemingly randomly. Sometimes it goes right back to the top of the article, sometimes it refocuses the window with your selected link on the bottom row of the screen, sometimes it moves smoothly. It's all very random...

I hope this is useful! Please tell me if you need more info. Wittylama 17:31, 25 February 2015 (UTC)

Thanks for the list, Wittylama. Can you remind me which browser/OS you're using? It's probably relevant to the last one. Whatamidoing (WMF) (talk) 23:51, 25 February 2015 (UTC)
Hi Whatamidoing (WMF), I'm on Chrome (v.40) in Mac (OSX 10.10). So, quite up to date!
I've meanwhile found a more precise way to replicate the screen jumping issue: Go to the article I mentioned, User:Wittylama/SAI, open VE and scroll down a few page lengths until you get to the "awards" section. You will see a colourful table his is the first table called "Ribbon color" with a footnote inside the second cell of the first column. Activate the cell, then try to activate the footnote to edit it. You will be jumped right back up to the top of the page. When you scroll back down again the activation of the footnote works correctly the second time. Can you replicate that? Wittylama 12:01, 27 February 2015 (UTC)
@Wittylama: I can help with one of the questions posed. Edit conflicts are determined (by VE and the wikitext editor) on a (roughly) paragraph basis, not a section basis. So, no, opening an entire article for editing (in VE) doesn't increase the likelihood of an edit conflict - if you edit one section only, and another editor is editing a different section, there will be no edit conflict. [And yes, this should be in the documentation for Wikipedia, and isn't.]
As an aside, the way the wikitext editor handles edit conflicts is a known abomination. If VE had a much better way to deal with those, that would certainly be an incentive to experienced editors (as in, those who do lots of editing) to switch to VE. -- John Broughton (♫♫) 16:44, 28 February 2015 (UTC)
The documentation does mention this (e.g., Help:Section#cite_ref-1). But people already know that it doesn't, because we all heard this once upon a time.
Wittylama, I just upgraded to 10.10 myself, but I haven't installed Chrome. I think Safari may be having the same problem, though.
In terms of a better edit conflict system, I wonder if you would prefer something that looks like the other diff display. It shows the page, with text highlighted in red or green to show additions and removals. I can never remember where the page is, so I'll have to call on my distributed memory system to find the link for you. Whatamidoing (WMF) (talk) 18:50, 2 March 2015 (UTC)
@Whatamidoing (WMF): The alternative diff displays currently available are:
HTH. Quiddity (WMF) (talk) 21:07, 2 March 2015 (UTC)

@Whatamidoing (WMF): - The place on to see how to minimize edit conflicts is here - WP:Edit conflict. I see that you edited that page in December 2013, seven years after the developers changed the code for how edit conflicts are determined. So yes, most experienced editors here may have heard that the documentation says conflicts are by section - and that's because the documentation did say that, until just over a year ago. Unfortunately, most of us lack the time to keep rechecking technical documentation pages (hundreds?) to see what has changed and what has not. -- John Broughton (♫♫) 02:06, 3 March 2015 (UTC)

Multiple damages[edit]

In just one edit, it's obvious that VE is not ready to be activated by default:

  • Categories moved inside a ref tag
  • Completely useless nowiki tags added with italics/bold around them: why VE added italics/bold around nothing ?
  • Several comments outside a table moved inside the table in the middle of sentences (same situation for each apparently)

Honestly, it's been more than a year and a half, how long do we still have to fix so much damages in a production wikipedia? --NicoV (Talk on frwiki) 17:44, 25 February 2015 (UTC)

I think that the last item will be fixed with the patch for phab:T73085. The other two have been discussed above. Whatamidoing (WMF) (talk) 23:54, 25 February 2015 (UTC)

Human readable ref names[edit]

I love the cite re-use feature, but one thing that would make it a bit better is human-readable ref names. Over at Russian Jews in Israel, we have a cite that's <ref name=":0">blah blah</ref> and all the later ones are <ref name=":0"/>. It would be nice if Visual Editor generated human-readable names, such as, in this case, <ref name="">, using the last name for books and news, and the domain for urls. Oiyarbepsy (talk) 00:27, 26 February 2015 (UTC)

  • I was just coming here to report this same issue. In particular, automatically generating refnames using numbers is really problematic because the "name" given to the reference doesn't match the number generated for the reference. A parameter that allows the user to add a reference name would go a long way in alleviating this issue. While the URL may be one possibility, it could be quite long for some references, so an actual parameter where the user can determine the refname should be considered a priority. Risker (talk) 02:29, 26 February 2015 (UTC)
    • Not the URL, but just the domain name - like instead of Oiyarbepsy (talk) 02:57, 26 February 2015 (UTC)
      • This is a long-standing request. It's apparently on the list for "someday". Actually, (if memory serves) the feature was (very) briefly available in 2013 (or was that only in testing?). I don't remember why it was removed. Whatamidoing (WMF) (talk) 18:27, 26 February 2015 (UTC)
        • Yes, the user should, when using a cite, have the option to specify the name. But VE should suggest a name - that is, the user should always have the option of not typing anything because he/she is satisfied with VE's suggestion.
        • A problem with using a url to generate a (suggested) name is that some cites [to off-line sources] lack that. And many citations aren't even formatted as a template, so one can't assume that VE can even use a value within a parameter such as title=. So perhaps VE should use part of a URL if there is one (I suggest the segment just before .com or .org - that is, the text just before the generic top-level domain, such as "wikipedia"), and if no url exists, the longest text string in the citation, adding "1" or "2" or whatever to avoid duplication. -- John Broughton (♫♫) 02:21, 3 March 2015 (UTC)

Not possible to add special characters/nonstandard punctuation into citations[edit]

Bug report VisualEditor
Description Not possible to add special characters/nonstandard punctuation into citations
Intention: Trying to add an endash into a citation date parameter to clear a flagged formatting error
Steps to Reproduce: While editing using VE,
  1. Click "Cite" in the toolbar, select "Cite News"
  2. Type in data, including publication date of "August-September 2009"
  3. Save edit. An error message appears beside the reference information in the reference section: "Check date values in: |date= (help)"
  4. This is reproduced at User:Risker/comment
Results: The error message was caused because of the use of an ordinary hyphen instead of the regulation endash. I could not find a workaround to fix this in VE, because the "special characters" don't operate at the same time as the cite option is functioning.
Expectations: It didn't occur to me that this would be an issue; however, having seen that it is impossible to add this particular special character from my keyboard, it means that one probably can't add any other characters that do not appear on a standard keyboard, either.
Page where the issue occurs Integral House
Web browser FF 36.0
Operating system Win7
Skin Monobook
Workaround or suggested solution Entered the information using wikitext editor.

Risker (talk) 03:13, 26 February 2015 (UTC)

It's a known problem. I can offer several workarounds, of widely varying practicality:

  • Follow the directions in Wikipedia:How to make dashes to type dashes from your keyboard.
  • Don't use a citation template. Select "Basic" from the Cite menu instead. The "Basic" editor will let you use VisualEditor's Special Character tool.
  • Buy a Mac, and use the simple keyboard shortcuts ( Option- for an en dash), or use its native Edit > Special Characters palette.
  • Wait until phab:T62657 is resolved.

There is significant work being done on the special character tool. It will completely change during the coming weeks. Whatamidoing (WMF) (talk) 18:45, 26 February 2015 (UTC)

Addition of nowiki tags[edit]

This is the latest manifestation of an old problem. I simply tried to add a space using VE. Δρ.Κ. λόγοςπράξις 07:07, 28 February 2015 (UTC)

Dr.K., I see the space you added. To the best of your memory, did you click on or interact with the ref tag at all? Also, what's your browser and OS? Whatamidoing (WMF) (talk) 18:53, 2 March 2015 (UTC)
Never mind about the browser/OS information; it happens everywhere. The problem is in the wikitext: the ref tag is <ref name="telegraphDowning> when it ought to be <ref name="telegraphDowning"></nowiki>. Whatamidoing (WMF) (talk) 19:00, 2 March 2015 (UTC)
@Whatamidoing (WMF): Hi Whatamidoing. We just had an edit-conflict! Thank you for letting me know. I'm glad it was resolved. For historical reasons I just wanted to mention that I remember after doing the edit being surprised to discover that VE would add "nowiki" tags so far down the sentence from the point I inserted the space. I never got close to that ref tag. Thank you again and take care. Δρ.Κ. λόγοςπράξις 19:08, 2 March 2015 (UTC)
The rule of thumb seems to be that anything on the same line (of wikitext, not that it's easy to tell what's on the same line when you're in VisualEditor) is fair game. If you edit (only) other lines on the page, then it doesn't nowiki the invalid wikitext. Of course, the ideal solution would be that we don't have invalid wikitext anywhere, but that's a bit unrealistic for a project that anyone can edit. Typos will happen despite the best of intentions. Whatamidoing (WMF) (talk) 19:18, 2 March 2015 (UTC)

Italicizing wikilinks[edit]

I made this edit to italicize wikilinked words. VisualEditor behaved incorrectly, creating a piped link and putting the italic characters inside of it instead of simply adding the italics characters to the outside of the square brackets. Another editor had to make a second edit to fix it. When will this problem be resolved? Many thanks. --Albany NY (talk) 19:15, 1 March 2015 (UTC)

I don't know when it will be fixed, beyond "not very soon".
Actually, I'm not entirely sure that it ever will be fixed, because it's not actually "incorrect", and it didn't really need "fixing". Both methods are correct. It's just not the way I would type it in wikitext, because I wouldn't want to bother typing the name of the link twice. Whatamidoing (WMF) (talk) 19:12, 2 March 2015 (UTC)


Thanks for the reply. I would argue that the non-piped method is clearly superior because the piped link makes the wikitext more difficult to read. Is this a bug that the developers are working on? --Albany NY (talk) 21:49, 2 March 2015 (UTC)
I agree with Albany NY, and probably others also since an other contributor, Cyphoidbomb, took the time to fix this. Creating complex wikitext syntax for something that should be simple is really annoying, and I think it should be considered as a bug, a bug that should be fixed before wider release. --NicoV (Talk on frwiki) 22:14, 2 March 2015 (UTC)
Although I would agree this is not a bug, since wikitext will continue to be used I think this would be a useful enhancement. As Albany says it makes the wikitext much easier to read. Mike Christie (talk - contribs - library) 23:11, 2 March 2015 (UTC)
Let me be clearer: I don't personally like it, either. I do almost all of my reading in diff mode, so these things are very visible to me. However, it's not actually a bug. Realistically, and not unreasonably, replacing one technically correct approach with a different, also correct approach is naturally much lower on the priority list compared to, say, getting rid of the nasty [[Link|<nowiki/>]][[Link]] bug. I think it's useful to recognize the priority level, even though we are all unanimous in our agreement that one of the approaches is better than the other. Whatamidoing (WMF) (talk) 00:51, 3 March 2015 (UTC)
I agree -- I just wasn't clear that this was going to be considered as a future enhancement; I think it should be. But I entirely agree with you on the priority. Mike Christie (talk - contribs - library) 01:07, 3 March 2015 (UTC)

Triage meeting this Wednesday[edit]

Howdy. This is your reminder that the upcoming VE triage meeting will be held on Wednesday, 4 March at 08:00 PST (16:00 UTC). Full information about how to join the Webex call or the IRC channel, and the links to the IRC logs and minutes for the last appointment, live as usual at mw:Talk:VisualEditor/Portal. I'm looking forward to seeing you there! --Elitre (WMF) (talk) 18:35, 2 March 2015 (UTC)

Preview Option?[edit]

Looks and works excellent most of the time. Well done, all of you. A suggestion for future improvement, though, would be to add an option to preview what you've edited before clicking "Save page". This could be either a live preview, which I think is still in beta (no? yes?), or at least a non-live one. :) Yay for Wikipedia! SarahTehCat (talk) 17:47, 3 March 2015 (UTC)

Category update[edit]

A patch has been submitted for Bug T74048. They're backporting it today, so the problem should disappear in less than two hours. If it's still happening, say, tomorrow morning, then please let me or User:Elitre (WMF) know, so that we can get their attention back on the issue ASAP. Whatamidoing (WMF) (talk) 22:23, 3 March 2015 (UTC)