Talk:VisualEditor/Archive 1

Keyboard behavior
Is there any document specifying how the keyboard should behave in the visual editor?

If i understand correctly, it doesn't use the regular editing controls that a user would expect in a textarea. The arrows may move the cursor correctly, but other keys may work unexpectedly or not work at all. For example, Ctrl-Home should jump to the beginning of the editing area, but if not configured properly, it may jump to the top of the page (this happened in Google Translator Toolkit last time i checked; the site doesn't seem to work now).

Some important keys that i can quickly recall: Home, End, Page up, Page down, Backspace, Delete, Ctrl-Home, Ctrl-End, Ctrl-→/←, Ctrl-Shift-→/←, Shift-→/←. There are certainly more. --Amir E. Aharoni 12:17, 11 October 2011 (UTC)
 * ... Oh, and also Ctrl-X and Ctrl-Z. Very important. --Amir E. Aharoni 13:43, 16 October 2011 (UTC)
 * Visual editor/Features. --Yair rand 00:55, 23 November 2011 (UTC)

Testers
Bensin (Lämna Skottland!) volunteers to beta test the visual editor once it's ready for testing. Sumanah 20:34, 27 October 2011 (UTC)

Luis Orlando volunteers to beta test the visual editor too. --Luis Orlando 14:08, 23 January 2012 (UTC)

Charles Dayton from Wikipedia.org volunteers to beta test the visual editor. CharlesDayton (talk) 17:37, 16 February 2012 (UTC)

Justin West volunteers to test in a limited production environment. Jwestyp (talk) 02:36, 6 June 2012 (UTC)

Nicholas Wilson volunteers to test in a production environment alongside an existing mediawiki deployment. Nick Wilson (talk) 20:25, 26 June 2012 (UTC)

Sal Quintanilla volunteer to test on our engineering intranet site. --Salquint (talk) 02:06, 23 September 2012 (UTC)

Important Details
Note that headings should have these little space characters. e.g. "== heading ==" instead of "==heading==". I propose there should be an intelligent algorithm which type of style is mainly used in one article and then go on with using this style.

It also has problems with preformatted text. Just try to make a new paragraph in a preformatted text!

I think it's still too dificult to set interwiki links with this new editor. You also may make sure that this visual editor has a lot of key bindings.--217.251.244.219 19:55, 17 December 2011 (UTC)
 * And another problem: If you have an empty heading or anything else empty on top of the page it should be converted into a plain paragraph if you use the "delete" button of your keyboard. Using the mouse to change the type is too difficult. --217.251.244.219 19:58, 17 December 2011 (UTC)

Heading problem
I want to point out, that the selection of the Heading is a real PROBLEM. We don't want presentational Layout but structured Layout. How do you make sure that people take the right Heading? With the current version of the editor which is deployed everywhere this is no problem, because people are forced to use the right heading. But how do you make sure that people don't use the Heading1 because they think that something is important but in reallity it should be heading3 ... i hope you understand what i mean.
 * How do you mean this is enforced in the current editor? From what I can tell this problem applies to that editor as well. Perhaps the distinction is that the structure is more apparent when viewing the wiki syntax in that case. --John Ericson 14:13, 18 December 2011 (UTC)
 * Yes, that is what i mean (the structure is more apparent when viewing the wiki syntax). This "forces" (at least me) to use a clean sturcture. Maybe you should show a hint "H1 ..." next to each Heading on the editing page (during editing). I think this would have the same effect.--92.203.104.91 08:23, 30 December 2011 (UTC)


 * "H1" is meaningless in a visual editor. You have to show the heading size to be clear on what it is. Badon 02:53, 9 January 2012 (UTC)
 * Now that I think about it, people don't understand "heading" either. To the average reader, they are "table of contents sections". Badon 02:56, 9 January 2012 (UTC)

