Talk:VisualEditor/Archive 1

Visual Editor in the User Namespace

I've enabled the visual editor in my preferences and the text states that visual editor will be enabled in the "Main" and "User" namespaces only. However when I go to my user namespace page (by clicking on my username) and the page I am directed to says "User Page" in the tab at the top the visual editor or "Edit" tab is not available to me. Only "Edit Source" is available. Do I need to do something more to turn on Visual editor in the User namespace? It currently works in the main namespace as it should.

Which project are you working on? Whatamidoing (WMF) (talk) 20:05, 11 March 2014 (UTC)

Have the same problem any solution about this? Steve

Steve, which wiki are you talking about? Thanks. --Elitre (WMF) (talk) 12:57, 3 March 2015 (UTC)

It seems like you're talking about your own installation of VE. In this case, the fastest way to get live help is via IRC; head to #mediawiki-visualeditor ^connect. Best, --Elitre (WMF) (talk) 12:59, 3 March 2015 (UTC)

Oh Im sorry wasn't sure how this works, yes I did go to IRC but noone responded and I can't find a way to resolve my problem ^^

The VE team is mostly based in San Francisco, so I suggest you try again after 5pm UTC. :) --Elitre (WMF) (talk) 14:37, 3 March 2015 (UTC)

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#Mouse and keyboard interaction. --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:

People	Dates
Person X	July 4th
Yoda	3,653 BBY

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:

Click [show] to reveal the table
People	Dates
Person X	July 4th
Yoda	3,653 BBY

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:

People	Dates
Person X	July 4th
Yoda	3,653 BBY

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.

Possible

This is fully possible. I made a prototype of a WYSIWYG wiki editor (not for Mediawiki) where you could paste images from your clipboard. I hooked the paste event in Javascript, uploaded the base64 encoded stream to the server via AJAX, which stored the image.

The problem I quickly ran into is having a lot of unreferenced images. When you explicitly upload a file, users instinctively know that it's a file on the server. When you can insert/paste an image directly into the article, instinctively users believe that if they delete a reference to an image in an article then that image is deleted from the serve.

So, in my Wiki prototype, I implemented reference counting of media. Now, people can make mistakes and want to revert an edit where they removed the image - so you could schedule garbage collection perhaps once a day (and only clean up files that were last referenced the day before) to give a 24 hour grace period. --198.160.96.7 15:30, 8 April 2014 (UTC)

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!

— Preceding unsigned comment added by 141.58.138.64 (talk • contribs) 11:17, 28 February 2013

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 [1].

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 <references /> block without any references to display, which crashes VE - see bugzilla: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#Current limitations, 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 mediawikiwiki: 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: [2]. 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[3]) 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:[4]

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)

Any idea when tables will be ready? --Orange-quarter (talk) 01:31, 27 March 2014 (UTC)

Tables keep getting pushed back. The design work has taken a long time, and it's been a less urgent priority compared to things like supporting non-Latin languages and Wikipedia-specific needs, like inline citations. The current best guess is that a basic table editor might be available in 3–6 months. (Insert standard disclaimers here.  ;-) Whatamidoing (WMF) (talk) 15:41, 27 March 2014 (UTC)

OK, thanks. That's a good guide - disclaimers aside! Appreciate the quick reply. :) --Orange-quarter (talk) 08:28, 28 March 2014 (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)

There is a workaround in the VE. Click the mouse into the spot you want your templated citation. Open the references dialog. From there, open the transclusion dialog. Hover over the "+" symbol (lower right) until a pair of []s appear. Click the [] and then type/paste your template-form citation. Click Apply. Kerry Raymond (talk) 07:06, 9 October 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)

@Steviex2: 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)

@Steviex2:  Done This is now patched to create $wgVisualEditorSupportedSkins in latest master: Gerrit change 88253. Jdforrester (WMF) (talk) 00:28, 8 October 2013 (UTC)

@Jdforrester (WMF):  Done Thank you man --Steviex2 (talk) 01:22, 8 October 2013 (UTC)

Feature Richness same as Wikia

Will the community/WMF-version of Visual Editor have the same feature richness as currently Wikia's version?

--Steviex2 (talk) 07:08, 8 October 2013 (UTC)

@Steviex2: Eventually, yes, VisualEditor will be feature equivalent (or more) than Wikia's current rich editor, which they are soon to replace with VisualEditor (which is why Wikia have worked with us on creating VisualEditor). Specifics as to what they're planning when and how are probably best aimed at them, but if you have any questions about general VisualEditor "richness" that you think is missing I'd be happy to answer. :-) Jdforrester (WMF) (talk) 18:35, 16 October 2013 (UTC)

@Jdforrester: Thank you... well when I log in to Wikia, Visual Editor is already activated. I see feature sections of VE like "Add features and media" which consists sub-features like galleries, video management/embedding, tables, sliders and so on. I can't find such features in my checked out WMF-git-branch of VE. In my opinion it would be nice to have this features for the MediaWiki development community too.

By the way...will VE have a decent plugin structure/API? So community developer can use it to bring VE forward- or implement features currently only exclusive available for Wikia users?

On that note, any thoughts on what video extension VE development is leaning towards for embedding video(dare I say YouTube)? We're building a mediawiki site and want to be forward-compatible! Wikia uses the video extension but there's also the embedvideo extension that seems popular. MarkJurgens

Email notifications

What about email notifications and hooking? Hot to catch onArticleSaveComplete hook from another extension, e.g.

