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

ISBN link[edit]

User agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36

It would be helpful to include a way to add an ISBN link.

Presidentman talk · contribs (Talkback) 16:31, 11 November 2015 (UTC)

You can edit pre-existing ones, but it's nowiki-ing new ones (if you just type one out with the WP:ISBN magic word). I'll ask what the plans are. My guess is that it's on the list, but not for soon. Whatamidoing (WMF) (talk) 17:58, 11 November 2015 (UTC)
Added the ticket number. —TheDJ (talkcontribs) 09:59, 16 November 2015 (UTC)
Update: It wasn't supposed to nowiki the new ISBN magic words, and it has been fixed. Whatamidoing (WMF) (talk) 23:44, 22 November 2015 (UTC)

ISBN-generated citation?[edit]

When will Citoid be able to take an ISBN and generate a citation? I ask because this functionality has been available for many years, elsewhere: OttoBib generates citations, when an ISBN is entered; the output can be set to be in Wikipedia format. -- John Broughton (♫♫) 03:08, 12 November 2015 (UTC)

Here there be dragons, or at least lawyers. On the tech side, it should be pretty straightforward at this point, but their ideal database (which might offer more than just ISBNs) requires a contract, which means that it requires lawyers. Whatamidoing (WMF) (talk) 02:21, 16 November 2015 (UTC)
phab:T108521 might be related ? —TheDJ (talkcontribs) 10:00, 16 November 2015 (UTC)
Yes, it is.
I just added this to T108521, because while OttoBib appears proprietary, there are alternatives:
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 ( ). 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?
And, hopefully, once an API is available, that's 90% of the solution.
-- John Broughton (♫♫) 17:25, 17 November 2015 (UTC)

Broken page with VisualEditor[edit]

To reproduce, try opening this revision of the November 2015 Paris attacks page with the VisualEditor. The page looks fine until the "Attacks" subsection, at which point raw wikitext becomes visible, starting with the text