Can this handle templates and tables?
Pretty much every Wikipedia article eventually runs into one of the two things that break pretty much all wiki visual editors -- tables and templates. Can this visual editor handle them? How are they implemented? How do you switch between entering template parameters and seeing the template? Is it laborious to figure out how to turn the visual editor off if that's what necessary to edit a template? For instance, a new editor wants to add some new information to the Barack Obama article on the English Wikipedia. How do they use a cite template without the ability to get into template editing? If they want to fix something or move something, will most of the page as it now stands essentially be locked to them, since they'd be unable to edit or manipulate the hundreds of current cite templates on the page? (Granted, the page is semi-protected, so it's going to be locked to them anyway, but after they're autoconfirmed will it still remain locked to them?) Then there are all the pages where tables are used to present well ordered information like: Or to put information on a webpage but (so as to not overwhelm the rest of a potentially small page) to make it "hidden" by default, which is usually done to include "here's lists of other related stuff" on the bottom of "linked" webpages, such as pages for bits of a series: Or to sort information (especially useful on particularly large tables -- click the up/down arrows to sort by that column) for instance if you want to see sports figures ranked by goals, or by some other metric, and they're initially ranked by name or team or some other standard than by how you'd like the list to be presented: Either a template or a table are seen on every English Wikipedia article that isn't a stub or something like that (all 3+ million of those article pages) and even on most stubs, since pages have infobox templates, stub-marking templates, etc. If this visual editor cannot handle either templates or tables, it's going to be fairly useless for anything except the lightest of editing. If it can handle those, then this is the greatest thing since sliced bread. Banaticus 05:01, 10 January 2012 (UTC)


 * Tables are easy. If word processors can do it, then a "visual editor" can do it too. Templates are different - probably only the most commonly used ones would be easy to make available, like "citation needed". Beyond that, the domain is so unrestricted that it would probably have to be dealt with the hard way. But, if users want to do that sort of thing, they're probably beyond their need for a visual editor anyway. Badon 06:04, 10 January 2012 (UTC)


 * Parsoid currently round-trips tables, but only renders / expands templates. The editor currently supports neither. In Parsoid, we plan to support unexpanded template round-tripping at first (so the page will not be WYSIWYG wrt templates). Editing with expanded templates will then likely follow later. See Parsoid/HTML5 DOM with RDFa for some ideas on how this might look. -- Gabriel Wicke (GWicke) (talk) 12:08, 28 June 2012 (UTC)

Image Manipulation
A really useful feature would be integration with image uploads so that a user can click insert image, select the image locally or from the web and upload/insert it right from there, with no need to visit the upload page.

Parse error message replaces content ... and there's no way to revert!
I think a visual editor is sorely needed as a core Mediawiki feature and the current beta has a nice look.

Unfortunately, I suspect the current software isn't very robust -- while making edits on the test page the content was replaced with a parser error message.
 * There's no revert function yet, unfortunately.Jasper Deng (talk) 01:39, 24 June 2012 (UTC)


 * Do you have a pointer to the revision where this occured? -- Gabriel Wicke (GWicke) (talk) 10:13, 28 June 2012 (UTC)
 * Never mind- found it. -- Gabriel Wicke (GWicke) (talk) 10:28, 28 June 2012 (UTC)
 * Will be fixed with the next deploy. -- Gabriel Wicke (GWicke) (talk) 12:02, 28 June 2012 (UTC)

Is there an Updated Project Timeline?
All of the dates I see for when the VisualEditor will be available reflect a June (in the past) date. Would it be possible to project the estimated first release so that we have a date to plan against? Thanks, and excellent work!!!

FAQ: why it is difficult?
Hello folks,

In the context of editor decline and so on, the VisualEditor project and the promises of a bright future that come with it, are often mentionned when talking to the press and like :-)

Though, I noticed we regularly have the comment (especially in tech-centered press) “but what hasn’t it done before”, “why does it take so much time”, “there are already so many WYSIWYG-like editors out there” etc. etc, and we are a bit at loss to give a really good answer to that (rest assured that we know you people are not sitting on your hands :-)

Would you have some kind of quick explanation “Why is it hard?” that we could use, ie that would not go into too much technical details?