— Preceding unsigned comment added by 213.232.243.233 (talk • contribs) 14:28, 9 October 2013‎ (UTC)

I'm not sure what you want. Do you want an e-mail message every time someone edits an article? Whatamidoing (WMF) (talk) 18:10, 16 October 2013 (UTC)

Also, I'm not entirely sure what this has to do with VisualEditor - possibly better asked on Talk:Echo (Notifications)? Jdforrester (WMF) (talk) 18:37, 16 October 2013 (UTC)

Private wiki support

I see that "VisualEditor now supports editing of private wikis, by forwarding the Cookie: HTTP header to Parsoid" but reading that and the bug report doesn't really clarify how to do enable that. Am I setting some variable like $wgEnableCookieForwarding to 1 on LocalSettings.php? In VisualEditor.php? We use a totally private wiki so this is a much awaited fix if it can be implemented --Silversonic (talk) 15:55, 16 November 2013 (UTC)

Yes, you need to set $wgVisualEditorParsoidForwardCookies to true; beyond that, it should "just work™" with master of VE and Parsoid. Jdforrester (WMF) (talk) 18:47, 18 November 2013 (UTC)

Thanks for responding. I set that global variable to true in LocalSettings.php per your suggestion, but when I enable editing on the wiki, it hangs indefinitely and I don't see anything logging from server.js (like it did before with access denied, so I guess that's progress). I'll look at it again later and see if I can find any logs or whatnot. Thanks again --Silversonic (talk) 21:35, 18 November 2013 (UTC)

@Silversonic: Is there anything logged on the JS console? Indefinite hanging definitely shouldn't happen! Jdforrester (WMF) (talk) 02:53, 19 November 2013 (UTC)

@Jdforrester (WMF): ok so I was just impatient when I tested it the last time, trying again I waited on the console when I run node server.js, it says

starting parsing of localhost:Main_Page

completed parsing of localhost:Main_Page in 100501 ms (take note of the timestamp)

And on the page I see "Error loading data from server: timeout. Would you like to retry?". So at least it looks like it's forwarding the cookies correctly. --Silversonic (talk) 20:51, 19 November 2013 (UTC)

It might also be worth mentioning that this site runs over https rather than http. I can get all the pages with a curl http://localhost/page.php, however, so I'm not sure how much of an issue that really is. --Silversonic (talk) 21:24, 19 November 2013 (UTC)

Perhaps also worth noting is that we use strict LDAP authentication for auth. Does Parsoid need a local user or does the cookie forwarding handle that bit? Sorry for the troubleshooting spam I'm throwing darts at a wall at this point.--Silversonic (talk) 22:30, 19 November 2013 (UTC)

Huzzah it's fixed!

Per the code comments in VisualEditor.php: I needed to enable $wgSessionsInObjectCache by putting $wgSessionsInObjectCache = true; in LocalSettings.php. Putting my solution here in case someone else runs into the same issue. --Devin Roark (silversonic) 15:37, 29 November 2013 (UTC)

Unpredictable enabling

Hi. I'm at a WMIT workshop we're giving to a group of librarians and it seems we are unable to predict whether the visual editor will show up for the participants or not: the computers had Internet Explorer and of course it didn't work (cf. [5]); we had the technicians install Firefox (10.0.10 ESR, I found out) but still on the main PC we don't see it on w:it:Meccanica quantistica which we had chosen as example on purpose because it has visual editor when seen on Firefox 25 (Linux)... I saw the target compatibility matrix, but it doesn't help. --Nemo 09:33, 29 November 2013 (UTC)

Hi Nemo,

I'm sorry you're having problems with this. User:Elitre (WMF) is the best person to help with the Italian Wikipedia, so you might want to contact her directly at it.wp. In the meantime, she'll probably want to know what version of Windows you're running, and VisualEditor appears at any page (try a couple at it:Special:Random). Whatamidoing (WMF) (talk) 20:42, 30 November 2013 (UTC)

She has answered me but this is not a question about it.wiki. I have no idea what version of Windows they're using, only that it was one of those which came after XP. Moreover, I'd like to be pointed to a page or tool or whatever to find out whether VE will work or not on a specific platform, so that I can determine it myself or send the instructions to the technicians who need to set up the machines. Thanks, Nemo 22:09, 30 November 2013 (UTC)

James has now clarifed perfectly.[6] Thank you all. --Nemo 18:53, 4 December 2013 (UTC)

Translation tool

Hi all.

There is effort in place to build a translation tool, which may or may not be a useful idea to integrate into visualeditor — https://tools.wmflabs.org/wmtran/ — with a specific bit that it would need to talk to two wikis at once.

In addition to existing functionality I linked, it might also need to load content from a target wiki so the user saves an unfinished translation and can continue at any time by loading two pages in the tool.

--Gryllida 07:44, 8 December 2013 (UTC)

This is now available as an «Idea» in the IdeaLab here. --Gryllida 13:35, 28 December 2013 (UTC)

Phase 5 question

In the phase 5 the developers included Mongolian script, I only need to confirm that Mongolian script is vertically written kind of script and it will be great you include it correctly into VisualEditor. I included some samples here:

1. [Sample-1]
2. [Sample-2]
3. [Sample-3]

Thank you. Orgio89 (talk) 02:01, 25 January 2014 (UTC)

Thank you for this message. It may take some time to get Mongolian working.

