(first: congratulations to this large step of development!) Please check
this edit and the
following. What happened? I went through a large article several minutes in visual edit mode. The review was OK, I pressed the “save page“ button. After quite a while, I got a javascript alert window with the message ”Error saving data to server: error“. I pressed OK and tried to save again. This took even longer and resulted in the same message. However, the first edit was saved correctly (first diff), the second resulted in a mess … I re-checked the editing window, the article looks perfectly ok, no sign of what we can see in the diff (“lfplatz“ etc.). System: Firefox 16.0.2, Mac OS X 10.6.8. If needed, I can provide screenshots. --
elya (
talk)
07:23, 12 December 2012 (UTC)
Yeah - it looks like the parsoid was being slow, hence the saving data error, but this is generally very weird :/. I'll report the edit borking now.
Okeyes (WMF) (
talk)
21:13, 12 December 2012 (UTC)
Editing just a section of an article
I hope I'm not missing the obvious, but I'm not seeing the ability to edit only a single section of an article. That's not a trivial issue - best practice is to edit only a section of an article unless one is moving text between sections or doing a similar reorganization.
For articles that get lots of edits, editing a single section is critical in avoiding
edit conflicts. Also, editing a single section means that the edit summary includes (automatically) the name of the section that was edited; this is very helpful when reviewing edit histories. -- John Broughton(♫♫)21:28, 12 December 2012 (UTC)
please cancel that. after purging everything one can purge on chrome 23.0.1271.95 m (on XP), it loads the article as such :), regards --
Jan eissfeldt (
talk)
10:38, 12 December 2012 (UTC)
failure to upload the edit, error contacting the Parsiod server. Changing the edit resulted after canceling in the Java script controls:
Uncaught TypeError: Cannot read property 'left' of undefined
Uncaught TypeError: Cannot call method 'getOuterLength' of undefined
On the top right, the warning button shows "2 notices". When clicking on it, only one appears "You're using the alpha version...".
Thanks for the great job and good luck continuing!
ClementD (
talk)
11:31, 12 December 2012 (UTC)
Not sure if it's a bug, but I just enabled the Visual Editor and I see "2 notices". When I click that, I see one message that says to double-check all edits the Alpha makes.
While there's a "2 notices" message, when clicking it, I only see one (about the VisualEditor being new). It's the same dialog that auto-pops when opening the editor (with no hints how to close).
Gojomo (
talk)
00:57, 13 December 2012 (UTC)
Thanks. Did you submit this through the "Something is wrong"->"Report a problem" screen as well, or did it break after you had gone through that screen?
Jdforrester (WMF) (
talk)
20:38, 13 December 2012 (UTC)
I have reported it as "Something is wrong"->"Report a problem" as well. But I have had no clue where these reports are collected/visible and decided to report it here too.
Raymond (
talk)
21:25, 13 December 2012 (UTC)
Tried my first edit, so, just a minor comment on the final message. It's now "Your changes to <name of article> have been saved. But since the article is quite prominently visible on the screen, I suggest something simpler: "Your changes to the article have been saved." (For non-article pages, this would be "Your changes to the page have been saved.") -- John Broughton(♫♫)20:33, 12 December 2012 (UTC)
You're right, we should use the system message now that there is one (VisualEditor's pre-dates the roll-out of this to enwiki, and the formatting and contents have changed). Now tracked in Bugzilla, per template.
Jdforrester (WMF) (
talk)
20:53, 13 December 2012 (UTC)
Icon for removing a hyperliink
The trashcan icon for removing a hyperlink is not exactly self-explanatory (it could also indicate complete removal of the highlighted text). I know there are page editors which have a "broken link" icon; that would be better. Or perhaps a link icon with a red slash through it. But I don't think of "dumping" anything (in a trashcan) when I think about dewikifying or delinking some text. -- John Broughton(♫♫)21:12, 12 December 2012 (UTC)
The rubbish bin icon is actually for removing any complex annotation from the selection, and is common to all inspectors. The problem is that right now we only have one inspector deployed (linking), so it's not as obvious a trope. Hopefully it will be much clearer when there are a half-dozen or so.
Jdforrester (WMF) (
talk)
20:57, 13 December 2012 (UTC)
Error loading data from server: Server error. Would you like to retry?
On Chrome (current/MacOS), dialogs are clipped within a header region so that most of their contents are not visible. This includes the advisory dialog which comes up when 1st opening the editor, and the 'review' dialog when trying to save changes.
Gojomo (
talk)
00:54, 13 December 2012 (UTC)
I like the visual indicator you are providing for non-editable elements of the page. It makes it very clear and the mouse over text makes it even clearer. What I feel is missing is some hint as to what to do next if you really need to edit that element. Advanced editors will, of course, know just to revert to wikitext editing but if and when this becomes the default it could be really confusing (admittedly, by the time it reaches that stage there shouldn't be many non-editable elements left).
Theflyer (
talk)
01:25, 13 December 2012 (UTC)
One of the things we're considering is created an embedded wikitext editor for elements that can't be edited in the VisualEditor - so you can cause it to create a fly-out editor of just that bit (be it a template or whatever) - for which we could do syntax highlighting and other niceties to make it the least-bad it can be. You'd be able to make and save your changes from there, staying inside the VE. But this is a little ways off for now.
Jdforrester (WMF) (
talk)
21:24, 13 December 2012 (UTC)
Templates need to be a priority (and especially references)
Since so much of Wikipedia operates via templates, it is imperative that some level of editing functionality be enabled for them as soon as possible. A special case of templates are references, which are the primary currency of an article (beyond the content itself) so the ability to create, edit, manipulate references should be first on the list IMHO.
Theflyer (
talk)
02:02, 13 December 2012 (UTC)
When you choose hyperlink and type something, clicking on an item in the list only highlights it. Hitting return does nothing; there is no clear way to exit the window. Clicking outside of it results in the text not becoming a link. I was forced to go back, highlight the text in question, and then click hyperlink, and *then* choose the desired item. When I did, the next thing I typed was still part of the link - why would I want that?
I'm sure it seemed logical to the VE team that one creates a hyperlink by (a) typing, in the article, the text to be hyperlinked, if not already there, (b) selecting that text, (c) clicking on the link icon, (d) selecting from the presented list, and then (e) clicking anywhere outside of the dialog box. But, as ZX95 points out, at least two things aren't obvious:
If no text is selected before clicking on the link icon, and then the text to be hyperlinked is typed inside the dialog box, selecting an article name from the list presented does not result in a hyperlink (wikilink) being created. Either it should (and there is a bug), or the editor should get a warning, not a dialog box, if no text has been selected at the time the editor clicks on the link icon.
After (a) through (d) are done, it is not obvious that the way to complete the hyperlink procedure is to click anywhere outside of the dialog box. It's fine that the system works like that, but there really should be both "Done" and "Cancel" buttons at the bottom of the dialog box to provide an obvious way to finish the procedure (or opt out of it). -- John Broughton(♫♫)00:29, 14 December 2012 (UTC)
What to do when an editing mistake is visible in the review
So I click on "Review and Save", and in the diff/comparison, I see that I made a mistake in my editing. Now what? I can see in two choices (buttons): "Something is wrong" and "Looks good to me". "Something is wrong" is for reporting a Visual Editor problem; "Looks good to me" saves my edit. I don't want either. What I want is a button that says "Return to article" (or "Return to editing"),
And yes, I eventually figured out clicking on the upside-down "v" in the upper right corner of the dialog box gets me back to the article, but that's more than a bit cryptic. -- John Broughton(♫♫)00:59, 14 December 2012 (UTC)
I agree that this was less than clear. it looks like the UI was designed to have a minimum of labelled buttons; this is mostly awesome, and gives the editor a nice, clean, uncluttered look, but in the case of dialogue boxes I think most people are used to having a "Cancel" button and get a bit disoriented without one. ∴ ZX95[
discuss04:20, 14 December 2012 (UTC)
The "Chaos de Montpellier-le-Vieux" page contains a gallery tag with a number of images. This is displayed in a very odd way in the visual editor. The way tags are handled should probably be improved.
Theflyer (
talk)
01:46, 13 December 2012 (UTC)
To summarize above bugs: I know that supporting these extension tags is very complex. The bugs are filed for the possibility to edit the plain wiki syntax inside the VisuelEditor as first step. Maybe showing the plain wiki text inside a box/border with an explanation/tooltip/whatever. Full graphical support would be the second or third step.
Raymond (
talk)
12:51, 14 December 2012 (UTC)
To clarify, there are three phases to working with alienated content:
Parsoid must understand the relevant wikitext natively (for core wikitext), or provide ParserHooks so that existing parser extensions written for the PHP parser can work.
This will prevent wikitext showing up as plain text in the middle of the content.
VisualEditor and Parsoid should provide a way to edit the wikitext of these "aliens" from within the VisualEditor.
A wikitext editor for alienated content was one of our plans, but didn't have a bug, now added (43133).
The VisualEditor team (and third parties and volunteers!) need to create visual "inspectors" to let editors adjust complex content.
For core wikitext, Parsoid will support the HTML->wikitext conversion natively, but for extensions, their author will need to provide "return path" code to do this conversion (e.g., how is the Parsoid meant to know what to adjust for the wikitext for an extension that lets you embed YouTube videos into a MediaWiki page?). These will no-doubt be awesome, but some of them will take extraordinary levels of work (for example, we are close to being able to enable the
Score extension for sheet music).
I wanted to remove a dead link and some text in
Lynn Hill. I tried three times. It looked like I had removed it in the VE but the edit wasn't saved. Other edits to the article were saved, however.
Wadewitz (
talk)
23:22, 12 December 2012 (UTC)
Something I'd like: currently when I want to save, my only option is "review and save." "Review and save" is good, particularly if I've made a major edit. However, personally I'd also like to have an option to just "save" -- that's what I would use if I were simply fixing a typo or changing a few words. The extra step slows me down which is kind of irritating, and doesn't add any value if I'm confident the change is what I want.
–
Sue Gardner (
talk)
19:49, 13 December 2012 (UTC)
Hi Sue, the mandatory "Review and save" is to ensure we're not accidentally corrupting pages while Parsoid (which needs to convert the page back into wikitext) is still in alpha. It'll go away (or become optional) as the parser matures.--
Eloquence*23:05, 13 December 2012 (UTC)
Yes, this is generally the case for any advanced formatting. Having a wikitext editor embed might serve for the occasional special case like this, but it's doubtful of the utility in this kind of extreme case.
Jdforrester (WMF) (
talk)
18:53, 14 December 2012 (UTC)
Comment
It's horribly slow. But that really rocks !!!!
Anthere (
talk)
When a paragraph begins with a word that's formatted in bold or italics, new text added before that word is automatically formatted the same way, but it isn't recognized as such in the editor toolbar - the 'B' and 'I' buttons aren't selected, and the 'Clear Formatting' button is not clickable.
This only applies to the newly added text; when selecting the original formatted word, the toolbar recognizes it, but when selecting the new text, the toolbar does not. As a result, it becomes just a bit trickier to unformat that new text, if I originally wanted it to be regular text.
Merlinsorca03:16, 14 December 2012 (UTC)
A possibly related bug: If you type some text, click the button to put it in a bulleted list, and then highlight the text and make it bold and then italic, then although it looks fine in the VE, the wiki markup review shows that the bold-italic text is entirely gone, leaving only a mess of apostrophes. ∴ ZX95[
discuss15:34, 14 December 2012 (UTC)
I wonder if this is related to a bug that I reported (via "Something is wrong"): The paragraph I was editing started with wikilinked text. I deleted that and added some text at the (new) beginning of the paragraph. Visually the change looked fine, but when I got to the Review step, the diff showed that the wikilink was still there, but that the first letter of the added text was gone. -- John Broughton(♫♫)23:27, 14 December 2012 (UTC)
It does look like it could be something similar...I tried going to review it, and it looks like the new text added, while looking visually formatted in the editor, is actually regular, unformatted text in the review.
Merlinsorca01:52, 15 December 2012 (UTC)
Too many divs; breaks on MacOS Chrome
There are at least two extra divs breaking the interface on my chrome instance.
One is full of green diagonal stripes and keeps me from editing in the first screenful of the vis. ed. so I have to scroll past that to make it disappear.
The second is the "review changes" div that pops open, or tries, to, when I click "review and save".
--> a) also include a "save" [no review] option, please.
--> b) on review, the mini-div that opens isn't tall enough, and is blocked by the page div that remains below/infront of it. so I can't actually see the bottom where there are options to confirm the save. I can't seem to navigate about in that mini-div by scrolling or tabbing either; tabbing moves about the page below/infront of it. So: no visual edits for me yet on this computer !
I can't see the results of various things in the top mini-div including the 'cancel' and 'review and save' buttons. for isntance, the popup on hover over the "N notices" alert is hidden by the main content div. See also previous comment. –
SJ +03:56, 17 December 2012 (UTC)
Obviousness that editing is taking place
I realize that the point of the visual editor is to make editing easier and more intuitive. However, I wonder if so many barriers have been removed that editors, new editors especially, may not realize that they are editing the page. The current editing method makes it pretty obvious that you are editing, but visual editor in its current state may be too unobtrusive.
Chris857 (
talk)
04:29, 12 December 2012 (UTC)
+1. I think the interface is fantastic; I find it simple and intuitive, and I love the fact that the whole window is the edit window (with the toolbar that stays at the top; brilliant). But for anyone who's ever edited a wiki page, it's very difficult to conceive that you're actually editing the page. Perhaps simply a light gray background or other visual clue could make it more visible that the page is being edited without ruining the stunning similarity between the final text and the edit window. In a nutshell, you guys are doing almost too good a job at hiding the edit experience :) I think some middle ground could be at least tried out.
guillom20:08, 12 December 2012 (UTC)
This is an interesting question - given that our entire intent is to get to a point where editing and reading are the same interface, I'm not totally comfortable about putting barriers back up. Something to think about.
Jdforrester (WMF) (
talk)
19:55, 13 December 2012 (UTC)
- WYSIWYG phantoms : I never saw a WYSIWYG editor output sane markup, but maybe I'm wrong and you found a way to manage it.
- Two panel reactive editor : Somehow I think a live two-panes editor with live update could be enough for most people. The main problem is discoverability or self-teaching of the syntax is the preview iteration delay, a full page refresh is a burden. To get to the point :
http://oscargodson.github.com/EpicEditor/ is what I'd aim for. Until you can migrate to a full in-place CMS (for the ontology v2 of wikipedia ? ;)
I think it's fine with the current explicit "review and save" step. If this is made more seamless, then a clearer indication of "edit mode" will be required. Even word processors have read-only modes.
Superm401 -
Talk15:39, 16 December 2012 (UTC)
We certainly hope to create sane markup (that's one of our primary objectives), but that will have to be something others judge us on. :-)
I disagree that a two-panel editor (which we demonstrated in a much earlier prototype version of the software at the end of 2011) is a desirable outcome, because another of our objectives is to obviate entirely the need for editors to learn wikitext. Helping them learn it faster, though a noble goal, is not what we're doing this for.
The current pre-save required diff is
a temporary measure whilst we're concerned about "dirty" diffs from the Parsoid, and will become an optional diff alongside the regular save dialog (as it is for the wikitext editor now).
For references (may already be known issues) on
Jacobsville Sandstone as an example, up arrows are displayed as opposed to the carets that are normal on enwiki. And refs used in multiple places appear like "2. 1.01.11.2" (note the lack of space between 1.0, 1.1, 1.2; and the number is zero-based instead of 1-based.)
Chris857 (
talk)
04:29, 12 December 2012 (UTC)
Thanks for this; there are four bugs that I can see:
Where a reference occurs multiple times, it appears multiple times rather than just the once - 43233
Where a reference is defined after its first use, it appears blank (except for the reference number) - 43234
Cite anchor links use the wrong character (using the code default of "↑" rather than enwiki's localised value "^" - 43235
Cites are zero-indexed rather than one-indexed - 43236
Sorry about these - can you confirm that you still get these? We've updated the software slightly since your report, and I've tested and now get no such errors in Chrome, Opera, Safari or Firefox (on Mac OS 10.8.2).
Jdforrester (WMF) (
talk)
17:06, 18 December 2012 (UTC)
VisualEditor as default
Would be nice of the VisualEditor was the default tab when browsing Wikipedia. This way, it would be a lot easier to make small changes immediately, instead of clicking the tab VisualEditor.
Mippzon (
talk)
15:11, 12 December 2012 (UTC)
Well, because it's still in development and doesn't work with quite a few elements of wikimarkup (infoboxes are a big one) it could cause problems :/. The plan is to eventually deploy as the default, but Engineering needs to get it fully working before we're comfortable with that, I think :).
Okeyes (WMF) (
talk)
19:54, 12 December 2012 (UTC)
Oliver (or anyone from the WMF), ultimately do we plan to default to VE mode, or to default to Read mode with VE replacing the Edit tab? I think Mippzon's suggesting defaulting to VE mode would be good.
Sue Gardner (
talk)
20:45, 14 December 2012 (UTC)
This was answered in the "office hours" open IRC meeting on Saturday, but to restate for those that weren't there: yes, this is an option we're quite excited about, but we'd need to look seriously at several things (like whether this seriously increased the page payload and calculating time for our readers) before we get there.
Jdforrester (WMF) (
talk)
17:08, 18 December 2012 (UTC)
This would be Parsoid that inserted the nowiki tags. Looking at the the relevant edit, it appears that you may have entered template wikitext in the VE. All text entered in the VE that might be interpreted as valid wikitext (Ex: {{Harv|Méry|Joly|2002}}) will get nowiki-escaped. Of course, if you never entered that template-like text, then something else is going on and we can investigate.
Ssastry (
talk)
06:39, 20 December 2012 (UTC) (Subbu -- yet to create my user page on en:WP)
Having read about it in the Signpost, I'm giving the VE a tryout. There is nowhere that I see signposted for feedback, so I'll post a couple of minor grumbles here, although I can't believe I am the first person to encounter them, so maybe someone will direct me to a more appropriate place.
Firstly, the principle is fantastic and I'm delighted to see it
Obviously the speed is an issue, I note the early stage of the Parsoid project and look forward to improved performance.
Using the VE seems to be adding pages to my watchlist even when the "Watch this page" option is decidedly not selected: not, I suspect, a tricky technical change (but I know nothing at that level)
Since I have enabled VE, it has become the default when I click on the [edit] button for each section. This is not presently useful, because of the speed and restrictions of the VE in terms of tables etc. While it is limited, it should be a specific choice, not a default position.
Kevin McE (
talk)
13:03, 16 December 2012 (UTC)
In
this edit I accidentally deleted the citation Harv|Méry|Joly|2002 because it appeared to me to be blank space. (In VE mode, I saw a visible citation, followed by a full line of blank space, followed by a period closing the sentence. I deleted the blank space between the citation and the period, which had the effect of also deleting the citation. This is not the first time VE has showed me blank space that isn't really blank.)
This issue might be related to citations being uneditable right now, and maybe it'll disappear once they are editable. But I flag it anyway, in case it's useful :-)
Sue Gardner (
talk)
15:41, 16 December 2012 (UTC)
Thank you for this. However, this is intentional - otherwise, it would not be a link to the file, it'd be a transclusion of the image, which will be done differently (an insertion inspector). Links to pages should not accidentally become images for users who do not (and should not) understand the way that wikitext expects that.
Jdforrester (WMF) (
talk)
21:55, 21 December 2012 (UTC)
Thank you for this one too. However, this too is intentional - otherwise, it would not be a link to the category, it'd be assigning the page to the category, which will be done differently (a page-level meta-data inspector). Links to pages should not accidentally become otherwise-hidden category assignments for users who do not (and should not) understand the way that wikitext expects that.
Jdforrester (WMF) (
talk)
21:55, 21 December 2012 (UTC)
The link remove/trash icon does nothing. I assume this is meant to delink it, rather than removing the text. So the title text should be clarified too.
Superm401 -
Talk17:43, 16 December 2012 (UTC)
I'm not sure I follow you. If I select some text and click the link icon, the text I selected has now become a link (it should change to be blue and underlined, depending on your User Agent and skin), and the editor opens up a link inspector to let you change the target of the link from the default (which is the same as the selection). At this point, clicking outside the inspector to dismiss it will leave you with a link in the page; clicking on the "Remove" button will remove the link from the selection. Maybe it should be "Remove link"?
If we didn't provide the remove button your only choice would be to remove all different formatting and then re-apply it, which right now would be very irritating, but when all the different other formatters are available (language, colours/font, etc.) would be unusable.
Jdforrester (WMF) (
talk)
22:53, 21 December 2012 (UTC)
Decrease Indent button is missing its tooltip message
[I'm using the latest Firefox version on the Mac; same problem with Chrome on the Mac.] I wanted to edit a single section of an article, which can't be done in VE (see comments above). But with the VE option selected, in my preferences, it looks like I can't edit just an individual section with the regular wiki editor. When I click on the "edit" link in a section of an article, VE starts up, and (of course) shows the entire article (although the pointer is at heading of the section I wanted to edit).
So now I'm going to have to turn off VE, in my preferences, if I want to edit a single section using the normal wiki editor. That's irritating. Please fix this bug. -- John Broughton(♫♫)17:34, 17 December 2012 (UTC)
There is a bug with this template : the first image’s width is 200px instead of 30px when I want to edit a page (for example
Gary Nolan (radio host)), maybe because no width is specified in the wiki source ? —
LtrlG☎,
19:59, 17 December 2012 (UTC)
HotCat is a popular gadget and any conflict with it should be avoided. For example, use VisualEditor on
User:This, that and the other/sandbox/Schfoof with HotCat enabled. The HotCat bar appears in the wrong place. (It probably shouldn't appear at all.)
A complete overhaul of HotCat may be required so it can integrate cleanly with VisualEditor. In fact it would even be nice if HotCat could become the way of editing categories using VisualEditor. — This, that, and the other (talk)00:52, 18 December 2012 (UTC)
Yeah, I've had this problem before (on English Wikipedia and also on MediaWiki.org); it comes and goes, but I've not been able to track down what causes it - it mostly looks like a race condition, but we'll try to find out why it happens - tracked above.
On stealingre-using the HotCat code for the Category interface, we're very much in favour of using others' good work rather than inventing our own where we can. :-)
Jdforrester (WMF) (
talk)
22:40, 21 December 2012 (UTC)
Links at end of paragraph
See
User:This, that and the other/sandbox/VE. I highlighted the words "made a link" (which were, at that time, at the end of the paragraph) and made them into a link. But there was no way to "escape" from the link. I wanted to add more (non-linked) text to the end of the paragraph, but it all got swallowed up into the link. Not nice. (By the way, I'm using Firefox 16.) — This, that, and the other (talk)06:31, 18 December 2012 (UTC)
I can't reproduce this in Chrome, and unfortunately I can't get Firefox to work at all right now; will check back once I've got to the bottom of that issue.
Jdforrester (WMF) (
talk)
22:30, 21 December 2012 (UTC)
Normally word processors and text editors have a left margin, allowing whole lines to be selected. There would normally be a small gap of a few pixels between the left column of text and the left margin, allowing a "margin of error" for regular text selection. To the left of this gap, any clicks select entire lines, and any drags up or down select many lines at once.
I don't know if there is a need for the complete left margin functionality in VisualEditor, but certainly, the editing area shouldn't stop at the exact edge of the letters. Perhaps the padding on the VE container needs to be increased with a compensating decrease in the margin - or maybe that's totally wrong, but you get the idea. — This, that, and the other (talk)08:38, 18 December 2012 (UTC)
Hi guys, the first impression is good and promising, especially for an alpha. We had a bit of hassle trying to edit text between a link and a fullstop plus a citation footnote. The editor kept thinking we were in the link and kept trying to edit the link instead of the text outside the link. If I moved the cursor to the right it ended at the footnote without allowing me to edit normal text. One possible fix might be something like permitting a left-or-right arrow that would exit the link without moving the cursor. Another might be that if I held down a shift key or control key, any text I typed would be outside the link.
Etc etc...
Btw, I entered the foregoing text from the article page, not from this feedback page, which I did not know about, so there is overlap between this wail and some preceding. Still, I am using Firefox 18 <snfff!!!>
I agree that the logic may need tweaking to let you more obviously break out of "pre-annotated" (keep-applying-the-formatting-to-new-text) mode. Alternatively, you should be able to press "return" to get to a new line and all the pre-annotations should fall away; if you backspace from something typed in on the new line it won't be formatted to the previous line's formatting, but this isn't a very good work-around. Sorry for this.
I posted a similar comment
above. I hope you have more success in getting a response from the VE team than I have had, so far. This is a dealbreaker as far as I'm concerned. I realize that what is offered at the moment is just an alpha version of the VE, but I'd still like to see an acknowledgment that section-editing functionality is something quite important to implement. -- John Broughton(♫♫)01:14, 16 December 2012 (UTC)
Sorry for the delay in replying.
Section editing only a part of the article within the wider article to read is not necessarily something we're sure we should do. It makes for a hugely-complex editing environment and user experience if we start inserting editing toolbars over some sections that for some reason don't let editors edit the next paragraph (because it's in another section, which is "obvious" to those of us who use wikitext but won't necessarily be for all users). There's also the questions about whether people would be able to edit multiple sections at once on one page (if so, what does the save button save - both sections or just one, and how would users be sure?), or switch from editing a single section to the whole page (and if so, can they switch back, are their changes saved for them, or retained between editing?) and other issues. However, there is no final decision on this at this point.
On the matter of section editing automatically labelling edits at the start of edit summaries, this is clearly something we should consider doing, but doesn't necessarily need people to be editing a section only to do this. Of course, asking users to always label their edits is good practice, and if the English Wikipedia would like to ask for that setting to be forced on for all users that could be done (but is outwith the scope of the VisualEditor)?
I understand that a lot of people believe that section editing is still necessary for avoiding edit conflicts; this is not the case (MediaWiki is able to cope, and has been for years). We're very much aware of the need to let several dozen people edit the same articles/areas at once, and this won't be an issue.
Hope this helps clarify our thinking in this area right now.
Heading 1 is very rare on enwiki, and indeed on most other installations. Where it is used (mostly on project discussion pages), it does not usually need to be edited. VisualEditor should not offer it.
(I also find Heading 6 a strange choice. It is very rarely used as well. I have certainly seen h5, but I honestly don't think I've ever seen a bona fide use of h6.) — This, that, and the other (talk)06:18, 18 December 2012 (UTC)
When I
edited the Architecture section of
Varnish (software) (I just moved the word will), it added a spurious ./ to a piped link, breaking it. I didn't touch the link at all. I'm using Iceweasel 11.0.
Furthermore, VE converted spaces in the same link to underscores. Since it's piped, that part doesn't matter, but I know you're trying to avoid dirty diffs, and this is a relatively simple case.
Superm401 -
Talk15:46, 16 December 2012 (UTC)
I have visual editor in my preferences and am on
List_of_numbers#Algebraic_numbers. I click the section edit link and it defaults to Visual Editor, however that section is awfully complicated to expect it to work with Visual Editor with math stuff there.
1) I am not sure about defaulting section editing to the visual editor, just yet. Maybe it can be a preference?
2) There should be an "Advanced" toggle or button in the edit mode, so I can switch to regular wikitext.
See
this edit. The only part of that that was intentional was the removal of the wandering dash. VisualEditor stripped the spaces between the bullets and text. Furthermore, when I clicked "review and save", the diff that was shown to me for review only showed the intentional portion of the change and did not show the removal of that whitespace, which is perhaps the bigger issue.
jcgoble3 (
talk)
01:38, 26 December 2012 (UTC)
Watchlist
The editor is automatically adding pages I edit to my watchlist even though i have been careful to ensure that the add to watchlist box is not being checked when I save the edit.
NtheP (
talk)
18:55, 26 December 2012 (UTC)
I failed to drag-and-drop text from one spot to another.
Article Areole. Doing a section edit. Generally worked OK, but it ignored my attempts to move a selected (highlighted) word to elsewhere. Am I missing instructions, or is it not yet implemented?
JonRichfield (
talk)
16:48, 22 December 2012 (UTC)
Here's an (possibly useless) idea: What if when a user is editing a page with the VisualEditor and a reader submits feedback using the Article Feedback Tool, the feedback immediately showed up in the "notices" part of the editors screen? --
Yair rand (
talk)
12:13, 27 December 2012 (UTC)
Missing features
A few minutes ago I wanted to try the VisualEditor for seeing how it looks like. There are two features which I miss (or which I didn't see):
There seems to be no way to show something like a diff before saving.
There seems to be no possibility to switch from VisualEditor to the old one during an edit.
If I use the VisualEditor, it is possible that I want to switch to the old one after changing something and before saving. Without these two features, I can hardly imagine to use the VisualEditor.
I think that the first point is very important for making the VisualEditor usable, the second point only for people knowing the previous wiki markup.
Stefan Knauf (
talk)
18:22, 28 December 2012 (UTC)
The first point is already implemented; clicking "Review and save" will first show you a diff before giving you the opportunity to enter an edit summary and save. Viewing the diff is in fact mandatory during the alpha test to ensure that nothing breaks; it is my understanding that it will be optional in the final implementation.
jcgoble3 (
talk)
23:39, 28 December 2012 (UTC)
I can't figure out how to enter a template using the visual editor; the template code is automatically surrounded with 'nowiki' tags.
PowersT04:37, 29 December 2012 (UTC)
Erroneous edits committed
I was editing
Star Trek: First Contact, and ended up with three edits in the history (all with the same summary). The first contained the correct edit I intended to make, but the second and third added these erroneous duplications of an unrelated sentence fragment:
[3].
PowersT19:45, 29 December 2012 (UTC)
Templates not shown correctly
I've few "template boxes" on my user page. They are side by side, but visual editor does the layout slightly differently.
Harriv (
talk)
22:04, 29 December 2012 (UTC)