Thanks, Jean-Fred (talk) 13:52, 2 August 2012 (UTC)


 * Hi Jean-Fred, I get a lot of the same questions myself when I'm explaining this. What I tell people is that it's hard because:
 * 1) It's Open-Source (all the exampes they give of other ones are usually proprietary) so we have to "invent from scratch".
 * 2) It's not hard to create pages that are "born-WYSIWYG", but it is SUPER-hard to make it backwards-compatible so that existing articles (with all the templates, images, tables, references...) can be converted to WYSIWYG.
 * 2.1) Then, to make sure people can make diffs of articles, you need to be able to swap seamlessly back-and-forth between old and new styles without losing any data in-between. Best way of giving an example of why this is hard is to compare with any translation software going back-and-forth between two or three languages and watching the original sentence lose its meaning/nuance.
 * 3) Our WYSIWYG has to work in right-to-left and left-to-right as well as mathematical and many other obscure languages and font systems. So, while it might be easy to complete 90% of the use-cases for English/French, when you add in 280 languages plus all the different template/table requirements that *might* be used in articles, that last 10% breaks a lot of code.


 * Hope this helps, Wittylama (talk) 06:25, 24 September 2012 (UTC)
 * Yes, this helps. But one point. It would be less difficult if we would start with an simple editor that can use references but ignores tables. As You wrote: For 90 % of our writers and potentially writers this would be a milestone. It would be no problem then to add the other abilities one or two years later. --79.226.60.194 16:12, 28 December 2012 (UTC)
 * The blog entry you can point people to: https://blog.wikimedia.org/2012/12/07/inventing-as-we-go-building-a-visual-editor-for-mediawiki/ Sharihareswara (WMF) (talk) 22:34, 28 December 2012 (UTC)

VisualEditor without 'References' is useless
Our main problem is that new editors' changes are often rejeceted because of missing sources for their improvements. If references aren't made top priority in this project the VisualEditor will be no improvement for our main goal, to get more and more female long time editors.--79.226.60.194 16:06, 28 December 2012 (UTC)

How to use it?
What's the easiest way to use VisualEditor? Especially if I am not a registered Wikipedia user? Please post a link if possible.

I found this testing page but it won't work for me on InternetExplorer 8, which i must use currently.

I'm really looking forward to this, it will be a great improvement for the project. I am a frequent Internet user but not a registered Wikipedia member. Sometimes I feel I could contribute soemthing, but the wikiediting doesn't encourage me to do it. Awesome idea, keep on!


 * Hello! Thank you for your kind words; we certainly hope that VisualEditor will make editing Wikipedia (and our other wikis) easier and more encouraging.
 * That page is indeed the easiest way to quickly test out VisualEditor on MediaWiki. However, as you have noticed, it does not work in Internet Explorer 8 - we have managed to support Internet Explorer 9 and above, but unfortunately it looks like supporting MSIE 8 would take so much effort that we would not deliver any functionality at all. Sorry about that.
 * Jdforrester (WMF) (talk) 16:52, 28 February 2013 (UTC)

Deletes spaces before nowiki
Title says it all Stefahn (talk) 18:55, 2 May 2013 (UTC)

bug
Hello,

I don't know where the bugs must be reported, but see.

I use Chrome Version 27.0.1453.110 m on Windows XP. I added internal links and removed some categories.

Regards

--Hercule (talk) 11:34, 14 June 2013 (UTC)
 * Thanks; this is a known bug, and is most definitely at our end and not down to your hardware or software :/. I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too). Okeyes (WMF) (talk) 14:31, 14 June 2013 (UTC)

VisualEditor:Test broken
VisualEditor:Test seems to be broken. Trying to edit it with VE's edit buttons (both fullpage, and section-edit), makes the animated-blue-loading-bar (name?) appear, but nothing further happens (For at least 4 mins).

Nobody has edited the page since June 13, so I assume this is a persistent problem that everyone is encountering. User:Jdforrester (WMF) ping.

(Note: I was wanting to test editing some templates with the newest VE, as suggested elsewhere, but no templates are in that page. Some should be added to its default 'restore' state, once it's working again. Ideally something as complex as en.wiki's en:Template:Cite book) Hope that helps. Quiddity (talk) 01:51, 17 June 2013 (UTC)


 * @Quiddity: Fixed; User:Ypnypn added an errant  block without any references to display, which crashes VE - see 49668.
 * For pages that test templates, see VisualEditor:Template_test; there's a level of cramming too much functionality into one test page. :-) Jdforrester (WMF) (talk) 02:40, 17 June 2013 (UTC)


 * Thanks Jdforrester. I've added that to the paragraph at en:Wikipedia:VisualEditor, which suggests trying out template editing here. Quiddity (talk) 05:12, 17 June 2013 (UTC)


 * @Quiddity: Ah, thank you. :-) The bug is now fixed and we'll deploy it later this week. Sorry again. Jdforrester (WMF) (talk) 14:58, 17 June 2013 (UTC)