Patrick is probably the best contact person for you right now. Whatamidoing (WMF) (talk) 23:54, 30 January 2014 (UTC)

I've asked Orgio89 for more information on mn.wiki, but if they would like to reply here, that's fine too. PEarley (WMF) (talk) 01:09, 8 February 2014 (UTC)

Line break

How do you insert a <br> in VE? 137.147.205.98 07:48, 7 March 2014 (UTC)

Why would you want to do that? Whatamidoing (WMF) (talk) 20:07, 11 March 2014 (UTC)

To break a line of text which isn't a separate paragraph... 137.147.58.23 07:44, 12 March 2014 (UTC)

⇧ Shift+↵ Enter. Jdforrester (WMF) (talk) 21:00, 12 March 2014 (UTC)

Doesn't seem to work, and isn't in the list of shortcuts. 124.180.52.183 06:32, 13 March 2014 (UTC)

In what context? And thousands of OS-provided keyboard shortcuts aren't in the "list of shortcuts", like ⇧ Shift+a = A. :-) Jdforrester (WMF) (talk) 16:17, 13 March 2014 (UTC)

⇧ Shift+↵ Enter is not an OS-provided shortcut for inserting a carriage return (which <br> is the HTML equivalent of), because it already has a key specifically for that, ↵ Enter. However in VE, it creates an entirely separate paragraph (which is fine, since that's usually what you'd want to do in an article). If ⇧ Shift+↵ Enter changes it back to the normal ↵ Enter action (which it doesn't), that would be a VE specific shortcut. 124.180.11.58 01:56, 14 March 2014 (UTC)

It's browser-standard, you're right, not OS-provided. The world of HTML editors has quite a few standards, and this is one of them. Jdforrester (WMF) (talk) 17:28, 14 March 2014 (UTC)

Under what circumstances would you want to break a line of text, without creating a separate paragraph? It would be helpful if you would give me an actual example of real text that you'd want to put a line break in the middle of.

James, the result of ⇧ Shift+↵ Enter is different in wikitext. Line break keeps the indentation, but not when you use the key press. Whatamidoing (WMF) (talk) 16:52, 14 March 2014 (UTC)

Primary this is useful to write multiple paragraphs in a single list item. (In other words, rarely.) Jdforrester (WMF) (talk) 17:28, 14 March 2014 (UTC)

Main uses are for small bits of text, like in infoboxes and tables. There are also the occasional issue where you don't want mediawiki to space the text out with <p>, so you need to use <br>. It's not something that is that common, but if you don't want people to have the annoyance of switching back to source editing (and if it's frequent enough, just staying there), you need to have a way to do these sorts of things. 60.230.124.181 00:25, 15 March 2014 (UTC)

TBC=??

Please an explanation in the article text.

• TBA = to be announced
• TBC = to be confirmed
• TBD = to be determined

They all approximately mean "nobody knows". Whatamidoing (WMF) (talk) 20:04, 11 March 2014 (UTC)

first line comes out extra words when typing chinese

mediawiki 1.23wmf18 , 20140318 git clone VE, 20140318 installed parsoid

when i use Chinese input tools, typing somewhere in the page "zhongguo" which will input"中国" in the page when i press "space" ，but the first line shows out "guo \n" frequently. so wired!

VE seems not compatible with chinese input method, i have found something like this in the early version

Chinese language variants aren't working yet. There's a developer working on it. It's very complicated, so it's likely to be a few months. Whatamidoing (WMF) (talk) 15:37, 27 March 2014 (UTC)

Support for VisualEditor on enterprise version of redhat?

Hi We're using mediawiki on an enterprise version of RedHat, and am told by our IT guys that we can't add on Visual Editor as an extension as it's not yet supported on that. Is this true? Are there other options? We're superkeen to move to Visual Editor, so if you could let us know if and when this might be possible (ie if and when we will be able to incorporate it on an enterprise version of RedHat), that would be brilliant. And if this is a while away (more than 6 mnths) if you have other suggestions as alternatives?

Cheers

--Orange-quarter (talk) 01:23, 27 March 2014 (UTC)

Hi

Still hoping for a response to this - we have tried to add Visual Editor and all looks good up to a point, then we get a parsing error. Please advise. --137.166.216.29 05:01, 22 May 2014 (UTC)

@Orange-quarter: Hmm. There's nothing in VisualEditor that should restrict your choice of OS, except if the OS can't run a Web server or node or something like that. Do they have any specific concerns? It seems hugely odd that it would be caused by your OS distribution. Jdforrester (WMF) (talk) 16:37, 22 May 2014 (UTC)

Cannot find locally uploaded files

The insert media still cannot find locally uploaded files. But when I change the $wgUseInstantCommons to true I can find the images on the commons. I really don't know what to do. — Preceding unsigned comment added by Frappeisthebest (talk • contribs) 05:56, 9 May 2014‎

User:Frappeisthebest, is this still a problem for you? Whatamidoing (WMF) (talk) 22:38, 2 September 2014 (UTC)

User:Frappeisthebest Whatamidoing (WMF) It's been five months since this thread was active, and I'm still encountering this problem as well. It works if you put the full file extension in there. Also see Thread:Extension talk:VisualEditor/Is picture search in VE wikicommons only?/reply (15) HiDenise (talk) 09:17, 1 February 2015 (UTC)