{{quote box↵|title=Timeline of attacks↵|align=left↵|width=25%↵|quote=↵13 November

and then most of the rest of the page following that is lost. It's been some time since I've seen the VE break on a high-profile page like this. Browser: Firefox 42 on Debian Linux 8, on x86-64. Also verified with Firefox 42, and Safari, on MacOS X El Capitan. -- The Anome (talk) 11:11, 15 November 2015 (UTC)

The problem is with the invalid wikitext: <ref name="reuterstimeline /> contains unpaird quotation marks. The wikitext has been corrected since then. Whatamidoing (WMF) (talk) 02:22, 16 November 2015 (UTC)
Since that rev displays OK, despite the bad wikitext, can VE parse the wikitext in the same way the display code does, to avoid having large amounts of page text disappear in vedit mode? Mike Christie (talk - contribs - library) 02:32, 16 November 2015 (UTC)
Agreed. The "invalid" wikitext is not the problem here. What is and isn't valid in wikitext is a moot point: the only real spec for wikitext is the behavior of the mainline wikitext parser, which is defined by implementation, not any formal spec. For this reason, the VE's parser is intended to mimic the behaviour of wikitext processing, quirks and all. Here it doesn't, and things break because of it. Bringing this to the attention of the Parsoid team so they can fix it, in order to make the VE more reliable so that it can be deployed more widely without breaking the encyclopedia, is the exact and entire point of reporting this bug. What's the point in us filing bugs here if they are just going to be ignored? -- The Anome (talk) 08:03, 16 November 2015 (UTC)
"The problem is with the invalid wikitext" does not mean "this is just going to be ignored". Identifying the trigger for a bug is generally a necessary precondition for fixing it, and as the dev notes below, this bug report has indeed been fixed.
However, when you are next faced with a decision about whether to argue in favor of maintaining bug-for-bug compatibility between VisualEditor and the current state of the various pieces of "the parser", you may want to keep in mind that the parser itself is being replaced (e.g., phab:T89331). This means that invalid wikitext that (sort of) works today will not necessarily work in the future. Whatamidoing (WMF) (talk) 18:30, 17 November 2015 (UTC)
You are still faced with the bug-for-bug compatibility problem in one form or another, because you have a massive corpus of text that you need to maintain backward compatibility with one way or another. Removing HTML Tidy is a good thing, but every ambiguity in the syntax or implementation is still something that requires a human decision to resolve. This should have been obvious from the start of the project: getting to 80% working was quick and easy, it's getting to 100% (or even to 99.9%) that's asymptotically difficult.

I don't envy the VE team's task, as I have some understanding of the challenges involved in maintaining backward compatible in messy, running systems without breaking them. If you take a look at how the HTML5 team resolved the similar problem with rigorously defining a parser that was backwards compatible with the ad-hoc heuristic parsing of various previous flavours of HTML in earlier browsers, you can see the scope of the problem. In particular, you can never have an invalid document in a workable wikitext system: only a document that does something that perhaps does something you didn't expect it to do, otherwise human editing of wikitext will become impossible without programmer-level debugging skills. -- The Anome (talk) 19:04, 17 November 2015 (UTC)

Yes, it has always been known that Parsoid will have a reallly reallllly long tail of edge cases around "broken" wikitext. We have come a really long way towards addressing that. And, yes, we are working with the assumption that there is really no "invalid" wikitext. Instead, we have a bunch of different directions we are exploring for the longer-term. It remains to be seen how these will evolve and which will actually see the light of day in production, but backward compatibility as well as strategies for migration will be an important part of evaluating any of these solutions. SSastry (WMF) (talk) 19:29, 17 November 2015 (UTC)
It's good to know that the VE team are aware that there's no simple obvious clear-cut solution for this: I'm firmly convinced that understanding that is the first stage toward finding a real solution. That's good quality work. -- The Anome (talk) 20:11, 17 November 2015 (UTC)

Hmm, interesting. I've asked if this is something that Check Wikipedia can pick up. Regardless of VE, it might also be bad for 3rd party tools. And it's ugly :). Phab ticket created as well. Though I wouldn't mind if this is tackled in the PHP parser, rather than in Parsoid..—TheDJ (talkcontribs) 09:56, 16 November 2015 (UTC)

Thank you! -- The Anome (talk) 10:20, 16 November 2015 (UTC)
Arlo has fixed this and once this is tested, it will go live. Thanks for the bug report. SSastry (WMF) (talk) 20:56, 16 November 2015 (UTC)
Thank you again. Knowing that bug reports here are listened to and acted on is greatly encouraging. I still remember the earlier fiasco where feedback on the VE was solicited, but turned out to have been simply deleted instead of being read; I spent ages documenting bugs on that one, only to discover it was all in vain. It's nice to see the VE software development effort maturing: the system is definitely becoming production-ready. I wonder if there was a way that this particular bug could have been caught by automated testing? -- The Anome (talk) 18:54, 17 November 2015 (UTC)
Regarding automated testing, it is complicated. Parsoid does do automated roundtrip testing on 160K pages from a bunch of different wikis. But, these only tests Parsoid's ability to cleanly roundtrip what it parses without breaking pages (which is the most important requirement when pages are edited in VE or other clients). We do have a lot of parser tests which we continually update on an ongoing basis (ex: new test added from this bug), but edge cases in parsing come in different forms, and to discover all of them requires mass visual-rendering-diff testing (comparing Parsoid's HTML rendering with PHP parser's HTML rendering). Currently, we have a limited form of visual diff testing in place which we have used to uncover and fix different rendering issues, but detecting real diffs from spurious diffs is a more difficult problem which had prevented its deployment in a large-scale mass testing scenario. But, the good news is that, at the time of this writing, we have made progress on this visual-diff problem. Once this testing framework itself is well-tested (ha! :)), we'll use this to more uncover rendering difference between Parsoid and the PHP parser, as well as for other projects (ex: replacing Tidy with a HTML5 parser). Hope this answers your question. SSastry (WMF) (talk) 19:08, 17 November 2015 (UTC)
Cool. Thanks for all your hard work on this difficult problem. -- The Anome (talk) 20:14, 17 November 2015 (UTC)

Missing Convention[edit]

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

URL: in 2012

Anime Fusion Bloomington, Minnesota Held in October Started in 2012

Lawbunnie007 (talk) 21:00, 16 November 2015 (UTC)

I have copied your comment to a more relevant page. You can see it at Talk:List of anime conventions#Missing Convention. Whatamidoing (WMF) (talk) 18:34, 17 November 2015 (UTC)

Editing a section with wikitext editor then switching to VE deletes rest of article[edit]

Another big problem related to editing a section first in wikitext.

  1. Edit a section of an article with wikitext. Say with a link like
  2. switch to VE
  3. make an edit and save

This removes all other sections of the article. See for example section edit to Machadodorp the edit was intended just to link a particular author but instead deleted the rest of the article leaving just the section edited.--Salix alba (talk): 06:37, 19 November 2015 (UTC)

See this recently archived thread: Wikipedia:VisualEditor/Feedback/Archive 2015 3#deleting all but the current section. Status is "patch-for-review" as of 22 November. -- John Broughton (♫♫) 21:32, 19 November 2015 (UTC)

Edit then edit again[edit]

I was doing quite a time consuming edit on National Cycle Route 2. I started in wikitext. Switched to VE. As it was a long edit I saved halfway through. I then started editing again in VE and the popup box asking if I wanted to keep the changes appeared? --Salix alba (talk): 10:21, 21 November 2015 (UTC)

Thanks, that seems to be a new one. Whatamidoing (WMF) (talk) 19:44, 23 November 2015 (UTC)

Pasting wikipedia links with % encoded characters[edit]

VE does quite a good job in allowing me to paste in a wikipedia URL like and producing an internal link Southampton. It fails if I try something like which has a escaped ' (%27), just inserting an unlinked URL.--Salix alba (talk): 10:30, 21 November 2015 (UTC)

@John Broughton:, would you look at the steps in that bug report, and decide whether that's something we should mention in the user guide? When it works, it's pretty awesome. Whatamidoing (WMF) (talk) 20:23, 23 November 2015 (UTC)

cs1|2 |publisher= parameter and google+ links[edit]

Please participate in the discussion at Help talk:Citation Style 1#Publisher

Trappist the monk (talk) 15:42, 25 November 2015 (UTC)

The problem isn't a procedural one, or one involving a manual of style issue, it's a bug, and it appears to be highly probable that it is being caused by VE. There are more than 2000 instances so far, so this isn't trivial. This page is the proper place to discuss whether VE is indeed causing this problem, and if so, what's an appropriate priority for fixing the problem. -- John Broughton (♫♫) 20:25, 25 November 2015 (UTC)
Example of edit, tagged "Visual edit", adding a |publisher= with a external link and adding an invalid |language=it-IT. Keith D (talk) 02:29, 26 November 2015 (UTC)
This is the information that Citoid was able to gather. It's not perfect however. I'm not sure if there is a concept of allowed types of paramater content in Zotero as strict as there is in Wikipedia. If there is not, perhaps Citoid can transform it when needed. You might wanna file a report in phabricator. —TheDJ (talkcontribs) 12:41, 26 November 2015 (UTC)

Nowiki problem[edit]

I'm guessing that this has been reported many times before, but just in case: this VE edit resulted in a number of unnecessary nowiki tags. (Perhaps ironically, I was using VE to edit a help page about using VE; the edit "broke" the page entirely.) -- John Broughton (♫♫) 20:45, 25 November 2015 (UTC)

Hmm, that's broken indeed. It actually already breaks before saving, the template dialog for that part is not right at all... Ticket filed. —TheDJ (talkcontribs) 12:58, 26 November 2015 (UTC)

Converting cites from multiple bare links to templates[edit]

I've used the cite conversion tool on an article where the same bare link cite was used more than once. Alas, it just converted that single instance, leaving the others as-is. When bare links are converted to cites, the VE should name the converted reference, check for the presence of any more instances of the same bare link in the article, and convert those to references to that named reference. -- The Anome (talk) 12:15, 26 November 2015 (UTC)

Autogeneration of reference names for converted cites[edit]

As a related issue to the above, the autoconversion tool should always generate <ref> names for each reference it converts. Ideally, that name could contain some semantically meaningful label made from an author's name or publication name, but even a label like "a26" would be better than nothing. (Of course, whatever name generation process is used, it should contain checks to ensure uniqueness within the article.) Even if this label is not used elsewhere at the time, having it in the article wikitext will make longer-term maintenance of the article easier, even if it's only for editors editing the wikitext directly. -- The Anome (talk) 12:22, 26 November 2015 (UTC)