Multiple copies of this VisualEditor article series
Do we really need to fork this series of articles, with one at VisualEditor and a copy at Wikipedia: Wikipedia:VisualEditor -- and for all I know, other copies elsewhere? Wikipedia: Wikipedia:content forking ? --DavidCary (talk) 17:43, 3 July 2013 (UTC)


 * The master documentation is here on mediawiki.org; it's available in multiple languages and linked to from the interface. If wikis don't have local pages, this documentation is the reference. There are also copies on some other wikis in order to avoid the Not my wiki effect. guillom 18:05, 3 July 2013 (UTC)
 * One of the more consistent problems we've had with the VE rollout so far is not reaching enough editors with information on the new extension. Redundancy is desirable if it helps get the news out, imo. PEarley (WMF) (talk) 22:31, 3 July 2013 (UTC)

What happens in 3 days ?
In en:Wikipedia:VisualEditor, it says that in the week of 8 July, there is the "Launch to all logged-in and anonymous users as the default editor" on enwiki. And that one week later, the same "on other first-stage projects" ("TBD – definitely dewiki, frwiki, itwiki. Probably also arwiki, nlwiki, hewiki, hiwiki, jawiki, kowiki, ruwiki, plwiki, eswiki and svwiki").

All members of the VE team seem to simply ignore all the posts in enwiki where users ask to make a break for fixing bugs, rethinking some of the graphical interfaces so they can be really used for editing WP (templates, references, images, conflicts, section editing, ...), including a few suggestions to have a really useful editor.