In my case the autocomplete matches whole words only (MediaWiki 1.24.2 Visual Editor 0.1.0). Since all files require an extension, that means that if the file has spaces autocomplete will work for the all but the last word. For example the file "Foo Bar.png" would match with the searches "Foo" and "Bar.png" while the file "FooBar.png" would only match with "FooBar.png". Igorrafaeldesousa (talk) 16:18, 13 May 2015 (UTC)

Changing link title

I just tried to change some link titles on mediawiki.org and tried to use the Visual Editor.

Basically, I wanted to change something like this...

<ref>http://example.org/</ref>

...to this...

<ref>[http://example.org/ Example.Org]</ref>

I clicked on the link in the VisualEditor and tried to change the link title and it seemed to get rid of the link formatting while I was editing. I ended up switching over to source editing to finish the edit. —Tom Morris (talk) 14:43, 8 August 2014 (UTC)

The process I use is this: Open the page, select the ref, open the ref. Select and cut the URL. Type the link label that you want ("official website" or "Example.org" or whatever), then open the link tool (control-k or command-k) and paste the URL into the box.

Ideally, it'll be mostly automated when Citoid is further along. Whatamidoing (WMF) (talk) 22:40, 2 September 2014 (UTC)

Mediawiki Default Editor

Is VisualEditor going to become the default editor of mediawiki installs in version 1.24, or will it always require Parsoid and the VisualEditor extensions?

Thanks, Mike

— Preceding unsigned comment added by Ausback (talk • contribs) 15:14, 28 August 2014‎ (UTC)

@Ausback: There are two separate questions here:

1. Is VisualEditor going to become the default editor of mediawiki (tarball) installs in version 1.24

   No. It's probably going to be premature to do this with 1.24, but eventually yes, this will happen (and the extension will be bundled).

2. Will VisualEditor always require Parsoid and the VisualEditor extension?

   Not entirely. Eventually, we will switch MediaWiki's back-end over to use HTML natively, which means new installs won't need Parsoid. However, even when this is done, the integration of VisualEditor into MediaWiki is very unlikely to be merged into MediaWiki core, and instead it will probably remain an extension for good. Just because it's an extension, however, doesn't mean we can't bundle it for all tarball users so it's available "out of the box", though.

Hope this helps! Jdforrester (WMF) (talk) 16:32, 28 August 2014 (UTC)

Draft things

I like the 'Insert comment' feature. In draft mode, I'd like to have an option to view the comments visible on a margin.

I might suggest that it's possible to start 'tracking changes' so that a second article contributor can review them -- accept or reject. That's insanely useful when people are working on a draft. --Gryllida 01:24, 30 August 2014 (UTC)

To clarify: both of the 2 people do not have reviewer right. They're collaborating as peers. This is not like FlaggedRevs, which accepts an entire article and has one of the contributors stand out as a reviewer.

Something like <del> and <ins> tags, but with an attribute which stores an author of the changes. This gets piped over to visualeditor and any contributor who clicks 'edit' can accept or reject any of these changes.

Perhaps all of this only in Draft: namespace (such as one at English Wikipedia) or in a special "Draft mode" (although how the non-draft mode would display them is unclear in such case). --Gryllida 01:40, 30 August 2014 (UTC)

I wonder whether User:Quiddity (WMF) could update us on the inline diff project. It's possible that something like that couple be adapted to this idea. Whatamidoing (WMF) (talk) 22:42, 2 September 2014 (UTC)

That project, Requests for comment/Inline diffs, is currently waiting on me having time to find&capture screenshots, and to follow-up on the questions I asked on the talkpage. It's literally just a different way of formatting a standard diff though, so I'm not sure how it's relevant here?

I think Gryllida is proposing something akin to Googledocs' new "suggested edits" mode, where we're not editing live, but instead every edit creates a "suggestion" in the margin, that can be [accepted/rejected/discussed]. I like that idea, but I'm not sure how feasible it is at the moment, nor how we'd add the feature without further overwhelming the articles with more links... Hmm. Maybe the section [Edit] dropdown menu as previously proposed in Winter (v5 and older), could have a "suggestion" option...? Not sure. Quiddity (WMF) (talk) 20:28, 3 September 2014 (UTC)

@Gryllida, Whatamidoing (WMF), and Quiddity (WMF):

Broadly, no – this isn't something we're particularly focussed on. Potentially we could replace FlaggedRevisions with a system like this, but I think the effort would be huge compared to the value we would extract, and it's hard to see how it would work for wikitext users. Not supporting wikitext users is not an option.

(I love how everyone compares to Google Doc's "suggested edits" feature rather than Microsoft Word's "tracked changes" mode.)

Jdforrester (WMF) (talk) 21:11, 3 September 2014 (UTC)

Is VisualEditor broken in eswiki?

Hi

Visual editor does not work anymore for me on eswiki while using firefox (31.0, 32.0). It works on Chrome. I can use Visual Editor with Firefox in other wikis other than eswiki. I have disabled all my gadgets, monobook.css, reset all my user preferences and no way! I have even installed Firefox from scratch in a different computer. Do you experience the same problem? Barcex (talk) 19:43, 4 September 2014 (UTC)

Works for me on es-wiki. Firefox 32.0 here. Do you even see the "Editar" tab or how it doesn't work? --Stryn (talk) 20:24, 4 September 2014 (UTC)

@Barcex and Stryn: Yeah, this works for me in Chrome 37, Firefox 32, Safari 7.0.6 and Opera 12.16. Can you give a link to a page where it doesn't work? Jdforrester (WMF) (talk) 21:11, 4 September 2014 (UTC)

Barcex, is this a recent problem? Whatamidoing (WMF) (talk) 21:09, 4 September 2014 (UTC)

So it is probably related to my account. In my contributions you can see that I was making edits with Visual Editor until Aug 23 (es:Especial:Contribuciones/Barcex) I noticed this behaviour a few days ago. When I press the Edit button it grayes out the screen and the upper right progress bar starts rolling... it keeps moving forever. See this screenshot [7] Barcex (talk) 21:33, 4 September 2014 (UTC)

I just fixed it. I deleted all the .js and .css from my User:Barcex namespace and now it works. I had not changed anything there but it seems that some of that code was creating the problem. Thank you for your support. Barcex (talk) 01:47, 5 September 2014 (UTC)

If you ever figure out what was causing the problem, then please share the news. I had a gadget enabled in my en.wp account that was causing intermittent problems–one time it would open, and the next time it wouldn't. It was driving me nuts. Whatamidoing (WMF) (talk) 16:31, 5 September 2014 (UTC)

VisualEditor on talk pages

Hi

On the visual editor portal it says Visual Editor is not enabled for talk pages, is this something that will change in future (I can't find more information about this). Is it something that could be enabled now on a stand alone distribution of mediawiki? Thanks and keep up the good work on this wonderful project Mrjohncummings (talk) 04:36, 9 September 2014 (UTC)

@Mrjohncummings: From a technical level, it's easy to enable VE on talk namespaces (you just change $wgVisualEditorNamespaces). However, VisualEditor has been intentionally designed around content rather than talk thread editing, so some features your users would need (add a new section to postfix; sign with ~~~~s; etc.) are missing, and core editing features have been tweaked to be great for content editing, not for talk threads (e.g. return after someone else's li inserts a sibling li, not an indented ol/li, because you're extending a list not replying to a question; return mid-way through a new list item inserts a new sibling li, not a paragraph break, because you're writing a list not a lengthy response; support for dls and dts/dds is missing or janky depending on what you're trying to do, because they're very rare in content, though most talk pages are entirely populated with these; etc.). Jdforrester (WMF) (talk) 20:31, 9 September 2014 (UTC)

@Jdforrester (WMF): thanks James, are there plans in the future to have a visual editor for talk pages or are there other plans for them? Thanks again --Mrjohncummings (talk) 04:41, 10 September 2014 (UTC)

@Mrjohncummings: The plan is that Flow will give people the ability to take part discussions via either VE or wikitext; we're not planning to do work in VE itself for the current model of talk pages, no. Jdforrester (WMF) (talk) 17:46, 10 September 2014 (UTC)

@Jdforrester (WMF): Thanks very much for the explanation :)

