Share your feedbackReport bugsYour feedback about the VisualEditor beta release
This page is a place for you to tell the Wikimedia developers what issues you encounter when using the VisualEditor here on Wikipedia. It is still a test version and has a number of known issues and missing features. We do welcome your feedback and ideas, especially on some of the user interface decisions we're making and the priorities for adding new functions. All comments are read, but personal replies are not guaranteed.
VisualEditor is a way to edit pages that looks more like a word processor. It was first offered here in 2013.
How do I enable VisualEditor?
VisualEditor is available alongside the original wikitext editor if you opt-in, by changing your preferences. It is currently not available to unregistered users at the English Wikipedia, unless they switch modes while editing.
Why is this change being made?
Some people who could become productive, experienced members of the community are turned off upon attempting their first edit in wikitext "source" mode. Some edits, such as adding or rearranging columns to a table in wikitext, are difficult even for experienced editors.
Where do I go to learn more about how to use VisualEditor?
In most cases, VisualEditor will not change or reformat lines that are not being directly edited. If markup already on the page is handled incorrectly (for example, with tables that are not closed), then it may attempt to correct these.
Will it still be possible to edit articles using wikitext after the visual editor becomes available?
Yes. While the visual editor will become available to all users as an editing environment, a method for editing the underlying wikitext "source" will continue to exist. There are no plans to remove the "Edit source" option.[1]
Won't this slow down reading and editing for people who have slow connections or computers?
VisualEditor loads the bulk of its code only when you edit a page in the visual editing mode. So if you keep using "Edit source" or are a reader, the effect on your user experience should be negligible (~4KB of additional JavaScript payload before you click "Edit", or about 0.5% of one typical page). Your web browser will typically cache the JavaScript, speeding up future uses even if you are on a slow connection. However, using the visual editor for editing may cause problems for those on slow computers or connections, especially on very large pages. For these users, opting-out for now may be the best option.
I've found an issue with VisualEditor or a feature that is missing. How can I tell you to fix it?
Please report the issue in Phabricator, after first searching exiting tickets to make sure it hasn't been reported already. Additional bug reporting instructions can be found here. There are four main kinds of issues that the developers especially need to hear about:
Something breaks: The failure may only affect a particular type of browser or computer, on a particular page, or after doing something else. Please post your problem at Wikipedia:VisualEditor/Feedback. In your description, it is helpful to include information about what you were trying to do, your web browser, computer operating system, and a link to the article or a diff of the edit if it was possible for you to save the change.
Performance problems: If all pages seem unexpectedly slow on loading or on performing a particular task, or if it used to be faster and has recently gotten worse, then please report this.
User experience issues: If it didn't make sense, or if it was awkward, or if you couldn't figure out what you needed to do (Wikipedia:VisualEditor/User guide covers the basics), please speak up, and feel free to offer your suggestions for improving the design.
Missing functionality: Is there something you need to do, but it currently can't be done in VisualEditor, like editing mathematics equations or seeing hidden comments that contain instructions to other editors? Make sure that it's on the developers' list of needed features. If you'd like to know which missing features have been reported before, you can search the talk page archives and feedback archives. If you can't find any reference to the new feature you'd like to suggest, please report it at mw:VisualEditor/Feedback.
To continue to edit the wikitext directly, simply click the "Edit source" button instead of "Edit". On section edit links, you can open the wikitext editor selected in your preferences for that section by clicking "edit source" instead of the regular "edit" link.
If you would like to remove VisualEditor from the user interface, then you can do so.
If it is a beta feature: go to the Beta tab of your preferences page, untick the checkbox "Visual Editor", and click the Save button near the bottom of the page. (As of 2021, this is how you do it on Meta-Wiki and the Chinese Wikipedia.)
If the visual editor is already out of beta:
go to the Editing tab of your Preferences page, untick the checkbox "⧼visualeditor-preference-betatempdisable⧽", and click the Save button near the bottom of the page. (This is how you do it on some sister Wikipedias, for instance, Russian Wikipedia, as of 2021.)
Can I install VisualEditor on my personal wiki outside Wikimedia?
Yes. The VisualEditor extension is available for download.
Can I use named references like the basic wikicode editor does, so I can choose my own reference names?
This has been requested via Community feedback, and is on the list of things to do. There are some links and more information about this on the Wikipedia:VisualEditor/Named references page.
The FAQ didn't answer my question. Where may I ask it?
^<<And no, we're not taking markup-level editing away. Some users may always prefer it over visual editing, even if the exact nature of the markup changes, and even if VisualEditor becomes the best tool it can possibly be.>> Erik Möller, deputy director of the Wikimedia Foundation, The VisualEditor Beta and the path to change, op-ed for Wikipedia Signpost, July 31st, 2013.
Deleting highlighted text
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)[reply]
@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)[reply]
Not enough said at all. What specific problems do you have with the VisualEditor? It's going to be deployed at some stage; it is in everyone's interests for people with issues to speak up so we can try to solve for them. Okeyes (WMF) (talk) 18:51, 16 June 2013 (UTC)[reply]
Thank you Okeyes (WMF). What I'm about to say is not directly for you but to them who are complaining here. I wish people could be more open with VE as it surely brings new editors who have avoided editing because they are not into codes and stuff. I wish people would not attack each other when they first see some changes. I've been a member of a game community for over 5 years and have done nothing but found and reported bugs. I used to enjoy the game until it turned out to be full time job and yet I didn't walk away. Over five years I've been struggling with the game, with its old version, beta version and now with a new version. Surely it's been exhausting but as I said I didn't walk away even though we had no chances of editing old-fashioned style and new-fashioned style as people can do in wikipedia. We only have got one style for editing and it's a lot worse than what happening here. Old editors here can use old-fashioned style for editing and yet they are complaining when you guys are trying to make this more user friendly for people who have knowledge but have no time or interest of learning all codes, as Pointillist mentioned below. Feedback is always welcome but being hostile for changes that really don't take anything off but give more tools for more people is not constructive. It's not polite to belittle newcomers. Also I have been screaming for many things and changes in my game community and in life generally but it doesn't mean I need to be mean when something happens. If people rather have this hostile attitude over VE towards other people even they have no reasons for that, you can be sure that newcomers don't join this community and leave you all in peace for doing what ever you were doing before VE, even though it would mean that they also take knowledge with them. If old editors here know all about everything, who needs new editors and their knowledge in this perfect community. Any of you have been novice once but obviously don't want to remember that. It's time to remind that we have to start somewhere as you once did. If you think that you can make wikipedia by yourself and don't need more people and knowledge here, so be it, but I have learnt long time ago that there's no such thing as perfect people. No offense but these comments here make me wonder if I wanted to do anything with wikipedia. But as I'm not doing anything much in English wikipedia, I don't need to read these negative comments, unless I'm looking for some help here. I really wish people could take things as they are, especially when there's no reason for crying out loud. The dogs bark, but the caravan goes on. And pardon my French. ;) AniaKallio (talk) 09:03, 29 June 2013 (UTC)[reply]
We've been screaming for a Visual Editor for literally years. If you say "whoah, let's halt this" now, no-one will listen, and quite rightly. The VE is almost usable enough for a serious workout ... that magical point where software becomes usable enough to seriously beta for bugs - David Gerard (talk) 19:56, 16 June 2013 (UTC)[reply]
I don't think there is any doubt about the strategic importance of having a full-featured, stable Visual Editor that inexperienced editors can use to make contributions without great risk of damaging existing articles. As I see it, the majority of concerns being expressed here are about deploying the current solution too widely too soon. It's a question of what&when, not whether. - Pointillist (talk) 21:10, 16 June 2013 (UTC)[reply]
Yeah, I'm not sanguine about this being ready for a July release. It's so near serious beta status, though ... I'll whinge about it here, with diffs, because I want it to get better real quick ... I've been tending to do a simple edit, create a diff that's been crapped all over, then revert and post the bad edit here, 'cos that's the best way I can think of to get attention to the problems - David Gerard (talk) 21:22, 16 June 2013 (UTC)[reply]
Mmm, I agree, except that real quick angle. IMO that's not really how software gets fixed. There's a small development team for VE and it looks as though the implications of editing complex pages completely safely weren't sufficiently explored by the business. It'll take time to get this right, and I doubt that Okeyes (WMF)'s recent promises to "kick the developers" are going to help. - Pointillist (talk) 21:50, 16 June 2013 (UTC)[reply]
It's the popular pages, which tend to have the insanely complicated wikitext, which the n00bs will hit first. I'm sure it'll be popcorn all round - David Gerard (talk) 22:37, 16 June 2013 (UTC)[reply]
That is the problem with WMF lately. Trying to kick things to impose their will instead of working through rough consensus. The WMF tries to run things through Meta which few people check for long due to the lack of integrated watchlists. Then the WMF tries to use "a small development team for VE" instead of what is needed, a massive development team. When the WMF finally realizes after years of work that the poorly-funded VE team may actually have something almost usable it tries to rush it through real testing on English Wikipedia.
Then the VE team gets inundated with genuine, non-ass-kissing feedback from busy editors who aren't part of the cliques at Meta and WMF. So this is the real world of English Wikipedia where no prisoners are taken. Get used to it, WMF. Or you may alienate more active editors by imposing a half-finished product.
This really is a good product if both source code editing of sections, and VE editing of sections, can both be used at anytime without having to go through preferences. That is being worked on (see bugzilla:48429). Lots of things need to be fixed, but the basic product looks good. Much better than Wikia's visual editor. But fixing all the problems will take time, and this beta should not be made the default for registered editors until the problems are fixed. Now that registered editors can opt in to VE the problems will continually be pointed out and fixed. And no one will be forced to use VE during this beta period. VE will not mess up thousands of pages if it is not prematurely made the default. --Timeshifter (talk) 23:38, 16 June 2013 (UTC)[reply]
So, let me just correct some assumptions here. The WMF isn't using a small development team - by Foundation standards, it's a very large development team. We've currently got eight people assigned to the project, seven of them devs (which seems the right ratio to me, at least). The WMF isn't running things through Meta, it's running things in parallel on multiple wikis - I can't help but feel that it's somewhat silly to poke a WMF staffer to pay attention to your thread, on enwiki, on the enwiki VE feedback page, which the staffer monitors, as part of a suite of pages on enwiki set up by the VE team....to tell the staffer that things are being run through meta.
If you think we're not aware that the enwiki community is a "real world" community, I invite you to take a look at my userpage and tell me that the people running this launch don't know what they're doing. Then take a look at my boss's. Following this, I invite you to come back and offer the feedback you have in a tone that doesn't imply you think we're all idiots. We're not expecting ass-kissing; we're expecting basic politeness. Okeyes (WMF) (talk) 10:00, 17 June 2013 (UTC)[reply]
It has obviously not been a large enough development team over time if it has taken this long to get this far. To say otherwise is delusional. A visual editor has been desired for many, many years. Much discussion about many major development projects in the past in my experience has been through Meta. Other venues have been used too. The major feedback discussion about the visual editor in practice on Wikipedia has only occurred relatively recently, and it is being rushed through incredibly fast lately. If you are asking whether I think some of the WMF staff are idiots, you are baiting and trolling.
You did not address the point from me and others in this thread about this being rushed through lately. Pointillist asks: "As I see it, the majority of concerns being expressed here are about deploying the current solution too widely too soon. It's a question of what&when, not whether." He also wrote: "There's a small development team for VE and it looks as though the implications of editing complex pages completely safely weren't sufficiently explored by the business." --Timeshifter (talk) 10:28, 17 June 2013 (UTC)[reply]
The technical complexities of any VisualEditor are vast. While it has been discussed for many years, that is very different from it being developed for many years. Development only began around two years ago (actually, taking into account the Parsoid team - we've got 12 developers, not 7. Certainly the biggest team I've seen here). Much discussion has occured on Meta in your experience, I'm sure - but this is not the case for the VisualEditor, or Page Curation, or AFT5, or Echo, or the mobile team's work, to my knowledge, or... etc, etc, etc. I haven't seen meta used as a primary discussion venue for major software since I joined the Foundation, almost two years ago. And if you think Meta is somewhere that the Foundation gets ass-kissing, I'd ask if you've ever seen the sort of people who tend to edit on Meta ;p.
To address your core point: yes, we're developing quickly - that's not a timetable set by me (or anyone else on the team), but it's a timetable we're going to do our best to adhere to while also doing our best to avoid deploying a bad product. There are a lot of bugs with the VE at the moment, some major, some minor, and the community-facing staffers are working closely with the development team to get them resolved, and to make clear what bugs are (from our point of view) blockers to any deployment. I have hope that these bugs will be fixed before any deployment takes place. Should new ones crop up during, for example, the A/B test, on such a scale as to totally disrupt editing for VE users and non-VE users, we retain the ability to disable the VE very quickly. Okeyes (WMF) (talk) 10:40, 17 June 2013 (UTC)[reply]
I discuss the technical aspects in the next talk section.
I don't want to belabor a point, but if the visual editor has only been worked on for 2 years, then it is worse than I thought. Wikia worked on it longer, and people have been asking about it on Wikipedia almost since Wikipedia was first started. Also, I wonder how many of the people working on VE have been working on it full-time. And when did they move from working on it part-time to working on it more. People have often asked the WMF to hire more development staff instead of the other staff they hire. I know I have. There are so many major features that have been requested over the years.
As for Meta, I use Meta as my all-around generalization for WMF discussing things away from Wikipedia. Whether feedback occurs through MediaWiki.org or Bugzilla or Meta or Strategy or other wikis they are all places ignored for the most part by regular editors due to the lack of integrated watchlists. MediaWiki.org uses the much-hated LiquidThreads for its talk pages. So it has 2 strikes against it being used much by regular Wikipedia editors for feedback. Bugzilla is even more difficult for regular editors to use and keep up with. It took me a long time to figure out how to use it somewhat effectively. I even researched and wrote a lot of how-to tips at WP:Bugzilla. You and I both act as interfaces between regular editors and developers, and between regular editors and the WMF board/staff. But the real solution in my opinion is to move most WMF and developer feedback to locations with watchlists that more people use: English Wikipedia and/or the Commons. --Timeshifter (talk) 11:28, 17 June 2013 (UTC)[reply]
I'm certain much work has gone into this, however, I suggest that you have an "opt out" option. I've been on Wikipedia for over 7 years and have over 120,000 edits and have written several thousand new articles.
Honestly, I haven't heard a massive cry from the user community about the need for a visual editor. Nevertheless, I subscribe to the Keep It Simple Stupid (KISS) philosophy when it comes to change and "making things better". I'm quite happy, thank you, with the current editor as it gives me maximum flexibility to edit and create articles without having to experience the problematic issues that seem to be well-documented by other Wikipedians (above) in this discussion.
If Visual Editor is designed for new editors, then that's all well and good. However, for the experienced editors here, I'd be quite happy with the old, antiquated, simple editor I've been using the past seven + years. I just don't see any advantage of going though a leaning curve to learn new software that, in the end, will force a learning curve and in the end, do exactly what we're doing now with the existing editor that is quite simple to use, is extremely flexible and quite adequate. Just a few thoughts. Bwmoll3 (talk) 08:39, 20 June 2013 (UTC)[reply]
At this point, there are absolutely no plans at all to turn off the classic wikitext editor for anyone. You don't need to opt out of VE to get what you're used to. You just need to click the [Edit source] button, which will always[1] be on every editable page. Or, to put it another way, there's no way to opt out of the classic wikitext editor. Everyone will have access to both.
^For values of always that may be somewhat shorter than the WP:DEADLINE, but are longer than the next couple of years.
I'm looking forward to VE because it'll make it possible to introduce friends and family to the joys of editing (and wasting hours trying to find sources for articles). When Everything is Working Properly™ I'm going to encourage my brother, sister, father and father-in-law to get started here. They've each got domain-specific knowledge, good writing skills and I know the retired parents have time to spare. If all our experienced editors were to recruit and induct a couple of new editors each, the project would get an enormous boost. That's the central benefit of the Visual Editor IMO. - Pointillist (talk) 10:25, 20 June 2013 (UTC)[reply]
An excellent point :). You know, I've been genuinely impressed by how willing so many community members are to open their minds around the VisualEditor. Sometimes I'll be working on software and it'll be a bit controversial, or not aimed at experienced editors, and a user will just suddenly turn up and blow me away with a well-reasoned argument for why this is A Good Thing, even if it's not something they'd use. With the VisualEditor, that seems to be happening daily. My barnstar button is looking rather worn. Okeyes (WMF) (talk) 14:10, 29 June 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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, [1] (in which Visual Editor also made random formatting changes... oh well):Jay8gInspect-Berate-KnowWASH-BRIDGE01:59, 25 June 2013 (UTC)[reply]
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)[reply]
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)[reply]
That is the current way to not use it. Once VisualEditor is turned on as default, you can go to your preferences and under the editing options turn off VisualEditor, just as right now you can select to turn it on. Keegan (WMF) (talk) 23:51, 25 June 2013 (UTC)[reply]
Or use one of the many browsers that are currently not supported, such as Opera.... Personally I still think this is being rushed far too quickly. Dsergeant (talk) 06:07, 26 June 2013 (UTC)[reply]
VisualEditor is improving a lot and in general I now prefer using it to editing the wikitext, so that's a huge step forward. I'm really looking forward to the instructions on how to use TemplateData so that we can get template parameters displaying in VE. A couple of issues I've noticed lately:
In VE infoboxes tend to sit on top of the text rather than the text wrapping around the infobox. As such you can't edit the text underneath (or you can, but you can't see what you're doing!)
When I first navigate to an article page and click any of the section edit links, VE opens. After making a change in VE, if I then click on one of the section edit links, I get the old wikitext edit box. Similarly javascript tools (notably WP:POPUPS) don't seem to work after saving an edit in VE.
Having played a bit more, it's not image_map specifically but there definitely seems to be something odd when there's an image in the infobox. WaggersTALK07:50, 26 June 2013 (UTC)[reply]
Yes it is, it seems to happen with any page with an infobox containing an image that is wider than the infobox would be if it didn't contain the image. WaggersTALK19:14, 28 June 2013 (UTC)[reply]
I see what you mean. The opposite happens at an article like Leukemia, where it seems to think everything should be skinnier than default. I have just created a Bugzilla account and filed this as my first bug. (I hope I did it right!) Whatamidoing (WMF) (talk) 09:35, 29 June 2013 (UTC)[reply]
It's supposed to be the same problem as Template:Bugzilla. Southampton is still screwed up for me. I'm not sure how to interpret this comment, which seems to say that it both hasn't deployed and that it already deployed. It might be one of those things that's fixed in the code but hasn't quite reached us. Whatamidoing (WMF) (talk) 10:34, 1 July 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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?
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)[reply]
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)[reply]
When I am trying to edit anything on the table/template that exists on this page, even if that is a simple typo, it gives me the notification:
→Cite error: There are ref tags on this page, but the references will not show without a reflist template. (See help page)
First, why is this happening and second, it's obvious that the page does have a reflist. Same happens to all the table/templates that are like this one. TeamGale (talk) 23:19, 25 June 2013 (UTC)[reply]
OK. The same thing as I said at the very beginning still happens with the table. Nothing changed. When I edit it, the notification appears so for now the only way to do it is with the "edit source" road.
For the references, I am not sure what you mean by saying that you can't edit them. Can't edit the old ones or can't add a new one? I can do both. What I noticed though is that when I clicked in an "old" ref to edit it, the text on the ref box appeared as a template so I had to click on it and edit it as template. I have to say that's something I was thinking to ask to be added on VE but, I see that it's already there. It took me 20min to discover how to do it after watching it but, I finally found it! :D
I am not sure if that's what you were asking. If the Q was if I could edit the article, table or refs, the answer is yes, except from the table that was the original problem TeamGale (talk) 14:59, 26 June 2013 (UTC)[reply]
Just wanted to say that this issue still exists. Can't edit with VE this type of templated because of the error that appears after the edit TeamGale (talk) 08:20, 28 June 2013 (UTC)[reply]
Hmm...I don't think is something specific because if I try to edit anything on a table like the one above, even if it's just one letter, I get the error notice in red letters...if you can explain me how to post a screencap, I might be able to show you what I mean better. If you try to edit the table, you are not getting that notice? TeamGale (talk) 10:40, 28 June 2013 (UTC)[reply]
I am. I'm not 100% sure it's a bug - it's a valid warning when there isn't a way to expand refs on the page, but there is at the bottom. That said, it certainly is confusing. In spite of the warning, I was still able to save the change (beyound -> beyond). TeamGale, are you trying to complete the edit after you change the template? The template editor subpage does not save the change - you have to click "Save Page" still at the top. Apologies if you knew that and it didn't work for you. :)
Meanwhile, while I managed to correct the typo, I am not at all happy with its decision to move episode 9 to the top of the list ([2]). Checking to see if this is a known issue. --Maggie Dennis (WMF) (talk) 14:04, 29 June 2013 (UTC)[reply]
Hmm...to be honest, after getting that notice I never tried to save the page because I didn't want to "damage" the table. I was clicking cancel and was going the old way to make my edits. But it seems that what VE does after saving, is way more interesting. TeamGale (talk) 15:11, 29 June 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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).
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)[reply]
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)[reply]
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)[reply]
Correcting typos
It would be helpful to have key mapping for correcting certain common typos, e.g.,
I think the user wants some kind of "change case" tool (e.g. change a passage of uppercase text to lowercase). The existing wikitext editor doesn't have this, but I suppose it could be nice to have it in VE. — This, that and the other (talk)06:10, 28 June 2013 (UTC)[reply]
Plausibly but, well, operating systems tend to cover this indirectly :/. Given the number of bugs/necessary enhancements I can't promise this is something we'll work on, now or in the near future. Okeyes (WMF) (talk) 09:43, 28 June 2013 (UTC)[reply]
Editors for operating systems may have tools for manipulating case, but not for altering the case of data maintained by an application. Are you suggesting cutting the text, pasting it into an external editor window, changing the case, cutting and pasting the text back? That would work, but seems rather clumsy. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:15, 28 June 2013 (UTC)[reply]
Or, in plain English, you're saying that if an editor encounters "tHIS IS THE WAY THE COOKIE CRUMBLES" in an article, then he should just re-type it from scratch rather than solving the problem by clicking a button.
The shift and caps-lock keys have an effect when you are typing; they cannot correct the case of text that has already been typed. Two of the editors that I use on a daily basis have case translation facilities, and I make heavy use of them. I doubt that I'm the only one that periodically accidently hits Caps Lock instead of Shift. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:43, 30 June 2013 (UTC)[reply]
Yes, it's easy to bump the caps-lock key (although I find that aiming for the tab key, rather than shift, is when I bump it). I also think it would be helpful for times when you're copying and pasting titles from sources, which sometimes use all-caps.
We could file a request for an enhancement. The only thing we can promise is that it won't happen any time soon, as fixing existing problems is obviously a higher priority than adding handy features. Would you like someone to do that? Whatamidoing (WMF) (talk) 06:57, 1 July 2013 (UTC)[reply]
It is awkward to enter special characters with the current editor. I would like to see a facility in VE to allow selecting characters from displayed Unicode pages as well as by typing their Unicode names. In additional, I would like a facility to automatically change certain characters to character attributes, e.g., []. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:36, 27 June 2013 (UTC)[reply]
VisualEditor doesn't normally interpret anything as having syntactic significance (see, e.g., half a dozen complaints that typing [[something]] gets nowiki'ed rather than producing a link). You can already type text with single square brackets around it without doing anything special. Here is an example. Did you have something else in mind? Whatamidoing (WMF) (talk) 15:34, 29 June 2013 (UTC)[reply]
If you try to insert it as raw text, yes, along with the braces and pipes. If you try to insert it as a template, using the reference editor, no. Okeyes (WMF) (talk) 18:56, 30 June 2013 (UTC)[reply]
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)[reply]
Edit and edit source links so confusing I had to disable Visual Editor in preferences
I disabled Visual Editor (VE) in preferences today due to constantly clicking the "edit" link instead of the "edit source" link. I am talking about section editing.
I almost always prefer editing with the source editor since I make frequent edits to tables, images, navboxes, and reference formatting. All at a deep level of formatting, placement, etc..
But since the source editing link only shows up after unintuitively mousing over the edit link I am constantly clicking the wrong link. So you have lost another beta tester. A good one too since I have written many comments and bug reports about VE here and in Bugzilla.
It would be better to use an icon for the "edit source" links for sections. For ideas:
I appreciate it's not immediately intuitive - I think that's always going to be the case for a subset of users with, well, any design. Icons are, I suspect, something that the community (at least on enwiki) would object to, and something that is very different from every other element of the interface, making them appear rather odd. If you look at the button below "enable the VisualEditor" in your preferences you will see there is an option to restore the old 'edit source' links as 'edit', without any mousing over; this is better than losing a beta tester, obviously. Okeyes (WMF) (talk) 19:07, 27 June 2013 (UTC)[reply]
There are many icons used constantly on Wikipedia. Look at the editing toolbar in the edit window. Look at the top of the page at the star used to add and remove the page from one's watchlist.
Mousing over a similar, but incorrect, link to be able to click on another link is not intuitive. It is confusing. Many people might adapt to it kind of like adapting to cheap chairs. :) But that does not make something intuitive that is inherently non-intuitive and illogical.
"edit source" can show up after mousing over the icon. That is much more intuitive. Just like mousing over the watchlist star at the top of the page.
This could drive away many editors. Anonymous editors especially. They have no ability to fix the problem by turning off visual editor in preferences. Many anonymous editors just do not like to log in, and are very used to editing in source editor. Some will be very irritated by the confusing clicking. --Timeshifter (talk) 19:35, 27 June 2013 (UTC)[reply]
Of the examples you've given, one of them (and it's a fairly tiny icon) is present in the reader-facing interface, which is what we're talking about here. I have serious concerns, as do others, that there would be understandable and substantial pushback from the community on introducing the icon, which would undermine any utility it provides since said utility is based on people accepting it. If you're interested in convincing us that this is worth pursuing, I invite you to start up a wider discussion about whether an icon would work better than the existing link. Again, I would ask for a citation on your statements about the habits of anonymous users. Okeyes (WMF) (talk) 19:45, 27 June 2013 (UTC)[reply]
I read what others write since I started editing Wikipedia in 2005. That is the citation. You can choose to ignore me, brush off my concerns, or otherwise pooh-pooh my complaints. You do this a lot concerning many complaints on this page. Your lack of respect in many cases, and true engagement in many cases, is an example of why many people dislike some of the WMF board members and staff.
I have seen your type of response many times on Wikia when we brought up the numerous problems with their visual editor. And so that visual editor remains unused by many, if not most, regular editors. Even worse this visual editor is now similar to that visual editor in that regular editors will have to disable it in order to be able to edit effectively. Wikia refused to provide an option to put the source editor tab on top of the visual editor tab. So people had to do a multi-stage process for every single edit in order to get to the source editor. Click edit, then wait tediously for visual editor to load, then click the source tab. For every edit...
Similar to here now. I have to use a multi-stage process to get to the source editor. Aim at "edit" link or the line it is on, mouse over that "edit" link or line, aim better if necessary, wait for "edit source" link to show up, move mouse over to that link, click. Many times I accidentally, or by habit, click the edit link, and then have to click the back button, and start over.
Here is a possible icon method. "Edit source" tooltip can show up after mousing over the icon. And the small icon can have a transparent left and right border that makes the area wider for mousing over. So people will have no problem understanding that the icon is an "edit source" link. The visible part of the icon will be small, similar in size to the watchlist star at the top of pages. But the clickable part would extend to the left and right a bit to allow easier clicking. --Timeshifter (talk) 23:03, 27 June 2013 (UTC)[reply]
I'm sorry you feel that my attitude is one of "brushing-off" complaints; I'd like to think that with the vast majority of issue reports I've been polite and reported them to the devs, who have ideally solved for the problems. But, here's the situation; my gut says that actually this is a pretty good implementation. The users here seem to agree - I see two contributors negative about it, three positive, which might not sound good but given the community's almost legendary capacity to speak up when it feels annoyed (and stay silent when it's comfortable with a decision) this would seem to suggest that people are generally okay with the change. My gut also says that the community is likely to be annoyed by an icon popping up in the middle of article text. I'm not brushing you off, I'm making a legitimate offer, here - demonstrate that this sort of iconography is something that the community wants or alternately is comfortable with, via a village pump discussion or any mechanism you choose, and I'll raise it to the developers. If you're not willing or able to do that all I can go on is the data I have in front of me, which, given the lack of shouting, strongly suggests most people are totally fine with it. Okeyes (WMF) (talk) 10:06, 28 June 2013 (UTC)[reply]
People shouldn't have to shout for you to listen. SHOUTING is frowned upon on Wikipedia. Several people in bugzilla:49666 also dislike multi-stage methods of getting to a link. It is clunky and wastes time. Anything that wastes editor time is a bad thing. The point of a visual editor is to get more editing done. It is hoped that it will make basic text editing and reference editing simpler for newbs. Making editing more difficult for more experienced editors is a bad idea. There are many experienced editors who do not log in. We can not afford to further erode the number of people who are editing. Nor can we afford anything that lessens the efficiency of editing.
Wikia's corporate execs and staff screwed up many things on Wikia, especially the visual editor. They had their gut feelings, and they have often been wrong. What is about execs and staff in organizations? I thing it has to do with groupthink, and the fear of telling the boss they are full of it on certain issues. So problems get glossed over, up and down the chain of command. Your gut feeling about icons is just that, a gut feeling. I highly doubt that anyone will edit less often, or edit less efficiently, because of an icon, or even a direct text link to "edit source". I am happy with either one. --Timeshifter (talk) 10:42, 28 June 2013 (UTC)[reply]
I'm not saying people have to shout at me, or that they should, just that they regularly do. If you think shouting is frowned upon you've clearly not seen many of the discussions around controversial software changes. I'm not a corporate exec - heck, I'm barely staff (short-term contractors ftw) - I'm a long-term editor and sysop who, my bosses will confirm, is perfectly willing to tell said bosses they're full of it. On this, however, I don't think they are. My gut feeling is, indeed, a gut feeling - the same is true of yours. Again, if you want to start a discussion and demonstrate that this is a wider problem than the evidence suggests, I will move forward. The alternative is that you're asking us to put our energies into a tweak with little evidence to show it is necessary. Okeyes (WMF) (talk) 10:49, 28 June 2013 (UTC)[reply]
I also dislike the new rollover system. The extra step is not justified by minor aesthetic concerns. If you want the buttons to look less in-the-way, I would suggest moving them back to the far right side of the page rather than hiding one of them. Speaking of which, if you set your account preferences to force the edit buttons back over to the right, you end up with an edit button floating about an inch to the left of where it should be and a big blank space waiting to display the edit source button.
Looks like it's actually a user gadget (Gadgets → Appearance → Move section [edit] links to the right side of the screen) so that's probably the issue, but I would still suggest moving the buttons over there as the default. I thought I remembered it being the default at one point, actually. Also, to be fair, it's not actually causing any problems in terms of functionality; it just looks really stupid.
Can I suggest a compromise? How about there be a setting in the Preferences that determines which edit link is shown first and which is hidden, make the [source edit] default for all existing users, and make the [visual edit] link default for all new accounts created after it's implemented. The next time a user opens an edit window, they would receive a "setup prompt" that would ask them "which editor do you want to set as your default?", which could be saved as a cookie for IPs and saved as a user preference for users.
Also, those icons are hideous from a design standpoint, and could probably be represented with unicode and CSS. Maybe
A good suggestion, but it sounds potentially finnicky and raises some philosophical questions (do we include a preferences switch for everything anyone could object to? If so, what do we do about the implication that we then support that outcome? How do we avoid doing this in a way that hinders future development?). In my experience if people are legitimately peeved by this they're liable to write a CSS hack that solves for the problem anyway. Okeyes (WMF) (talk) 14:02, 28 June 2013 (UTC)[reply]
Well, it's important for mobile users, where the hover state doesn't exist. In fact, I just tested on my iPhone, and it is impossible to use the source editor.—Love, Kelvinsongtalk14:12, 28 June 2013 (UTC)[reply]
Yes, but we're building a distinct and proper mobile setup as we speak, so hopefully the need to jury-rig the desktop interface on a mobile phone will go away. Okeyes (WMF) (talk) 14:22, 28 June 2013 (UTC)[reply]
Okeyes. We should solve as many problems as possible for as many people as possible. That is my answer to your question: "do we include a preferences switch for everything anyone could object to?" Or we use better designs where possible so that preference switches are not necessary. See talk section below for the reasoning:
I think that Oliver's suggestion of a regular community discussion on this point, perhaps at WP:VPR, is a good one. Since this seems to be more "irritating" than "desperately busted", there's no immediate rush here, so it could be held whenever anyone wants to start it. (If it's soon, then perhaps a link here would be handy, in case the devs follow up on it.) It sounds like the Mobile version isn't going to be a problem, so I'll add accessibility as a possible concern that could be discussed. It seems likely to me that people who have physical trouble using a mouse would have trouble clicking a link that moves on hover. So if anyone decides to start this conversation, then perhaps he or she would invite WT:ACCESS folks to join it. Whatamidoing (WMF) (talk) 15:55, 29 June 2013 (UTC)[reply]
The more problems, the less people will edit. See talk section below:
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)[reply]
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)[reply]
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)[reply]
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) :)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
Has it yet been discussed that when using VisualEditor, it doesn't seem that invisible comments <!--like this--> are visible to editors? We often rely on these to tell editors things like "please don't change this to 'color'; this article is in UK English" or possibly "this wording was decided by a binding RFC; please don't change it", and it would seem to be a loss if we no longer have a way to make new editors aware of such things. Heimstern Läufer(talk)05:46, 28 June 2013 (UTC)[reply]
Urgh. Would someone be willing to explain what that discussion means in a way non-devs can understand? Like, what is actually happening with comments? Is something being done to deal with this problem or not? Heimstern Läufer(talk)06:11, 28 June 2013 (UTC)[reply]
Well, I admit that that bug discussion is quite messy (most of the comments don't have a lot to do with the actual bug title) but I gather that this issue is being worked on. I don't know exactly what interface will be developed for this, so I await a pleasant surprise. — This, that and the other (talk)06:16, 28 June 2013 (UTC)[reply]
This has previously been discussed, and WP:Edit notice does not work for most hidden notes because notes are specific to specific parts of the page. Plus "All users can create editnotices for their user and talk pages, but editnotices for other namespaces can be created and edited only by administrators and account creators." Do new and old WMF staff drink some special koolaid that makes them not pay much attention to what people write now and previously on a subject? And then to pooh-pooh much of the feedback here? --Timeshifter (talk) 03:35, 30 June 2013 (UTC)[reply]
I'm familiar with the process for creating edit notices, as I have asked to have them created several times.
We don't know when the ideal solution will be available. There is a possible solution that may work today. I am going to keep providing possible solutions that may work today, even if you think that offering information and alternatives to people is "pooh-poohing much of the feedback" and even if you think that noticing that the OP's question was his first-ever edit to this page, and that he therefore probably hadn't seen the previous discussions, constitutes "not paying attention". Whatamidoing (WMF) (talk) 07:05, 1 July 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Direct image caption editing
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)[reply]
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)[reply]
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)[reply]
I'm not pleased that this has not been automated. Edit summaries are more than just etiquette. They are profoundly useful when scanning your watchlist and it's something new editors usually do not provide. Looking at the VisualEditor, there does not even appear to be a place to provide a summary, let alone encouraging or requiring new editors to do this. When a new editor makes many changes to an article, having the summary lets you know what they did and that it was productive. Unless this is changed and is somehow automated (they can't save until they provide the summary), all you're doing is making more work for the regular editors, checking on the new editors' work, reverting vandalism and warning new editors to use a summary. freshacconci talktalk15:01, 28 June 2013 (UTC)[reply]
Hello freshacconci. There is an "edit summary" section. When you click "save", a box opens where someone can describe the changes they did or preview the changes before save it. TeamGale (talk) 15:14, 28 June 2013 (UTC)[reply]
OK, thanks. Still trying to get a handle on this. I'm one of those editors who thinks that you shouldn't be able to save your edits until you've provided a summary, but I don't think that's ever going to happen. I'm relieved to see that there remains an edit summary section as I've come across new editors using VisualEditor who are not providing them. freshacconci talktalk15:18, 28 June 2013 (UTC)[reply]
You are welcome. Not be able to save your edit until you write a summary might be a good idea. I, personally, forget many times to write one after I preview my edits and I know it's not the best thing... TeamGale (talk) 15:25, 28 June 2013 (UTC)[reply]
Interestingly, that discussion shows a proposal to remind editors about missing edit summaries, but the reason for rejection is a reason for rejecting forcing them to add an edit summary. I use the preferences setting to remind me when I'm about to save without an edit summary (seems to work fine for me both in Edit Source and in VE), but if I don't want to add an edit summary I can just click Save again. I wonder if it's time to revisit that discussion? I'd be delighted to see that preference set as a default for all editors, and it is far short of "forcing". PamD19:54, 30 June 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
When I hover over a section header link, it changes to "[ edit | edit source ]", except for the [edit] in the lead (i.e. Edit section 0). GoingBatty (talk) 22:27, 28 June 2013 (UTC)[reply]
Well, the link as it currently stands goes to what is now called the "source code", rather than VisEd; as the only people who've enabled that gadget are more likely to be power users, I think it's fine the way it is (note: I have zero statistics on that, only my intuition). I'll mention it on the MW talk, though. Ignatzmice•talk14:05, 29 June 2013 (UTC)[reply]
Simplify Sidebar?
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Hostility on Wikipedia
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
References get misnumbered [3], the two refs in the infobox are properly numbered 1 and 2, but the count restarts in the main text. Reproduced in Safari and Chrome. --j⚛e deckertalk15:05, 29 June 2013 (UTC)[reply]
Hi, Joe. Your link is to the edit screen, and I can't reproduce it in Chrome. :) (I added a couple of quick citation requests for the quotes that lack inline sourcing.) It doesn't look like you saved in whatever edit resulted in that issue - if you can replicate that, can you save it and link it? It might help determine how it's happening. --Maggie Dennis (WMF) (talk) 12:53, 30 June 2013 (UTC)[reply]
I should have been more clear, sorry about that. If you compare the first reference within the infobox with the reference at the end of the "Early Years" section, you will notice that they have the same number while being edited, but have different numbers when the article is viewed outside the editor (e.g., the "Read" tab.) I continue to see this behavior on Mac/Chrome. --j⚛e deckertalk16:13, 30 June 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Template parameters
Currently, when editing a template, the template parameters list is taken from TemplateData (if exists), or from the actual page being edited.
Whenever TemplateData exists, everything is hunky dory. However, when there is no TemplateData, the user does not know which parameters are recognized by the template, if they are not already present on the page.
There are two possible solutions:
The more effective solution is for the backend to generate TemplateData based on parsing the template page whenever "TempalteData" does not exist. Presumably, in this case, only parameter names (or numbers) are available, and all other parts of the metadata will have their default values.
in the Visual Editor itself, run something like the following code to extract the parameters list from the template page if no metadata is available (this is an illustration, and uses "async: false" so it works correctly. in reality, there are better ways to do it than using async:false):
we use this exact logic in hewki, with the "TempalteParamWizard": the wizard does not use metadata embedded in the tempalte page itself - we did not have the TemplateData extension available - but rather we have an optional subpage that contains the data in a form which is more human-friendly and less script-friendly, but is basically very similar to TempalteData.
When this optional subpage does not exist, we use code very similar to the above to extract the parameters recognized by the template from the template page itself.
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)[reply]
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
en.wikipedia.org/wiki/Banana_peel it is en.wikipedia.org/w/Banana%20peel, which results in a 404 error message.
i wonder if the /w/ will be usable instead of /wiki/ ?
I have experienced the Visual Editor always timing out whenever I tried to make even minor edits to some of the large, higher-traffic generating, most-watched articles such as Barack Obama, PlayStation 3 and World War II. Anybody else experiencing this issue, especially with pages with combined tons of content, templates, images and citations? If so, that is not very good... Zzyzx11 (talk) 20:20, 29 June 2013 (UTC)[reply]
The error message is: "Error saving data to server: timeout". This error message is generated by the Visual Editor itself, not the standard server-side MediaWiki error message mentioned in that bugzilla case. Zzyzx11 (talk) 03:39, 1 July 2013 (UTC)[reply]
"Show changes" needed in VE also
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)[reply]
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)[reply]
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)[reply]
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." [4] Remember that users can't tell a web app from a native client app ;-) - David Gerard (talk) 17:58, 30 June 2013 (UTC)[reply]
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 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)[reply]
<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>
I can't speak for sure for this other editor, but there's something weird going on at Atoka, Tennessee, one of the few articles this editor has edited recently, even before I get into visual editor, and most of the references that show in that article at "read" (around 9, but numbered very oddly) don't show in Visual Editor (only two do). Mac/Chrome. --j⚛e deckertalk07:34, 1 July 2013 (UTC)[reply]
Ahhh, there are several reference groups, that's why the numbering looks odd in the unedited article. Without having dissected the source code, there does appear to be a bug there, which should be visible by comparing the reference list in the article as viewed and the article as edited. --j⚛e deckertalk07:38, 1 July 2013 (UTC)[reply]
I need to know if I'm not supposed to be using the "group" attribute on references. I was trying it out just to see how it worked. Do I need to remove it from my references or is it ok to leave - Atoka, Tennessee? — Preceding unsigned comment added by SLBohrman (talk • contribs) 16:31, 1 July 2013 (UTC)[reply]
Still need to know or learn markup
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)[reply]
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)[reply]
(Ahh, it is, I should have gone and looked in bugzilla first.) Looks like a fix is on the way--developed, but not deployed on ENWIKI yet. --j⚛e deckertalk07:46, 1 July 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I like the visual editor, and I predict that more people will edit WP when it's introduced. However, there is one thing that bugs me: After I clicked the "Edit" Tab, the view of the article does change only slightly - so sometimes I do not know that I am already editing, especially when I scroll down the article. I'd suggest a visual hint: A modal popup, a slim outline of the editing area or a more distinctive design of the tool bar, for example. Mateng (talk) 12:00, 30 June 2013 (UTC)[reply]
Any bouquets that arrive for me I will forward to you, Maggie. I would even give your username to the enthusiastic fan who put 16 barnstars on my talk page yesterday, if he hadn't been indeffed as a sock. JohnCD (talk) 15:55, 30 June 2013 (UTC)[reply]
To add support to this proposal, I've been dealing with a new editor who was frustrated that they couldn't edit - didn't realise that clicking edit called up VE and thought that nothing was happening. NtheP (talk) 22:17, 1 July 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
So, the old citation button produced a box. Not ideal, but workable. Now, however, it produces a "what do you want to cite" one line field, and a "use existing"/"create new" button selection, which then takes you to the box to input the citation. I'm not sure what happened to just producing the box, but if anything, this is glitchy and half the time doesn't let me create a new reference (by clicking the button for create new), and if it doesn't, it closes and doesn't let me click any other VE buttons except close and save.
Also, if anything, shouldn't it be moving toward a "reftoolbar" type thing, instead of a "go learn how to make references look right and consistent on your own then come do it"? Instead of the textbox for "what do you want to cite", have a dropdown with common options (book, web, news, journal, etc.) and then an "other" or "not here" which would default to {{cite}}. The rest would default to the other templates, preferably with two options (standard and advanced/all parameters) as the current Reftoolbar.
This isn't super urgent I guess, as long as references are in the VE someway, I can ping the person who made the RefToolbar video about a new one :) Charmlet (talk) 18:39, 30 June 2013 (UTC)[reply]
"this is glitchy and half the time doesn't let me create a new reference (by clicking the button for create new), and if it doesn't, it closes and doesn't let me click any other VE buttons except close and save" from above. I click reference, type something in, select the "new" option, and it freezes up and closes, will still let me type, but won't let me click any buttons other than save/cancel.
Also, saying that you can't add in a feature that'll work on wikis with the templates is not going to go well with some of this project - if anything, you're making it much harder to create references. It'd be great if you could work a little more with the community - when they say they want something, don't shrug it off with "oh but that's enwp specific". Charmlet (talk) 20:43, 30 June 2013 (UTC)[reply]
How do you think this should be handled? Would you be happy getting a list of citation templates, only to be told that the one you picked doesn't exist on the project you're editing? If they put all the templates into VisualEditor itself, then you're going to see things that only exist at the Spanish or Hebrew or Arabic Wikipedias, and they're going to see options that only work at the English Wikipedia. That doesn't seem likely to please anyone. Whatamidoing (WMF) (talk) 08:34, 1 July 2013 (UTC)[reply]
It is quite simple, or at least has been done before, that it would be programmed to work on the Wikipedias that have them. Maybe look at the old RefToolbar for ideas, I'm not a coder, I don't know. But what I do know is this is going to lead to more unsourced edits, more unsourced BLP edits, more unsourced stuff in general.
On projects where the templates already exist, code in something (hell, hardcode the word "citation" or "cite" in each language if you must) to find {{cite web}}{{cite news}}{{cite}}{{cite journal}}{{cite book}}, (es:Plantilla:cita webes:Plantilla:cita libro etc.) and any ones more common in another language. That's a big part of the old edit window, is the easy ability to add citations, and I don't support rolling this out to anyone more than it needs be before a referencing tool is added in that doesn't make people still learn the templates.
This is supposed to be for new editors, who don't know WikiCode. They aren't going to have any idea that they're supposed to click template, then type in "cite web", then type in some random paramater names that, frankly, aren't super intuitive, and then save it. They're going to be overwhelmed with another text box, and not know how to cite. So they'll give up. Isn't the VisualEditor supposed to eliminate that kinda situation? Charmlet (talk) 13:40, 1 July 2013 (UTC)[reply]
I concur with the stated concern: if the purpose of the VE is to get more editors, then referencing has to be easy with it. Easier than the present system. Facilitate a minimal reference, e.g.<ref>http://url</ref> at the least (and I confess to doing reference links like that when I can't be arsed to do the entire tedious {{cite web}}) - David Gerard (talk) 16:23, 1 July 2013 (UTC)[reply]
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)[reply]
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)[reply]
Just had a go at adding a reference to James Gordon MacGregor (to replace an existing somewhat malformed "links" section). Ouch.
Clicked on the icon for "Edit reference"
It seemed to offer me "Create new source" or "Use existing source" but neither link was responsive
Then there was a blank window asking what I wanted to cite - no clues about format
Eventually stuck the URL into it, as I didn't see what else it wanted. Superscript "1" appeared.
Clicked on the icon for "Reference list": nothing useful offered (can't remember exact detail)
Used the "Transclusions" icon to add "Reflist"
No visible response to that.
Repeated previous step
still no response.
Went to "Save page", looked at "See your changes", observed that Reflist was added twice.
Despaired of being able to do anything useful in VE except offer this feedback, and will now save the page and reopen in Edit Source!
Nothing intuitive, no indication how to get anything like the helpful prompts from the dear old RefToolbar. Oh dear.
Ah, when I save it, the two copies of Reflist take effect and I have a duplicated single-entry list of refs. But, as with several previous comments, we need to be able to see in VE the effects of our VE edits, because lack of visual feedback causes confusion!
I guess I'm echoing what User:Charmlet said a couple of items above: it's a terrible step backwards to move from the RefToolbar approach into a blank "what do you want to cite" box. This is not going to help new editors to create full, well-formatted, references. If I'm editing an article and know I'm going to be adding references (much of my editing is wikignomish stuff which doesn't involve that), I'm going to have to remember to use Edit Source until VE can come up with something more helpful - and that's as an experienced editor. PamD20:47, 30 June 2013 (UTC)[reply]
I'll say that es:Wikipedia:Portada and other Wikipedias also use cite templates, so this would help out a lot more than enwp.. And if I remember right, those don't have the A/B test going on, so they may not even know that they're going to lose the RefToolbar. Charmlet (talk) 20:52, 30 June 2013 (UTC)[reply]
There's a feature request already tracked at Bugzilla 50458 (linked above) that might be a good place to discuss this - I note that already under request there is a list of parameters to be filled in, which I agree would be enormously helpful. I'm not finding this feature very intuitive myself. :/ I link here in case either of you would like to add your support or your own thoughts. --Maggie Dennis (WMF) (talk) 13:48, 1 July 2013 (UTC)[reply]
My Verdict
What is my verdict on the Visual Editor? MOST EXCELLENT! I always use the Visual Editor on Wikia, and have little idea how to use wikimarkups. Now making a table will be easy! --BNSF1995 (talk) 21:09, 30 June 2013 (UTC)[reply]
If I'm editing an article and want to add categories for birth and death dates, I need to be able to see those dates in the article while I'm adding the categories. The "Page settings" box totally obscures the article. I can probably remember one, but not both, of theose two dates. But I might want to add other categories too. Some categories involve unfamiliar placenames whose spelling is difficult to remember. The response seems to tell me that looking at the article while adding categories is undesirable multitasking. Can this bug please be bumped up the system: it's not a "low-importance enhancement" but a feature which makes doing a perfectly ordinary job very difficult.
When I'm stub-sorting I tend to add defaultsort and birth/death categories whenever I can, even if my main aim in opening the article was to remove {{stub}} and replace it by something more specific. I might add a maintenance category or two, as well as tidying up obvious typos, making a link or two, unlinking a date, etc etc. The response to this bug says "As far as adding a category or changing the default sort of a category directly from some other mode (such as reading, or editing paragraph text) we should look at those workflows rather than dissolve the intentional model-ness of the dialog." (I guess "modal-ness" is intended) - this makes my heart sink, as it seems to say that my sort of driveby wikignoming is not at all what editors are supposed to be doing, and we must categorise our activities into separate modalities and not expect it to be simple to make several quick improvements to an article in one short editing session. Deeply depressing. PamD21:32, 30 June 2013 (UTC)[reply]
Monthly number of edits will continue its downward slide since 2007
Timeline of anonymous edits on English Wikipedia.
The many problems with this visual editor may cause many anonymous IP editors to edit less. So the monthly number of article edits by anonymous editors may continue its downward slide since 2007. See:
WMF board and staff are hoping that the VE editor will be easier to use by IP editors. But if those editors are being constantly reverted there may be a net loss in the monthly number of edits as many edit less. Post-and-run editors may edit more. IP editors who prefer wikitext source editing may edit less if they are as frustrated by the lack of a direct link to "edit source" as I am. See section higher up: #Edit and edit source links so confusing I had to disable Visual Editor in preferences. Registered editors can turn off VE. IP editors can not.
It is about net losses and gains. Some have asked whether the VE developers should try to please everybody. Well, they should try to please as many people as possible in order to slow down the decline in monthly edits, or to reverse it. If the loss is inevitable, then we need to make editing more efficient, so that there are less reversions, and less mistakes. So people get more done with less edits. --Timeshifter (talk) 21:52, 30 June 2013 (UTC)[reply]
@User:Timeshifter, I'm not sure if I understand this line of reasoning. Currently a small fraction of people edit Wikipedia, as IPs or otherwise. Those people are self-selected in that they're the ones who brave the Wiki-code. Wouldn't making it easier to edit result in more people editing, since we wouldn't be weeding out would-be editors who are afraid of computer code? Is there an underlying assumption that a higher proportion of edits will be reverted? (I'm a bit confused by the 2nd sentence in the 2nd paragraph.) ~Adjwilley (talk)22:04, 30 June 2013 (UTC)[reply]
That is the theory. But that only works if VE actually makes editing easier for IP editors. If there are many reversions, then there may be a net loss in the number of IP edits over time, or only a small gain, or a gain smaller than it could be. Until recently IP editors could edit sections without having to check a preview for a whole page for errors introduced by VE. With VE they now have to check a preview for a whole page for every single edit they do. So the net effect of VE may be to make editing more time-consuming, but "easier". See what I mean about net losses and gains? How will it add up? Looking at Wikia's experience with its VE I foresee many problems with Wikipedia's VE. --Timeshifter (talk) 22:31, 30 June 2013 (UTC)[reply]
Until recently IP editors could edit sections without having to check a preview for a whole page for errors introduced by VE.
Last I heard, unregistered editors couldn't use VisualEditor at all, and thus are untroubled by the section edit links that bother you so much. I suggest that you log out and try it before worrying about the IPs' experience. The latest timeline that I've seen says the VE might become an option for them as early as next week. A couple of people over at Meta have encouraged the devs to postpone the switch for IPs until the core community has had a month to get used to it, and there are other reasons why it might be postponed (e.g., if the increased load might slow down the Parsoid system too much). Whatamidoing (WMF) (talk) 10:25, 1 July 2013 (UTC)[reply]
I mixed up who the A/B test was implemented for. I knew it at one point and forgot. :) It is good that VE has not been implemented for anonymous IP editors. I think it would be a catastrophe if implemented now for IPs. I keep thinking of more reasons why.
In the last few days I have been thinking of the last reason you mentioned. Since every single edit by VE edits the whole page that could add a crushing burden to the servers if implemented for IPs. IPs will not be able to opt out, and will click the "edit" link most of the time since they will not notice the hidden "edit source" link at first. I believe in its current state many registered editors will opt out of VE when VE is made the default, or they will not use it much. They will click the "edit source" link much of the time. They will be more likely to notice it since many people will be talking about VE on talk pages. So registered users may not be as much of a burden on servers if VE is implemented by default for them. So it would be dumb to make VE the default for anonymous users first. First see how much of a burden registered users put on the servers when VE is made the default. --Timeshifter (talk) 16:29, 1 July 2013 (UTC)[reply]
Addition of <u></u><u></u> and removal of categories.
Here's the diff. All I tried to do was move a quotation mark, and it added a bunch of underline markup in the References section and removed all the categories. ~Adjwilley (talk)21:54, 30 June 2013 (UTC)[reply]
I tried to reproduce this in the sandbox, but it looks like VE is only for article space. Do you know of a sandbox-type place where I can play with VE that's not going to cause problems in the main space? ~Adjwilley (talk)23:59, 30 June 2013 (UTC)[reply]
Okeyes I think that is a great suggestion if your still watching this thread. It should be fairly easy to extend the Article/Userpage functionality to subpages like /sandbox. Kumioko (talk) 00:20, 1 July 2013 (UTC)[reply]
OK, I did three test edits in my sandbox. The first was an exact reproduction of what happened in the article. In the second I wanted to see if it was my edit summary and/or use of the "minor" checkbox that did it, so I didn't check "minor" and I left a blank summary. It did the underlines and removed the categories, plus a whole bunch of other changes that I hadn't seen before. In the third edit, I wanted to see if it was my moving the quotation mark that did it. Instead of moving a quotation mark, I just added a "test" sentence to the Lead. I left an edit summary, but didn't tick the "minor" box. I got pretty much the same result as in the first edit.
Summary: Apparently no matter what edit I do to that particular article, it blanks the categories and adds the underline tags. If I don't leave an edit summary, it does even more. ~Adjwilley (talk)02:02, 1 July 2013 (UTC)[reply]
Okay, I tried to follow your footsteps and remove a quotation mark from the article (not the sandbox), and I notice that there is a bold note at the bottom of the save screen that says, "Warning: Your edit may have been corrupted – please review before saving." On review, I see the same issues you did. Do you see that note as well? --Maggie Dennis (WMF) (talk) 13:33, 1 July 2013 (UTC)[reply]
Yup, I get that (I hadn't noticed it before...the save screen text is pretty small for me.) It actually doesn't matter what edit you make, by the way, you still get the "corrupted" changes. I did it just now by adding a single space. ~Adjwilley (talk)16:11, 1 July 2013 (UTC)[reply]
Automatic fixes
On a related note, I just ran across this. The user was just trying to add a new section, but Visual Editor made some other repairs to the page, both good as I can tell. (It got rid of a stray </blockquote> and merged two a duplicated named reference.) Like I said, the changes were good, but above in the FAQ it says VE's not supposed to be making changes like that. (I'm fairly certain the user didn't do that himself, since he's very new, and would have had to do a lot of searching to find those errors.) ~Adjwilley (talk)03:20, 1 July 2013 (UTC)[reply]
I've added this to my list to ask about - if it turns out that it is meant to make changes such as this, we'll have to correct the documentation. :) --Maggie Dennis (WMF) (talk) 13:25, 1 July 2013 (UTC)[reply]
The "This is a minor edit" label is truncated for me: I see ∆ This is a ∆ Watch this page. Happens on Safari 6.0.5, Chrome 27.0.1453.116 on Mac OS 10.8.4. I assume it's because of something in my CSS (most likely the fixed-navbar thingie), because it doesn't happen in my sock account.
Another thing: Also in the last dialog box before actually saving, there is what I assume is supposed to be an "X" in the top right corner. Clicking on it closes the dialog box. However, I do not see an X—it looks like an upside-down check mark (it isn't symmetrical). It seems all of the top half and half of the left half (of a regular [square] X) are somehow truncated. Ignatzmice•talk22:14, 30 June 2013 (UTC)[reply]
When I try the following steps using Firefox 22, I get an incorrect warning:
For any article page on your watchlist, click the "hist" link to go to the Revision history page.
Click any "cur" link to go to the Differenve between revisions page. Note that there is a "Previous edit" link, but no "Next edit" link.
Click any "Edit source" link or the "Edit" link at the top of the page, and you can make your changes just fine. However, if you click a section's "[edit]" link, you see a big red warning stating: "You are editing an old revision of this page. If you save it, any changes made since then will be removed.".
Will this break the ways that minority language Wikipedias (Cherokee, Navajo, etc) have rigged their special input methods? Is there a way to refuse the upgrade if so? Cheers, Nesnad (talk) 05:50, 1 July 2013 (UTC)[reply]
I believe that it's been turned off on the Chinese Wikipedia because of language-specific problems. If there is actually a problem at any of these languages, then there shouldn't be any difficulty in doing the same for them.
On the other hand, if it works for minority languages, then I believe you'll want to keep it. It's already hard enough to find people who can write in a minority language, without eliminating anyone who doesn't have time to learn wikicode. Whatamidoing (WMF) (talk) 08:13, 1 July 2013 (UTC)[reply]
I'd have expected this to be a known issue, but I failed to find such feedback: I see no way to add references to template parameters. See for example User:Huon/Test: The references within the template parameters are displayed as wikicode within the Visual Editor, the named reference <ref name="mojo"> that's used within the infobox is not available for re-use outside the infobox, and while all references are correctly listed in the "references" section, Visual Editor numbers the first reference after the infobox [1]; apparently it doesn't realize at all that the references within the infobox exist. If I add a <references /> instead of (or in addition to) the {{Reflist}}, that one won't display the footnotes within the infobox at all.
On a related note, I don't see how I could add templates within templates either - except by manually inserting the wikicode. Huon (talk) 08:06, 1 July 2013 (UTC)[reply]
The tracking number I've added refers to the reference count. When I look at your diff, though, the reference numbering seems correct to me - the two in the infobox are 1 & 2, the one in the body is 3. Does it look different to you? --Maggie Dennis (WMF) (talk) 12:33, 1 July 2013 (UTC)[reply]
I've seen something similer in that while editing the main body, the reference numbering starts from 1 regardless of the fact that there are references in the infobox. When the edit is saved everything then appears as expected so it's a quirk of the edit process that's ignoring refs not within the main text. Haven't tried the named reference yet to see if I experience the same. NtheP (talk) 14:36, 1 July 2013 (UTC)[reply]
Indeed the result is what I'd expect, it's just the VisualEditor itself that doesn't realize that references within templates exist (or indeed any formatting; links or italics would also have to be added manually to template parameters). VisualEditor doesn't allow me to add them, it doesn't allow me to refer to named refs that exist already outside the main body, and it doesn't count them correctly. The last effect is an entirely cosmetic bug (VisualEditor is not WYSIWYG here) that's just a symptom of the underlying problem.
In a similar vein I can't add a reference or a template to an image caption, though templates and images can be added to references. Huon (talk) 15:59, 1 July 2013 (UTC)[reply]
On second thought this seems to be a generalization of bug 50182 - I don't just want to nest templates within templates, I want to nest references in templates (though not in templates within references!), and references and templates within image captions. All that is unsupported at the moment. Huon (talk) 16:26, 1 July 2013 (UTC)[reply]
Spaces and nowiki tags are being added to a table on my users page when I'm editing elsewhere on the page using VisualEditor. SLBohrman (talk) 14:28, 1 July 2013 (UTC)[reply]
It seems to have gone wonky in this edit. It looks like the </ br> markup, etc. might have confused something in there. I'm wondering if the issue you encountered in the welcome message has to do with the known problem with colored text in signatures (unless that was fixed while I was out of town). I'll poke about. :) --Maggie Dennis (WMF) (talk) 16:04, 1 July 2013 (UTC)[reply]
In this edit I wanted to remove one of the two templates which were nested in {{multiple issues}}: the only way I could see was to delete {{mi}} and then re-add the one template I still wanted. Messy. What if there had been 5 templates within {{mi}} and I'd wanted to delete one or two: can it be done in VE? PamD15:14, 1 July 2013 (UTC)[reply]
When editing "MI", I see a "1" beneath it. Clicking on the "1" brings up the subtemplates, which I can remove individually. Unless that isn't working for you, it seems less a lack of feature than a lack of clarity. If you can let me know which, I'll see what we can do with it. --Maggie Dennis (WMF) (talk) 15:45, 1 July 2013 (UTC)[reply]
Right, thanks Maggie, I can now remove one or more of the templates from within {{mi}}. But if I've removed all but one, so want to drop the {{mi}} but keep one of the inner templates, can I do that? It might be one with a long text parameter (perhaps {{cleanup|reason= some verbose description of everything that's wrong with the article ...}}, tedious to retype. See this example edit. (Only a low-priority issue, as copy-and-paste or retyping would work) PamD21:15, 1 July 2013 (UTC)[reply]
Templates have evolved since this morning, I'm happy to see. You can now see the name of the subtemplate. But, alas, I don't see any way to remove the top template without removing the subs. This would be a nice feature to have, I agree - I'll put it in, but it probably will be low-priority, as you say. :) --Maggie Dennis (WMF) (talk) 21:45, 1 July 2013 (UTC)[reply]
VE picking up old version of file? - 27 ghost references!
If I open Queen Anne Grammar School in VE, I can see two superscripts linking to references - and 29 references in the reflist. Some of them perhaps most, are the refs which were deleted in a series of edits 9 hours ago while the article was being moved from AFC to mainspace. If I open it in Edit Source, it's a respectable little stub with two refs and no sign of the other stuff.
Extremely confusing. I've got a word doc with a couple of screenshots pasted into it, could attach to an email if told where to send it.
Meanwhile will edit the article in VE and see what happens.
... Have italicised motto, stub-sorted, saved page, all in VE. When I open it again in VE it still shows 29 references.
... Closed it, edited it in Edit Source, saved it, no sign of refs 3-29. Re-opened it in VE, they are still showing up. PamD20:54, 1 July 2013 (UTC)[reply]
Hi Epicgenius, can you tell us more about your browser, WP skin and OS? Which article were you working on? Have you experienced other issues that you feel might be related? Thanks, --Elitre (WMF) (talk) 21:17, 1 July 2013 (UTC)[reply]
I tried saving an edit to U.S. Route 377 in Texas (diff), it took a while and then finally I got an error. Sorry I didn't copy it but it was something close to "Error: Invalid error type." However, when I check the history it did accept the edit in spite of the error. FWIW, -- Gyrofrog (talk)21:50, 1 July 2013 (UTC)[reply]
Hi Gyrofrog, did it edit exactly like you wanted to, no extra things or something? I'll try and see if it happens to me as well. --Elitre (WMF) (talk) 21:52, 1 July 2013 (UTC)[reply]
Specifically, look at the album for "Oh Africa", which certainly wasn't "Rowspan=3;style=background ...", or the album for "Lock Down", which wasn't style="background: #ececec....—Kww(talk) 22:28, 1 July 2013 (UTC)[reply]
Yes, that is what it looks like. I can see the HTML as well in edit mode. PEarly, I filed a new bug, feel free to merge it (or have it merged) if this is already in Bugzilla. Keegan (WMF) (talk) 22:35, 1 July 2013 (UTC)[reply]
Hey y'all...I have to say, in the past few weeks the VisualEditor has improved quite a bit, and I'm proud to say that, what the heck, Oliver, for the first time ever you didn't botch up a release. I'm just kidding of course -- kudos to the entire team. Keep it up! Theopolisme(talk)22:20, 1 July 2013 (UTC)[reply]
Error message: 'Error: Invalid token'
I just tried to test VisualEditor by removing some text from my userpage, and got the message 'Error: Invalid token'. What does this mean? Robofish (talk) 22:20, 1 July 2013 (UTC)[reply]
It seems to have been a problem with the edit summary, I changed that and it worked. Are hyphens no longer allowed in edit summaries or something? Robofish (talk) 22:22, 1 July 2013 (UTC)[reply]
Inline comments
First off, I want to say that the new visual editor is remarkable improvement over the version I tested out several months ago. This is an editor which I could actually use to manage articles! That said, one feature it currently lacks is viewing or editing inline comments to a page. These are useful in many different fashions. Could it be possible for Visual editor to display and/or allow editing of inline comments? Sailsbystars (talk) 22:21, 1 July 2013 (UTC)[reply]
I've been trying VisualEditor recently, and so far, I've been pretty pleased with it. I do have two nitpicks, however:
1) The text size for edit summaries and reviewing changes is a bit too small for me. I sometimes find that I have a bit of difficulty reading what I write in the text box and seeing the changes I made without zooming in. I think the text size could be made a bit bigger.
2) When I edit a particular section of an article, it would be nice if the text summary noted which section I edit like editing the source would. Currently, VisualEditor doesn't do that.
Thank you for your feedback, Lugia2453. Good point about the edit summary sizes and section edits being noted. We should certainly look into that. Keegan (WMF) (talk) 22:44, 1 July 2013 (UTC)[reply]
References
(at native size of 23px).
(at native size of 23px).
(at native size of 22px).
wikimedia.org :). Okeyes (WMF) (talk) 13:54, 30 June 2013 (UTC)