So, I'm asking. What's the plan ? Is it still the schedule displayed in en:Wikipedia:VisualEditor ? --NicoV (Talk on frwiki) 12:20, 5 July 2013 (UTC)
 * The plan has been pushed back one week, per James' post here: . Far from ignoring those posts, the Liaison team definitely took them in, and lobbied hard for this delay. I've amended the schedules here to the updated version. PEarley (WMF) (talk) 16:30, 7 July 2013 (UTC)
 * Hi, thanks for the reply. When I said "VE team", I didn't target the Liaison team (you're doing a difficult job) but rather the management of the VE project which seems not to take the opinion of many experienced users into account. I do think that most of the team is doing a good job, but this one week delay seems like a bandage to an open fracture. For me, VE at this time is far from being ready for production, not only because of the bugs, but because the main features are simply not ready.
 * Apart from basic syntax (text, internal links, titles, ...), VE is just not mature : template editing isn't finished, image editing isn't finished, reference editing isn't finished, ... And postponing one week won't change much things about that. Currently, VE isn't promoting good practices for articles creation, rather promoting bad practices : for example, when you insert an image with VE, there's not even a suggestion that adding a caption should usually be done (it's an entirely separate action), and adding an alternative caption (which is very important for accessibility) is not even possible. And images are inserted with a size, which is against every Wikipedia manual of style... And every important features are in the same condition.
 * So, I just think this one week dealy is not even close to an answer to the current situation... I'm very disappointed because I hoped that VE could help new editors to contribute efficiently, but that's rather the opposite : things that were very easy with wikitext are still easy with VE (once the many bugs are fixed), but things that aren't so easy with wikitext are even harder with VE in its current status.
 * Some new editors say they like the new editor, but when you look at their contributions with VE, either they made none (!!!) or they only made really basic editing (text, internal links), and didn't even see the dirty diffs that VE made in some of their edits.
 * --NicoV (talk) 18:35, 7 July 2013 (UTC)
 * Nico, you've made some accurate criticisms of VE's present state here, but I'll ask you to look at it from a different perspective for a second. The functionality you'd (and I) like to see will come with time, but I'd like to point out, that to the new editor (I mean brand new, no experience) the old platform does not promote any practices - it simply provides an editable window of marked up text.  The good practices come with practice - viewing other articles, getting feedback from one's peers, and reading the policy pages.  I remember my first attempt to add a reference back in 2008 - the wikitext editor showed me how to add a bare url, and that was it.  Even that was a struggle. I didn't learn about cite templates until I saw others using them in DYK nominations (about 2 years after I started).  The actions we're seeing new editors use VE for are the same actions newbies make using markup - the simple ones.  VE should provide direction on how to do more advanced tasks well, and as it matures, it will.
 * On the image front, adding a "Do you want to add a caption?" dialog would be a good improvement, no?
 * I'd add that a week is very valuable in terms of shutting down the worst of the bugs - the developer team can get a lot done in that time period, especially if the flow of bug reports slows down. The maturing process of VE is, in my opinion, best done hand in hand with the editing community - every day since the rollout people have suggested how they'd like to see it function, and that is shaping its evolution. The alternative is that VE be developed in more of a black box, with selected testers.  But would this lead to the product we all want, which is something that simplifies the many, diverse tasks we do while editing?  I'm not confident.  At least with the current approach, editors are in either direct (through Bugzilla) or indirect (through us) contact with the developers as the product is being worked on. PEarley (WMF) (talk) 19:39, 7 July 2013 (UTC)
 * Thanks for the answer. Just a few comments.
 * It's not entirely true that the old platform does not promote any practices : the cite menu helps for adding references (according to comments, a lot better than what VE currently does), and you forget the value of simply copy/pasting existing syntax (to a limited extent since it depends on the quality of the existing wikitext) which is not possible with VE.
 * For the image, yes, adding the caption at the same time than the image name would be nice. It would even be nicer, if there was also the alternate caption.
 * As working with the full community compared to a group of beta-testers, I just want to remind that volunteers didn't have a chance to test VE with its major features (releasing template editing and reference editing was done almost at the same time as the roll-out to new users). I really think a more sensible option would have been to keep going with beta-testers to find the majority of bugs and get a good bunch of suggestions, then once VE would have reached some stability, releasing it to a wider audience. I'm pretty sure you would have get most of the comments you have now with only the beta testers, and the release to unexperienced users would have been easier. Submitting VE to the comments of the entire community is great, but it's too soon.
 * I also asked in the en feedback page if it was possible to have some features only available to volunteers. That would allow to release features not yet finished without having them used by editor that don't want to debug a software. --NicoV (talk) 20:44, 7 July 2013 (UTC)
 * Some good points, Nico. The ref toolbar functionality is something we're shooting for with VE. (Remember, it was once only a gadget, and was only made default in 2011) The value of copy/pasting templates and the like isn't lost on me, but, isn't that a workaround that we have developed as editors to avoid the difficulty of hand-coding complicated elements? It's not something that the old edit window helped you do, it's something the old edit window forced you to do because it gave you no help with infoboxes/navboxes/tables etc. at all.
 * Yes, it would have been desirable to have more of the bugs squashed before the en rollout. Some of those bugs may not have shown themselves with a small group of testers though, they only became apparent when the extension was exposed to a large amount of volume.  But, yes, it could have been done on a more extended schedule. I'm not the best person to ask about this - I'm inherently lazy and would support "Let's do it later" in almost any situation ;)  I've got to focus on making the rollout go more smoothly on our smaller wikis, still lots of work to do on that front.  As for your suggestion on en.feedback, I think it's going to be a very difficult sell to convince the developers to stop working on important bugs in order to code a new version of VE.  I do get where you're coming from - we won't retain new editors if they have a bad experience with a partially-functioning interface - but these added functionality issues are being dealt with as fast as possible.  And because of the rollout, they're being dealt with using the editors' input. PEarley (WMF) (talk) 00:01, 8 July 2013 (UTC)

We need a sandbox
As far as VE was deployed on all Wikipedias, but just in the main ns, there is no way to perform its tests in local environment. Would it be possible to create a page on local wps to test it, or how to do so?--Juandev (talk) 05:31, 7 July 2013 (UTC)
 * It is also enabled in User space. I've checked on German and Czech Wikipedia ;-) John Vandenberg (talk) 06:25, 7 July 2013 (UTC)