English Wiktionary request

Pursuant to some discussion of the topic, English Wiktionary is interested in activating VisualEditor as a limited opt-in only feature, but (due to our heavy reliance on templates and other features that are easily broken by less experienced editors) would like to put some additional controls over who is enabled to use it. Is it possible to enable VisualEditor as an option only for administrators, or only for editors whitelisted to use it (in the way that we whitelist editors to use the Auto-Wiki Browser)? Cheers! BD2412 (talk) 15:56, 19 September 2014 (UTC)

@BD2412: I'm afraid it's not possible to restrict Beta Features to only a limited group of users (like only sysops), no. Theoretically someone could build that, but it sounds like a lot of work to enforce a social norm. Couldn't you just block people that abuse the software, like normal? Jdforrester (WMF) (talk) 18:50, 19 September 2014 (UTC)

That is unfortunate. We are not seeking to enforce social norms, but to ensure that tools with a broad capacity for generating errors are limited to those who will have the experience to avoid those errors. BD2412 (talk) 01:46, 20 September 2014 (UTC)

@BD2412: There's very little "broad capacity" in VisualEditor for such issues if it's opt-in… Jdforrester (WMF) (talk) 20:38, 20 September 2014 (UTC)

@BD2412: , what's the status of TemplateData at the English Wiktionary? The more templates that have TemplateData defined, the fewer problems you're likely to end up with. Whatamidoing (WMF) (talk) 21:52, 9 October 2014 (UTC)

I don't think TemplateData has ever been discussed at Wiktionary. However, we do have substantial concerns with editors not using templates at all where templates have been designed to contain the information in our entries. BD2412 (talk) 04:24, 16 October 2014 (UTC)

User:BD2412, I really think you want to spend a while dealing with TemplateData before trying VisualEditor. It's not unusual to see two dozen different templates on a page there. Do you have (or can you get) a list of the most commonly used templates? It looks like just two templates have TemplateData now, and Kephir might be a good person to talk to. (The other was added by someone copying and pasting a template doc page from en.wp.) Whatamidoing (WMF) (talk) 20:16, 22 October 2014 (UTC)

Add characters to Special Characters

I searched for a while but could not find something: Is thera a way to change or add characters in the Special Characters window? For example there are latin accents but in greek wikipedia, greek polytonic accents would be more useful. Are they configured in some MediaWiki message or hardcoded? --Geraki (talk) 13:37, 8 November 2014 (UTC)

Hi Geraki,

The right answer might be that they're "hardcoded in a MediaWiki message". The instructions for changing them locally are at VisualEditor/Special characters. It is a site-wide change that affects everyone. The special characters palette needs to be re-designed to accommodate a much larger set of characters (without filling the entire screen). If you have ideas about how you would like it to work, then please let me know. Whatamidoing (WMF) (talk) 20:15, 10 November 2014 (UTC)

