This is an archive of past discussions about Wikipedia:VisualEditor. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current main page.
Office hour in March
Hi all, the office hour for this month is scheduled for Monday, March 17th, at 15:00 UTC. Please join as Product Manager James Forrester discusses VisualEditor, new features and upcoming plans. For more information on office hours, including how to attend, you can see meta:IRC office hours. If office hours are heavily attended, it can be difficult to get to all questions, but if you want to ask a question and cannot attend or do not speak English, please let us know your question here or via email by the day before, and I or another community liaison will add it to possible discussion topics, as usual. (Complete logs are always posted and categorized at meta:Category:VisualEditor office hours logs after each office hour completes anyway, for your convenience).
I really like the editor, as the interface is very easy to use and intuitive.
I especially like the image adding feature, as well as the link feature.
However, I would like to see some insertable templates added to the editor. For example, a drop down menu with the a few template options. Minimuffin128 17:07, 1 March 2014 (UTC) — Preceding unsigned comment added by Minimuffin128 (talk • contribs)
I just tried to add a wiki link on the table and this happened...I have no idea what and why..? My edit is at the end of the changes. TeamGale20:22, 5 March 2014 (UTC)
Seems reproducible (Chrome, W7), I tried to add a wiki link near what you did, and the same happens in the diff. And it's not visible unless you look at the wikitext diff. --NicoV(Talk on frwiki)20:32, 5 March 2014 (UTC)
That doesn't look nice. Should we place bets on not exactly perfect wikicode vs a VE or Parsoid bug? I'll check ASAP anyway, if nobody beats me to it. Thanks, --Elitre (WMF) (talk) 12:49, 6 March 2014 (UTC)
Well, for me: VE/Parsoid bug (seriously damaging the article without a clear indication for the user is obviously a bug...) triggered by an unperfect syntax. --NicoV(Talk on frwiki)13:30, 6 March 2014 (UTC)
Elitre (WMF) I agree with NicoV on that. When a "bad" syntax doesn't break the table while editing on wikitext it shouldn't break it while editing with VE either. It's not possible every user who edits to know that the result is because of bad syntax. Especially since VE is supposed to be more useful to new editors and help them edit an article easier, you don't expect the new editor to know how to fix that "bad" syntax, right? All the editor will see is a damaged table just like I did. Just my opinion. TeamGale13:44, 6 March 2014 (UTC)
Maybe there should be some sort of Edit Notice or similar when Parsoid detects broken html. That would at least alert users to potential problems. Something along the lines of "A problem has been detected to with the HTML/wikitext of this page. This may mean VE behaviour might be erratic. Consider using the wikitext editor to fix the problem".
p.s. I've recently been part of a drive to fix 7000 broken <sup> and <sub> tags. These render incorrectly in VE as parsoid corrects the html in a different manner to the normal renderer.--Salix alba (talk): 14:46, 6 March 2014 (UTC)
Undesired link changes and split links still happening
Bug report
VisualEditor
Mito.money
Please app{}
Intention:
Changing [[People's Republic of China]] to [[China]]
Steps to Reproduce:
Deleted "People's Republic of" from [[People's Republic of China]], I didn't use the link inspector.
Results:
VE produced two links: [[China|C]][[People's Republic of China|hina]]
Expectations:
[[China]]
Page where the issue occurs
diff (look at the third change above the Line 757 header)
Web browser
Firefox 27.0.1
Operating system
Linux
Skin
Monobook
Notes:
There are two bugs here. One is the well known problem of changing link targets independently of displayed text (see comment 1 at T52945 where I was attempting change 3 but got change 2). The one I'm mainly reporting here is the producing two adjacent links, which might be T52678 but I'm not convinced. I know it has been seen before, but I thought it had been resolved since last summer. I made this same change several times in this edit, T52945 happened every time but this only once. I don't recall what if anything I did differently as I didn't spot it until I got a dablink notification.
I think I fixed a typo in the Results field, I couldn't find an instance with a missing h. I'm not sure if this should be reported if not reproduceable (or if we don't know how to reproduce it), but I could do some testing and/or add your report to Bugzilla if you want me to. Great to see you here from time to time :) Elitre (WMF) (talk) 11:31, 4 March 2014 (UTC)
Yeah, the missing 'h' was a typo. It's definitely reproducible as I remember it from last summer, but what I don't remember is how to reproduce it or what the bug was. Thryduulf (talk) 17:49, 7 March 2014 (UTC)
So, if this only appears after yesterday's VE update, it might be easier to understand what's going on and fix it soon. I'll contact someone on IRC today. Thanks, --Elitre (WMF) (talk) 11:35, 7 March 2014 (UTC)
Thank you very much guys. I use VE, limited as it is, in specific circumstances. But I didn't catch yesterday's problem until later, almost by accident, when I went to check again the diff of my edit. The VE automatic edit-summary, for the edit in question, was also weird. I had seen VE act up before, but this incident was the first time I became really concerned about using VE in the future. Δρ.Κ.λόγοςπράξις16:01, 7 March 2014 (UTC)
I'm pretty sure we'll learn more about this issue soon. There's no need to worry further, though :) When I asked James about the warning message, he explained: "This is caused when VE has noticed that the HTML it will send back to MediaWiki is different from the HTML that it received – that something in VE has corrupted the document. In most cases nowadays this is fixed by Parsoid so it doesn’t result in broken or unexpected wikitext". But when it does, like in this case, letting us know - like you did - is certainly important, so, thank you! --Elitre (WMF) (talk) 16:27, 7 March 2014 (UTC)
Quick update: The patch for this is already written and will be deployed as soon as possible. It's Friday, and there are no scheduled deployment windows on Fridays, so I'm not sure what time is most likely. Whatamidoing (WMF) (talk) 19:18, 7 March 2014 (UTC)
Hey, is there any way to use the InputBox extension with the VisualEditor? Various projects use this feature to allow simple creation of new articles, however new users have found the old editing way too clumsy to dare creating a new article. Is there any way to create a form where you could enter the article's title, click on ”Create”, so that it brings you to a page using the VisualEditor instead of the old editor? --Danutz (talk) 13:47, 9 March 2014 (UTC)
Unfortunately, the answer, in practice, is "no". There's some necessary background work (at T51622) that would have to be done first, and even then it might be a lot of difficult work to make it happen in VisualEditor after that. I think you can count on this not being possible during 2014 (at least). Whatamidoing (WMF) (talk) 16:40, 11 March 2014 (UTC)
Whatamidoing (WMF), thank you for your answer. Glad to know that guys at Bugzilla are taking this into consideration. However, I wonder if provisionally there could be a way to create a form that could lead the user to the creation of a new article with the VisualEditor, without necessarily using the features preload/editintro (without using the Inputbox extension). That is basic html for a common website but I see that wikimarkup does not accept the html <form> tag. --Danutz (talk) 16:56, 11 March 2014 (UTC)
Definition lists are widely misused in Wikipedia articles. We may be able to reduce the incidence of this bug by eliminating them and discouraging their use through the manual of style in situations where they are not strictly adhering to the strict semantics of when definition lists are intended to be used in the HTML specification.
I was editing a section in VE (this was on the Board wiki; else I would post the revision).
I left the editing window open, off and on, for an hour. I had also pasted in text that included explicit carriage-returns.
A stray keystroke wiped the section.
When I tried to undo this, I got a few undo-steps worth of gibberish, and then no further change. I'm not eager to try to reproduce, but will of course report it if I am able to. :-) – SJ +06:38, 8 March 2014 (UTC)
Hi SJ, can you tell me what kind of page you had pasted from (e.g., an email message, a Word doc, a wiki page)? That might help narrow down the options for testing. Whatamidoing (WMF) (talk) 20:46, 9 March 2014 (UTC)
It was a paste from an etherpad, and another from a thread of google doc comments (multiple comments threaded to a single parent comment). The textarea wipe may have been a command-shortcut. It reminded me of a similar experience in the old editing toolbar: once you click on the editing toolbar, undo no longer works as expected. (It never removes the insert caused by the toolbar; sometimes you can still undo previous edits while retaining the toolbar-insertion; but sometimes - for instance if you type after the toolbar-insertion - you can no longer undo anything before it.) – SJ +22:02, 9 March 2014 (UTC)
Thanks, SJ. I'll see if I can reproduce it. (Anyone who figures out how to reproduce it reliably, please post!)
Also, what's your browser/OS/Wikipedia skin? This may turn out to be one of those things that behaves differently depending on the details. Whatamidoing (WMF) (talk) 18:32, 10 March 2014 (UTC)
Just my 2c here, leaving an edit tab open for 1 hour is probably not optimal, not even for the source editor. I think you'll get some kind of warning about data being lost, and please try to log in again, something like that :) This said, it might be important to know details about the content (its length, if it was plain text or if it included templates/tables/...). Looking at the diff would probably help :/ --Elitre (WMF) (talk) 11:47, 11 March 2014 (UTC)
It was 6 paragraphs of text, no tables or templates or unusual formatting. The only slightly non-standard character was a line-starting carriage return (which apparently are in the copy buffer when you capture more than one successive comment in a G!Doc comment thread) -- which showed up as an explicit ↵ . – SJ +23:25, 12 March 2014 (UTC)
Using VE on Meta
I'd like to use VE while editing on Meta. Is this possible? I don't see it as an option. – SJ +06:33, 8 March 2014 (UTC)
No, it's not available there. It has generally been made available to any non-Wikipedia community that asks for it (either opt-in or opt-out, whichever is preferred). You could start a discussion to support such a request if you wanted. Whatamidoing (WMF) (talk) 20:39, 9 March 2014 (UTC)
One of the reasons I think VE is still not available there is that Meta might feature discussions even outside talk pages. See for example the "village pump" there, or Forum, which is in the main namespace: there's a lot of traffic there and VE wouldn't work well because it doesn't support signatures, and it can't currently be disabled on a single-page basis. HTH. --Elitre (WMF) (talk) 13:28, 10 March 2014 (UTC)
Ah, you're right, Elitre. It should still be fine to allow this as an opt-in. I really hope that a signature option is added to the VE interface soon. (Is the obstacle to implementing this technical or philosophical?) That's made it tricky to use on some other pages as well. – SJ +03:05, 13 March 2014 (UTC)
Okay. Based on a brief discussion, there is some support on Meta, and no active opposition. JamesF proposed waiting until a related issue with the Translate-extension is fixed, which seems poised to happen. – SJ +03:05, 13 March 2014 (UTC)
When I try to edit a section, what you appear to do is make entire page editable. This takes TIME, and is confusing, as the entire page becomes an edit area. Please don't do that. Please provide an edit area for one section only. Gryllida (talk) 21:40, 10 March 2014 (UTC)
@Gryllida: Not a developer, but I believe this is a bug and isn't intended behavior. Its been brought up before, but I'm not sure how much of a priority it is. --Nicereddy (talk) 05:16, 11 March 2014 (UTC)
The assumption behind these requests is that editing a single section will be faster. It won't. To do proper section editing, VisualEditor would need to open and process the entire page (e.g., to find and process references that are being re-used in the one section that you want to change), and then throw away most of the information. This is actually slower than simply opening and processing the entire page and not figuring out which parts can be thrown away. So section editing won't be faster; instead, it will be slightly slower.
IMO even slower section editing would be a desirable option, because sometimes we open sections specifically to provide ourselves with some focus: I'm going to work on this section, and I don't want to be distracted by the stuff around it. But once people understand that true section editing would be even slower, their interest in it seems much reduced. Whatamidoing (WMF) (talk) 16:54, 11 March 2014 (UTC)
When you say that it will be slower, you completely disregard one important factor: what has to be sent back when saving your changes. When you have a slow internet connection, you often end up with a very slow upward bandwidth, and sending an entire article can become very difficult or even impossible, whereas sending back a single section is a lot easier. --NicoV(Talk on frwiki)17:28, 11 March 2014 (UTC)
I would like to propose a different way to imagine section editing. Think of it as "editing only what is between the section header and the following section header." No touching the rest of the page, no editing anything that falls outside of it.
Why is this useful behavior?
It reduces the amount you are focusing on, on-screen.
It can indeed greatly speed up rendering, if you only render what is within that section. Some elements will be ambiguous: the trick would be finding a sane way to represent that ambiguity.
It can speed up saving, by sending a smaller chunk of text upstream. (that may not be as significant, however)
It may or may not limit edit conflicts. (see below)
Casual editors may not see the option to edit by section. So those who see it will have chosen to see it, and will understand the quirks and consequences. But the gains in both speed and reliability of edits would make it very worthwhile to me. – SJ +23:51, 12 March 2014 (UTC)
It is about a year since we first discussed the lack of section editing in V/E. As far as I'm concerned it is one of the biggest drawbacks of V/E. Not as big a problem as V/E not working on Internet explorer and running at glacier speed on older kit, but still on its own a good reason to keep it well away from newbies (apologies if any of the major problems have been fixed in the last year, but if any of the bugs I reported a year or so back have been fixed no-one has told me). ϢereSpielChequers00:15, 13 March 2014 (UTC)
SJ, your benefit #1 is wrong: Section editing has not affected edit conflicts for years now (since about 2006 or so, from what the devs tell me). I completely agree with your point about focus. However, there are drawbacks to this "fake section editing" idea. The most important one (IMO; perhaps others disagree) is that you wouldn't be able to re-use references. In the wikitext editor, if the ref is defined elsewhere, you just type in the ref name as usual. In VisualEditor, if the ref is defined in a section that isn't processed, then it might as well be defined on another wiki entirely. You won't be able to re-use it, because VisualEditor will not know that it exists (and if you process the whole page so that VisualEditor knows that it exists, then you lose all of the speed benefits you were hoping to get). Would that be a desirable tradeoff? Or do you think this would be an unpleasant surprise to users?
WSC, I know that Timo was working on Internet Explorer's problems last week. He reported that he solved one known problem and discovered a new blocker. As this process of fixing and discovering new breakage has happened repeatedly, they've given up estimating even what quarter IE's problems might be resolved in. However, I've never understood why the problems with modern versions of IE (which affect 10% of editors) is supposed to be a good reason for keeping it away from people who are using Chrome, Firefox, or Safari. The logic behind "It works fine on your computer, but you aren't allowed to use this, because it doesn't work on somebody else's computer" has always escaped me. To me, it seems more sensible to say, "If it works for you and your computer, then you make your own individual choice" than to say "The choices made by just 10% of other editors (or, more often, by their school or work IT departments) determine what you personally are permitted to do on your own computer." Whatamidoing (WMF) (talk) 18:20, 13 March 2014 (UTC)
Have you tried running a training session where some people are using V/E and some the classic editor? It is complicated enough that in one training session you might have everyone on a different combination of browser, keyboard and O/S. Of course outreach training only involves a minority of editors and generally I would agree that you could leave some browsers out providing it is properly communicated. An informed choice would of course be OK, but that wasn't what I encountered last year. The problem comes when you don't get a warning that V/E won't work on your machine, or worse will slow you down to the point where you start thinking something is wrong with your kit or connection. As for that 10% figure, is that worldwide or current US users? ϢereSpielChequers18:43, 13 March 2014 (UTC)
I will say that I am getting tired of the IE story. Normally, one establishes a baseline set of features, gets them working in all browsers; adds the next set of features, gets them working in all browsers; repeat ad infinitum. That way, you always have a code base that works in all supported browsers and your engineers, being engineers, tend to keep an eye on things and keep divergence between versions under control. Trying to go into an existing codebase and rework it to add a new browser while other people are simultaneously changing code to add new features is a recipe for disaster. If that's the approach that is being used, it's a good bet that VE and IE will remain forever incompatible.—Kww(talk) 14:05, 14 March 2014 (UTC)
Your idea of "normal" does not appear to have been normal for several years now. It seems to now be a bit more like you have WebKit specialists and IE specialists and Mozilla specialists, and if the IE guys (and it's almost always IE that takes far longer) are running behind, then the other teams don't just sit around waiting for the IE group to get their work done. All the other teams move on with their work regardless of where the others are. The fact that IE can't save a page doesn't block the development of editing tools. Whatamidoing (WMF) (talk) 23:03, 14 March 2014 (UTC)
Anyone that structures a project around different teams to support different browsers is structuring themselves to fail. They may occasionally succeed, but that's probably more an accident than anything else.—Kww(talk) 20:03, 15 March 2014 (UTC)
While your analysis is probably right, it is IMO not complete. Basic incompetence probably comes into play as well. Bug 50379, quite a major VE bug, was open from June 2013 on. Nothing much was done on it, for a variety of reasons (e.g. User:Jdforrester (WMF) either not knowing that this bug existed, or not considering it to be important to have VE support the recommended default image size syntax), until I raised it again. At that moment, the defense by User:Whatamidoing (WMF) was "As I understand it, the addition of fixed sizes on all new images is due to a challenge in Parsoid, not VisualEditor itself, and it is actually harder to fix (without breaking other things) than one might expect. It is a truism in software development that things users believe "should" be easy are not always so easy. And they obviously aren't ignoring this, since they've assigned someone to fix it at bug 50379. Whatamidoing (WMF) (talk) 19:09, 18 February 2014 (UTC)" This "harder to fix" "challenge" was suddenly solved five days after I pointed out that VE already supported this, that this was not a Parsoid problem, and that by using a backdoor in VE, you could already do this. A major bug, open for 8 months, suddenly solved because it turned out that their arguments were completely invalid. One wonders if similar ongoing incompetence at all levels isn't also to blame for the IE problems, more than purely technical problems or a very bad choice at the start of the project. Fram (talk) 14:31, 14 March 2014 (UTC)
To be candid, I'm nervous about that hack, and it's already broken for me once since then. It's still Parsoid's job to do it, and to do it right, and Parsoid still hasn't done it (last I checked, which was last week). So that's "resolved-fixed" on Bugzilla but also "expect-regressions" on my list. Whatamidoing (WMF) (talk) 23:03, 14 March 2014 (UTC)
Thanks WAID. I think most editors would be okay with not getting that reference feature unless they choose to edit the entire page. As to edit conflicts: I thought this triggered based on whether two people's changes are automatically mergeable or not? Section-limited editing doesn't prevent that from happening, but makes it less likely than edits each of which may scatter small updates across the page. – SJ +07:53, 14 March 2014 (UTC)
If you make a change in one section, and I make a change in a different section, then it doesn't matter whether either of us clicked "edit source" for the whole page or just for the one section. It's true that a person who is editing one section is less likely to "scatter small updates across the page" (I love that description), but it's the nature of the edits, not the presence or absence of section editing, that actually matters. Whatamidoing (WMF) (talk) 23:03, 14 March 2014 (UTC)
The only reason why potentially section editing might avoid edit conflicts, is simply because the HTTP requests take a shorter time, thus creating a shorter timeframe in which you can overlap with another user. It's this overlap of the timeframes between request of user and commit of edit into the database, which causes the conflict, short frames, means less likely to overlap if you have an equal amount of user activity. Once a conflict occurs, it can be resolved automatically or returned to the user. On that last part section editing makes no difference. —TheDJ (talk • contribs) 11:54, 15 March 2014 (UTC)
I suspect that part of the reason why section editing is an effective way to reduce edit conflicts is that by separating your edits into different ones by section, those of us who tend to edit busy pages by section do edits where the system can usually handle the edit conflicts without rejecting our edits. With the classic editor and editing sections I still get some edit conflicts, but of course only when someone else is editing the same section. Speed is of course one of the considerations here. Newbies are unlikely to have learned the importance of saving little and often when using this site, the risk they have of edit conflicts if they change more than one section in one edit, and of course the downside if they use V/E that because it slows down editing it increases their chance of being on the losing side of an edit conflict. As for the myth that section editing is unrelated to edit conflicts, has anyone here ever experienced an edit conflict where they were editing one section and someone else was editing a different section? ϢereSpielChequers20:47, 16 March 2014 (UTC)
Have you ever experienced an edit conflict in which you clicked the "edit" button at the top of the page, changed one paragraph at the top, and had an edit conflict with someone who changed the last paragraph on the page—with you never touching 'their' paragraph, and the other person never touching 'yours'?
Well, neither have I. The section-edit buttons don't create some sort of magic protection. MediaWiki is now capable of automatically resolving that kind of edit conflict. Its ability to resolve the edit conflict is not impaired by using the whole-page edit button, nor is it enhanced by using the section editing button. What matters is the changes that were made, not the button you clicked on for making them. Whatamidoing (WMF) (talk) 23:57, 17 March 2014 (UTC)
Selecting mixed content with templates, copying
Say I have a page with {{lang|fr|France}}England{{lang|de|Germany}}. Open VE, select "FranceEnglandGermany", right click on "England" and click on "copy", this will copy all of the content. Do the same, but right click on "France" or "Germany", the rest of the text will deselect and clicking on "copy" will only copy the "France" or "Germany" content. Firefox 27.0.1 Windows 7 SP-1 64-bit. Monobook and Vector.--Atethnekos(Discussion, Contributions)20:49, 15 March 2014 (UTC)
If you have selected different types of things, and then you right-click on a template (or ref, or image, or any other "node"), it deselects everything and then re-selects only what you clicked on. This is not entirely unreasonable behavior. Compare it to selecting nothing, and right-clicking on either one word or a template, and to selecting multiple things, but right-clicking on a non-selected template.
However, there is a selection bug there: Select text + any normal ref tag, and then right-click on an {{sfn}} tag. (Try my sandbox; select the sentence containing ref 3, then right-click on ref 8.) The whole page lights up in selection-blue. Whatamidoing (WMF) (talk) 00:28, 18 March 2014 (UTC)
This is now T64765, but I think it's Safari only, and it's not 100% consistent for me (but I may be accidentally double-control-clicking when it fails; I'm not sure). Whatamidoing (WMF) (talk) 00:47, 18 March 2014 (UTC)
references
I am totally lost on how to add a simple reference even after reading the guide. I just want a simple dialog to add an isbn or pubmed id and have everything autofilled like is possible with the manual editor. I tried a bunch of templates but they were all inscrutable. Is there a place with examples of adding different types of references rather than a broad overview? Pgcudahy (talk) 05:27, 20 March 2014 (UTC)
They're working on an autofill option, but it's unfortunately going to be a while. First, they're redesigning the citation editor, and after that, they're adding autofill to it. Right now, the simplest thing is to to go Insert > Reference and just type in the citation manually: author, date, title, etc. For ISBNs and PMIDs, you can just type ISBN 12345 or PMID 12345 (whatever the number is, in plain text) and the MediaWiki software will recognize it as a WP:Magic word and create a link when you save the page.
Alternatively, if you want to use citation templates, you can go to Insert > Reference and then Insert > Template, and the template you want will be {{Cite book}} for books and {{Cite journal}} for academic journals. But you'll have to fill in all of the parameters by hand. Another options is {{cite doi}}, which isn't popular but is quick to add: add the doi, and a bot takes care of the rest later. Whatamidoing (WMF) (talk) 18:37, 20 March 2014 (UTC)
Doesnt work with WikiTrust
I have just find out that VisualEditor wont work, if you load WikiTrust script. So only way is to dissable your wikitrust script by comenting it or removing it from your user common.js.--Juandev (talk) 20:10, 17 March 2014 (UTC)
Hi Juandev, isn't WikiTrust discontinued anyway? I really liked it, so i just checked again - only errors. See [3][4][5] and [6][7].
A few months ago, I mentioned here that the arrows (keyboard buttons) sometimes work, and sometimes (well, most of the time) don't. No improvements seem to have been made in this regard.
So, why not test another, similar keyboard feature: the tab button, to go from one field to another? Open a random article with an infobox or other template with multiple parameters, and test! Mayaguana Airport: Hmm, strange, in the first few parameters, I have to tab twice to get to the next, but after a few a single "tab" is sufficient. Scroll back up, cursor in first box, and test again. So, you tab from the first to the second field, and then, well it depends: it goes to the parameter below the one where you were before you scrolled back up, or you don't go anywhere at all if you were at the bottom when you scrolled back up and refocused.
Apparently VE "remembers" where you were, and insists on going back there even though you have manually, explicitly changed the position of your cursor. Basically, you are only allowed to tab-scroll through the parameters once, and VE doesn't want you doing this a second time... The fun thing even if halfway through the parameters you put your cursor further down (skipping some parameters) and then start tabbing, it goes back up to where you were.
With a little delay but, this happens to me as well. I use FF28. And a small addition, while being on the last parameter if I click the tab button it takes me to "apply changes". Why does it skip the "add parameter" on the left? It would be much more easier to not skip it and force us to click on it with the mouse every time we want to add a new one. Thanks TeamGale05:46, 23 March 2014 (UTC)
For the past few weeks I've been trying to use the VisualEditor for as many edits as I can. While I'm hardly afraid of Wikicode, I find VisualEditor exponentially more elegant and enjoyable to use. I've managed to complete most edits just fine with VE, only running into errors occasionally, all of them being fairly minor.
Here are a few links which I hope will support the idea that the VisualEditor is capable of improving articles:
My contributions page - The majority of my recent non-Talk edits have been made using VisualEditor, and I've yet to experience any problems that weren't incredibly minor.
GoldSrc - I rewrote/wrote the majority of this article using the VisualEditor, and I'm quite satisfied with its progress since I began editing it (see Contributions for proof, of course)
Day of Defeat - Same as above, I edited this significantly, with almost every edit having been made in VisualEditor.
When editing any page with the Template:Infobox settlement (only some 400,000 pages, so not something obvious to check of course...), you encounter a sad problem with the template editing box. This template has many long parameter names, which only differ at the end, like
subdivision_type1, subdivision_type2 and subdivision_type3
subdivision_name1, subdivision_name2, and subdivision_name3
What is displayed though is "subdivision_ty" (three times) and "subdivision_na" (three times), which is of course rather useless. The former is the result when "show options" is used, without this the name are slightly longer, "subdivision_type" and "subdivision_nam". For parameters like "population_density_urban_km2" and "population_density_urban_sq_mi", which have no explanation, this means that it is impossible to distinguish between the two in the standard (no options) view... Perhaps a pop-up that displays the full name may be some initial solution? Fram (talk) 12:51, 25 March 2014 (UTC)
Wrong message: "You are adding the "[...]" template to this page. "
When editing a template (without templatedata, this seems to make a difference), you get the message "You are adding the "Infobox_Locomotive" template to this page." or "You are adding the "Horseraces_infobox" template to this page." (with the correct template name, thuis is just an example). Of course, I am not "adding" that template, I am editing, changing it. The message should reflect this. Fram (talk) 10:50, 25 March 2014 (UTC)
It's the same message used when you add it, alas :) I don't think VE can display two different messages there, so, suggestions about a single one which covers both cases? Mine would be fairly simple, You are adding or editing ... --Elitre (WMF) (talk) 11:08, 25 March 2014 (UTC)
VE knows enough to display the "insert template" button (when you are adding one) vs. "apply changes" button (when you are changing one); it shouldn't be hard to change the message in the same manner, detection of what happens is already done. Fram (talk) 12:36, 25 March 2014 (UTC)
According to the user guide, updated by User:Whatamidoing (WMF), "If you are adding a new template, required parameters will be automatically added"[8]. Really? So if I add, say, "Template:Sortname", VE knows that I need two unnamed parameters and adds these? I don't think so. Of course, it also doesn't work if you e.g. use one of the many synonyms for our templates, e.g. Template:Citebook instead of Template:Cite book. I presume, what the change to the user guide wanted to say, was that if you used the exact name of a template with complete templatedata, then and only then will the required parameters be automatically added... Fram (talk) 13:42, 21 March 2014 (UTC)
Hi again. I think the user guide can (and will) be changed to remind editors of the role of TemplateData in this (so that, yes, when TD is available, then the parameters will be added, and things like that). What might be interesting to know is that if TD isn't available yet there's now a handy link to the template documentation in the dialog, which is IMHO a nice improvement. The synonyms issues you mentioned is a tricky situation, as 50964 reveals, which needs to be addressed by multiple teams. --Elitre (WMF) (talk) 14:31, 21 March 2014 (UTC)
"Required" means that the parameter was labeled as "required" in TemplateData.
Notice that this "requirement" is not being enforced in software: you can still save the page even if you don't add all "required" parameters to a template that allegedly "requires" them. This could be changed, but I doubt that the results would be desirable. You'd have people adding garbage or refusing to save because they didn't know what to put in the "required" field. Also, it might "require" you to fill in missing data on a template that was added previously (just like the spam blacklist requires you to remove spam that someone else added). Whatamidoing (WMF) (talk) 21:43, 25 March 2014 (UTC)
""Required" means that the parameter was labeled as "required" in TemplateData." This is the kind of technically correct but very user-unfriendly things that should not be put into a user guide. You can't expect a user to guess these things, you should describe what a technically unaware user encounters. As it stands, the information you added is useless and confusing. Fram (talk) 08:07, 26 March 2014 (UTC)
Template parameters with multiple lines
When a template parameter is longer than the input box displays (which isn't too hard to achieve, e.g. with a ref in a parameter), you don't get an indication of this when opening the template. This is confusing. Worse: when you then click inside the parameter input box, you get a larger box and a scroll-bar once the parameter length is three or more lines, but for some obscure reason, you don't get a larger box or scroll-bar (or any other visual indicator that there is more to come) if the parameter is two lines long...
Example: Contra (album), go to the "professional ratings", and explore. Parameters "rev10score" or "rev2score" do not indicate that a second line follows: parameters "rev3score" and "rev5score" give a sudden scrollbar when you click in them, because they are longer than 2 lines.
The boxes should automatically, ab initio, indicate that more text follows, and should have either a scrollbar or preferably the larger box for two-line parameters. Fram (talk) 11:06, 27 March 2014 (UTC)
In Firefox 28, I get properly expanded boxes for "rev3score" and "rev5score" upon clicking in them, but not before clicking in them. For the two-line items, I don't get expansion or a scrollbar (although I can scroll there). In my quick check today, I didn't find any template with long parameter data that displays correctly (pre-clicking) in Firefox. It works perfectly in Safari (and therefore probably also in Chrome). Whatamidoing (WMF) (talk) 18:18, 27 March 2014 (UTC)
I'm trying to edit Line–line intersection to add a note after the last equation in the X and Y values of intersection on a linear curve section. The obvious way to do this is to place the cursor at the end of the equation, press enter to make a new line and type. Problem is that it indents the text (using a <dd>) and there is no way to cancle this indentation. Using the style format drop down does not work, the decrease indent button is greyed out, no combination of shift-enter seems to do it.
A workaround is to place the cursor before the following heading and press enter. This is decidedly non intuitive. --Salix alba (talk): 09:57, 27 March 2014 (UTC)
You're right: there is no support for HTML definition lists in VisualEditor (yet). I'm told (by the W3C experts in the community) that nobody should be (mis)using : to create indentations, but it turns up all over the place because there is no support in MediaWiki for proper indentation. It's one of those things where "looks fine on my own screen" does not happen to be semantically correct. Presumably when support for definition lists is added, then this will be resolved. Whatamidoing (WMF) (talk) 18:27, 27 March 2014 (UTC)
"Frame" option
One of the recent "advanced" settings we get for files is "Frame". Sadly, we read on Wikipedia:Picture tutorial:
"Replacing "thumb" with "frame" causes the image to be displayed in its native size, that is, the size that it was originally uploaded with. This use is obsolete and should not be used because it is disruptive for many displays, especially mobile devices. Instead, if an article would be better with pictures resized in some way other than the default, use the "upright" parameter." (emphasis mine) Of course, while we do get the obsolete, disruptive, not to be used option, we don't have the "upright" option.
Apparently, it wasn't sufficient to point out, repeatedly, for months, that "no size" is the default, before this was finally implemented after it was shown that, contrary to what was said, this worked perfectly allright in VE, and it wasn't sufficient that e.g. NicoV regularly indicated that French Wikipedia really needs "upright" to match their defaults; we really need to tell the WMF that there are policies, guidelines, things that should be avoided, already well described on the different wikis, and that they are to duplicate these unless there is a very good reason not to. I have no idea why they decided to include "Frame", and not to include "Upright"; if anyone from the WMF can post a link to the analysis, documentation, discussion that preceded the development, I would be grateful (and frankly surprised). Fram (talk) 12:47, 21 March 2014 (UTC)
While I can not speak for the devs here (I haven't had a chance to ask yet, and probably won't have one until next week), I'd like to remark that "upright" actually seems to be on its way (62666, 62671, if Parsoid behaves, something it probably already does with "frame", which might be an explanation for priorities). As for "frame", which might be locally deprecated like you point out, I couldn't find any comment on the Mediawiki guide for images that refers to it as to something which is obsolete or should not be used anyway (I actually couldn't find similar remarks for any option there, meaning that probably all of them will be featured, at some point). So (always wearing my "I really don't know" hat) I'm assuming that unless there are serious technical reasons which make that not work in MediaWiki, "frame" will be available despite the current usage (which is never set in stone, BTW. DYK that the Italian Wikipedia concretely adopted "upright" only this month?). HTH, and will let you know more when I can. --Elitre (WMF) (talk) 14:14, 21 March 2014 (UTC)
I am quite surprised to let you know I was actually right on this :O While James isn't personally a big fan of "frame", it's not an unused parameter. But, turns out that Multimedia devs don't like it at all, so its future is not clear. You might want to hear from them, in case you're interested? HTH. --Elitre (WMF) (talk) 13:59, 25 March 2014 (UTC)
Thanks. 14:21, 25 March 2014 (UTC)
To add another detail, frame and frameless behave like they do because of an old bug, not because they were supposed to. It's possible to fix it now, but since thousands of MediaWiki installations depend on it being "broken", nobody knows whether it makes more sense to fix the bug or to declare it a "feature". Whatamidoing (WMF) (talk) 21:40, 25 March 2014 (UTC)
Sadly, the "upright" option is also broken. The way it has been documented on various pages was at odds with how it is actually implemented in code. I've fixed all the wrong documentation on enwiki, but bad translated documentation is undoubtedly all around. There's an RFC out to implement something which actually works "right", see mw:Requests_for_comment/Square_bounding_boxes for more details. C. Scott Ananian (talk) 19:53, 28 March 2014 (UTC)
I've been busily editing, and since it's been mostly copy-editing, VE works great. One question though - I was going through an article and deleted one too many spaces, causing the paragraph I was working on to join with the bullet-pointed list above it. I fixed it using edit-source but I was wondering if there was any way of fixing that in VE? (I have read the user guide but didn't spot anything about it.) Red Fiona (talk) 23:33, 28 March 2014 (UTC)
The answer is that you put your cursor between "Two" and "New paragraph" to get the "New paragraph" on its own bullet point (which you might have done already) and then, with your cursor on the "New paragraph" bullet point (nothing else selected), click the bullet list icon in the toolbar to turn off the list formatting (just for the one list item). Whatamidoing (WMF) (talk) 22:35, 29 March 2014 (UTC)
Sort of connected with my bug report above, I'd like for the "Default summaries" gadget (Preferences > Gadgets > Editing > "Add two new dropdown boxes below the edit summary box with some useful default summaries") to be integrated into the VisualEditor. This is very very useful for lazy people (See: most of Wikipedia's editors, apparently), because it allows for edit summaries to be descriptive with minimal work required by the editor. Blank edit summaries are useless, inconvenient to other editors, and acronyms (e.g. "ce" in place of "copyedit") are horribly cryptic to new users. Discouraging these practices would benefit everyone, and making it easier to include edit summaries would be a great way of dealing with this issue. I imagine this feature would be shown at the same time as the edit summary, obviously. Edit the page with VE > "Save page" > Edit summary input window w/ two dropdowns below it, directly next to each other horizontally rather than taking up too much room vertically, as is the case with the current gadget in combination with VE. I imagine these dropdowns to look a lot like those in this Watchlist redesign mockup.
In general, user scripts like that are not supported, so I don't think that they'll necessarily address the problem you've reported (although I will report it so that they at least know about it). But there is some interest in solving the edit summary problem in some way, possibly by writing a new version of that gadget. I've linked a handful of the most relevant feature requests. Would you mind looking through them and telling me which ones you think would be most helpful, or if they inspire even better ideas for you? Whatamidoing (WMF) (talk) 17:58, 31 March 2014 (UTC)
Trying to use the "Default summaries" gadget to input a description of my edit quickly, but it wouldn't work when submitting via the "Save" dialog in VisualEditor.
Steps to Reproduce:
# Navigate to Preferences > Gadgets > Editing > "Add two new dropdown boxes below the edit summary box with some useful default summaries"
Edit any article with VisualEditor
Try to save page, instead of typing anything into the edit summary box, use the dropdown menus added by previously-mentioned gadget.
Submit the edit summary you've filled with the dropdown.
Results:
You may receive a warning saying that the edit summary box is blank, ignore it and save it anyway. In the "View history" tab, no description is included with your edit.
Expectations:
The description entered via pre-filled dropdown should be included as my edit summary.
I did some quick testing, and the edit summary is saved, if you click back inside the edit summary textarea after choosing an item from the list. If you don't click back inside the box, then you will get the warning about no edit summary (if that's enabled) or saving without an edit summary.
Also, I found another problem: Open the save dialog. See the two drop-down menus. Close the save dialog (like you decided to make one more edit before saving). Open it again. Count the number of menus you get when you open it. I'll post bug reports for both of these in a few minutes. Whatamidoing (WMF) (talk) 18:08, 31 March 2014 (UTC)
I've previously encountered T61748 in Safari. If you type "teh" and let it auto-spell-correct the word to "the", then you'll still get "teh" when you save. (Safari and Chrome are both WebKit and tend to have the same, or at least similar, problems.) If you read that older bug report, you'll notice that it matters whether you click outside the paragraph after trying to fix the spelling. If that's the case for you, too, then that would be valuable to know.
In the media advanced options, some weeks ago the "wrap content with this item" option was added. Looking at it now, it is still there, but the tag box (similar to the "border" box in the image type section) is no longer usable, as some strange bold-looking rectangular box is superimposed on it. I can change the value of the "wrap" box by clicking on the text next to it, but I only discovered that workaround by accident. FF28, W7. Fram (talk) 14:10, 2 April 2014 (UTC)
{{tracked}}
Entire page becomes editable. I edit the section I wanted and also improve something else on the page, and click save. Surprisingly, the edit summary has the name of the section I originally clicked to edit, and ignores the fact that I also edited other sections.
When I edit a section, please either
make only a section editable (I think I already mentioned this possibility to you before and it could make things really better performance-wise, as a section is smaller and it's less work for you), or
track my edits to other sections and update the edit summary you're about to show me.
The section name was added automatically at community request.
Your second idea has been suggested before, and I think it's a good one. Nobody in the WMF is working on this request at the moment, so it's open for any volunteer devs who want to submit a patch.
True section editing would slightly hurt performance on opening pages and have no effect on the actual editing process. It's possible that it might have a small benefit on saving pages (on very large pages, the potential benefit might be enough for people to notice it), but since the save process has been tweaked to start sending necessary information while you are typing the edit summary, it's not likely to increase perceived speed of saving on typical pages (except perhaps on the largest ones). Whatamidoing (WMF) (talk) 17:32, 2 April 2014 (UTC)
So, you are requesting the opposite of what bug 50872 managed to achieve! :) Anyway, you might be interested in bug 51903, If the user only has edited in one section, insert the name of that section into the edit summary as if they were section-editing, which is already assigned, and then bug 52859Populate the edit summary for simple changes / bug 63142Automatically generate an edit summary for the user. --Elitre (WMF) (talk) 17:57, 2 April 2014 (UTC)
I think of Gryllida's suggestion as being a refinement of 50872: give us the section name, but be smarter about removing it when it's not appropriate. :-) Whatamidoing (WMF) (talk) 18:05, 2 April 2014 (UTC)
You gave some thoughts on generating an edit summary. They're entertaining and verbose, thank you.
However, I would personally encourage making only a single section editable. It may have little or none performance effect, but the old editing system only did that, and it matches expectations (a user who wants to edit a section will be grateful to you letting him do exactly that). Gryllida (talk) 22:21, 2 April 2014 (UTC)
I have reset the {{tracked}} template at this section beginning, it has a bug only about a half of my request. Fill it in about the other half, and reinstate it. Gryllida (talk) 22:23, 2 April 2014 (UTC)
Uh ,no, or I would (incorrectly) complain that VE didn't support the typography refresh at all. I used Vector, with the refresh enabled (I have since disabled it), and editing in VE showed the new typography (title and headers in serif), but the dropdown, where you can choose "paragraph, heading" and so on, didn't reflect this (in the "heading" and "title" choices. Considering that the dropdown tries to simulate the actual look, this seemed strange. Not a big deal obviously. Fram (talk) 14:18, 4 April 2014 (UTC)
As you say, it's strange. I checked both FF and Chrome and I don't notice anything weird (I've been using the TR as a BetaFeature for months, I think I'd be able to recognize the difference now?). We'll see if anybody else reports the same problem. Thanks, --Elitre (WMF) (talk) 14:23, 4 April 2014 (UTC)
So, when you use the "paragraph" dropdown, you see "heading" and "Page title" with serif font, and the others with a sans serif font? Strange indeed, doesn't happen to me. The mysteries of the internet... Fram (talk) 14:31, 4 April 2014 (UTC)
I'm seeing san-serif fonts. Chrome Mac OSX, Vector. It looks like the appropriate css selector would be .oo-ui-tool-name-heading2 but this does not seem to specify a font-family.--Salix alba (talk): 15:24, 4 April 2014 (UTC)
Reusing references from a "pool" across all articles on the respective Wiki?
This is likely an insanely complex suggestion, but one that would also be incredibly useful for all editors. I would like for there to be some sort of back-end tracker of all references across the English Wikipedia (for example), so that when you entered an article title it would be searched and a suggestion would be made to automatically fill out the entire reference template automatically, assuming that reference has already been used on another page.
I've recently been editing a number of articles on games by the Valve Corporation, and have found that references frequently overlap between the games because news articles may discuss multiple games in a series or by the same developer. This would make the process of referencing exponentially easier, and help to make sure that if a reference with an issue is corrected on one article, it would be corrected on all articles using that reference. It would also allow for easier archiving of references and tracking of dead links across an entire wiki.
Again, I realize this would be incredibly difficult to create, but I also think it would be incredibly beneficial to users. Not only would you be able to reuse references in a single article, but reuse references throughout millions of articles. --Nicereddy (talk) 03:58, 6 April 2014 (UTC)
Hello. I think that something similar is at least partly going to happen at some point. The future reference system will not just provide quick access to the most used referencing templates: it should also have an autofill feature that retrieves and fills in data about a book or a journal article. But, if I understand it correctly :), what you suggest about correcting the links sounds odd to me. That's a task that (AFAIK) bots can do well and quickly, and I am not sure how the software could distinguish between "replace this link everywhere because it's broken" and "replace this link here because I have a better source or it was put in the wrong place"? --Elitre (WMF) (talk) 13:43, 7 April 2014 (UTC)
Office hour in April
Greetings! As you know, the Wikimedia Foundation's engineering department holds monthly office hours to discuss VisualEditor. Please join Product Manager James Forrester to discuss the product and upcoming plans in April.
The discussion will be on IRC (w:Internet Relay Chat) at irc://irc.freenode.net/wikimedia-office. For more information on office hours, including how to attend, please see m:IRC office hours. Logs will be posted at Meta afterwards.
If office hours are heavily attended, it can be difficult to get to all questions, but if you want to ask a question and cannot attend or do not speak English, then please let us know your question here by the day before, and someone will add it to possible discussion topics. Thank you! --Elitre (WMF) (talk) 17:43, 7 April 2014 (UTC)
Templates
If the "insert > templates" would show the templates I highlight, that would be great.
I want to add a timeline to list items in chronological order to an article & I can't seem to figure it out.
If you select an existing template, and then tell it to insert a new template, it's going to open the existing copy, instead of replacing the selected one or adding another. If you wanted to edit the existing copy, then this is great (but double-clicking would be faster). If you wanted a second copy of it, then you need to know the desired template's name. Click where you want the new copy to go, Insert>Template, and type in the template's name. Whatamidoing (WMF) (talk) 20:22, 8 April 2014 (UTC)
When editing templates, the trash can meaning "remove parameter" only shows if you click in the box of the relevant parameter. I think the trash can should always show. -- Ypnypn (talk) 19:50, 9 April 2014 (UTC)
I agree, Ypnypn. Thanks for this suggestion. It's especially confusing if the first one is selected, and subsequent ones are not. It makes it look like the others can't be removed. This request is now T65775. Whatamidoing (WMF) (talk) 15:31, 10 April 2014 (UTC)
I agree. It's planned, but it's going to be months before we see anything concrete. Dealing with table structure is a difficult design decision. Whatamidoing (WMF) (talk) 16:26, 12 April 2014 (UTC)
I am sure this bug was mentioned a long time ago but as I can see still didn't get fixed. On this edit you can clearly see the problem. When I tried to bold already existing links, VE "doubled" the title in cases that it was not necessary instead of just putting the '' outside the brackets. Here is the correction of the "problem". TeamGale09:58, 13 April 2014 (UTC)
I couldn't find any double bold in that diff. This line, for example:
[[Tegan and Sara|'''Tegan and Sara''']]''', ''[[Heartthrob (album)|Heartthrob]]'''''
Gives you this:
[[Tegan and Sara|<b>Tegan and Sara</b>]]<b>, <i>[[Heartthrob (album)|Heartthrob]]</b></i>
(or, in English, turn on bold for the link, turn off bold at the end of the link, turn the bold right back on for the comma, add italics, turn both bold and italics off). Whatamidoing (WMF) (talk) 23:33, 13 April 2014 (UTC)
Whatamidoing (WMF) I don't mean that it doubles the bold but the text when it's not necessary. Look the difference again. For example this:
''[[Behind the Candelabra]]'' should become '''''[[Behind the Candelabra]]''''' and not ''[[Behind the Candelabra|'''Behind the Candelabra''']]
There is not need to add "Behind the Candelabra" twice just to bold it. It only has to add the 's outside the brackets. As for the example you are giving, again it's not the result I was expecting. Since I highlighted the whole line to make it bold the result should be:
'''[[Tegan and Sara]], ''[[Heartthrob (album)|Heartthrob]]'''''
with the 's just to be added at the very beginning and at the very end. Not to double the "Tegan and Sara" text and add the 's twice. There are many examples on the difference. If you look at the second difference I gave where I removed the unnecessary texts you can see it better I guess..?
What I am saying is that VE adds unnecessary text when someone tries to bold an already existing link. I think when you bold/italic first and then the link this "problem" doesn't exist. But that's not the solution. When you already have the link I don't suppose that we should unlink it, bold/italic and then link again! I am sure that this bug was mentioned months ago and I don't understand why I still see it... TeamGale04:47, 14 April 2014 (UTC)
Thank you for the bug Whatamidoing (WMF). I know there is one, as I said at the very beginning of this post: "I am sure this bug was mentioned a long time ago". My question was why it still exists? Can we have an update on that? From what I can see it was first filed almost a year ago! What's the issue with it? Is it so difficult technical to be fixed? Or it was forgotten? Because it happened bugs to be forgotten in the past... Is it easy to have an update about it? Thanks TeamGale20:39, 14 April 2014 (UTC)
From the discussion on the bug report, it looks like this is a complicated problem. On the positive side, though, it sounds like fixing this will fix multiple other things (including some of the very annoying [[Link|Li]][[Link|nk]] ones). I can ask about its status. It may be that they've been working on other priorities. Whatamidoing (WMF) (talk) 20:42, 14 April 2014 (UTC)
Hi TeamGale, I have more information for you about this. It is a complex problem, but the basic story is that they tell VisualEditor not to mess around with the wikitext whenever it's possible to avoid doing so, and this is a time when we actually want it to mess around with wikitext. A quick-and-dirty fix would risk page corruptions (messing around with the wrong links), so they're going to have to be very careful about how it's handled, which means a major update to the relevant parts of the data model.
This is the good news: multiple link-related bugs will get solved when this is all settled. This the bad news: it will take at least a month of uninterrupted time to get this right, and maybe more. This is the reality news: no progress has been made on this bug during April because everyone wanted references to continue working, and they were going to break if Ed hadn't spent all of April so far on maintaining refs. Fixing bug 50098 is not currently scheduled, but James F says that it is on his top-5 list for major necessary improvements, and while he can't absolutely promise that it will be done soon (because he can't promise that Ed's attention won't be even more urgently needed elsewhere), he definitely expects it to be done this calendar year and is cautiously optimistic that it will be next quarter rather than the last quarter. Whatamidoing (WMF) (talk) 18:01, 15 April 2014 (UTC)
Thank you very much for the update Whatamidoing (WMF). At least now we have a picture of what is going on. I really hope they can get to it the soonest as possible. Thank you again. TeamGale19:34, 15 April 2014 (UTC)
Well, the last discussion on the bug report is more than 7 months old... How do want us to believe anyone is really working on this? This bug is among several others that are making wikitext more difficult to understand (the result if awful for wikitext users, which are 90% of the editors), but isn't really visible to VE editors. And it gives the impression, that the VE manager has no interest in fixing this kind of bugs that require other users to come and fix what VE is producing. I have about the same discussion on frwiki about the bug T55315 (telephone numbers) where the technical solution was given 7 months ago, and the current VE manager position is "we will need to experiment". So, when are you finally going to "experiment" and fix those annoying bugs that have been reported many months ago? --NicoV(Talk on frwiki)20:56, 14 April 2014 (UTC)
As a practical matter, "start working on X" always means "stop working on Y" (or postponing Y even further). This means that fixing "your" bug sooner means not fixing someone else's bug as soon as it might be done. In general, they work on the highest priority bugs first. Average priority bugs like 53315 may sit for months with no action, or they may get fixed immediately. It's hard to predict.
I've never asked you to believe that bug 53315 is being worked on: it is unassigned, and nobody is working on it. Nobody knows whether the proposed fix would work, but they do expect it to have some collateral damage. Assuming that Apple doesn't change their approach (The Right Thing™ for that particular bug is for Apple to fix it, rather than for VisualEditor and all similar programs to work around Apple's design), then someone will eventually be assigned to it and fix it. Assignments usually change every two weeks, so "eventually" could be soon, or it could be next year, or anything in between. If you'd like, I'll ask James F to bear it in mind when the next sprint is scheduled, but I honestly don't think it's going to be a focus during the next month or two. Whatamidoing (WMF) (talk) 23:37, 14 April 2014 (UTC)
First of all, it's not my bug: they are bugs that make wikitext incorrect or very difficult to read, and usually require someone else to use the wikitext editor to fix the VE edit. I often said it and I will say it again: I think priority should be put on fixing bugs like that because I think people are tired of going after VE to fix the problems it creates, rather than spending time on writing an encyclopedia. So, yes, if it means postponing the addition of new features to VE, I don't care, because what I care about is wikipedia. Other bug in the same category: the nowiki tags still being added to internal links, even creating things like [[Link|<nowiki />]]. --NicoV(Talk on frwiki)06:26, 15 April 2014 (UTC)
Yes, it's not really "your" bug, which is why I put that word in scare quotes.
The fact remains that there is an unavoidable opportunity cost: working on the bugs that seem most important to you means not working on the bugs that seem most important to people who disagree with your priority. Speaking for myself, I think that corruption bugs should generally be high on the list. But having said that, I think that corruption bugs that affect very few editors and very few pages aren't always as important as missing features. For example, T65121 is a corruption bug, but I'd rather have support for upright image sizes. Whatamidoing (WMF) (talk) 15:24, 15 April 2014 (UTC)
Slowly improving
After several months, I gave the Visual Editor another try today. My initial observations:
Basic functionality for text editing and linking has greatly improved: far less glitchy, and the interface is more intuitive than before, with more things behaving in ways that follow the principle of least surprise.
Startup time is much improved
Template editing is also significantly improved: even things like reference templates within references now work. Unfortunately, this is still not nearly enough: templates are so intrinsic to Wikipedia's structure that this needs to be made far more intuitive.
It's not at all obvious how to edit categories: I eventually found it under the menu icon -- this dialog should surely be accessed from clicking on the category box, which should still be displayed on the editable page.
The VE is definitely getting better, and a lot of the "paper cut" bugs are now fixed, to the point where it's actually a practical option for making small textual edits to existing articles. It's still nowhere near being a practical replacement for wikitext editing, though. -- The Anome (talk) 16:30, 13 April 2014 (UTC)
Reference templates editing will "soon" be a real thing (and hopefully easier/more intuitive than the generic template editing option), and I agree with you that categories might deserve a more prominent place, as suggested for example by 50239. Thank you for your feedback, --Elitre (WMF) (talk) 10:47, 17 April 2014 (UTC)
On small articles such as Act of Depression, the reference template blocks other templates, in this particular case the album ratings box. If I try to edit the album ratings box by clicking on it, I end up selecting the references template.--¿3family6contribs20:41, 18 April 2014 (UTC)
In that case I can select it, but the puzzle piece popup appears far above; actually very close to where the Infobox puzzle piece shows up. FF 28.0 Win7 SP-1 64-bit. Vector skin. --Atethnekos(Discussion, Contributions)21:15, 18 April 2014 (UTC)
Thanks for these notes.
The "missing" puzzle piece is T51922. The template is highlighted where you see it, but the puzze piece appears where the underlying wikitext is located (in this case, second line of the page).
The original report is bug 51933, and whether it's a problem on any given page depends on your screen width and font size. As a horribly clunky and non-intuitive workaround (but possibly better than nothing in some cases), you can select that template by placing your cursor at the top of the page (where the wikitext for that particular template is) and using arrow keys to select the template (e.g., →—no need to hold down the shift key, because templates autoselect when the cursor finds them). That will give you the puzzle icon and let you edit the template. Whatamidoing (WMF) (talk) 21:42, 18 April 2014 (UTC)
All of a sudden the text and line spacing in the Visual Editor are substantially smaller than when reading the page. I'm using Firefox on OS X 10.6.8. The line spacing is also uneven, in that references create greater than usual space above them. This wasn't the case a few days ago. – Arms & Hearts (talk) 11:05, 19 April 2014 (UTC)
It appears that this is supposed to be fixed in the main MediaWiki software, rather than in VisualEditor. I'll be looking foward to the resolution. Whatamidoing (WMF) (talk) 21:16, 21 April 2014 (UTC)
beta stuff
beta visualediting doesn't seem to be saving properly: I click 'save', it loads for a while, I 'exit' saving, but it has, in fact, saved.
Hi Peter13542 , I recall having the same issue in the past, so this is probably already filed, but would you please specify your browser/skin/OS and on which article this happened (you recently edited 3 with VE), so I can see if it's reproduceable? Thanks, --Elitre (WMF) (talk) 08:54, 24 April 2014 (UTC)
Icons in the (large-form) dialogs overlap other things, making the controls unusable. (Firefox 28, Windows 7, monobook):Jay8g [V•T•E] 01:04, 24 April 2014 (UTC)
This is a known issue with Firefox, but thanks for stopping by anyway! Will add the bug number ASAP if noone beats me to it. --Elitre (WMF) (talk) 08:49, 24 April 2014 (UTC)
I attempted to add and fix some references in an article and when I clicked "save" I got a message "unknown error" from VE and as it seemed my edits didn't get saved. I clicked again on the "save" button and this time the page was saved. When I went to my watchlist I saw that the page was saved both times but in the first time VE removed big amount of information that I didn't even get close to during my edit. Here is the first difference where it gave me the error, saved my edits and removed the info at the end of the page; and here is the second difference where it actually brought back the info it removed in the previous "save". Any idea why this happened? Is it a bug? TeamGale13:57, 21 April 2014 (UTC)
I'll have to go look, but I suspect that it's something to do with the succession boxes. I think this has been reported once before, and only appears when there is a particular type of table-creating set of templates box, plus ref tags, when you've clicked in the slug after the last visible text under a blue moon and without invoking the protection of the dogcow first. In other words, a bug that you couldn't have predicted or prevented. ;-)
Whatamidoing (WMF) Sorry for the delay answer...I am not really a tech expert so I don't understand all the terms you are using. What I can say to might help is that I added many references in the specific page with VE in the past days and that was the first time I had this problem. I don't think I did anything different this time to cause this :/ As for the question if I left the dialog box between the two attempts to save, if I remember correctly I did. Is there a bug report for that yet? Or it wasn't filed yet? I hope we can find what caused it so I might avoid it next time..? Thanks TeamGale23:30, 23 April 2014 (UTC)
It's T66375. I talked it over with James F (the product manager) before filing it. He says to thank you for finding this very bad corruption bug for them. I don't think that there is anything that you could do to avoid it. He's going to get someone working on it soon. Whatamidoing (WMF) (talk) 17:16, 24 April 2014 (UTC)
You are welcome although it was more matter of luck...or not...finding it ;) I hope it can get fixed before it causes more corruptions. In case I encounter with it again (hope not) I'll post the difference. Thanks TeamGale15:22, 25 April 2014 (UTC)
To reproduce have MathJax enabled in your preferences: appearance tab Math section select Leave it as TeX (for text browsers) and MathJax (experimental; best for most browsers). And also the VisualEditor formulae editing beta feature enabled. Find any page with a <math> tag on. Edit with VE. Find a formula. Initially this will appear as a PNG. Edit the formula by clicking on the Σ popup. As soon as a change is made the formula is re-rendered using MathJax and look terrible.
The problem seems to be a clash of CSS styling. MathJax makes heavy use of position: absolute yet this is all rendered to nothing by the CSS rule
So its quite clear that overriding the position, top, left, right and bottom is going to mess things up big time.--Salix alba (talk): 07:43, 28 April 2014 (UTC)
VE is not parsing unmatched onlyinclude tags in a way that enables it to identify problems with them
VE added what it thought was a missing table terminator at the end of the article which will nearly always be wrong even if adding it somewhere would be correct
Thanks for the note. I'll file the bug report on Monday if no one gets to it any sooner. We'll have to sort out whether it's VisualEditor or Parsoid that is having the problem. Whatamidoing (WMF) (talk) 16:25, 12 April 2014 (UTC)
Mirokado, I can't reproduce this. I've tried a couple of things, but it never adds a new "close table" tag for me. There may be some interaction with other elements on the page.
I imagine the includeonly tags were so that the table could be transcluded elsewhere, but it looks as if the article is not transcluded anywhere at present. I was away a couple of days but will also try to reproduce this over the weekend. --Mirokado (talk) 09:13, 17 April 2014 (UTC)
Hi Whatamidoing (WMF), I have been able to reproduce the problem by doing exactly what I did before: changing the text of a wikilink and then updating the link. Please see this edit. I imagine that changing the link like that triggers some reparsing which does not happen with a simpler edit. --Mirokado (talk) 20:03, 18 April 2014 (UTC)
I think I've got it sorted out. Changing a link causes the problem... but only if the link is after one of the oddly formatted tables. If you pull the first table out, then the problem doesn't appear with the Pheonix/Phoenix link. However, because the second table has the same formatting system, the problem reappears if you change a link after the (still present) second table. Also, all of that post-table text is formatted as if it were still part of the table (while you're editing), and it obviously shouldn't be. This is now T66571. Whatamidoing (WMF) (talk) 21:25, 28 April 2014 (UTC)
There is a display bug with the infobox when editing, moreover [9] VE modified the infobox even if I didn't modify this part of the page. This happens with Chrome 34, Windows 8.1. Sorry if this was already reported, I am not familiar with VE on the English Wikipedia (but a lot more on the French WP). NemesisIII (talk) 20:04, 2 May 2014 (UTC).
Thanks for your note. Basically, the current status is that VisualEditor (or the underlying Parsoid software) doesn't work with the strange infoboxes used in many articles about ships on the English Wikipedia. I've been meaning to ask the editors who work on ship articles why they're using such an odd system. Whatamidoing (WMF) (talk) 21:36, 2 May 2014 (UTC)
Open an article with references in VE. Open a reference. Select "insert template". The only thing that still works is "show options" / "hide options", but you can't select a template, and you can't close that "add template" frame anymore. Only solution? Close the page, do not save, do not receive $4000. Tested through "random article" at Wacker process, SRGAP2, and Char BrahmanagarFram (talk) 07:58, 25 April 2014 (UTC)
Thanks for the report, Fram. It works for me in Safari, so this is presumably a Firefox-only bug. Also, it works for me in Firefox if you first click inside the reference box. What version are you running these days? Whatamidoing (WMF) (talk) 16:19, 25 April 2014 (UTC)
Just an update: This also happens if you try to add new citations, which is even worse. People are not especially likely to open an existing reference and go directly to the template (without removing what's there); they are likely to start a new one and go directly to template insertion. Whatamidoing (WMF) (talk) 16:28, 25 April 2014 (UTC)
Any update on the specific bug? It's really annoying when someone is trying to add references with VE! I know you can add template if you first click on the box but, not everytime can remember this unnecessary step and the result is to lose all your work :/ I can't see any comments on the bug report...any other update? TeamGale15:29, 28 April 2014 (UTC)
Ed has fixed it. I'm not sure how soon we'll see the fix here. Tomorrow afternoon (San Francisco time) is the earliest possibility, but I'm guessing that next Thursday is more likely (so that they can have a week of testing at MediaWiki.org to make sure that it didn't break anything else). Whatamidoing (WMF) (talk) 21:50, 30 April 2014 (UTC)
@TeamGale: It's a very annoying bug and we'll do what we can to get it resolved in production ASAP. In the meantime, if you click into the reference window before inserting a template, it should work. Thanks for your patience.--Eloquence*22:18, 30 April 2014 (UTC)
@Whatamidoing (WMF):@Eloquence: Thanks both for the update. I hope it will be available the soonest as possible. I know about the clicking into the reference window first..the only problem is that the step is not really necessary and many times automatically I skip it and go straight to the template addition. Thanks again for the update. Can't wait for it to get resolved! TeamGale23:28, 30 April 2014 (UTC)
You can't do anything, which is presumably the "fix" for the earlier bug. Doubleclick inside the ref.
Check "Insert" -> "Template": nope, you are not inserting a template, but editing the one that was already there.
Oh, perhaps I didn't need to doubleclick, but use a simple click?
Indeed, now I can insert a new template. All's well that ends well...
Type "cite web", click "add template"; hey, the "select templates" drop down remains sumperimposed over the parameter fields. That's very annoying...
Close the "add template" screen, reopen it; nope, the dropdown obscures the whole upper left of the template screen. Clicking inside it makes it disappear, but that's hardly optimal behaviour. Fram (talk) 08:25, 5 May 2014 (UTC)
Fram, I can't reproduce any of this in Firefox 28.
When I open Ref 3 in the same article, and immediately mash my keyboard (no clicking anywhere), it just works: the new text appears before the existing template. If I immediately go to Insert > Template, it inserts a new template (also before the existing template).
Insert > Template always edits the existing template, if you have have a template selected. "Insert" isn't a great description (and they're looking for better options), but it's actually intended to either insert a new one or edit an existing one, depending on whether you have one selected.
Common edit summaries lists appearing multiple times
Hi,
I just tried again VE on an article (Win XP, FF 17). Each time I open the save dialog, both lists "Common edit summaries" and "Common minor edit summaries" appear as many times as I opened the save dialog. For example on Lovespell, first time I open the save dialog, both lists appear one time. Close the save dialog, open it again: each list appears twice. Repeat: 3 times... --NicoV(Talk on frwiki)07:08, 7 May 2014 (UTC)
Hey NicoV. I believe you'll want to tell the creators/maintainers of the gadget on which that depends? Add two new dropdown boxes below the edit summary box with some useful default summaries is not a VE feature, AFAIK - although something similar has already been asked for (also in other bugs). --Elitre (WMF) (talk) 11:42, 7 May 2014 (UTC)
I think the most I managed to accumulate was eight copies. The problem has to be fixed in the gadget. It appears to be one of the more actively maintained gadgets, so perhaps it will be done someday. Whatamidoing (WMF) (talk) 14:53, 7 May 2014 (UTC)
Change to edit source
I noticed that the popup which tells you if you try to use wikicode that it does not work still tells you to click on on "edit source" but lose your changes but it should tell you to use the change to edit sourcecode option which keeps your changes. Where can this be changed. All of this in the German Wikipedia as as above I could not see what the english does.--Saehrimnir (talk) 14:54, 6 May 2014 (UTC)
Hello back, thanks thats what I meant. Is there an easy way to find this other than the asking here? Searching for Visualeditor in the MediaWiki namesspace somehow does not seem to work. Does this mean it has to be changed in each wiki individually? Because I think this is an important information which improves the usability and maybe would reduce the barriers to use VE.--Saehrimnir (talk) 14:05, 7 May 2014 (UTC)
You probably mean that there is not much activity on some bugs and feature requests which de.wp awaits (for example, being able to create a table). But VE has changed a lot since when de.wp turned to the opt-in status (a development which necessarily implies that a lot of bugs are closed ;) ) and I really appreciate you testing it again now. Best, --Elitre (WMF) (talk) 16:21, 7 May 2014 (UTC)
VisualEditor office hour in May
The Wikimedia Foundation's engineering department holds monthly office hours to discuss VisualEditor. Please join Product Manager James Forrester to discuss the products and upcoming plans in May.
If office hours are heavily attended, it can be difficult to get to all questions, but if you want to ask a question and cannot attend or do not speak English, then please let us know your question here by the day before, and someone will add it to possible discussion topics.
In contrary to Chrome, in Firefox (version 29) when I select an entire row (or more rows) and press Backspace it will only delete the last item. For instance try Visual Editor via Firefox on this table. -- Magioladitis (talk) 12:23, 10 May 2014 (UTC)
VisualEditor does not support editing tables at this time. The fact that it manages to remove any rows in any browser is surprising.
The selection in Firefox looks very different from the selection in Safari. I suspect that this is something that will be fixed when tables are properly supported (possibly about six months from now). Whatamidoing (WMF) (talk) 20:47, 10 May 2014 (UTC)
For me, it displays the "thumbnail" in Safari but not Firefox. However, the "thumbnail" is much larger (probably full size), because the wikitext is this:
[[Αρχείο:A Quick Guide to AutoWikiBrowser.pdf|A Quick Guide to AutoWikiBrowser]], George Washington University, 11 Ιουλίου 2012
This is not set to be a |thumb at all, so it's not surprising that it doesn't display them as regular thumbnails.
However, it's not coping with what it's getting. Under Advanced Settings in the image dialog, it says, "Size values are invalid. Could not retrieve original file size." And then it seems to hang: I wasn't able to close the image dialog (so don't try that, unless you're prepared to lose work). I'll file a bug report on this. My guess is that it's something about the pdf files not being standard images. Whatamidoing (WMF) (talk) 21:00, 10 May 2014 (UTC)
According to international experts I summoned, that's a wise user reverting him/herself after something bad happened. ;) Seriously though, looks like yet another case of broken browser plugins injecting weird stuff, unfortunately. Filing this as I'm writing. Thanks! --Elitre (WMF) (talk) 17:01, 12 May 2014 (UTC) Now at 65227. --Elitre (WMF) (talk) 17:23, 12 May 2014 (UTC)
When I click "save" and the window with the summary opens, the cursor remains to the main article instead being in the summary box and if I start typing, my text is written in the article. I have to click on the box first and then start typing. As far as I remember this was not happening before..? Unless if I didn't notice but I don't think it was happening. FF29 W8 TeamGale23:23, 11 May 2014 (UTC)
Thank you both. If it's a problem that appeared in the last weeks and also not consistent probably that's why I didn't notice it. If it was happening all the time I would notice it because I remember typing straight to the box without having to click on it. Now it happens every time I try to safe something with VE. Hope it's not hard to be fixed. Thanks again. TeamGale18:39, 12 May 2014 (UTC)
The edit buttons next to sections used to work, they don't now, they pull up the whole article to edit. Has this been reported? - Dank (push to talk) 16:38, 12 May 2014 (UTC)
While I"m here, I see discussion above about whether VE has reached the point where we should try to push it again. I'm going to stay neutral, but I want to point out a few things: just today, something called the "visualeditor-toolbar-cite-label" got broken, so that the VE toolbar takes up more than a third of the editing screen (with the larger fonts via Ctrl-+, not even counting the lefthand column that's never available for editing). Even when that gets fixed, the VE toolbar will still be much bigger than it needs to be, and the various menus will still take up more than a quarter of the screen, which breaks everyone's PageDown key (and anything else that pages down) ... the toolbar takes so much space that people miss 3 or more lines of text if they page down. On top of that, there's a big "1 notification" popup when VE loads ... and when you click on it, or on the thing it's pointing to, it gives you no idea what it is that's so dangerous that they had to alert you to it before you could edit. I'm not making any comment here about the usability of VE, I use it and like it for some purposes, but the 3 or 4 problems I just mentioned are things that will hit the eye of the casual user in the first few seconds of use, giving VE an "unfinished" look-and-feel, even though it's quite functional for some purposes. I don't think this would be a good time to promote it. - Dank (push to talk) 16:52, 12 May 2014 (UTC)
Dank, thanks for the report about the problem with the citation tool label. It was a problem with the cache in the internationalization system, and it's been fixed.
Can you give me some more details about what you mean with the section editing problem? Section editing has always pulled up the whole article in VisualEditor. It scrolls you down to the section you clicked on (unless you start scrolling before it finishes loading), but it has always opened the entire page.
As for the size of the toolbar, it looks normal for me. VisualEditor's toolbar is almost exactly the same height as the default toolbar in the wikitext editor. Both of them are about 9 mm high on my screen. Actually, the wikitext editor's toolbar is much larger for me, because I always have the "Advanced" tab open. In that situation, it takes up far more space—half the screen, if I max out the font size with Ctrl++, compared to only a third with VisualEditor in the same situation. Whatamidoing (WMF) (talk) 17:37, 12 May 2014 (UTC)
Let's break this down into multiple points, for clarity sake.
The edit section buttons work for me. They always pull the whole article to edit, that's by design - there are several discussions in this page's archives you'll probably want to read to figure out why. Their purpose is auto-focusing on the section you wanted to edit, though: if this is not happening for you, please let us know!
User:Whatamidoing (WMF), User:Elitre (WMF): My bad, I thought I remembered only being able to edit a single section in VE before, but it sounds like that's not possible. The lack of true section editing will be an on-and-off issue in the more collaborative areas of WP, where people are sometimes fussed at for tying up a whole page for too long. If the load and save times for VE can be reduced a little, then people will be more comfortable saving after just a few edits, and my guess is that would mean we won't get much flak from article nominators and reviewers over this issue. - Dank (push to talk)
The label you're talking about's already been fixed. Refresh to check ;)
I can't see any issues with the toolbar. A screenshot would be welcome, see the one I just posted to give you an idea of proportions (it's on Chrome). Is it so different from what you see on your computer? If it is, please provide the following details: browser (and version number), skin, operating system.
Please see File:Screenshot1 of Lamb article in VE, monobook, Firefox.png (Windows 7, Firefox 28.0), and after I hit "Pgdn" once, File:Screenshot2 of Lamb article in VE, monobook, Firefox.png. Note that the VE toolbar takes up enough space that 3 lines from Lamb are missing between the 2 screens, which makes "Pgdn" (and anything else that does the same thing) useless for reading the whole article. Also, the VE toolbar appears to be a lot bigger than it needs to be, both because it takes up 2 lines (if the user has clicked Ctrl-+ at least once, and many do), and because the icons are much, much larger than characters in the article. - Dank (push to talk)
Thanks. I've filed a bug report for the scrolling problem. When you zoom in, do you want it to not zoom in on the toolbar? I believe that's controlled by the browser, but it's possible that something could be done. Would you be happier with a larger default font (the effect you should get from changing the minimum size under Preferences > Font > Advanced in Firefox) rather than a larger everything else? Whatamidoing (WMF) (talk) 22:57, 12 May 2014 (UTC)
I agree with your bug report, I'll add something there. The problem comes from the toolbar wrapping. - Dank (push to talk) 02:06, 13 May 2014 (UTC)
There is no notification routinely showing up when you VEdit. You might see some on particular pages though, for example protected ones. If the warning you got was unclear, please try to remember which article you were editing and tell us so we can check what was wrong there. Thank you for your feedback! --Elitre (WMF) (talk) 17:54, 12 May 2014 (UTC)
Note the big "notification" panel in the screenshots, which appears on many pages in VE ... it seems to be saying that there's something I need to know before editing, but clicking on that panel, or on the "danger symbol" that it's pointing to, doesn't do anything.
I want to be clear that I'm not whining because I think VE is broken; it works fine for many purposes. I'm concerned about the discussion I see above saying that VE is ready to go. If someone using monobook doesn't know anything about VE, and takes a peek to see if they think it's ready, and in roughly 5 seconds they see that Pgdn doesn't seem to work correctly, the bar seems to be bigger than it needs to be, and it seems to be flashing a notification pointing to a danger sign that doesn't seem to be going anywhere, they might stop looking at that point and decide that VE isn't for them. That might inhibit healthy discussion. - Dank (push to talk) 22:30, 12 May 2014 (UTC)
Are you thinking about the formatting of edit notices like the ones on Today's Featured Articles? (See today's.) It should scroll if it doesn't fit on the screen. The formatting (declaring that the icon absolutely must have a column all to itself, instead of having text wrap around it) is the template designer's decision. Presumably the design was settled on before smartphones (and other narrow screens) were common. Whatamidoing (WMF) (talk) 23:04, 12 May 2014 (UTC)
Logging out fixed it, in the sense that I now get text in the notification box telling me I'm logged out ... so there's an actual notification. Thanks. - Dank (push to talk) 02:10, 13 May 2014 (UTC)
VE is actually becoming usable
As a strong critic of the earlier deployment of the VE in its earlier, more or less unusable, state, I've been watching the VE evolve since then. In the time since its withdrawal from public use, it's improved almost beyond recognition. Kudos to the VE team for the improvement.
Given this level of improvement, I think it's probably ready for a cautious public non default beta on enwiki. However, negotiating this with the community first will have to be carried out very carefully, given the bad blood that built up last time. I certainly wouldn't go as far as making it visible to non-logged-in users yet.
Perhaps a place to start might be to put up a sitenotice, for logged-in users only, inviting them to try it out using the beta options preferences? -- The Anome (talk) 13:44, 12 May 2014 (UTC)
There were (very roughly) two kinds of complaints re: VE. That it wasn't ready for prime time. And that real editors don't need WYSIWYG. As you note, the first complaint was valid. The second, seems to me, came more from entrenched habit. So perhaps the message to non-beginners should be that VE is actually becoming usable but is not a source editor replacement--you can't fully participate here with VE alone. Rather, VE is a useful, arguably superior tool for many common tasks: adding material, proofing, and, with the new cite function, referencing. Barte (talk) 14:21, 12 May 2014 (UTC)
I agree completely. Although I'm a very experienced editor, I'm finding the VE useful for making small edits now, and I can see myself using it increasingly often. You are also quite right that full wikitext editing is unlikely to go away for a very long time: as yet, there is no serious alternative proposal for a replacement.
So how do we go about getting a relaunch of the opt-in beta on enwiki? No new software or configuration changes are needed, since the opt-in beta program already exists on enwiki, all we need is to generate publicity for the changes. Is there a way of displaying the notice to, for example, only editors with more than 6 months experience, and only to those using supported web platforms? -- The Anome (talk) 14:28, 12 May 2014 (UTC)
Site notices are fairly ham-fisted things: you can show them to all logged-in users, all logged-out users, or all users. I think that with some CSS magic you might be able to show things to all admins or to people based on what skin they're using, but not to users based on how old their acounts are. I don't know if the geolocation system is enabled here.
CentralNotice over at Meta is more flexible; it's mainly used to schedule things in advance, but I think it can do things like showing only to 10% of users. However, as far as I know, it still can't be set to only reach people with a certain account age, and it will also reach people at non-English Wikipedias that happen to have their language preference set to English. (In all of these cases, you won't see any of these here if the notice is posted only in English and you have selected something else.)
Have you considered a watchlist notice? They are (much) less visible, but they tend to attract attention from more experienced editors. Whatamidoing (WMF) (talk) 16:59, 12 May 2014 (UTC)
Yep, still about one in 5 articles has this problem (and not just at enwiki, but at all major wikis). Importance according to the WMF devs? [11]: Importance: Low minor Open since the 4th of July, but no reason to celebrate...
As for the new reference template dialog: nice, but why did it take a year? It's a simple variant of the "template inserter", with four templates preselected. This could have been done two weeks after the template inserter was ready. Instead, months and months have been lost developing a very complicated cite inserter screen, and in the end the simple solution is implemented anyway. Good result, terrible way to achieve it. Fram (talk) 15:08, 12 May 2014 (UTC)
I've been talking to WikiProject Ships about their very strange multiple-templates-inside-a-table infobox system; we may be on our way to a partial solution (one that would make the wikitext more standard as well). I think that their infobox system would really benefit from a modern re-write, entirely from scratch in Lua, but I don't know how to do that, and there are relatively few volunteers who are interested in that kind of work.
The football-kit problem was just fixed; I believe that it will appear here with the usual update on Thursday afternoon.
Like the football-kit problem, most of the other problems don't result in page corruptions. They just don't look pretty while you're editing, and for exactly the same reason that the football kit hasn't looked pretty. These problems are pretty minor, though: The quote box, for example, shows both of the decorative curly quotes (didn't the MOS prohibit those in articles anyway?) at the end of the box instead of putting one at the start and the other at the end. The location indicator puts the red dot in strange places during editing. As TheDJ told you months ago, the best solution for these would be to re-write those templates to use a far more reliable and robust system for placing the dot. As a side effect of those improvements, it would work within VisualEditor. But that's another thing that requires finding a skilled volunteer with the time and interest for re-writing the template.
As for the citation tool, it is more complex than a simple variant on the template inserter (for example, it has to be able to detect which existing references belong to the citation tool), but even if it had been, the first step was completely re-writing the template inserter itself, and that step alone took months. Whatamidoing (WMF) (talk) 16:50, 12 May 2014 (UTC)
The WMF should never care about the MOS, which is local and may vary. It should make sure that things display as intended, even if they are not MOS-compliant. As far as I understood the DJ, getting it to work in VE wasn't a side-effect, it was the main reason to rewrite these things. And of course, when VE can't handle things like the dot locator used nearly everywhere, volunteers should fix it. Is a bit ass-backwards: paid developers can't get this to work, so volunteers should fix it. A bit like paid developers can't be bothered to test, so volunteers should do it. Or paid developers implement tools in the interface that 10% of the people use (on the wikis where it is the default for a year, not really a resounding success) but volunteers have to add these useful features in the interface that 90% uses. It doesn't look as if the WMF has gotten it priorities right. Fram (talk) 06:49, 13 May 2014 (UTC)
Actually, I don't think that rewriting the dot placing templates is 'the answer'. Sure it needs to happen regardless and the many forms of maps was actually something that we discussed quite extensively during the hackathon last weekend, but even when replaced with a more consistent and proper solution, it would probably still use the same technique to place elements. Having this NOT consistent is a barrier to mobile and VE, but not being able to use absolute and relative positioning techniques is not something that I think should be a goal. What I said is that the technique for coordinates is a problem and the VE 'fix' for that problem is causing the issues with absolute and relative positioning. However changing this requires core software changes as well. —TheDJ (talk • contribs) 09:57, 13 May 2014 (UTC)
The Anome: I'd support a wider beta, sure. And I'm another long-time critic. I'm not suggesting that there aren't signficant issues remaining, but it is probably time that devs get exposed to a little more feedback from a wider range of users. I can now imagine a relatively new editor making an article with this tool that we don't just immediately delete (because references), that is a major step forward. --j⚛e deckertalk16:22, 12 May 2014 (UTC)
Joe Decker: agreed. To Fram and Dank: I'm not suggesting that the VE is in any way yet ready for release to the general editing population, I'm suggesting that it's actually beta-quality at last, and an expansion of the beta to a wider set of users would be a good idea, now many of the bugs that made it unusable pre-alpha quality software last time have actually been fixed. -- The Anome (talk) 18:45, 12 May 2014 (UTC)
I don't think it is ever a good idea to expand VE to a wider set of users, it only encourages the WMF to spend more time and money on it instead of on the more widely used wikitext environment (even where VE has been the default for a year, it still is a clear minority option); and (regarding a complete rollout, which you aren't suggesting) it also is not helpful to require new editors to learn not one but two editing environments, VE and wikitext, which is still needed inside articles (templates and the like) and for all talk pages of course. But that's just my position, it doesn't make your reasoning or arguments invalid. Fram (talk) 06:49, 13 May 2014 (UTC)
In my opinion, we should keep further beta testing of this out of en.wp for at least another half year. I asked at some point if the reduced test group of VE on en.wp was effecting the speed of development and this was stated not to be the case and so I don't really think But I think further more aggressive beta testing in a few other high level Wikipedia's might be warranted. —TheDJ (talk • contribs) 09:57, 13 May 2014 (UTC)
I don't have an opinion either way on the next beta, but I'd like to register disagreement with Fram's comment that the WMF should not be encouraged to spend more time and money on VE. I think it's a priority to get VE to the point where wikitext is truly an option, and is not a required skill to fully participate in the community. One of the goals of VE is to lower the barrier to entry for new editors; when it reaches the point that it is a full alternative to wikitext, that goal will have been achieved, and I think that's very much worth spending time and money on. Mike Christie (talk - contribs - library) 11:58, 13 May 2014 (UTC)
Not the time and money needed to actually achieve this. This would require Flow to be fully working as well (which is a very long way off) and VE to become a lot better (complete), which is also a long way off. All this without much indication that VE indeed lowers the barrier significantly (as it stands, it doesn't seem to be achieving its intended goal on Wikis where VE is the default). Fram (talk) 12:13, 13 May 2014 (UTC)
Some feedback
Some feedback from editing with VE recently:
Great to see that the cite function has been enabled.
Editing an existing ref using the cite dialogs does not consistently work, yesterday I was thrown into the standard template dialog multiple times, today it does seems to work okay — Wouterstomp20:46, 12 May 2014 (UTC) — continues after insertion below
There was a bug with template names sometimes not being recognized, it should be fixed now. It still takes you to the template editor when you double-click the footnote (as opposed to clicking the icon), I think that's a bug as well and have pinged James about it.--Eloquence*00:30, 14 May 2014 (UTC)
Hope to see PMID autofill implemented soon, this should be pretty straight forward compared to ISBN.
The naming and order in the cite dialogs is a bit strange; e.g. when editing a journal citation, the author field is named 'last name' instead of 'author' or 'author last name' and this is one of the last instead of one of the first fields in the list.
A star seems to indicate an obligatory field (in the cite dialogs). However at the same time you can delete them, or insert a citation without filling them out.
It can be quite confusing to have both a cite and insert reference option in the menus. I would suggest to move the insert reference option to an 'other' option under the cite menu.
It should be possible to use an existing reference in the cite dialogs.
Even better would be if existing references would be suggested if you enter one that is very similar to an existing one and likely to be a duplicate. — Wouterstomp20:46, 12 May 2014 (UTC) — continues after insertion below
A bug which seems to have been introduced recently: If you remove any template or image in an article, you get thrown back to the start of the article (at least in both chrome and safari on mac).
When starting the visual editor, I consistently get this annoying '1 notice' popup coming from the exclamation mark on the toolbar, when there actually isn't any notice at all.
Insert special character gives a list which is too long to fit on the screen, leaving both the top and bottom obscured. When that is happening, the moment you open the dialog, your cursor position is not on the screen anymore.
Some dialogs have a "<" in the top left corner to close them (insert special character, insert formula, editing a link), while most others close with an X in the top right corner.
Insert references list should probably warn you when there already is a references list present in the article.
The references list should have some basic options such as for displaying 2 columns.
When the insert media dialog doesn't have any results for your search, there is no indication that this is the case. For all the user knows it could still be searching. A simple 'no results' being displayed would be great (I think I have reported this here before).
Use this group in the reference and reference list dialogs is not self-explanatory, I have no idea what it does at all. — Wouterstomp20:46, 12 May 2014 (UTC) — continues after insertion below
In the languages list of the options menu, as long as editing is not possible right there, it would be nice to simply provide a link to the corresponding wikidata page.
When you change an existing page into a redirect, there is no visual indication of this at all.
When editing a link, the term hyperlink is used, while I think this term is rarely used anywhere else within wikipedia. Better would be internal/external link, wikilink or simply link.
When you remove a line of text using backspace, things are a bit weird when you press backspace when the line is empty and there is a template or image right before that. Instead of first deleting the line and then selecting the image/template, the preceding template/image gets selected first and eventually gets deleted when you press backspace another time.
When selecting a 2-column reference list, a long blue selection block extents below the first column of the list.
Some these points may already be known, but I hope others will help improving VE further. Thanks. --WS (talk) 20:46, 12 May 2014 (UTC)
Regarding the new citation menu
Thank you for adding this, but I can't help but be disappointed by it. I realize there is likely back-end things which are too complex for me to understand as a front-end user, but the current implementation is a far cry from the mockups shown a few months ago. I would love to be able to edit and name references with more consistency, but that simply isn't possible. To be completely honest, the current implementation is barely an improvement from the previous. You don't get a visual "response" until you submit your chosen citation template to the template editor, the Cite feature is simply a dialog, and the fantastic potential displayed in the mockups seems to have gone unused. I really hope this is a simply a stepping stone to a far more advanced version of the reference menu, as this is the one thing I've consistently been annoyed by in VisualEditor.
I'm a huge supporter of VE and use it on around 80% of my non-Talk edits, but the current implementation feels almost insulting given that its been what I've most looked forward to for months now. Perhaps I'm being a self-entitled twat, I've simply found myself waking up on Christmas morning to find coal in my stocking, so to speak.
@Nicereddy: Thanks for the feedback. I'm glad you're looking forward to the proposed improvements, I am too - I'm a designer working on VE tools. When you said you don't get a visual "response", do you mean something like this? Preview of reference when clicked in visual editor We are hoping to implement something like this soon, so that after you finish filling in the fields in the dialogue you get some feedback of what you've added. KHammerstein (WMF) (talk) 20:44, 13 May 2014 (UTC)
This tool is EXCELLENT! The lack of such a tool was the predominant reason I had continued to mainly edit the wikitext. A sincere thank you to the developers for creating this tool! Keep up the great work. –Prototime (talk · contribs) 17:18, 10 May 2014 (UTC)
I second that. Would suggest cite "News" rather than "Newspaper" to be consistent with the template and the range of acceptable media beyond newspapers. Barte (talk) 23:15, 11 May 2014 (UTC)
Plus one to that! So much easier having all the parameters I personally use ready without needing to add them! Saves so much time for me! Thanks! :D TeamGale23:24, 11 May 2014 (UTC)
Barte, I'm not sure why it says "newspaper". I agree with you, and AFAICT, it's supposed to be just "news". This is probably going to take a few days to get fixed, but I'll file a request to have it changed right now. Whatamidoing (WMF) (talk) 23:58, 11 May 2014 (UTC)
Forgive me if this has been discussed, but what's the prevailing wisdom re: named references? The numeric names certainly work if you are using VE. But if you are using the source editor and click on the "Named references" menu, won't the lack of a better description be an issue? That said, the new cite tool is a tipping point for me. I've been using VE on and off, but as of now, I consider it my default editor (where applicable, of course). Thanks to the developers for your hard work and persistence, especially in the face of curmudgeon responses from some of the old guard. (Of which I'm a card carrying member.) Barte (talk) 00:53, 12 May 2014 (UTC)
Yes, it's been discussed. Eventually, the devs plan to add a "name this ref yourself" feature, and, as far as I'm concerned, that can't happen too soon.
But even when they do this, they need to have a system for assigning automatic names to refs, because many people won't notice or care. Furthermore, they need to have a system that will work in 280+ languages, not just in English/for people using keyboards designed for English. (You can easily imagine how inconvenient it would be, if your keyboard didn't have any English letters on it, to discover that the ref you needed to re-use was <ref name="apple" />.) They also wanted something that was unlikely to conflict with a system that anyone was deliberately using. So they settled on a colon and Arabic numbers, because practically all modern keyboards have colons (for the sake of typing http:// or its local equivalent) and nearly all keyboards have access to Arabic numbers.
I'd like them to do something more complicated but more human-readable, like taking the first four characters out of each of two required parameters (assuming the citation uses a template), but so far they've been sticking with simple. Most of this won't matter when they add the "name this ref" feature. At that point, I'll just name the refs myself. Whatamidoing (WMF) (talk) 18:07, 12 May 2014 (UTC)
Thanks for that info. I agree that a name-your-own option would suffice. The need is between editors, not within VE. Within VE, existing citations are listed as they actually appear, which I think is more informative than a ref name. Barte (talk) 19:39, 12 May 2014 (UTC)
This is really quite an improvement, and the guidance on what belongs in each field is great. Bravo!
Are there any plans to continue improving this so that it can match something like RefTools in being able to fill in a title from a URL, access date from current date, quite a variety of fields from an ISBN and/or Google books URL, and so on? Those tools more than halve the amount of work necessary to add a reference in comparison with RefTools, and are as near as I can tell, the only thing that is keeping me from switching to using VE. --j⚛e deckertalk16:09, 12 May 2014 (UTC)
Yes, definitely! ISBN, URLs, PMIDs, and DOIs are all on the list. I don't know what their plans are for the very handy direct-from-Google-Books system, or if they'll replicate the one that decodes The New York Times URLs so conveniently. It might seem too "niche" for them. (Or we might yet convince them that implementing these is not only good, but also cool and fun and worth giving up a weekend for.)
However, I wouldn't expect to see any of this for a few months. I believe that the next sprint is focused on technical debt and bug fixing rather than new features, but they'll get back to this before long. They expect this work to take a couple of months, all told. ISBNs in particular seem to be one of those things that's harder than it looks. (I'm not an expert in this, but from listening to the devs talk about it, it sounds like if you want to have this work for non-English books, then you have to do a lot of extra work, because most of the ISBN databases seem to be country-specific. And while there's code to use as a model for English ISBNs, there's nothing for nearly all of the other languages. This is because autofilling is really only an en.wp thing. Changing that is one of their major goals.) Whatamidoing (WMF) (talk) 17:50, 12 May 2014 (UTC)
Thanks for the feedback! I've been working on plans to streamline the cite web workflow to pull title, date etc. from URLs. You can check out a pdf here. KHammerstein (WMF) (talk) 20:34, 13 May 2014 (UTC)
I feel an "advanced" or "other" option, leading into the standard reference dialog, is needed, since the new "Cite" menu is more visible than the standard reference button (hidden in the Insert menu), and new users could get confused by the lack of options when trying to add a new reference, since the options are fairly limited:Jay8g [V•T•E] 01:23, 13 May 2014 (UTC)
Jay8g, do you want that option to be in the Cite tool's menu, or after you've opened up (say) Cite > Web and decided that you really wanted Insert > References?
(If you're looking at an existing citation, you can select it and Insert > Reference will always open it in the standard form, even if it could be opened by the simpler Cite tool. But that's not so convenient when you've already got the simpler one opened.) Whatamidoing (WMF) (talk) 15:59, 13 May 2014 (UTC)
Putting the normal "Reference" dialog at the end of the "Cite" tool has already been considered and rejected. Apparently it makes things even more confusing for editors (or at least for first-time editors, which is one of their formal testing groups), because one item does something different from the others. But I'll ask again, because I think that if it were labeled correctly (maybe "Advanced" or "Manual" instead of "Reference") that the confusion might be reduced. Whatamidoing (WMF) (talk) 17:00, 14 May 2014 (UTC)
Last night I removed some content from Punk Goes 90s 2, including an {{album ratings}} box that used a reference also used in the article body. It wasn't clear whether the ref was defined in the template or in the prose, so I ended up accidentally removing the instance where it was defined, and had to go back and restore it using the old editor. Here's the diff; the ref is called "AltPress review". Is there anything I've missed that would have allowed me to distinguish between the instance where it's defined and the instance where it's invoked? If not it'd be great to see a fix for this (maybe with list-defined references?). Otherwise I'm liking the new referencing setup and looking forward to future improvements, keep up the good work. – Arms & Hearts (talk) 17:59, 14 May 2014 (UTC)
The problem arises because the citation is defined inside the template. VisualEditor can't "see" references that are inside templates. This means that you can't edit the reference with Insert>References. If the citation were only present in the template, you would not be able to re-use it. (If it's already been re-used, then it can be re-used, but VisualEditor won't be able to show you the citation's contents, only the fact that one named "AltPress review" already exists.) And, unfortunately, if you delete the template that contains the citation, then VisualEditor can't "see" that there is a citation that needs to have its contents copied out.
I think that the devs know that this is problem, but I couldn't quickly find a bug report for it, so I have created T67301 to make sure that it gets tracked. From listening to their explanation of the problem, though, I don't think it will be possible to fix it very quickly. :-( Whatamidoing (WMF) (talk) 19:05, 14 May 2014 (UTC)
VE apparently can't handle ref 4 in FLAG-tag, which is an URL with {{full}} added at the end. In VE display, it gives empty square brackets, and in ref editing mode, it is an element that can only be edited in source mode... Fram (talk) 11:33, 15 May 2014 (UTC)
Thanks for telling me about this interesting issue. If you add a space between the two elements (the bare URL and the template), then it works fine. I think that the problem is that there is no obvious separation between the end of the URL and the start of other text. Curly braces are not permitted in URLs, but from the results here, the disallowed characters might be getting processed differently. It's T67362 now. Whatamidoing (WMF) (talk) 19:02, 15 May 2014 (UTC)
Once in a while I try VE again and did so lately in the German Wikipedia and it was quite nice so I think you are really getting there. Unfortunately on en whenever I tried in the last month it failed to start at all every single time. I did not have any time to look before and now after I did I only got an Indication that some kind of configuration might be required but did not find what. Using latest Java Firefox and Windows 7.--Saehrimnir (talk) 14:46, 6 May 2014 (UTC)
p.s.:Spanish and French doe work fine too.
I was having problems in Firefox yesterday, too, but only on some pages. I'd try to open them, and it would start, but then not ever get all the way open. Would you mind clicking on Special:Random several times and seeing if you can get any pages to open at all? Whatamidoing (WMF) (talk) 22:10, 6 May 2014 (UTC)
I tried several pages and on all of them the same it appears to be bussy loading showing the flashing bars but nothing further ever happens.--Saehrimnir (talk) 13:47, 7 May 2014 (UTC)
I've filed a bug report. I don't know if it will do any good (we can't give them a lot to go on here), but at least they'll know about it. Whatamidoing (WMF) (talk) 19:26, 15 May 2014 (UTC)
Internet Explorer is blacklisted, but there exists a way for it to show up on IE
Although Internet Explorer is blacklisted, there still exists a way to get the button to show on IE (desktop, not Modern).
Steps to Reproduce:
First, open a standard Wikipedia article in the article namespace. Then, resize the window to a very small size so that the buttons overlap to the next line. Finally, resize the window to the original size and see that the "Edit beta" button shows up, which was previously not there.
Results:
The "Edit beta" button shows up under IE after following the above steps.
Expectations:
Only the "Edit source" button should show up at the moment until IE support is fully implemented.
Thank you for this very interesting bug report. Can you tell me whether the "Edit beta" button works (that is, if it tries to open VisualEditor when you click on it)? Please make sure that you've saved everything before you try that, because, if it does "work", it might cause Internet Explorer to crash. Whatamidoing (WMF) (talk) 23:13, 12 May 2014 (UTC)
User:Whatamidoing (WMF): When I click the "Edit beta" button, it loads, but gives me the following error:
Error loading data from server: novenamespace: VisualEditor is not enabled in namespace 4. Would you like to retry?
It gives me two options, OK and Cancel. Clicking OK closes this dialog, but immediately pops up another one of the same kind. Clicking Cancel cancels the action. Gparyani (talk) 03:03, 13 May 2014 (UTC)
Thanks for this very useful information. I've already talked to the developer about this, but I filed T67292 so we can keep track of it. They won't know how long it will take to fix it until they understand the exact nature problem. Whatamidoing (WMF) (talk) 16:55, 14 May 2014 (UTC)
Update: This problem is actually with the Vector skin and is unrelated to VisualEditor (except that VisualEditor happens to be the tab that you noticed the bug affecting). Whatamidoing (WMF) (talk) 19:16, 15 May 2014 (UTC)
In Polynoidae, I can't edit the contents of the long list of genera. The recent fix that redlinks are finally shown as redlinks in VE also doesn't work here. Fram (talk) 11:36, 15 May 2014 (UTC)
FF29, W7. I see the template with the content, break, content and so on, but all are empty. I haven't tested if I can add anything, as long a sI can't touch the existing entries it is rather pointless to add new ones inbetween. Fram (talk) 14:41, 15 May 2014 (UTC)
Hmm. So it's browser specific. When I use Firefox, I don't see the list either. In Chrome, I can alter the contents as well as add new. I'll check back - if this hasn't already been reported, I'll make sure it is. Thanks, User:Fram. :) --Maggie Dennis (WMF) (talk) 15:24, 15 May 2014 (UTC)
@Fram and Mdennis (WMF): Yes, there's a minor (irritating) issue in Firefox of it not expanding the long list of wikitext in "content" sections until you click into it – thanks for the spot. It's familiar from a similar issue we had with Firefox, caused by a browser bug. We should get that fixed. However, it was possible for me to change the content blocks once I'd clicked into them in Firefox. Or had I missed something else that was wrong? Jdforrester (WMF) (talk) 18:16, 15 May 2014 (UTC)
You don't get anything in the first content box, because it started with an empty column. There's nothing "there" in wikitext, either. I've replaced these templates with something that will work better on different screen sizes, but this will doubtless be an issue for many more articles. You'll still see an empty first line in the transclusion editor, because the first bullet point is not on the same line as the template, but when you click inside (or use something other than Firefox), you'll see the content. Whatamidoing (WMF) (talk) 19:13, 15 May 2014 (UTC)
I hadn't tried clicking inside the content boxes (and I guess many editors won't), good to know that at least that workaround exists. Thanks for the feedback. Fram (talk) 06:21, 16 May 2014 (UTC)
When you put your cursor inside a bluelink (in VE) and type, the text gets included in that bluelink (like you would expect). But this doesn't work when you use "insert special character", it splits the bluelink and adds the special character as an unlinked (black) character. It is not that Wikipedia doesn't support these, e.g. typing a "ç" from my keyboard works, but inserting it from the special character menu gives the above problem... Fram (talk) 09:29, 19 May 2014 (UTC)
Is there a way that VE could allow me to use a cite template without reference tags, like so: Mick, Kenneth (2012). My First Book. Me Publishing.? This is very handy for working in "Further reading" sections. Currently, with the references toolbar, you cannot do this either, but as you work in wikitext, it takes all of five seconds to remove the "<ref>" tags. As far as I know, I cannot do this in VE.--¿3family6contribs14:29, 21 May 2014 (UTC)
Simply use the "insert template" and choose which cite template you want! But you are right that VE has no way to convert a ref into a non-ref cite template (e.g. often used for "further reading" sections, in case anyone wonders why we would need this) Fram (talk) 14:37, 21 May 2014 (UTC)
I don't think that it's possible at the moment, which isn't a big problem now (just Insert > Template), but it may be irritating when the Cite tool has autofill and Insert > Template does not. It should be possible to copy and paste a template out of the Insert > Reference box; that would give you a process of (eventually auto-)fill in Cite, open in Insert > Reference, copy the template out, close the dialog, remove the reference, and paste in the copied template. Not elegant, but it will work. However, right now, I can do that in Firefox but not in Safari. I'll file a bug report for it. Whatamidoing (WMF) (talk) 15:56, 21 May 2014 (UTC)
Hi I just wanted to exchange the filename of a picture with another, because the copy at commons has a different name. But there seems to be no option to do that. Or am I not looking in the right place?--Saehrimnir (talk) 03:22, 22 May 2014 (UTC)
Thanks for your note. You are correct: it cannot be done yet. It's on the list of things that the devs would like to do. As far as I can tell, nobody has started work on that yet, so it is hard to predict when it might be done. However, the dev who has been doing most of the image-related work is wrapping up a big project, so it's possible that she'll be able to deal with this request as early as next month. Whatamidoing (WMF) (talk) 18:05, 22 May 2014 (UTC)
I had noticed this occasionally recently, but thought it was an editor error. But considering that this happens so often, and to different editors, and to one editor at teh same page multiple times, this is no longer plausible (or it indicates at least a serious problem with the VE interface if it does). More likely, these vowels are added by the system for no good reason at all. Fram (talk) 13:35, 21 May 2014 (UTC)
This MAY have happened to me, though my memory here is quite fuzzy. I think that at one point when I was creating an article, the cursor ended up going to the top of the article. In this case, I was able to catch this and delete the change before I saved the article. It was either a letter, or a blank space, that I typed. Either way, my point is that sometimes the cursor jumps to the beginning of the article. I don't remember what I was doing when this happened, though.--¿3family6contribs14:10, 21 May 2014 (UTC)
It's a known bug, and it's not just vowels (although it's more commonly seen with vowels, because we type them more often). I've forgotten the details and the bug number, but I believe it only happens in Firefox. Whatamidoing (WMF) (talk) 15:05, 21 May 2014 (UTC)
It has been reported on frwiki 2 months ago... Any chance to see it fixed in a near future ? I would have hoped that bugs damaging articles would finally get some attention from VE team... Some of them are picked up by an abuse filter, it happens several times a day... --NicoV(Talk on frwiki)08:54, 22 May 2014 (UTC)
People keep adding unwanted nowikis, e.g. [18][19]
VE keeps unnecessarily changing the look of reference names, e.g. [20][21] (adding quotes, spaces after the slash); note also how the interwiki links are put on one line; the same sometimes happens with infoboxes as well
People keep accidentally removing section headers, e.g. [22] by removing a block of text above the section header
People have difficulty layouting, e.g. getting too much into a link, and bolding a header[23]. An attempt to solve the header makes it only worse[24], forcing the editor to abandon VE and use traditional wikitext editing instead[25]...
Adding a logo doesn't work in VE[26], so editor has to switch to wikitext editing[27], defeating the purpose of VE of course.
Most of these are well-known, basic issues, which are still present and indicate rather fundamental issues with the way VE works and fails to match its goals. The Ref name thing is not relevant for this, it's just an old bug which still remains but is of less importance. Fram (talk) 14:19, 21 May 2014 (UTC)
There's a known bug about correcting the spacing and quotation marks on lines that aren't being edited.
Some of these are simply not knowing or using the tools that are available. For example, Jared could have used "Clear formatting" on that section heading. On the last item, the logo is in a template. There is nothing "visual" about the process of adding a picture to an infobox. The editor got the wikitext that he added, and the correction (manually correcting the wikitext) is the same in both editors. I think that as people have more time and experience with VisualEditor, most of these problems will reduce significantly. Whatamidoing (WMF) (talk) 15:18, 21 May 2014 (UTC)
Bug 53613 will reduce the problems with adding images inside templates.
I think I need to file a bug on reformatting ref tags that are inside tables; I can't find one. Putting all the interlanguage links on one line may be the same bug as putting all the cats on one line. I believe it's a Parsoid problem; I don't know if a bug exists for it. Whatamidoing (WMF) (talk) 18:29, 22 May 2014 (UTC)
The deployment underway now is fixing a problem with the "beta notice" that all users receive the first time they open VisualEditor. As an unforunate side effect, it will re-display the notice (which still hasn't been updated to include information about switching to wikitext) to everyone one more time. However, this will solve problems with re-re-re-re-re-displaying the notice for people who edit from public computers or clear their cookies regularly. Whatamidoing (WMF) (talk) 18:44, 22 May 2014 (UTC)
Things hidden beneath the left side navigation bar?
When I open Harton, North Yorkshire with VE, the coordinates disappear, only the very end of it ("55'W") appearing on the left side of the VE screen, between the text and the stub line, as if the rest of the coordinates is hidden behind the left side toolbar. FF29, W7. Fram (talk) 09:23, 19 May 2014 (UTC)
Hi Fram, do you know when this problem first appeared? They just changed some things about CSS positioning, and it's possible that the fix for one quirky template broke another. Whatamidoing (WMF) (talk) 17:35, 19 May 2014 (UTC)
No idea when it first happened, I only occasionally open articles in VE, can't stand it for any prolonged period of time (I'm someone who uses the arrow buttons to navigate in pages and text. Very frustrating when you do this in VE. Raised the bug months ago already. No improvements, no action taken as far as I can tell). In [28] the coordinates appear for me on top of the first line of article text (starting at the "A" of "Mount Allen"), making it rather strange and ugly. On Quedas do Iguaçu it still appears at the bottom, hidden beneath the left side toolbar. And on Polydendri, Thessaloniki, it appears in the top right corner of the infobox. Like they say, it's all over the place, but never in the right spot sadly... Fram (talk) 19:25, 22 May 2014 (UTC)
Focus should be on the edit summary box when you click save
The edit text box should be active and in focus when you click "save page", because it's the next thing the user fills out. Clicking on the box takes an extra step. Doing this would also encourage users to leave edit summaries. Albany NY (talk) 02:01, 24 May 2014 (UTC)
Use scrollbar in the link insertion dialogue to view more possible link targets
Steps to Reproduce:
Bring up the link dialogue for any word with many possible links -- e.g. "Texas". A scrollbar will appear on the right of the list. Click on the scrollbar to scroll down.
I've recently started using VE for creating articles, which I hadn't tried before; I've found it so much easier and quicker than wikisource that I don't expect ever to create an article with wikisource again. I ran across a couple of minor bugs which I've reported above. I did also see a couple of examples of strange behaviour which I think is linked to losing connection in the middle of an editing session; if I can reproduce those I'll post a note here.
I have a couple of interface suggestions, neither very high priority. First, the link suggestion dropdown is a great tool, but I sometimes find myself baffled by the fact that the order is not what I expect. It comes up alphabetically, but as far as I can tell, dab pages and redirects are usually at the end. This isn't always what you would expect. For example, I recently had to link Texas Rangers, and was surprised to discover that there was no simple "Texas Rangers" link at the top of the list. It turns out that that's a dab page, which is reasonable, but I still think it should have been top of the list, with a note. Redirects, I think, should be sorted in to the list in alphabetical order too, but it should be possible to see that they are redirects, and more importantly to see what they redirect to and choose that as a target.
Second, and I'm sure I'm not the first person to suggest this, when adding a field to a template, it would be nice if the dialog didn't automatically jump to the top of the field list. E.g. in cite news, the "page" field is not present by default; when I go to the "add another field" button and add it, the dialog scrolls back to the top. It would be far more sensible to scroll to the bottom.
Hmm. The very next time I went to the cite news template and added a page field, it behaved exactly as I requested it to in my post above. Either there is a team of programmers here instantly implementing my requests, or this is intermittent behaviour. If I figure out what causes it I'll post a follow up note here. Mike Christie (talk - contribs - library) 14:44, 26 May 2014 (UTC)
Hello there. Thanks a lot for giving VE such a great try again! (Although we do recommend that you keep editing Wikisource ;) ). As for the link suggestion, I discussed this often with James and turns out that this is not really due to VisualEditor, but to the new search engine. So VE has a related bug but I think I was told that's just a reminder of something VE suffers from, but the team probably can't do much about that. As for the second thing, the cursor jumped at the bottom of the list for me as well. Have fun with VE, --Elitre (WMF) (talk) 15:49, 26 May 2014 (UTC)
DEFAULTSORT and categories for article creation
Hi, apparently, when creating an article, VE (sometimes ?) put the DEFAULTSORT after the categories, and then put new categories after the DEFAULTSORT if you edit again the article. Could it stay consistent and keep DEFAULTSORT before categories ? --NicoV(Talk on frwiki)14:58, 26 May 2014 (UTC)
Hi Nico. This doesn't sound familiar to me, so I'll ask James about it - I'll file a bug then if he tells me to. Thanks! --Elitre (WMF) (talk) 15:52, 26 May 2014 (UTC)
No idea about this bug, but I do notice (in preview, don't want to save my tests) that when you have e.g. cats and then stub templates, that any nw cats are added after the stub templates in VE. And in another test, I added a cat and changed a defaultsort at the same time, and the defaultsort was "added" at the bottom, without replacing the old defaultsort. So it seems to me that NicoV's report is correct (as usual), and that there is a lot more wrong here as well (also, as usual). Fram (talk) 16:11, 26 May 2014 (UTC)
As far as I can tell, it's not possible at all to specify in VE that you want to substitute a template. This makes VE useless for various maintenance tasks, such as tagging a redirect with {{rfd}} (what I was trying to do). Am I wrong? — Scott•talk13:18, 24 May 2014 (UTC)
Thanks - most of VE's features are self-explanatory to the point that I haven't needed to look at the guide while using it, but that's non-obvious and surprising. I'll look forward to seeing a checkbox appear in the interface. — Scott•talk17:33, 26 May 2014 (UTC)
I'm pretty sure that this was reported (and possibly fixed) months ago, but I couldn't find it today. I've filed T67647, with the expectation that it will ultimately get marked as a duplicate, but at least the devs will hear about it. Whatamidoing (WMF) (talk) 18:18, 22 May 2014 (UTC)
Thanks. I think this came up a while ago as a Parsoid problem (but perhaps ony for new ones?) and has reappeared, probably due to a new bit of brokenness. Whatamidoing (WMF) (talk) 22:54, 23 May 2014 (UTC)
Yes, it was happening (and probably still happening for new categories), but never seen for existing categories. An other example, that also shows other recurring problems with VE that have been reported months ago: extra characters at the beginning, and strange characters ☃☃. --NicoV(Talk on frwiki)08:11, 24 May 2014 (UTC)
Thanks for adding that link to the bug report. I'd guess that the ^ at the top was a spellcheck correction. The snowmen are a problem with a component called "ContentEditable", maybe(!) related to character formatting. Whatamidoing (WMF) (talk) 18:48, 26 May 2014 (UTC)
Something similar was already reported and fixed in the past. I can't know whether it's exactly the same case, so I'll ask. --Elitre (WMF) (talk) 11:31, 27 May 2014 (UTC)
HTML tags (<strong>...</strong>, ...)
Hi, I have the feeling that recently, more articles modified with VE have HTML tags like <strong>...</strong> (example) instead of classic Wiki formatting. Could VE try to keep with MediaWiki syntax instead of adding more HTML formatting in wikitext ? --NicoV(Talk on frwiki)17:36, 26 May 2014 (UTC)
That diff has been deleted. Can you find out whether it was deleted as a copy-paste copyright violation? It's the nature of rich pasting that it would copy the HTML formatting from the source, and be capable of differentiating between <b>...</b> and <strong>...</strong>. Whatamidoing (WMF) (talk) 22:36, 26 May 2014 (UTC)
It was a copy-paste copyright violation. I don't see why VE keeps all the formatting from the source: there's almost no real life case where we would like to keep all the formatting of the source, because it has no reason at all to be formatted like articles are usually formatted on Wikipedia. Pasting all the formatting tags like <strong>...</strong>, <em>...</em>, ... is unnecessary, and rather counter productive, because either we have more work to clean up this unwanted formatting, or we end up with articles having different looks and wikitext unnecessarily complexified. --NicoV(Talk on frwiki)07:13, 27 May 2014 (UTC)
If we are able to detect a copy paste from an external source (I assume, that is possible, due to missing VE classes and data/rel attributes), we might wanna ask the user. "Do you want to paste with or without formatting". Just a thought. —TheDJ (talk • contribs) 08:25, 27 May 2014 (UTC)
TheDJ, yes maybe. I'm just thinking that all formatting doesn't need to be treated the same way: bold, italic, subscript, ... seems rather ok in general ; more advanced formatting is usually not (colors, font, ...) ; some may be replaced by wiki syntax (strong becoming bold, em becoming italic, ...). So, I don't see how to explain that to the basic user, and let him choose... And I fear that many newbies will choose "with" formatting (because "without" is not appealing) when in 99% of situations they should have chosen "without". --NicoV(Talk on frwiki)09:26, 27 May 2014 (UTC)
You can do a plain paste, but I'm not sure that most people will bother, so long as it looks about right. The HTML tags can be removed with "clear formatting".
As for "translating" it, I recall one of the accessibilty experts opposing treating <i>...</i> and <em>...</em> as identical, een if they look the same to the average user. Whatamidoing (WMF) (talk) 19:26, 27 May 2014 (UTC)
Adding footnote gives confusing feedback to the user
I just added a footnote to Jan Chapman on en.wp using the new citation system (very nice work, by the way). However, when I filled out all the info and clicked "apply changes" there was confusing visual feedback about whether I'd inserted it correctly (or indeed at all). That is, the information I'd just input and submitted did not appear in the "references" section even though a "[1]" appeared in superscript in the correct place. This was confusing because mousing over that "[1]" higlighted the footnote was *previously* number 1 in the References section. I assumed that my content had not been saved and perhaps that the pre-existing footnote had mysteriously moved itself up to where I was trying to create a new one. I cancelled, did it all again, to the same result. This time i saved the edit anyway and the result produced a perfect footnote exactly where I was hoping it would. So - the issue is not with the coding of the footnote system but the user-feedback it produces. Wittylama05:34, 27 May 2014 (UTC)
This only happens on pages that use {{reflist}} instead of <references />. It is not possible for VisualEditor to update the contents of a template based on input to other parts of the page.
Would you like something like a "Your citation was added" box, similar to the "Your change was saved" box that appears when you save a page? Would that help? Whatamidoing (WMF) (talk) 19:31, 27 May 2014 (UTC)
Template:R from move not removable when overwriting a redirect
Bug report
VisualEditor
Mito.money
Please app{}
Intention:
Tried to overwrite a redirect with an article
Steps to Reproduce:
Open an article that is a redirect from a move in Visual Editor. Uncheck the redirect checkbox and then enter the text of the new article.
Results:
The R from move template remains visible, and as far as I can see it can't be deleted.
Expectations:
I wanted to be able to remove the R from M template.
As it happens, I am getting the alert notice on every single VE edit, which I assume is a temporary situation. This revealed what may be a separate issue: the redirect checkbox dialog comes up before the VE "you are using a beta" alert. Presumably it should come up afterwards instead.
Hi there, Mike. As for the beta dialog, James noted that with last week's update it is now hidden for logged-in users using a user preference rather than a cookie; it will show up one last time for all logged in users on their next use of VisualEditor, and then go away entirely. As for the R template issue, as you can check from your sandbox' history, all my attempts were fruitful - I have your same setup. The first time I deleted it by placing the cursor below it and hitting Back Space; the second one instead, from the line above and using Del. The third time I clicked elsewhere and then clicked on it again so that the puzzle piece icon showed up; at that point, hitting Del worked. My guess is that the focus isn't really on the template initially, although I can see it's blue. Will ask James tomorrow, if nobody already knows the answer. Thank you for stopping by! --Elitre (WMF) (talk) 15:13, 26 May 2014 (UTC)
Thanks for testing this. I tried again following your suggestions and discovered that I can delete it in a couple of ways. I guess the only issue is that if you uncheck the redirect box, the template is highlit but there's no puzzle piece; I didn't try clicking off it and on it, which did work. Re the VE dialogue, I do have the user preference set, but I get the dialogue every time. Is there a way to turn it off? Does it see a cookie I don't know about? Mike Christie (talk - contribs - library) 15:25, 26 May 2014 (UTC)
I get the welcome screen on every page I open with VE, so that update doesn't seem to work as predicted. In other news, bears... Fram (talk) 16:12, 26 May 2014 (UTC)
In theory, WP:BYPASSing the cache shouldn't matter, because the point of the change is to make it not dependent on cookies. You should see it (and I have seen it) exactly once (per account/per project, so in my case, about six times each in both Safari and Firefox) and then never again. Fram runs Firefox on Windows 7. I've got a Mac. I think Elitre runs Chrome on a Windows box. Is anyone else having this problem, and if so, could you tell us about your browser and computer? Does it happen to you if you open a sandbox at MediaWiki or a random artcle at the French Wikipedia a couple of times in a row? Whatamidoing (WMF) (talk) 18:56, 26 May 2014 (UTC)
I too have been seeing the notice over and over and over and over. I checked this here and at MediaWiki, an different pages and reloads of the same page. This is new since Thursday, when the system changed. Before that, I got it just once per browser restart. Firefox 29, Windows 7:Jay8g [V•T•E] 00:35, 27 May 2014 (UTC)
While editing Klein Bikes, which has a large transcluded section at Template:Klein model history with both refs and notes, in the VE, the order of the refs was confused, and the Notes section was garbled, although the actual edit is fine. See screenshot.
Thanks for the note. This is a known problem, and apparently very complicated. Unfortunately, the word is that it's not likely to be fixed any time soon. I'm sorry about that. Whatamidoing (WMF) (talk) 00:49, 29 May 2014 (UTC)
When you have a template without template data (i.e. the majority of templates), this displays hidden comments behind each parameter as info in VE. Nice, but... (checking Template:Infobox UK place)
A return in the comment means the end of the info, e.g. "area_total_km2"
Multiple comments will only show the first one in VE, e.g. for "Static image"
A | in the comment means the end of the info, e.g. "population_density"
No hidden comment means a strange flat white box as info, e.g. "os_grid_reference"
When there are hidden comments in the infobox doc, they appear in the field in VE. E.g. Jackson Township, Harrison County, Indiana (which I had to open twice, first time just kept on going...) has in the infobox in VE, in the field "Image_seal", the text "<!-- Maps -->"; in "Motto", it has "<!-- Images -->"; this is very confusing, to say the least. Fram (talk) 13:49, 27 May 2014 (UTC)
Open any article using the template, and you'll note the problems in the infobox (when opening it to edit it, not on simple display). Take e.g. Aberystwyth, open in VE (close the very, very annoying "welcome" screen which still appears on every single page I open in VE), open the infobox, click in a parameter field, and then click the "i in a circle" at the top right of that field. I have indicated above which fields display the problems, and I have given the reason for it (not the technical cause), like "no text", "a pipe symbol in the hidden comment", and so on. So it isn't caused by template vs no template data, that may be true, but the end result is the same, you get a lot of "wrong" information. Fram (talk) 07:14, 28 May 2014 (UTC)
I opened the recommended article, and here's what I found:
"area_total_km2" wasn't in the infobox, so I added it. The help/information button (i with a circle around it) displays the description that is in the TemplateData, word for word, letter for letter, in its entirety.
"static image" was also not present, so I added it. There is only one item in the description for this parameter. It correctly displayed only the one description. (I'm not sure that it's even possible to have multiple lines in these descriptions, because the TemplateData is so brittle.)
"population_density" was also not present, so I added it. There is no pipe in the description for this parameter. It displayed correctly.
There is no description in TemplateData for "os_grid_reference" (which is present in that article), so the description box is empty. I can file a request that empty descriptions not offer empty boxes. (Update: This is now T67862.) Whatamidoing (WMF) (talk) 17:27, 28 May 2014 (UTC)
I have an update on Bug 65862: The TemplateData description for that parameter is " " (one space), rather than "" (nothing), so it's displaying the (white)space. The devs talked about it today, and will suppress stray spaces (which means everything, in this case), since getting a "description" of one (invisible) space is not very useful to the user. Whatamidoing (WMF) (talk) 18:45, 30 May 2014 (UTC)
Modification of internal links
Also posted on frwiki, but it tends to get less attention, so posting it also. Is there any plan to handle correctly internal link modification in VE some day? By correctly, I mean that VE would behave in a way that doesn't lead new contributors to do awful modifications, like in this example (damaged link, incorrect selection, nowiki, ...) --NicoV(Talk on frwiki)17:20, 26 May 2014 (UTC)
There are several discussions and bug reports scattered on wikis and Bugzilla about links, and I can't recall right now if this is really a case which wasn't covered at all before and if it isn't somehow caused by the user. Any help with that is appreciated, before I get the chance to ask James like I will for the other case reported below. --Elitre (WMF) (talk) 11:48, 27 May 2014 (UTC)
Thanks Elitre. My report is more about VE ergonomy on links modification than on a "bug": I just think that VE ergonomy is not obvious in this situation for novice users, and they end up doing this kind of modification, which is clearly not what they intended to do. VE should be more obvious so that the usual situation is easy to do, and shouldn't require the user to be extra careful (a new contributor won't be) on what characters he really selects. --NicoV(Talk on frwiki)12:05, 27 May 2014 (UTC)
I agree with you and James that the easiest solution here might be to tweak the link inspector. There are proposals like Chris' one for links, but that looks "too heavy", so we'd be very interested in hearing ideas from anybody on this subject. --Elitre (WMF) (talk) 14:45, 2 June 2014 (UTC)
I don't know if this is a known problem and I'm not good enough at navigating Bugzilla to work it out, so apologies. I'm finding that when I've just uploaded an image to Commons the "insert media" menu takes an unreasonably long time to acknowledge the existence of the image, so it's not possible to add it to the page I'm working on. I never really upload files locally so I don't know if this would also apply in that situation. Right now, File:Doug Heckman.jpg was uploaded a little over ten minutes ago but doesn't show in the menu. Perhaps it'd be useful if the menu were to have an option to enter the exact file name in addition to being able to search for files? – Arms & Hearts (talk) 13:30, 1 June 2014 (UTC)
I believe this is due to the new search engine rather than to VE. Will verify this though. Thanks for your feedback! --Elitre (WMF) (talk) 14:51, 2 June 2014 (UTC)
That may be true, but in wikitext, you can add any filename you want, while in VE, you can only add files that VE finds, making this not only a search engine problem but also a VE problem. Something different: how can one add commented-out files (e.g. non-free files in a user sandbox)? Typing in the filename, and then? We are not allowed to add wikimarkup, thanks to the infinite wisdom of the eloquent devs, and I can't find another method to do this. By the way, now that we are busy: the rather unwanted "make full size" button in advanced file options (when does one ever need that one?) doesn't work when you click it once, this just changes the "default" size to the "custom size", only when you click it then a second time does it really add the max size... It's also rather strange that, when coming back from the advanced settings, the default focus seems to be on "alternative text" and not on "caption", even though caption is the first and most often used option. Fram (talk) 15:22, 2 June 2014 (UTC)
Why would you want to add a commented-out file? Presumably it will be possible when hidden HTML comments are supported, but what's the specific purpose of adding a file name that way? Commons de-linker bots mark pre-existing, but now deleted, files that way, but normal editors basically never add a new file name in hidden comments. Whatamidoing (WMF) (talk) 19:39, 2 June 2014 (UTC)
Non-free files in a user sandbox. Like I said above. Just the same way that people add commented-out categories in their sandbox. In wikitext at least, I doubt it can be done in VE as well... This is not the same as adding, editing or showing hidden comments, which is also needed and wanted; a hidden comment is hidden, a commented-out filename or category name (by adding a colon after the first double square bracket) is visible in text format. Fram (talk) 08:33, 3 June 2014 (UTC)
A few more caveats: when I open your page in VE, the commented out file link is a redlink, not a bluelink, even though it is a correct link. And when I add afile in this way and try to access it, I often get "Bad title" due to the double colon. But , like you said, not always... no idea why he adds the file name after a pipe as well, isn't really necessary either. But thanks for finding a way to do this, it may help the devs to implement this correctly. Fram (talk) 13:42, 3 June 2014 (UTC)
Fram, when you asked for a commented-out file, I thought you meant a <!-- commented out file --> instead of a link to a file name. Links are links: see here. Type the link you want (including the colon), open the link inspector, and add it. Erica, if you manually correct the double colon in the link inspector, the double colon goes away. It won't look like it is corrected, but the wikitext is corrected. Whatamidoing (WMF) (talk) 17:33, 3 June 2014 (UTC)
Now try a different way to include a link, which normally works (and is to me more intuitive and less work); place your cursor, use the "link" icon, and start typing what you want to find. When you use a pagename, you'll get no problem. When you use a filename, you'll find it, get some colons, and when you think that you have finally added it, yuo end up with... nothing. Not a file, not a colon-preceded file, nothing. All links are equal, but despite your claim, files are clearly less equal. Fram (talk) 20:51, 3 June 2014 (UTC)
(edit conflict) Do you mean that I also wouldn't be able to find the image if I were to search for it through the main search rather than the VE menu? If so the problem is still specific to VE because (to my knowledge) VE only allows you to add a file to an page by searching for it rather than directly entering the file name. If there was a way to add a file by inputting the file name directly then the slowness of the search wouldn't be such a problem. – Arms & Hearts (talk) 15:26, 2 June 2014 (UTC)
That's how galleries work (and bypassing the search, adding Heckman's pic that way works, for example). So there's a bug requesting the ability to change the file name for an already existing picture to replace it, for example - I can't find one which suggests that this should be done also when adding an image for the first time. There's also a bug suggesting that the 2 dialogs should be merged, but I don't know what this would imply. As I said, I'll ask James when I can. --Elitre (WMF) (talk) 16:18, 2 June 2014 (UTC)
Yes, right now, if you can't find the image by searching for its file name in VisualEditor, then you also won't be able to find the image by searching for its file name with the regular search box at Commons. They're using the same search system. (The new search system should have fewer instances of this, but it's still not getting everything instantly.) I know this has been discussed before, but I can't find a formal bug report, so I've filed T68046 specifically about this. T62398 has one related idea: a list of your own uploads. Whatamidoing (WMF) (talk) 19:39, 2 June 2014 (UTC)
So, here we are in June with an editor complaining that his recent uploads don't show up in VE (and he has no other way to include them in VE), and in a areply a link is given to bug 60398. There we see that in January 2014, we got the following statement by @Jdforrester (WMF):
> new images may not appear in the API search results due to caching.[citation needed]
The exceptional amount of work put into the new search system has this as its most significant user-facing improvement.
So, yet again an "exceptional amount of work" by the devs has gone down the drain, since the "most significant user-facing improvement" still doesn't work five months after these claims... (as for the "cn", perhaps you could have tested whether your significant improvement really worked, instead of doubting the word of an editor? Anyway, I just tested it with File:Parwana 1947.jpg (note the commented out use of a file!), and I can't access it in VE. Not even to add it to Parwana (1947 film), an article where the same image is already present! Fram (talk) 13:29, 3 June 2014 (UTC)
The work on search has significantly reduced this problem, but there is no guarantee that 100% of images will be indexed within ten minutes of being uploaded (which is the amount of time between that upload and you finishing your post here)—or even ten hours. Before this work was done, indexing times in excess of three days were common.
The need to improve search is unrelated to VisualEditor; VisualEditor gives you the same results that the search box at the top of the page gives you. If you'd like to talk about search, then you should probably contact one of the devs working on search, such as User:^demon. Whatamidoing (WMF) (talk) 17:44, 3 June 2014 (UTC)
Wrong, WhatamIdoing. In wikisource, you can add the new image you uploaded easily, no matter if it turns up in search or not. In VE, you cannot add the file if it isn't available in the search results yet. So this problem is not unrelated to VE, as was explained already in this very thread. I am not interested in discussing search, I am discussing things you can do in Wikitext and you can't do in VE, and adding an image you have just uploaded is a rather basic requirement. Let me repeat, from my previous post, the one you were supposedly responding to, with added emphasis: "an editor complaining that his recent uploads don't show up in VE (and he has no other way to include them in VE). I hope the problem is finally clear now? Fram (talk) 20:51, 3 June 2014 (UTC)
I understood that need well enough to file the enhancement request yesterday, Fram. If you'd like to read it, click on the number in the box at the top of this section.
Yes, in Beta, and have restarted my machine to make sure that I wasn't still using some old cached version. Makes no difference for this problem whatsoever. As for "I understood" and so on, then why did you make yesterday's reply which indicated that you didn't understand the relevance of the search problem (and the Jdforrester quote-of-the-week) for VE especially? You aren't making sense here. On second thoughts, don't bother trying to explain this discrepancy, it probably won't help matters anyway. Fram (talk) 17:43, 4 June 2014 (UTC)
I hardly call this our most significant user-facing improvement. I'd like to say near-real-time indexing is Cirrus' biggest improvement over MWSearch. Anyway I digress. Searches should be showing up your media from Commons within a minute or two at most. If it's not that's a bug. I know for a fact that the feature works for newly uploaded images to Commons showing up on enwiki. I justtested (api too) and took about 15-20 seconds for it to show up. So I dunno what VE is doing, but it's not the new search engine's fault (also if you don't have it enabled as a beta feature, you're not using it). ^demon[omg plz]02:44, 4 June 2014 (UTC)
There are complaints at Commons that "old search" is out of service: commons:Commons:Village pump#Search engine is down. "New search" is still in beta features, so I'd assume that most people aren't using it.
Yeah, the old search engine is barely limping along now...doesn't surprise me at all if it's having indexing problems at this point. Re: Parwana: No, weird. It's not showing up. That looks like a bug. ^demon[omg plz]17:24, 4 June 2014 (UTC)
If I VE Plato#Secondary sources and click on the little puzzle piece over that section, I get a box with a heading "Loading..." and then eventually I get a popup with a heading "Warning: Unresponsive script" and a message: "A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
I have two options "Continue" and "Stop script". If I select "Continue", some seconds will pass and the same popup will display again. If I press "Stop script" then box with the heading "Loading..." will display some templates, but not all of them. Firefox 29.0.1, Windows 7 64-bit SP1, Vector skin. --Atethnekos(Discussion, Contributions)22:20, 7 June 2014 (UTC)
Hi Atethnekos,
When bits.wikimedia is having a bad day, then just about everything breaks, including VisualEditor and Twinkle. Ops is making more reliable performance one of their main goals for the coming fiscal year. Whatamidoing (WMF) (talk) 23:07, 7 June 2014 (UTC)
"It's not so visual, it happens every day, no matter what you say" (courtesy Tom Jones)
The "visual" editor has some problems with the visual aspect. This edit was intended as "whitespace fixes", as indicated by the editor. But what happens? If you want to reproduce it, just open the pre-edit version in VE, put the cursor at "In 1960, a student uprising (the "April 19 Revolution") led to[...]", and remove the too many lines of whitespace you get above it. Backspace (nothing?), backspace again (ah, that works!), and so on. Save.
@Fram: I've reverted it, we have discussed before that one should not edit just for removing the white space. Editor has been informed. OccultZone (Talk) 13:42, 10 June 2014 (UTC)
nowiki's still occuring
A couple of days ago I switched the nowiki edit filter back on to see how well VE had fixed the nowiki problem. There are still quite a number of occurrence in the RecentChanges. Today there have been six hits for nowikis caused by VE.
VE should really give the version without "nowiki" as the default, and at most give the option to add a nowiki where people really want it. But the devs (or their superiors) have made it very clear that what is best is not what we will get, since they, well, why exactly remains unclear, but they don't want it (yes, explanations have been given; but no, none of them convincingly explains why the devs chose to go with the 1% exception and therefor disallowed the 99% normal use).
Mind you, if in e.g. the last example, I try to get rid of the nowiki using VE, the end result is [[Russia]]<nowiki/>[[Russia|n]] . Not really optimal code, that... I know what my vote will be in the perhaps upcoming VE-activate RFC some people are planning. It will be exactly the same as the answer the WMF people gave to our requests regarding wikicode and nowikis. WONTFIX. Fram (talk) 14:42, 11 June 2014 (UTC)
They have tried to give different technical explanations, none of which made any sense. Eventually, the only explanation turned out to be a philosophical one, they don't want it because it doesn't belong in their vision of what VE should be (never mind that you need the wikitext in things like templates and so on, and on talk pages, and ... ). They then give examples of places where wikitext would give the wrong result: but the only result is that they are making the exception (those very, very few cases where e.g. a square bracket is wanted as the result) the rule, and are creating much problems. The end result is that this is one of the many reasons that VE is now opt-in on four of the major wikilanguage versions (en, de, nl and es), and a clear minority tool (about 10% of the edits) everywhere else, a year after it was ready for production according to the decvs, and became the default editing environment on those other wikis. Anyway, back to the nowiki issue, no, there isno good technical reason for this.
Sorry, but this is not something we'll ever do, as I explained in comment 9. It's not simply a matter of prioritization - it's a matter of ensuring we can provide a user experience that's not modeled on markup, but on best user experience practices. As James said, we provide keyboard shortcuts, and will provide other user interfaces optimized for markup. But parsing markup within the visual editing context is completely off the table.
And comment 22:
We're listening, but in this case we're saying no, and that decision is final. We can elaborate a bit more on the why if that helps, but parsing wikitext in VisualEditor is absolutely not going to happen.
If accidental insertion of wikitext is still an issue, we should focus on other ways to mitigate that issue.
I love the last line of that comment, "If accidental insertion of wikitext is still an issue,..." No, Möller, VE is still an issue, which you apparently WONTFIX. Or CANTFIX, whatever. You still haven't explained how ensuring we can provide a user experience that's not modeled on markup, but on best user experience practices. can be coupled with the fact that the users still need (and will need for a long time apparently) to insert wikimarkup when they want to edit templates (infoboxes and the like) in article space, but also talk pages and the like. You require users to know wikimarkup if they want to do any editing that goes beyond the most gnomish tasks, but you don't allow them to use that knowledge where it could be useful as well, because it doesn't fit your flawed philosophy. The end result is a botched, hybrid environment that gives a very poor editing experience once you try to do anything a bit more complicated than typo fixing. Perhaps the reason why so few people use it on those wikis where it has been the default editor for half a year or more? Fram (talk) 06:53, 12 June 2014 (UTC)
Template fields will become rich text during the coming year. This will require updating a lot of TemplateData to mark data types for parameters. The ultimate goal is still to make it possible to edit any part of an article without needing to know wikitext. Whatamidoing (WMF) (talk) 19:04, 12 June 2014 (UTC)
Default "right" overrides pre-existing "left" for images?
Cite doi footnotes - can or will the template contents be editable via VE?
There are more than 50,000 footnotes that have been created using the {{cite doi}} template. For example, see footnote 8 of Arctic sea ice decline. In that case, in edit mode, the wikitext editor shows this: "{{cite doi|10.1038/ngeo467}}.
What the reader sees is:
Overland, J. E.; Wang, M. (2013). "When will the summer Arctic be nearly sea ice free?". Geophysical Research Letters 40 (10): 2097. doi:10.1002/grl.50316. edit
Let's assume that the citation is incorrect - say there should be a third author, "Smith, W. N.", included in the citation. Not using VE, an editor needs to know that he/she should click on the "edit" link while in reading mode to make that change. [Putting "Template:cite doi|10.1038/ngeo467" into the Search box will work, too, though that's a bit of a kludge.]
While it might be good for VE to be able to edit the template subpage (not just edit the template parameters), that doesn't seem to be an option now, or in any case I couldn't find that option when I used VE to edit this article. Did I miss something? If not, does the current roadmap for VE call for adding an editing option that would directly edit the underlying templatespace subpage (that is, edit Template:Cite_doi/10.1002.2Fgrl.50316)? -- John Broughton(♫♫)04:21, 12 June 2014 (UTC)
I don't believe that this has been considered. Do you think it would be a good idea? It seems like a very small niche at the moment—maybe one in 1,000 articles will need to make such an edit. However, the general case of clicking on any links (including that 'edit' link in the citation template) might be sufficient to address the problem, and that is now T68549.
On a related point, the ultimate fate of {{cite doi}} has been on my mind recently. I've recently seen interest both in promoting it and in deprecating it. With luck, both groups will decide that autofilling {{cite journal}} from the doi (which VisualEditor might do as soon as August) is a fair compromise. Whatamidoing (WMF) (talk) 19:17, 12 June 2014 (UTC)
We should generally not want to make it too easy for editors to edit templates - that's one of the appeals of templates at all is that it keeps formatting and navigation away from casual editing. Filling out {{cite journal}} is the right solution because it keeps the data attached to the article itself. This is both for scholarly integrity, ensuring that the exact reference used is preserved, and for anyone that reuses content from us. They should only need to copy the article and then create their own template or process to expand the cite journal data. Right now, they have to get the article, get X number of cite doi subtemplates for each reference, then parse them. -- Netoholic@15:51, 13 June 2014 (UTC)
Editing footnotes when their text is in the References section (can't be done)
There are certainly thousands, perhaps tens of thousands of articles where editors have decided to avoid putting the text of some or all footnotes/citations in the body of the article, instead putting the text in the References section. For example, see Helminthopsis (all footnotes) and Pope Francis (footnote 51 and several others).
VE does not currently allow editing of such footnotes. Is this a known bug? And if so, is this a priority to fix? I'm hoping it is, because leaving such footnotes uneditable could cause endless frustration to those who edit lots of articles and are using or want to use VE: Seemingly random footnotes not being editable.-- John Broughton(♫♫)01:40, 12 June 2014 (UTC)
Although it's not a very attractive answer, it's possible to edit these using VE by clicking on the references at the end of the article, which gives access to the Wikitext. Ideally the footnotes could be edited through the visual interface at that point; and it would also be good if VE gave information about this option when attempting to click on the footnotes in the article, which currently just refuse to be edited. Mike Christie (talk - contribs - library) 02:10, 12 June 2014 (UTC)
When the user places his/her pointer over a footnote number of the type being discussed, the user sees a tooltip that says "This reference is defined in a template or other generated block, and for now can be only edited in source mode.", but in fact that isn't true. The user actually can edit the footnote, within VE, by editing the template that contains all the footnotes.
This shouldn't really a problem, because the user can always edit the block of references to remove the template.
Really? VE gives misleading information when such footnotes are encountered, but we should expect editors to figure out that this is misleading? Really? And one solution (for those who don't figure out that they really can edit such footnotes in VE, albeit clumsily) is for editors (including novices?) to change the template formatting, using the wikitext editor. Really?
No. I can file the report, but I expect it to be closed as WONTFIX, because the most transclusions of references can't be edited, and I don't realistically expect them to re-write VisualEditor to try to guess which templates contain refs that could be edited (via the template editor) vs which ones are transcluded from another page. Whatamidoing (WMF) (talk) 17:51, 13 June 2014 (UTC)
I absolutely think it's wrong to assign this a "low" priority; this is a serious problem, if only because there is a random nature to this. ("If I'm using VE, will I or will I not be able to edit this particular footnote?"). I think the fix is not particularly difficult (and yes, I have a fair amount of programming experience), because VE isn't required to "guess" which template has the ref; the ref *must* be in a "reflist" template for the MediaWiki software to work. I've spelled out (in Bugzilla) the three additional steps that the VE software would need to do in order to make citation information within reflist templates editable by simply clicking on the reference number within the body of the article. -- John Broughton(♫♫)18:47, 13 June 2014 (UTC)
No, for it to work, the text must be in MediaWiki's own <references> tag when the page is parsed; the {{reflist}} is just one way to get that information into the native references tag. Specifically, using {{reflist}} is a common way to do it here at the English Wikipedia, and a possible way to do it at maybe two-thirds of the other Wikipedias, and not a way to do it at all at hundreds of other wikis, which have their own ideas about how to handle references. And even where {{reflist}} exists, it is not the only template that could do this: there are multiple templates that can do this here.
So here's the problem: You want VisualEditor to know that there is (sometimes) a template (or many templates) that might contain list-defined refs. How do you tell VisualEditor which templates these are? I am convinced that the devs will not accept hard-coding in the name of your favorite template. Scanning all of them will create performance problems. What other ideas do you have? Whatamidoing (WMF) (talk) 23:43, 14 June 2014 (UTC)
Using an existing ref doesn't work if ref just added
If I add a reference in VE, I can't get it to recognize that reference in the "use an existing reference" option, unless I save my edit and re-open VE. This makes it VERY difficult if I have added content that needs to cite a reference multiple times - I don't like having to save it as unreferenced, and then go back in and add the reference. Example: this then this. Is this a known issue?--¿3family6contribs20:39, 9 June 2014 (UTC)
User:3family6, thanks for these notes. I'm a bit short on time today, but can you tell me exactly what happens, with every detail you can remember? This was working for me in Firefox just a couple of days ago, but there used to be a problem with this (months ago), and it may be a code regression. Thanks, Whatamidoing (WMF) (talk) 23:31, 9 June 2014 (UTC)
@Whatamidoing (WMF): I tried to copy some references from the artist page in VE, but I could not paste them. I then tried to save me edits, but when I clicked the "save changes" button, nothing happened.--¿3family6contribs23:36, 9 June 2014 (UTC)
Oops, I confused this thread with the bug that I filed above. Sorry about that, @Whatamidoing (WMF):. I'm a little fuzzy on the details, and I can't remember how recently I tried to do this (I'm pretty sure it was less than a week ago). Basically, if I add a new reference, it won't show up in the list of existing references if I click the "use existing reference" option. That's as much as I really know.--¿3family6contribs18:01, 10 June 2014 (UTC)
It looks like an intermittent bug; I can get that, or something like that, but not consistently. I've filed T68629 for it. Feel free to add (or ask me to add) any other details or examples you encounter. Whatamidoing (WMF) (talk) 23:51, 14 June 2014 (UTC)
Internet time-out issues
Bug report
VisualEditor
Mito.money
Please app{}
Intention:
I was trying to make a major edit to an article, including copy-pasting references
Steps to Reproduce:
I do not know how to reproduce this, since it involved my internet connection refreshing
Results:
I was working on a major edit to Tunnel Rats (album) for about an hour-and-a-half, when my internet connection broke. I attempted to continue editing offline, as I can in the wiki-text editor, but I could not copy paste references from the Tunnel Rats (music group) article (which was also in editing mode at this point). I figured that I could just save the content I had and then re-open either VE or the wiki-text editor and add the few references which still needed to be cited. But I could no longer save my session. Ultimately, I had to copy the text I had in VE and paste into another open VE session of the same article, which resulted in this mess, where the references were transformed into superscript test and many of the wikilinks disappeared. I then opened up the article in WTE to fix the reference and wikilink problems.
I tried to copy some references from the artist page in VE, but I could not paste them. I then tried to save me edits, but when I clicked the "save changes" button, nothing happened.--¿3family6contribs23:36, 9 June 2014 (UTC)
What's the use of keeping the whole page when you use the "redirect this page" option? If you take an existing page, go to VE, and choose options (or page settings), you get as very first choice "redirect this page to". When I choose this, I don't see the "redirect" text appearing in the VE screen, it is as if nothing has changed. But in "review changes", I note that the redirect has been added at the top of the page, above the complete text of the page. This is totally useless IMO. Keep the categories perhaps, or any remaining interwikilinks, but the rest? At least it should be placed in a hidden comment. Preferably don't expect the editor to remove the article text, the result when I tried it was that I had a redirect with a "use dmy dates" parameter left... Fram (talk) 07:34, 13 June 2014 (UTC)
It's not obvious what should be done. Should you automatically blank it? What if the editor wanted to set the redirect first and then copy the content out second? Should you hide the text, so the redirect page will look right? That will hide the existence of the problem from editors who might be willing to clean it up. Should categories be kept or blanked? They aren't usually wanted on most redirects. (Removing invisible templates is a separate problem.)
If people can come up with an agreement on the ideal solution (assuming that "let each editor blank it, or not, as he chooses" isn't the ideal solution), then I'd be happy to tell the devs. I'd particularly like to hear from User:NicoV or other people involved in other languages or non-Wikipedia projects for this, because whatever system is put in place will need to work everywhere, not just for the English Wikipedia. Whatamidoing (WMF) (talk) 17:59, 13 June 2014 (UTC)
I note that blanking a page by mistake is hardly fatal - any desired text is still available via the History tab (prior versions). If someone is creating redirects, he/she can be presumed to be experienced enough to at least know where to ask for help if he/she can't remember that a prior version of the page still exists, with full text.
Having said that, I think a good solution would be this: When you click "redirect this page", a dialog box appears that has two checkboxes, one for "Blank all existing text", and one for "Remove all categories". Both boxes should already be checked. The dialog box would also have the normal "Continue" and "Cancel" buttons.
This solution would make VE faster, in most cases, than the wikitext editor, because it adds (in most cases) only one click ("Continue"), while the wikitext editor requires (in most cases) selecting all text and hitting the delete key. -- John Broughton(♫♫)18:21, 13 June 2014 (UTC)
Exactly. Microbe currently redirects to Microorganism. That editor wants to redirect it to Prokaryote. I'm not making any judgement on which is better. Just making the observation that I see this user misunderstanding very frequently in the current Wikitext editor usage. As I reported in item #9 above, all you are doing is transporting a frequent Wikitext user error so that it becomes a frequent VE user error. The interface for creating a redirect to an article needs to be more intuitive; it is not obvious that the redirect itself needs to be edited to do this, and, really why should it? Maybe yes, technically behind the scenes, but the user just needs/wants to create a list of redirects they want to add as synonyms for the actual article they are editing. It is this sort of "value added" stuff that will really make VE a leap forward from Wikitext. Wbm1058 (talk) 03:15, 14 June 2014 (UTC)
@Wbm1058 and Whatamidoing (WMF): The way to make VE a leap forward, with regard to redirects, and to minimize user errors, is to avoid jargon and explain clearly. In the Page settings dialog, don't say "Redirect this page to", say "When a reader arrives at this page, send (redirect) the reader to this page:" And don't say "Target page for redirection", say "Page the reader should be sent (redirected) to". [The word "redirect", without explanation, assumes prior Wikipedia editing of redirects; "target page" is programmer-speak.]
Also, if that dialog box had two additional, already checked options - "Blank all existing text", and one for "Remove all categories" (both immediately above the greyed out "Prevent this page ..." option), then it would be more obvious to new editors that what they were thinking they want to do isn't what they are about to do, and they'd be less likely to make a mistake. It would also - as importantly - remove a "pain point" of people wanting to move from the wikitext editor to VE.
Finally, with regard to VE changes: The right side of the Page settings dialog really, really needs to have horizontal separators (lines) between each of the (three, currently) settings. That way, the user can see at a glance that he/she can do one or more of three (at this time) things: create a redirect, change the table of contents, and remove edit links. As the page is now, users have to slow down and figure out what's happening. Also, horizontal separators make it easier to give instructions such as "go to the third setting option".
(As an aside, why is "redirects" on the "More" menu? I tested this in both Chrome and Firefox; it doesn't seem to do anything.)
By the way, the the user guide provides no information on the subject of redirects. Having such information, there, might reduce the number of mistakes of the kind being noted here. -- John Broughton(♫♫)04:37, 15 June 2014 (UTC)
The fact that VE doesn't give any feedback is a huge issue. I don't understand why this has been released in production with this: having no visual return on what they have done, many users won't see that they've made an incorrect edit by adding a redirect. This is again something that will create more damaged articles (especially with many wikis were VE is in opt-out mode). With the feedback, the user would clearly see what he has done, and could undo it if it's not what he meant.
The current behavior is (almost ?) never wanted when creating a redirect. Already selected options in the options box as suggested would be a lot better than the current situation, but I'm not sure it will be very good either. For me, transforming a page into a redirect is an action, not an option: I would rather see a menu item "Transform this page into a redirect" (with better name, I agree with John that "redirect" should be avoided) that displays a dialog box with the needed options: title of the page to redirect to, already selected checkbox for removing the page contents, already selected checkbox for removing all categories (and maybe a list of categories to individually select which one to remove), already selected checkbox for removing all interwikis ?, ... I would prefer this because, I'm not sure what it will give in the options dialog if you come back a second time in the options after adding for example a category for redirect pages: what will be the meaning of the checkboxes ? Or as John said, they could only appear when selecting the redirect check box.
I also like the idea given by Wbm1058 to have VE be able to give the list of redirects to the current page and add redirects from other pages to the currently edited page (the actual work of creating redirect pages being done in the background by VE). This could be an extra feature. But I'm wondering how to deal with pages that already exist (probably prevent them to be added as redirects to the current page ?), or removing redirects.
# Added a subheader 3 header using the "Paragraph" button.
Saved edit
(Was not reproduced the next time I tried it)
Results:
Got five "=" signs on one line, the header text and five "=" signs on the next line. On looking at the diff, a <br> had been inserted after the first five "=" signs
Nope, I made a point of using the VE button; in any case, I'd never use that particular construction, with a break in the middle. Risker (talk) 00:04, 15 June 2014 (UTC)
What I meant was to find out whether you typed "Buses" directly from your keyboard, or if you copied that word from somewhere else. (Much of the rest of the page looks copied.) Whatamidoing (WMF) (talk) 23:32, 16 June 2014 (UTC)
It was one of the few words I added "by hand", because I wanted to have a header there. No copy/paste involved. Risker (talk) 00:04, 17 June 2014 (UTC)
Thanks for your help. I've given up trying to reproduce it. Instead, I've filed T68846 to tell the devs that, no matter how it happened to get there, there should never be a <br> left in any section heading. This should at least cover up the effects of whatever caused that mess. Whatamidoing (WMF) (talk) 16:28, 19 June 2014 (UTC)
Bug Reports/Comments should add the page to the users watched pages.
And you've lost your changes. In most applications, the "x" means "continue editing" - not "yes, discard changes". -- Ypnypn (talk) 00:51, 18 June 2014 (UTC)
I filed bug 66851 for this. I suspect that the 'reason' is that Trevor's re-worked the inspector/dialog distinction, and that the result has been an unnoticed problem here. Whatamidoing (WMF) (talk) 16:57, 19 June 2014 (UTC)
Creating a bullet list should only require one mouse click.
When selecting an item from the menu, like lists, I think the button should be sticky and perform the action that is currently shown rather than requiring two clicks to take an action. The example that brought this to my attention is when creating bullets. The default icon shows a traditional bullet so when I click on that, I expect it to just start a bullet. However, the action I get is to open the menu where I then have to select which bullet list option I would prefer. I think there should be a way to act on the existing icon (and it should change to whatever I had last selected) and also a way to pull down the list if I want to change to a different type of action. This is the way Microsoft Word works. There are two clickable hotspots. Thanks. Don Theflyer (talk) 15:55, 21 June 2014 (UTC)
I am making several edits to The Big Bang Theory (season 1) and while the VisualEditor is really useful it is also a bit laborious to start and stop after each tiny edit. It would be nice to be able to save an edit (and edit summary) but stay in edit mode. Padillah (talk) 15:56, 17 June 2014 (UTC)
Padillah, it would be helpful to know exactly which table(s) you were editing. Some tables work well; others don't. Full support for table editing isn't expected for some months. Whatamidoing (WMF) (talk) 17:01, 19 June 2014 (UTC)
The "table" at The Big Bang Theory (season 5)#Episodes doesn't display correctly for me even if I don't edit it, because it isn't just a table. What looks like a table there is constructed mostly from templates, rather than being a standard wikitext table, and it is not really expected to work at this stage. The tables at The Big Bang Theory (season 5)#Ratings use standard wikitext markup, and they work normally for me. If those standard tables aren't working for you, then please let me know. Whatamidoing (WMF) (talk) 17:51, 20 June 2014 (UTC)
Actually, now I can't edit anything except the first template entry. Activating VE highlights the entire page and clicking opens the first sub-template. I don't know how to edit anything else at this point. Padillah (talk) 18:03, 20 June 2014 (UTC)
I believe that if you use the arrow keys on your keyboard, that you'll eventually get out of the templates and into the regular text. I don't know what's wrong with that particular template, but several are far "bigger" than they look on the screen (or display in one place, but are located and only editable in a different place). Although the dev team has made some improvements, it's very frustrating when you encounter these. Whatamidoing (WMF) (talk) 18:25, 20 June 2014 (UTC)
I'm trying to fix a vandalism [36] on Britain First but there has been a second edit since so I could not rollback. I tried to cut and paste from a diff
select the yellow text in the diff
copy using command-C
switch to a tab with VE and paste
VE didn't add the text I selected instead just pasting a few spaces. I don't think I have any unusual preferences for my diff appearance but it does appear in colour, yellow/light blue.
Would it be possible to make the edit summary box behave like the traditional editor's box in that the browser can store previous edit summaries for later use? I frequently use stored summaries that pop up under the box when using the wikitext editor (in the most recent version of Firefox), but my summaries are not saved when using the VisualEditor. Having to type in a new summary each time with the VisualEditor is a major inconvenience, and in fact this is the main issue that prevents me from using the VisualEditor on a daily basis. It would be fine if restoring the saved edit summaries requires the summary box to be confined to a single line (provided the line is long enough for a lengthy summary. --Albany NY (talk) 20:15, 20 June 2014 (UTC)
I agree with you. They can't be re-used because it's a "textarea" box, and browsers store information only for "text input boxes". I've added links to a couple of related suggestions that might interest you. Whatamidoing (WMF) (talk) 21:43, 20 June 2014 (UTC)
True: People are more likely to fill in a big box than a skinny line. So how about making the text input box be the same size and shape as the current textarea box (assuming that's even possible)? I doubt that people can look at a box on a screen and say "Hey, that's a text-foo box!" I can't. Whatamidoing (WMF) (talk) 16:53, 25 June 2014 (UTC)
I think the reason more editors are adding summaries with the VisualEditor is that the box pops up before the page is saved (so it's more noticeable and may even seem mandatory). The size or type of box probably doesn't have much to do with it. --Albany NY (talk) 01:42, 26 June 2014 (UTC)
Updating the references list
I've added couple new references in an article and the numbers in the inline citations updated. Ie it was "foo [1] bar baz[2]" and now it is "foo [1] bar [2] baz [3]". But the references list at the page bottom still has the old number of references. Gryllida (talk) 03:16, 26 June 2014 (UTC)
If you use MediaWiki's native <references />, then it will auto-update. If you are using a template to transclude the references (e.g., the {{reflist}} template popular here at en.wp), then it won't. This is a "can't fix" (at least, not without taking a truly massive performance hit and/or completely re-writing the database where articles are stored), not a "won't fix": the product manager would like this to be possible, but it can't be done. Whatamidoing (WMF) (talk) 04:18, 28 June 2014 (UTC)
Feature Suggestion: Ability to Resize Columns in Tables
I think a great feature to add to the Visual Editor is the ability to resize table columns, and I think a lot of people would agree with me on this one. And it would also make the Visual Editor better. Please add this feature in a later Visual Editor update. I would really like it if you guys did that. :) Kamran Mackey (talk) 02:20, 29 June 2014 (UTC)
Thanks for your suggestion. Support for editing the structure and formatting of tables is a planned project for the coming 12 months. This one might be implemented as soon as six months from now. Whatamidoing (WMF) (talk) 04:11, 29 June 2014 (UTC)
Template name overlaps remove icon in advanced dialog
In the advanced template dialog, the remove template icon overlaps the template's name with certain long template names. (Firefox 30, Windows 7):Jay8g [V•T•E] 02:40, 28 June 2014 (UTC)
I've filed a report. Since a redesign for both icons (being dumped in favor of words) and the dialog boxes (one style rather than two) is in the works, it's possible that this will be overtaken by events. Whatamidoing (WMF) (talk) 04:12, 29 June 2014 (UTC)
I had just completed a large edit to User:Jay8g/sandbox and pressed the first save button (in the toolbar) when VE decided to freeze up. Nothing was clickable or selectable within VE, and the standard MediaWiki stuff (sidebar & header) wouldn't do anything either (but the UTC clock gadget was still working). Quite frustrating. (Firefox 30, Windows 7):Jay8g [V•T•E] 20:40, 27 June 2014 (UTC)
Nyq, I can't reproduce this in either Safari or Firefox. Could you do a quick double-check to confirm that the problem still exists? It might have been fixed on Thursday's update. Whatamidoing (WMF) (talk) 03:08, 29 June 2014 (UTC)
Whatamidoing, as per your suggestion, I just checked in Chrome 35.0.1916.153 m, the problem no longer appears. You must be right about the Thursday's update. Many thanks! Nyq (talk) 10:51, 29 June 2014 (UTC)
When you add multiple templates in the advanced template editor, such as in this edit, line breaks are not added between the templates, which breaks many of these templates, including the ones I was adding. Adding line breaks, however, would not cause any issues and is needed in most cases:Jay8g [V•T•E] 21:58, 26 June 2014 (UTC)
How would you tell VisualEditor which consecutive templates should have line breaks and which shouldn't? If we put line breaks between all consecutive templates, then someone adding {{fact}}{{pov-inline}} is going to be very unhappy. For that matter, how do regular editors know that it's not okay to put your table-building templates on the same line, but that you really ought to put other templates on the same line? Perhaps we need a more robust system for all users, regardless of which editing environment is being used. Whatamidoing (WMF) (talk) 04:30, 28 June 2014 (UTC)
When they are added using the advanced template dialog, which most people adding multiple unrelated templates won't do, line breaks should be added because most people using the advanced dialog will be adding series templates. I would be fine with adding them on the same line, but this will break many if not most series templates, which are often table-building (and tables are quite touchy). I would be happy with them working if added on the same line, but don't know how to fix that:Jay8g [V•T•E] 18:46, 28 June 2014 (UTC)
I think that would work when you're setting it up, but how would you insert another row, which you might do with the simplified template inserter? Just warn people in the template doc not to do that? Whatamidoing (WMF) (talk) 03:22, 29 June 2014 (UTC)
I'm not completely sure what you're asking. If you're asking what would happen if you add a row to a new table template without using the advanced dialog button, there is a strong deterrent in that it shows up wrong in VE, and if you are adding something to an existing template, VE goes to the advanced dialog automatically:Jay8g [V•T•E] 03:56, 29 June 2014 (UTC)
Doing that would solve a minor problem with column templates, too. I've filed T69268. (Naturally, that means that we can expect someone to show us that this will completely break some other set of templates.) Whatamidoing (WMF) (talk) 04:23, 29 June 2014 (UTC)
I've noticed that when editing existing transclusions (with the needed line breaks), it shows "Content" blocks between each template with only a line break in them, which could be confusing (and shows a workaround):Jay8g [V•T•E] 16:02, 29 June 2014 (UTC)
.svg){kind=logo}
_cover.png&action=edit&redlink=1){kind=link}