Real-time collaboration and chat
From the WMF annual plan:[//wikimediafoundation.org/w/index.php?title=File%3A2013-2014_WMF_Plan_As_Published.pdf&page=17] As Visual Editor becomes a robust, stable, and performing default editing environment, we will shift our attention to a new frontier: real-time collaboration and chat. Collaborative editing environments (Google Docs, Etherpad, etc.) have proven that this combination is very powerful.

In the Wikimedia context this will help address edit conflicts and inefficient collaboration on articles that receive attention from multiple users at the same time. It will also create wholly new opportunities for engagement and mentoring. Is there an esteem of the amount of articles suffering from said «attention from multiple users at the same time»? My guess would be that it's a tiny minority of articles, mainly those in the news, which are also arguably the least important; it's not clear to me how improving the experience on said articles would help the strategic goals. We also must be careful not to disrupt the WikiNow. --Nemo 22:22, 9 July 2013 (UTC)
 * The joy of multiple users editing a single document at the same time is like the joy of discovering the page you're reading is editable: it's a natural extension of wiki tech to use modern algorithms.   A number of mediawiki enthusiasts (including me) use etherpad or even Google Docs (gasp) when they need this experience... even though it involves sacrificing permalinks, recentchanges, interwiki links, image inclusion.  It's a powerful draw -- and will encourage new types of editing, more than supporting current practice.  Sj (talk) 15:05, 23 July 2013 (UTC)

Non-Wikipedia
When is the VisualEditor available for non-Wikipedia-projects like wikinews? -- 92.75.18.80 20:32, 14 July 2013 (UTC)


 * We plan to make VisualEditor available to the non-Wikipedia projects in the coming months. We need to investigate what extra requirements those projects have before just rolling it out - I'd be very happy to hear if you think there are any special considerations for e.g. Wikinews that VisualEditor does not currently meet, so that we can add them to the list to be worked on. Jdforrester (WMF) (talk) 22:20, 14 July 2013 (UTC)


 * I'm currently working at a big change for the German wikinews - for example a new main page or a general template for all articles (example): you can do easier more things automatically, and, with the TemplateData, it's easier for new users to edit Wikinews. And, Wiktionary can be like Wikidata, I think: it's multilingual, and any language has his own namespace, for example en:word, de:Wort and fr:mot. And normal parameters like declension or translations can be translated automatically in other languages, so only things like example sentence or description must be translated by humans - etymology can be written computer readable if you make many different templates for this. Basic data is after a few translating for all languages once always in any language version available. -- (probably another IP, but the same real person) 92.75.5.209 12:25, 15 July 2013 (UTC)

Inserting Tables
I'm finding it extremely difficult to add a simple to an article I am writing. Please guide me.. Gihaned (talk) 16:38, 17 July 2013 (UTC)
 * Gihaned, currently table editing isn't supported, but we hope to have it up and running soon. PEarley (WMF) (talk) 02:04, 18 July 2013 (UTC)

Noob question
Sorry to sound like a noob, but how to get started with this editor? do I have to download something to get started? Thanks. 46.185.181.194 16:34, 23 July 2013 (UTC)
 * Which wiki are you working on? The only wiki currently with VE enabled for IP users is English. By the end of August, all users (logged-in and IP) on all wikis will have it.  Another factor is your browser - VE currently only supports recent versions of the major browsers. PEarley (WMF) (talk) 16:54, 23 July 2013 (UTC)
 * OK Thank you, I am working on Wikipedia. 46.185.181.194 17:28, 23 July 2013 (UTC)

What is the best-practice for providing easy citations in third party websites
I'm writing this question in my capacity as employee of the National Library of Australia - responsible for social media. As you may know, the National Library and its "Trove" service include a WP citation code in the "cite this" drop down in all search results (along with permalink, and various standardised footnoting styles). See for example the 'cite' button here: http://trove.nla.gov.au/ndp/del/article/628050 This system has proved extremely useful for providing precise footnotes to WP articles and for raising awareness of the Trove historic Australian newspaper digitisation program. At the Library, we are currently in the midst of a very broad tech and database integration process - part of which is revisiting this citation system. I'm going to a meeting next week to discuss where the WP citation sits within this and I'd really appreciate some feedback as to how the Visual Editor may affect this system.

In short, what effect does the Visual Editor have on the provision of this kind of citation code? Is it even useful anymore to provide pre-filled wiki markup? Will there always be a free-text "paste from clipboard" option when creating new footnotes or is there a more efficient way for the Library to provide precise footnote information? Is there a way this system could be easily improved (noting that it is optimised for en.wp's referencing style). Wittylama (talk) 10:10, 7 August 2013 (UTC)
 * I should also note that when copy/pasting this citation code from the aforementioned link (or any other citation generated by that system) into the 'reference' dialogue box in the Visual Editor - it wraps the edit in nowiki tags - which are impossible to remove without going back and using 'edit source'. Wittylama (talk) 13:02, 7 August 2013 (UTC)
 * Wittylama, I will try to get an answer on this as soon as possible. However, much of the team is at Wikimania this week and next, so no promises. The VE reference editor is being re-designed - I will make sure that the issue of pre-formatted citation code is included in the discussion. Another solution is to work a fix into VE's copy-paste functions, perhaps. I'm no coder, but also very interested in citation templates. I'll keep you updated.  Excellent work getting your National Library thinking about wikipedia - ours here in Canada is being slowly gutted and can't seem to figure out what its mandate is. PEarley (WMF) (talk) 16:30, 9 August 2013 (UTC)

Is the timeline correct?
Hi there,

Is the timeline correct? Will Phase 2 still start on the 24 September? If not it will affect one of our projects.

Hoping for a swift answer and thank you for your hard work!

Best, John Andersson (WMSE) (talk) 14:51, 8 September 2013 (UTC)
 * Hello John! Yes, we are still planning a release to several wikis on September 24th. We are still under discussions with editors and the WMF developer team as to exactly which wikis will be on the list.  Which wikis are involved with your project? Best regards, PEarley (WMF) (talk) 02:28, 9 September 2013 (UTC)

Visual Editor on sister projects
I looked at the timeline, and it seems to only mentions Wikipedias. Is there a plan to make Visual Editor available on sister projects (specifically Wikisource)? Or is there a way to request it? Dovi (talk) 18:14, 21 September 2013 (UTC)


 * We are mostly looking to deploy to Wikipedias first before attempting the sister projects, as sister projects' needs are a superset of those of the Wikipedias'. We could theoretically bring forward some of the simpler sister projects to support, but it may not be obvious as to what makes a wiki hard. For example, Commons will be relatively simple, needing only gallery support before enabling makes sense, whereas Wikisource will be hugely complex to support (we are likely to have to re-write "ProofreadPage" from scratch, which is not easy). Of course, if anyone wants to help make VisualEditor a useful experience on their wiki, we'd be hugely grateful for any help! Jdforrester (WMF) (talk) 03:04, 22 September 2013 (UTC)

Hard coded/protected restrictions for Skins
I noticed a hard-coded restriction for custom skins: /** List of skins VisualEditor integration supports */ protected static $supportedSkins = array( 'vector', 'apex', 'monobook' ); There are a lot of compatible, modified skins existent. Is it possible to leave this gate open for customized skins? A less restrictive solution could be to make $supportedSkins globally available, or declare it as global conf.-var. ($wgVeSupportedSkins).

--Steviex2 (talk) 21:47, 7 October 2013 (UTC)


 * Yeah, this is mostly an artefact of when we were originally developing VisualEditor, WMF had 9 'supported' (read: not supported) skins. We now have 4 skins, 2 of which are supported and 2 of which are the responsibility of their maintainers. VE's initialisation and integration layer makes a lot of assumptions about the skin, which aren't going to necessarily be true. The plan is to have sub-classes for each skin (so if you want VE to work in your skin, you just have to sub-class an integration), but pending that refactor we can certainly move it into a config variable (I think $wgVisualEditorSupportedSkins would be best); will get this done. Jdforrester (WMF) (talk) 22:41, 7 October 2013 (UTC)


 * ✅ This is now patched to create  in latest master: . Jdforrester (WMF) (talk) 00:28, 8 October 2013 (UTC)


 * ✅ Thank you man --Steviex2 (talk) 01:22, 8 October 2013 (UTC)