Can't have specials characters

Hello, I've a small problem, I haven't the Special characters button on my installation of the visual editor. Is there an option or a parameter to activate? --TheoHenri (talk) 23:04, 15 February 2015 (UTC)

TheoHenri, please see VisualEditor/Special characters for some instructions. Whatamidoing (WMF) (talk) 02:11, 16 March 2015 (UTC)

Success Criteria

This was posted on the executive Director's Talk page:

We are beginning with the collaborative buildout and deployment of VisualEditor. We are moving community engagement processes and product decisions into earlier stages of development, and making them iterative. In a perfect world this process would start prior to feature development, but in this case VisualEditor is already in-flight, so your participation now is critical. With your participation, we can work together to ensure this new process works.

In this new process, we commit to:

1. Collectively identify success criteria for each target audience, from new editors (simple feature set) to expert editors (complex feature set).

2. Ensure success criteria represents the quantified and qualified goals. The feature will only be shipped when the success criteria is met.

3. Enable the feature for only portions of specific audiences that would best benefit

I would like to take you up on that commitment. In addition to any other criteria, Visual Editor should not be considered for OPT-OUT deployment unless it fulfills it's project rationale:

Rationale: The decline in new contributor growth is the single most serious challenge facing the Wikimedia movement. Removing avoidable technical impediments associated with Wikimedia's editing interface is a necessary pre-condition for increasing the number of Wikimedia contributors.

When you're ready, initiate an appropriate size test group taken from new account creations. A group of controls with Visual Editor left default-off, and equal size group with Visual Editor set to on. My suggested metric for comparing the two groups would be the number of not-reverted article space edits. Note: Some participants may switch their Visual Editor setting on or off during the research period. My suggestion is to simply ignore what group the individuals started in, and total their edit counts based on their active setting. People who switch Visual Editor on would have their edits totaled with the Visual-Editor-On group, and those who switch Visual Editor off would have their edit count totaled with the Visual-Editor-Off groups. One month would be a very bare minimum for preliminary data, but it really should be longer to pick up a true trend-over-time.

• If the Visual-Editor-On metrics show a significant greater total contributions than the Visual-Editor-Off metrics, this would be a strong success criteria for Visual Editor OPT-OUT, assuming other success criteria had been met.
• If the Visual-Editor-On metrics show a significant lower total contributions than the Visual-Editor-On metrics, then clearly setting Visual Editor to OPT-OUT would be detrimental. Harming our overall mission would obviously be a critical block.
• If there is no statistically significant difference, there should be a fresh WMF&Community discussion what cost-benefit factors exists for or against deploying Visual Editor as a new default editor. Alsee (talk) 10:35, 1 March 2015 (UTC)

Hi Alsee,

I know that there's some interest in running an A/B test, but I can't promise anything. As for your suggested criteria, reversion levels are probably a valid metric.

The total number of edits isn't reliable: what if it takes three tries to get the formatting right in wikitext, but only one in VisualEditor—or the other way around? That doesn't mean that the editor contributed more actual content, just that they found one environment easier. In fact, you'd be penalizing the environment that helped the editor get it right on the first try. There is also a lot of variation in this already. For example, men (on average) need more individual edits than women to add the same amount of content.

I think that it might be useful to compare any number of things, ranging from the likelihood of saving the first edit, the number of editing sessions (do I come back tomorrow?), and the likelihood of adding a source. What else do you think would be interesting? Whatamidoing (WMF) (talk) 02:18, 16 March 2015 (UTC)

I was trying to capture the net contributions to article space. Hopefully the difference will be big enough (in either direction), that things are clear without sweating the nuances. I considered edit-bytes, but that has potentially messier issues than edit count. Number who remain active over time is a strong metric, and number of days that they edit (that avoids the few-big-edits vs many-small-edits issue). And of course it's important to break-out the data for those who switch their Opt-In/Opt-Out status in each direction.

I specifically exclude non-article-space edits because we don't know the significance of them without looking at the content of those edits. Some kinds of non-article edits could indicate positive learning and productive work, or they could indicate someone is having problems. Very significantly, non-editors using talk pages just to argue for their ideological-causes is a very disruptive negative. I'm not thrilled with likelihood-of-saving-first-edit metric. If for some reason that metric went the opposite direction of long-term-contributions, we absolutely want go with long term contributions. The number of sources added is intriguing, but that's the sort of thing that can change a lot with experience. On one hand it would be fine if Visual Editor meant newbies started out with more text-only edits and stayed around to become high value experienced editors, on the other hand it would be bad if Visual Editor meant newbies tossed in a source or two and never came back. I'd rather stick with editor-retention-over-time and general article-space activity. Alsee (talk) 21:16, 18 March 2015 (UTC)

Ah, I didn't mean that editors saved an edit the first time they opened VisualEditor. I meant the likelihood of the editors ever saving any edit at all. Most people who create accounts never save an edit.

I think that focusing on article-space is good. It might be reasonable to include userspace, because some people use that for drafts. I agree with you about ignoring or discounting talk page contributions. It's important to communicate, but raw numbers of edits are even less useful there.

I think we're going to win a test along these lines, maybe even soon. Of course, anything could change without warning (the Analytics department is really overloaded), but, as of today, it's looking like you and I will get something similar to what we want. Whatamidoing (WMF) (talk) 00:10, 20 March 2015 (UTC)

