This is an archive of past discussions on Wikipedia:VisualEditor. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current main page.
When placing the cursor at the beginning of a subtitle (I mean the things like "Enter bug" above) and pressing the enter key, not only will a blank line appear (as should), but the cursor jumps one position to the right as well. This causes that subtitle to be fragmentated when entering a few times. Also deleting a blank line that's above such a subtitle will convert that subtitle to normal text.
I noticed this in my sandbox on the Dutch Wikipedia. I use Windows 7 and the latest version of chrome (no extensions). Amphicoelias (talk) 20:00, 6 June 2013 (UTC)
If it ain't broke....
Reading the description of this feature was enough for me. It sounds like a complete mess. I don't even want to try it. Why was it even developed? Is somebody bored?WQUlrich (talk) 21:31, 8 June 2013 (UTC)
Wikimarkup code is a barrier to attracting new editors. They will be more familiar with a word processing style interface. It is a good idea, in principle, and hopefully most of these bugs will be gone when it goes live. Lesion (talk) 00:43, 9 June 2013 (UTC)
Why was it even developed? Because we have been asking the devs for this kind of major upgrade for literally years now. WhatamIdoing (talk) 01:08, 9 June 2013 (UTC)
Well I have checked the box to enable the new editor in my preferences, saved them, but everything seems to be just the same as it always has. Is it actually enabled for all logged in users or only some? Doing this edit in the old editor. What am I supposed to see when I enavble visual editor? (by the way, using Opera 12.14, has it been checked with Opera?). Dsergeant (talk) 07:21, 9 June 2013 (UTC)
From the FAQ: "Wikipedia editors have asked for this type of improvement since at least 2004. Previous discussions include 1, 2, 3, 4, 5, 6 and more." If you'd happened to keep up with the project space all these years, then you'd already know this, but since you work on articles rather than hanging out at the discussion pages, it's not really surprising that you hadn't noticed the steady stream of requests. WhatamIdoing (talk) 17:48, 9 June 2013 (UTC)
Well, yes, it is broke, or is rapidly becoming so. As software and operating systems outside Wikipedia advance there is a growing disconnect between the way eveyone else works and Wikimedia. At the same time our templates system (which was never intended to be a vehicle for coding) has become ever more complex and sophisticated. In my view it is now impossible for a passing newbie to have a hope of understanding at a glance the code jargon that now confronts one in the average article edit window. A WYSIWYG editor is an obvious improvement that should be welcomed by all. Of course it is a mess right now, this is only alpha development release, but I welcome the opportunity to be able to comment on it before it all gets set in stone.
Thanks.... looking at that list of limitations it looks as it is years away from prime time release. Won't waste time on it, I can handle the existing editor like I have been doing for years. Dsergeant (talk) 05:58, 10 June 2013 (UTC)
Another small thing I noticed is that you can't select somewhere in the text of the summary text you enter with the mouse cursor. You can use arrows to add something into what you have already entered, but it just seems odd that the mouse doesn't work too. Lesion (talk) 00:43, 9 June 2013 (UTC)
In the pop-up that appears when editing a link, it doesn't make sense that the "close" button to dismiss the pop-up is at the top left and labelled with the "<" symbol.
First, it's difficult to discover, as there are no visual cues as to what effect it will have (once the tooltip appears it's already too late - someone looking how to close the dialog will not think of this button as the "save" action).
Second, it's unclear whether the changes to the panel will be saved or not when pressing the button. I *think* the only way to actually save the edit is by pressing Enter and the "<" button will destroy my edit (which is utterly dangerous), but I'm not even sure about that.
Third, it doesn't make sense that you need to click twice on a link to edit it. We're already in edit mode, there's no need to show the "link" icon as an intermediate step. When I click on a link in edit mode, I want to edit the link.
The standard way to dismiss a dialog is with the "x" symbol at the top right. The standard way to accept a change is with a "Save" button at the bottom. Heck, this very "submit feedback" form where I'm typing this gets it right. Please fix this very basic interaction element and don't reinvent the wheel. Diego (talk) 07:37, 9 June 2013 (UTC)
I added Bugzilla:49147 a few days ago, so it is being looked at.
I suggested a number of tooltips for those icons, but I'll link to this thread, from there, so that we can discuss it further here.
I tried it on my sandbox and found it difficult to do the one thing that should be easiest: clicking on the editing tools. There was a template at the top of the editing area while I was working, and every time I moved my mouse up to the toolbar, I ended up with a grayed-out box saying "Sorry, this element can't be edited using VisualEditor" covering up all the editing tools. I had to constantly circle around the perimiter of the page with my mouse to avoid this. The grayed-out box is fine, but it needs to stay underneath the toolbar rather than automatically becoming the top layer when it appears. Feel free to edit my sandbox if you want to see what I'm talking about. –Thatotherperson (talk/contribs) 07:59, 9 June 2013 (UTC)
Save changes popup should be opaque. I mistakenly clicked on a para while saving and a greenish box overlaps the popup. RedtigerxyzTalk14:24, 9 June 2013 (UTC)
Confirmed, but I think this is only a problem for items that the editor is currently not see setup for (ie. references and templates), not for plain paragraphs. See a screenshot of my mousing-over an ambox, just before clicking the "Review and save" button.
This shouldn't be a problem once in-article templates can be edited, though it might need to be considered for particular non-content templates like amboxes? –Quiddity (talk) 19:46, 9 June 2013 (UTC)
Non breaking spaces are not allowed: putting would result in and hence we cannot put non breakingspaces :( This is a problem for articles that should follow WP:units (such as 15 km)
The green striped shade that is displayed over unvisualeditable parts when hovered over them will remain there if you are placing mouse pointer over the toolbox (and other non-article part like the diffs) directly.
It looks like none of the insert-symbols stuff has been done yet. I would prefer to add nonbreaking spaces directly from the keyboard (option-spacebar), but I just checked, and that doesn't work in either editor. WhatamIdoing (talk) 20:11, 9 June 2013 (UTC)
Missing capabilities
Right away I miss the formerly available search and replace capabilities that have been so useful in the past. :)John Cline (talk) 20:29, 9 June 2013 (UTC)
Switch between stand and VisualEditor
make it so you can switch back and forth between standerd editor and VisualEditor... ♠|RP|♠ 16:29, 24 May 2013 (UTC) — Preceding unsigned comment added by Rlp17 (talk • contribs)
Support: probably necessary if you are going to want a lot of people to try it. The fear will be that you will need to abandon your work on an edit that hasn't worked; to be able to fix it manually later would mitigate those fears. Edgepedia (talk) 06:20, 25 May 2013 (UTC)
In this edit, VisEd added a space and removed some three-quotes from line 133—totally not what I was doing up in line 4. Is this some sort of forced markup fixing? It seems that the bolding in Miniapolis' sig remained the same (i.e. VisEd only removed redundant formatting). Thanks, Ignatzmice•talk04:36, 30 May 2013 (UTC)
This was supposed to be just a couple of very simple changes to the words and character formatting in a single sentence. First it was incredibly slow, and then it claimed that it timed out without doing anything, and then I found the 850Kb mess. WhatamIdoing (talk) 02:15, 7 June 2013 (UTC)
I can add a bare external link to an "External links" section - e.g.http://wikipedia.org - but I can't see a way to add a label - e.g.[http://wikipedia.org Wikipedia]. Is this deliberate? It's annoying for any serious work - David Gerard (talk) 10:17, 7 June 2013 (UTC)
Confirmed. Typing/pasting the URL first, then adding the label, is very complicated/problematic.
Note: The other way around works well: Type or Paste the label text; Highlight that text; click the "link" button; paste URL. –Quiddity (talk) 17:00, 7 June 2013 (UTC)
I agree, I did not understand how to do this until reading your comment. Perhaps we can do it like this?
Click on hyperlink,
Have the hyperlink popup bring up two text spaces, one for a link and one for text
If user had text selected when they hit the hyperlink button then the space for text on the popup will already be filled with the selected text.
If you didn't have any text selected when you hit the hyperlink button then the space will be blank, and if no text is added then a bare url will be given.
I made a similar suggestion on the IRC; the developers' report is that that is too heavyweight for what is supposed to be lightweight aspect of the interface, because the anchor can be more than just text. --Atethnekos (Discussion, Contributions) 00:57, 8 June 2013 (UTC)
Yep; the problem is that the anchor can be a table, or part of a table, or a template, or a section, or.... it gets problematic very quickly, I'm afraid :/. Okeyes (WMF) (talk) 10:01, 13 June 2013 (UTC)
Review and save
Too many clicks to save. The review step is unnecessary and cumbersome. Dump the comment dialog in favor of a dropdown/typeaway in the control bar. Lfstevens (talk) 19:39, 7 June 2013 (UTC)
I have found the review step to be incredibly important for identifying ways that this alpha version screws things up unexpectedly, so I can not save these mistakes. WhatamIdoing (talk) 00:53, 9 June 2013 (UTC)
Same. I don't understand what the point of then showing the source is - or is that just the Alpha. I have faith the developers will get it right, at least for new users. Jamesx12345 (talk) 21:08, 13 June 2013 (UTC)
So far, I've found no defects as long as you stick to pure text. More importantly, I already review my changes before saving. How about this: when you click save, switch to the old preview page. That way I can clean up broken stuff and use my old tricks for handling summaries, etc. Lfstevens (talk) 22:29, 13 June 2013 (UTC)
Backspace to blank line on number list adding blank lines
Type "a". Press number list button. [ENTER]. Type "a". [ENTER] Type "a". [ENTER]. [Cursor up]. [backspace]. "a" in "2." numbered line is removed but two blank lines appear under "2." and before "3." Firefox 21.0/Windows 7.--Atethnekos (Discussion, Contributions) 21:21, 7 June 2013 (UTC)
For me, using Chrome, VE is slow and not that useful (sorry). OK, so anytime I want to edit something inside a transcluded template, image, table, columns, etc, I need to ignore VE and go to the source. The VE toolbar seems lacks most of the options that could be enabled via preferences in the old editing window. If you are scrolled half way through a template, and you move the cursor to the toolbar via the area of the template, the toolbar is grayed out along with the template. To use the toolbar, you have to move the cursor to it avoiding the area of the template. Is this just chrome? What browser would be best to use so the loading time is minimal and it runs smoothly?
I support the idea that users, especially new users, should not have to learn basic wikimarkup code, but I foresee a frustrating time ahead for me getting used to this thing. Lesion (talk) 11:36, 8 June 2013 (UTC)
@Lesion: Dunno about the slowness, but I believe all the "can't edit x, y, and z" aren't Chrome-specific. VE just isn't that developed yet, I believe. But I'm not anyone official. Ignatzmice•talk11:59, 8 June 2013 (UTC)
reading some of the comments above about slowness, it might be more related to your location apparently. Hope this will not feature when it goes live. Lesion (talk) 00:43, 9 June 2013 (UTC)
@User:Lesion; the bugs you're reporting aren't Chrome-specific, we're still working on templates, images et al. The slowness is also something I hope will be solved for :). Okeyes (WMF) (talk) 10:06, 13 June 2013 (UTC)
First comments from Spinningspark
I have only just this minute turned VisEd on, but here are my first impressions. The basics are very good; selection, bold, italic etc are all intuitive and do what I expect.
Small text
There does not seem to be any way to generate small text. I was expecting Ctrl-S to do something - either small text or strikethrough.
Links
The suggested links are too small to read
Too many clicks
It takes too many clicks to get in and out of editing mode. The confirmation stage is going to be useful at first, but once experienced editors are used to the tool and are confident what the editor is going to do the extra click is just going to be annoying. In fact, I can foresee that I would want to stay permanently in edit mode on many sessions and not have to click "edit page" at all as I go from page to page. This would be the case for instance, when working through my watchlist or dealing with a disruptive editor. SpinningSpark21:35, 8 June 2013 (UTC)
Agree. Before there was one click to enter the editing window and one click to save, unless you clicked preview first or had enabled auto preview via preferences. For me VE is slow, and these extra steps just make things worse imo. Lesion (talk) 00:43, 9 June 2013 (UTC)
What's this "extra click" you're talking about? I click [Edit] (and wait for it to load), and I'm in the editor, without any second click. (I have to click where I want to start typing, but that's true in the old edit window, too.) WhatamIdoing (talk) 01:11, 9 June 2013 (UTC)
I think in time this'll prove less useful, but it does have two advantages (one ephemeral, one permanent). The ephemeral advantage; we're currently in an alpha. It's buggy, it's slow, and it's going to cause weird stuff to happen; being able to identify that before you break an article and someone snarks is A Good Thing, I think. The permanent advantage - this will persist for newbies. At the moment people do what they think is right and, if it isn't, invariably get told off for 'breaking' an article. Having a stay on that is nice. I appreciate it's non-ideal for experienced users, and will become less of a big deal when the software is more stable; we can look at what to do with it then, I think :). Okeyes (WMF) (talk) 10:13, 13 June 2013 (UTC)
my guess is that adding citations is a function that doesn't exist yet in the visual editor? if it *is* possible, then my feedback is that I could see how to do that. MicheleJackson (talk) 20:27, 9 June 2013 (UTC)
It's supposed to be fixed in a future release. Categories, images, and citations seem to be the top priorities at the moment (for the VE half; I believe that improved speed is the goal for the Parsoid engine half). The devs have promised that it will not be made the default (for beta testing, with a goal of July 1st) unless and until it's possible to add citations. WhatamIdoing (talk) 21:23, 10 June 2013 (UTC)
@User:Dodger67; it is high priority; highest priority is getting the software to work consistently for the things it officially can do :). I'll be perfectly blunt; I can't see any widespread beta or other release happening unless references work at least theoretically. Okeyes (WMF) (talk) 10:17, 13 June 2013 (UTC)
Not being able to edit template parameters such as those used in infoboxes and reference citations is a real pain; being able to edit those kind of elements is essential. The same is true for image captions. WaggersTALK09:32, 10 June 2013 (UTC)
@User:Waggers; this is a known and something that is being actively worked on. A very early form of the template inspector is live at the moment on MediaWiki.org, if you want to test it :). Okeyes (WMF) (talk) 10:18, 13 June 2013 (UTC)
I don't use VisualEditor myself; but I have noticed a problem with edits made by somebody else. Specifically, this edit which added a <gallery> immediately before the existing <Gallery>, and which also added a </gallery> at the very end of the article. The first error was spotted by that user and fixed, but I fixed the second. --Redrose64 (talk) 11:01, 10 June 2013 (UTC)
It seems like it could be good for some edits but not for others. I would like to reinforce the need to give editors the option to disable it (or choose to use it on an as-needed basis). Thanks! - tucoxn\talk05:37, 12 June 2013 (UTC)
It sounds like the current plan is that you won't be able to turn the old one off. Everyone will be given both options for all pages. WhatamIdoing (talk) 18:36, 12 June 2013 (UTC)
The main thing that I find frustrating in the current editor is formatting tables. I hope that the new Visual Editor will have WYSIWYG table editing. —Anne Delong (talk) 15:10, 10 June 2013 (UTC)
Editing the contents of tables is currently possible. Editing the structure and formatting of tables is not, but it will be one the main areas of work after July. (References, templates, categories, and images come first.) Ypnypn (talk) 21:22, 10 June 2013 (UTC)
I'm somewhat less than totally happy - I guess you only looked at the "Line 11:" part of your diff. Look further down; you actually broke a lot more than you improved. I'm thinking particularly of all those <nowiki>...</nowiki> around the URLs in references. --Redrose64 (talk) 09:03, 11 June 2013 (UTC)
I had hoped the VE would be good for reviewing long articles and making minor copy edits, which is very difficult to do in Wikitext. I found two problems: 1) the inability to edit section by section (only able to edit an article in its entirety); and 2) when editing an entire long article, as one move down in the page, the remaining text of the article accumulates garbage text, such that the remainder of the article becomes gibberish. Since there is no way to save only what has been edited at a certain point, I had to cancel all edits and begin again in Wikitext. Meclee (talk) 00:10, 11 June 2013 (UTC)
Maybe I'm not understanding something, but if I want to use VE and also edit any of the longer articles, I'm thinking I'll have to toggle back & forth between VE & the previous/older editing tools... Some of our articles are just so huge, seems like it'll take forever for them to load while editing. Shearonink (talk) 19:06, 11 June 2013 (UTC)
I'm not quite understanding what you mean by toggle back and forth between the edit tools. With VE on you are given two tabs at the top of the page, an edit tab for VE, and an edit source tab for how we've been doing it. You can just click on either depending on what you want to use.AioftheStorm (talk) 20:05, 11 June 2013 (UTC)
You don't understand the problem. The Edit source tab at the top can only be made to edit the whole article, so the current standard "edit section" source editor (which is indispensable for long articles) is lost. I've disabled the VE today just because of this. If the VE is made the default without the possibility to source-edit a single section, it will create a HUGE backlash. Diego (talk) 11:40, 15 June 2013 (UTC)
The VE will (or, was going to, last time I asked, more accurately) include an internal source editor - so hopefully that transition will be more intuitive. @User:Redrose; while it is becoming the default there will be an opt-out. Nobody's suggesting the VE become mandatory. Where did you get that impression? Okeyes (WMF) (talk) 10:54, 14 June 2013 (UTC)
Will this planned source editor capable of editing one single section, or is it the current Edit source tab that can only edit the whole article? Diego (talk) 11:43, 15 June 2013 (UTC)
Skins
I use the Modern skin. (Click here for this page displayed using Modern.) As of 06:50, 11 June 2013 (UTC), I cannot access the VE. I disabled a gadget I use that modifies that area, with no difference. When I switched from Vector a couple months ago, I didn't care that there wasn't a way to easily access it because it was still in alpha... then forgot VE existed. Am I right in thinking that it will be available soon? Also, what about the other skins? ––Ɔ Ȿ♭ ௵ ☎ ℡ ☎06:50, 11 June 2013 (UTC)
Confirmed. Monobook and Vector both work. Modern and Cologne Blue do not appear to support it. Even with a manual hack of the URL.
Well that sucks for me. I didn't know my preferred skin was (is?) on the brink of deletion. Thank you for your archive-scrounging. ––Ɔ Ȿ♭ ௵ ☎ ℡ ☎08:49, 11 June 2013 (UTC)
You misinterpreted that slightly. The modern and cologneblue skins are not going to be deleted, because they still have volunteer community support. However, that also means that it is probably up to volunteers to support V/E on those skins, and likely that it will never look as good as on the two skins that are officially supported by WMF (Vector and monobook) —TheDJ (talk • contribs) 09:25, 11 June 2013 (UTC)
I hope that the developers are also working on adding more features. It's very basic now, what I miss the most is the ability to add citations to the text and adding photos from Commons. Teemeah편지 (letter)07:49, 11 June 2013 (UTC)
Um, I also experienced a strange thing. I only removed some unnecessary text from a table and the VE removed some HTML coding throughout the table, too. Please see the diff [1]. I don't really like that edits I did not intend to make will be stored under my name in the page history. The editor should edit only what was requested and not change the codes otherwise. This is confusing and might result in personal attacks from other editors who check a change and then will accuse the editor of removing codes or altering a table formatting. :) Teemeah편지 (letter)08:15, 11 June 2013 (UTC)
I'm not an official spokesperson, but I've seen answers to others' questions saying that they're slowly adding features.
You'll be slightly relieved to know that all VE edits come with a "Tag:VisualEditor" in the history. Unfortunately, tags aren't shown on diffs. :<
After actually reading the diff, it seems it just removed a bunch of dead code and did other maintenance (assuming you removed the sentences and it removed the <small></small>'s and added the ""s on the ref names). ––Ɔ Ȿ♭ ௵ ☎ ℡ ☎08:36, 11 June 2013 (UTC)
I don't use VisualEditor myself, but if I encounter <small></small> with nothing between, I do remove it - manually. I believe that AWB removes it too, and there are certainly bots that do so. So in this case, I don't count it as a bug. --Redrose64 (talk) 09:23, 11 June 2013 (UTC)
It's not a bug, but a editor dhould not do this without the user knowing it might happen! Then the developers need to give clear descriptions that the VE will also do small automatic maintenance along with your on edits. I think it is important, I was surely surprised to see edits I didn't make under my own name! Teemeah편지 (letter)17:56, 11 June 2013 (UTC)
It's certainly a misfeature. It makes diffs harder to read and the extra edits from bots fixing these problems will clutter up people's watchlists. Dricherby (talk) 21:17, 11 June 2013 (UTC)
Surely bots won't have to fix those problems if extraneous markup is being handled by the VE? Teemeah; I'll bear this in mind as something the help documentation should cover. Okeyes (WMF) (talk) 13:40, 13 June 2013 (UTC)
This is confusing to me; I can't even figure out how I can test this new and likely unnecessary development.
The most important thing I can say is that, as a woefully un-technical middle-aged woman who barely knew how to use a word processor, I learned to edit Wikipedia. Yes, I had to learn, and yes, I made mistakes. Along the way I added to my personal skill set and enjoyed positive interactions with more knowledgeable editors. The interface has been improved several times since I created an account seven years ago. What's wrong with it? Yopienso (talk) 17:46, 11 June 2013 (UTC)
You said it for me. I'm an older man who's proud of having been able to learn some HTML and I don't see why anyone who's seriousy interested in editing can't do the same. I know it's going to make me sound like an old grump, but it seems like everyone wants to DO without having to KNOW. Anyway, should Wikipedia be edited by people who aren't smart enough to learn the coding system? If this isn't made optional, I think some of the experienced editors may take their interests elsewhere.WQUlrich (talk) 18:58, 11 June 2013 (UTC)
@User:WQUlrich, it's nothing to do with intelligence. It's to do with the initial barrier. I look at it like this; when I first started, I didn't know what Wikipedia was, particularly, or how the internal dynamics worked. I didn't have big interesting articles to write built out in my head, I wasn't aware of subject areas that needed specific work. I wanted to do one thing; categorise articles. That's it. After that I moved on to patrolling new pages - adding tags (manually, back in those days!), passing things, so on and so forth. I'd imagine that this is the same for a lot of people here, and for a lot of newbies; we didn't start wanting to write big articles. We didn't start with the drive to achieve big things. We started wanting to do a small number of little changes.
If a newbie wants to make those changes, they have to learn markup. They have to be comfortable with a screen of markup, something nowhere else on the web really offers you these days - frankly to a neophyte, hitting edit makes it looks like you managed to break the website. If I want to make a category change, not only do I need to learn linking and namespaces, I also need to learn the relative position of categories, and scroll through all of the text and all of the templates to make my tweak. It's a pretty high barrier when all you want to do is change a link - or add a reference, or fix a typo. It's nothing to do with intelligence, and it's all to do with the fact that when all you want to do is make a small tweak, you only want a small amount of cognitive load. Wikimarkup doesn't offer that - people are just going to go away, fix themselves a coffee and engage in some other hobby. Okeyes (WMF) (talk) 12:08, 13 June 2013 (UTC)
I know the citation/reference feature has "highest" importance in bugzilla,
and "is set to be deployed to the VisualEditor in a matter of days, not months." I see from the Q3 quarterly review that you're hoping (per slide 19) to deploy Visual Editor "on all language Wikipedias" by July 1 and (per slide 24) you won't proceed if references like {{cite web}} aren't available. I've tried it out a little on MediaWiki and it looks like you're going in the right direction, though IMO it is far too easy for a novice to delete an entire citation without realising what it is.
But the devil is in the detail and I just want to ask please allow plenty of opportunity for testing, review and polishing. There's no desperate urgency to make VE the default editor on enwiki. It's better to keep it as an "opt-in" preference for registered users until the citations functionality is ready for prime time. A few extra weeks won't do any harm. - Pointillist (talk) 11:23, 12 June 2013 (UTC)
We're going to have a pretty big beta with a lot of opportunities for testing and review; hopefully those should catch most of the major bugs (which reminds me, I have some bugzilla tickets to write...) Okeyes (WMF) (talk) 14:32, 12 June 2013 (UTC)
It'll be a pretty short beta if VE becomes the default editor for all users on July 1st! The generally accepted name once that happens is release. - Pointillist (talk) 15:19, 12 June 2013 (UTC)
It is launching soon, but yep, not very long. The beta does include an A/B test however that'll hit a large number of incoming new users - the idea is that we should be able to grab most of the issues with the VisualEditor from reports here, and from the beta. If it turns out that deploying it as a default is simply not workable I'm sure we'll reconsider. Okeyes (WMF) (talk) 18:30, 12 June 2013 (UTC)
I thought I had read that July 1 was to enable it for registered users only at the English Wikipedia (assuming all goes as planned), and that both IPs and most of the other Wikipedias would be later. Is that the current plan, or have I gotten something confused? WhatamIdoing (talk) 18:42, 12 June 2013 (UTC)
Oliver, all the draft schedules I've seen are still pushing for July 1 or very soon afterwards:
Per slide 27 of the March 27th quarterly review the final go/no-go decision was due in w/c 24 June for deploying VE as the default editor for enwiki in w/c 1 July.
The Wikimedia engineering report released last Monday says Our objective is for VisualEditor to be the default editor for all Wikipedia users, capable of letting them edit the majority of content without needing to use the wikitext editor, in July 2013.
It might be possible to deploy the software by those dates, but since the citation/template feature hasn't been deployed for opt-in testers on enwiki yet, it looks unnecessarily risky to shoot for full release so soon. - Pointillist (talk) 22:23, 12 June 2013 (UTC)
Plausibly, but I'd note that the pre-1 July work is going to consist of a rollout of references, at least, and then the release of a very widespread beta which should hopefully catch a pile of issues. We will invariably have bugs un-identified or identified and un-fixed when we deploy: that's an inevitability of software development. What's important is that we have as many bugs identified as possible, so that we can make an informed decision on "is this broken in a fundamental way that would prohibit a more full release". Off the top of my head, references being fundamentally broken for a big chunk of users would be a blocker for me, at least. Okeyes (WMF) (talk) 11:42, 13 June 2013 (UTC)
Visual Editor needs a way to display HTML notes since many times they are used within a page to describe information that is important to anyone who might be editing. That may include notes on how specific elements should be treated or that discussion is necessary before changes are made because such an element is disputed (see the genre sections of the article Green Day for example). Cat-fivetc ---- 11:30, 12 June 2013 (UTC)
Good point. Another example is the comment requesting that editors do not change the description of Taiwan at ISO 3166-2, where the official ISO description ("Taiwan, Province of China") must be used but is just a wee bit controversial. Quite often, lists have instructions about where new entries should be added, what sourcing is required, and so on. Dricherby (talk) 11:45, 12 June 2013 (UTC)
(edit conflict) If HTML could be at least displayed, it would aid AfC. As you all probably know, new editors who attempt to create an article are usually guided through the Articles for Creation process, which, after some informational screens, plops them into a new article with a small preloaded template. You can see what that looks like here, HTML comment included. Try the same page in the Visual editor, and you'll see the problem, this is something I'm also trying to bring up at Wikipedia_talk:WikiProject_Articles_for_creation#Be_aware_of_Visual_Editor_changes_coming.. --j⚛e deckertalk18:47, 12 June 2013 (UTC)
With regard to edit notices, that's not a general solution for HTML comments, as for articles and article talk pages, only admins and account creators can create them. It'd totally work for that particular example, though. --j⚛e deckertalk18:51, 12 June 2013 (UTC)
I agree, also they are not flexible enough for use to highlight specific sections of an article. Not to mention that they require editing a separate page to add. Cat-fivetc ---- 11:03, 13 June 2013 (UTC)
I dare say that this should be a showstopper to rolling this out for everyone by default, this WILL break articles and unlike the vandalism concern raised above, this will be good faith editors who inadvertently are doing this. Cat-fivetc ---- 11:03, 13 June 2013 (UTC)
It won't break articles; being able to parse and handle HTML comments is something already being worked on. Articles aren't getting broken. Being able to modify the HTML comments is another matter entirely, but I'm with Joe - things like page notices might be a better way of handling these (or the VE's little 'notices' box). Okeyes (WMF) (talk) 11:39, 13 June 2013 (UTC)
I should have phrased it better. It is going to break article editing for many articles. Well intentioned editors are going to make edits that are out of line with consensus and/or specific foibles in an article, or even a specific section of an article, because they can't see HTML comments alerting them to these things. In essence you will have accidental vandalism because people can't see the necessary comments. In terms of being able to modify HTML comments, that's secondary to just being able to see them. For the time being I don't think anyone will object to the idea that if you want to modify an html comment you should be doing edit code, as long as you can see them in every editing interface. Cat-fivetc ---- 16:44, 13 June 2013 (UTC)
At which point we have a problem of having lines of text in the editor that can't be modified. A better solution to this, as said, is for us to start using things like pagenotices for that kind of information rather than storing metadata in html comments. Okeyes (WMF) (talk) 18:28, 13 June 2013 (UTC)
If VE can be made to display HTML comments, surely it can be made to modify them? And, as has been said, page notices can only be placed by admins. Dricherby (talk) 18:41, 13 June 2013 (UTC)
Not to mention the fact that they require editing a page that is separate from the article. You shouldn't have to edit a separate page to give people vital information about editing an article. Cat-fivetc ---- 20:33, 13 June 2013 (UTC)
We already have text that can't be modified. Content that is transcluded (in articles that's mainly tables) can't be edited in the article and without going into edit code it is non-intuitive that you have to go somewhere else to edit it when it is greyed out on the main article while trying to edit it. Now, that's a different issue of course but it's an example of also how HTML comments could be dealt with. HTML comments could show up as a different color and be treated as a different element (click on it to edit just the comment) for the purposes of editing. Cat-fivetc ---- 20:33, 13 June 2013 (UTC)
Comment. VE needs to stop removing hidden HTML notes wholesale. At the time of this discussion by VE developers, Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations, hidden notes were preserved. Now ALL hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.
Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section.
If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates.
If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother?
Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work. Except this would only show up in VE edit mode. --Timeshifter (talk) 04:21, 15 June 2013 (UTC)
Page notices
VE does not display all page notices. For example, if you edit the source of Barack Obama, you see three notices: compliance with BLP, article probation and semi-protection. If you edit with VE, not only does the page take a very long to load but it only displays the article probation notice. The BLP policy notice seems too important to leave out, here. Dricherby (talk) 11:54, 12 June 2013 (UTC)
The BLP notice is not a page notice. It's a 'fake' notice that is dynamically added by JS, based on the presence of a category. It's an en.wp only feature, so it is our responsibility to 'fix' it and not that of the VE team. —TheDJ (talk • contribs) 15:54, 12 June 2013 (UTC)
OK – who are the people at en.wikipedia who need to be aware of this so it can be fixed? As for the loading times, VE takes 20-25s to start on Barack Obama for me. That's with Firefox 20.0.1 under Windows XP SP3, on a 1.33GHz Intel Core2 Duo with 2GB RAM. (So, basically, a four-year-old laptop but, if this is going to be rolled out world-wide, it ought to be useable in countries where some rich westerner's four-year-old laptop is a high-spec machine.) I just tried with Chrome 27.0.1453.110 m and the load time there was about 15s. Dricherby (talk) 20:13, 12 June 2013 (UTC)
The technical minded part of our community has a tendency of residing at WP:VP/T. Also, this is just a notice, we can fix it, but it doesn't seem like it would be the end of the world if some users for some days would be missing out on it. (Last time it took 6 days for anyone to notice that the blp notice had broken). —TheDJ (talk • contribs) 22:17, 12 June 2013 (UTC)
Another suggestion: would be good to be able to click and drag highlighted text to a new position with the mouse cursor, just like in word processing software. Lesion (talk) 15:06, 12 June 2013 (UTC)
I'll add it to bugzilla as an enhancement, but warning in advance: I can't promise when it'll be worked on or even if it will be at all. Priority right now is getting the VE to work full stop. Okeyes (WMF) (talk) 17:28, 12 June 2013 (UTC)
I'm worried that one of the biggest websites in the world is planning to introduce a major software update in only 18 days while saying "Priority right now is getting [the new software] to work full stop." If it's not ready for release, the 1 July target should be abandoned. Dricherby (talk) 20:04, 12 June 2013 (UTC)
I totally agree; if we lack things that are required for mainstream editing, we shouldn't release it for mainstream editing. But as far as I know things are proceeding at a great pace to have things like referencing functional; if something as important as that simply doesn't work, I'm sure the team will reconsider. I'd note that this major software update has been worked on for years and in an alpha (released here) for 6 months - and that the 18 day window will include a beta release which will, I'm sure, identify most of the bugs given the scale. I'd recommend heading over to MediaWiki.org and trying out the version there, which is slightly newer than the one here and includes things like a template editor. Okeyes (WMF) (talk) 11:37, 13 June 2013 (UTC)
I hope the temptation to release it prematurely isn't being driven by anything silly like June 30th being their year-end.... - Pointillist (talk) 22:56, 12 June 2013 (UTC)
I tried to fix the capitalization of a link like this and received the message "Your edit has been ignored because you have made no changes to the text." WhatamIdoing (talk) 18:35, 12 June 2013 (UTC)
In Fomitiporia_ellipsoidea#Description, the "note 1" is displayed incorrectly in VE. This is probably either due to the #tag use or the nested ref inside.
In List_of_awareness_ribbons, images are sized all sorts of ways by the VE, and the table is also shown oddly.
Also in Fomitiporia_ellipsoidea, the "protected" and "featured article" icons are displayed in the wrong locations.
(In my opinion, the VE seems way buggy to deploy atm. I hope some serious bug-fixing gets done before the deployment...) --Yair rand (talk) 22:19, 12 June 2013 (UTC)
Hi, Yair rand. Thanks for helping float issues with these. :) The tech team have been busily working on improving the VisualEditor and addressing bugs and will certainly continue right on up to deployment (and even after :D). You can see the list of bugs that have been filed (and resolved) here. It's good to see so many issues being floated now so they can be repaired.
Looking at Wikipedia:VisualEditor/Feedback/Archive 2013 05 there are an awful lot of bug reports that had still not been responded to when they were archived, five from me alone. Would it be an idea to suspend archiving on this page, or would it be reasonable to assume that this project is unlikely to be implemented without a major rewrite and a fresh testing phase? ϢereSpielChequers22:29, 12 June 2013 (UTC)
I'm working through it now; I was only assigned to this project formally yesterday, so it may take some time. WSC, you might get a better reaction if you simply go "hey, so you haven't addressed some bug reports, would it be a good idea to suspend archiving so they don't get buried?" rather than unnecessary snippiness. Okeyes (WMF) (talk) 09:29, 13 June 2013 (UTC)
I was sufficiently patient to wait until those reports simply got archived. Glad that the WMF has put some extra resource in, I will assume that this means they appreciate there is a problem. ϢereSpielChequers13:33, 13 June 2013 (UTC)
It means we appreciate there's a lot of feedback. Resourcing will continue to ramp up given the upcoming beta and then production launch. Okeyes (WMF) (talk) 13:38, 13 June 2013 (UTC)
Just added my first wikilink with visual editor, from Governor Stevens to Isaac Stevens. A little confusing. Wanted link to Isaac Stevens page to be blue to indicate the page exists. Also would have wanted to see "Appears on page: ..." and "Page linked to: ..." to confirm I did it correctly (not necessarily with these exact labels.) Djembayz (talk) 00:16, 13 June 2013 (UTC)
Here's what I'm seeing when I linkify a phrase that does have a matching title. When I linkify a phrase that doesn't have a matching title, it looks exactly the same except without the "Matching page" line. The text is blue after you exit the link creator box, but it's confusing that the search results use red text when a match is found. –Thatotherperson (talk/contribs) 11:57, 13 June 2013 (UTC)
I wanted to clear my sandbox (apart from the standard template at the top). It contained two paragraphs of text, each with a L2 header. Starting below the template, I dragged the cursor over the whole content to select it all and pressed "delete", but there remained the empty "== ==" of one header, like this. JohnCD (talk) 10:17, 13 June 2013 (UTC)
Was there any visible line for a header within the VE? So, what I'm thinking is that it could've assumed you were trying to change the header text and so left the presence of the header. We had a couple of similar problems with some usertesting videos we did, actually. Okeyes (WMF) (talk) 11:33, 13 June 2013 (UTC)
After pressing "delete", the thin horizontal line of the header was still visible in VE. I tried again, selecting only the second paragraph including its header and pressing "delete"; the == == from the second para's header remained and the thin horizontal line was visible. But when I selected both paragraphs including their headers, only one empty header remained. JohnCD (talk) 12:23, 13 June 2013 (UTC)
There may be an issue with this specifically but I'll note that at least for me, recently WikEd has been showing the same behavior with the Twinkle menus so there may be a bigger issue afoot with how menu systems are interacting with editing windows of any type. Just something to note FYI. Cat-fivetc ---- 11:22, 13 June 2013 (UTC)
A similar issue I've had (on MediaWiki) is that when clicking "Page Settings", the drop-down menu (with move etc) usually gets triggered, so I have to move the mouse away, wait a few seconds, and try again. Should this be considered a separate bug? Ypnypn (talk) 21:30, 13 June 2013 (UTC)
I think the "Heading 1" option should be removed from the menu; this should be used so little that the cost of editors messing up the page seems more than any possible benefit. Ypnypn (talk) 21:33, 13 June 2013 (UTC)
VE is clearly not ready for mainstream release and would be disruptive to editors, especially new editors. Therefore, the release of VE should be postponed until the bugs are worked out. There's no need to rush the release of VE and the best interest of Wikipedia should be our goal. Right now, VE would be harmful to WP. VE should be released when it would be beneficial to WP. SMP0328. (talk) 00:00, 14 June 2013 (UTC)
That's not massively helpful without, I guess, a request for prioritisation. That is; what bugs are to you complete blockers on any deployment? If we have a list of what people here find most important we can look at prioritising specific problems. Okeyes (WMF) (talk) 10:34, 14 June 2013 (UTC)
Am I supposed to be able to click and drag text? When I highlight text and try to drag it to drop it somewhere else, I see the insert cursor but when I release it, nothing happens. Jason Quinn (talk) 05:33, 14 June 2013 (UTC)
Huh; I was informed that this was possible, but I've just tried it both here and on MW.org and can't make it work. I'll kick the devs. Okeyes (WMF) (talk) 10:43, 14 June 2013 (UTC)
Second try at using VE, second bug. I tried editing another article, EastEnders, and again tried to (p)review my changes. Using the mouse wheel to scroll down, the mouse moved over an Infobox on the page. This obscured the "Return to Save Form" button even when I moved the mouse back up the 'dialog', so I couldn't click it. Took me a while, but eventually I figured out that I had to move the mouse back over some other part of the article behind and the green gauze disappeared... In usability terms, 3/10 I'm afraid! Stephenb(Talk) 11:12, 14 June 2013 (UTC)
(Using Firefox, btw) Stephenb(Talk)11:13, 14 June 2013 (UTC)
In this edit I attempted to delete the entire Oxygen subsection, including the table. I was able to do this using the VisualEditor interface without any problem. However, when I saved the page, the content was replaced by HTML markup. This is clearly a severe bug. — This, that and the other (talk)12:13, 14 June 2013 (UTC)
I like VisualEditor, however some problems do pop out. When I bold or unbold articles, in the preview it looks great, but after saving, random apostrophes pop out. Marcnut1996 (talk) 12:21, 14 June 2013 (UTC)
Please look at this diff. I tried to change the header type from 3rd level to 2nd level only. VE placed a huge string of codes in the article :S Teemeah편지 (letter)12:22, 14 June 2013 (UTC)
Yes looks like its just fallen over in a big way today. Massive curruption of whole page not just the edit! See Here. Tmol42 (talk) 13:32, 14 June 2013 (UTC)
I've just spoken to James; he's marking this as of highest priority (as in: the fix needs to be out immediately, whatever the deployment schedule says). I'm terribly sorry about this - I think I speak for James and the rest of the team when I say that. Okeyes (WMF) (talk) 14:41, 14 June 2013 (UTC)
Having posted this, I now see the notes above. Probably you turned VE off while I was doing the edit, in which case no need to reply! JohnCD (talk) 15:06, 14 June 2013 (UTC)
Is there going to be any sort of instruction manual - well manual is too heavy, instruction page or help page? I know it's meant to be instinctive, and it's pretty good that way, but I did flail about a bit when first trying to make a wikilink, and would have been grateful for something that said "1. type the display text, 2. select it, 3. click the "link" icon, 4. type the target". Similarly when first using the header drop-down menu. Maybe I am too soaked in wiki markup, but then so will many of your users be. JohnCD (talk) 15:45, 14 June 2013 (UTC)
Hidden comments/notes are useful for editors to see if there are things that are not supposed to be changed and/or things that can only be changed in a certain way.
The VisualEditor does not allow the editor to see them. It would be great if there were an option to enable/disable the ability to view these hidden comments (but have them enabled by default). Johnny Au(talk/contributions)02:17, 15 June 2013 (UTC)
Much worse than not seeing them is that Visual Editor removes them. All of them. It removes all hidden comments and notes. Hidden comments are critical in many cases. This really [censored] me off that Visual Editor is doing this, and that it is still doing this today after many complaints. I noticed it doing this today again when I tried to edit a section and was forced to use the Visual Editor due to the latest changes in default settings.
What is more atrocious is that it removes them from the whole page, and not just the section one initially started in. And unless you check the preview diff for the whole page you may not see this removal. Many of us spent a lot of time and thought adding hidden instructional notes for tables, references, sources, and much more. --Timeshifter (talk) 02:33, 15 June 2013 (UTC)
Easy there, Timeshifter. This is obviously a bug. Non-obvious bugs like this are inevitable during the development of a piece of software as complex as VE. — This, that and the other (talk)03:28, 15 June 2013 (UTC)
I was editing this page: Death of Neda Agha-Soltan. I bailed out of VE when in the preview diff I noticed VE removing a hidden HTML comment and a nowiki tag. The hidden comment was in an infobox. The nowiki tag was in a reference. I thought VE did not edit infoboxes and references. --Timeshifter (talk) 03:35, 15 June 2013 (UTC)
That is much worse than I thought. I will have to switch off VisualEditor until the hidden comments and notes are fixed, as it is a major issue. Having VisualEditor delete all the hidden comments and notes in an article, especially a long and contentious one, is a major deal-breaker. Johnny Au(talk/contributions)16:02, 15 June 2013 (UTC)
Wow, I sure miss that "edit" link on sections ...
Wow, I sure miss that "edit" link on sections! Keep going back to "edit source" for the whole article instead. Hope you'll have a way to "edit source for this section!" Djembayz (talk) 03:58, 15 June 2013 (UTC)
When I save, I get popup to describe what I have done. If I don't give comments and push Save, I get a reminder that I did not enter an edit summary, but the edit summary box is now disabled. My only option is to save again.
If I'm understanding you correctly, you're saying that when you tried to edit this version with visual editor to remove an image that had been deleted, you could not because it didn't show up in the VisualEditor window. Is that right? --Maggie Dennis (WMF) (talk) 14:21, 15 June 2013 (UTC)
[2] I could not edit para 2 (a blank line between para 1 and para 2) using VisualEditor. A mouse over resulted in para becoming green with "Sorry..." message. --RedtigerxyzTalk09:27, 15 June 2013 (UTC)
Not really a constructive comment, but I'd like to say that VE alpha is slow as hell and essentially unusable for me. If it is able to edit what you want to edit (i.e. not within a template of any kind) then chances are that in other parts of the article, it will mess with layout in a bad way, or insert a load of random characters for no reason. I'm now disabling VE alpha with extreme prejudice. Lesion (talk) 09:51, 15 June 2013 (UTC)
I've also disabled it after finding the thing to be slow, clunky and confusing. Even the hyperlink thing seemed like hard work, although the concept of providing a list of possible targets (as per dablinks) is fundamentally sound and fails only because the lists were so truncated compared with the possibles.
I can imagine that the thing would be useful as a means of avoiding those accidental misclicks that cause <big>, bulleted lists etc to appear but beyond that it was just frustrating. Hopefully, it will improve and hopefully the potentially single most useful element will turn up when the initial issues are resolved, ie: a decent way to construct tables visually. - Sitush (talk) 21:22, 15 June 2013 (UTC)
Closing popup boxes
I think I mentioned this before, but I think it needs to be raised again.
Currently, the popup box for editing links can be closed by using the left-pointing arrow in the top-left corner, or clicking away from the box. However, the most common UI pattern (Windows, Mac, Facebook, etc.) is to have a "close" button on the top-right corner and/or a "cancel" button in the bottom-right corner. But instead, we have the "remove link" trashcan icon in the top-right. Many users will click this when they want to close the link editing popup, and find their nicely created link gone.
This is worse with the "category sortkey" popup box within "page settings". This doesn't have any obvious way of closing it at all (other than clicking out, which is not well-known among less tech-savvy users).
I have heard a member of the VE team explain in the past that users will be comfortable with the "back" metaphor... Well, dialog boxes don't normally have "back" buttons in the top-left corner; instead, they have "close" or "cancel" buttons, as I explained above. This is a confusing mix of UI metaphors that fails to help the user efficiently interact with the VE interface.
Can I please urge the VE team to reconsider this UI design decision, and introduce a more obvious "close" and/or "cancel" button in these popup boxes? — This, that and the other (talk)10:07, 15 June 2013 (UTC)
{{sfn}} broken : used on every page I write- no mention of whether {{efn}} works
<!-- ... --> : used on many pages to leave trails of where references may be found, and advice on potential dubious arguments and unreliable references.
caption editing broken :
tables :
templates :
I don't dare to enable a test.
Perhaps I am too long in the tooth, and seen too many software improvements destroy systems- no matter how brilliant the coding. But can I ask that one improvement is immediately incorporated, that: The edit summary of all edits made with VE are clearly marked, so we see immediately in our watchlist which articles have potentially had their structures 'improved'. From the comments above just about every article I have ever edited is vunerable.-- Clem Rutter (talk)13:06, 15 June 2013 (UTC)
An edit I made using VE resulted in "<nowiki>" and "</nowiki>" (without the quotation marks) appear throughout the source version of the article. I removed them in the edit. They don't appear in the public version of the article, but there's no good reason for them to be added. I was using Firefox 21. Clicking "edit" next to a section or subsection header should lead to VE. Currently, so clicking leads to the standard edit window. Otherwise, VE worked well. SMP0328. (talk) 02:36, 11 June 2013 (UTC)
@SMP0328.: I agree that if you place [[ ]] into the edit it shouldn't give you "<nowiki>" and "</nowiki>" but there is a link button on VE that allows you to highlight words or phrases and convert them into wikilinks. I also agree that clicking "edit" next to a subsection should open VisualEditor and not the Source. I ran into that as well. I actually do like VE. Teammmtalk email03:17, 11 June 2013 (UTC)
Just to reiterate, "<nowiki>" and "</nowiki>" appeared throughout the article, not only in the part I edited. Also, I did not add or remove any wikilinks in my VE edit. SMP0328. (talk) 04:02, 11 June 2013 (UTC)
I'm just passing through.... My guess is that while it, of course, should only do it in the intended area, it purposefully added "nowiki" so that you could type the brackets instead of making a link. Again, the link button mentioned is what editors are intended to use for links. ––Ɔ Ȿ♭ ௵ ☎ ℡ ☎05:10, 11 June 2013 (UTC)
So you're saying that when WhatamIdoing munged many links in a table, thinking he was editing something else there, that wasn't a bug, it was a feature? —David Eppstein (talk) 05:20, 11 June 2013 (UTC)
Since I don't know what you're referencing and am too lazy to search this page, I'll just restate: The link button is the (current) intended way to make an internal wikilink. What I was trying to say is that since SMP0328 typed brackets, it tried to make sure that those brackets were visible. Basically, I'm guessing the VE is (rightly) programmed to make visible any typed wikimarkup/HTML so an editor doesn't have to click a "nowiki" button because one is (currently) expected to use buttons, etc. for wikimarkup/HTML. ––Ɔ Ȿ♭ ௵ ☎ ℡ ☎06:14, 11 June 2013 (UTC)
I'm referencing sections #Beta release seems rushed and #Tables immediately above, where WhatamIdoing posted about using VE to edit some tables. If you look at WhatamIdoing's diffs (as Ypnypn pointed out in one of those sections), unbeknownst to WhatamIdoing, a whole bunch of links elsewhere in the tables got nowikied. If you think this is correct programming, and that SMP0328's report is just a user misunderstanding of a useful feature, you are very badly mistaken. —David Eppstein (talk) 06:37, 11 June 2013 (UTC)
In this section, Teammm said that typing brackets caused the nowikis, which is what I responded to in my initial statement. I'm now noticing that SMP says (s)he didn't try to change any links, which I must've glanced past. (I didn't notice exactly what was different because of the added newline causing the diff to not clearly show what (s)he edited.) I just took Teammm's comment as reputed truth. I now realize what's going on and partially stand by what I said. I think the VE is not programmed clearly enough to reliably distinguish URLs and a plain sentence with a year from typed wikimarkup/HTML and is therefore trying to make all the supposed coding on the page visible whether or not any are changed. Sorry for my fubar. ––Ɔ Ȿ♭ ௵ ☎ ℡ ☎08:07, 11 June 2013 (UTC)
Facepalm Rereading all this, I noticed another point of non-clarity. When I said that it's rightly programmed to nowiki typed coding, I meant it was a good idea, not that it was implementing that idea correctly. ––Ɔ Ȿ♭ ௵ ☎ ℡ ☎08:20, 11 June 2013 (UTC)
Happened to me too, in this edit - I changed wording in the last sentence of the intro, and the VE gratuitously put nowiki tags around several URLs inside cite templates. (You can see it also altered some spacing inside template parameters.) - David Gerard (talk) 19:38, 13 June 2013 (UTC)
It looks like Subbu (one of our devs) was planning to work on this, so I've poked him. If he's busy or doesn't have a firm ETA I'll throw it in Bugzilla as a distinct and frankly high-priority ticket. Okeyes (WMF) (talk) 10:52, 14 June 2013 (UTC)
@CSB_radio: The link button is the (current) intended way to make an internal wikilink. If that's true, I hope you're providing a keyboard shortcut for that button that will work under all browsers. Otherwise you're removing the possibility to edit paragraphs including wikilinks by keyboard alone, which would be a terrible design mistake. Diego (talk) 11:54, 15 June 2013 (UTC)
Ok, I've found that links can be added with the CTRL+K shortcut. But now there's a problem - I tried to create a link with [[ and ]], and the whole sentence was marked with the noWiki tag (instead of just the brackets) so it can't be edited again, the whole sentence is treated as a block that only can be deleted with the VE. (I did it at the sandbox page of Mediawiki, thus using the new version there). Diego (talk) 12:25, 15 June 2013 (UTC)
This is cool, when i edit this, it shows me my references. What's interesting is that it adds 9 nicely formatted references beforehand, and I have no idea where they're coming from. :) I cut/pasted below, the last 2 refs are correct as near as I've observed.
↑ Bourne, G. E.: Columbus, Ramon Pane, and the Beginnings of American Anthropology (1906), Kessinger Publishing, 2003, p. 5.
↑ McKenna, T.: Food of the Gods – The Search for the Original Tree of Knowledge – A Radical History of Plants, Drugs, and Human Evolution, Bantam Books, 1993, p. 199.
↑ 3.0 3.1 Porter, R., Teich, M.: Drugs and Narcotics in History, Cambridge University Press, 1997, p. 39.
↑ Techmedexperts.com
↑ "Smoking ban puts snuff back in fashion". Retrieved 1 November 2010.
↑ Snuffbox.org.uk
↑ Boffetta P, Hecht S, Gray N, Gupta P, Straif K. Smokeless tobacco and cancer. Lancet Oncol. 2008;9(7):667–75. doi:10.1016/S1470-2045(08)70173-6. PMID 18598931.
↑ Phillips CV, Heavner KK. Smokeless tobacco: the epidemiology and politics of harm. Biomarkers. 2009;14(Suppl 1):79–84. doi:10.1080/13547500902965476. PMID 19604065.
↑ Russell, M A H Russell; Jarvis, M; Devitt, G; Feyerabend, C (1981). "Nicotine intake by snuff users". British Medical Journal (BMJ Group) 283 (6295): 814–816. doi:10.1136/bmj.283.6295.814. PMC 1507093. PMID 6794710.
↑ Schomburgk, Sir Robert Hermann (1848). The History of Barbados: Comprising a Geographical and Statistical Description of the Island; a Sketch of the Historical Events Since the Settlement; and an Account of Its Geology and Natural Productions. Longman, Brown, Green and Longmans. pp. 332–. Retrieved 13 June 2013.
↑ Wilson, James Grant; Fiske, John, eds. (1900). "Stein, Conrad". Appletons' Cyclopædia of American Biography. New York: D. Appleton.
:Hmmm, can't reproduce now. Not sure if it's because I added a couple more refs myself or not, but I did try editing an old version, and still can't reproduce this as of the last few minutes. --j⚛e deckertalk23:01, 13 June 2013 (UTC)
That's too bad, because that would be an awesome unexpected feature of VE. :) I mean, assuming William Spry has some connection to snuff. :) They come from that article, fwiw, but without being able to replicate the issue it's hard to figure out how. (I imagine. It would be hard for me to figure out how even if you could replicate it, but I bet our developers could work it out.) --Maggie Dennis (WMF) (talk) 11:49, 14 June 2013 (UTC)
I'm not sure if it's related to the TL:DR infobox comments above, but I just had my first ever VE edit destroy an infobox by adding nowiki to a bulleted list. I clicked the edit section link way down the page and didn't go near the infobox other than to find the save button. I think that's enough of a trial for me. You have to make sure the "do no harm" principle is followed in terms of not touching parts of the article that aren't being actively edited, we don't want all edits running an auto-mini AWB-general cleanup-fix routine at the same time. The-Pope (talk) 15:03, 15 June 2013 (UTC)
I'm finding VE useful, even in its alpha state, as an adjunct to the source editor. I still primarily use the latter, but VE is good for proofing, like finding format errors. When the UI gets streamlined, I'll be inclined to use it more, and as others have noted, the ability to invoke one inside the other would be especially helpful. RE: the concerns that VE will open the floodgates to disruptive editing, I share that concern. But I think the answer isn't to dump a useful tool, but to make sure that disruptive editors are dealt with more convincingly. That's a policy matter. Barte (talk) 15:21, 15 June 2013 (UTC)
Thanks for your comments, Barte, and I appreciate your checking out the alpha. Hopefully as bugs are repaired and features are enabled, it will become more and more useful. Speaking more from my own perspective as a long time volunteer, I have similar thoughts regarding the disruptive editing concerns - both worries about it and the hope that it's something we can accommodate. I find myself thinking that it must be in some way a similar sensation experienced by the editors of Nupedia, when Wikipedia was first proposed. If you open the gates wider, what will come through? Will it work? I hope it will turn out as well. :) --Maggie Dennis (WMF) (talk) 12:37, 16 June 2013 (UTC)
As eager as I am to use VE, it does not seem ready as evidenced by the multitude of threads here -- section editing, redirects, speed, templates, low level of confidence in not breaking wikiformat, so on. Has management considered postponing the date of making VE the default editor? 192.136.210.191 (talk) 21:38, 15 June 2013 (UTC)
There's a link on my watchlist that says "help us to test [VisualEditor]" and it takes me to this page, which doesn't tell me how to help to test VisualEditor. I've worked out how (and think it's useless until I can add references with it, FWIW), but it's far from obvious. Could an appropriate link be added to the top of this page, or alternatively the watchlist notification be rewritten? – Arms & Hearts (talk) 00:17, 16 June 2013 (UTC)
A number of people (e.g. the item above this, and "More infobox dramas" further up) are reporting unintended consequences of VE edits in parts of the page distant from what they intended to edit. Are these all bugs, or is VE designed to make AWB-type cleanup edits in addition to what the user asks it to do? JohnCD (talk) 11:15, 16 June 2013 (UTC)
My guess (but the developers would know better) is that it's not an intended consequence, but rather a mismatch between the wikitext that we think of as the source and whatever internal format VE is using to represent the source. —David Eppstein (talk) 18:55, 16 June 2013 (UTC)
@Okeyes, I find "AWB-type cleanup is involved" extremely alarming. With AWB there are strict Rules of use, permission is required and is given only to trusted users with at least 500 mainspace edits, and it is made clear to them that they are responsible for everything done by it, and their permission may be withdrawn if it is misused. If VE becomes the default editor for everyone including newbies, we cannot expect them to check on "cleanup" edits it may make in other parts of the page, possibly involving wiki-markup they do not understand, so its automated "cleaning-up" will effectively be unsupervised. What sort of testing is planned that could possibly make that a safe or sensible idea? JohnCD (talk) 19:55, 16 June 2013 (UTC)
Yes. If it's "too hard not to do that", that's one thing - if it's a deliberate design decision, that's a seriously bad idea. Do you have documentation either way? - David Gerard (talk) 19:57, 16 June 2013 (UTC)
This is terrible. This is the edit I wanted to do (literally, add one character); this is what the VE actually did. At present it's in Sorcerer's Apprentice mode - how is anyone supposed to look at a diff like that and see what the actual change was? It's an open invitation to subtle vandalism - David Gerard (talk) 20:48, 16 June 2013 (UTC)
This is a bug in Parsoid that serializes HTML back to VE -- this is a regression introduced recently. I added a bug report for this T51655. Thanks for the report. Ssastry (talk) 21:28, 16 June 2013 (UTC)
Jumps down a screen or so on "Section edit"
I noticed that when I try to edit a section by clicking on the "edit" by the section header, VE automatically jumps down to later in the article, and I have to scroll back up to edit again. I initially thought it was jumping to the next section, but it seems to be somewhere between a screen and half a screen in my browser (Firefox). ~Adjwilley (talk)15:34, 16 June 2013 (UTC)
@Adjwilley: I'd guess this is a result of the vanishing Table Of Contents? If that's the case, then a bug is already submitted: Bugzilla:49224. If it's not related to that, then please let us know, so that we can narrow it down. –Quiddity (talk) 18:51, 16 June 2013 (UTC)
R-to-L text?
Can't edit the Arabic at Osama bin Laden. (And yes, I can edit that article, just not the Arabic! I presume this is a general bidirectional text issue, that is a known hard problem.) --j⚛e deckertalk04:48, 17 June 2013 (UTC)
Ah, that's in a template to tag it. I'd strike this, but in the long run, a solution for entering and appropriately setting off non-English text is probably a low-urgency requirement. --j⚛e deckertalk05:35, 17 June 2013 (UTC)
Additional backup?...
is that some devs or editors who are really REALLY familiar with the Visual Editor should hang out in at least #wikipedia-en and #wikipedia-en-help on IRC for a while. There could possibly be a lot of questions that the regulars won't be able to answer. Shearonink (talk) 14:20, 10 June 2013 (UTC)
I'm (I guess) the second category; once the beta goes live I'll be hanging around in both channels - probably not watching actively, because I imagine talkpages will be rather a-flutter, but available to be pinged. Okeyes (WMF) (talk) 13:41, 13 June 2013 (UTC)
Another possible issue is that when the 50percenterVE/IPs come into the Help Channel asking questions about VE, if Helpers do not have VE ennabled in their Preferences then they will have no idea what the noobs are talking about, so yes having a dev or someone experienced with VE would be very helpful. Please, some of you folks who have been testing this, PLEASE make a point of hanging out in the IRC/#wikipedia-en-help channel for the duration of this roll-out. Shearonink (talk) 04:19, 18 June 2013 (UTC)
Concerned about citations
Making things easier for new editors is a great goal. However, if Visual Editor is released in its current state and succeeds in getting lots of people to edit who wouldn't edit otherwise, then we have lots of editors using an interface that's incapable of producing citations. That means that these editors are incapable of making anything but the simplest edits (essentially, things that could legitimately be tagged as minor) in a way that is compliant with Wikipedia's core policies on verifiability. That really seems like it's inviting trouble. It's not even clear that it's a net benefit to the encyclopaedia: we get a lot of new editors but, whenever they try to do something substantial, more experienced editors will have to come and fix the mess. We're setting up the new editors for failure: they'll be criticized for not sourcing their additions and have a lot of their edits reverted. The only constructive advice we'll be able to give these editors is, "Don't use Visual Editor." Please do not introduce this software until it can deal with citations: policy requires this. Dricherby (talk) 21:13, 11 June 2013 (UTC)
Great news. Thanks for making that clear. If VE makes adding citations easy for new users, I think we could be on to a great thing, here. Dricherby (talk) 22:35, 11 June 2013 (UTC)
Really? It gets pushed onto 50% of all new users in a matter of hours yet it still has nothing to assist with citations, do not foist this on new users before this major hole is fixed Jasonfward (talk) 21:35, 17 June 2013 (UTC)
Why isn't VisualEditor enabled for section editing? I was playing around with VisualEditor on my user page. I can not foresee much use for VisualEditor if it can not be used for section editing.
If it is enabled for section editing, then it will also be necessary to enable "edit source" somehow for sections too. So people can choose between the two. Just like at the top of page.
This is not about long articles either. I use section editing for almost all my editing, whether in short or long articles. If the developers are worried about cluttering up each section with both "edit" and "edit source" links, then there needs to be some icon next to "edit" that will be the link for "edit source". The clickable icon will have a popup tooltip saying "edit source".
Anonymous editors do much of the editing on Wikipedia, and many will prefer to edit the source wikitext. Many will prefer the VisualEditor. There has to be a choice at every stage, or this venture could drastically lower the total number of edits in the months following full implementation. It may take a long time to build back from that loss of monthly edits. --Timeshifter (talk) 00:13, 12 June 2013 (UTC)
The purpose of section editing is so that you don't have to page through screenfuls of code to find the typo (or whatever) you want to fix.
Since there are no screenfuls of code to page through—you see the typo, and you fix it right where you read it—what practical purpose does section editing serve? WhatamIdoing (talk) 05:26, 12 June 2013 (UTC)
Edit conflicts are (mostly) solved for these days, but the load time argument is a good one. There's actually a bug (now linked) about the problem. Okeyes (WMF) (talk) 18:33, 12 June 2013 (UTC)
Edit conflicts are mostly solved for? Wow, that's certainly news to me, almost every third edit I've done for the last month has hit an edit conflict or otherwise been messed up because of two editors working in the same section at the same time. And no, edit conflicts will remain a problem if two people are working on the same article and cannot edit section-by-section; experienced editors tend to make several corrections at one time rather than saving after each typo fix. Since the edit isn't saved as soon as the keystroke is complete (nor should it be), you're still going to have edit conflicts. Risker (talk) 04:05, 18 June 2013 (UTC)
WhatamIdoing and all. Load time will still be an important factor with VisualEditor. That reason alone justifies continuing with section editing. Also, many people will still use wikitext source editing. There will long be a need until every single bug is fixed in VisualEditor. I can tell you this from years of experience with the Wikia visual editor. Many, if not most, regular editors on Wikia avoid it due to its continuing bugginess. Bugs are seemingly never-ending and ever-growing with visual editors. Also, many anonymous Wikipedia editors are experienced Wikipedia editors, and will not tolerate having to only use VisualEditor. So never get rid of the option for source editing.
Do you have section editing enabled? If not, you might try it. It speeds up editing immensely for me, and many others. See: Special:Preferences#mw-prefsection-editing and "Enable section editing via [edit] links". It would be better if it were enabled by default for all editors, whether logged in, or not. I don't know why anybody would want to wade through paragraphs of irrelevant stuff to get to the paragraph and section one is interested in editing. Especially if you make multiple edits, and use multiple previews. Why wait long periods of time for full-page previews? A section preview is much faster. I have been editing since 2005, and at one point I had forgotten that section editing is not a given for all editors. We are wasting a lot of editors time by not enabling it by default. Since there are fewer and fewer editors we need to make their editing more and more efficient. --Timeshifter (talk) 19:44, 12 June 2013 (UTC)
I get it now. I must have been confused by the preference. I see now that section editing is enabled by default for both anonymous and logged-in users. It is a preference to turn something off.
I would hate to lose section editing of source wikitext if VisualEditor is enabled for section editing. That would be a serious step backwards. --Timeshifter (talk) 22:10, 12 June 2013 (UTC)
(unindent). Comment. I sometimes like to open up a section in a new tab for editing. So I can switch between tabs to alternate between how the section currently looks, and how my preview looks. This also helps me in finding stuff in the wikitext. I can use browser find in both tabs to help me find where I need to edit.
This can be very necessary when editing references, tables, navigation boxes, image captions, and other such wikitext. Images that are right-floating, for example, can be difficult to find in the wikitext otherwise. So section editing of source wikitext is essential. Let us not remove section editing of source wikitext when VisualEditor is fully implemented, and when VisualEditor is enabled for section editing! It would be extremely difficult and time consuming to do these things with two side-by-side full pages in tabs. --Timeshifter (talk) 22:39, 12 June 2013 (UTC)
I think the point is, it doesn't matter how many features you add to the editor, there always will be some features not implemented that require access to the source. The editor should be designed around backwards compatibility with wikicode, because that's not going away anytime soon. Sure, make easy edits easy, but not at the cost of making more complex use cases difficult or impossible (when they're straightforward now through wikicode and section edits of source code).
Your design needs to take into account not only which functions you're adding for new editors, but also which flows you're changing or removing for experienced users. It's a great thing that you've opened this discussion and are actively watching it, as it will allow us to expose those flows that we depend on from the old editor and that you couldn't have previewed when you started the tool. Diego (talk) 12:01, 15 June 2013 (UTC)
I've been avoiding VE since {{sfn}} was broken (above) making it unusable, but left it enabled. This morning it started when I clicked on a section edit tag, and this was the mess it made of the sandbox I was editing. I will now need to turn it off under Preferences.
This doesn't feel like it's ready to enable as default. If it's still messing up articles, inexperianced editors are going to see their edits reverted through no fault of their own. In my opionion it needs to be working for at least 2 weeks before enabling by default. Edgepedia (talk) 04:10, 14 June 2013 (UTC)
I've asked James and his team to prioritise multi-layered referencing (which is the thing going wrong there). In the meantime there is a preference switch to have section edit tabs take you to the source, rather than visual, editor - "Use the wikitext editor for editing sections while VisualEditor is in beta " under "Editing". Okeyes (WMF) (talk) 10:41, 14 June 2013 (UTC)
for section links? I think many of us enjoy being able to help with the beta, but enjoy the option of using edit-source when templates or problems are encountered. Thanks. –Quiddity (talk) 19:07, 14 June 2013 (UTC)
Well, changing that preference doesn't prohibit you editing with the VE :). So, I would honestly just recommend changing that tickbox if you're encountering problems; all section-edit mode does with the VE is render the entire page and then scroll you down to the appropriate section, so from a bug-identification or testing point of view you're not actually losing anything. Okeyes (WMF) (talk) 19:14, 14 June 2013 (UTC)
(unindent). Many registered editors don't edit enough to know much about preferences. This is a bad idea. VE editing of sections should be opt-in, not opt-out.
This could cause many editors, who already do not edit much, to edit less because their edits get reverted soon after using Visual Editor. VE messes up many things. I have seen it myself, and so I do not use VE. I have to check a WHOLE-PAGE preview diff for errors it inserts before I save some other minor thing I edited. Minor typos and other things that used to take me a few seconds to fix now take a long time with the Visual Editor.
Visual Editor needs to edit SECTIONS, too. Not the whole page. So this fix is not a fix. Visual Editor still does not support section editing. It still only edits the whole page.
Worst of all, what was once an interesting option has now become an imposed encumbrance. There is no way to edit in source mode now without effort. Registered editors are forced to use VE. They can only opt-out of VE section editing. They must go here: Special:Preferences#mw-prefsection-editing
Please return section editing of source wikitext as the default. Make this VE section editing gimmick the option in preferences. Make it opt-in, not opt-out.
The WMF does not have anywhere near a consensus or approval or any other type of community process sanction that justifies imposing beta VE. Especially when it is as buggy and beta as it is now. VE was actually an interesting option until this latest forced imposition of beta VE.
This option in preferences means that once I enable it I lose this gimmicky ability to edit sections with the Visual Editor. So that means we still do not have the ability to edit sections with Visual Editor. I did not want to sacrifice the ability to edit sections in source mode in order to get the ability (however gimmicky) to edit sections with VE. So I noted that in bugzilla:48429. --Timeshifter (talk) 00:47, 15 June 2013 (UTC)
What do you mean "they can only opt-out of VE section editing"? They can opt out of using the VE altogether. In addition, I'm confused by your statement that "VE editing of sections should be opt-in, not opt-out." I've conducted some tests at my end; the ability to edit sections through the VE appears only if you have actively enabled the VE. In other words, the only editors who could possibly be hit by this are editors who are self-evidently able to modify their preferences and aware of what's going on with the VisualEditor. I may be wrong, however; can you, at your end, replicate "being able to edit sections with the VisualEditor, when the VisualEditor checkbox is unticked"? Okeyes (WMF) (talk) 10:46, 17 June 2013 (UTC)
Back when I wrote my last comment in this thread I was still confused by all the opt-in and opt-out preferences for section editing. It was already confusing before the VisualEditor preferences were added. It will be triply confusing to new editors on June 18 when VE is made the default for half of new editors. This will be true unless both "edit" and "edit source" links are on each header for users with VE enabled. --Timeshifter (talk) 12:51, 17 June 2013 (UTC)
Why will it be confusing? New users don't tend to go near their preferences. Again, can you replicate the initial issue you brought up? Okeyes (WMF) (talk) 12:53, 17 June 2013 (UTC)
It will not be confusing to new users if those new users with VE (half of them from June 18 on) have BOTH "edit" and "edit source" links on each section header.
See my comments in bugzilla:48429 to see my initial issues and the followup issues as I figured out how the preferences were working, and which ones were on by default, and which ones were not on by default.
Enable section editing by right clicking on section titles (requires JavaScript).
Enable VisualEditor (only in the main and user namespaces).
Use the wikitext editor for editing sections while VisualEditor is in beta.
Currently only the first preference is on by default. On June 18 "Enable VisualEditor" will also be enabled by default for half of new users. --Timeshifter (talk) 13:12, 17 June 2013 (UTC)
I'm not seeing how this is confusing. I'm not seeing how adding a edit source link to sections will do anything but confuse our test results. New users, if they fall into the 50 percent that get the VE, will be presented with the VisualEditor consistently via the 'edit' button, and the VE consistently via the 'edit' button in sections. Where's the point of confusion there? If what you're asking is "can we have the edit source link because we, as power users, need it" just say that - there's no need to wrap things up in new user concerns to make me pay attention. Okeyes (WMF) (talk) 13:20, 17 June 2013 (UTC)
You need to get this. Many people have written about this numerous times in multiple talk sections here, and in various bugzilla threads recently. I have explained it to you several times myself on this talk page. Concerning both new users and regular editors. I am tempted to say that this illustrates the common problem I have noticed when people who hang out a lot with the developers on Mediawiki.org and Bugzilla try to understand the point of view of regular editors giving honest feedback. They just can't wrap their minds around it. Many new editors also use source editing. It seems you just don't get this. Lots of other developers get this now though, so I will trust them to follow through. Listen to them if you don't trust and/or understand me. --Timeshifter (talk) 14:13, 17 June 2013 (UTC)
Timeshifter, I'm not a developer, I'm an editor. Be accurate; you're not tempted to say it, you are actually saying it - there is a difference :). If I can understand your argument, which is very different from many of the statements you've made so far; a lot of new editors are going to be used to wikimarkup from their time as IPs, and so will need access to the source editor. Is that correct? Okeyes (WMF) (talk) 14:18, 17 June 2013 (UTC)
Yes, that is it. And they need that access via section links to "edit source", and not just from the "edit source" link at the top of the page. And new editors, whether they have previous experience with wikitext or not, will need "edit source" links in order to edit the stuff that can't be done with VE.
My other point was a more sophisticated analysis of why the regulars in any project (including projects outside Wikimedia altogether) have difficulty understanding the point of view of others seeing the project. Related topic: UX, and the user experience. I was only guessing if it applied to you or not. Another possibility is that you are tired, or I am tired. I could be explaining things poorly at this point. I sometimes do not understand things at first. I have noticed that I occasionally have "brain farts" where I just can't grok something, and it is clearly obvious to me later. This talk section illustrates it. It took me awhile to understand the settings that were enabled by default. --Timeshifter (talk) 14:42, 17 June 2013 (UTC)
The medical phenomenon of brain farts is well-understood at this end; I have them on occasion too, so I think it's safe to leave the source of the confusion here a known unknown :). That's a good point; hopefully, in that case, the bugs mentioned above will be solved for and this can be introduced. I'd say that actually we shouldn't be giving new editors access to non-VE stuff if they're new to Wikipedia, insofar as if the end goal is "have a VisualEditor that does all the things people need to do in markup", having people be able to go "hey, I wanted to do X and can't do X" is useful so we can prioritise X, whatever that might be. But your point about prior experience is well taken. Okeyes (WMF) (talk) 15:26, 17 June 2013 (UTC)
Section headings in edit summaries
When all of the edits are within one section, it would be nice to have the section headings listed in the edit summary by default. This ought to begin with the usual link to the section and "External links". WhatamIdoing (talk) 04:48, 14 June 2013 (UTC)
That makes sense; it seems like the sort of thing that should be factored into a proper VE section-editing plan, however. Okeyes (WMF) (talk) 13:29, 17 June 2013 (UTC)
When I attempted to correct something minor in Bleak House using VE (my first ever use!) I decided to preview the changes just in case, only to be surprised that it would have removed the hidden comment "<!-- See [[Wikipedia:WikiProject Novels]] or [[Wikipedia:WikiProject Books]] -->" from the Infobox. This confused me (as an experienced editor) - particularly since the Infobox is 'off-limits' to VE, so I don't know what a new editor would feel! That change, if I'd left it, could also have been seen as minor vandalism. Count me as unimpressed so far. Stephenb(Talk)11:00, 14 June 2013 (UTC)
This is a bug in Parsoid that serializes HTML back to VE -- this is a regression introduced recently. I added a bug report for this T51655. Thanks for the report. Ssastry (talk) 21:31, 16 June 2013 (UTC)
As you can see with the threads above this one, there's a pretty serious issue with the VisualEditor at the moment; it's been tentatively traced to a deployment earlier this morning. We've made fixing it of the highest priority, and in the meantime are about to turn off the VE to prevent people accidentally munging articles. It goes without saying that we're very sorry about this issue, and the disruption it has caused; hopefully it won't be repeated! Okeyes (WMF) (talk) 14:49, 14 June 2013 (UTC)
Trying to change simple text from "almost 11.900" to "22.300" resulted in this [3]
trying to change two wikilinks (Danube Bridge 2 and Vidin-Calafat Bridge to Vidin–Calafat Bridge) resulted in this mess: [4]... the first 1st link came out as [[Vidin-Calafat Bridge|[]][Vidin–Calafat Bridge]] and the 2nd link would have worked, if not out of nowhere "nowiki" would have been added to the link... Hope you can fix these issues. noclador (talk) 14:42, 14 June 2013 (UTC)
I copied the correct name of the article and then pasted that over the two existing links in the Vidin article. Before saving both links looked correct (i.e. like: [[Vidin–Calafat Bridge]]) and after saving I checked both links again and found them to be messed up. --noclador (talk) 16:34, 14 June 2013 (UTC)
Wait, so you just copied the raw text over? or the raw text including wikimarkup, or...? Changing links in the VE is a two-step process; you need to change both the text in the article and create a link from the link dropdown. Sorry if I'm sounding silly; trying to scope out the bug :). Okeyes (WMF) (talk) 16:39, 14 June 2013 (UTC)
I tested image adding on my userpage, and that didn't go too well, either. :/ That one is being tracked as bug 49596. The answers to your other questions have not yet been entered into the VisualEditor/FAQ, but are definitely in the plans, with a space for "How do I edit images and other media files?" --Maggie Dennis (WMF) (talk) 14:18, 15 June 2013 (UTC)
Just tested visual editor for the first time. I like the idea but it definitely needs more work (especially on things like referencing). It did something weird with the image in this article too. Visual editor somehow doubled part of the code which then broke the image tag and the tag showed up as plain text on the page. This was funny, as I thought I didn't even go near the image tag on my edit. Seems scary that it can do a random thing like that. --Gemena (talk) 01:11, 18 June 2013 (UTC)
Holding delete key & edit summaries
When holding the delete key, one of 2 things happen:
A large amount of text is suddenly deleted with no warning, with no "deletion scrolling animation" at all, so you can't see how much you are deleting
the delete scrolling animation is slow and laggy, and after a second or 2 just stops deleting text.
To use the delete key, you need to rapidly tap it, which seems to work normally.
The old editing window had optional add ons that could be enabled like having 2 drop-down menus of common edit summaries. These would definitely be good to include in VE, not sure if you guys are already on to that. Thanks, please keep up the good work, Lesion (talk) 09:13, 15 June 2013 (UTC)
Hi. :) Thanks for testing it out and reporting your thoughts. I haven't been able to replicate the deletion issue - is this a problem you're still seeing? --Maggie Dennis (WMF) (talk) 13:46, 17 June 2013 (UTC)
Use of templates within the beta Visual Editor is not intuitive, and "help" was not easy to find
The use of templates within the beta Visual Editor is not intuitive, at least to me, and I could not easily locate help.
I just made my first use of the VE, both attempts to add simple {{citation needed}} templates did not go as planned: when I reviewed the edit, both the article improvement tag, and the sentence it followed, seemed to be enclosed inside nowiki ... /nowiki syntax. So I didn't save the edit, and have gone back to standard editing in my preferences. Cheers. N2e (talk) 18:25, 15 June 2013 (UTC)
tried to edit by adding [[Japanese people|Japanese]] correct link in passengers and it came out as plain text every time. At the moment I will go back to the old ways. Also i could not find the wiki markups that were always handy. Thanks Edmund Patrick – confer19:14, 15 June 2013 (UTC)
I'm glad you sorted out the original problem and understand reluctance to move to the system while it can't yet handle what you need. I hope that as functionality rapidly improves, it will come to serve you better. :) --Maggie Dennis (WMF) (talk) 13:15, 17 June 2013 (UTC)
Sorry to keep posting here, but I couldn't sleep last night and was thinking about VE :/
A lot of editors are complaining that their trusty [[ ]] and {{ }} syntaxes aren't working. I think it is unlikely that users (newbie or otherwise) will often need to actually enter double brackets into article content, so how about a sort of "autocorrect" mechanism for these syntaxes to ease the transition to VE? Upon pressing the spacebar, [[new york]] turns into new york, [[new york city|new york]] into new york, etc...
Here's an interesting point: I understand the citation editor will be rolled out very soon. However, the vast majority of our articles use templates inside the ref tags. If these citation templates cannot be edited via VE when the beta is launched in July, VE will most likely be met with ridicule from within the community. There are a few solutions:
Allow editing of the wikitext within the ref tags (i.e. show an old-style source editor within the "reference" dialog) until template editing is supported
Quickly develop a simple template editor for the {{cite book}}, {{cite web}} etc. family, as this would allow editing of most references in most articles
Maybe the template editor will be ready by July (but I don't believe this is so)
Actualy no. There is a wide gap between the editing styles used in different areas. In Bancroft Shed a recent DYK which is a work in progress- the references are all {{sfn}} and {{efn}}. The References subsection is a c&p from a similar article. All new items to the bibliography are added to my user page using c&p or the {{cite book}}- tested then introduced into the article by c&p.The edit history will show how this article developed. VE needs to be rock solid on edits like this, and each edit by a newbie no matter how wierd must not damage the existing text structure. I can see it is a nightmare trying to cater for areas where you no personal experience. There are standard large scale system testing methodologies used in the industry which could be employed- but I would see it valuable if a small group could get together to document the proposed testing procedures and work on a checklist. -- Clem Rutter (talk)08:44, 16 June 2013 (UTC)
@Okeyes (WMF):: These aren't actually bug reports - that's why I was apologising! The first one is saying that, if you look through many of the comments on this page (in some cases you need to read between the lines), you will see that people are trying to create a wikilink in VisualEditor using [[ ]] wikitext syntax. I am suggesting that, to accommodate these users, a sort of autocorrect be implemented, so that when [[ ]] links are entered, they are automagically converted into proper VE-style links.
The second one is just me worrying about the editing of citation templates in references from VE. I think I'm right to worry about this, but I would be pleased if you could either allay or confirm my fears. — This, that and the other (talk)11:04, 17 June 2013 (UTC)
@This, that and the other: I think you're right to worry insofar as it keeps us on our toes :). As said in a couple of places (more standardised documentation is coming, but I keep getting distracted by, ah. Bug reports ;p.) we've got a list of bugs that'd preclude any A/B test, and proper reference support is on there, internal template or no internal template. If you look here you should be able to play around with and test the new template editor, actually; I'm hoping it gets deployed to enwiki soon-ish, because I'm somewhat uncomfortable with launching with something that hasn't gone fully through the wringer.
On the autoconversion front; that is something I can stick in bugzilla, if it isn't in already, but it sounds pretty complex (speaking as a relative luddite). I can't promise it any time soon, but it's certainly an idea worth investigating - although it may be that deploying without it precludes needing it, since muscle memory will correct. I'll throw it in and we'll see what happens :).
VE enabled June 18 by default for half of new accounts
"Starting on June 18, VisualEditor will be randomly enabled by default for half of newly created accounts on the English Wikipedia to test stability, performance and features."
I think this is a bad idea. The VE team is already getting a lot of feedback from editors who opt in voluntarily (via preferences) to try out VE.
This could cause a lot of new editors to quit editing Wikipedia due to the many bugs, and due to the many reverts they are likely to receive. Also, many new editors started out as anonymous editors, and are somewhat familiar with wikitext source editing.
Unless "edit source" links are returned to article sections many editors will be clueless as to how to use what they know works. So they will do the logical thing and quit editing for awhile or permanently (since many people drift to the latest thing that interests them). --Timeshifter (talk) 02:58, 17 June 2013 (UTC)
Do you have a citation for "Also, many new editors..."? There's been a watchlist notice about this A/B test for some time, although I'm just about to start more actively screaming from the rooftops. Personally, I agree there's potential for it to go terribly wrong; the community people assigned to the VE are communicating very actively with the developers and explaining what bugs are 'blockers' - in other words, what existing issues need to be fixed before we feel comfortable deploying for an A/B test. Hopefully they'll all get fixed prior to any launch, whether that's on Tuesday or later. If they are, we launch, and something goes wrong, we have the ability to turn it off in an instance, and will be closely monitoring the situation.
The primary purpose of the test isn't actually to get feedback on bugs; I agree that we've got a lot of feedback (and a lot of bug reports) already that we can run off, and frankly if our goal was gathering bug reports we wouldn't bother with the test - the primary vector to give those bug reports is via wikitext anyway (i.e. talkpages) - and experienced users are far more adept and comfortable using them, and are doing a damn good job reporting issues thus far. The goal is simply this; when we launch the VE for all new users, and say 'this is your default editor now', we're going to (hopefully!) have a piece of software that dramatically increases the likelihood of people completing an edit, and people staying around. That's going to stress a lot of the project's community workflows - we're, as volunteers, used to the current level of conversion between reader and editor, and used to the current volume of users. Our processes aren't set up for 2,000 new people flooding in a week, let alone a day. Now, I don't think 2,000 a day (or a week, really) is plausible, but there will be some increase. The purpose of this test is to get an approximation of what the increase would be, so that, when we make the go/no go on a final launch, we can go in with information about what the likely impact on the community is. We don't want new editors to quit editing Wikipedia due to the many bugs or reverts, but we also don't want them to quit because we've overwhelmed the community and it's hitting out. One lasts a week, the other potentially far longer. Okeyes (WMF) (talk) 10:13, 17 June 2013 (UTC)
I do not know what percentage of newly-registered users have already done some anonymous editing. That is an important question. From what I read here and there it seems to be a lot. If I am correct, then this A/B test may not give accurate results. That is another reason to wait awhile. At least wait until there are "edit source" links on every section. That is being worked on now.
When that is finished, then I think this A/B test will get more accurate results. Because half of new editors will actually be able to easily use both methods of editing. The other half will only be able to use the source editor. So we will get a better idea how much a visual editor will help in keeping new editors editing. I am assuming there won't be too many reversions due to bugs in VE. So we have to get the major bugs fixed. Or at least the bugs that cause regular editors to quickly revert new editors. --Timeshifter (talk) 11:02, 17 June 2013 (UTC)
Totally agreed; that kind of bugfixing is the priority at the moment. On the anonymous editing front, we don't actually know - if you've got any research on the subject that you've found I'd love to see it, because it's new to me. I know we did some (limited) work last year as part of the AFT5 research, but it didn't include a large number of users and I'm not sure if we tested anonymous -> registered conversion. Okeyes (WMF) (talk) 11:05, 17 June 2013 (UTC)
On Mac/Chrome/Version 27.0.1453.110, this puts a thin rectangle with a small icon, looking like a missing image, roughly centered left-right on the page, starting about the first line of the lede and continuing down to about the fifth line of the first paragraph of the Biography. The text does not flow around the box, but ignores it. In Safari 6.0.5 (8536.30.1), there's no box, but there is an abonormally wide area after "Help" but before the close parenthesis, more or less:
Hermann Müller (help ) (18 May 1876 – 20 March 1931),
When I open this in Visual Editor, I get a link symbol pop-up, and I have no idea why. Reproduced on Chrome and Safari. --j⚛e deckertalk04:33, 17 June 2013 (UTC)
Scroll to the lawsuit section, note the replication of the link to Title IX just under the portrait. Reproduces under Chrome and Safari. --j⚛e deckertalk04:37, 17 June 2013 (UTC)
there is no corresponding defense in English law.[2][contradictory]
In Visual Editor, it reads:
there is no corresponding defense in English law.[2][<span title="This text contradicts text in the article "Necessity in English law" (3 May 2011)">contradictory]
Well, the wikitext source for [contradictory] is a template, {{Contradict-inline|article=Necessity in English law|date=3 May 2011}}, and VE isn't suposed to cope with templates yet. JohnCD (talk) 10:19, 17 June 2013 (UTC)
The image formatting should be fixed (it's a known); the template messing-up looks like another instance of what you reported earlier - links being handled wrongly. I'll throw it in as an example :). Okeyes (WMF) (talk) 11:54, 17 June 2013 (UTC)
The first three discography tables, but not the last of the four, have something strange going on in the ruling at the bottom of the tables. Chrome and Safari. --j⚛e deckertalk05:07, 17 June 2013 (UTC)
Sorry for being cryptic. Here is my revision [7]. With "125 px" as parameter, the infobox image appeared full size when using Visual Editor. With "125px", everything works like a charm. (using Firefox Nightly 24.0a1 (2013-06-16)) --Alberto Fernández Fernández (talk) 12:59, 17 June 2013 (UTC)
Shouldn't VE only be made the default AFTER all bugs have been removed AND everything that can currently be done in the normal editor can also be done in VE? Wikipedia:VisualEditor/FAQ says VE is supposed to be turned on by July 2013. How can VE be bug-free until then if this is true? -- ToshioYamaguchi11:44, 17 June 2013 (UTC)
If you're looking for software that is shipped with zero bugs, you're not going to like...well, anything any software developer on the planet produces. Any development firm, or development department, will tell you that things always have bugs; this is inevitable. Our priority is to make sure that there aren't any critical bugs by launch - things that render it very difficult or impossible to edit, or things that actively break pages. If we come up to the proposed deployment date and that hasn't been done, we'll discuss it; the community-facing staffers talk regularly with the developers, and if we see a bug that is a blocker, we'll make that known. Ultimately we retain the ability to disable the VE in a heartbeat if something goes seriously wrong. Okeyes (WMF) (talk) 12:11, 17 June 2013 (UTC)
Not always, but certainly for the foreseeable future (I feel leery making proclamations that something will "always" be around). Okeyes (WMF) (talk) 14:03, 17 June 2013 (UTC)
That was my impression from developers lately in bugzilla threads. Some of them seem to feel as strongly about this as I do. On Wikia the wishful thinking about the visual editor still exists, but I believe that some of the developers on Mediawiki bugzilla see why "edit source" links may always be necessary for article sections. Including for users with VE enabled. --Timeshifter (talk) 14:21, 17 June 2013 (UTC)
Indeed, although I think in future we'd want to move away from the current model; this does not mean not having "edit source", but I more mean things like integrating the source editor into the visualeditor, a la wordpress, so that changes can be easily saved between the two. Okeyes (WMF) (talk) 14:24, 17 June 2013 (UTC)
Guh; sorry, evidently I brainfarted above :). I mean there will (for the forseeable future) be an "edit source" link. I can't speak of source-editing section links in addition to VE-editing section links, which is a proposed, rather than decided, feature. Okeyes (WMF) (talk) 18:26, 17 June 2013 (UTC)
OK, as a vehement supporter of VE and the VE team, I'm going to put this out there. You better watch it extremely, extremely closely during that A/B test. Even I feel that with the amount of reports that have trickled in over the past two weeks, going for an A/B test right now seems overly optimistic and basically setting the foundation up for getting their heads bashed in by this community. I fear this is not going to end well and that would be a shame. I'm not asking for something bug free, I don't care what it says about this community, nor do I care about performance numbers and deadlines of the foundation, I just want it to not end badly. —TheDJ (talk • contribs) 19:25, 17 June 2013 (UTC)
I wont be testing anymore. It's not intuitive. It doesnt work. It uses a diff paradigm. I'm happy with what I have. Atlas-maker (talk) 13:52, 17 June 2013 (UTC)
@User:Atlas-maker Diff paradigm? Can you point to specific issues with it being non-intuitive and not-working? I'm sorry to see you switch away from it, but there's not much we can do to solve for the problems without specific feedback. Okeyes (WMF) (talk) 14:01, 17 June 2013 (UTC)
After clicking Edit the page scrolls up losing focus of the section I meant to edit.
After adding a wiki-link to a word or string of words I have to close the pop-up dialog by clicking on an arrow pointing left. What is the rationale behind this? Why not a simple X or a Done or Save button? Hadn't it been for the mouse over text that said "Close" I wouldn't have had a clue as to what that arrow was supposed to do and how I should save the changes. This is terribly counter-intuitive and should be fixed.
No Edit source switch for sections? If I want to edit a section using the old source editor I'm forced to select Edit source for the whole article. Am I missing something here?
Can't edit/add sources, mathematical symbols, etc, but you obviously are aware of this already.
Good job but still needs quite some work done. Also, I've seen this mentioned somewhere but I have to comment on it: is it wise to release a tool to make editing faster/easier without the feature of adding sources? This seems like asking for trouble. Cheers. Gaba(talk)20:22, 17 June 2013 (UTC)
Rather than write my own section.. I was coming to this page to express my frustration at points 1, 3 & 4. Grr! I just want to edit a section without it going to the visual editor.. ツStacey (talk) 20:50, 17 June 2013 (UTC)
It would be nice if VE could accept simple wiki-mark up like brackets for links [8] or equals signs for section headers [9] without automatically inserting the nowiki tags. It would make for a smoother transition for experienced editors IMO. ~Adjwilley (talk)20:23, 17 June 2013 (UTC)
How to add references?
In visual editor mode, the page currently renders the refs as numbers but there's no way to change the refs - for example to change the page number. Hovering the cursor over gives a cannot edit symbol; hovering the cursor over the refs section gives the same symbol. How are we to verify the material we write? Victoria (talk) 20:42, 17 June 2013 (UTC)
(I'm not sure, but I believe: The main Mediawiki release is now getting updated weekly, on Thursdays. But extensions (listed at Special:Version) can be updated and toggled on/off at any time the devs want. –Quiddity (talk) 02:57, 18 June 2013 (UTC)
I think the visual editor should display any <!-- internal comments --> the article contains. Many of these comments are designed to prevent the repetition of erroneous edits before they occur and their omission in the VE view neglects this purpose. :)John Cline (talk) 22:45, 17 June 2013 (UTC)
I just tried some editing of templates at mw:VisualEditor:Template_test, and I have some feedback, with the most important at the top.
It doesn't appear that I can actually edit templates at that test page, as the changes never propagate after clicking "Apply Changes" and the inspector cannot be brought up again on any template. The reference insertion tool also doesn't act and hangs after an attempt. I can edit plain text.
Could the inspector pop-up be able to be moved on screen, like the citation tools on Reftoolbar2.0? It's annoying when you can't see what you are editing underneath.
Closing the inspector jumps me to the top of the page, which I don't think it should do, especially if I haven't changed anything.
(Minor) Informative tooltips, not <visualeditor-dialogbutton-template-tooltip> (probably in the works, I assume).
The VE is so not ready for prime time. My #1 request at his point is for an easy "toggle" to toggle over to "edit source", similar to the way most visual editors for html let you toggle easily between visual and html code editing mode. Meclee (talk) 23:28, 17 June 2013 (UTC) I should probably clarify that, by "easy way to toggle", I don't simply mean a button or tab. As it stands, if I'm in Wikitext mode and have made Wiki mark-up changes, I cannot simply toggle over to VE because VE cannot handle the WMU changes made. I'm not a developer, but perhaps the "toggle" should "save" the changes before switching? Meclee (talk) 23:43, 17 June 2013 (UTC)
That is, I believe, the long-term plan - to have a source editor within the VE, so that you can toggle between the two (a la wordpress), but the impression that I get is that it's not a small engineering challenge. Okeyes (WMF) (talk) 05:16, 18 June 2013 (UTC)
Visual editor appears to have screwed the article contribution history and my editing history
I supposedly made this edit [10], except I did NOT make all those changes, and in fact did not change any citations. Perhaps there was an edit conflict or something. But that seems like a significant "bug". Alanscottwalker (talk) 01:17, 18 June 2013 (UTC)
This was a regression introduced recently in Parsoid (See T51655). New code deployed today which fixed this bug. Thanks for your patience while we work through the bugs. Ssastry (talk) 04:09, 18 June 2013 (UTC)
Suggestion to resolve section editing problems
Just a thought: would it not be possible to have the visual editor detect whether changes had only been made to a particular section, and if this was the case, to treat the edit as an edit to that section (including appropriate notations on the diff, as at present, e.g. -->History)?
This would circumvent most edit conflicts, enable editors to see quickly what areas had been changed by an edit, and possibly speed up the saves. I can't see any disadvantages to implementing this. hgilbert (talk) 01:42, 18 June 2013 (UTC)
That's been raised, and seems like a good idea to me, but I'd note that really the bug that needs to be solve is "there isn't a VE section edit mode". The actual problem - of multiple edits to different sections - is something that I understood had been resolved in source editing quite a while ago. Okeyes (WMF) (talk) 05:13, 18 June 2013 (UTC)
Three Two of the eight most recent edits using VisualEditor [11][12][13] have attempted to use wiki syntax in VisualEditor. The wikilink syntax issue is bugzilla:49686, but the use of apostrophes is probably more an issue of community education than compensating with software features. If people try to use VE this way, they will get a negative impression that VE "doesn't work", because it is not doing what they expect it to do.
That is interesting. I would think any solution is better than the nowiki tags that are being added in VE in order to stop the wikitext from working in the source editor. Maybe a warning in VE on preview or saving saying that wikitext was inserted, and won't work. So people may then try to use VE correctly. It would lessen the amount of nowiki tags being added by VE. --Timeshifter (talk) 03:40, 18 June 2013 (UTC)
Changing image captions should not be any harder than changing other kinds of text. Why is it not possible? Also, while it's probably going to be impossible to edit templates visually, it should be possible to remove them, as well as images.eh bien mon prince (talk) 05:35, 12 June 2013 (UTC)
It's got a template editor on MediaWiki.org; looks like it hasn't been deployed here yet - ditto for image modification. I'd advocate going over there and playing around with it just in case there are any bugs that haven't been noticed :). Okeyes (WMF) (talk) 17:47, 12 June 2013 (UTC)
OpenOffice is a large and complicated page, with hundreds of references. In normal wikitext editing, it takes thirty seconds or more to just save and re-render the page. So I just tried doing a pile of text edits with the VE ... and it timed out. The error: "Error saving data to server: timeout." It did this both when I asked for a preview and when I went ahead and hit "save" anyway. Needless to say, this needs never to happen.
(Also, odd thing: I tried typing the summary ... and couldn't backspace or edit what I'd typed in any way, just type more. This was after the first server timeout.) - David Gerard (talk) 08:30, 16 June 2013 (UTC)
OK, looks like the edit was saved ... You have a look through that diff, and see all the ways the VE crapped over the article - gratuitous nowiki, mangled references, gratuitous spacing changes and a weird mangling around line 780. Lots of bugs for you! - David Gerard (talk) 08:38, 16 June 2013 (UTC)
Lots of gratuitousness from my test, too - it did save, without a timeout issue, but took about 15 seconds to render either the 'review changes' diff or actually save. I'll have a word. Okeyes (WMF) (talk) 11:14, 17 June 2013 (UTC)
8 MBit ADSL1. Generally runs at full speed (700kB/sec or more) - apparently it's good for quite fast ADSL2, but I have an old DSL modem - David Gerard (talk) 12:57, 18 June 2013 (UTC)
Just tried again and the "review your changes" diff was clean. Thank you! This time around, the review step didn't time out, but the save step did (with "Error saving data to server: timeout.") and failed to actually save; same a second and third time, so I don't actually have a clean diff to show you, sorry - David Gerard (talk) 12:57, 18 June 2013 (UTC)
The end of the article, in the Visual Editor, reads:
* Official Biography at Griffin|Schein
* Chad Griffin на сайті Internet Movie Database (англ.)
Шаблон:S-start↵Шаблон:S-npo
Попередник:
{{{попередник}}} ↵{{{титул}}}
Шаблон:S-inc
Шаблон:LGBT
Шаблон:Use mdy dates
And another: The french word for template or module is put in place of the word Template twice at In re Estate of Gardiner, once near the top, once at the bottom, e.g., "Modèle:Infobox Kansas Supreme Court case" --j⚛e deckertalk05:19, 17 June 2013 (UTC)
There is likely a software entity representing templates, when reconverted to a textual form, they are sometimes being treated as if they are in another language. Why Russian, Vietnamese and French respectively? No idea. The last case doesn't have any interwikis. Maybe an unset variable. --j⚛e deckertalk05:20, 17 June 2013 (UTC)
Okay, this is...an excellent bug. I've now posted it with the note of "I have absolutely no idea what's happening" :P. Thanks for the report! Okeyes (WMF) (talk) 11:34, 17 June 2013 (UTC)
After the word Hinterland, VE displays a ↵ symbol (not unlike that found on some Enter/Return keys) following the word "hinterland." Both Chrome and Safari. --j⚛e deckertalk04:31, 17 June 2013 (UTC)
You do really great bug reporting. :) Thanks for the clarity and detail. I'm not actually sure that's a bug, though. Looking at the code, it seems like it indicates that there is a line return there that will not establish a new paragraph. It's markup in the source that does not impact display - at least, that's true of Miss South Africa. --Maggie Dennis (WMF) (talk) 12:44, 17 June 2013 (UTC)
The new visual editor gives not the least indication (that I could find) how to insert/edit references, this is a huge missing, since it actually makes it a lot harder to insert references for new editors (i.e. those that don't know how) and will further stratify between knowledgeable and new editors as all new editors stand a big chance of their efforts being reverted due to lack of references and having no way to find out how to do referencing.
For me there is no way a new editor should be introduced that makes an already difficult and archaic task, yet a required task, basically impossible, there is no way I could support the new editor whilst this gaping hole in functionality exists. And if the functionality does exist (I would hope it does) it needs to be obvious and simple and easy to use. Jasonfward (talk) 21:27, 17 June 2013 (UTC)
Then don't foist broken stuff on new users (the go live for 50% of new users is a very few short hours away) fix it BEFORE turning new editors into despondent editors because all their work got reverted. Jasonfward (talk) 21:38, 17 June 2013 (UTC)
Seriously. Has WMF never heard of the software development lifecycle? Sorry if that was a bit harsh, but I'm incredulous you're rolling this out live with a key feature no user has seen before, let alone tested, to meet some arbitrary deadline. I know you've said you can turn this off easily if it causes problems but is WMF going to be cleaning up the problems? My clients would fire me if we rolled out a major feature without any beta testing and then said, "Oops! Sorry! Looks like you'll have to fix the mess we caused," when the inevitable bugs popped up. Why not have experienced volunteers test this new code first? --NeilNtalk to me00:33, 18 June 2013 (UTC)
OK, that was annoying. The inability to modify citations, for example, is a deal killer. Speed...feels like I went back to pre-Pentium days. I have quickly disabled this, and am glad it will continue to be an option one can disable. I can't imagine when I would ever use it, unless it got some really smooth table creating and editing features. That's the one thing I dislike doing in the present editor.
Positives: I'm sure it will be easier for the casual user (as long as that casual user has lots of time on her hands). hgilbert (talk) 21:51, 17 June 2013 (UTC)
I share almost the same feelings: citations and speed are dead killers, while tables is a great feature. The VE is supposed to save time and effort, not waste it. Mohamed CJ(talk)09:26, 18 June 2013 (UTC)
Causes irreversible edit
Hi. This was my first experience with VisualEditor. I was editing Microsoft OneNote when I somehow caused the infobox to move below the lead. I noticed too late, when reverting it via undo button was too costly and time-taking and putting it back manually was impossible.
I tried copying the diff of my changes so that I could re-apply them in Source Editor... only to discover that it is impossible to select or copy diff text.
I tried editing User:Faizan/Guestbook by simply adding a new line and my signature, but lucky I clicked review changes: VisualEditor was tampering with other user's signatures! It didn't seem to like links that were multi-coloured, and was instead changing them to a single colour. WHY? -- (T) Numbermaniac (C)08:17, 18 June 2013 (UTC)
From what I can tell the visual editor edits template text poorly, and does not edit the formatting at all. I am not sure if VE can, or will be able to, edit transcluded templates at all. At least not where the transcluded template is used in a section of an article. This is important for updating navigation boxes used in multiple articles, for example.
So we need quick access to a list of transcluded templates used in that section of the article. So we can click on a template link and edit that template. The source editor for a section does not immediately show a list of transcluded templates in that section.
I had no idea until yesterday that a list of templates used in a section existed. I knew only of the full page list of templates that shows up at the bottom of the page when you click the edit (source) link at the top of the page.
But I now know that a preview of a section edit in the source editor shows a list of transcluded templates used in the section. Just hitting the "edit source" link for a section does not show this list of templates.
That needs to change. We need to see that list of transcluded templates right away after clicking the "edit source" link for a section.
To see what I am talking about hit the edit source link for this section. You will not see any template links after the edit window. Then click the "show preview" button. You will now see the Bugzilla tracking template linked after the edit window under "view templates". --Timeshifter (talk) 10:04, 18 June 2013 (UTC)
Have you tried the template editor on mediawiki.org, then? It seems to be displaying transcluded templates fine to me. Okeyes (WMF) (talk) 16:50, 18 June 2013 (UTC)
I was thinking this, too. Submitted as Bugzilla:49772. It's not a full list of "every template in this (page/section) being edited" (which I'm guessing would be technically hard, particularly a section-specific list), but it will enable easier access to each visible template. –Quiddity (talk) 21:03, 18 June 2013 (UTC)
(unindent). Here is a page that has a table and a couple transcluded navigation-box templates at the bottom:
But with VE the existing text in the 2 navigation boxes can not be edited as far as I can tell. At least not within VE from that page. I am talking about after clicking the edit icons for the navigation boxes. New parameters can be added to one of the templates, but I don't see a way to edit the text for existing parameters in either navigation box. So those are examples of transcluded templates that would need links in "view templates" when section editing in source mode.
Quiddidy's idea would also help. That is if it provided a direct link to the transcluded template page, and not to the core templates that make up the navigation box at the core level. --Timeshifter (talk) 05:24, 19 June 2013 (UTC)
I couldn't remember if this had been brought up already, but when you enter editing mode on a page with redlinks they all suddenly turn blue. It kind of defeats the purpose of a WYSIWYG editor if the page renders differently in editing mode. –Thatotherperson (talk/contribs) 09:51, 18 June 2013 (UTC)
Thank you for reporting. It has been, but better safe than sorry. I've added the tracking number in case you'd like to keep an eye on its progress. :) --Maggie Dennis (WMF) (talk) 12:02, 18 June 2013 (UTC)
Made a minor change to the lead, and an image caption disappeared. [14]
The image sizes are all wrong on the edit view; tried to resize the lead image and it didn't work. I got a number of error boxes when trying to save, but the save had been committed.
Changed some italics to normal text, something strange has happened here [15]
I tried to place an image. The UI really wasn't intuative, but perhaps thickening the line around the selected image would be an improved. The result, however, was a bit of a mess.
Huh! Thanks for these; I'll go through them :). I appreciate that reporting bugs is a relatively thankless task, most of the time, but I find it tremendously helpful, and am very grateful that so many editors are willing to kick the VE in so many places :D. Thanks for all your hard work! Okeyes (WMF) (talk) 18:44, 18 June 2013 (UTC)
I like the new Visual Editor, but I think it could be useful to allow some "hybrid" writing. For example, I'd like to be able to write ==Title== and let the editor to autotransform in a title. I know it is possible to click in the button, but I think productivity would be increased if it is possible to work only with the keyboard. --FAR (talk) 13:34, 25 April 2013 (UTC)
@FAR: Thank you for your idea. However, the intent for VisualEditor is to create an editor for people that doesn't require them to know wikitext. This covers them not needing to know it for either using wikitext deliberately, or for accidentally using it. We don't want users to create some text like "== foo ==" or "''hello''" and have them surprised at the results - it would be very confusing, and would ultimately mean that every new user would have to learn wikitext anyway, which goes against our objective. Jdforrester (WMF) (talk) 22:50, 11 May 2013 (UTC)
@Panpog1: Do you mean that you could select an item and edit it as wikitext? This is something we've considered but would need a great deal of work on the back-end (similar to section editing). Jdforrester (WMF) (talk) 08:37, 24 May 2013 (UTC)
@Jdforrester: I think @Panpog1: meant that in user preferences there would be options for the editor to interpret wikitext. So for in the above example "==Title==" Would appear like that by default but if you enabled 'titles wikitext' the editor would recognise it and display it as a heading. This would mean that by default users would need to know no wikitext but for more advanced users wanting to use it to be more productive that option is there too. Moohan (talk) 15:49, 9 June 2013 (UTC)
@Jdforrester: I think it would be more pleasing to experienced editors who want to use VisualEditor to have an option on the template for adding references. An "Add a Citation" button with all the fields to fill in shouldn't be hard for new users to understand. I think many will use it. Teammmtalk email23:35, 9 June 2013 (UTC)
This is also my first impression. I was curious about how many times the text string "===" occurs in Wikipedia articles (as normal text, not as a section header). So I searched for that and got this error: An error has occurred while searching: The search backend returned an error: -- Wbm1058 (talk) 17:58, 19 June 2013 (UTC)
The premise above was that a novice might type "==" at the beginning of a line and be surprised at the system's response. My theory is that the odds of that happening are extremely low. However, I was unable to do any research to prove my theory right or wrong. On the other hand, it's not unusual for me to accidentally stumble on some browser button or shortcut and be totally surprised at the result, having no clue about what I did to get the undesired result or how to undo it. (that last comment is not at all about VE specifically, but rather about "visual" interfaces in general.) Wbm1058 (talk) 18:31, 19 June 2013 (UTC)
In the existing editor when I start typing in the edit summary field it will prompt me with various edit summaries that I've used before. This often saves the majority of key depressions needed for one typo fix. Visual editor doesn't do this, is that intentional? If so it is a pain. ϢereSpielChequers05:36, 15 May 2013 (UTC)
The problem here is that we are now using a multiline textarea, rather than a single line textbox. The auto-completion you are currently seeing is provided by the browser and only for single line textboxes. In order to bring it back we'd need to implement our own auto-complete. ESanders (WMF) (talk) 15:09, 18 May 2013 (UTC)
Or return to a single line textbox. VisualEditor is all about making the editing experience better, this aspect doesn't contribute to that goal.SchreiberBike (talk) 19:24, 18 May 2013 (UTC)
I have to agree, and it's not the first time this point has been mentioned. The auto complete history of edit summary fields is a much enjoyed aspect of the edit page for many editors. —TheDJ (talk • contribs) 20:25, 18 May 2013 (UTC)
Thanks for the response, I can appreciate that it would be possible to deploy without this fix, but with so many bugs to work on it would be nice to see this sneaked into this version - you could probably attribute it to popular demand. If we do have to wait for v2 can we at least have assurance that there is budget for this sort of thing? ϢereSpielChequers19:30, 28 May 2013 (UTC)
As you say, 'with so many bugs to work on'. I can't speak for the VE team, but I assume they're prioritising things that are actively broken over things that work but could be improved. Okeyes (WMF) (talk) 09:51, 14 June 2013 (UTC)
Just wondering what the point of a multiline textarea for edit summaries is when the current limit for edit summaries is very short. I frequently run into it and then have to work on condensing my summary to fit. Are editors able to "write an essay" in VE only to find that the lower-level software truncates it, or are there plans to allow longer summaries? Wbm1058 (talk) 18:48, 19 June 2013 (UTC)
I've stopped testing for now - it has simply slowed to the point where I can't take part, but I figure testers are not in short supply considering how many open issues I and others have on this page. I reverted to the old editor for this after it had hung for several minutes, the second edit in a row that happened to me. Normally when fixing minor typos I would be averaging one a minute so a 7 minute gap looks like a 6 minute overhead and feels like far more. ϢereSpielChequers14:33, 25 May 2013 (UTC)
It's been variable for me, but it does seem to want a fast connection and appears to have had little developer testing outside well-connected US cities (an endemic problem with recent WMF dev work). Imagine a world in which every single human being can freely share in the sum of all knowledge as long as they live in San Francisco - David Gerard (talk) 10:31, 7 June 2013 (UTC)
This is an issue that has previously been discussed at the main page redesign proposal feedback. Should we really introduce features that require fast internet connections and brand new computers, when most of the world (me included) doesn't have access to one or both of those things? Manxruler (talk) 20:48, 8 June 2013 (UTC)
I just tried it and it was very slow for me. As there appear to be enough testers, I will unlikely be involved in testing at this stage, and will wait until speed (and functionality) is improved. My impression at the moment is that the functionality is so limited that only simple copy-editing is possible - adding content (which requires adding cites) doesn't seem feasible, and - for me at least - much of the page is not editable (can't access references or images for example). SilkTork✔Tea time21:34, 9 June 2013 (UTC)
Yeech :(. Same problem at this end - Firefox 21 - although on general principle I would advise switching to Firefox/Chrome, or at least updating IE. It won't help with this issue but there are others it will solve for. Okeyes (WMF) (talk) 09:15, 19 June 2013 (UTC)
That makes sense. We're adding a reference editor in a tick; we were going to deploy it today, but fell behind on one element of it and didn't want to deploy it broken. We do now have template editing generally, however! Okeyes (WMF) (talk) 09:56, 19 June 2013 (UTC)
How to opt out?
Okay. Just a quick and hopefully easy question: How do I opt out of all this? I do not want to spend my time learning this new system when I've done perfectly well with the old one for the last almost eight years. Manxruler (talk) 18:55, 8 June 2013 (UTC)
Thanks. Those are almost exactly my concerns. I'll turn it off once it becomes default. I'd rather not have days, or weeks, of disruption of my editing, to fix something that isn't actually broken. Manxruler (talk) 19:48, 8 June 2013 (UTC)
The FAQ does not say anything about: what if an anonymous (not logged in) editor wants to turn it off. For instance (as discussed earlier here) this editor is unusable for mathematics articles. Is it going to be possible to attract new anonymous editors to help edit those articles, or are they going to be shut out (permanently preventing us from attracting new editors in this area)? —David Eppstein (talk) 20:34, 8 June 2013 (UTC)
First, I believe that when it goes live for "all" of us, that it's not going live for the IPs. That is scheduled for a later date. But even when it does, I believe that anyone will be able to get to the "edit source" tab easily, at least for months to come, because there are things that cannot be done in VE yet, like editing math equations. WhatamIdoing (talk) 01:06, 9 June 2013 (UTC)
Thanks to the original poster for bringing this up. I'll probably access the 'old' version for as long as it is available...took me forever to "get" the old editing system, don't look forward to having to learn a new one. And forgive me if this has been asked before on this page, but is a "Plain & Simple 'Visual Editor' Tutorial" available? Thanks, Shearonink (talk) 14:17, 10 June 2013 (UTC)
As dumb as it may be, that is something that came to my mind as well. I, too, have spent countless hours on learning the current system and I am proud of being experienced with most stuff of the current system. Don't get me wrong, I am not saying that Visual Editor cannot be better at some point than the current system (hopefully it will be). It's also not meant to say everything is perfect the way it is or that nothing should be changed, but it is something that should be kept in mind. Think of the seniors, masters and grandmasters as well. Hopefully everyone will be satisfied in the end. -- ToshioYamaguchi12:40, 18 June 2013 (UTC)
You are not going to be forced into it. You always have the option of clicking [Edit source] instead of the plain [Edit] tab.
VisualEditor is struggling with {{sfn}}. You're definitely not the first person to report this problem, although I don't know what the Bugzilla number is for it. WhatamIdoing (talk) 04:46, 14 June 2013 (UTC)
First, there should be an "edit source" link for each section. Second, new editors will likely click "edit" (leading to VE) rather than "edit source", because they will not know what "source" means and so will think it's some special type of editing. Finally, the adequacy of "edit source" is irrelevant. VE should not be mainstreamed until it can be used reliably. SMP0328. (talk) 05:09, 14 June 2013 (UTC)
SFN tags are not actually that common. I agree that work needs to be done, and it is being done, and it won't be done any faster if you make proclamations to WhatamIdoing ;p. Okeyes (WMF) (talk) 10:33, 14 June 2013 (UTC)
Okeyes, you're absolutely correct, they're quite rare actually. Transclusions of {{sfn}} + {{sfnp}} combined account for a measly 16,312 articles, or 0.4% of the total count. Shouldn't that qualify them for "Endangered Template" status or something? But seriously though, at first impression, that hardly sounds like something to lose sleep over (as I did last night) – until we realize after looking at the list of articles that they tend to be meaty, scholarly articles – you know, Featured Articles, Wikipedia's highest-value assets. And having just framed it in that light, I've changed my mind: I'd vote for the alternative temporary solution suggested above: that is, to disallow VisEd from editing such articles for now. —Grollτech (talk) 11:37, 19 June 2013 (UTC)
Oh, I agree; see "work needs to be done, and it is being done". But there are very few VE-based edits being made, and very few VE-based editors, and all VE edits are easily identifiable via Special:RecentChanges. People should be checking the edits they make; as the interface makes clear, this is essentially an alpha. In my experience, most of the time people do - when they don't, we have recentchanges to identify them. There's no need to disallow VE edits on certain articles, which frankly sounds like a pain; I'd rather have the devs focus on solving the problem, personally. Okeyes (WMF) (talk) 11:46, 19 June 2013 (UTC)
Visual Editor not enabled in Opera
This is further to my earlier comments above. Using Opera 12.14 here. Last night I checked what VE looks like in Firefox, where it is working. But in Opera the new tabs for Edit and Edit Source do not appear after I enable VE in my preferences, the tab is still labelled Edit this Page, so clearly VE is not currently being enabled in Opera. I tried identifying as Firefox in my browser preferences but no change. There are some earlier comments in the bug reports indicating Opera was working once so guess they have disabled it again. Would be nice to have a statement about this. When VE goes live can we assume that we Opera users will continue to get the old configuration rather than a silly 'update your browser' message? (and by the way, the Chrome look alike version of Opera, Opera 15 currently in beta, will come out in due course. Because of many issues lots of us will continue using Opera 12 for a long time afterwards so this needs supporting as well). Dsergeant (talk) 05:55, 15 June 2013 (UTC)
@Dsergeant: I'm afraid not. See mw:VisualEditor/Target browser matrix, particularly the comments at the very bottom of the page. I used to be an avid Opera user, so I can commiserate with you. (I went back to Firefox because of Extensions that I needed.)
I would humbly suggest that anyone capable of finding and installing Opera, is much more likely to be a power-user that enjoys the hands-on-mechanics of source code! That's been my experience, anyway. (As a die-hard HTML-editing-in-gedit person...). HTH. –Quiddity (talk) 17:33, 19 June 2013 (UTC)
so... what is this supposed to look like?
Three times I've turned on VisualEditor over the last couple weeks, including just now, and three times I haven't seen any difference. Either I don't know what to look for, or this doesn't work for me. I'm on Firefox 16, although apparently I'm not supposed to be (it likes to warn me about that) because my OS is too old or something. Wasn't going to mention anything here but now it seems more and more people are actually getting to try this thing out. I agree with the user above, I would only want to use it if it actually made creating tables easier (I prefer to not have to rack my brains when creating something normal; nor do I want to memorize a bunch of code unless I was getting paid six figures to write code). But figured I'd mention here that VE does not seem to do much of anything for me. Edit buttons still appear in sections and editing still seems to be... like normal. Am I missing something here? Is there supposed to be some awesome looking screen? I wasn't able to find any screenshots around here to help me out. – Kerαunoςcopia◁galaxies22:37, 17 June 2013 (UTC)
Not an expert, but this is my take: There should be two tabs visible at the top: "Edit" and "Edit source". Clicking on edit will give you the visual editor. Clicking on "edit source", or any of the section edit links, will give you the traditional editor. hgilbert (talk) 01:30, 18 June 2013 (UTC)
Ok, thanks. I don't see "edit source", and "edit" only takes me to what "edit source" would take me anyway (the old/normal/standard editing form, I presume). Perhaps I should try this on a couple other browsers—maybe it's my firefox. – Kerαunoςcopia◁galaxies01:31, 18 June 2013 (UTC)
Nope, I tried OmniWeb and Safari, and even tried it after changing my visual preferences from Modern to the default, Vector. I don't see any tabs of any kind leading to anything remotely resembling anything different than regular panes. – Kerαunoςcopia◁galaxies01:40, 18 June 2013 (UTC)
I'm having a similar problem. Turned it on in preferences and saw the new version. Logged out, logged back in again and Visual Editor is gone. I've turned it on a couple of times in Preferences, reloaded the page, logged in and out, but nothing. So I'm happily editing with what we now have. Safari, btw. Victoria (talk) 01:48, 18 June 2013 (UTC)
I am using Firefox 21 in Windows 7. Maybe try other more popular browsers such as Internet Explorer or Chrome. I don't think VE is enabled for all browsers, nor for some old versions.
Enable VisualEditor (only in the main and user namespaces).
Use the wikitext editor for editing sections while VisualEditor is in beta.
If you don't want source editing of sections do not check "Use the wikitext editor for editing sections while VisualEditor is in beta". --Timeshifter (talk) 01:51, 18 June 2013 (UTC)
This is similar to what I have reported above in it not being enabled in Opera, but it is enabled correctly in Firefox 20.0. If VE is so buggy that it only works in the latest version of a few browsers it is very far from being in a state to go live. Dsergeant (talk) 06:05, 18 June 2013 (UTC)
@Dsergeant: As said below, it may be totally unrelated to the user's browser - and since the user's browser is five versions out of date, I don't think it's fair to describe it as only working on "the latest version". Firefox 16 is used by less than 0.3 percent of readers, let alone editors - and that data is months out of date. Okeyes (WMF) (talk) 06:09, 18 June 2013 (UTC)
Fair enough, but whatever the reason is it seems VE is not working for a significant number of editors and browsers. There has been no statement as to why this is from the team. Maybe there is a feature that some later browsers support that earlier ones do not and this should be clearly stated in the information given to us, ie 'browser requirements'. For what it is worth, Opera is used by 2-3% of internet users, it is far from insignificant. Personally I am quite happy that it does NOT work so long as the old editor continues to work as before. But since this is a specific page for VE feedback I would expect to see answers to these sorts of questions here. Dsergeant (talk) 10:57, 18 June 2013 (UTC)
New Safari bug
Thanks, I'm aware of how to choose it from preferences, and no we shouldn't have to change browsers to write here. The problem is that choosing it in preferences worked a few hours ago, and then it simply disappeared. So. Victoria (talk) 01:56, 18 June 2013 (UTC)
Yeah, I think it is. I re-tested and it's currently chosen from preferences, but gone. Safari 5.1.1, OS X 10.7.2, Macbook pro. I'm logging out now, but have an I-Mac w/ an earlier OS that I can test as well tomorrow. Victoria (talk) 02:22, 18 June 2013 (UTC)
It may not be a Safari bug, actually; sometimes ResourceLoader loads improper (and incomplete) JavaScript, and so it doesn't load. What happens if you add ?debug=true to the end of the URL on an article? If I'm right, it should take longer to load, but you should then see both "edit" and "edit source" (and if I'm wrong, well, nothing ;p.) Okeyes (WMF) (talk) 05:29, 18 June 2013 (UTC)
Tried ?debug=true and it doesn't do anything except take slightly longer to load, but no new tabs. Again, I'm on Firefox. I merely tried Safari (which I've since discarded) and OmniWeb for the heck of it, but I do all my editing on Firefox, OS 10.5, and VE isn't working for me. Not a huge deal. – Kerαunoςcopia◁galaxies05:41, 18 June 2013 (UTC)
You know what, this must be something to do with some settings I have—no idea though. But I just went to VE template test (linked on another section below) and I was logged out of mediawiki; I saw the Edit and Edit Source tabs. The moment I logged in, the two tabs vanished (and only "edit this page" appears). I double checked the preferences and they were (I guess default?) set to use VE. – Kerαunoςcopia◁galaxies05:46, 18 June 2013 (UTC)
I think the problem is that you are using a very old version of Firefox. Also, you are using a very old version of OS X. You are using 10.5 which came out in 2007. See this article on Mozilla.org:
Thanks Timeshifter! I thought 16 was the newest version for some reason. Well that would certainly explain the mysterious non-workings on my end. Case closed on my part. – Kerαunoςcopia◁galaxies16:52, 18 June 2013 (UTC)
However, that doesn't explain why it's not working with Safari 10.7.2. - although it did yesterday when I first tried it. Have just now again reset in Preferences and still nothing. Victoria (talk) 17:34, 18 June 2013 (UTC)
Well technically I don't think it answers my problem either since, using Firefox 16 on an "old" OS, I actually can use VE, as long as I'm logged out. But I'm not about to play around with checkboxes in my preferences to find out if the problem lies there. – Kerαunoςcopia◁galaxies19:03, 18 June 2013 (UTC)
Question: for those of us running unsupported browsers is the situation that nothing will change? Quick note: after a lengthy conversation w/ Apple I learned that OS 10.7.2 was bundled with a build of Safari 5.1.1 and it's no longer possible to download a separate browser upgrade (I tried - didn't work). The only option is a full OS upgrade. Victoria (talk) 19:20, 19 June 2013 (UTC)
Using CTRL-Z deletes picture after resizing Agiorgitiko
Not sure whether shortcuts are planned in VE, but using "CTRL Z" do not undo my previous edit (Sorry bad habits die hard) as expected but deletes the picture instead with no obvious way to undo it
Way to reproduce:edit with VE; resize a picture; hit "CTRL Z"
Funny things also happen when you hit "CTRL+B" or "CTRL+I", the selected word is replaced with a weird character while the corresponding button becomes active (using FF Nighlty 24)
Alberto Fernández Fernández (talk) 07:59, 18 June 2013 (UTC)
According to mw:VisualEditor/Features, anyway, shortcuts are intended to be supported. When I tried your "CTRL Z" shortcut after resizing, it moved the picture but did not delete it (same article). It seems to work for me as intended with text - does it work for you with text? Apparently, the "CTRL+I" and "CTRL+B" bug is occasional (see the tracked ticket; the shortcuts worked for me.). --Maggie Dennis (WMF) (talk) 12:19, 18 June 2013 (UTC)
I tried with an image: resize, CTRL-Z and save: the picture disappears because VE cuts the wikicode after undoing per this revision [16]
I tried this time to undo my changes using the back arrow in the toolbar. Instead of getting back to its original size, VE created a page-wide table containing the image. When saving, the VE added code. (I did add a space to force VE save) See this revision [17]
Oh, I see what you mean. That was the result I saw as well - I assumed it was moving and didn't recognize that it was creating a table. Interestingly, as I try to replicate this, I tried manipulating it again, pulling on the edges to adjust the size, and it snapped back into place and then saved properly. (I addressed a typo to force save.) I had the same results in a test at Gil Aldema. I am guessing that CTRL + Z cancels the change you made, but keeps you in the resizing editing mode...which doesn't seem to affect the size of the image. In my ongoing tests, I'm not sure VisualEditor is actually resizing images at all - I haven't been able to make that work. Does it work for you? --Maggie Dennis (WMF) (talk) 15:51, 18 June 2013 (UTC)
You're right. Resizing images do not work at all... Sorry I haven't noticed it before. Apparently, if the parameter "thumb" is not used and replaced by "right" (See [18]) , you can not resize the image in VE. --Alberto Fernández Fernández (talk) 16:48, 18 June 2013 (UTC)
This reopens a question I asked above (under "Is VE intended to do automated cleanup?"), which was side-tracked because the worst example given turned out to be a known bug.
In this edit I changed only a single word, but VE also, unasked, altered multiple levels of <small> ... </small> and <big> ... </big> to single levels. Under "Why is it changing everything else?!", three above this, Numbermaniac found it altering multi-coloured signatures to single colours. Are these bugs, or is VE intended to perform AWB-style tidying up? Editors may not be happy to have their material re-formatted, unless it is explained what is and is not allowed.
Also, to repeat what I said above (two days ago, but two days is a long time in this environment!) I find it alarming if VE is doing AWB-style cleanup. With AWB there are strict Rules of use, permission is required and is given only to trusted users with at least 500 mainspace edits, it is made clear to them that they are responsible for everything done by it and their permission may be withdrawn if it is misused. If VE becomes the default editor for everyone including newbies, we cannot expect them to check on "cleanup" edits it may make in other parts of the page, possibly involving wiki-markup they do not understand, so its automated "cleaning-up" will effectively be unsupervised. What sort of testing is planned that could possibly make this a safe or sensible idea? JohnCD (talk) 11:25, 18 June 2013 (UTC)
As far as I know, this kind of "AWB-style cleanup" should not be happening at all. Once our copy of VE is updated (on Thursday I think?), some of these should stop occurring. Any lingering instances of dirty diffs (i.e. unintended changes in diffs) should be reported. — This, that and the other (talk)11:41, 18 June 2013 (UTC)
I shall be relieved to be assured that's so, but when I asked two days ago "Are these all bugs, or is VE designed to make AWB-type cleanup edits in addition to what the user asks it to do?" Okeyes' reply was: "Plausibly 'both', AWB-type cleanup is involved..." JohnCD (talk) 14:57, 18 June 2013 (UTC)
It looks like the AWB-type cleanup should be happening on a per-line basis; that diff above is a bug (and I'll throw it in bugzilla now). Okeyes (WMF) (talk) 16:54, 18 June 2013 (UTC)
By "per-line basis" do you mean only in the immediate vicinity of actual edits the user is making? If so, that is slightly less alarming, as it is more likely that the user will notice if it does something undesirable or unexpected, but I am still twitchy about this and would like more details of what VE is intended to do in the way of automated cleanup and why it is thought safe to let it do that unsupervised. JohnCD (talk) 21:36, 18 June 2013 (UTC)
To me what this indicates is that they've hacked VE to keep the article source unchanged on lines you don't change, but haven't done anything about the underlying bugs causing it to make unwanted changes. You'll now see those bugs much less often because they'll only happen when they're triggered on the line you're editing, but they'll still be out there biting people occasionally and much more difficult to track down. —David Eppstein (talk) 17:22, 19 June 2013 (UTC)
Visual editor being pushed to 50% of new user accounts
Given that there are still some serious bugs with the VE program at current I think we need to hold off on doing the 50% release. Likewise I think we need to remove the comment that is displaying on the contributions page. Kumioko (talk) 16:55, 18 June 2013 (UTC)
Hi, Kumioko. The VE test is scheduled for today, but everyone will be watching for serious issues that mean it should be halted. What comment are you talking about? I'm not sure what you mean by "contributions page". :) --Maggie Dennis (WMF) (talk) 17:17, 18 June 2013 (UTC)
There are still a lot of comments about formatting errors, things not working quite right and a lot of things that can't be done yet. There is a massive list of bugs associated with it that are still be worked. Its too early to force a 50% test on new users. We are going to drive them off and irritate the regular editors who have to clean up the mess. Its just not ready yet and forcing it isn't going to help your chances for success. Kumioko (talk) 17:31, 18 June 2013 (UTC)
I agree that this is premature, at least if it will be the default editor. New users will have no idea what the restricted areas are about. No problem allowing it as an option and telling people that it's available. What it does, it does usefully. Lfstevens (talk) 17:34, 18 June 2013 (UTC)
I do understand your perspectives, but I do not believe that the testing will be halted at this point unless problems do develop. The data that the A/B test gives about conversation rate is really essential for the full rollout so we know what we're in for. The alternative is that we deploy without any idea of what the likely impact on the community will be and can't warn people in advance if it is likely to be problematic. Bug fixing is going on actively right on up until the deployment (well, and even beyond :D), so hopefully some of the issues already identified will be resolved before then. --Maggie Dennis (WMF) (talk) 17:43, 18 June 2013 (UTC)
With respect Maggie, the problems have already developed and been identified. I cannot stop you from contunuing but I would caution you and the group that if you want the communities support then you should proceed carefully. Many in the community (including me) are already upset at the nature of the WMF forcing these changes, many of which are unwanted and problematic. Releasing VE knowing that there are more than 150 bugs, with only 2 namespaces supported and with no support for templates, references and other objects is not going to help yuor cause to unsuspecting and uneducated (in our ways) new users is just plain dumb. VE has been in development for years. It is not going to hurt one bit if we delay implementation to work out some bugs rather than rush it into production, get the community in defiance and then have the whole things scuttled because the WMF was impatient. Its a good app, it has a lot of potential, but you are in danger of making it the Windows Vista of Wikipedia. Kumioko (talk) 17:57, 18 June 2013 (UTC)
Honestly, I don't think this is a WMF-mandated change. :) People have been asking for a WYSIWYG editor for years - as the Wikipedia:VisualEditor/FAQ notes, since at least 2004. (See also above.) VisualEditor is not quite that, but it is a massive step in that direction (and arguably better than that) - it uses WYSIWYG techniques to make Wikitext/HTML simpler to understand. No software release is bug-free - for that matter, Wikitext is not bug free - but they do hope to keep it containable. The A/B Test is a crucial stage in roll out. Obviously, I didn't set the timing on this; I haven't reached that level of clout. :D But I trust our engineers will know if the software is ready when the time comes and that they will make the best decision. Certainly, you and everybody else who choose test the system can help them in knowing if this is the best decision. When you guys discovered a bug that broke the system completely, they responded - they turned off until it was fixed. Having many people testing is the best way to find "blocker" bugs that make deployment not a good idea.
Assuming they do deploy on schedule, they will be watching to make sure that everything goes as smoothly as possible, and, if it doesn't, they can roll it back. This is obviously very different from the situation Microsoft was in when they released Windows - hard to retract something like that which is installed on individual machines. :/ --Maggie Dennis (WMF) (talk) 18:41, 18 June 2013 (UTC)
Roger that, good luck. For what its worth I think you underestimate your "clout" but its good to see your staying humble. :-)Kumioko (talk) 18:50, 18 June 2013 (UTC)
Just one last note. Realize your audiance. You are releasing it to a group of editors who likely have little clue of how things work, so they won't know where to go with problems if they find them. They'll just stop using it and leave. Or not even notice the errors and make a lot of work for others to clean up. Some of the errors identified were subtle and only caught becuse we were watching for them. VE isn't ready, but I can't stop the train. All I can do is tell the conductor the bridge is out and jump before we go over. Kumioko (talk) 18:53, 18 June 2013 (UTC)
And as if to justify my faith, the developers have evidently decided it isn't quite ready for the A/B. :) I've just received word that it's being postponed. Announcement soon. --Maggie Dennis (WMF) (talk) 19:06, 18 June 2013 (UTC)
Amen to that! Kumioko, your comments were right on the money; I couldn't agree more. Maggie Dennis (WMF) or anyone else who wants to hear feedback, that was absolutely the right call... I've been involved with a good many Fortune 500 technology roll-outs, and without question, releasing a product too soon is far, far worse than too late. I was heavily involved in the rollout of the very first eCommerce website for one of the three major wireless phone companies, and I'd rather not admit how close we came to a very public train wreck. We couldn't stop the train either, but we did convince them to slow it down by two weeks, and that made all the difference – we still got banged up pretty good, but at least we came out of it alive and successful.
VisualEditor is a tremendously lower risk and complexity than that example, yet plunging off the bridge causes the same damage, no matter the size of the train. I suspect too that this project is smaller and simpler than previous WMF successes, but we all know that size and complexity don't measure importance. After all, it wasn't terribly difficult for Coca-Cola to develop New Coke – yet as did New Coke, so too does VE represent a change to one of our "core fundamentals". It has the potential to bring about seismic change – for the better if done right – processes will change, policies will change, and possibly quality, culture, or even identity may change, in ways that nobody can predict. Yes, people have been asking for a WYSIWYG editor for years. If we've waited this long, we'll gladly wait a little longer – when at the end of the day, we all benefit from a renewed confidence and trust that picking up this tool will help us, not hurt us. Thank you for that. —Grollτech (talk) 05:25, 19 June 2013 (UTC)
I like VisualEditor and support its development and moving forward with it. However, I can't think of a worse time to do A/B testing with new users. Hardly anyone knows well enough how VE works, or how to explain it to newbies. More particularly, aside from vandalism, the most common reason for reversion of edits from new editors is a lack of supporting reference. VisualEditor does not yet properly support referencing. So...you're throwing the new users to the lions because they will be incapable of actually meeting minimal editing expectations, they're going to be reverted, and then they won't be technically *able* to add the reference source. This helps new editor retention how?
Get the template and reference stuff straightened out, make it the default for experienced editors...fine. But at least make sure this is a functional product, and that there are lots of people who know how it works, before you start newbies on it. The few WMF staff assigned to helping people work things out aren't nearly enough to support the new users who are going to be sideswiped here. Risker (talk) 05:35, 19 June 2013 (UTC)
Thank you for sharing your thoughts, Risker and Grolltech. I believe that the desire to better support those features was part of the reason for the delay.
There is quite a lot of work going on at the WMF to prepare for this all around, including adding new staff (such as - as a preview - m:User:Whatamidoing (WMF)). A usage guide is actively being compiled at mw:VisualEditor/FAQ and hopefully will be pretty complete soon. Nobody wants this to go badly. :) But the developers believe that an A/B test with new users is essential at least in part to help determine what the impact on existing workflows is going to be.
Speaking personally for myself, I also wonder if you can fully and fairly test a new software by rolling it out only to users of the old. As a long time editor, I know that I am highly familiar with the old ways - at least the ones relevant to my work - and I suspect that the way I approach editing through VE is going to be impacted by that. It seems to me that new users may have entirely different approaches to VE that those of us who have been around a while may not anticipate. In any event, I do personally agree that tossing them into it without giving them the best support possible would be a very bad idea. I think the developers recognize that, too - hence the delay. They want to do the A/B test with the best product they can. --Maggie Dennis (WMF) (talk) 14:52, 19 June 2013 (UTC)
A/B test postponed
Hey all. We're going to postpone the A/B test for several days; I'll post more details as I get them, but I understand it's largely down to known bugs with the existing software - bugs that you reported, and bugs that were crucial in making a go/no go decision. Thank you to everyone for all your hard work poking at the VE, and for all your reports thus far; it's much appreciated :). Okeyes (WMF) (talk) 19:22, 18 June 2013 (UTC)
Good. I hope the beta version with reference and template capabilities will be available for us to poke at before the A/B test starts? JohnCD (talk) 21:25, 18 June 2013 (UTC)
[Copied from WP:VPT] I've only made two edits with VisualEditor recently, both yesterday, both disasters: this and this. The random garbling of text (insertion of "ad a private-pilot license and" and "[[File:Audie-Murphy-Monument.jpg|right|thumb|200px|Monument at the site of the plane crash in which Audie Murphy d"), the random insertions and removals of spaces throughout the article, and the random deletion of a hidden comment from an infobox ("<!-- LEAVE THIS ALONE! See Talk page discussion.-->") were all VE. (It's possible someone thought that "fixing" HTML markup by adding or removing a lot of spaces throughout was a feature and not a bug, but they were misinformed ... it takes a lot of time to search through a long diff to check to make sure no additional significant errors were introduced.) I was editing just one section at a time, and the errors introduced were in sections I wasn't editing. - Dank (push to talk) 20:29, 18 June 2013 (UTC)
No, it shouldn't be doing that; the images insertion is a known - I'm not sure where the heck the text garbling is coming from, though :/. Okeyes (WMF) (talk) 11:14, 19 June 2013 (UTC)
Thanks much Oliver ... just realized what I said could be read two ways ... I meant that each time, I clicked on a section edit button, not on the page edit button, and it inserted things in a section I wasn't editing (and couldn't edit ... I don't recall seeing any text other than the section text, while I was editing). - Dank (push to talk) 20:10, 19 June 2013 (UTC)
I tried another edit to LibreOffice (which I didn't save) and it wanted to do the same substitution (turn the i into a new paragraph). Something odd about that page - David Gerard (talk) 09:18, 19 June 2013 (UTC)
Nah, the nowiki was trying to add an S to the end of [[Linux distribution]] and it decided that I didn't really want the blue link to autoextend to include the S. Which is fine in context. Though the VE does need a way to make the link text not be the same as the name of the page being linked to.
I just now realised that it's possible to enable VisualEditor (why is it one CamelCase word anyway?) for registered accounts, so I decided to try it out, followed the instructions, and enabled it in Preferences/Editing. However, no pages seem to have changed; I've gone to the edit screen both in mainspace and in userspace, and I've waited more than a little pause without anything appearing. Any idea what's wrong? I thought my use of Monobook might be responsible, but I see above that someone's gotten it to work in Monobook. Using IE8 in Windows 7. PS — when adding this section I got an edit conflict, even though I was using the new section tab. Can't remember ever getting an EC when using the add-a-new-section tab; is this perhaps caused by the VisualEditor? Nyttend (talk) 23:43, 18 June 2013 (UTC)
(Re: "why is it one CamelCase word anyway?" - I think we're generally blaming developers who have been around since the old days, or have the habit from too much command-line usage (spaced names need quotation marks around the entire string). There are other recent examples elsewhere... ;) –Quiddity (talk) 17:16, 19 June 2013 (UTC)
Now done so (@Nyttend:, @KumiokoCleanStart:). My advice to you both would, frankly, be to switch broswers (or at least upgrade), but I've entered a tracking bug just to make sure that people know this will be an issue and can explain what's going on. Okeyes (WMF) (talk) 09:22, 19 June 2013 (UTC)
Thanks; I'm doing my best to stay with IE8 because later editions make changes that greatly impair my browsing. I like the VE idea, but it's definitely not something I'd be using anyway; much easier to edit the code itself. Nyttend (talk) 11:37, 19 June 2013 (UTC)
Thanks, I noticed it from my work computer earlier in the day but didn't have the time to say anything. A lot of folks are still using versions 7 and 8 though. Kumioko (talk) 13:41, 19 June 2013 (UTC)
Little issue of recycling computers to give to those who are financially excluded as well. In my world I prefer to delete all proprietary software and work back through Mint and Ubuntu till I find one that doesn't draw too much power- but what do you do with a working Windows 98 machine when you know the kids school does all their work using MSPublisher? You use the IEjunk that comes with it. If VE cant cope- run a browser check before VE fires up and degrade to the text editor.-- Clem Rutter (talk)12:45, 19 June 2013 (UTC)
So, the end outcome; IE8 will essentially never be supported. The full(sorta) rationale can be seen here; essentially there are a lot of things IE8 does not support, to the point where to make something that might work we'd need to basically build an entirely new VE and run it alongside everything else...and even then, a lot of things wouldn't function. Okeyes (WMF) (talk) 16:24, 19 June 2013 (UTC)
No problem and that's kinda what I thought too. That just basically ensures that we will need to still allow the ability to modify the code directly as well as having the VE aplication (which I would prefer anyway for a lot of reasons). Once VE becomes the default for new editors how will Wikipedia handle cases where someone has IE8 and cannot use VE? Will it just default them to the current edit capability or block them from editing? Also, there are still a lot of applications and websites that don't work with Version 10 (we are having major problems with that where I work) so a lot of people are putting off upgrading to that and staying at 8 or 9. For example virtually no one in the US Government has anything higher than 9 and 98% are using 8 and will be for sometime. That is just one example of a large pool of editors that won't be able to use IE. Many colleges and universities are in the same boat. I would highly recommend not building anything into the app that requires IE 10. Kumioko (talk) 16:32, 19 June 2013 (UTC)
XP users are limited to IE8 and there is another year before 'end of life'. I take it from what you say that Opera will likewise never be supported even though it does meet all the requirements listed in your linked bug report.. Dsergeant (talk) 16:55, 19 June 2013 (UTC)
FYI all users of Microsoft's Office 365 are being forced off old versions of IE. MS recently gave notice that Office 365 will require either "the current or immediately prior version of Internet Explorer; or the latest release of Chrome, Firefox, or Safari." The first step is dropping support for IE8 in April 2014 (details here). Presumably when IE11 becomes the "current version" – maybe as soon as Windows 8.1, which is scheduled for fall 2013 – they'll give notice that IE9 will be dropped. - Pointillist (talk) 17:00, 19 June 2013 (UTC)
No problem- sensible decision- it would be a waste of resources- but we do need a fallback statement that guides potential users to a workable low-resource free browser on the MS-DOS platform, and to test against and recommend a low-resource browser on Linux machines and Apples. Though this seems to be low priority it can be written into the functional spec and become part of the testing schedule saving time in future -- Clem Rutter (talk)17:03, 19 June 2013 (UTC)
That's completely understandable but there are some differences here that make the situation a little different. First, Office365 isn't really catching on. A lot of people still have "problems" with putting their documents on the cloud. Second, Microsoft doesn't rely on volunteers and although very popular doesn't cater to the same user base. We have a worldwide, multiracial, multilanguage user base, many of which live on fixed incomes with limited access to resources. If they have XP for example and its working they are unlikely to go through the rather high expense of upgrading to Windows 7 or higher just so they can edit. Some may have computers that couldn't run windows 7 anyway. I am in the computer industry and I don't usually upgrade until something goes seriously wrong with the current version. Kumioko (talk) 17:20, 19 June 2013 (UTC)
I wasn't trying to make any particular point except that the WMF developers aren't alone in making the decision not to support IE8. I assume all our editors have access to libraries and know how to use them. Let's hope that the libraries our editors use will have modern browsers on their PCs. - Pointillist (talk) 17:50, 19 June 2013 (UTC)
Hi all!
I started testing the VisualEditor and tried a few simple edits.
A while ago, I performed this edit which was just a correction (135 instead of 130).
The visual editor somehow messed with the images, duplicating part of them, check it out.
I corrected the edit with the normal editor.
--CeruttiPaolo (talk) 09:24, 19 June 2013 (UTC)
Templates which are hidden like {{Use British English}} and {{use dmy dates}} aren't showing when you go into edit an article with VE, all you see is a carriage return ( ↵ ) which is easily deleted as a superfluous character. See Stoke-on-Trent for an example. This could lead to a rash of deletions innocently thought to be cleanup of stray characters. NtheP (talk) 10:58, 19 June 2013 (UTC)
Select the first wikilink to English (which is actually a link to England).
Ctrl-X to cut, Ctrl-V to paste at end of second paragraph. You will see a white pawn.
If you hit Ctrl-Z twice, you will see a white pawn appear at the point where the link to English was.
I saved it, here's the edit - you'll see the link is a white pawn linking to England. Note it also added a gratuitous pawn link to Rema-Rema lower down the page.
I notice that you get one of "your edit has been saved boxes". What's the .css hack to switch this off (I already have it disabled for source edits with .postedit { display: none;} )? NtheP (talk) 19:12, 19 June 2013 (UTC)
I set out to add a db-a10 template, which takes a single parameter, and was baffled when asked for a parameter name. Eventually I guessed that "1" was the right answer. Perhaps there could be a hint for that: "Enter parameter name, or 1, 2 etc if no explicit name." JohnCD (talk) 21:49, 19 June 2013 (UTC)
I think VisualEditor is supposed to understand the TemplateData metadata format for describing template usage - as I understand it, the idea is that a list of possible parameters will be provided, and they will be displayed with human-readable names (e.g. "name of other article" instead of "1" for db-a10). However, it seems to only be partially implemented in VisualEditor at the moment, and moreover, none of our templates have TemplateData metadata yet. — This, that and the other (talk)00:59, 20 June 2013 (UTC)
I successfully added a db-a10 template to the top of a test page, but when I removed it (using the jigsaw icon and "Remove template") a line of detritus was left behind, see here. JohnCD (talk) 22:04, 19 June 2013 (UTC)
Why is the beta release scheduled for July? The alpha version seems more than a month away from being useful. All it can do is edit basic text, which is not a problem with the current editor. Everyone says VisualEditor is going to help new users overcome the Wikimarkup barrier; how will it do that without being able to edit elements that use complex markup? Inexperienced editors are not having trouble adding links, section headings, or basic text. They have trouble formatting references, editing transcluded content, adding lines to tables...all the stuff VisualEditor can't do. The current version is an interesting prototype, not a useful product. Thatotherperson (talk/contribs) 11:05, 10 June 2013 (UTC)
I agree. As it stands VE is cosmetically more friendly to new-comers accustomed to word processors, but it does not aid them with editing things like templates and references. More so, I don't see any way to edit at all to include references, which seems worrying to me. When I first joined Wikipedia, I just looked around at the formatting others used, and copied it, and all was fine. But if I were to join with the VE as default, I think I would be really confused as to how to make things like references.AioftheStorm (talk) 20:48, 10 June 2013 (UTC)
Citations are supposed to be working soon, but I just edited this huge table without having to look at any markup, and I believe that this is a major improvement that will improve editing for experienced people as well as for new users. (This particular table is on my watchlist specifically because people keep having problems with the formatting.) I don't see any way to add rows or change column widths yet, but just being able to change the text is a significant improvement. WhatamIdoing (talk) 21:35, 10 June 2013 (UTC)
Looking at your diff, you (I'm sure accidentally) wrecked the URLs inside the {{cite}} templates by adding tags around them. Should a bug be filed? [[User:Ypnypn|Ypnypn]] ([[User talk:Ypnypn|talk]]) 01:22, 11 June 2013 (UTC)
::::Yes, I think what it did to the rest of the page is evidence of a bug. I didn't touch anything outside the one cell (partly because I wasn't sure that it would work, so I didn't want to try anything at all complicated). [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 05:28, 12 June 2013 (UTC)
*It's going to have templates, transcluded content, tables and references; all of those things minus references ''should'' be live on MediaWiki.org in various forms, and will be deployed here later. [[User:Okeyes (WMF)|Okeyes (WMF)]] ([[User talk:Okeyes (WMF)|talk]]) 10:19, 13 June 2013 (UTC)
:::::This is unnerving, and confirms the suggestion that the Beta release is a rush job. [[User:Hgilbert|hgilbert]] ([[User talk:Hgilbert|talk]]) 01:14, 18 June 2013 (UTC)
::::::It's definitely rushed. I'm not against change and I actually liked the idea as it will invite more new editors, but implementing it this way (barely half ready) has negative consequences. <b>[[User:Mohamed CJ|<span style="font-family:Segoe Script;color:#ff0000">Mohamed CJ</span>]]</b> [[User talk:Mohamed CJ|<span style="font-family:Script MT Bold;color:#07517C">(talk)</span>]] 09:35, 18 June 2013 (UTC)
:::::::Rushed releases often create chaos and end up with less users than before. I don't think it's a good idea to rush this out to general use as crippled as it is now. New users should be leaving citations, not just changing things for fun without citation. [[User:Ellin Beltz|Ellin Beltz]] ([[User talk:Ellin Beltz|talk]]) 20:01, 20 June 2013 (UTC)
::::::::Its definately rushed. I completely agree. I am glad that they put off the intitial release for a couple weeks at least because the app doesn't appear nearly ready enough to thrust upon new users. We are still finding and fixing too many problems and too much functionality still needs to be added. [[User:KumiokoCleanStart|Kumioko]] ([[User talk:KumiokoCleanStart|talk]]) 20:30, 20 June 2013 (UTC)
== Impossible to edit sections with wikitext ==
{{tracked|49666}}
{{tracked|48429}}
:''Note. See related section: [[#Now unable to edit sections by old method]].''
Whenever you click on a section edit link, it takes you to the visual editor for the whole page. [[User:Kelvinsong|Kelvinsong]] ([[User talk:Kelvinsong|talk]]) 20:15, 14 June 2013 (UTC)
:Change this setting at the new [[Special:Preferences#mw-prefsection-editing]]–"{{tq|Use the wikitext editor for editing sections while VisualEditor is in beta}}"
:And see the section above, [[#Now unable to edit sections by old method]], for discussion. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 20:19, 14 June 2013 (UTC)
::Do the words "''while VisualEditor is in beta''" in that setting imply that when VE is fully released source-editing of sections will be possible without a special opt-out? [[User:JohnCD|JohnCD]] ([[User talk:JohnCD|talk]]) 20:29, 14 June 2013 (UTC)
:::No, the opposite; once the VE is working, source links will prioritise the VE without, necessarily, an opt-out. Frankly, though, that's not something we have to worry about right now; the software is not stable enough for anyone to consider it 'done', and won't be considered that way for a very long time (read: ask me again in a year). [[User:Okeyes (WMF)|Okeyes (WMF)]] ([[User talk:Okeyes (WMF)|talk]]) 21:34, 14 June 2013 (UTC)
::::I don't understand what you are saying. What exactly is the current plan for section editing when VE is fully deployed in a year or whenever? I tried to edit a section, and it now uses VE by default for sections (a really bad idea). I had to disable VE in my preferences because it was screwing up so many things. Now I find out about this preference to return section editing via the source wikitext editor. The preference is here: [[Special:Preferences#mw-prefsection-editing]].
::::So VE is being already being imposed on us even though it is in beta buggy mode. Just like Wikia's visual editor. Are the same people in charge? Regular editors on Wikia, for the most part, ''detest'' Wikia's VE, because it breaks so many things, and is so buggy. On Wikia one can not use both editors easily. One can not make source editing be the top tab. One has to wait for VE editor to load, and ''then'' click on the source editing tab. Takes forever. So most regular editors turn off VE altogether in preferences.
::::The one improvement in implementation I see here is the ability to use this preference. You should be advertising it heavily because otherwise many people may stop editing Wikipedia altogether for awhile. Just because the WMF board and staff is imposing yet another thing without community consensus. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 23:29, 14 June 2013 (UTC)
: Good job rolling out a [[Facebook|silent default switch]] and hiding the checkbox to fix things in the Preferences without as much a notification. Not a good strategy to get more beta testers. -_- —[[User:Kelvinsong|Kelvinsong]] ([[User talk:Kelvinsong|talk]]) 21:41, 14 June 2013 (UTC)
:Yes, there is a problem here. I fail to understand the reason for the VE team's reluctance to consider providing a parallel set of section edit links for editing the source of each section of a page, at least while VE is in beta. I suppose a user gadget could be written to provide this functionality, but I don't see why that should be needed. If the requested functionality will not be provided, it would be interesting to hear why: [[User:Okeyes (WMF)|Oliver]]? — <span style="border:dashed #666;border-width:1px 0 0 1px">[[User:This, that and the other|This, that]]</span> and <span style="border:dashed #666;border-width:0 1px 1px 0">[[User talk:This, that and the other|the other<small> (talk)</small>]]</span> 00:51, 15 June 2013 (UTC)
::I agree that the current VE implementation has the '''[[unintended consequence]]''' of effectively eliminating subsectional editing for all but the most advanced and persistent editors. First of all, it eliminates the very helpful subsectional labels automatically added to edit summaries, which are very useful for all editors who rapidly scan the summaries. Another negative consequence of eliminating subsectional editing is a marked increase in the number of [[WP:EDITCONFLICT]]s, especially on articles with high edit activity. Edit conflicts are distracting and time-consuming enough for experienced editors, but will be very dismaying and discouraging to novice editors.
::If the VE developers insist that the subsectional "edit" pointers all lead to an article-wide VE window, at least place an "edit source" or "advanced edit" pointer next to each occurrence, pointing to a standard edit window at the subsection level, so that more-experienced editors can continue to do their work more efficiently. I understand that the development of VE is intended to bring in novice editors more easily, but this should not be done at the expense of impeding and driving away the more-experienced contributors. [[User:Reify-tech|Reify-tech]] ([[User talk:Reify-tech|talk]]) 16:07, 20 June 2013 (UTC)
== What happens now? ==
I am a typical, moderately active, Wikipedia editor, well used to Wiki syntax but totally understanding the wish for WYSIWYG editing. I have not tried to use the Visual Editor but I have read this page in detail. I also have experience of WYSIWYG editors bundled with content management systems. Those typically have a 'source' option to bypass WYSIWYG and directly edit the HTML being generated for the page.
From the horrific bug descriptions above, it seems to me that the VE code is designed to display to the wiki editor the entire existing wiki page, enable the editor to make her/his edits, then re-upload the entire page. This is why so much formatting is being lost and this is why we get complaints headed ''VE doing unasked-for reformatting'' or ''VE inserting errors in sections that weren't being edited''.
What I'm sure Wikipedians are expecting from a WYSIWYG version of the Wikimedia edit facility is something that would replicate the actions that an editor would carry out using the traditional edit facility. In other words, if the user chooses to edit one word, only that word should be changed. If they decide a phrase should be in italics, a pair of <code><nowiki>''s would be inserted, and nothing else. That is what we need from a WYSIWYG development, not something that will destroy pages that have been carefully constructed over a period of years by removing all syntax that the half-finished software does not understand.
Secondly, the user needs to be able to insert wiki code into the edit window in the way they always have. Remember, the various codes like [[link]], '''bold''', {{template}} use characters that are unlikely ever to occur in the text of an article, so the edit system should silently accept them and save them, not surround them with nowiki tags.
The software needs to comply with these basic requirements, along with several others like proper support for cites/references and templates, before there can be any serious roll-out to users other than volunteer testers. If this means 3 or 6 months so be it. Sussexonian (talk) 21:24, 18 June 2013 (UTC)
I see that we have many problems here, due to the enthusiasm of the coders- and the lack of bruises from working in a software development team for another big project.
an inadequate analysis phase, thus not understanding the myriad of ways that wikipedia is edited causing the wrong type of visual editor to be developed. As a case study I was working with some museum staff who were keen to contribute- but reticent to start. The first thing they wanted to do was to add references (obviously I advise {{sfn}} as I can just c&p the correct reference block with the standard books they are all using and they can find the page numbers and have the satisfaction of see immediate improvements. The second thing is to add new facts supported by the {{sfn}}- references are in their blood. I know that other new editors work in different ways but many don't
--a lot of work has been done here but it is directionless
No evidence of a testing schedule (users should have been asked to contribute to this- it is not even clear on which version of which browser the tests have been (should have been )run on. Testing needs to be done against the Functional specification which will be iteratively modified.
Exception debugging- there has been a lot of that to the point where it looks as if this is being used instead of testing.
In short we are all being asked to alpha test the wrong product.
The team should complete the test, and use it as evidence when they go round the software cycle, and more rigorously apply themselves to the analysis phase. This should be published for comment. Actually all of the above should be available for comment.
The consequences of this being set loose is that a lot of editors I work with are going to do automatic reverts on any edit using VE that finds its way onto their watchlist. Arbcom and the civility police are going to e working overtime
I actually think that Parsoid and VE surface are very well thought out and implemented and have a pretty good test surface. Both have been in development for two years (with a full reboot after the first year). They are extremely complex but flexible pieces of software that are very capable of fulfilling their technical promises.
Personally I support your comments when it comes to the VE 'block' editors. These are basically the image, reference and template editor (major UI components of VE). In my opinion these parts of the software are the areas that do show some of the problems that you mentioned and they have strong signals of being rush jobs.
This was in alpha testing for 2 months. If it takes threatening to deploy it within 2 weeks to actually get people to start participating in the alpha testing process, then perhaps this wasn't such a bad exercise after all. Wikipedia is not a commercial product, sometimes the volunteers need active pushing around to actually get stuff done. We have given a gigantic amount of feedback over the past 2 weeks, much more than in the 2 months before that, and worlds more than in the 6 months of prototype testing that came before it.
So what if we are alpha testers ? That's exactly what we are supposed to be. So what if eventually we didn't go to Beta this week afterall ? Did the project die? was it heavily disrupted ? Did we learn a lot ? Did we get to give feedback ? —TheDJ (talk • contribs) 23:29, 18 June 2013 (UTC)
TheDJ, you consider templates and references to be "major features" and yet you suggest that VE has been "in alpha" for two months. That's too optimistic. No version of the Visual Editor which supports those major (I'll go so far as to say "essential") features has been exposed to the content of ENWIKI. I still have no idea what the interface for references looks like, I haven't seen a screenshot, I haven't seen a working implementation, and if you want to start getting more editors engaged in actively testing it, you're going to need to install, with all its "major features" it on ENWIKI where editors willing to do testing can start trying to use it to get their work done. I kept trying, but found that for thee-quarters of my work or more that the lack of "major features", specifically references, made that impossible. I would have thought this would have been obvious. --j⚛e deckertalk23:55, 18 June 2013 (UTC)
The extra feedback in the last two weeks is likely due to the Watchlist notification being added around that time, not the threat of deployment. I tested VisualEditor the day I found out it existed...about a week and a half ago. I didn't hear about the planned A/B test until later. –Thatotherperson (talk/contribs) 02:49, 19 June 2013 (UTC)
I have no idea the source, although I can make a guess - but whatever the source of the feedback is, I'm very grateful for it. Having said that, I'm with TheDJ on this; the software has not been a "rush job", and I take issue with the citation-less argument that the developers on it haven't worked on a large software project before. I'd like to know what evidence this is based on. Regardless, that argument is rather secondary; the primary issue here is "the VisualEditor has a lot of bugs". To which I respond "Yes".
The VisualEditor is, by default, a complex project; wikimarkup is not a simple thing to parse and interpret. It's made a lot more complex by user differences on it. By that I mean the fact that enwiki may do things very differently to frwiki, that neither of them may have anything in common with ptwiki, and that even after these differences are resolved, each of the projects is heavily reliant on a ton of different templates, the CSS and HTML of which may or may not be VE-compatible. It's a thorny problem, and the best way to solve for it is to see what actually happens to the VisualEditor on production, where these templates and project-specific differences live; that's exactly what we're doing.
If people have specific bugs I'm happy to address them and throw them at the developers, who frankly have been doing a pretty fantastic job solving for them. If people want to sit here and make ill-informed arguments for the developers being incompetent, or their work being for naught, that's not helpful. @Sussexonian:, I totally agree with your user needs; the errors being inserted are being fixed, and there's already an enhancement bug for having wikimarkup support within the VisualEditor - but I'd note that it's a fairly complex task, and the underlying problem there may resolve itself as muscle memory adapts. Okeyes (WMF) (talk) 09:28, 19 June 2013 (UTC)
What we're seeing now is the process pretty much working. People are reporting bugs at a furious rate and they're being addressed. The VE then becomes more usable for some other edge case, which generates more interesting new bugs. If the developers can keep up with the reports on this page, then everything is actually going great! (Then, once it's robust enough, we could make it faster ...) - David Gerard (talk) 13:36, 19 June 2013 (UTC)
I'm not sure I would call that a "working" process. I don't think releasing half-functional software as a product intended for active use by the general public qualifies as "working"—remember, this was supposed to go live for randomly selected editors yesterday. The "furious rate" of bug reports suggests to me that the VE has not undergone much rigorous testing on the actual real-life data it's intended to operate on. These reports are not relatively minor cosmetic issues or inconveniences; entire aspects of the product's intended functionality simply do not work, at all. That sounds to me like something barely even ready for alpha testing by interested parties, not working software ready to be foisted on the userbase at large. Basically, the way to write good software is not: throw together a bunch of code, release it for public use, get your users to tell you all the parts that don't work, then go back and make those parts work. If Mozilla released a new Firefox version that only displayed certain HTML elements, or if Microsoft released a new Windowsservice pack that didn't support playing video on the system, they would be publicly excoriated, and rightly so. The Foundation's developers seem to be taking their cues from Facebook and other "Web 2.0" (or 3.0 or whatever we're on now) sites that make a practice of pushing out half-functional software for public release and using their end users as guinea pigs to figure out which parts of the software still need to be written. I am judging this based on the appearance that a large portion of the bug reports seem to be things that would be noticed relatively quickly in testing on actual pages on Wikimedia projects. I would think the "release metric" or whatever you want to call it for VE would be pretty simple: pick a reasonable value X, select the X most-trafficked Wikimedia projects, select the X most-trafficked pages from each of those projects, open them in the VE, make some changes, save them, see if the intended outcome occurs. Obviously you would be doing this in versions copied to a test wiki, not the actual live sites. Given that the developers have finally admitted the VE is not ready for release, I would hope that in the future they will not consider releasing software before it's verified to be working as intended in actual real-world environments. --108.38.191.162 (talk) 17:57, 19 June 2013 (UTC)
I'm confused. Your argument is that the process isn't working because this is a product intended for active use, and we were meant to release it yesterday...except it's not, it's still being tested, and we didn't release it yesterday because of all the bugs....which we detected and factored into our decision not to deploy thanks to the existing process. Okeyes (WMF) (talk) 18:10, 19 June 2013 (UTC)
My argument is the process is not working because the initial public release was planned yesterday, until the actual moment of that release came and the developers decided it was so clearly not ready for release that the release was called off. If it's evident a release target cannot be met, it's best to make that publicly known ahead of time, instead of at the actual moment of planned release, especially when other people are making plans based around that target. Ideally, in software development, there are regularly scheduled reviews of the development process, which include assessment of whether targets that were previously made are still realistic. --108.38.191.162 (talk) 18:49, 19 June 2013 (UTC)
The developers are having plenty of meetings and reviews; I sat in on one of those yesterday. Those meetings do include determining if deployment is on target, but unless they prepare the software far in advance, there's always going to be estimation involved - how long it will take to fine tune this or that aspect; how many bugs may be uncovered when this feature is unrolled. Certainly, I can agree with you wholeheartedly that consumer products should not be released when they are half-functional. I'm not particularly happy when I'm an early adopter of a new technology and find it bug-riddled. But I'd ask people to keep in mind that Wikipedia is fundamentally different. We are collaborators - end users are not guinea pigs, but participants in the process. I do not think that the VE software would be half as good or ready half as quickly as it will be if it were not for the tremendous assistance of the community here. :) The feedback we've been receiving and passing on has been critical to its rapid improvement. --Maggie Dennis (WMF) (talk) 12:29, 20 June 2013 (UTC)
I tried to add one image and replace anotherone both did not succeed.[19]. Also how are the suggested items choosen? It seems every image which just contains the word Dublin anywhere on the description site on commons comes up. better just use the Category. --Saehrimnir (talk) 15:27, 19 June 2013 (UTC)
If I'm reading that one correctly, it looks like a fix for that is in the works. :) Thanks for reporting your experience with it. I'll pass along the category suggestion - I'm not sure how images are chosen myself. --Maggie Dennis (WMF) (talk) 12:34, 20 June 2013 (UTC)
I asked about this one about an hour ago and I'm told that while it would wonderful to be able to use the category system, it's not something that VE can do without a massive restructuring of Wikimedia Commons, along the lines of Wikidata. :/ It searches basically as if you entered the term in the "search" bar. --Maggie Dennis (WMF) (talk) 19:23, 20 June 2013 (UTC)
VE still attempting whitespace cleanup in templates
Add a "cancel" button as well as "Review your changes/Save"
When you get to the final stage, and you review your changes, and you realise VE has turned the article into guacamole, and you've already reported the bug in question ... a cancel button right there would be a very good thing to do. The impression it would give a n00b is "hah, no way out! You can only review it again, or save!" - David Gerard (talk) 20:20, 19 June 2013 (UTC)
@David Gerard: Do you mean exit from the save dialog, or exit from VisualEditor? The "^" icon in the top-right corner of the save dialog (soon* to change to "X" like all the other dialogs *: when we port it over to use the newer dialog system rather than its own version) does the former currently; for the latter, once the save dialog's gone, you get the toolbar again with its "Cancel" button which gets you out of VisualEditor entirely. We could put a cancel-and-kill-my-changes button in the save dialog, but I worry that people would press it (and click through any warning modal we give them) expecting the back-button to retain state, which it wouldn't. :-( I think the "^" isn't sufficiently self-explanatory, and that "X" isn't hugely better, but adding yet-another-darn-button to the save dialog (when it's already busy/complicated enough, with five potential phases - initial save view, review diff, save-post-diff-viewing, saving, edit conflict). Thoughts? Jdforrester (WMF) (talk) 02:20, 20 June 2013 (UTC)
Yeah, I see the problem. But I do anticipate confusion on this point. The real problem is that, as you outline, the present process is entirely too modal (there are multiple possible levels of cancellation) - David Gerard (talk) 06:51, 20 June 2013 (UTC)
I've had my doubts, but this is starting to look good.
Sure, change is scary, and not everyone (myself included) is entirely comfortable with it, but you guys are doing a great job, especially now that we can edit templates. (Very cool for tables, by the way...except they're pretty easy to break if you delete a cell.) I think this is a huge leap forward, and will open Wikipedia to a much wider base of would-be editors. Thank you for all your hard work! ~Adjwilley (talk)01:38, 20 June 2013 (UTC)
Thank you. :) Being not all that comfortable with technological change myself, I've had (and continue to have) plenty of moments of confusion with VE, but it's really exciting to me to see it coming together. I honestly do not think it could happen (at least not as well) without the massive outpouring of assistance we've seen from the community here. --Maggie Dennis (WMF) (talk) 12:44, 20 June 2013 (UTC)
Thanks. :) They're working on this one. You can read the bug report, if you like, at the link provided. In terms of citations, I hope that by the time we do rollout, it won't be harder to add citations. --Maggie Dennis (WMF) (talk) 12:55, 20 June 2013 (UTC)
If you enter, for instance, "Welcome" in the new template box, on clicking "Apply changes" you see the result; but if you enter "subst:welcome" you see only {{subst:welcome}}, though after clicking "Save page" the result is correct. Should there be a check-box for "subst" in the New template dialogue, (a) to save typing it out, (b) to arrange the correct display? JohnCD (talk) 11:33, 20 June 2013 (UTC)
And asked. I'm told that substituting templates should be supported, and since this is not yet in Bugzilla, I've been requested to do so. :) On it! Thanks much for finding the issue! --Maggie Dennis (WMF) (talk) 19:27, 20 June 2013 (UTC)
More detritus after deleting template
This is different from "Removing template leaves detritus" six items above: this time, the template I added was subst-ed, so the "Remove template" dialogue was not available. To try to remove it, I dragged the cursor across to select the whole line and pressed "delete", but the HTML comments included in the template were not deleted. JohnCD (talk) 11:50, 20 June 2013 (UTC)
Really with substituted templates there's no way to maintain the same deletion process, since the entire point of substitution is that it copies the contents of a template wholesale into the article - and the HTML comments aren't going to be supported (in fact, this bug is the result of fixing another bug, which was that HTML comments wouldn't render properly and could be accidentally deleted). I think the solution for this one may be at the community end and operate around "stop using HTML comments in templates". Okeyes (WMF) (talk) 13:09, 20 June 2013 (UTC)
Editing Templates
Look very good! I would like it more if the parameters would appear in the order they are in the template rather than alphabetically for intance in in Ethanol the image parameters in the info box are split up because of that also often the parameters are in the order of the rows in the Infobox to make the easier to find and or identify.--Saehrimnir (talk) 13:34, 20 June 2013 (UTC)
Thanks! So, this is down to a lack of TemplateData associated with that template; once someone adds it, they can be in the appropriate order, and will also contain more human-readable names and a description of what each parameter does. I'm planning on writing up a TemplateData tutorial so people can get on with adding it to templates over the next few days :). Okeyes (WMF) (talk) 14:29, 20 June 2013 (UTC)
Visual editing will be a handicap, similar to a graphical user interface (GUI) over a command line interpreter. It is far more expeditious and flexible to type what is intended rather than to click and poke, which requires considerable manual dexterity. — Preceding unsigned comment added by Roesser (talk • contribs) 15:34, 20 June 2013 (UTC)
And the source editor will remain. The problem we're trying to solve for here is not, largely, the difficulty of typing what is intended. What we are trying to solve for is the fact that typing what is intended means knowing what you need to type to achieve a particular outcome - that there is substantial cognitive overhead in learning wikimarkup and in utilising it, and that this presents a large barrier to beginning to edit, particularly if all you're trying to do is fix a typo. To use your analogy; yes, command-line interpreters are more precise than GUIs. I'd much rather use the UNIX terminal to run SQL queries or set cron jobs than I would a GUI equivalent. But last time I checked the vast majority of internet users, even highly intelligent and educated ones, use GUIs - because the barrier to entry is far lower. Okeyes (WMF) (talk) 15:49, 20 June 2013 (UTC)
Trying to strip superfluous sections or space off the end of a page fails to leave an empty line between the last visible text and wikimarkup (categories, persondata, et cetera). See this diff [21] and this diff [22]. This is only a problem in VE because the things at the end are invisible- an editor can't tell if there is markup there or not. A412 (Talk • C) 16:37, 20 June 2013 (UTC)
I opened my user page in the Visual Editor - and found that an image I'd linked from the page displayed, large, wrecking the layout. Perhaps the link to it is non-standard, but I've happily read and edited that page for years with that link "pictured" with no problems. The wikicode is [[:Image:Flag of Wales 2.svg|pictured]] . PamD16:42, 20 June 2013 (UTC)
Thanks A412 :). I'm afraid that's a problem for the gadget authors to solve, not the VE developers. Ultimately every project is going to have 101 gadgets, and 101 individual fragments that make it to user JS and CSS files that don't qualify as gadgets. It would be unrealistic for every software team to, each time, design around a large number of totally unofficial components of mediawiki that may exist on a per-language basis. It looks like User:Alex Smotrov is the gentleman you want to talk to. Okeyes (WMF) (talk) 17:18, 20 June 2013 (UTC)
Clicking outside the "Describe what you changed" box locks it
After clicking "Save page", if you happen to click outside the "Describe what you changed" box, e.g. in the WP search box just above it (quite a likely mistake, I have done it more than once) or in the article text area, the "Describe what you changed" box locks and you cannot edit there. You can get out of that by clicking "Review changes" and then "Return to save form", but it's irritating. JohnCD (talk) 18:47, 20 June 2013 (UTC)
Ooh, that reproduced it for me. Testing on a few other pages, and yep: click in the search box so the cursor's blinking there, and you can't get back to editing your commit message. Same in Chrome 27.0.1453.116 m on the same box - David Gerard (talk) 20:57, 20 June 2013 (UTC)
Aha! Thanks, both; one of our user testing people had this happen and I had a devil of a time trying to figure out why. Throwing in bugzilla. Okeyes (WMF) (talk) 04:43, 21 June 2013 (UTC)
The bold/italics/apostrophes in the lead section of Flaming Pie looks just fine when reading the article, but click Edit and you'll see that the VisualEditor doesn't display the bold/italics/apostrophes properly. GoingBatty (talk) 00:56, 21 June 2013 (UTC)
The "Important note" opens in a duplicate window that covers a good portion of the page, even when scrolling, and it's not obvious that you have to click the words "1 notice" to close it.
Some source code is visible in Edit mode, such as:
please [[<tvar|bugreport>Special:MyLanguage/How to report a bug</>|report the issue in bugzilla]] in the [<tvar|bugzilla>https://bugzilla.wikimedia.org/enter_bug.cgi?product=VisualEditor</> "VisualEditor" product]
So I decided to test the Visual Editor again today, and seeing the new template editor, I'm impressed. I just wish you didn't have to go to a separate tab to edit each parameter, this can get really annoying for templates like {{IPAc-en}}. Also, for some reason, it only works for a few common templates like {{taxobox}} or {{main}}. I see no reason why it wouldn't work for more obscure templates, but I'm not a coder.
A few visual design quibbles:
Please change the parameters scrollbar on the template editor to something less intrusive. Right now it uses the system/browser scrollbar, which is quite ugly. (I can't believe I'm saying this but) take a cue from Facebook and use something like:
So I work often on fixing links to disambiguation pages. Is it somehow possible to find in a big page the link that is piped to a specific page? because Firefox only looks for the lable.--Saehrimnir (talk) 15:02, 20 June 2013 (UTC)
As an editor of technical articles not being able to edit formulas in the visual editor is an issue. There should be a small window opening when you click on top of a formula to see the LaTex source for editing. That would be fantastic.sanpaz (talk) 04:54, 21 June 2013 (UTC)
Hi - I reverted this [23] edit to Jasper Fforde, partly because of the poor spelling (instalment has only one 'l' in UK English, and 'Uniteed' States is clearly wrong) and the overlinking but also because of parts of the edit which may be due to VE - note the change to "[[Parody|<nowiki/>]][[parody]]" and "[[The Guardian|''The '']]''[[Guardian]]''". It's difficult to tell whether these were genuine mistakes by the editor or caused by VE, but I suspect the latter simply because the wiki markup is all over the place - unless, maybe, said editor is entering the markup manually? Stephenb(Talk)06:47, 21 June 2013 (UTC)
I think what David meant was that the tag signifies the edit is definitely made by the VE, and the user is not manually entering markup (although I guess he/she could be entering it, in the sense of using markup in the VE, which does cause problems). I'll reach out to them :). A pity to see it happen to Fforde, of all people - one of my favourite writers. Okeyes (WMF) (talk) 08:17, 21 June 2013 (UTC)
Yes, I thought the user may be entering it in the VE editor (or it may possibly be a VE bug, hence reporting it here), sorry for any confusion. Fforde is also one of my favourite authors :) Stephenb(Talk)08:43, 21 June 2013 (UTC)
My other half has forbidden me from calling our firstborn "Thursday". Very disappointed. Still, everyone has to make sacrifices in a relationship. Anyway, I've dropped them a note - hopefully we can work out what they were trying to achieve and see if there are any new and interesting bugs there. Thanks for reporting it! Okeyes (WMF) (talk) 09:04, 21 June 2013 (UTC)
Makes stub-sorting laborious
As far as I can see, if I want to replace {{stub}} by {{Italy-saint-stub}} or {{1970s-rock-album-stub}} I've got to do two separate operations, one to remove a transclusion and one to add a new one. Very tedious, for those of us who sort hundreds of stubs. Have I missed something, or is it going to be OK in future version, ... or will VE make life more difficult for stub-sorters? PamD15:14, 21 June 2013 (UTC)
It's going to be somewhat more difficult, yes. For what it's worth, the source editing mode will remain around, and ultimately I'm hoping that Wikidata will sort of automate this process; something like "find me the intersection between the stub category and the 1970s rock albums category". Okeyes (WMF) (talk) 15:46, 21 June 2013 (UTC)
Sorry to hear that. And of course the possible future Wikidata fix only works if the article has been categorised before being stub-sorted, which is very often not the case. Ah well, that's progress. PamD16:06, 21 June 2013 (UTC)
It's also very tedious to have to go through the "click at bottom of article, click on transclusion icon at top, wait" routine several times when adding more than one stub template. Couldn't there be a "add another transclusion" option? And, they get added on the same line, where they ought each to be on a separate line. See this edit.
On the other hand, the drop-down menu of templates is a great help, thanks. It would be even better if there was an option to only see the templates with names ending in "-stub"! And now I've done for a while, after this flurry of feedback, as Mother wants her tea!PamD17:34, 21 June 2013 (UTC)
Tags at head of article don't look distinctive enough
When editing an article with maintenance tags, perhaps under a "multiple issues" wrapper, they display looking very similar to article text. Could they be boxed round as in the actual article display, to help distinguish them from the actual article content? See Virivilai for an example of the effect. PamD16:32, 21 June 2013 (UTC)
If I can't read the article, because the "page settings" box is large and un-draggable and hides all the article (I can scroll the article behind it, but not move the box out of the way), how can I see what defaultsort or categories I want to add (especially as for defaultsort I probably want to copy and paste all or part of the article title)? This just doesn't work. PamD16:50, 21 June 2013 (UTC)
The Page Settings box displays the article title as a default "Defaultsort". But it doesn't seem possible to edit it: typing any letters removes the whole existing text, while trying to delete a few characters has no effect. Where the sort key is not identical to the article title it's usually a variation of it - delete a leading "The ", or move the given name from start to end. It's a waste to have to retype it all: we ought to be able to edit that box. (I'm using Firefox 21.0, in case that's significant). PamD18:36, 21 June 2013 (UTC)
The article I was editing had a blank line between {{reflist}} and the catetories, and another between the categories and the stub templates. I wanted to add an "External links" section and found it difficult. I typed "External links", highlighted and clicked to get it as H2, but then couldn't add anything below. Went back and undid the H2, added blank lines below, then re-H2'd it, add EL section... and it all came out as H2. Then gave up, saved edit, and re-edited in "Edit source" to clean up (as I've done with every recent VE edit, given the garbage that VE produces when I remove a stub template!).
I had an earlier problem trying to add an "Italic title" template to the top of an article - it appeared in the midst of the lead sentence.
So as a generic problem: it's not easy to insert new headings or templates into the right place.
I like the idea of VE, and the dropdown menus of templates, but it's proving very hard work to use it at present. PamD20:31, 21 June 2013 (UTC)
The template-removal garbage will be fixed with the next weekly VE update (every Thursday).
The handling of blank lines is confusing, because a lot of the blank lines you see are actually "slugs", not blank lines - these are quite unintuitive, and ways are being worked out to improve the handling of slugs (bugzilla:47790).
Templates like {{italic title}} should (with any luck) be moved out to the "page settings" dialog box, since they are closer in behavior to "magic words". (In fact, {{italic title}} is just a wrapper for the DISPLAYTITLE magic word.) — This, that and the other (talk)01:59, 22 June 2013 (UTC)
User guide
@Okeyes: further up the page I asked about a basic user guide and you said it was on your to-do list. Good, but two comments:
For future reference (this is aimed at the developers, not you), it's good practice to write the user guide in parallel with the design, not as an after-thought. Having to think from the user's point of view often exposes mistaken design assumptions.
I think absence of a "Help" button linking to a basic page of user guide should be a show-stopper for an A/B test, or any exposure of the VE to newbies.
@Okeyes (WMF): - Also, having a user guide makes it easier to differentiate between bugs and disagreements on the intended functionality. For example, I hope that the user guide would detail each of the additional automatic fixes that the VisualEditor will make to an article. Looking forward to reading it! GoingBatty (talk) 01:00, 18 June 2013 (UTC)
Interesting to see that the last line in the user guide states: "In general, VisualEditor should never make changes to formatting on lines that are not being directly edited." GoingBatty (talk) 04:39, 23 June 2013 (UTC)
Ctrl-C problem
The Ctrl-C problem (reported above under "Shortcuts keys - Firefox 17.0.1 (Windows)") was supposed to have been fixed with Bugzilla 49816 but I still find, when copying/pasting formatted text in VE Edit mode (Windows 7, Firefox 21.0) that while right-click+copy, cut, paste behave as expected,
Ctrl-X cuts text out of the article, but does not put it in the Windows clip-board
Ctrl-C (which should be "copy" not "cut") also cuts it out of the article, and does not put it in the clip-board. Sometimes, though this is not consistently repeatable, the dreaded white pawn appears in the article and is put in the clipboard.
Yes please. The faster the bug-fixing cycle for beta testers, the better, at this stage of development. By the way, you get exactly the same problem on Macs with their command-X, command-C, command-V keys. -- The Anome (talk) 09:21, 22 June 2013 (UTC)
While I'm editing an article, or more especially a dab page, I may well want to see where the links go. The lead sentence shown on mouseover from an article, or from the old edit system, usually gives enough info to upgrade a dab page entry without having to open the whole article. In VE, I can only see the article title. That's a real negative. Is it a temporary bug? I hope so! PamD19:43, 21 June 2013 (UTC)
You're referring here to WP:NAVPOP, which is actually a custom gadget. The gadget itself will have to be modified to accommodate VisualEditor. (And no, I'm not volunteering to do it; the NAVPOP gadget code is a terrible mess and really needs to be rewritten!) — This, that and the other (talk)01:32, 22 June 2013 (UTC)
I lose track of what's a gadget, what's built in. This gadget is extremely useful for checking the links in any article - "does it go where the editor means it to?". I feel lost without it (I tend to check links etc while stub-sorting, if the article looks a bit iffy.) PamD07:44, 22 June 2013 (UTC)
Title of infobox displaying with code, outside the box
The infobox template had some bad syntax; I've repaired it. In case you're wondering why VE choked, it tends to be more "strict" on correct wiki-syntax than the regular MediaWiki page viewer. — This, that and the other (talk)01:36, 22 June 2013 (UTC)
Thanks, for explanation and fixing the problem. I thought it might be something like that. PamD07:52, 22 June 2013 (UTC)
When I try to use VisualEditor to edit some articles such as Yellow Submarine (song) or Eleanor Rigby, I get an error stating "Error loading data from server: parsoidserver-http-bad-status: 500. Would you like to retry?" However, I don't get this error on other articles such as Wilmington, Delaware. I get the error on Windows 7 with IE10 and Firefox 21. GoingBatty (talk) 23:05, 21 June 2013 (UTC)
I get that too on both those pages (also Win7 FF21.0). The page stays in its greyed-out state for about 25 sec, and then that message appears. JohnCD (talk) 10:14, 22 June 2013 (UTC)
That happens if you click outside the edit summary box - see 'Clicking outside the "Describe what you changed" box locks it' higher up this page. JohnCD (talk) 10:20, 22 June 2013 (UTC)
No, they mean they can't reposition the cursor in text they've already submitted. I've just tested, and they're right. Okeyes (WMF) (talk) 10:27, 22 June 2013 (UTC)
The browser has a perfectly good one-line text box, which does all this stuff without it being reimplemented by hand ... - David Gerard (talk) 16:22, 22 June 2013 (UTC)
Can't expand hatnote without retyping whole thing
I made this edit in "Edit Source" because I couldn't see how to do it in VE. I don't want to have to retype a whole hatnote just to add an extra couple of un-named parameters. Am I missing something, or is VE missing something? PamD13:05, 22 June 2013 (UTC)
Overly long wiki links
When inserting a link to Hawaii with the text Hawaiian, it did not simplify the link to ((Hawaii))an. Is this going to be fixed? autoED fixes that kind of thing pretty readily, as does AWB. Many thanks. Jamesx12345 (talk) 21:16, 22 June 2013 (UTC)
Copy-pasting a section with a header "de-headers" it
Starting with this test page in edit mode, I selected everything above "Second L2 header" by putting the cursor at top left and dragging it down to the start of the "Second L2 header" line. Then I did right-click/copy, placed the cursor at the bottom of the page, and did right-click/paste. The result was this: everything has copied correctly except that the first header is no longer a header. The diff shows that the == == have been removed from it, and a mysterious ==<nowiki/>== has appeared at the bottom. I have tried other variations and the results are consistent: the top header loses its == == and ==<nowiki/>== is added at the bottom of the pasted section. JohnCD (talk) 21:55, 22 June 2013 (UTC)
Template:sfn instances are being completely changed
When editing an article using {{sfn}} references, {{sfn|Smith|1990|p=20}} is now expanded into something like <ref name="FOOTNOTESmith199020">[[#CITEREFSmith1990|Smith 1990]], p. 20.<ref>
However, it appears I cannot yet edit these references with the visual editor. This stops any serious use (i.e. testing) of the editor, even on drafts in user space. Edgepedia (talk) 14:44, 7 June 2013 (UTC)
Okeyes, I'm sorry to say that's an unacceptable answer. As I understand this problem, the mere act of using VE to edit an article to do something as mundane as inserting a missing space between two words of text converts every{{sfn}} (and probably {{sfnp}}) into a spasm upon saving the article. Take for example, this edit that I reverted yesterday. The whole point of {{sfn}} is that it is a short footnote, and while the links still function, I suspect that waiting until beta to unwind that watch will be a challenge. Therefore, IMHO, this is a data corruption that added 2000+ bytes to the article, and a classic example of why one should never do alpha testing against live production data. The alternative, of course, is a temporary kludge that prevents the editing of any article containing shortened footnotes, which is an equally unattractive choice. Try explaining that to a newbie. —Grollτech (talk) 06:02, 19 June 2013 (UTC)
@Grolltech: Well, the VisualEditor it exists now is pretty difficult for a newbie to enable (newbies tend not to be familiar with the intricacies of the user preferences interface). I'd argue that this is a classic example of why tests should be run against production data - things like the sfn template do not exist on newly created wikis, since they're entirely of the users' creation. If we'd alpha-tested on prototype-wiki or test-wiki this bug would have come out when we deployed fully, and I don't think anyone wants that to happen.
The bug will be fixed by the beta; I'm sorry that this isn't acceptable to you, but it's the best I can offer. The Sfn and Efn templates have multi-layered ref tags in them, which is not something MediaWiki normally does (and is the source of this problem). It's not that trivial a problem to fix, and as this page demonstrates there are quite a few pretty high-priority bugs. In terms of unwinding the watch, the software is an alpha and its ability to produce weird output is a known; people should know to check their edits when they've hit save. For those who don't, there's a tool for that. Okeyes (WMF) (talk) 09:05, 19 June 2013 (UTC)
@Okeyes (WMF):There's a subtle but critical difference between our statements. Yes, such tests should be run against production data – but against a copy of that data, never live production data. Yes, it's important to do a real-world test, but to actually sacrifice your real world in the process is suicide. —Grollτech (talk) 12:09, 19 June 2013 (UTC)
Except that's never going to work. Okay, so all the templates, categories and user-specific gadgets are on enwiki, fine; let's say we create visualeditortestwiki.wikimedia.org, transfer a complete copy of enwiki over. It'd be a total pain, but it's doable. What then? Well....nothing, because ultimately the best defence to a ton of bugs is the "many eyes" strategy. We need a lot of users hacking away at the VE to get out major bugs - automated QA tests, a small handful of volunteers and the developers is not going to be enough, and as someone who has been doing this job for almost two years it's pretty much impossible to convince large numbers of users to migrate to a secondary, soon-to-be-deleted wiki and play around with something. It's, even if a perfect clone of enwiki, not their native environment. When we released Page Curation we'd run it against a relatively-complete copy of enwiki (for the area it was in) and found a load of bugs - and when we released, we found a load more, because we had a lot of users actually using the software. Many of the bugs highlighted on this page would not have been found even on a perfect copy, because there simply wouldn't be the people available.
If we were actually sacrificing, to use your term, production to run these tests I might feel differently, but we're not. The editors testing the VE have been pretty good at cleaning up after themselves - the example you provided, and one edit I made where rollback failed, are the only examples I've seen of people not treating the VE as it should be treated: with caution. Sacrificing is not a term I'd use, because it's not what's happening here. Okeyes (WMF) (talk) 12:25, 19 June 2013 (UTC)
These are some minor graphical/usability glitches that someone else may have mentioned but I didn't see it mentioned anywhere else. These are all in Firefox 21.0.
The drop down tab that reads "Paragraph Heading 1 Heading 2, etc" is transparent at the top. When transparent such as in that image I am also unable to click on Header 1. Also, clicking on paragraph accidentally clicks on Leave Feedback.Is there a way to make that drop-down menu opaque at all times?
In order to read Heading 6 and preformatted I have to scroll down below External Links. The drop down menu should perhaps have a scroll bar that allows you to scroll down it without moving to the bottom of the screen?
@AioftheStorm: can you try those actions again and let me know if the problems are still occurring? Sorry to be a bother, but we've updated the VE version deployed here since the above problems occurred, and I want to check the issues aren't resolved before pestering the devs :). Okeyes (WMF) (talk) 09:35, 19 June 2013 (UTC)
I didn't realize this was replied to! Sorry for late reply, but yes the glitches have all been fixed. Although deleting the text from a header, without deleting the header fully, still results in a blank header with a nowiki tag. I think VE should just automatically delete any header that has no text in it, otherwise you end up with an invisible header, but either way it's not that important.AioftheStorm (talk) —Preceding undated comment added 00:54, 25 June 2013 (UTC)
Some funnies
On this simple test page, if I wish to add something at the top, I put the cursor at top left, just left of the "H" in "Header", and press "Enter". The page moves down, as expected, but the cursor is left to the right of the H.
Pressing the "Up" key now moves the cursor to the start of the line above, as expected, but anything else, like pressing "Backspace" to undo the initial "Return" does not work as it should.
Once having got the cursor up to the top line, pressng "Delete" moves everything back up as expected, but also de-headers the header line, like this. JohnCD (talk) 22:36, 19 June 2013 (UTC)
I've been doing some more research on this. Starting with this simple test page, with the cursor at top left. here are the results of:
One press of the "Return" key This is as expected, adding a new blank line at the top, but the cursor was left positioned to the right of the initial "H", so that pressing additional keys produces unexpected results.
More than one "return", intending more blank lines at the top:
I just changed "32" to "35" on one of my user pages.[26] VisualEditor also saw fit to hack my signature further down the page. Maybe that's why it took so long. (I thought it was editing the whole internet) --AussieLegend (✉) 08:00, 20 June 2013 (UTC)
I don't know about that. I copied the article to my sandbox. It uses templates like {{colort}} and {{color sample}} rather than span codes. A simple edit produced a mess, in which "{{cite book" strangely turned into <span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fwiki.riteme.site%3AUser%3AWhatamidoing+%28WMF%29%2Fsandbox&rft.aufirst=Adrian&rft.au. I also got a rather unhelpful error message, "Error saving data to server: error." But it silently saved the page, although it didn't exit edit mode. This is repeatable; the second edit produced the same error about not being able to save while saving the page anyway. However, it's not consistent, because the third similar change produced no errors. Whatamidoing (WMF) (talk) 08:51, 25 June 2013 (UTC)
Beta deployment in July
I think many People sayed that before but for me an beta version is a software which does the essential things its made for but may have bigger errors. Adding an row to a table is one essential thing. If you are really going to deploy in July you will annoy a lot of people especially if it replaces the normal edit mode in any respect. What about the Combination Alt+Shift+E will it open the "normal" edit mode or the source code what about the hundreds of userscripts which most of the time will do things which are not supported by the new editor by then. So far >50% of my tries I could not do what I wanted to and I only tried the simple things. After so many year why the hurry?--Saehrimnir (talk) 13:13, 20 June 2013 (UTC)
Well, so let's go through in order; first, yes, we're planning a beta release in July - but we're not going to do it with a fundamentally broken product. We were also, as you may note, planning a A/B test - this has been suspended and put off precisely because there are a lot of bugs and we need to fix them before it's workable. We're not going to fling the software out without checking that it can function. When we do release, we will not be replacing the wikimarkup-editing interface; it will remain around for the foreseeable future, in its current form. If you have had specific problems, please let us know; it's kind of hard for us to fix bugs with the software if people don't tell us what the bugs are :). Okeyes (WMF) (talk) 14:26, 20 June 2013 (UTC)
Thats the point the problems I had are no Bugs they are just missing features like table formating and Wikidata access.--Saehrimnir (talk) 14:48, 20 June 2013 (UTC) p.s. ok just saw that wikidata works like normal so maybe it is not so far from having all the needed features after all.--Saehrimnir (talk) 14:55, 20 June 2013 (UTC)
At this time, the normal Wikipedia:Keyboard shortcuts for editing the page takes you to editing the source. There is information on that page about writing your own code to customize keyboard shortcuts if you want to. At the moment, it appears that 22 of the 26 letters in the English alphabet have already been assigned (a, b, g, and o are left). Whatamidoing (WMF) (talk) 09:00, 25 June 2013 (UTC)
Initial thoughts: At the moment I'm used to typing {{convert|100|mi}} to use a template. While the new UI is good for newbies or unfamiliar templates when template metadata is working, it's slower because I have to move my hand from the keyboard to the mouse and back again. Any keyboard shortcuts? Also if I select a template and press control-x, surely that should cut it into the paste buffer? Edgepedia (talk) 16:40, 20 June 2013 (UTC)
Thanks for the bug reports (although I'm sorry, of course, that you had to see the bugs ;p). Some of those issues (the blue rectangle, ferinstance) are known, but some are quite new - I'll throw them in now. I can'tsee the loss of a caption in the first diff; can you point me to the line number? Okeyes (WMF) (talk) 17:25, 20 June 2013 (UTC)
After checking, I see both first two condition already appear at step 2, but they persist after saving and only return to normal after refresh. --WS (talk) 12:39, 21 June 2013 (UTC)
That's just weird :/. I mean, the VE not perfectly rendering internally is, I think, understandable, although it will be getting better at that, but it shouldn't be screwing up after save. Can you give me an example article? Okeyes (WMF) (talk) 13:01, 21 June 2013 (UTC)
Scaphoid fracture, to give a simple example. Increased spacing in the infobox even persists after cancelling editing, while the navbox template looks normal then. --WS (talk) 15:16, 21 June 2013 (UTC)
Something like that happens to me too with the infoboxes and the templates. When I hit "save page", the lists that should look collapsed they are not and the hide/show option is gone. But when I refresh the page everything looks normal again. TeamGale (talk) 21:48, 23 June 2013 (UTC)
Removing PROD template also took out infobox
With this edit, the first time I have dared to use VE on a live article, I intended to remove the PROD template (which I did not find easy or intuitive - I will explore that further and comment separately) and add a "notability" template (which went fine). However, VE also took out an infobox. JohnCD (talk) 20:13, 21 June 2013 (UTC)
I'm not sure, and when I tried to repeat it just now I got a completely different result - the template was not removed, but <span data-mw="{"parts":[]}"></span> was added in front of it. I am really struggling with "remove template": I made five attempts just now, the first four of which got nowhere or locked up. I will try again soon and write a blow-by-blow account of what I do and what happens. Could you give a brief description of how removing a template is meant to work in VE? It's a common task, e.g. when declining a speedy or restoring a contested PROD. JohnCD (talk) 10:55, 22 June 2013 (UTC)
Well, the VisualEditor tends not to be built around individual project policies. Categories are added right and the end, on the grounds that they are effectively metadata rather than actual data. Strictly-speaking the same is true of stubs, but the VE does not have a way of determining that a template is a stub template. Okeyes (WMF) (talk) 10:13, 22 June 2013 (UTC)
If I refer to it as Wikipedia:Manual_of_Style/Layout#Order_of_sections, does that give it more weight? The rule that stub tags go at the end isn't an "individual project policy", it's part of WP:MOS. VE could surely use the rule of "a template which either is {{stub}} or has a name ending in "-stub" is a stub template": they aren't hard to recognise. (We need both versions, rather than just "template with name ending in "stub", just in case there's a navbox for a band or place called "beerstub" or something like that.) PamD13:02, 22 June 2013 (UTC)
Well, it is an "individual project policy", in that we are an "individual project" of the Wikimedia Foundation, and it is our policy. I don't know how keen the VE team will be to support this.
In case the VE coders want to know the reason for this rule, it is to make sure stub categories are listed after all the other non-hidden categories at the bottom of the page. — This, that and the other (talk)07:28, 23 June 2013 (UTC)
"Userspace draft" template displays incorrectly while being applied
The {{Userspace draft}} template is designed to display differently depending on the type of page it is on. When using VE to add it to a user sub-page, clicking "Apply changes" shows the "This page is a new unreviewed article... " version appropriate to a mainspace article page, but when the page is saved, what appears is the correct "This is not a Wikipedia article: it is an individual user's work in progress page... " version appropriate to a user page. JohnCD (talk) 22:06, 21 June 2013 (UTC)
Not sure whether this is a visualeditor or chrome bug: whenever I try to cut & paste the commons category template, it crashes the chrome tab at the moment of pressing command/x. Ran into this on Pancytopenia, but it happens on any page using this template. It does not happen with any other template that I have tried. This is on Chrome 28 on mac, on safari it works fine. --WS (talk) 11:47, 22 June 2013 (UTC)
This edit was intended to just change one link in the intro paragraph: not only did it not do so correctly, it also made spurious edits througout the rest of the article.
One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)
As ever, please keep up the good work: this is intended as constructive criticism, not an attack, you're making fantastic progress on solving a very difficult and ill-defined problem with hundreds, if not thousands, of awkward corner cases, and I'm impressed by how much the VisualEditor has improved in recent weeks. -- The Anome (talk) 11:59, 22 June 2013 (UTC)
I just wanted to add {{in title|pork}} to Pork (disambiguation), but can't see how to do it in VE (now done it in Edit Source). Similar problem to the hatnote issue above, but simpler. PamD16:55, 22 June 2013 (UTC)
OK, found it now - type the pipe and parameter after the template name in its box. Not intuitive, when you know there's a "parameter" box. Ah well, I know now. PamD16:59, 22 June 2013 (UTC)
I found that typing "1" as the parameter name worked for a one-parameter template, and I guess "2" etc might work for more parameters. See "Parameter name" further up this page, which has a Bugzilla link. JohnCD (talk) 17:20, 22 June 2013 (UTC)
We're working on deploying TemplateData, which will have lovely descriptions for each parameter, and getting the VisualEditor to automatically pull all the possible parameters out of that :). Okeyes (WMF) (talk) 00:30, 24 June 2013 (UTC)
Starting with this test page in edit mode, as in the test above, I again selected everything above "Second L2 header" by putting the cursor at top left and dragging it down to the start of the "Second L2 header" line. Then I did right-click/copy and in a new, empty test page in "Create" mode did right-click/paste. The result was this - all formatting lost. JohnCD (talk) 21:57, 22 June 2013 (UTC)
While making this edit to CBS Studio Center, I was surprised to see that the entire bulleted list of TV shows can only be edited with markup, even inside the VisualEditor. The list is contained between a pair of column-sorting templates – {{div col|colwidth=21em}} and {{div col end}} – which VE treats as one transclusion. Everything in between the two templates can only be edited by opening the transclusion editor and clicking on the "Content" tab, at which point you are given the exact same raw code to edit as if you had opened the source editor (except it takes several extra clicks to get there and the editing window is much smaller). Obviously I don't mind having to use markup, but it's going to be a problem for all those newbies VE is supposed to recruit. Thatotherperson (talk/contribs) 10:54, 23 June 2013 (UTC)
So, what, you expect someone to completely redo how those templates work for the sake of VE? I can't picture anyone taking the time to do that if the VE development team doesn't do it themselves. Why can't VE just show a separate puzzle-piece icon for each template when you click on the content in between? Surely VE could be programmed to treat them as separate templates, considering the source code shows them that way. Thatotherperson (talk/contribs) 10:05, 24 June 2013 (UTC)
Plausibly, and that's something that can be linked into, but it sounds like a good way of having an infinitely nested list of template inspectors - particularly since a lot of templates legitimately include other templates you wouldn't want to open. As for the VE team doing it themselves - do you know how many templates there are on enwiki alone? We're deploying this to 300 wikis; it's not a viable plan of action to have developers modifying every template that needs modifying unless we're okay with not fixing bugs with the software proper. Okeyes (WMF) (talk) 13:27, 24 June 2013 (UTC)
Alright, but when you classify it as a "templating problem rather than a VisualEditor problem", I hope you don't think it falls outside the domain of the VE development team. Everything VisualEditor can't convert from code to WYSIWYG is a VisualEditor problem. The people who edit templates don't have a stake in making them more editable for newbies. You guys, the VE development team, are the overlap between people who know how to edit code and people who want everything to be editable without code. No one else is going to fix it.
As for the infinitely nested template inspectors, I think you may have misunderstood: it's not a template inside a template, it's two separate templates with a bulleted list in between. VE treats the first template as the beginning of a transclusion and the second template as the end of the transclusion. I'm saying the list should be editable without opening the template inspector at all, and there should be two puzzle-piece icons – one above the list and one below – for anyone who wants to edit the existence or nature of the templates, rather than simply editing the list in between. Thatotherperson (talk/contribs) 06:39, 25 June 2013 (UTC)
VE makes changes to formatting on lines that are not being directly edited
I see that the VisualEditor has a new button for editing references. What is the button image supposed to be? I had to rely on the mouseover to discover what it was. I thought I'd try it out on Joe Flacco by changing the date format on reference #26. I went into Edit mode, went to the "2012 season: Super Bowl MVP" section and noticed that some references displayed as [25] while others displayed as [25]. Also, what is marked as #26 in Read mode is marked as #24 in Edit mode. I highlighted [24] and the Reference button appeared, so I clicked on it. The Reference content window appeared, and when I clicked on the reference, it was highlighted in blue and a new button appeared in the bottom right, but there was no icon on the button and clicking it didn't do anything. Instead, I clicked on the Transclusion button in the toolbar, changed the date parameter, clicked Apply Changes, another Apply Changes, and Save page. Although the reference change in this edit was great, the change also incorrectly added <nowiki>...</nowiki> tags in the infobox, so I reverted the change. GoingBatty (talk) 14:01, 23 June 2013 (UTC)
@Okeyes (WMF): - Thanks for all your responses to the feedback posted here. In this section I detailed four different issues - hope you're tracking all of them (some may be duplicated above). I also hope you'll let us know when the bugs are fixed so we can retest for you. Thanks! GoingBatty (talk) 01:39, 24 June 2013 (UTC)
We are :). The one thing that was confusing me is the different size for [25] - it looks like that's because you're relying on Template:R, which is being interpreted weirdly :/. Okeyes (WMF) (talk) 13:28, 24 June 2013 (UTC)
@Okeyes (WMF): - Does {{sfn}} have the same issue? When looking at Michelle (song), the rendered page uses one integrated set of reference numbers for <ref> and {{sfn}}. However, in VE edit mode, it appears that the <ref> references are numbered separately and formatted differently than those with {{sfn}}. Another implication of this is that I can't seem to figure out how to edit reference #5 (Dominic Pedler. The Songwriting Secrets of the Beatles. Music Sales Limited. Omnibus Press. NY. 2003. pp435-437). Thanks! GoingBatty (talk) 23:48, 24 June 2013 (UTC)
Is there any way to get HTML comments (<!--...-->) to show up when editing? In the current system, these are used quite frequently, yet there appears to be no alternative in Visual Editor at this time:Jay8gInspect-Berate-KnowWASH-BRIDGE-WPWA-MFIC15:23, 23 June 2013 (UTC)
Is anyone aware of any issues when Dot's Syntax Highlighter (a gadget available under editing in your preferences) and the Visual Editor are both enabled? It seems like these two would interfere with each other, and probably shouldn't be enabled simultaneously. I, Jethrobotdrop me a line (note: not a bot!) 15:35, 23 June 2013 (UTC)
Chiranjivi: I pressed Delete after "Chiranjeevinaha[citation needed]", however the quote disappeared (as though backspace was used) and the undo was also not working.--RedtigerxyzTalk17:48, 23 June 2013 (UTC)
After you make your changes and click the "Save page" button, you should see a new section that says "Describe what you changed". Type your edit summary there and click the "Save page" button again. If that doesn't help, please provide more detail as to the specific issue you're having. GoingBatty (talk) 18:36, 23 June 2013 (UTC)
I don't know about other editors but sometimes for complex edits I like to go back and forth between the edit window and edit summary box to keep track of what I've been doing. Now I have to remember it all until later? —David Eppstein (talk) 20:41, 23 June 2013 (UTC)
Alpha or beta?
Is VisualEditor in alpha or beta testing? Although this page requests feedback for alpha testing and Wikipedia:VisualEditor states beta testing is scheduled for July, the VisualEditor itself says "BETA". Note that it's not obvious that "BETA" is also a button to submit feedback. GoingBatty (talk) 18:48, 23 June 2013 (UTC)
It's currently beta software in an alpha release (and if that makes more sense to you than it does to me, more power to you). Things should be in sync in a couple of days :). Okeyes (WMF) (talk) 13:19, 24 June 2013 (UTC)
Hidden feedback button
I'd never have expected to find the "Feedback" button hidden under "BETA", until seeing someone mention it on this page. Could it be made more obvious? Perhaps rename the "BETA" button as "Feedback"? PamD19:32, 23 June 2013 (UTC)
The rationale is that the moment we mark it "feedback" we get a billion and one comments on every page impression if the news about the VE covers a substantial area. Okeyes (WMF) (talk) 01:11, 24 June 2013 (UTC)
This might have been mentioned up the page, but I'm not sure if it's the same thing: In this edit, besides doing nice things (like removing duplicate images in the infobox) and meh things (like changing <ref name=foo /> to <ref name="foo"></ref>), VisualEditor also removed an HTML comment in the infobox. This seems to be in line with the "get rid of whitespace in infoboxes" that it was also doing, but comments should be exempted from that, I'm thinking. Ignatzmice•talk19:58, 23 June 2013 (UTC)
When I added a couple of External links, VE decided to alter a repeated reference elsewhere in the article from <ref name=uhmb /> to <ref name="uhmb"></ref>. Not an improvement: I always choose reference names without spaces so that I don't need to use quotes round them, and I've always understood it to be correct to close the ref tag within the one occurrence (as shown in Help:Citing_sources#Repeated_citations). VE's version is very clunky, and a long way from the lines I was editing. It should not be making this change. PamD20:20, 23 June 2013 (UTC)
I'm getting timeouts again ("Error saving data to server: timeout.") reviewing or saving on OpenOffice. This is still a thing that should never, ever, happen. Is there any way to measure where the time is going? - David Gerard (talk) 21:04, 23 June 2013 (UTC)
I didn't get a timeout error when I used VE to make this edit to the OpenOffice article. I did experience two other issues:
VE made changes to formatting on lines that were not being directly edited, which the user guide says VE won't do.
In Edit mode, the infobox covers the right hand side of the lead, making some portion of the lead uneditable.
I have just enabled VisualEditor and made my first edit ([29]). I was updating a section further down the page but the editor made some bot-like formatting changes further up the page without me knowing. These were useful changes, but I didn't know it was doing them. Cloudbound (talk) 22:31, 23 June 2013 (UTC)
On my small computer (1024X600), the save page and review changes boxes appear very small with not very legible text, making it almost impossible to write an edit summary and see wikitext changes, as if it is scaled to the computer's screen size. This appears to be a recent change, as it worked fine as recently as yesterday:Jay8gInspect-Berate-KnowWASH-BRIDGE-WPWA-MFIC02:56, 24 June 2013 (UTC)
That happens to me too, but I don't think it's because of the italicised cause I didn't italicised the text. I don't know why it happens. When I click "CTRL+K" on a blank page while I am typing, the "link box" appears and I type what link I want to add straight there. After choosing the link and clicking "enter" the link appears twice on my main text. Something that doesn't happen if I write first on the text, then highlight it and then click "CTRL+K" to make it a link. TeamGale (talk) 08:24, 24 June 2013 (UTC)
I experimented further and for me it seems that bolding or italicising part of the term will create two links, while VE is happy with commas and brackets: I'll copy the results here. In each of these cases I chose "Silverdale, Lancashire" from the choice of targets offered; thr first three give a single link, the other four give two links.
And if anyone is thinking "Why would anyone want to link from something with different format?", one answer is in adding entries for disambiguated books, films, etc to dab pages - as in my original example above, of Demolition (1978 film). PamD13:58, 24 June 2013 (UTC)
I decided to experiment with VE in my sandbox ... and {{User sandbox}} which starts off "This is the user sandbox of PamD..." is displaying in non-roman characters (Japanese?) and has the name "Ichiro Kikuchi". Disconcerting. PamD13:41, 24 June 2013 (UTC)
Hey all. We're looking to start the A/B test in a couple of hours. My sincere apologies for the short notice :/. If you notice any new bugs, or any substantial problems, please bring them to us as soon as possible so we can resolve them; we'll be monitoring the situation closely and will be able (and willing!) to disable it or put the test off if there's something big that needs resolving. Thanks, Okeyes (WMF) (talk) 15:58, 24 June 2013 (UTC)
I think (and have said at WP:AN) that it is extremely unwise to throw VE open to newbies before you have cured the bugs which make unasked-for changes in other parts of the page. JohnCD (talk) 19:15, 24 June 2013 (UTC)
Newcomers generally haven't used it so far, because you have to know about it and find your way to "Preferences" and turn it on. JohnCD (talk) 19:38, 24 June 2013 (UTC)
The entire point of the A/B test is that the accounts have it enabled by default, so they don't. If you look at the recentchanges feed under the visualeditor tag you'll see quite a few people using it. Okeyes (WMF) (talk) 19:52, 24 June 2013 (UTC)
Sorry: I thought you meant, prior to the A/B trial you had only seen two VE newbie problems, and I was saying, that's because prior to the trial newbies weren't using it. Yes, the trick is to watch the RC list for the combination of the "New editor getting started" and "VisualEditor" tags. JohnCD (talk) 20:18, 24 June 2013 (UTC)
Yep. Actually the getting started thing is also being tested, so only some of the newbie VE edits will have it; I've been using 'redlinked userpage' as a (pretty reliable) heuristic filter to make sure. Okeyes (WMF) (talk) 20:26, 24 June 2013 (UTC)
Oh, also, another complaint is that the font size in the edit summary box is hideously small, that even I (who has generally good vision) have to squint to properly see what I've written. Insulam Simia (talk/contribs) 17:57, 24 June 2013 (UTC)
Hmm, mine seems to be displaying as the same size as the rest of the text on the page. Is there a difference between the edit summary text size and the page text size? Which browser are you using? PEarley (WMF) (talk) 18:05, 24 June 2013 (UTC)
Voodoo mind-reading time; Insulam, you're using monobook. Pat, you're using vector :). This is a known bug, and something we're working on. Okeyes (WMF) (talk) 18:16, 24 June 2013 (UTC)
This test just now is a repeat of one I reported earlier, where copying a block of content "de-headered" the top header and added a supurious ==<nowiki/>== at the bottom. What I did not notice then was that in the third line, where the word "both" had five apostrophe characters each side to make it bold and italic, VE has stripped off three of them after the word. The effect is that the following words "at once" appear in bold. What is odd is that after doing the copy-paste, "at once" does not appear in bold; that only happens after the page is saved.
I then tried to make a simpler demonstration to show this effect, but here where I copied and pasted a single demonstration sentence within the same page to show the effect, I didn't get it; instead, all the formatting was lost.
If, when editing a page with a large template like {{prod}} or {{db-person}}, you click on the template, it is covered by a blue highlight, but so also is a separate broad, shallow rectangle at top left of the page. I found this disconcerting when I began experimenting with templates, though it doesn't seem to do any harm. It does not happen with a smaller template like {{notability}}. JohnCD (talk) 19:32, 24 June 2013 (UTC)
I know it was mentioned before but I don't know if it's the same bug (or bug at all) since the other user was saying that it was happening while using Italics or Bold format.
When I am writing an article and I want to add a name-link, I click CTRL+K so that the link box appear. When it appears, I type the name there, I am choosing it from the list and click enter. But when I click enter, the name appears twice on the article.
Yes, I'm getting this too. If I can't find it in an existing report (or if Oliver doesn't come along and point it out for me), I'll start a new one. PEarley (WMF) (talk) 22:08, 24 June 2013 (UTC)
When I've been using VE, I've been saving my changes and then reviewing the page history to see exactly how VE updated the code. From now on, I'll be clicking the "Review your changes" button, so I can see exactly what VE will be changing before choosing to click "Save page". GoingBatty (talk) 23:34, 24 June 2013 (UTC)
I've seen this before, and reported it as part of a more complex issue. Here it is, isolated: if you make an edit where there is something in both bold and italic, so that there are five ' characters each side, VE strips out three of them from the second set, so that following text appears in bold. This is not apparent as you make the edit, only when you save the page. Note added to Bugzilla. JohnCD (talk) 09:57, 25 June 2013 (UTC)
I added (moved) an external link, it killed the navbox...
Making this edit, it did something really odd (I can't figure out what) which made almost all of the links in the navbox pop out of the table and above the header. Also, the header text disappeared. Very strange...:Jay8gInspect-Berate-KnowWASH-BRIDGE02:35, 25 June 2013 (UTC)
As I was editing History of Delta Air Lines, I noticed that when there are multiple images in a row at the start of a section, such as the sections "1960s and 1970s" and "Merger with Northwest Airlines", they show up at the top, not their actual positions, and they are not editable, with diagonal green stripes covering them. All the other images are normal:Jay8gInspect-Berate-KnowWASH-BRIDGE02:56, 25 June 2013 (UTC)
Could we please add a countdown to the current watchlist notice that says something like "The default editor will switch to the Visual Editor in ___ days" so that people will know when it's going to happen? or tentatively scheduled to happen Thanks. 64.40.54.119 (talk) 03:33, 25 June 2013 (UTC)
No. I agree that it should, but it doesn't. When you click the "Bold" icon on something that is already bold, on the screen it changes to look even bolder, but what VE does is add three more ' characters each side, like this, so that when saved it ends up bold, italic and enclosed in single quotes, like this. Clicking the "Italic" icon on something that is already italic makes no visible change on the screen, but adds two more ' each side, so that when saved it ends up bold but not italic and enclosed in single quotes, like this. JohnCD (talk) 11:13, 25 June 2013 (UTC)
Probably related to some of the problems mentioned above, but here I wanted to change [[Portsoy]] to [[Grange]]. Changing the link target is easy, it's not so changing the displayed text. Edgepedia (talk) 11:17, 25 June 2013 (UTC)
Oh, another complaint I like to file is that I can't highlight and drag text to another location in the article, meaning I have to cut and paste it. This is annoying since I prefer using the first method. Insulam Simia (talk/contribs) 15:53, 25 June 2013 (UTC)
couldn't figure out how to add citation-needed tag
I tried the visual editor because I want to be helpful, but I could figure out how to add a {{cn}} tag, so I went back to the editor I've been using since 2006. Leadwind (talk) 17:29, 25 June 2013 (UTC)
Leadwind, you can use the "puzzle piece" icon on the toolbar to add temps - just type in the name of the template into the prompt, and it will drop it in for you. It works for cn, seems to having trouble with some other templates though. PEarley (WMF) (talk) 18:40, 25 June 2013 (UTC)
First issue: When I named the parameter 1 for {{User:Charmlet/me}}, it named it 1= = content, instead of 1=content.
Second issue: There is no subst: option short of putting subst:TEMPLATENAME into the box, which ruins the search feature.
Third issue: There's no way to pull in the parameters and/or reference templates {{cite}}{{cite web}}{{cite news}} etc.
Fourth issue: The reference has spaces before and after the = sign, which can, if I remember right, have undesirable effects on reference parameters.
Unrelated issue: The icon for references is not very intuitive. The reference one, at first glance, looked like a city skyline, and nobody in the IRC help channel who is a new user has been able to figure out how to use it for references. One even tried to plug in the reference content as the group name for the "reference list" icon, since it looks like a reference.
One more - Heading 6 produces (if my eyes don't fail me) the same as bold in appearance, so new editors may feel it's okay to just use bold. Maybe a distinguishing feature could be added in VE to make it obvious it does more than just bold? Charmlet (talk) 20:55, 25 June 2013 (UTC)
Charmlet - Not sure about the first, I'll ask someone more savvy. The second is covered under Bug 49904. Could you explain the third in a bit more detail. The fourth I've been noticing a lot, I think it's tracked but I'll make sure. The unrelated is bang on, agree muchly. PEarley (WMF) (talk) 23:38, 25 June 2013 (UTC)
Okay, so if I read this right, the third is the only one needing more explanation? Here goes -
When using {{cite web}}, there's standard, named parameters one uses to make the citation. These are automatic fields in the RefToolbar (more here), but now you actually have to type in the parameter names, which requires having the documentation open. It'd be easier if the reference button was made more like the RefToolbar used to be :) Charmlet (talk) 23:45, 25 June 2013 (UTC)
This is true. The template dialog needs to list supported parameters. The RefToolbar is one of my favourite tools, and its functionality needs to be built in to the new platform. I believe this is covered by Bug 49833PEarley (WMF) (talk) 00:20, 26 June 2013 (UTC)
I changed some text, and there were some side effects mentioned above, such as <ref name="BP&HBR"/> was changed into <ref name="BP&HBR"></ref> and the {{London Gazette}} and {{cite web}} template transclusions had spaces added either side of the equal signs.
Changed a page number using the tranclusion editor. The transclusion was duplicated and more spaces added.
{{sfn}} and <ref> are numbered differently in the edit view.
I next tried to change a template inside a reference, however this wasn't recognised as a change and I wasn't able to save it, and I wasn't able to open another reference. Edgepedia (talk) 21:20, 25 June 2013 (UTC)
When I made this edit [34], it turned {{Chicago Blackhawks roster}} into {{Chicago Blackhawks rost, even though I wasn't editing anywhere near that section. HueSatLum22:26, 25 June 2013 (UTC)
When I click on a picture, the vertical rectangle with the picture icon appears, but it is not clickable. Instead of the mouse acting like it is a link (showing a hand icon), the mouse icon just wants to move the image (showing as 4 arrows). (Firefox 21, Windows 7):Jay8gInspect-Berate-KnowWASH-BRIDGE00:33, 26 June 2013 (UTC)
Yes, something is screwball with that mini mountains icon. It's also creating a blue shaded area on the top-left of my screen. If this persists, I'll do a report. PEarley (WMF) (talk) 00:47, 26 June 2013 (UTC)
When using Page down on the keyboard, tables are shifted to the left, the left cells are not visible any more. If I use the down arrow, no problem.
The table about "100 plus grands succès français" is oddly layed out (column size, italian flag on line 76 is huge, …)
I only removed internal links (links from 1 to 30) : in about 10% of the time, in the hyperlink window, the link was shown as being to a missing page which is false (all pages exist).
Other modifications have been done by VE in places I have not modified : doubling whitespace before « : », removing spaces in references names (not a problem), several modifications in tables (adding « " » around « center », …).
I'm using Chrome 27.0.1453.116 m. The problem with the shifting to the left doesn't appear on the first page down, rather on the second one (maybe dependent on the screen resolution ?). In fact, it's not only the tables that are shifted to the left but the whole article. If I go back to the first line, the contents is scrolled back correctly. Do you need a screenshot ? --NicoV(Talk on frwiki)16:59, 26 June 2013 (UTC)
Screenshot available here. There's not a lot of answers on frwiki recently, so I preferred to post my initial message both on frwiki and enwiki. --NicoV(Talk on frwiki)18:11, 26 June 2013 (UTC)
It would be very nice if the linking dialog would prevent you from linking to an disambiguation page or at least give you an idication that you are about to do so and you normally should choose a better target.--Saehrimnir (talk) 11:06, 26 June 2013 (UTC)
It would, but how would that work, exactly? MediaWiki doesn't know that something is a disambiguation page. The best we could do is have it read through the templates in the target article looking for a disambiguation template - which (1) sounds like it would slow things down for the end user and (2) wouldn't really work, since this is going to be launched on ~200 wikis :/. Okeyes (WMF) (talk) 13:18, 26 June 2013 (UTC)
Things that are expensive put a lot of strain on the server where such should not be necessary. It says something about the current feasibility, not about the desirability. —TheDJ (talk • contribs) 16:16, 26 June 2013 (UTC)
In de:wikipedia there is also this gadget which highlights them [35] I think based on the index. So the tech is already there but I don't know how expensiv does not seem to slow things down to much even with the sites in the fixing project like this [36] which consist mostly of disambiguation links.--Saehrimnir (talk) 15:08, 26 June 2013 (UTC)
Sounds a really useful suggestion - though not "prevent" but "warn strongly against and need a conscious decision to proceed with" or similar: people editing dab pages or hatnotes need to be able to link to dab pages deliberately sometimes. PamD15:12, 26 June 2013 (UTC)
Indeed. I've added a tracking bug; I'd note (in regards to Wbm's contribution above) that indeed, it needs to be balanced - and that "So what if it slows things down for all of our editors?" is not a particualarly convincing start to a counterargument. Okeyes (WMF) (talk) 16:10, 26 June 2013 (UTC)
I can see categories when I read an article. I can see them below the editing paraphernalia when I'm in Edit Source. But in VE I can only see them by clicking "Page Settings", which (a) takes a click and (b) means I can't see any of the article content (eg the hard-to-remember-the-spelling district name, the birth date, etc which I might want to use in creating categories, having seen that they aren't already there). Please display the categories in or around the article, not just as "Page settings". PamD13:43, 26 June 2013 (UTC)
I made comments a week ago about Functional Specifications and testing schedules which have now scrolled off this page- and a lot of hard work has been done since on exception debugging. I am still not willing to opt into this software while it is so flakey and producing so many fatal side effects. Obviously it is a brilliant aspiration and obviously a lot of us are going to have to spend a lot of time cleaning up pages where it has been used. If I am working with newbies- the principle function I need is {{sfn}}{{efn}} and associated referencing tools. As this software can't do that- can I suggest an easy damage limitation measure.
Encourage the user to state in plain text in the Edit Summary box where she found the information- so a simple pseudo reference is included next to/ or in the VE-Tag in the edit summary. This could be a simple as putting two text mandatory input boxes instead of one. The first labelled: What changes have you made?, the second labelled: Where did you find this information? (name the book or paste in the website address). When referencing is working and stable the edit summary box could quietly change back.-- Clem Rutter (talk)14:03, 26 June 2013 (UTC)
"Mandatory input box" for source? But what about all the content-free edits so many of us make: cleanup, stub-sorting, adding categories, general tweaking. I don't know what proportion of my edits need a reference, but I'd guess around small single-digit percent. Nice idea, but potentially disastrous. Might be useful for article creation, certainly. In fact, extremely useful for article creation, when I think it through. Just not for later edits. PamD15:22, 26 June 2013 (UTC)
Mandatory input would still be a bad idea for new articles. What if you're creating a disambiguation or list article? VE wouldn't be able to tell the difference, as both disambigs and lists are in article space, but neither needs a source to justify its existence as long as the linked pages exist. Making input mandatory would just leave us with a bunch of misleading or meaningless clutter in edit summaries that otherwise would have been blank.
Removed the stub template (having now realised I can just highlight and hit "delete", where previously I thought I had to go to "Transclusions", "Remove transclusion": much easier)
Tried to open "Page settings" to fix the DEFAULTSORT
Couldn't, so will now save page and try again (observing, as I go, that VE is still doing "cleanup" on lines I'm not editing - here removing a duplicate space in a reference. All very well, but I thought it wasn't supposed to be doing AWB-type genfixes).
Click on "Page settings": it opens, though I can't see the top of it because hidden under the top bar of the window - horrible welcome for anyone unfamiliar, as the (cryptic) close button is invisible.
Close it (by scrolling up to make it usable)
Remove stub tag by highlighting and "Delete" key
Open "Page settings" OK, close it
Add two new stubs (having finally found that little "+" which allows me to add a second ... and cursing that I can't see the article to decide which of the subtypes of {{Russia-footy-bio-stub}} to apply as I hadn't memorised whether he's a goalie or a striker, etc)
Still no problems opening "Page settings". Hmm, good and bad.
Try again: Eugene Lies, very similar stub to R G Allen above:
Now can't open "Page settings". (Forgot to try between the two above moves!)
Saved it, re-opened in Edit Source, and in one line of typing "
{{subst:L|missing|missing|Lies, Eugene}} " I've set up the birth and death date categories and the defaultsort. I want to be able to do so in VE with as little effort, please! (Usually there'd be years in there instead of "missing": I do this sort of fix again and again while stub-sorting, as a quick way to add three enhancements to any biog article which lacks them - and to add Category:Living people if the death date is empty.)
Will try once more to identify the stage at which Page Settings jams: Charles H. Johnson
Tried to open "Page Settings" and can't: the cursor recognises the link but won't click
Aaargh- now I can't add a transclusion (ie the right stub template) either: that button too has jammed. It's not all the buttons - I can still add a hyperlink, or bold the text, but regardless of where I put the insertion point on the screen I can't click on the "Transclusion" button or the "Page settings" button. Using VE is an uphill struggle!
I hope this is useful (and apologies if it's all old bugs already in Bugzilla) - will leave in all the above stream-of-consciousness stuff as it shows various aspects of the VE which, to my mind, still need fixing. Good luck with it all - a few aspects are really nice, but a whole lot aren't (yet). PamD14:27, 26 June 2013 (UTC)
The wikilink for "Seistani" in the first line of Gondophares was muddled before, but this attempt to fix it using VE made things worse, because it resulted in "nowiki" tags being placed around the whole phrase, so that subsequent attempts to sort the link out got nowhere. I think adding "nowiki" tags round VE attempts at Wikimarkup probably does more harm than good. JohnCD (talk) 21:07, 26 June 2013 (UTC)
Agree. We're seeing too many nowiki tags in general. One suggested fix is a warning box that pops up when an editor uses markup in the VisualEditor: Bug 49820. PEarley (WMF) (talk) 21:32, 26 June 2013 (UTC)
Template interface is horrifying
So I tried adding a referenced sentence to an article. The edit worked perfectly, so that's good. The interface to enter the parameters was just terrible. Click to add a parameter, click to enter parameter name ... click again to enter a value. How do I add another one? Oh, I click back to the template name. Click to add a parameter, click to ... whoops, put the value in first, that's wrong ... etc. Repeat for each parameter. It was like a command-line enthusiast's parody of GUI interfaces.
Surely a less terrible interface for entering parameter-value pairs is possible? What others were considered? Is this written up anywhere? - David Gerard (talk) 22:12, 26 June 2013 (UTC)
I absolutely agree. After adding a parameter, there should be an option to add another; at present there is nothing but "Apply changes" which takes you back to the article. Even if Templatedata is going to provide an eventual clean solution, we need something better than this in the meantime, because it will be some time before all templates have data. JohnCD (talk) 22:37, 26 June 2013 (UTC)
Earlier, it said, for example, "Heading 1". Now it says "<visualeditor-formatdropdown-format-mw-heading1>". (Note:this is only with the headings, "paragraph" and "preformatted" still work):Jay8gInspect-Berate-KnowWASH-BRIDGE00:02, 27 June 2013 (UTC)
Awesome! Yeah, we're trying to move those around a bit so that well-intentioned people don't automatically run for Heading 1 - which is deprecated pretty much everywhere, I think. Okeyes (WMF) (talk) 02:53, 27 June 2013 (UTC)
It would seem that the section editing links have been changed again. However, this change isn't really working right. When I mouse over the [edit] link by a section heading, it changes to be 2 links-probably intended. Unfortunately, these are "edit" (pointing to what is otherwise "edit source", so vague) and "<visualeditor-ca-editsource-section>" (clearly not what was intended):Jay8gInspect-Berate-KnowWASH-BRIDGE00:08, 27 June 2013 (UTC)
Yeah, I spotted this on launch (just as I went to bed) and ran back to point it out. Thanks for reporting it, however; the more reports of issues we get, the more issues we can fix :). Okeyes (WMF) (talk) 02:56, 27 June 2013 (UTC)
{{redirect|Pērkons|the rock band|Pērkons (band)}} with
{{redirect|[[Perkele]]|Pērkons|the rock band|Pērkons (band)}}
which is incorrect because Perkele doesn't redirect to the article, there is another article with that title. So I use VE to "remove" that parameter, and it does not remove it, rather it replaces it with a null first parameter.
"{{{1}}}" redirects here. For Pērkons, see the rock band. For Pērkons (band), see Pērkons (band) (disambiguation).
Oh, I see. I need to:
cut parameter 2
paste parameter 1
cut parameter 3
paste parameter 2
cut parameter 4
paste parameter 3
remove parameter 4
Hmmm confusing, the Save button wouldn't work, though it didn't seem to be greyed out. But the "Restore" button did work. So now we're making some artificial distinction between save and restore? BTW, along the way I ran into this error:
Error loading data from server: parasoidserver-http-bad-status: 500. Would you like to retry?
I see that to add an "unnamed" first parameter, you have to name it "1". I'll bet a lot of editors haven't figured out that unnamed parameters really do have names ;) Wbm1058 (talk) 02:18, 27 June 2013 (UTC)
Edit summary box hidden under top matter, forcing scrolling; up-arrow exit is cryptic
If I edit even a short article like Edson Leal Pujol but happen to be looking at the bottom of the article when I hit "Save page", the box for the edit summary is largely hidden under the top bar with the editing buttons on it. I have to scroll all the way to the top of the article for the dialogue box to be usable. I can't click and drag it into a more useful place. This is irritating. (Using Firefox on a laptop, if that's relevant).
And within that box, the "upwards arrow" is a bit cryptic for "How do I get out of this without saving the page?" (eg if on looking at the changes made I want to change them... though it's usually easier to just save the page and then sort out the damage in Edit Source!) Could we have "Return to editing" perhaps?
The idea that half of new editors are being thrown into VE is somewhat scary, it's still got so many unresolved quirks. It will be fascinating to see the results, whether this has a higher or lower retention rate. Good luck! PamD13:35, 26 June 2013 (UTC)
OK, have finally managed to make a screenshot (a learning experience: never noticed that "Function" button on my laptop in the 4 years I've had it!), but how do I send it? Wikipedia email doesn't seem to allow attachments. PamD23:19, 26 June 2013 (UTC)
Sorry to steal your thunder, Pam, but is this what you are describing?
That is happening to me too :( And it was not happening before. It started today and it's not really helpful. TeamGale (talk) 00:51, 27 June 2013 (UTC)
I am having the same problem, but mine is a little more dramatic as not only the top but also the part where you leave your message is obscured. Here are the images, the first is me scrolled to the top, and the 2nd is me scrolled a little bit down. I'm using FireFox 21.0, Mac OS X 10.6.8.AioftheStorm (talk) 19:52, 27 June 2013 (UTC)
Hmn. I'm not sure if that's the source of the problem, but either way the problem shouldn't be live. Tracked in bugzilla. Okeyes (WMF) (talk) 13:42, 27 June 2013 (UTC)
Just turned on VE to create a redirect LeeStock. So I figured out how to use the button to create LeeStock without it getting no-wiki'd -- but can't figure out how to stop no-wiki on the #REDIRECT. Not that I've ever seen the text string #REDIRECT as part of a normal English article. Don't want to "cheat" by going to the "edit source" tab. Wbm1058 (talk) 00:20, 27 June 2013 (UTC)
Looks like the eventual plan is to have redirects covered under the "Page Data" dialog "Page Settings" dialog, but hasn't been integrated yet. Might have to cheat for now. PEarley (WMF) (talk) 00:31, 27 June 2013 (UTC)
Null edit
OK, fine, I cheated ;) Now I want to do a null edit on LeeStock Music Festival to remove it from Category:Missing redirects. I figured it out with some effort. At first the "Save page" button is "greyed out" (or whatever the technical term for that is) so I can't click it. So I type a character, then backspace, to "trick it" into enabling the button. I click "Review Your changes" and it thinks about it for a while, then comes back with "Could not start the review because your revision matches the latest version of this page." OK, let's skip the "review" and just Save it. Thinks awhile, then comes back with "Your changes to LeeStock Music Festival have been saved." Voila. It's gone form the category :) Wbm1058 (talk) 01:11, 27 June 2013 (UTC)
Null edits are an unfortunate thing to have to worry about. Should VE support them? I don't know if it needs to. So long as the wikitext editor is always there, one can just use it for any null edits.
After this edit, I tried to do the same using the VisualEditor.
After clicking on edit on the section, there was nothing to say anything was happening unless I scrolled up to the top of the screen.
On my screen the 'toolbar' overlaps the reference and transclusion boxes.
When typing the template name, is having a list of the subpages useful. (e.g. type in cite web and I get cite web/doc, cite web/sandbox ... etc) ?
I couldn't copy a ref, so I could paste it elsewhere. This is the way I would create two similar refs, eg pointing to different pages on the the same website.
The results included some seemly random changes to the article source.
Subpage exclusion is something we can look into; the problem is trying to compensate for the practises of 200 wikis :/. What OS/Browser? Any chance you could take a screenshot? Okeyes (WMF) (talk) 12:17, 27 June 2013 (UTC)
Once I thought perhaps I'd done something wrong, but second time I'm sure it's VE: it's adding a ":" before the Categories I'm adding, to make them into links to the category rather than real categories. I think I've successfully added categories before... but perhaps I haven't! PamD08:49, 27 June 2013 (UTC)
I noticed that if I make a word into link and then italiced it, then I get something like [Defiance (TV series)|"Defiance"] for a link. When I italice the word and then make it a link, I get "[Defiance (TV series)|Defiance]". P.S. I used only one pair of [] here, so it won't turn into a link.
The final result is the same but, it just looked weird the first time I saw it on "Preview". You can see what I mean here The first is italiced after linked and the second before. TeamGale (talk) 09:53, 27 June 2013 (UTC)
Not at the moment - it's coming, though :). Hence my confusion. I don't think the desktop editing interface will ever fully work on mobile because, frankly, it's not built to work on mobile. We will have an editing setup for the mobile site relatively soon, however. Okeyes (WMF) (talk) 18:36, 27 June 2013 (UTC)
Some thoughts
Not sure if this is the appropriate forum for this, but I just experimented with the VE in my sandbox; here are some of my thoughts (NB: Copied from User talk:NYKevin/Sandbox; experiment was on the corresponding subject page):
Overall it was very pleasant to work with, which surprised me. The usability team has outdone themselves.
Transclusion needs work. While the interface looks friendly enough, it lacks affordances. In particular, it does not suggest parameter names. This is really bad for {{cite foo}} templates, which typically have a whole bunch of parameters.
It might help to display the {{doc}} inline under the "add a parameter" UI.
Also, it's annoyingly hard to work with positional parameters. When I tried creating parameters called 1 and 2, it instead made unnamed positional parameters and wrapped them in <nowiki> tags. These tags were visible in the transclusion UI upon editing again, making me concerned that saving may not be idempotent in this case. Even if it is, the template only looked right in the editor, not on the live page.
Adding a {{cot}}/{{cob}} around some content worked, though it initially looked ugly in the editor. Trying to change the wrapped content after the fact forced me into a wikitext editor, but hopefully people won't be trying to do that very often anyway.
Someone who doesn't understand how our references system works might be confused by the process. They might try to edit the references via the references list (i.e. the <references />), and that doesn't work.
It looks like the editor appended a <noinclude></noinclude>, which puzzles me as there seems to be no purpose for it. The only explanation I can think of is leftovers from the previous version, since I didn't manually blank the page before experimenting (instead, I used VE to erase everything, then directly began editing). Certainly VE has no business playing with noinclude, since it probably won't be active in the Template namespace for quite some time, if ever.
The "Review your changes" button (i.e. show a diff) still uses a wikitext-based interface. I suppose we must walk before we can run. More troublingly, it took several seconds to load; an end user might try to cancel out or even leave the page.
By far the most trivial complaint: Bullets and numbering are done as #foo instead of # foo; the former looks sloppy to my eye.
If this is too sloppily organized, or too verbose, or the wrong format entirely, sorry about that. --NYKevin18:45, 27 June 2013 (UTC)
No, that's great! Thanks for all the feedback, and for your lovely note :). So, in order: I totally agree about transclusion. What we're working on at the moment is two things; first, automatically reading all the parameters in. You add the template, it loads the possible parameters. Second, TemplateData; templates will have associated human-readable names for each parameter, descriptions of what they do, and descriptions of what the template does, and these will be loaded on top of raw "1"s or "2"s when available. Hopefully it'll make it not only easier than it is now, but easier than it is to do in source editing.
Referencing definitely needs work; I'm having some difficulty replicating the include issue (do you mind me tinkering with your sandbox? Seems like a likely place to replicate). I actually agree on bullets and numbering - not only because it's sloppy, but because it reduces the readability of the markup, and people will still need to edit markup. I'll add it into bugzilla :). Okeyes (WMF) (talk) 19:04, 27 June 2013 (UTC)
I'm not able to reproduce the noinclude issue either. However, the previous version of the page did include an empty pair of noincludes (I checked), so I think the problem (if you can call it a problem) is that the VE is preserving content which has no effect on the page. The real problem, of course, is that in the previous version, those noincludes had been affecting the page; specifically, they were preventing a ~~~~ from being expanded. I'm not sure if there's a correct answer to this one, but VE's behavior is not totally outlandish IMHO. It could plausibly be left as-is. So I guess that particular one is not a bug. --NYKevin04:04, 28 June 2013 (UTC)
I am sure it has been thought of, but I couldn't find any mention of it in the roadmaps or in bugzilla: can the cite book/news/website/journal templates be integrated with the reference functionality? And please together with the autofill functionality for isbns/pmids/dois. That would make life/referencing so much easier. --WS (talk) 19:18, 27 June 2013 (UTC)
Working on it :). The bug is under kinda a counter-intuitive title, it seems (I had to spend a good five minutes looking around, and only found it in my inbox). Okeyes (WMF) (talk) 19:20, 27 June 2013 (UTC)
I added {{italic title}} to Pompidou (TV series), and it had no visible effect - I checked to see that I'd added the template OK and yes, it showed up in "See your changes", but was still displaying vertical. I saved the page, still vertical. I clicked on "Edit source", and it went into italics. Cancelled the edit, and it's still nicely in italics. Opened it in VE again, and it still shows in italics.
But I've have expected the title to display in italics in VE the moment I'd applied that template. And most certainly to do so after I saved the page.
Having finally (see above) found out how to add what would have been {{subst:L|1985||Kurak, Adam}} to Adam Kurak, laboriously, click by click, I then Saved the page... and the categories weren't shown. When I reopened the page in another tab, Category: 1985 births and Category:Living people were both listed properly. This feels a bit similar to the italic title problem I found earlier - VE making changes but not displaying them after "Save page". I've had the same effect trying subst:L on my sandbox, so it's reproducible. PamD23:02, 27 June 2013 (UTC)
Edit source by section may be knocking out Hot Cat
Edit source by section is great. But I think it's knocked out the Hot Cat functionality on my last 2 category edits-- the little plus signs weren't there.— Preceding unsigned comment added by Djembayz (talk • contribs)
I've come across an issue where highlighting and deleting text doesn't remove the text and causes the cursor to jump and delete part of a non-highlighted word. It works after three or four tries. Also, I can't highlight and delete text in the edit summary. Teammmtalk email01:24, 14 June 2013 (UTC)
@Whatamidoing (WMF): Yea, it happens on all articles. I'll highlight multiple words in order to delete them, but instead of deleting the cursor jumps and deletes a portion of another word I previously worked on. I also can't highlight and delete multiple words at a time in the edit summary save box. Teammmtalk email16:35, 24 June 2013 (UTC)
Will there be the dropdown choice of recently used edit summaries which we get at present? For WikiGnomes, who do the same sort of edit repeatedly, it's really useful - can include links to project pages or WP policies, etc; my most regular one being "Stub-sorting (you can help!)", which I wouldn't want to have to type from fresh, or copy-and-paste from a clipboard, every time. If we've lost this, then that's sad.
Is the intention that "serious" editors will have to graduate to "Edit source", or is VE intended to become the system of choice for us all? There seems a lot missing at present. PamD16:41, 21 June 2013 (UTC)
Unfortunately not :/. This is not directly a VE problem, it's a browser problem; for a multi-line comments box most browsers (read: I've not encountered one that does, ever, but I haven't used every single browser) doesn't feature autocomplete or any kind of memory. The VE is intended to eventually be the editor-of-choice for all, although that's not to say we'll remove "edit source" - it's worth noting a lot of features, such as table, maths and gallery editing, are all in the works now. Okeyes (WMF) (talk) 16:57, 21 June 2013 (UTC)
Sad. Could we have an option of a one-line edit box with memory, for WikiGnomes? There are a lot of people out there who do repetitive useful edits and for whom it saves a lot of time. Or we'll just get less useful edit summaries from gnomes. PamD17:26, 21 June 2013 (UTC)
I second that. I have just restored a string of nine contested PRODs, each meaning 1. restore, 2. remove PROD, 3. add notability tag, 4. add "oldprod" to the talk page; and not having to type all the edit summaries because the system supplied them (is it the browser? I thought it was Windows) was invaluable. Oh well, I suppose we can stick to the old editor for repetitive tasks like that. Do we actually want people to write such long edit summaries as that box allows? JohnCD (talk) 22:18, 21 June 2013 (UTC)
So if it's only all of five chars longer, do we really need to go to multi-line summaries? Can't it just stay single-line? 14:11, 26 June 2013 (UTC) — Preceding unsigned comment added by Wbm1058 (talk • contribs)
Seconded. Given that the loss of functionality is already being flagged as a problem ... what was the problem with the browser-supported one-line box again? - David Gerard (talk) 14:29, 26 June 2013 (UTC)
I haven't heard of a reason for this design choice. If I do, I'll let you know.
I have some hope that this will change eventually. James F filed the enhancement request back in April after this discussion. But all things considered, fixing those dirty diffs and improving the refs is probably more urgent, so it will likely be a while before they get to this. Whatamidoing (WMF) (talk) 08:53, 28 June 2013 (UTC)
I am a new editor (being here for less than 2 weeks) and I have to say that I spent many hours these past days trying to learn the code system by searching in the help pages or by copying and observing things in already existant pages. Have to say that it was not easy and sure I still don't know how to do many things. I just started getting used of that code system when today I found out about VE. I don't know if it was there and I just didn't see it or it was a released today to everyone or some new editors or something. I tried it and my first impression is really good. Took me a while to get used of it but it sure will take less time for someone totally new to understand how to write or edit. I just wanted to add some things I noticed or some ideas that might help (or not, just thoughts) VE to get better.
Maybe a center button would be useful next to the bold and italics one in case someone wants to "center" a text.
About references: in the "old version" we could add the author's name of the article, the published date, the title etc along with the link. After clicking "save page", Wiki was automatically appearing those infos on the ref list and the highlighted part that was leading to the external link was the name of the article. We couldn't see the original link. I think that was a good think and it's something that we can't do with VE. I mean, I can type the infos but, is there a way title + link won't appear both on the ref list?
Something else I noticed about the references. I added some with VE and when I saved the page everything was ok. I could see them all in the ref list. But when I clicked "edit" again to change something, the references disappear. I could see the heading but not the links. When I got to the article again, they were there. We are not suppose to see them when we are in edit form? Or is that a bug?
When I click "edit" in a certain section, I get the whole page and not only that section.
You are welcome. Of course I can. If you go to this page and see the references; No2 was made with the "old version" and No3 + No4 with VE. In No2 the actual link is hidden behind the title of the article (I think it looks more neat) but in the other two we can see both, title and link. Thank you for all you are doing! :) TeamGale (talk) 01:48, 24 June 2013 (UTC)
Thanks! I see what you mean. So, it is possible to do that (you'd paste the link text in as a word, and then turn that text into a link) but you shouldn't ;). As you say, the other format is more neat. Okeyes (WMF) (talk) 13:23, 24 June 2013 (UTC)
Sorry if I am bothering you but, I am not sure if I understood. Is there a way to make it look as it looked in the old version by using VE but I shouldn't do it? If yes, how? Cause I tried but I don't seem to find a way... :( The only way is when I add the refs with VE to go back to "edit source" and make the changes there. Something that takes more time. Changing the text into a link works for links that there are "inside" the wikipedia, like actors' names or places etc, but does it work for outside links while I am trying to add a ref IN the ref box? TeamGale (talk) 14:21, 24 June 2013 (UTC)
You could do this: Type out the citation, skipping the URL. Then select the title, and click the "link" button (as if you were making a wikilink; both wikilinks and URLs to other websites use the same button). Type the URL into the space (where you would normally type the name of an article, if you were making an internal wikilink). Save that. You can see here that it works.
Thanks. I am not sure if I understood the ways you are describing here since I am not very friendly to technology, but I found my way through it and now I can do it :) TeamGale (talk) 22:58, 25 June 2013 (UTC)
I'm glad you found a way that works for you. Please keep posting as you run into problems; it will help us figure out what's broken or confusing. Whatamidoing (WMF) (talk) 08:58, 28 June 2013 (UTC)
I sure will! :) I might get annoying because I said it many times but, thanks for everything you are doing! I really appreciate it! TeamGale (talk) 10:14, 28 June 2013 (UTC)
Some comments
After my first edit, I'm rather impressed with the VisualEditor, but only up to a point. As an editor who's well accustomed to using MediaWiki markup, I find it tedious to have to use the toolbar to link, create headings, and bold/italicize text. I tried to add a link on the page I edited with the VisualEditor, but it added nowiki tags around the lines that I edited. I'd suggest that VisualEditor be able to turn these markups into links/formatting as editors type, as this will probably help editors who are used to just typing in the markup language (like me) to adjust to the new editor interface.
That's my main issue with the VisualEditor. Of course, I haven't toyed around with it quite enough to give more feedback. One random thing I'd like to point out: the good article icons become part of the editable text and can be deleted, so that should be fixed to ensure no accidental deletions of icons ever occurs. Also, the speed at which VisualEditor operates is not ideal, as I'm sure other users have pointed out already.
For now, and likely if/when VisualEditor becomes the default editing mode, I'll be sticking with the "old" means of editing. I'll be testing it out every now and then, however, and I'd appreciate that my suggestions be considered and incorporated into the updates. Thanks, and happy editing! Prayerfortheworld (talk) 07:03, 24 June 2013 (UTC)
WTF? All that is supposed to be "easier" to learn? I have no clue about what half of that table is talking about. And if I accidentally stumble on my Ctrl key, when I meant to hit the shift key, and it isn't immediately obvious to me how to undo that mistake, I'll be cursing at you. Triple-clicking? OMG. Wbm1058 (talk) 12:56, 26 June 2013 (UTC)
Honestly, I'm struggling to think of even one occasion when I've had to use <nowiki></nowiki> tags in mainspace. Maybe in templates that are included in mainspace? Most need for nowiki is on talk pages (like here). If VE isn't even designed for use on talk pages, what's the point of all these convoluted keyboard shortcuts? Are you really that concerned about the risk that wiki markup might collide with legitimate article text? Wbm1058 (talk) 13:25, 26 June 2013 (UTC)
WP:Flow is probably going to use VisualEditor, or at least offer it as an option. Also, VE will eventually be wanted for editing non-mainspace pages, like Help: pages. Whatamidoing (WMF) (talk) 09:05, 28 June 2013 (UTC)
The instructions say how to toggle bold and italics on, but they don't say how to toggle bold and italics off. Seems an extra step "selecting content" is required before toggling. Do you need to "un-select content" to turn off bolding and italics? Wbm1058 (talk) 13:35, 26 June 2013 (UTC)
If it's already italicized or bolded, and you don't want it to be, then select the text and press the same keys that you would for making them bold or italics. This is the same system used in basically all word processors and mail clients since approximately WordPerfect 5.1, so I think that most of our users will have little trouble figuring it out. Whatamidoing (WMF) (talk) 09:05, 28 June 2013 (UTC)
Most of these shortcuts in the table are rather commonplace, at least the cut/copy/paste and bold/italic type shortcuts. I've had to use nowiki plenty of times, but I don't quite see why that's been brought up. The same commands are used to toggle on as to toggle off. I'm not a fan, however, of the "editor shortcuts" section, as I do feel (and agree with you) that memorizing the new shortcuts is quite a pain. Moreover, this doesn't quite present a palatable solution to my request, which I feel would be best solved by allowing the "normal" markup (i.e. the markup that editors must use now) to be integrated into the VisualEditor. Prayerfortheworld (talk) 14:23, 27 June 2013 (UTC)
So, I put the Visual Editor to the Chloroplast test, and I'm happy to say that it's very close to passing.(Templates and references, yay!) Some problems remain, though:
1 Section editing. Please. The Visual Editor can be quite slow (but not unbearable).
2 Links can be frustrating. Please make it so I can type "[[" as a keyboard shortcut instead of having to grab the mouse and find the o-o button at the top of the editing window. Also, when I'm done with the link text, hitting Enter doesn't work, I have to click outside the link dialog to close it. That's not intuitive. Also, after closing the link dialog, it takes two clicks to move the cursor. One closes the dialog, the second moves the cursor to a new location. Also, if there is only one possible link target, just skip the dialog and link it (red or blue, though I think this has been reported already).
3 Z-index problems remain. For some reason the editing toolbar doesn't float above stuff in the editing window. Often a template will obstruct the editing toolbar, even though it's visually behind the toolbar.
4 Too many cryptic icons. Look, I am all for visual icons, but can you include a text label because the icons can be quite ambiguous and unclear. For example the references icon looks like a city skyline and the Reflist icon looks like it should be the references icon. Take a lead from some applications like Blender, which uses icons along with text on its buttons. Like
References
5 References. Any way to get the cite tools integrated? Or at least have a blank template syntax to fill in? I don't feel like typing <ref>{{cite journal|doi=|title= etc... especially cause I'm going to forget or misname some parameter like the date or coauthors. Also, any reason why I would need to insert an image into a reference? Also using named references is not working—it should give a dropdown list of available references, or better, just let us copy and paste the [1]s.
6 Templates. When you insert a template, could it give you a list of all the available parameters for that template? That would be a huge improvement over the text editor.
7 Images. Nonthumb images should not have their alt text displayed like a caption underneath. This messes up page rendering. Just make it behave like a template, and use a dialog to edit the alt text.
8 Visual Editor is not a bot or AWB. It should not be going around turning ></ref>s into />s or adding ""s. And it's still wiping out hidden comments. See diff:1.
9 Take a look at that same diff:1, and go down to where I added to the section on the TIC translocon (under ==Chloroplast DNA== ===Protein targeting and import===). See what your visual editor did...
Thanks for the detailed feedback! 1, 2 and 3 are all being worked on; I'm asking about 4, and will stick 5 in bugzilla now. 6 is going to be built in. Can you give an example of 7? 8 is a known bug, yep :/. For 9, I'm not seeing a problem with that bit - what am I missing? Okeyes (WMF) (talk) 15:58, 24 June 2013 (UTC)
You can see 7 everywhere at Chloroplast, there's tons of double captions because {{plain image}} adds both alt text and a caption for accessibility reasons. This is really the one of the big two bugs that are preventing the VisEd from getting a passing B on the Chloroplast test. (Right now, I give it a C–, I would give it an A if it succesfully rendered {{Chloroplast cladograms are complicated}}). The other bug is the Parsoid's inability to recognize position: absolute.
9 as you may have guessed is the Cite error: A set of <ref> tags are missing the closing </ref> which probably arises from the fact that VisEd adds its own set of <ref></ref> in addition to any ref tags that editors may have added in the reference text box. This should not be hard to fix, I did similar idiotproofing when I coded parts of {{plain image}}.
Yes, because I figured if I was going to give the reference a name, it would need the <ref name=".." . Also, using {{cite journal}} means an uneditable template transclusion in the Reference dialog. Try changing a date on one of the journal cites at Chloroplast with the Visual Editor. I dare you. I am watching that article. :)—Love, Kelvinsongtalk16:38, 24 June 2013 (UTC)
"Reference name" is wikijargon known to most of us with more than a thousand edits, but it isn't going to make sense to inexperienced editors. Having said that, another explanation, perhaps like "Give this reference a nickname so it's easy to re-use" might be better for everyone. Whatamidoing (WMF) (talk) 18:21, 25 June 2013 (UTC)
Sure, and then we get conversations like: "What's the name of the reference you're using?" Oh, the book is Watching the English: The Hidden Rules of English Behaviour, by Kate Fox." "No, I meant the reference name, not the name of the source you're referring to." Whatamidoing (WMF) (talk) 09:11, 28 June 2013 (UTC)
When adding links with a plural appearance, normally one would type, for example, [[example]]s, while Visual Editor puts in [[example|examples]]. See, for example, [37] (in which Visual Editor also made random formatting changes... oh well):Jay8gInspect-Berate-KnowWASH-BRIDGE01:59, 25 June 2013 (UTC)
I'm not sure that this is really a "bug". It might be a case of "working as designed". I believe that the [[example]]s approach was designed for users of screen reader software, so that the software would say "example s" (which sounds very close to "examples") rather than "example examples" (the first being the link and the second being the label). Perhaps User:RexxS or User:Graham87 will tell us whether my memory is accurate. Whatamidoing (WMF) (talk) 18:36, 25 June 2013 (UTC)
Nope, the [[example]]s code was just designed as a shortcut in the edit window and has nothing to do with the displayed HTML; screen readers will only say the label rather than the link unless instructed otherwise. The Visual Editor should really be using the shorter form to keep the wikitext as compact as possible. There used to be advice in the accessibility guideline to this effect, but I eventually removed it because it's not really an accessibility-specific issue. Graham8703:05, 26 June 2013 (UTC)
e.g. This leaves an "[edit]" link hanging in space in the saved article (which you can't see in that diff), and an empty TOC entry (which you can) - David Gerard (talk) 11:35, 25 June 2013 (UTC)
I did try quite hard to delete it - if I hit "backspace" it deleted the reference list, and if I hit "delete" it deleted the infobox - there was nothing there that I could actually delete - David Gerard (talk) 12:54, 25 June 2013 (UTC)
Hi David, what he means is that (despite trying your best) you probably only deleted the "words" instead of the "paragraph". I'm sure you've done that on purpose in editing an e-mail message or using a word processor before. The result is a blank line that still has the same formatting, just without any text on it. That's what I did to reproduce the problem here.
Ideally, VisualEditor will be smart enough to realize that empty section headings aren't wanted, but, in the meantime, you can work around this by selecting the entire section heading plus the invisible "paragraph end" character that follows every paragraph. Whatamidoing (WMF) (talk) 18:48, 25 June 2013 (UTC)
I'd say this is absolutely the time to treat this sort of thing as a bug that must be fixed, and not to be advising workarounds - David Gerard (talk) 19:14, 25 June 2013 (UTC)
The bug has been assigned to Rob Moen, so it will get fixed. However, I don't know how long it will take to get fixed. In between now and then, the workaround will keep it from screwing up your editing. Whatamidoing (WMF) (talk) 09:18, 28 June 2013 (UTC)
The second type of reference works just as well as the first. As for the CookiesOK; we can't build code for every potentially conflicting extension on every supported browser. I would suggest contacting the addon maintainers. Okeyes (WMF) (talk) 12:46, 25 June 2013 (UTC)
It may work just as well, but it is not what is intended. <ref name="foo"/> looks like what it is, a self-contained reference that is defined elsewhere. <ref name="foo"></ref>, what you change it into, looks like a new definition of an empty reference, and is likelier to lead later editors to errors such as changing the name or adding text inside the ref. Not to mention it's gratuitously verbose. —David Eppstein (talk) 16:49, 25 June 2013 (UTC)
All of them render rather oddly; the infobox renders partially on top of the prose in the beginning, the lock is sticking on the left side, and the map's labels are just in a list, not actually on the map itself at all. See this. Dashie (talk) 16:37, 25 June 2013 (UTC)
Yeah, I see this problem; thanks for reporting it, Rainbow DascC :). I'm adding Turkey as an example to the bugzilla, and have identified the problem as a blocker on wider deployments. We can't be having big chunks of text left uneditable. Okeyes (WMF) (talk) 10:27, 28 June 2013 (UTC)
Changing headings ("formats") works inconsistently
When I attempted to change multiple heading's levels in a row, sometimes it would keep the formatting (I would highlight the second and it would change it to be like the first) and sometimes it wouldn't (I would highlight the second and nothing happened):Jay8gInspect-Berate-KnowWASH-BRIDGE03:03, 26 June 2013 (UTC)
Do you think you could provide an example, or some clearer steps to reproduce this bug? At the moment I don't really understand what you mean here. — This, that and the other (talk)10:07, 26 June 2013 (UTC)
See this edit. I was changing the levels of headers. Steps:Highlight 1 and change it. Highlight another; it often will change itself without using the drop down menu. Highlight another; it probably won't change without using the menu:Jay8gInspect-Berate-KnowWASH-BRIDGE16:51, 26 June 2013 (UTC)
1Whitespace issues—nonthumb images add extra lines for some reason, and after references, the space breaks, example:
It's been proposed to be part of the TIC import channel.[62][71]
There is no in vitro evidence for this though.
2Accidental deletion Sometimes, the Visual editor deletes stuff when the cursor isn't right in front of it.
For examples if this is the end of a line and the cursor is[74]
|here, hitting backspace will remove the [74] reference.
This also happens with images (see 1, when trying to delete extra lines).
3More accidental deletion Visual editor loves displacing invisible templates like {{clear}}. At least it's leaving page comments alone.
4Links How do I click through to a linked page to make sure it's the right page to link to??? The middle click does nothing except duplicate the link text, leaving something like α-helicesα-helices. This is frustrating as —.
5Strange fragmented links Sometimes when making links with italics and stuff, the link will fragment, for example translocase. The underline also fails to extend under the first letter.
Wikimarkup the VisEd left:
'''''[[Translocase of the inner membrane|t]]'''''<nowiki/>''[[Translocase of the inner membrane|ranslocase]] on the '''[[Inner mitochondrial membrane|i]]'''[[Inner mitochondrial membrane|nner '''m'''itochondrial '''m'''embrane]]''
6Excessive link piping Why [[In vitro|''in vitro'']] instead of ''[[in vitro]]''?
7References Reusing references is too hard. There are too many dialogs to click through. I miss copy and paste in the text editor. On the other hand, it's great that cite templates are working now. Now if only I could remember the names of all those parameters...
8VisualEditor why you no leave name=parameter alone?
—
See the diff that inspired these additional reports: 1
In order; for 1, I'm not seeing any problems in the diff you provide; there should be a space between a reference and the start of the next sentence. 2, I can't replicate :( 3 is being fixed; 5, ditto. 4 is a good point - I'll add it as an enhancement. 6 is also being fixed; 7, we're going to have TemplateData automagically pull in parameters when you pull in the 'cite' template or whatever - that's being worked on already. 8, I don't see 'parameter' I'm afraid :/. Sorry to be unhelpful. Okeyes (WMF) (talk) 19:26, 26 June 2013 (UTC)
1 The problem is that the space breaks—it goes to the beginning of the next line instead of the end of the first line. 2 is probably partly a side effect of number 1, but the image also disappears if you try to delete the blank line at the top of Chloroplast. In fact if you try to back up the first text line, the entire lead paragraph disappears. For 7, that still doesn't solve the problem that it takes nine clicks to copy one reference.a 8 means that it keeps adding unneeded spaces around the equals signs.
aSelecting the reference, clicking the popout icon, clicking the refname box, highlighting and copying, closing the dialog, moving the cursor to new location, clicking reference icon, clicking refname box and pasting, closing the dialog
Thanks for the followup :). So, on 7, if you mean reusing in the sense of citing the same thing multiple times, you want to add a ref name. If you mean reusing in the sense of "I cite Foo, page 27, and now I want to cite Foo, page 33, and it's a pain in the tuchus to copy everything out", bug 50283 might interest you. 8 - the space is unneeded for it to function, but actually this is deliberate; it improves the readability of the source wikimarkup. Ultimately even when the VisualEditor is fixed, we'll still need to go in occasionally and tinker for whatever reason; that's easier when things are less smushed together. I'll work on replicating 1 and 2 now. Okeyes (WMF) (talk) 13:45, 27 June 2013 (UTC)
For two, I think the bug I found and the bug you found are probably related. I just realized the vanishing lead paragraph bug was actually the lead jumping into the caption of the first thumbnail image caption. Don't know what causes the first image to disappear when backspacing at the front of the line before the first lead paragraph, but it could be related.
V Backspacing here causes (1)
Structure of a typical higher-plant chloroplast
Chloroplasts visible in the cells of Plagiomnium affine, the many-fruited thyme moss
The word chloroplast (χλωροπλάστης) is derived from the Greek words chloros (χλωρός), which means green, and plastes (πλάστης), which means "the one who forms".[2]
The word chloroplast (χλωροπλάστης) is derived from the Greek words chloros (χλωρός), which means green, and plastes (πλάστης), which means "the one who forms".[2]
The word chloroplast (χλωροπλάστης) is derived from the Greek words chloros (χλωρός), which means green, and plastes (πλάστης), which means "the one who forms".[2]
I'm trying not to report the same bug more than once. However, if someone could post a summary of the bug fixes as they are implemented, we can test them and provide more feedback if needed. Thanks! GoingBatty (talk) 03:32, 27 June 2013 (UTC)
If you want, you can look at this Bugzilla query that gives VisualEditor bugs marked as "fixed" in the past 3 days. However, you would need to keep in mind that "fixed" on Bugzilla merely means "fixed in the code", and not all bugs marked "fixed" may have been fixed on-wiki yet. There is also a weekly VisualEditor bulletin that is sent to WP:VPT and possibly also to this page.
Thanks for your responses. Could you please post the future bulletins on this page (or at least post a link to the appropriate WP:VPT section)? GoingBatty (talk) 22:31, 28 June 2013 (UTC)
Do you mean they don't work as in the rendering they include isn't displayed by the VE, or they don't work as in 'typing them in in the VE does nothing'? Okeyes (WMF) (talk) 15:33, 27 June 2013 (UTC)
Yes; the VisualEditor is a rich-text editor. It doesn't support HTML any more than it supports wikimarkup - anything you type in is rendered as text. We are actually looking at better ways to support this, but I'm not sure what that will look like. Okeyes (WMF) (talk) 10:00, 28 June 2013 (UTC)
User:ClemRutter/sandbox3- eventually a new article Piece-rate lists
I switched on VE and kept a parallel log in gedit of the experience. It was an interesting way to spend a morning. I am on a Thinkpad T410 under Mint 14 Linux using Firefox 1.0 18.0.1 for Linux. I have added line numbers for clarity- but rendering her is patchy
cp via link User:ClemRutter/sandbox3- something is happening
edit- simple deletion- worked fine- saved worked fine but dropped me out of the editor (Issue 1- no save and continue editing button)
check- to history did a comparison- all fine- clecked on edit to continue- directed to the edit-source editor (Issue 2- should stay in ve) (Issue 3- the history needs to be modded to give [undo][edit][edit source])
edit- copy edit- went fine
Cntl-S- to save edit- no that only saves the Mozilla page-Went to save dialogue box then Cntl-S to save and that wont work- tried right click that wont work -used Save Page button (Issue 4 Cntl short cuts not connected)
edit section- highlight link-cntl c- mv to above paragraph cntl-v, upto the paragraph button set as subheading- works- mv to para above- select 4 words- cntl-c, mv above para cntl-v- the copy works- upto paragraph button select sub-heading as before- click and the whole para becomes bold. (Issue 5 Not sub-heading)
looking at save preview- wow =====Factory Act in 1891===== (Issue 5a Markup issue)
save it for the record. It sees it, it is the para above that was hit not the one I was working on
edit section- paragraph button/paragraph recovers it.
edit- I am about to move some paragraphs and delete some others. I click on ref[2] to view it- I just see a jigsaw. rt-click nothing double-click jigsaw- hover nothing (Issue 6). I click the jigsaw- and I get a box saying sfn. All I want to see is the contents of sfn- and a link that will take me to the full reference in the reference list. This is a genuine work in progress- I am looking for false links, and broken links with the reflist. If I want to replace the pseudo- reference {-{sfn- |Memory|-}-} with a real reference Dickinson|2002|p=47 typing directly is the quickest way and I want to immediately see that is in the reflist. (Issue 7 sfn Broken does not have basic functionality)
I want to copy sfn (3) to two other places in the text - I highlight cntl-c mv to spot cntl v and only see the characters not the reference. (Issue 8)
I want to copy sfn (3) to two other places in the text but change the page number (parameter)- I should do the above then edit. This fails because of Issue 8- (Issue 9)
I want to move some text from the body to a {-{efn. I cntl-x the text.I go to the recieving spot and hit the jigsaw- I add the template efn. I have the text in the buffer and a screen that is asking for a parameter name- efn only has one parameter- but it doesn't have or need a name. Add parameter is greyed out- and stays that way until you give the template a name. No hint, no hover to help and nowhere to paste the buffer. (Issue 10)
edit- in moving paras I now have a sub section head with no text. (Issue 11)
edit- rm extraneous paras from below the real text- easy but I now have another sub section head with no text.
So at this point I am printing out the text and editing on paper and posting this report. There are 12 issues to be investigated- all discovered in doing a standard edit. On the sfn/efn issue I think there is a basic misunderstanding of their use. I use them as a speedy way to manage my references which are 60%+ of the work in an article- the jigsaw facility is a generic way to implement a template (software orientated and not article orientated). I will have a go later at one of my List of mills articles, that heavily uses templates and referencing to achieve a specific aim. Does this qualify for a Barnstar? -- Clem Rutter (talk)17:22, 27 June 2013 (UTC)
Can you explain things in a bit more detail? I have no idea what "cp Editing User:ClemRutter/sandbox3 -cant find it cp=change page" means, for example. Okeyes (WMF) (talk) 17:43, 27 June 2013 (UTC)
So, in order; for 1, that's not so much a bug as it is an enhancement. It sounds like an interesting thing to have, but the sort of thing that would make most sense in the future - i.e. when we have a better way of handling things like edit conflicts and collaborative contributions (which is, I know, on the table). 2 and 3 are a good point; I'll add it to bugzilla. 4, there isn't a save shortcut - this seems like the sort of thing we may not want to have (too easy to accidentally hit), and it makes no sense since there's an additional interaction - edit summary writing - between 'save page' and an actual save. 5, yes, if you haven't selected an open piece of space it will turn the entire thing into a sub-heading, which is sub-optimal, obviously. I haven't been able to replicate 5a, unless I select sub-heading 3 instead of sub-heading. 6, what skin are you using and when did you undertake this test? We had some problems with monobook that were patched earlier today. 7, can you explain in more detail how sfn is broken? 8 is known and being worked on, ditto 9; for 10, yes, it doesn't know what parameters to pull in until you've explained what template you're using. 11 is a great addition; I'll check bugzilla to see if it's there and add it if not. Okeyes (WMF) (talk) 18:48, 27 June 2013 (UTC)
So I switched to vector, and attempted to cx the subheading h5 to a h3
it didn't work- I see why. You call a h3 subheading- a Subheading 1 and a h5 subheading a Subheading 3 hence I had selected the wrong one-- but that doesn't explain why the toc displayed it as a h3- I think we must put that down to a glitch in the way the wiki parser works.
Onto checking whether hover works when looking at an existing sfn reference in Vector. Yes but it just says transclude- what will a newbie make of that- it needs to give a copy of the reference in Harvard format Name, year, page.(Issue 6)
Any rate -click it and now in Vector the top of the template editor is overwritten with the editor bar.(see illus) . You cannot close the window.(Issue 12).
Press apply changes, and the software wipes the {-{reflist}-} and gives an error message. I tried this twice. (see illus)File:Screenshot-6.png The only way to recover is to not save your changes (Issue 13)-- Clem Rutter (talk)21:27, 27 June 2013 (UTC)
I have switched back to Monobook. It seemingly effectively c&p'd sections- but we are back to references. Found the target spot clicked the icon on the toolbar- I needed to add sfn| Dickinson|2002|p=47- fat chance, this icon wont do sfn. So moved over to the jigsaw icon- typed in sfn- and here we have a blank page with no clues. We are back at (Issue 7). Can't go any further without sfns. Yes ve is pretty- but unstable and lacks a suitable way of adding references. This must be implemented before we can use it.-- Clem Rutter (talk)00:14, 28 June 2013 (UTC)
We're working on automatically pulling in template parameters, which should hel. I'd remind people that sfn is just that; a template. The VE has a perfectly workable way of including templates, it's just that MediaWiki's actual support for template formatting is limited. Okeyes (WMF) (talk) 09:45, 28 June 2013 (UTC)
The problem is that sfn s are what you need to use to get an article to dyk- anything else has to be changed to retain consistency. It is also the point that if you are referencing any academic work you shove in a Harvard style reference and that is what wp:en requires now. Just because it is possible to go round the houses doesn't add any value- antagonises folk, and does mean that someone else will have to change the edit back to a sfn. I work on that type of article- as a rule of thumb we need one reference per paragraph and one for any surprising fact. Elsewhere in wp:en different standards apply. At the moment I tell newbies that a useful article is 60% references and 40% prose.
I have a work around but I don't think that is the point- but it also handles PamD's concerns about maintenance tags. I'll share it. On the tool bar you just add an extra icon, '@' would do it would open up a popup box with a single text-enter box- the contents are the raw contents of a template- for instance I would type sfn|Dickinson|2002|p=47 and press return (or {{sfn|Dickinson|2002|p=47}}) . This would have have any matching outer {-{ stripped to cater for people who are c&p known templates,and then {-{ }-} would be added to build the template - a validation check *a could be done- then the raw code could be written into the text. On rendering would appear like '[14]' a normal reference. This system could be used for any template *b - personally I would also use it for {{convert|86|ft|m}} . Whenever there is a hover event, the raw code comes up as a alertbox. We don't even need an icon, a double-click event in the text could take you into raw. Keep it simple, dont attempt to do multiple line that adds a degree of complexity.
-*a During the validation check, if a sfn was discovered it would check if the matching cite was on the page and invite the user to dismiss the alert or enter your citation editor.
-*b On User/Preferences you could invite the user to default to raw or use the template editor you are developing
The task is to allow the maximum number of folk to add the worlds most important encyclopedia- not to try and make newbies and experienced editors to appreciate a new piece of software. We must stay on focus- visual most of the time- inline raw when that is more appropriate and strict js input boxes as a last resort.
<ramble>But it would be cool if I could drag and drop an image directly off my camera onto commons and see it appear on the wp:page I was writing, using cookies to add meta information such as co-ords, and copyright then allow an external app such as Shotwell to straighten, crop and enhance</ramble>-- Clem Rutter (talk)15:48, 28 June 2013 (UTC)
How old is relatively old; what version are we talking about here? Bear in mind that there's a pretty strong inverse relationship between "browser's release date" and "amount of effort needed to make things work for it"; we've had to write off Opera, for example. Okeyes (WMF) (talk) 19:09, 27 June 2013 (UTC)
Then the answer is almost certainly no, I'm afraid. That's...not a small jump, that's 11 versions of the software out of date. Okeyes (WMF) (talk) 13:54, 28 June 2013 (UTC)
"Edit section" links missing on this page?
I see no "Edit section" links on this page for sections 88 "Table/Template" to 117 "Subst and template date" inclusive. Has the page got too long? (Win7, FF21.0) JohnCD (talk) 20:19, 27 June 2013 (UTC)
Huh; same (setup and experience, that is). I'm not sure what the source is - if it was length, you'd think there wouldn't be section-editing here, ferinstance - but I'll up the archiving rate. Okeyes (WMF) (talk) 20:37, 27 June 2013 (UTC)
I don't seem to have an "edit" link beside the section above, so continuing here.
I think I confused issues by raising too many questions at once, so:
I cannot see how to add multiple positional parameters to a template. If I choose to add the template {{about}}, and then specify a parameter named "1", I click on "Add parameter", and get a box to put it into but no button to "add value of parameter". All I can do is hit return (no effect) or click the "Apply changes" button, or click the "+" at bottom left (which disconcertingly turns into the transclusion icon) which offers me a chance to add a new template. No apparent way to add parameter number 2. How do I add a parameter with multiple positional parameters (eg {{about|this|that|elsewhere}})?
I understand that in future the system will recognise that I've added a template it knows about and offer me a menu of parameters (which will make {{cite web}} etc usable - until now I've always used the RefToolbar approach and would miss it if I tried to add a ref in VE). But my question is: will this setup offer me the parameters for template Foo if I'm adding it as template Subst:Foo ?
Pam Hey Pam...if I can help on what you are asking on your first question. To add a second parameter, after you'll write your description about the first one, you just click on the template's name and it gives you the option to add a new parameter :) TeamGale (talk) 22:34, 27 June 2013 (UTC)
On the second...cite web IS usable now too. When you add a template, you can type cite web and add it. Only that it doesn't give you the parameters yet so you have to add them by yourself the way I wrote you before TeamGale (talk) 22:38, 27 June 2013 (UTC) :)
Thanks re the first, I'll try. Not exactly obvious. On the second, when I said cite web wasn't usable, I was being lazy: I meant it wasn't offering the user-friendly approach of offering a menu of parameters in the way the old RefToolbar form does. How can we expect new editors to work out for themselves what parameters to use in such a complex area? PamD22:44, 27 June 2013 (UTC)
Yeah...I know. Took me a while to figured it out in general...how to add a new template with it's parameters and look right after saving! :D About the menu, it's something I am waiting with patience since people of VE are working on it. It will sure be VERY useful! But yes, personally being a new editor for only two weeks and working one week to the "old version" trying to learn it and then I found VE (trying to learn that one now), I don't think I would know how to do it or what parameters mean if I was coming straight to VE... TeamGale (talk) 22:59, 27 June 2013 (UTC
OK, now a simple request: please provide an "add another parameter" button, alongside the box for input of parameter content. It's just completely un-intuitive to have to click on the template name. I'm impressessed that TeamGale managed to find it, but I wonder how many other editors will do so. PamD07:09, 28 June 2013 (UTC)
That's an excellent suggestion; I'll throw it in Bugzilla. For TemplateData templates (which there will hopefully be a lot more of after today - I'm about to send some announcements out!) it should, according to this bug, automatically load the parameters in...but that bug was meant to be solved for yesterday and isn't. Chasing them on it. In any case, we need a solution that works for non-TemplateData templates too. Okeyes (WMF) (talk) 09:33, 28 June 2013 (UTC)
If I wish to add something to the end of this test page, in "Edit source" mode I can place the cursor below the last line; but in VE I can't. It has to be put at the end of the last line, and then if I press "return" to get to the line below, VE starts to add a further bullet point. Experiment finds that pressing "return" a second time gets rid of the bullet, but this seems complicated and unnatural.
You get the same effect (can only put cursor at end of last line, not below it) with simple text, where it is less serious because you don't run into the bullet-point effect; but it still seems unnatural not to be able to place the cursor below the last line. JohnCD (talk) 22:23, 27 June 2013 (UTC)
John, I can agree this is a weakness in the design, but what's the situation where an editor needs to drop to that bottom line before they save? PEarley (WMF) (talk) 01:17, 28 June 2013 (UTC)
I suggest two: (a) simply to add more text to an under-construction article one has had to save and leave (eg real life interfering with a planned long editing session). (b) to add a stub template or other matter which belongs at the end per WP:ORDER. PamD07:13, 28 June 2013 (UTC)
Yes, the problem is not on saving but when an editor wants to add something to the end of an existing page. JohnCD (talk) 08:51, 28 June 2013 (UTC)
VE display after a change doesn't reflect reality - line break after adding hatnote template
I added a hatnote. As VE displayed it, the hatnote was on the same line as the following text. I might have spent ages trying to fix it, but recorded it in the edit summary, saved the page, expecting to report it here as a bug. Once I'd saved the page, it displayed correctly. But if this is a Visual Editor, it should be displaying the page properly, immediately a change is made. This is similar to my earlier comments on Italic titles: if VE doesn't display the result of a change, or displays it looking wrong, editors are going to assume that their edit didn't work and struggle to "fix" it. PamD08:03, 28 June 2013 (UTC)
If you edit an article, save, then go to a different page and press the back button, you will be served with the cached version of the article from before your edits were made (happens this way in Chrome, don't know about other browsers). Either the edited version should be cached, or a refresh should be enforced upon viewing the article again. --WS (talk) 09:03, 28 June 2013 (UTC)
Yes. Did some more testing: this happens only when I add or remove a template, but no text at the same time (noticed it when removing stub-templates from some articles). As soon as you change any regular text (only or as well), all works fine. --WS (talk) 11:12, 28 June 2013 (UTC)
Also when you press edit again afterwards, it tells you you are working in an older version. --WS (talk) 11:13, 28 June 2013 (UTC)
I agree; I think this is mostly due to the complexity of tables :/. For what it's worth, we're doing a lot of work at the moment to make templates a lot easier to modify, and the template inspector more friendly. Can you point me to a particular template that is causing problems? Okeyes (WMF) (talk) 10:32, 28 June 2013 (UTC)
Templates as simple as "Help:Columns" in source are just split up to dozens of sub-menus. Also awards templates for accolades (E.g. Rage Against The Machine) make less sense in the visual editor than they do in source. But maybe that's just me. Ultimately this is amazing program this WVE and I hope it upgrades to be along with source editing. :) Jonjonjohny (talk) 10:59, 28 June 2013 (UTC)
It would be nice if you could edit image caption text just like any other text. Having to go into the template dialog adds an unnecessary extra step and is harder to discover. --WS (talk) 11:53, 28 June 2013 (UTC)
I agree that editing an image caption that way would be optimal, but VisualEditor handles all files through the Media box to ensure standardization in editing files. Not 100% perfect, but it's the best way to process files at the moment. Keegan (WMF) (talk) 17:10, 28 June 2013 (UTC)
Edit summary input issues with Vimperator
Vimperator is a Firefox plugin that makes Firefox more like Vim. I use it for reasons of accessibility: it allows me to use Firefox with more keyboard controls and less recourse to mouse/trackpad.
I tried VE out and it actually works fine... but for one thing. In the 'save' panel, I can enter characters but I can't delete characters in the edit summary. Backspace just doesn't work. The only way I found I could remove text was to highlight it with my mouse and use Cmd+X to cut it. This is fairly niche and I can perfectly understand that making sure the visual editor works with a fairly unorthodox browser plugin might not be very high on the to-do list. And in all honesty, I'll probably not use the visual editor as for keyboard-preferring users like me, it is likely to be slower than editing the markup directly. But I thought I'd report it anyway just in case. —Tom Morris (talk) 14:07, 28 June 2013 (UTC)
This ref desk question raised an interesting problem. The editor cut operation from a source, also brought with it a hidden link. I am somewhat concerned that the hidden link could also be added using the Visual Editor, but not actually noticed by the editor at all. Is this a valid concern? Astronaut (talk) 15:48, 28 June 2013 (UTC)
It's as concerning as it could be doing the same in edit source as VisualEditor. A quick test adding the hidden text shows up quite clearly in VisualEditor as it does in source. Keegan (WMF) (talk) 16:51, 28 June 2013 (UTC)
This is a known :/. Some problems with MediaWiki generally meant the site went down, and so we've had to revert to an older version of the codebase. Hopefully things will be more stable and we can get the improvements to media editing deployed :). Okeyes (WMF) (talk) 16:19, 28 June 2013 (UTC)
I see that Ctrl-C, Ctrl-X and Ctrl-V are now working - good! I had some instances yesterday of losing formatting when copying within a page, but I could not reproduce them consistently, and not at all today, so it must have been a transient glitch.
However, copying from one page and pasting in another still consistently loses all formatting: I just copied everything above "Second L2 header" from this test page and pasted to another page producing this. JohnCD (talk) 17:51, 28 June 2013 (UTC)
When editing the above article, the a,b,c in front of references that are used multiple times change in 1.0, 1.1, 1.2 etc. --WS (talk) 18:37, 28 June 2013 (UTC)
Interesting. I see what you mean. When not in edit mode the letters resolve just fine, so it looks like that is how its organizing itself in edit mode. I'm not sure how big of a deal this one is. We'll look into it further. Keegan (WMF) (talk) 18:56, 28 June 2013 (UTC)
Feedback
I really appreciate Wikipedia and I want to be part of this big source of information web-site.
Regards
Onea Mihai Alin Onea Mihai Alin 18:48, 28 June 2013 (UTC) — Preceding unsigned comment added by Brumson (talk • contribs)
I still think we have more to do before the 1 July release
I hate to continue to be a fly in the ointment here and I am pleased to see that so much work has been done to fixing VE and I think its coming together wonderfully, but I still think there is too much more to do for a 1 July release. With something just under 200 bugs and counting, some of them quite significant and still not having the ability to add citations, I really think we need to continue development before release. Its certainly not a good idea to release it to the general public yet. Keep up the great work guys. Kumioko (talk) 19:43, 28 June 2013 (UTC)
I agree; we're working out what to do and prioritise now. If you guys can point to particularly severe problems, tracked or untracked, we can take a look at them :). Okeyes (WMF) (talk) 20:18, 28 June 2013 (UTC)
In my opinion it appears that you already have a good handle on the major ones. The citations, slow loading, the wierd data errors and things of that nature, etc. I would be happy to look through and identify some that are priority but as far as I can see its the same ones you already have identified. I just think we need to whittle those down a bit before releasing it. You guys are definately knocking them out though. Kumioko (talk) 20:25, 28 June 2013 (UTC)
Thanks! :). I agree, the slow loading worries me; citations, we'll see what we can do. As a technically-minded individual you might want to look into TemplateData; I imagine adding TD to cite templates, sfn, efn etc. would probably help a lot at making reference editing easier. Okeyes (WMF) (talk) 21:06, 28 June 2013 (UTC)
Impossible to edit templates when they are in close proximity
Hi, I was trying to edit the review table at the article All 6's and 7's, but I can only edit the track listing template, as the blue thing that denotes I'm hovering over a template obscures the review box and makes it impossible to edit.
And could you also remove the character limit for the subject section on the VE feedback box? It means I can't fully type the section heading I wanted on here. Insulam Simia (talk/contribs) 20:11, 28 June 2013 (UTC)
I tried to save the following templatedata to Template:Foreign relations of Australia, but it said there was a JSON error. Can someone please complete this for me?
<templatedata>
{
"description": "A template showing a box with lists of articles about the foreign relations of Australia",
"params": {
"state": {
"label": "Collapsed status",
"description": "Whether or not the template is collapsed into one line Allowed values collapsed expanded or autocollapse Auto collapse only collapses if there are more than one of this same template on the page unusual",
"type": "string",
"required": false
}
}
</templatedata>
Thanks --99of9 (talk) 22:13, 28 June 2013 (UTC)
When I edit arc diagram (OS X, Chrome, monobook + a larger font-size in custom css) the top and bottom lines of the "Notes" section, which contains only {{reflist|colwidth=30em}}, are cut off. It appears that the ten lines of notes are split into 3 columns as 3.5 lines for the first column, 3.5 lines for the second column, and 3 lines for the third column, instead of the more obvious 4-3-3 split. The same bad columnization also occurs in the references section of the article, which uses a {{refbegin}}/{{refend}} pair. See the screenshot here. (The already-reported issue with bad numbering of footnote uses as 1.1, 1.2 instead of a, b is also present.) —David Eppstein (talk) 23:11, 28 June 2013 (UTC)
Congratulations on addressing one of the problems people face when editing Wikipedia. What is being done to address the other serious problem of hostility on Wikipedia? --Rskp (talk) 03:33, 29 June 2013 (UTC)
I think you might find better answer for this concern at the Teahouse. This page is for feedback about VisualEditor, but there is always a place for this discussion there. Happy editing to you! Keegan (WMF) (talk) 05:31, 29 June 2013 (UTC)
Is VisualEditor the reason why Edit links are blocked via JavaScript from opening in a new tab? This has been the case for the past few weeks, only on the English Wikipedia, only for Edit links (e.g. not History links), and of course only when JavaScript is enabled.
If this bug has been introduced by the VisualEditor changes, it should be fixed for editors not using VisualEditor. --pmj (talk) 23:57, 21 June 2013 (UTC)
Yes, this seems to work fine for me whether VisualEditor is turned off or on, or whether I am logged in or out. Maybe Thatotherperson and I are too Other to notice the problem!
Interesting. Browsers affected (English Wikipedia only; VisualEditor not enabled):
Firefox on Linux (logged in)
Chromium on Linux (not logged in)
Browsers not affected:
Firefox on Windows (not logged in)
Internet Explorer on Windows (not logged in)
Everything works fine on several other language Wikipedias. Any idea what to make of this? Have there been changes to the way the Edit links work recently? --pmj (talk) 12:47, 22 June 2013 (UTC)
Firefox on Windows and possibly other ones. I don't have access to Linux to test.
Just to be clear, Pmj, how are you attempting to open the Edit screen in a new tab? Ctrl+click? Middle-click? Right-click and "open in new tab"? etc? — This, that and the other (talk)09:53, 25 June 2013 (UTC)
Under Linux, neither middle-clicking nor Ctrl-clicking opens a new tab, while selecting 'Open Link in New Tab' from the right-click context does. When the edit link in this page is middle-clicked, the browser for some reason requests the following URI (some values redacted):
This fails with a 204 No Content error from the server, after which the browser proceeds to request the edit page and load it in the same tab. This round trip produces a slight pause between clicking and page load, which is also not present under Windows.
Presumably this issue doesn't appear under Windows because middle-click historically has a different significance in Unix-like operating systems. But the real question is, why is this edit-link-click event bound to the Edit button for a non-VisualEditor user? --pmj (talk) 10:36, 25 June 2013 (UTC)
Thanks! I recommend you mention the edit-link-click event in the Bugzilla ticket, to give the developers a head start in their investigation. --pmj (talk) 22:24, 25 June 2013 (UTC)
Bizarrely, this is only fixed for middle-click; Ctrl-click still exhibits the incorrect behaviour of opening the edit page in the same tab after a brief delay. --pmj (talk) 03:01, 30 June 2013 (UTC)
When I create a whole new article with VE, when I click on the "preview your changes" I get a very weird page that it's not easy to go through it. I know it's not possible to have a comparing page with the previous one since it doesn't exist but that kind of page makes it difficult for me to check the article. I don't know how to describe the page and I don't know if that's how it was supposed to look. Just try to copy an existing article and paste it to a totally new page (no need to save it) just to see what I mean. Thanks TeamGale (talk) 13:06, 25 June 2013 (UTC)
No, it's fine! So, latest update; what we're hoping to build over the next couple of months is HTML-based review, so instead of getting weird wikimarkup you'll get shown a "this is what your article will look like" render - almost a preview. That's some time off right now, however :/. Okeyes (WMF) (talk) 10:25, 28 June 2013 (UTC)
Oh! That's amazing! Can't wait to see it! Personally I am patient so, I don't mind waiting...I know you have many things to work on and it's not easy. I can deal with the one that exists now till the new feature arrives :) Thanks for the update! TeamGale (talk) 10:51, 28 June 2013 (UTC)
I don't see the point of that; a WYSIWYG editor should already show you "what your article will look like" without having to hit preview. The review-your-changes step only seems useful as a way to review the changes you've made to the code. Will it still be an option to review your changes as a markup diff, or will we simply have to use the markup editor for that?
I was wondering the same thing. I use Ubuntu which has a "---" emdash shortcut, but it would be nice to have a special characters panel for Windows users.—Love, Kelvinsongtalk15:54, 27 June 2013 (UTC)
Mac users can do this easily from the keyboard. Is Windows still using the "type the special numeric code" system that they were using twenty years ago? Whatamidoing (WMF) (talk) 08:38, 29 June 2013 (UTC)
Yes, we Windows users do still have the Alt+number thing (a MS-DOS holdover, I think). We may as well not have it, though, since it is exceedingly rare for non-power users to know about it. — This, that and the other (talk)10:05, 29 June 2013 (UTC)
If someone wants to edit an infobox that is included in another one, is there a way to do it?
Plus, while making a template with parameters or editing one that already exists, when I want to add a wiki link in the description of one parameter, I have to use the brackets to do it. Any chance in the future to be able to do it in the template the way VE does it on the main article? Thank you TeamGale (talk) 16:45, 27 June 2013 (UTC)
Sure. Go to this page and try to edit the infobox of the episode. The parameter "Season list" is concisted by another infobox. Is there a way to edit that infobox if I want to change something on it? TeamGale (talk) 18:41, 27 June 2013 (UTC)
Thank you so much! I didn't want to "edit" something on the second infobox but, a what if... came to my mind when I saw it :) Hope the wiki links issue can be fixed too. Thanks again for everything you are doing. We really appreciate it. TeamGale (talk) 10:10, 28 June 2013 (UTC)
And thank you for the attitude you (and many others, I must say) are bringing to the VisualEditor. It's a genuine pleasure to come to work each morning; this is probably the smoothest and most on-the-point deployment process I've ever been involved in. Okeyes (WMF) (talk) 10:13, 28 June 2013 (UTC)
You and all the people who work on VE, are trying to bring us something more helpful and easier to work with. Reporting something that we see and it might need improve is the least we can do to help. Especially when you are so patient and polite with all of us. :) TeamGale (talk) 10:34, 28 June 2013 (UTC)
I am aware of this. I just gave it as an example to explain what I meant. But if there was a transcluded template inside it (the ones we can edit on the original page) how would we do it? Can we? :)
And since you mentioned it, with the "markup" we could find infoboxes after we were clicking "edit" at the bottom of the page. Is there a place we can find them now after clicking "edit" with VE? And just a thought...why we can't edit them on the original page like templates? I am just wondering. TeamGale (talk) 13:57, 29 June 2013 (UTC)
Subst and template data
I've started to read the documentation about adding Template Data. One question: will it work for subst'd templates? Or will typing "Subst:L" in the template name box ignore any information about the parameters?
Have I got this right, that it is impossible at present to add more than one parameter to a template if it doesn't have this "Template Data" info? And we're rolling this out as the default editor within days? Not good. PamD16:58, 27 June 2013 (UTC)
No, you can list all the parameters; what TemplateData means is that instead of getting "1" or "2" or "colwidth" or something, you'll get an actual descriptive name for each parameter, and a description of what the parameter is for. The infobox here is a good demonstration. I'm honestly not sure about substitution; I'll ask :). Okeyes (WMF) (talk) 17:48, 27 June 2013 (UTC)
I just can't see how to do it: if I want to add, say, a hatnote like
This page is about something. For something else, see elsewhere.
(ie {{about|something|something else|elsewhere}}), how do I do so? I can add one parameter, numbered as "1", but then can't see how to add a second. I tried adding them all in one go (ie typed "something|something else|elswhere" as parameter 1), the result was
I just want to add that they're getting some of these problems fixed. We've gone from about 5% of VE edits having some sort of problem down to 2% recently. (We're all looking forward to 0%, of course.) Whatamidoing (WMF) (talk) 09:42, 29 June 2013 (UTC)
Nice job on the Section edit links!
Well, thought I would take a break from my usual list based Visual Editor complaints and just say that the little animations on the [ edit | edit source ] are really good from a motion design standpoint. It's very hard to subtly introduce new buttons/text in a non jarring way. This is one of the few examples of good design I've seen on wikimedia projects (no offense!). Nice work.
Thanks @Kelvinsong:, @AioftheStorm:! I'll pass your compliments on to the devs :). I think at this rate I might owe them a small brewery. The pertinent patch can be found here if you're interested in looking at the animation mechanism. Okeyes (WMF) (talk) 08:54, 28 June 2013 (UTC)
No, something like the edit/edit source animation can't be done in pure wikitext (though it could with Common.js/Common.css). Superm401 - Talk05:00, 30 June 2013 (UTC)
Good start, needs fine tuning
I've been testing VE and it's working pretty well. I appreciate that you still left the source code for those who wish to use it.
Here are a few difficulties I've found with it in the short while I spent trying it.
1) Templates are seemingly impossible to move around the page. Perhaps it's just my browser (Chrome), but I'd appreciate it if templates could be either copy-pasted or dragged around.
2) I'd like a way to edit parameter and template names after they're created. If I incorrectly capitalize a parameter name, I currently have to delete it and reenter it. Same with template names.
3) The Source editor has some useful features that are not as easily accessible in the VE; namely, special characters and certain highly used templates.
I also am worried that VE will be impossible to implement in the Wikipedia name space due to the complexity of many pages there that only the Source Editor can create. If this is the case, casual users could more easily add content, but would still have to learn a lot about Wiki markup if they want to access many of the Wikipedia namespace pages, especially noticeboards. Marechal Ney (talk) 00:36, 28 June 2013 (UTC)
Hey Marechal Ney. Thanks for the feedback.
For point 1 - Most large templates have a "home" (i.e. navboxes at the bottom, infoboxes right- and top-justified, so on). Which temps where you trying to move around?
Point 2 - This is concerning to lots of people, including me. The developers are working hard on improvements to the template dialog.
Point 3 - Hopefully enhancements can be added for all that we find useful. I believe the special characters need is tracked, I'll check. Reporting here anything else useful but not supported will help make it happen faster.
Top icons, as used to identify e.g. good or protected articles, are shown within the text at the location where their template is instead of at their normal location at top of the article. This is confusing and makes it very easy to erroneously delete them. --WS (talk) 11:31, 28 June 2013 (UTC)
Keep displaying the icon at top (perhaps editable with a template-puzzle icon?), and handle the template in the text like any other hidden template. Perhaps statuses like these are best handled in the page settings. --WS (talk) 11:43, 28 June 2013 (UTC)
Indeed, although for that MediaWiki would have to recognise them, which it doesn't :/. The problem is twofold - one, there's no space for them (insofar as there isn't really a top bar to the VE), and two, a lot of people put them at the bottom of the article; VE renders things where they appear in markup. Okeyes (WMF) (talk) 11:49, 28 June 2013 (UTC)
Space isn't a problem, they are displayed to the far right of the article title, and this space is still there and empty when using the VE. And I would think that the VE should render everything as it would appear normally, not necessarily directly where it appears in markup. Probably still a technical challenge though. --WS (talk) 11:58, 28 June 2013 (UTC)
Yeah. I'll inquire about it, but what I suspect is that the CSS in the featured article star pegs it to an element that simply doesn't exist in the VE. This is something that is meant to be deployed to 200+ projects, so I suspect that requests for direct support of wiki-specific templates will be problematic :/. Okeyes (WMF) (talk) 12:05, 28 June 2013 (UTC)
Well... maybe Mediawiki should recognize FA and GA status. It could be generalizable as a 'page status' setting, which I imagine that a lot of non-WMF wikis would use for new pages, outdated pages, etc., but we could use it for recognized content (and maybe for pages under discretionary sanctions). Whatamidoing (WMF) (talk) 16:15, 29 June 2013 (UTC)
Switch to edit source
It's nice to use Visual Editor to make quick corrections, but when there are more structural changes, using Visual Editor may quickly become troublesome and unpredictable. In this case, it will be nice to switch to source edit without having to save the visual edits as a revision first. It will be even more awesome if you can switch back and forth between the two - edit the source, preview the result in the WYSIWYG editor. ADTCTalkCtrb17:38, 28 June 2013 (UTC)
@Agent007bond: Agreed! I am thinking of sorta how Wordpress handles it, for example, with the visual/html tabs. I think this is on the to-do list for the long term :). Okeyes (WMF) (talk) 19:25, 28 June 2013 (UTC)
We'd love to provide simple switching, but sadly doing so would make it very hard to still provide clean wikitext diffs. This might have to wait until wikitext diffs are replaced with HTML diffs. --GWicke (talk) 21:06, 28 June 2013 (UTC)
Hi both, thanks for the responses. Although ultimately we would like to see Visual/WikiSource switching, in the meanwhile, if you can at least irreversibly switch to WikiSource editing (with all the Visual edits carried over) that could also work. At least it would serve one group of people who might start off editing visually, but at a certain point want to continue editing in source or do a clean-up of the source. What do you think? -- ADTCTalkCtrb
Technically such a one-way switch is pretty straightforward. Indeed something for the VisualEditor team to consider. --GWicke (talk) 16:56, 29 June 2013 (UTC)
Trying when editing articles to think "Could I use VE for this?" I came on an article where the {{AfD}} template had been removed and needed to be restored. The easiest way to get that right is to call up from the history a version with the template in place, and copy it from there to the current version. This doesn't seem possible in VE: after selecting the template so that it is highlighted, Ctrl-C doesn't copy it, and right-click doesn't offer a "Copy" option. JohnCD (talk) 21:29, 28 June 2013 (UTC)
The current default source editor of wikipedia has an elaborate system of dialogue boxes for adding references. It includes scripts to fetch details of reference from ID like ISBN/DOI/PUBMED ID etc. Hope this is included in future development of VisualEditor. ★Saurabh P. | ☎ talk21:34, 28 June 2013 (UTC)
At least one of the older reftools versions can do magic with Google Books URLs and NY Times URLs, writing out pretty much full citations from those alone. Would have never gotten through the old unreferenced BLP backlog without that. --j⚛e deckertalk21:38, 28 June 2013 (UTC)
The visual edit is looking pretty good and should be much simpler for editing when released as the default editor. I especially like how easy it is to link other pages, add media, and references. One suggestion would be to make editing the sidebar easier. I noticed that in order to edit the sidebar you must open up a special menu and use traditional link format. Perhaps this could be simplified? Paranini (talk) 22:51, 28 June 2013 (UTC)
Thanks for the feedback. Currently VisualEditor is just meant for editing actual articles (or User space) and is not meant to simplify editing MediaWiki in general. Perhaps that will change in the future if VisualEditor works in a way that makes this possible. Keegan (WMF) (talk) 01:22, 29 June 2013 (UTC)
I believe he is talking about the infobox, Keegan, based on his edit. :)
If I'm right, Paranini, what you're dealing with there is called a template, and they're a little more difficult to work with at this point because they're fairly complex. I will pass along your request, though. --Maggie Dennis (WMF) (talk) 13:42, 29 June 2013 (UTC)
There is so much detailed descriptions
There is so much how to, and explanations of what everything is I can't even find a link to make a change even on a semi locked page..so here is my change to Zlatan Ibrahimović. The best soccer player in the world, and his number at Paris st. Germaine is 18 not 10..that is all — Preceding unsigned comment added by Willyj89 (talk • contribs) 22:51, 28 June 2013 (UTC)
I really loved my first use of VisualEditor editing a page Visual Editors on English Wikipedia. And it was a such a brilliant experience! I'm looking forward to the completion of this worry-free and handy tool. Keep up! Alnel Vincent Alico 23:46, 28 June 2013 (UTC) — Preceding unsigned comment added by AlneltheGreat (talk • contribs)
It's good that new users find it easy, it's not so good that when I look at the edit, it appears to have introduced formatting errors into the article. NtheP (talk) 13:32, 29 June 2013 (UTC)
Feedback from roads projects
I tried editing some road articles with the VisualEditor and here are the issues I found:
On my 13 inch screen, the editing toolbar always obscures any template/reference windows, which is a bit annoying.
No way to insert nonbreaking spaces.
Most junction list tables can be edited (see the bottom part of California State Route 78 for an example), though there is an awkward Content thing in between the templates.
Nested templates cannot be edited with the interface, such as {{Jct}}.
I ran into an error where the table did not show up on California State Route 52 when I tried to edit it. Not sure what happened.
Overall though, the experience was a lot better and more functional than I thought it would be, with our complicated templates! --Rschen775402:58, 29 June 2013 (UTC)
I'm happy your overall experience went well! Issues with templates and tables are being worked on as we speak and hopefully they'll be debugged very, very soon. If there was anything striking that you may have noticed as a bug in particular, we'd like to hear about it. Keegan (WMF) (talk) 05:27, 29 June 2013 (UTC)
One other thing: I've added TemplateData to {{mileposts}} as a small test but it's not showing up in VisualEditor after several hours. Is something wrong? --Rschen775407:07, 29 June 2013 (UTC)
Missing warning message for editing protected or semi-protected pages
I'm I missing something, or is there no warning message like MediaWiki:Protectedpagewarning and MediaWiki:Semiprotectedpagewarning that displays on the VisualEditor when editing a protected or semi-protected page? This is just as important as the page notices. The last thing we need is an admin inadvertently making a controversial edit to a fully protected page solely because there was no similar MediaWiki:Protectedpagewarning on the VisualEditor interface like on the regular editing form. Zzyzx11 (talk) 04:57, 29 June 2013 (UTC)
I'm happy to see that you truly are making editing Wikipedia a lot easier for us who don't know Wiki codes and who have no time or interest of learning them. I've always wondered why making a minor editing in Wikipedia is so hard that I rather quit than make any changes even though I know what to edit. It just has been too complicated. I learnt to walk and talk 49 years ago, I learnt to write 45 years ago, and I learnt my first English words at age 6, that's 44 years ago but in 2010 or 2013 I couldn't make even a minor edit in Wikipedia because I'm not into codes. You have no idea how many times I have given up on editing, simply because it has been so difficult and takes too much time considering what I'm about to edit. This VisualEditor is so welcome to me. Maybe from now on I don't have to walk away from a page even if I see it needs some editing but instead of that I can do it without sweat, toil and frustration. I can't wait to try new VisualEditing. I believe it makes me more active for making minor editing. And later on I might take bigger editing jobs as well. Thank you for making my extra hobby a lot easier. AniaKallio (talk) 07:24, 29 June 2013 (UTC)
The pleasure is all mine. :) But, now I'm beat after reading all these bug reports and comments here. I think I need a cup of coffee and fresh hot sunny air. Keep on doing good work! AniaKallio (talk) 10:15, 29 June 2013 (UTC)
I used VE to remove two redlinks from List of male kickboxers, but had to revert because it also made unwanted format changes all through the article, see diff. It is quite hard to make out from the diff just what it did - it seems to have added extra "pipe" characters in half a dozen places, and |}|}|}|}|}|} at the end. The effect, seen here, is that items are progressively more indented as you go down the list. JohnCD (talk) 13:11, 29 June 2013 (UTC)
I find a bug like this, which makes changes well away from the intended edit, very worrying on the eve of general release. The inexperienced editor most likely to use VE would not understand a diff like this even if he checked it. While an inexperienced editor would not be removing redlinks, he might well add an entry to this kind of list: I just did that as an experiment with the same result. I notice that VE chose the same six locations (B, G, H, I, J, M) to add extra pipe characters - that may have some significance. JohnCD (talk) 14:16, 29 June 2013 (UTC)
To be fair, that page's wikitext is very messed up. Each section is wrapped in a table, but many of those tables are never closed. This results in the remainder of that page being wrapped in unclosed tables. While I agree that we can further improve our handling of such situations, simply closing those tables can avoid the problem right now. --GWicke (talk) 17:03, 29 June 2013 (UTC)
I went ahead and closed all the unclosed tables -- in general, it is hard to support that kind of buggy wikitext well. Try editing the page again in VE. Ssastry (talk) 21:18, 29 June 2013 (UTC)
Yes, that has largely fixed it for that article - only one extra "pipe" this time. But this is still a serious issue: I'm sure there are many, many more articles which have screwed-up wikitext but display OK, and it is bad news if an innocent edit with VE can screw up the actual display and require this sort of digging into the wikitext to sort out.
The FAQ at the head of this page says that "In general, VisualEditor should never make changes to formatting on lines that are not being directly edited." I think that is a very important principle, which is why I have been reporting counter-examples (and I would like to know more about that "in general" caveat).
It has never been clear to me whether these instances stem from a design intention to have VE make AWB-style automatic tidyings-up, or whether they are just undesirable side-effects of its design. Repeating today this test of another example, I saw for the first time the interesting message: "Warning: Your edit may have been corrupted – please review before saving". Can you tell me what triggers that? JohnCD (talk) 22:41, 29 June 2013 (UTC)
Thanks for reporting the bugs -- this bug is being tracked and we'll fix the issue with the extra pipe there. Parsoid attempts to do its best to represent wikitext as well-formed HTML (which is required for editing and converting it back to wikitext). However, badly nested tags, missing closing tags, stray closing tags are some cases Parsoid has to fix up the HTML and record information about the fixup so that the original (even if buggy) wikitext can be restored. It does a decent job of handling a lot of corner cases, but bad table markup will occasionally trip up Parsoid (as in this example). So, on converting HTML back to wikitext, sometimes (not always), the wikitext gets fixed up. But, our HTML-to-wikitext converter is also designed to only do this fixup (when it does happen) in edited portions of the document (other fixups are bugs which we will fix whenever we encounter them). Does this answer your question? Ssastry (talk) 04:23, 30 June 2013 (UTC)
Attempting to remove the space that is erroneously between the period and the following ref at the end of the penultimate sentence of the second paragraph at Michael Lowry (actor) fails--the editor visually appears to allow the change, but when the change is saved, no error is produced, nor is any change left in the article history. Reproduced in Chrome and Safari. --j⚛e deckertalk15:19, 29 June 2013 (UTC)
Confirmed in Win7/FF21.0. There are actually two spaces in there; at first I thought the problem was maybe that you were only removing one and VE didn't consider that a change, but removing both still produces "No changes. Could not start the review because your revision matches the latest version of this page" when you do "Review your changes". JohnCD (talk) 17:54, 29 June 2013 (UTC)
This is very odd. In this version that you saved, there are still spaces left of the reference, which I don't suppose you intended - in fact, looking at it in edit-source mode, there are three. I moved the reference back (because they are supposed to be outside the punctuation). What I did, in VE, is:
put the cursor to right of the full-stop
backspace to remove it
left-arrow to put the cursor "on" the ref
left-arrow again to put cursor just left of the ref
backspace three times removing spaces
backspace once more removing the "n" at the end of "Epsilon" (to be sure there are no spaces left)
replace n
add full-stop.
Now (still in the editor) it looks just fine. Save it - and the two spaces between the full-stop and the ref are back! It looks as though VE is adding spaces to the left when it saves a reference. I will try to devise a simple test case to demonstrate this. JohnCD (talk) 09:07, 30 June 2013 (UTC)
Reproduced on MacOSX/Chrome : The infobox grows over a fair bit of the lead in a "oh, that can't be right" manner. --j⚛e deckertalk16:35, 29 June 2013 (UTC)
And on Win7/Firefox21.0. The infobox covers the whole of the lede and "Early Life" and part of the "Education" sections. JohnCD (talk) 17:32, 29 June 2013 (UTC)
I was able to pull it up on my iPad/Safari. Is it possible that you're not logged in there? (I only suggest that because that was a mistake I made in trying to reproduce this.) --j⚛e deckertalk17:32, 29 June 2013 (UTC)
No, I'm logged in, but I only see the "Edit" links, which go to the Wikitext editor. When you say "pull it up", did you have to take some special action to get it? I have "Enable VisualEditor" checked in "Preferences", of course, or I wouldn't be able to use VE on my desktop machine. I am still on IOS5, being a slow adopter and mistrusting Apple's maps - could that be it? JohnCD (talk) 17:45, 29 June 2013 (UTC)
Haven't tried Maze. I like Bing maps because, in the UK, at appropriate scales it offers the option of displaying the excellent Ordnance Survey 1:50,000 and 1:25,000 maps. JohnCD (talk) 21:22, 29 June 2013 (UTC)
Suggestions for TemplateData attributes
(all of those are in use in hewiki's "TemaplteParameterWizard")
define a "secondary" flag. add a checkbox to the template edit dialog, "Show secondary parameters" (or "Show all parameters"). This lets designers of templates with large number of parameters to specify both "condense" and "comprehensive" list of parameters.
add a "depends on" field. in many templates we have parameters that depend on other parameters. for example, we might have "population" and "population year". the 2nd parameter specify the date when the data in the 1st parameter was collected (e.g., "2011 census"). we can hide the 2nd parameter entry, whenever the 1st parameter is empty. Another example are templates which allow defining several instances of the same thing, e.g., tracks in an album. the template may allow for 20 tracks, while most albums contain much less. in this case, we make "track 2" depend on "track 1", "track 3" depend on track 2 etc. this way, the dialog will show only one empty field for "track", but as soon as the editor fills it, we show the next one. (if each "track" is represented by more than one parameter, e.g. "track3", "length3", "lyrics3", "music3" etc., the editors will make all those parameters depend on "track3", and "track3" itself will depend on "track2".
for "boolean" fields, allow defining what will be written in the page if the user chooses "true". (i assume that if a field is defined "boolean", the dialog will use a checkbox to represent it).
Regarding the 'secondary' idea, I agree that would be quite useful. ProveIt has a similar concept in its current representation, 'default' parameters. Default parameters are automatically shown as blank fields. They are not necessarily required (that is tracked separately, as TemplateData already does). It seems that default parameters and non-secondary parameters are essentially the same thing. For the track1, track2, etc. example, there should probably be a repetition type. This is also useful for authors; the cite templates (such as {{cite book}}) now allow essentially an arbitrary number of numbered authors, using Lua. Superm401 - Talk04:47, 30 June 2013 (UTC)
links preview / proper links in editor
hi guys :)
VisualEditor is amazing! thanks and keep up the great work!
one suggestion: after adding links with the autocomplete field (love it!) the linked pages can not be opened by clicking on them (which makes sense to be able to edit the text), but if i right-click to follow them the URL is not what it should be i guess. so for example, instead of
wiki.riteme.site/wiki/Banana_peel it is wiki.riteme.site/w/Banana%20peel, which results in a 404 error message.
i wonder if the /w/ will be usable instead of /wiki/ ?
VE dropped the "Preview", as a matter of course, but on the way to do that, it also dropped the "Show changes" option. This action is useful, and all the reasons why it's needed with the traditional editor, is just as valid when using the VE.
Not everyone uses "Show Changes", but some people do use it routinely. I can't think of a single good reason why this option should not exist in VE. Please find a way to integrate "View Changes" into VE. peace - קיפודנחש (aka kipod) (talk) 20:25, 29 June 2013 (UTC)
Using VE, after you make your changes and click the first "Save page" button, you're presented with a window to enter your edit summary. You can click "Review your changes" before clicking "Save page" again. GoingBatty (talk) 00:28, 30 June 2013 (UTC)
thanks. i missed it: maybe we want to consider placing this functionality in a more predictable place? i was looking for a place to review my changes *before* saving them.
The convention is that if the button you are about to click is going to open a new dialog, the button text ends with ellipsis.
if the button would have read "Save..." instead of "Save page", i would probably be more inclined to press it even before i reviewed my changes, assuming that pressing the button will open a dialog with several options, one of which will just cancel the operation. peace - קיפודנחש (aka kipod) (talk) 00:38, 30 June 2013 (UTC)
It's a standard computer UI convention for buttons and menus, since the first Macintosh - no ellipsis to do it straight away, an ellipsis if it leads to a dialogue box. e.g. "An ellipsis prepares users to expect another window to open in which they complete the action the button initiates." [38] Remember that users can't tell a web app from a native client app ;-) - David Gerard (talk) 17:58, 30 June 2013 (UTC)
Could the button say "Review and save" or something like that, to give a clue that this is where you can check what you've done? Though I suppose the "ordinary" editor shouldn't need to bother looking at the changed wikicode because all their changes will be visible on the screen as they edit (unless they've added or changed any categories, made the title italic, added {{reflist}}, ... no, I know it's not really fair to pick on all the recent problems!).
I rather like the idea of "Save..." leading to a place where one can 1) write an edit summary 2) review changes and/or 3) save. Ignatzmice•talk21:24, 30 June 2013 (UTC)
Template:Loop
I have been working on creating the TemplateData for Template:Loop/doc and keep getting a "Syntax error in JSON." I've tried a couple of scenarios, including having 2 optional parameters for the string, with and without the equal sign, + this simplified approach. Either way, I'm unable to get one to successfully save.
<templatedata>
{
"description": "The template is used to produce a simple loop of repeated strings.",
"params": {
"repeat": {
"label": "Number",
"description": "number of times to repeat",
"type": "number",
"required": true
},
"string": {
"label": "Alpha-numeric text",
"description": "the string to be repeated",
"type": "string",
"required": true
}
}
</templatedata>
it seems you forgot to close the last "string" clause: the next } actually closes "params", and the next one closes the whole object. here is the corrected form. peace - קיפודנחש (aka kipod) (talk) 20:54, 29 June 2013 (UTC)
<templatedata>
{
"description": "The template is used to produce a simple loop of repeated strings.",
"params": {
"repeat": {
"label": "Number",
"description": "number of times to repeat",
"type": "number",
"required": true
},
"string": {
"label": "Alpha-numeric text",
"description": "the string to be repeated",
"type": "string",
"required": true
}
}
}
</templatedata>
Yes, its great and should allow many more people to contribute.
One worry I have is that it makes it difficult for new users to edit links, citations etc. To do these tasks, the editors will have to revert to 'editing source'. So to get effective contributions, editors need to use the skills of editing wiki markup, bypassing the simple editing process.. Making the editing simpler has in my view made the learning process harder as people still have to investigate how to edit the source. So the difficulty has been eased, but not removed.
I have VE enabled in my preferences and its edit tab is visible normally when I view an article. It is not visible when I view a redirect using &redirect=no (e.g. this one) nor is it visible when I view an article's history. Any reason why not? —David Eppstein (talk) 01:50, 30 June 2013 (UTC)
I think the "insert reference" icon would be much more obvious if it looked like a "[1]" rather than a clothesline at night. —David Eppstein (talk) 03:03, 30 June 2013 (UTC)
I thought it was a graph with some meaning like "page statistics" and assumed that the bookshelf icon was "add a reference". Of course, now that I know, it's perfectly clear. Whiteghost.ink (talk) 10:23, 30 June 2013 (UTC)
When I try to add a new reference in a page which already has many, like this page, I can't find the "create new source" button. I think it's because the list is very long and it was "moved" up. Either a scroll apply is needed or better, "create new source" and "use an existing source" may always be visible and the scroll apply only to the list of the references. TeamGale (talk) 09:59, 30 June 2013 (UTC)
I tested that page in both Chrome and Firefox, and I find "create new source" at the top of the list in each on that article. If I scroll down and don't select anything, when I hit "insert reference", it seems to default to creating a new source. Can you tell me what you're seeing and what browser you're using? Or perhaps I'm misunderstanding your concern? --Maggie Dennis (WMF) (talk) 12:24, 30 June 2013 (UTC)
Firefox. I tried it again now but I am getting the same. When I click on the ref icon to add a new one, I can only see the last refs of the list. No "create new source" nor "use an excisting source" buttons. Is there a way to scroll up the page and I can't see it? :( The only way to "activate" the "insert reference" button from grey to green is when I am clicking in one of the existing sources, but that way I can't add a new one. TeamGale (talk) 12:42, 30 June 2013 (UTC)
Hmn; what browser version and OS? Could you send a screenshot? We've had quite a few confused users from the current references setup, so I think this is something we need to look at. Okeyes (WMF) (talk) 12:43, 30 June 2013 (UTC)
Sure. I just took the screenshot, just guide me how to post it. Is there a mail I can send it? And...sorry for the stupid questions but, where can I see the version and OS? What is OS? I am clueless about technology! :) Just to add that, I don't have any problem adding a ref, the problem here is that I can't have access to "create new source" so I can do it. TeamGale (talk) 13:14, 30 June 2013 (UTC)
Quick way: go to http://www.whatsmyuseragent.com/ and see what it says your web browser is announcing you as. e.g. this browser on this machine announces itself as "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0" (Firefox 22 on Windows 7, 64-bit) - David Gerard (talk) 13:33, 30 June 2013 (UTC)
Thanks for the help! :) Well...it says: "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0" TeamGale (talk) 13:44, 30 June 2013 (UTC)
Firefox 21, then; that should be working fine. Oh dear :/. Feel free to just email me the screenshot; okeyeswikimedia.org :). Okeyes (WMF) (talk) 13:54, 30 June 2013 (UTC)
Just sent the mail. Just to clarify once again, the problem seems to appear only when the list of the already existing refs is to long. TeamGale (talk) 14:07, 30 June 2013 (UTC)
After choosing "heading" or "sub-heading 1" etc for a line to apply, the cursor disappears and I have to click again in the text to make it appear and be able to write. Wouldn't it be easier after the apply the cursor to be at the point you left it before? TeamGale (talk) 10:04, 30 June 2013 (UTC)
When I test that with Chrome, my cursor does not disappear. It's still flashing merrily away where I was. But I do replicate the issue in Firefox. What browser are you using? --Maggie Dennis (WMF) (talk) 12:10, 30 June 2013 (UTC)
At least a browser specific one, it seems. :) Now that I know, I'll search the bugs, see if it's known, and mention it if I don't find anything. --Maggie Dennis (WMF) (talk) 12:25, 30 June 2013 (UTC)
Some templates should always be subst-ed, some should not. I'm not sure whether there any where it is optional? TemplateData should cover this: there should be a "subst" field with values always/optional/never, and some indication when the template is applied: "This template will be subst-ed"/"Click here to subst"/"This template will not be subst-ed". JohnCD (talk) 12:15, 30 June 2013 (UTC)
The problem is TemplateData is built around template structure, and templates don't include that as a value. It sounds like it would be worthwhile to put in the description of each template, though - well, each template that should be substed. Okeyes (WMF) (talk) 12:41, 30 June 2013 (UTC)
That's a pity. We need a neater way of subst-ing: at present you can do it by typing "subst:foo" in the box but (as I reported higher up, but I think it has been archived) then you only see {{subst:foo}}, you don't see the effect of the template until after you save the page. There should be a check-box for "subst" on the "add template" dialogue, and it would be nice to have the system check it automatically where appropriate, or at least call up guidance from the template description somehow. JohnCD (talk) 13:51, 30 June 2013 (UTC)
Sleep, what's that? ;p. My task today, as it happens, is to come up with a timetable to provide literal 24-hour coverage of enwiki from 1pm PST tomorrow to 1pm Tuesday. I need a pay raise. And 20 staff. And a pony. Okeyes (WMF) (talk) 14:27, 30 June 2013 (UTC)
Need to be able to follow links/refs while editing
In editing Pli I added a hatnote and wanted to check that the piped link had worked: couldn't click on the piped link in the hatnote from within VE. In editing Ponticus I wanted to look at the reference, an online source, to see what it said and check the claim that something wasn't supported by the source: couldn't do so within VE. We need to be able to follow links like this while editing, please. PamD19:21, 30 June 2013 (UTC)
You should be able to using right-click; in firefox, at least, that opens up the dialogue box you'd normally get with right-clicking links ("open in new tab", etc) Okeyes (WMF) (talk) 19:24, 30 June 2013 (UTC)
––Ɔ Ȿ♭ ௵ ☎ ℡ ☎ 08:49, 11 June 2013 (UTC)
Facepalm Rereading all this, I noticed another point of non-clarity. When I said that it's rightly programmed to nowiki typed coding, I meant it was a good idea, not that it was implementing that idea correctly. ––Ɔ Ȿ♭ ௵ ☎ ℡ ☎ 08:20, 11 June 2013 (UTC)
But seriously though, at first impression, that hardly sounds like something to lose sleep over (as I did last night) – until we realize after looking at the list of articles that they tend to be meaty, scholarly articles – you know, Featured Articles, Wikipedia's highest-value assets. And having just framed it in that light, I've changed my mind: I'd vote for the alternative temporary solution suggested above: that is, to disallow VisEd from editing such articles for now. —Grollτech (talk) 11:37, 19 June 2013 (UTC)
References
wikimedia.org :). Okeyes (WMF) (talk) 13:54, 30 June 2013 (UTC)