Hi @Whatamidoing (WMF): , that's great. Will you update this page if that happens? Sj (talk) 19:33, 13 April 2015 (UTC)

I just heard that this is almost certainly happening, maybe even at the end of the month. If I can get the date and some details nailed down, or a link to Meta (where most research projects are posted) then I'll post it. Whatamidoing (WMF) (talk) 20:03, 13 April 2015 (UTC)

Hi Sj, a draft has been posted at m:Research:VisualEditor's_effect_on_newly_registered_editors/May_2015_study. I'm happy to say that Halfak's running the study, which means that we can expect timely reports from a rigorous study. I'll make sure that he sees Alsee's comments here, but anyone who wants to reach him should probably post at the study's talk page on Meta. Whatamidoing (WMF) (talk) 19:38, 16 April 2015 (UTC)

Hi Alsee! It turns out that we agree 100% on everything except the duration of the experiment. I did a power analysis and it looks like we can get more observations than we need in a week long study. I'd like to make sure that we always do studies like this in multiples of 7 days because there's an important period around a week (weekend editors are different than weekday editors), so the minimum study length that I'll agree to is 7 days. From there on, it's just a question of # of observations. Beyond what you suggested we measure (which is actually one of the key measures of newcomer performance that I like to use -- see m:R:Productive new editor and m:R:Productive edit), I'd like to also measure the burden of newcomers on experienced editors. So I'll be looking at the raw number of edits that need to be reverted and the proportion of newcomers who need to be blocked/banned. Sound reasonable? --Halfak (WMF) (talk) 22:48, 17 April 2015 (UTC)

Hi Halfak (WMF). I'm super-glad to see this study is being done. You mentioned "burden of newcomers on experienced editors".... I was thinking something similar, "how much trouble are new editors having"... essentially the same thing. I dropped the idea because I couldn't think of a good way to capture that, but it's great if you have some way to look at it.

As for "m:R:Productive new editor" and your suggestion that 1 week might be enough, I'm concerned that we might be looking at different things. It's crazy-hard to try to capture the "value" of edits in any automated way, aside from the bit about discounting reverted edits. As discussed above, things like edit counts or edit-bytes could be misleading here. I saw a figure somewhere that if we threw away the first 5 edits by every account, we would only lose a single-digit percent of Wikipedia. Furthermore the value of someone's edits is strongly tied to experience. There is little value in someone who makes one (or a couple) of edits and never comes back. I was trying to look at something more like "editor retention". Ongoing editing means accumulating contributions regardless of measurement challenges, as well as increasing editing-value with increasing experience. Forget the first week... how many days do people keep showing up to edit during the following weeks? That captures long term value, and it gives time for the effect of problems or help-requests to start showing up. Alsee (talk) 23:53, 19 April 2015 (UTC)

Oops I forgot to ask, will you track and break-out the data for those participants who actively reverse their VisualEditor setting? Alsee (talk) 00:03, 20 April 2015 (UTC)

Hey Alsee, it seems to me that retention is addressed, here. Best, --Elitre (WMF) (talk) 15:33, 20 April 2015 (UTC)

Thanx Elitre (WMF)! Great link. For the VisualEditor data collection, will T1 be set to zero? It looks like a non-zero T1 would seriously distort the results if, for some reason, the Visual group are more or less likely to register on one day but actually start editing during their next session. The page says the "WMF Standard" is T2=T3=One_Month, is that going to apply here? Also I was thinking we might be able to capture more significant information if we look at number-of-days-active during the T3 period. Can something like that be included in the results?

I'm still looking for confirmation that participants changing their VisualEditor setting will be tracked and broken out separately? That would result four data groups, based on initial_setting & current_setting. It would badly junk the results if users who chose to work in one mode get incorrectly compiled into the opposite edit mode. Alsee (talk) 21:32, 20 April 2015 (UTC)

Hey Halfak (WMF), can you shed some light on Alsee's doubts? Thank you! --Elitre (WMF) (talk) 13:10, 21 April 2015 (UTC)

Actually, it won't junk the results at all. The question being asked is more like "what happens if you offer this?" (something that depends entirely on the researcher) rather than "what happens if he uses what you offered?" (something that depends importantly upon the characteristics of the user). Also, while it's probably easy enough to check the two groups to see whether anyone opted in or out, the experience at other wikis suggests that this effect will be very small (probably not statistically significant) and much less important than new editors choosing which editor to use each time they edit. Whatamidoing (WMF) (talk) 18:36, 21 April 2015 (UTC)

┌─────────────────────────────────┘

I think that Whatamidoing (WMF) puts it well. It would actually cause problems to look at these groups separately since there's likely a confounding reason why some newcomers chose not to use VE and that would affect our outcome measures. In order to have validity in the experiment, I must compare the two groups whether they use VE or not. So, rather than comparing VE and Wikitext, we're comparing a world in which VE is enabled with a world in which it is not enabled. I think this is actually a better thing to know. However, we still will be able to observe the opt-in/out rates and learn from that. That's something I plan to look at.

Regarding the observation period, I don't see a good reason to look at mid- to long-term survival of new editors in the experiment. If VisualEditor affects this, the effects will likely be very small and very noisy since so many other factors play a part in a new editor's decision to keep editing (e.g. social interactions with other editors). But, it turns out that we can get a good sense for mid- to long-term retention by observing measures of short-term retention. For example having a second edit session or editing for longer than 60 minutes is a strong predictor of long-term retention (see my work here: m:Research:Newcomer survival models).

If you'd still like to look at long-term retention effects out of curiosity, I'm with you and I'd be interested in running that analysis in couple of months. Generally, I'd also like to invite you to observe my work log entries (see the widget in the upper right of the project talk page). If you'd like to ask questions, or request analyses as I go, I'll do my best to accommodate -- time permitting. :) --Halfak (WMF) (talk) 02:26, 22 April 2015 (UTC)

I shouldn't have said "junk". I was imagining things in terms of a "default editing mode" which is indeed rather different. Still, if significant numbers of people in the control group are actively switching to edit in Visual Editor that seems like valuable information. If significant numbers of people in the test group are actively getting rid of Visual Editor that seems like valuable information. The percentages will probably be very low, but I assume the cost of checking those figures is minimal. Alsee (talk) 02:56, 22 April 2015 (UTC)

BTW, here is a link to the updated timeline. --Elitre (WMF) (talk) 16:03, 19 May 2015 (UTC)

Pending change

On 8 April 2015, the necessary file name (for Special Characters) will change to MediaWiki:Visualeditor-quick-access-characters.json, and will only need to include items that you want quick access to. Whatamidoing (WMF) (talk) 16:20, 1 April 2015 (UTC)

Here's a quick link to VisualEditor/Special characters. --Elitre (WMF) (talk) 13:12, 21 April 2015 (UTC)

Number of unique users

Tracked in Phabricator
Task T94637

phab: T94637 has a list of how many unique, registered users saved an edit in VisualEditor at least once during the previous 30 days, at each project. NB that you can't just sum the numbers, because any person who saves an edit in VisualEditor at two different projects will be counted for each project (i.e., one person who edits at the English Wikipedia and at mediawiki.org is one person, but that person gets counted as one user in the en.wp count and again as a separate user in the mw.org count). Whatamidoing (WMF) (talk) 00:15, 21 May 2015 (UTC)

Unable to Create Table

Hi,

I'm new to both MediaWiki and VisualEditor. I've installed the stable version of MediaWiki, version 1.24 with Bitnami stack. Right after that, installed Parsoid server and VisualEditor extension. Both are working fine but I noticed there is not table creation/editing and are not exactly the same as per the VisualEditor in the MediaWiki's sandbox page. Weird enough, both are showing version 0.1.0 in the SpecialPage:Version. Can I know how to enable the the table feature? Was it because I'm using an older/stable MediaWiki? Thank you.

Http://imgur.com/pOjss8t

Hi User:170.38.99.34,

Yes, I believe that you're right. The table feature is fairly new, and the older versions of MW don't support it. I'm not a technical person, so take this with a grain of salt, but I hear that the recent versions of MW are pretty reliable, so you might consider upgrading to at least 1.25 (MediaWiki 1.26/wmf9 is the current version), even though it isn't labeled as a long-term support version. Whatamidoing (WMF) (talk) 19:51, 5 June 2015 (UTC)

Exception in load-callback in module ext.visualEditor.targetLoader:

When I click "Edit" the progress bar get stuck and the browser log shows the following errors:

Exception in load-callback in module ext.visualEditor.targetLoader:

Error: Unknown dependency: oojs-ui.styles.icons-editing-advanced Error: Unknown dependency: oojs-ui.styles.icons-editing-advanced {stack: (...), message: "Unknown dependency: oojs-ui.styles.icons-editing-advanced"}

I am running a public MediaWiki 1.25.1 and have the following LocalSetttings.php configuration:

require_once "$IP/extensions/VisualEditor/VisualEditor.php";<br />

$wgDefaultUserOptions['visualeditor-enable'] = 1;

$wgVisualEditorParsoidURL = 'http://[MY_IP]:8000';

$wgDefaultUserOptions['visualeditor-enable'] = 1;

My Parsoid server is running fine, and I see the calls to Parsoid and there are no errors. I am running everything on Oracle Linux.

Hi William.macdonald1,

Thanks for your interest. I'll see if I can find someone to help you. Whatamidoing (WMF) (talk) 19:53, 5 June 2015 (UTC)

This seems to be a common error, I've seen quite a few people with it. It seems to be mis-matching versions of MediaWiki and the VisualEditor extension. Please make sure that you definitely have the REL1_25 version of VisualEditor from Special:ExtensionDistributor/VisualEditor. Please could you tell me how you got the version of VE that does this? Also you don't need that wgDefaultUserOptions entry twice. --Krenair (WMF) (talk) 20:03, 5 June 2015 (UTC)

Thanks Krenair (WMF)! I downloaded Visual Editor to my local machine, then extracted it, and copied it to the remote wiki server, and it works now. Before, I downloaded the extension directly onto the Oracle Linux wiki server using the link https://extdist.wmflabs.org/dist/extensions/VisualEditor-REL1_25-c1ed854.tar.gz provided on that download page, and extracted it. I'm not sure why there would be a difference.

change margin and padding

hello im currently working on implementing this editor to our company´s wiki. everything worked out fine but I have one last question about customizing the editor. is there an easy option to change the padding and margin of the elements/button in the editor globally ? imo they are too big an occupy to much space on the wiki, also they cramp up the dialog in the edit image window. i hope you can help me, thank you.

VisualEditor

VisualEditor is not available on my mediawiki 1.25 page.

wiki.westeros.pl